On Fri, Mar 20, 2015 at 2:37 PM, Vitaliy M wrote: > It is possible to use OOP in C, we've been doing it at our company for about 7 years. > > Search the archives, I posted some details on our implementation, a few years ago. > > Basically, it boils down to (1) using naming conventions to emulate OOP, and (2) using aggregation instead of inheritance. > > You can quickly get in trouble if you try to emulate inheritance/method overloading in C. The good news is, you can reap the benefits of OOP withou= t it. Interesting, I will try to find that thread. It does seem like it might be something a bit beyond my capabilities, but hey, why not take another risk! --- 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 my 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. 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'r= e surprisingly easy to read despite being chock-full of great ideas. An example can perhaps explain the idea much better than talking in the abstract: Uart_Init(); Uart_SetBaudRate(115200); Uart_Open(); Uart_PutString("Hello World!"); 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: UartInitializer UartReceiver UartTransmitter So when you call the PutString() method of Uart, it just does a little chec= k and passes the call through to UartTransmitter: Uart_PutString() -> UartTransmitter_PutString() This allows you to break up the code into several smaller, cohesive "objects". It promotes loose coupling between objects, since the only thing you're exposing to outside code, is the interface to the Uart "object". If you were really so inclined, you could combine all code into a single file, or break it up into successively smaller objects, or change the way it work= s -- it would not change a single thing on the outside. A couple of practical hints: 1. Add a custom prefix to your object names. For example, our UART object i= s 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) 2. Create subfolders in your MPLAB project, one per object (in both Source Files and Header Files folders). For example: [StnUart] StnUart.h StnUartInitializer.h StnUartReceiver.h StnUartTransmitter.h 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. 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. Yes, there's additional overhead. Some things seem silly on the surface, fo= r 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, you begin to think "there's got to be a better way". :) 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 .