> "When my program blows up randomly, the first thing I look for is..."

>- unintialised variables
>- interrupt problems (must assume nothing, must preserve
>averything, race conditions? multi-byte updates?)

Also check for foul ups in the non-interrupt code where you should disable
interrupts around a piece of critical code (empty/fill a FIFO that is
filled/emptied by interrupt routine) or race conditions on setting/resetting
flags for these. I find it is easy to get the interrupt code properly set
up, but then inadvertently take a short cut in the background routine.

This is an area where I found using Olin's modular development environment
very handy. Having the background routine in the same module, right adjacent
to the interrupt code helps keep the thinking for both sides in step. It
also enforces a process where you have to use an already written interface
routine to access buffers, so that the data registers have an encapsulation
enforced, which helps stop writing spaghetti code that gets you into
trouble.

It also results in having a module to do a function (uart, I2C, etc) that
you know has been thoroughly debugged and works, so in the next project you
do not have to do it again. At worst some additional routines may need to be
added to the encapsulation to add features.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads