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?
> 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.
> 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.
> 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!"
> 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.
> Do not do anything unless you know what you're doing :)
Very good advice for all embedded systems programmers!
Kris
k...@abbey.co.nz
Kris Heidenstrom Embedded systems design engineer / programmer
Abbey Systems Ltd Telemetry specialists Wellington New Zealand
Voice +64 -4 -385-6611 Fax +64-4-385-6848
