Olin wrote:
>>> ...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.
>
> I also take issue with the statement that it's often easier to take a
> working system and tweak it.  Most of the time I've taken someone else's
> code and tried to integrate it into a embedded system it was more trouble
> than it was worth.  The other code is rarely well written, and of course
> never fits into the philosophy of how my particular system is structured. 
> I
> can't think of a single PIC system where in hindsight I wouldn't have been
> better off creating the subsystem myself.
>
> The only bright spot I remember about using existing code were the JPEG
> image routines that I integrated into my own imaging library.  The 
> routines
> I found for free on the net from the from the Independent JPEG Group just
> worked, and the interface fit well enough into my image file driver
> architecture.  Of course this was PC code, not PIC code.

Let me clarify what I meant.

I recently read an article about Tesla Motors, which mentioned a story about 
how its CTO (JB Straubel) got started with electric vehicles. When he was 
fourteen years old, he got his hands on a broken down golf cart that needed 
to have its electrical system rebuilt.

Sometimes taking a golf cart and tweaking it for your needs, is sufficient. 
Sometimes it isn't, but taking one apart and playing with it would make it 
much easier to build your own electric vehicle.


Now, regarding code reuse.

I agree with you that the embedded code out there is generally poorly 
written, and that often you are better off creating the subsystem yourself.

HOWEVER :-)

I strongly believe that it does not have to be that way. I think it's 
largely because we in the embedded world lag behind the PC world when it 
comes to programming techniques. Code reuse is all the rage there.

You mention how you were able to use existing code for JPEG routines on a 
PC. I find the same is true about the standard C libraries on a PIC. While 
at the same time, Microchip libraries and example code are pretty horrible.

The key difference, is that the C libraries have a simple and clean 
interface, and they have few dependencies. It is possible to design regular 
programs this way, too, as long as you follow the "loose coupling, tight 
cohesion" principle.

"Loose coupling" means having as few connection points between program 
elements, as possible. "Connection points" are functions and variables that 
a module exposes to the outside world, or variables that are shared between 
two or more functions or modules.

"Tight cohesion" is how you get the simple and clean interface for both 
functions and modules. A function should only do what its name implies. Not 
more, not less. A module should only contain functions that directly relate 
to the module's "job description".

If properly followed, these rules help ensure that you can reuse the code 
with a minimal amount of pain.

Vitaliy 

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