First Time with Microcontrollers

EE here, let me get you started its been a while since I have done PICs so bear with me

Luckily Microchip has a decent IDE, start by downloading MPLABX and setting up a project with the microcontroller specified as the target.

Embedded programming is literally RTFM, so read the datasheet linked by . The way embedded programming works is you literally have a ton of macros which are defined in the header files MPLABX automatically adds to the main.c file.

For PICs you find the register you want to set, say I2C1CON (the register which controls the #1 I2C interface, see page 188 of the maual), and you set it to what you want. Suppose I want the interface to operate in 10-bit mode with everything else default I would write:
I2C1CON = 0b0000010000000000
Then, I need to enable it, I do that by writing the enable bit to one:
I2C1CON = 0b1000010000000000
Its good practice to set the config bits before you enable modules, and if you need to change the config to disable it first.

One thing about PICs is that you need to set the config of the pins before you can use them, they default as inputs on startup and you need to configure them as you need. Say I want to use RA0 (the first pin on port A) as an output for an LED, I would first make my life easier by #defining it to a variable name:
// Define RA0 to be LED0#define LED0 PORTAbits.RA0
This means that when I call LED0 and set it to 1 or 0 it will toggle that pin (which has an LED on it).

Now I will initialise the port, I do this by setting the tristate buffer to the config needed for it to be an output, and just as a precaution I set the output low:
void main(void){//Initialize RA0//Set the tristate buffer for RA0 to outputTRISAbits.RA0 = 0;//Set the port lowLED0 = 0;while(1){//main loop}}
Note that I didn't make my main return anything, this is because in embedded programming you don't have anything to return to. If you want to make your main function return a 1 on completion there is nothing stopping you though.

The PORTAbits.RA* and TRISAbits.RA* are defined in the headers, if you want to do things the long way you can also do what I did with the I2C1CON example above. Likewise you can also go I2C1CONbits.A10M and I2C1CONbits.EN instead of what I did there. MPLABX has this nice feature where if you type something like I2C1CONbits. it will bring up a dropdown menu with all the possible completed names.

One thing which trips up a lot of people new to PICs is the ADC module, if you are wanting to use a pin which can be set as an ADC input you will also need to configure the ADC port config register. In my example above I used RA0, this isn't a pin which has ADC functionality so I didn't have to do anything.

There is lots of other stuff you will have to learn as well but this will get you started. Luckily though you are using a PIC and because of the way they are setup once you have programmed one PIC you have basically programmed them all since they are so similar.

I forgot to mention something important, you also need to set the configuration for the oscillator and other important system functionality.

In MPLABX you do this by going to the configuration bits menu and select what you want, then you copy the output and paste it at the top of your main.c file.

You will also need a compiler, the Microchip XC16 is the one you will need for the PIC24

Presumably you've only previously used C on an x86 machine with glibc, so I'll warn you: Be careful of the standard, alot of what you know might not apply (like 'char' is one byte) so do things the standard way (sizeof(char))and make sure you're not falling into undefined behaviour.

The interesting question isn't why he applied for a job he doesn't know anything about--people apply for jobs for which they're under- or un-qualified for all the time--but how the fuck he got it.

How did you, ohpee? Are you a nigger or vagina life support system who got in as a diversity hire or something?

is having "void" for an empty parameter list in function declarations common or required in C? I've never seen it before, but i don't use C much. How is memory management usually done in embedded devices like these?

Good employees can be just as hard to find as good jobs, consider that a significant amount of applicants can't even do fizzbuzz. And it's certainly not uncommon to hire an employee who doesn't know the particular language or domain you seek, and have them learn it, especially for obscure languages.

Here is a piece of advice, good work ethic is more important to employers than skills. Skills can be learned, work ethic cant.

OP applying for a job he clearly had no existing skills in is a sign hes willing to step out of his comfort zone and do new things, which is extremely attractive to the employer. There is always something simple that needs doing so there is nothing bad about having a new and inexperienced engineer around who you can give it to so your experienced engineers can focus on the important stuff.

Required.

Preallocation mostly. But for filtering, fixed size buffers are usually enough.

For the love of god, use a code analyzer. This will save you hours of debugging because you managed to write 1 byte outside of a variable and fuck your entire program up. You have absolutely no protection against buffer overflows and, unlike in a desktop environment, your program will happily plow along until it does something weird 30 functions away because you wrote something out of bounds earlier.

Having void as the sole argument in a function that accepts nothing is absolutely required in C. The default function declaration in C is (iirc) int fn(...) which means a function that takes any number of arguments and returns an integer.

If it's using CCS, then the debugging environment should be pretty good. If it's anything like the one I've used, you can do the usual things such as breakpoints, step in/over/out, variable inspection, register inspection, etc.

There are other and (in my opinion) better debug options for embedded programming, namely putting extra LEDs and buttons onto the board.

They are an easy to use and visual way to see if and where your program is fucking up

There is far more debugging possible with cheap components you can easily add to the circuit board than be done with an expensive debugger/emulator.

He might have been talking about automated analysis for buffer overflows etc. , for example through symbolic execution.
doc.ic.ac.uk/~cristic/papers/klee-osdi-08.pdf

Yeah. So many times I've seen people run into weird errors where they wrote into parts of the RTOS because they overwrote a global variable somewhere.

LEDs and buttons show that execution has happened, but I find breakpoints to be more generally useful. If you don't have a debugger, then use them but I'd imagine the company OP's working for probably has a debugger or two available.

You could always use Forth instead of C.

Full front-panel with toggle switches ftw. But they also used to make "system monitor" boards, some with just 7-segment LEDs and hex keypad, others more fancy that connected to CRT and keyboard. Wonder what happened to that...

Manually.You have to be aware of how many function calls you're making, especially with interrupts, because you risk letting the stack overflow and when the stack overflows it gobbles up global variables first.