Vitaliy wrote:

> 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.

Even for a student, starting from scratch is a great exercise. To do it right,
you'll still have to analyze what happens when things go wrong, the list is no
shorter, and if it's your own creation, you'll probably have more accurate
'simulations' in your head than trying to imitate the intricacies of some other
protocol and/or design. That doesn't say one shouldn't become familiar with
other designs in advance, but by digging and thinking deeper, one can decide
what subset or superset or combination of protocols might work for this given
case.

Having done much teaching, I can attest to the value of having to thoroughly
think through the system in the early part of one's education. You not only
have real world effects later on, but the protocol has to implemented in some
hardware and software, with their interfaces, et al. Problems will happen.

I suggest, as a general rule, to first look at what's out there for designs
(protocols) and learn what you can on what they do and why. Then create a list
of your specs. Have a bare minimum required list and a 'that would be nice to
have' list. Design and simulate in your head, with state diagrams, etc. Refine
until the bare minimum list works in all scenarios, and the failure cases have
acceptable or recognizable modes. Then build and test it. Then start adding on
the nicer features.

This makes it a good educational exercise while not trying to conquer the world
with rev 1. You become familiar with other work, you think about your
particular needs and how they could be implemented, you end up with a design
that you are intimate with, rather than trying to figure out why someone else's
isn't working, you have a quicker implementation, and a base to grow from
(which is also easier to debug).

I've seen a lot of students just pick up something like a protocol and
implement it, only to spend multitudes of more time trying to debug it in their
implementation (they missed something in hardware or interface or code that was
needed in their case but they didn't take the time to understand that or think
they needed to). Then, when they go to tweak it, because they aren't totally
familiar with the 'black box' they decided to use, they alter a part that is
necessary in other non-obvious ways and are in deeper doo-doo as far as getting
it to work goes. Not having spent the thinking time in advance puts them in
even deeper over their head. Thinking it through also develops good engineering
skills and an ability to find ways to save time later on.

-Skip

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