Dr Skip wrote:
> I haven't followed this thread, other than a casual look at random posts, 
> but
> this statement caught my eye as being so antithetical to engineering
> methodology that it deserved a response. Don't bother wondering about the
> genesis of all the mechanisms that may ruin your design approach, other 
> than to
> identify test cases. First, simulate (on paper, on the bench, etc) every
> combination of disaster that might occur. Lost nodes, noise, lines pulled 
> high,
> pulled low, and so on, even if you don't think it will ever happen. This 
> is
> especially important in architecture or protocol design.

While I agree that this approach has merit, I think it may be overwhelming 
for someone who is just starting out. My advice would be to start with an 
off-the-shelf protocol (many people suggested CAN). As you put it together, 
you will find yourself saying "aha!" when you start realizing why things are 
done a certain way. This is way better than finding yourself saying "doh!" 
when you begin to understand the reasons why your experimental system 
doesn't work.

This sort of approach works for many things. It is often easier to take a 
working system, and tweak it until it does what you want, instead of writing 
one from scratch. Even if you end up rewriting it from scratch anyway.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist