Kris Heidenstrom wrote:
Hi all,
I couldn't find an email address for Steve Underwood, who wrote the very good
online manual for mspgcc, so I'm posting
this message on the mspgcc-users forum (even though I'm not a user :-)
In response to the "tips and trick [sic] for efficient programming" section. I
agree with most of these recommendations
and thank you for a good quality piece of work. I think some explanations would
be appropriate, rather than just the
guidelines. I have specific comments on a few points:
5. Avoid using global variables of small size - it is a waste of RAM.
I don't understand this at all. It's normal for an embedded program to have
lots of global variables, and many of these
will be bytes. If you mean what you wrote, I disagree and I don't see your
point. If you mean something else, perhaps
you could make the wording clearer. By "small size" do you mean smaller than a
byte?
Have you looked at the typical embedded programmer's work? 90% of all
their variable are global. It derives from poor assembly language
programming, I guess, and the style is carried over to poor C programming.
6. Avoid using volatiles, unless they are really necessary.
No one would ever declare a variable volatile unless there was a good reason
to. Are you saying that the compiler can
optimise better with variables which aren't volatile? That's normal for any
compiler AFAIK.
Do you have any idea how small a percentage of embedded C programmers
understand what volatile really means, and where it is needed?
Lots of people who have used the IAR tools complain about GCC being
broken, because changes to a global are not sensed. The IAR compiler is
too dumb to optimise away most things, and you can be sloppy and leave
out all the volatiles. Most programmers do. At the other extreme, some
people put volatile in front of everything. That looses you a lot of
space and speed optimisation with GCC.
const is another important keyword, especially for embedded systems,
that people can't really get the hang of. static is even worse.
7. Use int instead of char or unsigned char if you want an 8 bit integer.
What? An unsigned char _is_ 8 bits wide. Do you mean the case where you need
eight bits _plus sign_? That would be a
9-bit integer.
If you use a char or unsigned char as a simple small integer, like a
loop counter, the code will be bigger and slower than using the natural
integer of the machine - an int. Perhaps I use expand the wording there.
18. If you execute
while ((long) a & 0x80000l);
the program will hang, unless 'a' is declared volatile. So, do it!
That would be a really weird and pointless thing to write, unless you _know_
that 'a' is volatile and _will_ be changed
elsewhere, e.g. by an interrupt handler. And I think you mean "So, _don't_ do
it!"
Maybe the wording could be better. My intention by "do it" is do declare
the thing volatile. I should change the order too, to group this with
other volatile related points.
19. Delay loops are very sophisticated routines.
[...]
I don't think delay loops are necessarily "poor programming style" in the
context of an embedded system where the MCU
clock frequency is known and the device has a (fairly) predictable number of
cycles per instruction. If you want to
delay by a few microseconds, a loop is the obvious way - you could use a timer
(if you have one spare), with or without
an interrupt, but this would add lots of overhead, and a very short tight delay
would not be achievable. True the
maximum execution time is not defined if interrupts are used and interrupts are
enabled during the loop, but this is
often not the case - it depends on the context in which the code is used. In
any case, it's not always necessary to have
a maximum limit on the delay time - for a safety timeout, for example, it's
just necessary to avoid getting stuck
forever in a loop somewhere due to some hardware failure. Instead of saying words to the
effect of "don't do it", you
could suggest how to trick the compiler into not optimising the loop away into
the ether. For example, adding an
"asm("nop")" (or mspgcc's equivalent) in the body of the loop might be enough;
if there's no recommendable way to do
this, perhaps you should add a feature to the compiler to specifically support
short delays, e.g. it could generate the
loop itself, given a number of CPU cycles for the delay. Short delay loops are
common in embedded systems software; some
conventions that apply to other programming situations apply less or not at all
to an embedded system. Just a
suggestion.
Delay loops are often the only appropriate way to get a small
predictable delay. There's nothing wrong with that. There is something
wrong with
for (i = 0; i < 10; i++);
GCC will optimise it clean away, unless i is a global volatile. Even if
i a global volatile, the speed of the loop is totally uncertain. The
brief_pause routine I show in the manual is what I would call a good
pause routine - compact and basically predictable. Sure, and interrupt
could extend it, but these things are usually there to impose a well
defined minimum delay. Adding _NOP() is wasteful - maybe only a little,
but still poor style when you are programming a 1k chip.
Do not do anything unless you know what you're doing :)
Very good advice for all embedded systems programmers!
Steve
