> See my comments added in-line below/ > > Sincerely, > > David Smead
I've snipped a bit, and added new comments below. mvh., David > > On Fri, 4 Nov 2005, Kris Heidenstrom wrote: > > > Hi all, > > > > > >> 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. > As far as I can tell, accessing data directly (in absolute mode) has the same size and speed as accessing it via a pointer. In fact, absolute mode is implemented as indexed mode using R2 (which gives 0 in indexed mode). Occasionally, the optomizer might be able to use auto-increment or auto-decrement modes for accessing structured data, which might be very slightly more efficient. The reason for the tip could be that mixing bytes and words in the global data section could waste bytes through alignment padding. > >> 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. > > Not true, and not true. Proper use of "volatile" causes newcomers to embedded programming a great deal of trouble, and sometimes they do err on the side of making too much volatile (for example, there is the myth that all data accessed by interrupt routines must be volatile). Also, there are plenty of embedded compilers which effectively treat all global data as volatile - people switching from these to gcc are particularly prone to confusion. > >> 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!" > > People do write this sort of thing - while loops that wait on a flag, or a counter passing a certain value are common. And if you don't know how to use "volatile" properly, you get in trouble. And he does mean "So, do it!" - the "it" refers to "declaring a volatile". But I'd have to agree it's not very clear. > >> 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. > > >> Do not do anything unless you know what you're doing :) > > > > Very good advice for all embedded systems programmers! > >
