AVR-Chat

> Also spend a lot of time looking at the generated assembly output. 
Is
> not so important as to be able to write assembly as it is to be 
able to
> read and understand what the compiler thought of your instructions. 
This
> way you know how expensive it is to attempt to abstract the UART via
> indirection in a structure. You know that 16 bit values require two
> accesses which an interrupt may jump in between. All those little 
things
> that differentiate code which happens to work vs. solid code which
> always works and is easy to maintain.

I know a lot of people use C, and yet I see this sort of thing, and 
compiler bugs, and rather bad code optimization, and I think.. "and 
this is better?"

I guess I'm still a hardware guy at heart, I tend to write my code 
from the output bit-twiddling on up, twoard the functional routines 
that I'll need to implement the spec, which is usually looking from 
top-down.  I don't spend a byte when a bit will do, and I don't push 
anything that dosen't need pushing. 

I try to write in a way that is pretty much hardware independent, at 
least as far as moving I/O pins around, so that a routine to drive an 
X device can be popped into another AVR system on a different port 
and pin, with only changes to an equate table. Of course some ports 
being in ram space hoses that plan sometimes, but at least it's not 
prone to subtle problems. :)

Subtle problems are the worst, like NOT PROGRAMMING CKOPT for 
example! 


> One parting note, use some sort of version system. CVS, Subversion,
> something, anything, from the start. Get used to frequently updating
> your repository with concise comments as to what you were doing or 
what
> motivated the changes. Comments in the code are important but the
> quality of comments in your commits are just as important.


Tortoise CVS makes that pretty painless. I have an offsite CVS server 
which helps protect me from any little disasters.