that people can't really get the hang of. static is even worse.
That's because it has TWO meanings, depending on context:
"private to this file" and "don't store on stack - store in a fixed RAM
location."
The initialisation & recursion etc issues caused by the second usage also
cause problems!
Isn't C wonderful? :)
Richard
----- Original Message -----
From: "Steve Underwood" <ste...@coppice.org>
To: <mspgcc-users@lists.sourceforge.net>
Sent: Friday, November 04, 2005 3:16 PM
Subject: Re: [Mspgcc-users] Attn Steve Underwood, mspgcc online manual
section 7, "tips and tricks", opinions and questions
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
-------------------------------------------------------
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
