> It's one very common rule : "Every program has one  error at least.
> Correct it and you will have two others".

I think this is completely wrong when talking about small microcontrollers
like PICs, and very bad to start thinking it is acceptable.

Most PIC projects are small enough and relatively simple (compared to 10s or
100s of thousands of lines of high level language code written by lots of
different people) so that they can be very reliable with decent software
practices and good testing.  While it usually impossible to prove any one
project produces the right outputs for all possible inputs, you can get a
pretty high confidence level with reasonable testing.  Of course I've had
bugs in PIC code I've written, but the overwhelming majority of PIC projects
worked as intended after release to the customer.

I think there are two important top level factors in producing reliable
code, good software coding practises and testing.  Good coding practises
start with well partitioned modularization and meticulous commenting, but
there has been much said about this already.  Testing seems to be ignored,
but is just as important.  All too often I see someone doing a quick test
and claiming it works.  Good testing includes trying to break it in as many
devious ways as possible.  There is nothing wrong with the testing phase
taking more time than the development phase.  Sometimes I've written more
host code to test something than PIC code to implement it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu