Olin Lathrop wrote:
>> "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.
>
> Those things generally help, but there's more to it than that.  On a small
> embedded system there is no operating system, so code may have to make
> assumptions about how certain parts of the hardware are used, and about
> overall project firmware structure.  Even well written code can be
> incompatible and difficult to integrate into another project.
>
> For example, one project may use a master event loop.  Another project may
> use simple threads.  A subsystem may be designed quite differently 
> depending
> on which model it assumes is in use.  Making it general may not be easy,
> either requiring a mess of build-time switches or excessive runtime bloat.
> Your project may need to reserve interrupts for a particular low latency
> task, but a off the shelf subsystem uses interrupts in a integral way.
> Changing its overall structure may well be harder than creating a subsytem
> designed from the beginning to not use interrupts.  Then there is 
> allocation
> of limited hardware resources that need to be planned at the project 
> level.
> A off the shelf subsystem may have been designed assuming it can have a
> hardware resource to its exclusive use.

I understand. What I said above applies more to the higher-end PICs than it 
does to the PIC16s et al.

I might have mentioned that we started using OOP techniques for embedded 
development on the 24H. I was really surprised at how easy it was to 
transfer the modules from one project to another, it was almost literally 
drag-and-drop, plug-and-play.

Having a faster chip with more resources means that you can also apply 
patterns, for instance you can use an Adapter or a Facade, to temporarily 
hide the ugliness of borrowed code. Eventually the code gets refactored, but 
the interface doesn't change so the rest of the code can stay the same.

Vitaliy 

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