Hi Members,

Could anybody please let me know or point to some standard tutorials which says what are the good practices to be adopted while programming 8 bit PIC16 microcontroller in C language?
I need to know this in terms of 8 bit PIC16 programming more than just general C coding guidelines?

Thanks & regards,
Sarvanan.

 

From a performance perspective (EDIT), the best advice I can give you is stay connected with the underlying asssembly ie. always have a pretty good idea of how your C will be compiled into the device's instruction set. In my code this results in:

1. Avoiding floats; use chars where possible; shorts are ok
2. Avoid divide (/) operators, and code up my own proxy for it in C
3. Using bitwise rotate operators (>>, <<) more than you usually would
4. Use pass by ref. sparingly
5. Be aware that making the code readable by splitting into functions has a runtime cost

However if you're in the fortunate position to not worry about a few ms lost here or there then disregard this

 

Well this is a guideline for optimizing.

You should by all means isolate IO statements to keep your code portable.
Dont use numeric values through the source but use defines

Make use of lookup tables, and remove reundant calculations, especially multiplication and division,
if you need the result multiple times, dont calculate it multiple times.

If you need to multiply with only a few different values, optimize with lookup table and shift operations.

Actually in some cases using a multiplication or division doesnt make a difference but be aware the code size will increase a lot and its very slow

 

I agree with all that but in many cases it may be better and easier to use floating point maths if:
1. There is enough space in flash for the code.
2. If the time it takes does not compromise the code.
Using floats can make the code much clearer and easier to understand, especially when you come back to it after some time.
So avoid floats where you need to, but don't sweat it if you don't need to.

 

I agree with all that but in many cases it may be better and easier...

Bang on, I've modified my original post. I'm down a rabbit hole at the moment where runtime performance is critical and I keep getting caught off-guard by 1000s of instructions lost on seemingly simple operations.

 

... what are the good practices to be adopted while programming 8 bit PIC16 microcontroller in C language?

Same as with any other programming - think before you do, know what you're doing, be creative, program in small increments, take responsibility for your actions, etc.

 

Keep in mind that C does not fully insulate you from the underlying PIC architecture requiring that you know something about that. A couple of examples I can think of :

RAM is limited and broken up into banks. That usually means limits on array sizes, buffers etc. requiring that any single array be able to fit into the 80 or so bytes in one bank, even if you have RAM available in other banks.
RAM and ROM need different instructions to access data. Structs/strings etc. of the same type are frequently stored in both. Some compilers use run-time tests to generate code to get that data and keep a light footprint. Others like MikroC ver 6, read the constant data from ROM to RAM at startup severely limiting the amount of constant data you can have.

In short, C can be useful tool but you still have to know the underlying PIC hardware very well to avoid problems.

 

just general C coding guidelines?

It all depends on what you mean by "good" or "bad".

I generally prefer modular and robust code vs. Fancy code. If that's your cup of tea, try misra for a good starting point. Or lint.

 

Use a device with more than needed memory/speed resources at first. This allows you to concentrate on good data structure/algorithm design and good implementations of those structures and algorithms. After it works then try to optimize for speed and space.
Readability is king!

Learn to use (from the hardware point of view) the structured 'goto' (switch) in C and don't be afraid to use a plain 'goto' for fatal error handling in nested functions or modules to a single label. Typically the implicit/global processor state gets manipulated at this level so you want the program state to closely mirror that at a low level. This means things like designing data structures that are a binary match for peripheral device registers so they can be easily manipulated and passed with structure pointers. Use global variables sparingly but because of memory limitations the use of 'static' variables in functions is sometimes a good idea in non-nested functions.

http://embeddedgurus.com/barr-code/2011/08/dont-follow-these-5-dangerous-coding-standard-rules/

8-bit 'integral promotion' in XC8 is not your friend when you need to do strict 8-bit math tricks (non-portable hacks) for speed.

http://www.microchip.com/stellent/groups/sitecomm_sg/documents/devicedoc/en555854.pdf

Because 8-bit controllers are usually directly involved with I/O devices and simple hardware interrupts our friend the volatile keyword in C is important. Atomic operations are usually at the 8-bit level so 16-bit integer values can change mid-evaluation when volatile if they are not protected with memory barriers (like disabling interrupts during some operations and re-enabling them later, double reads, buffers or etc ...).

 

Thanks a lot to all of you who responded to my query.

I got enough information. Thanks again.

With best regards,
Sarvanan.

 

Bang on, I've modified my original post. I'm down a rabbit hole at the moment where runtime performance is critical and I keep getting caught off-guard by 1000s of instructions lost on seemingly simple operations.

If that's an issue, plan on skimming through the list file looking for lines of C that compile into outrageous amounts of assembly code. You may be able to rewrite the C instructions to encourage the compiler to be more efficient, or perhaps you'd want to put in a block of assembly instructions. It's another argument for having some understanding of how the processor works.

 

If performance is that important, use a faster chip or go assembly and be a great programmer.