I have done similar things in assembler, using Olins packaging of modules .=
 Works very well for keeping things modular.
Alan



> It's not rocket science, in fact IMO it is easier than "traditional"
> embedded programming. I came up with the idea after getting frustrated
> with
> my own inability to effectively write embedded code, then pitched it to m=
y
> partner (who is a much better programmer than I) and together we
> developed
> it into a system that is teachable and produces highly readable,
> maintainable, reusable, extensible, and flexible code.
>=20
> Number  1 in my OP came out of Code Complete 2 (McConnell), and 2 from
> Design Patterns Explained (Trott). I highly recommend the two books, they=
're
> surprisingly easy to read despite being chock-full of great ideas.
>=20
> An example can perhaps explain the idea much better than talking in the
> abstract:
>=20
> 	Uart_Init();
> 	Uart_SetBaudRate(115200);
> 	Uart_Open();
> 	Uart_PutString("Hello World!");
>=20
> Uart is the "object" and Open() is the "method". Small change, huge
> benefits: you can now think in objects. Under the hood, the Uart object
> relies on several "helper" objects:
>=20
> 	UartInitializer
> 	UartReceiver
> 	UartTransmitter
>=20
> So when you call the PutString() method of Uart, it just does a little ch=
eck
> and passes the call through to UartTransmitter:
>=20
> 	Uart_PutString() -> UartTransmitter_PutString()
>=20
> This allows you to break up the code into several smaller, cohesive
> "objects". It promotes loose coupling between objects, since the only thi=
ng
> you're exposing to outside code, is the interface to the Uart "object". I=
f
> you were really so inclined, you could combine all code into a single fil=
e,
> or break it up into successively smaller objects, or change the way it wo=
rks
> -- it would not change a single thing on the outside.
>=20
> A couple of practical hints:
>=20
> 1. Add a custom prefix to your object names. For example, our UART object
> is
> called "StnUart" (Stn =3D ScanTool.net). It makes it easier to recognize
> whether you're using your or someone else's code (you could write object
> 'wrappers' for someone else's code, if you wanted to)
>=20
> 2. Create subfolders in your MPLAB project, one per object (in both Sourc=
e
> Files and Header Files folders). For example:
>=20
> [StnUart]
>   StnUart.h
>   StnUartInitializer.h
>   StnUartReceiver.h
>   StnUartTransmitter.h
>=20
> 3. Never call the helper objects directly. So, if you wanted to send a
> strring over UART from main.com, you would not include
> StnUartTransmitter.h,
> only StnUart.
>=20
> 4. With very few exceptions, you should only have two files in the "root"
> project directory: main.c and Initializer.c. Everything else should be an
> object.
>=20
> Yes, there's additional overhead. Some things seem silly on the surface, =
for
> example having four successive function calls to set a variable. The
> benefits are realized over the long term, and become especially apparent =
on
> projects with many thousands of lines of code. Once you start drowning, y=
ou
> begin to think "there's got to be a better way". :)
>=20
> Vitaliy
>=20
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

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