See my comments added in-line below/
Sincerely,
David Smead
www.amplepower.com
www.amplepower.net
On Fri, 4 Nov 2005, 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?
If you organize variables in structures, or arrays, then access to them
can be done with a pointer, which may stay in a register much of the time.
Code will be smaller and faster.
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.
An int is the `native size', whereas signed 8 bit variables force sign
extension be done.
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've been programming embedded systems since the mid-1960s, and I don't
use delay loops, although I have used three nops in a row to stretch a
pulse. I've also resorted to tricks like using the known time of an A-D
conversion as a way to time some action. I can remember when computers
were slow and wasted cycles meant something wasn't going to work right.
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
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
