Hi all,

I've had this idea buzzing in my head for quite a long time... and I need to discuss it with experienced people. A recent reply I just made suddenly compelled me to make this posting. Also I haven't seen a really HOT technical discussion on this forum for some time now, and I'm hoping this turns into one!! :-))

Object Oriented Analysis & Design (OOAD) for Hardware, and especially Embedded Systems, design.

Oh, I am not talking about C++ and OOPS software design and all... I mean the design of the ENTIRE systems as a whole: processor, peripherals, sensors, displays, motors, FPGAs, PLDs, software, all other hardware components and all.

Ok its my software background talking now, but frankly, I can't see anything wrong in OOAD. Thinking and working ALLLL the time in OO at my job, I am impressed by how systematic it makes the job of developing huge systems with a bunch of people working on them. Its a great way of laying out the requirements and assigning responsibilities to each module, and prioritizing tasks. Of course the countless classes and objects this sort of design generates makes it terrible for the programmer to trace program flow and locate bugs... :-)) But as a design methodology, its excellent. I guess it can be used on almost any type of system.

In fact I am sure that EVERYONE of you does it ALL the time (of course but not realizing its OOAD), only I'd like to get it clarified and formalized.

Its pretty easy to represent each module / component as an Object, be it an ADC, or a LCD, or the processor itself.

Each one provides an interface for other objects to use its functions (say clear and LCD) or access its private variables (e.g. read an ADC) An interface in this case is a clearly defined and usually simple protocol (eg. setting and clearing of bits and reading port to get value of ADC)

This fulfills one of the requirements for OO: ABSTRACTION. The other object does not need to know the internal workings of the ADC to use its funcitons.

It also caters to another requirement: ENCAPSULATION. Whatever data (registers) are used by the module internally is hidden, and only the proper variables are exposed through the interface. This is most apparent in multi-processor environments where each processor knows only what the other processor is willing to give.

The next requirement of OO is INHERITENCE. This is I think can be easily achieved at the microprocessor/ microcontroller level, but not so easily anywhere else. Suppose uC #1 "inherits" an ADC... if another uC, say #2, wishes to access the value of that ADC, it must go through an interface provided by uC #1. I suppose the hardware equivalent of Inheritance would be having that "base" and "sub"component on the same PCB, with the only interface being through the "sub" component.

The last requirement of OO is POLYMORPHISM. The best example I can give is to write a protocol such that the uC decides at run-time which function is to be called based on the contents of the request. Maybe there are better examples out there :-)) ... Virtual functions (having the functionality of the base object implementedby another) can be explained as one microcontroller implementing a function for another. This, and over-riding are something similar.

Despite all this OO design, the assembly code itself can be in assembly, C, C++ whatever.. so you don't have to worry about obfuscated code ;-)

Maybe embedded designers well-versed in OOAD can offer more examples and suggestions.

As I said all these things I mentioned are what designers actually do. I am only mapping it to OO. It will make the deisng process much easier... For example once you have the OO model ready and can clearly see what each Object (component) needs to do, it will be much easier to select the appropriate IC for it.

This model won't really be make difference for small, one-uC designs, but rather for complex applications that require several components. I strongly believe that for complex systems a good design will be using a number of smaller/simpler processors each handling certain tasks, rather than having the full functionality embedded in one powerful, fast, expensive, high end processor. The testing of such systems will also be easy...since you can test each component separately through PC serial/parallel port and logic analyzer to check whether it is doing what it is supposed to do.

Another great idea would be to represent the Power Supply and Noise as Objects that provide inputs to the System Objects. Maybe Noise can be the Base Object if ALL Objects, since noise is omnipresent :-))... only it will have virtual functions that may be implemented depending on the amount of noise present. This may make it easier to consider all possibilities in the design, although you will not have to implement them.

Of course, software OO and hardware OO is quite different... in Software you can create any object of any class as many times needed at run-time. But that is due to the vastly changing nature of the application... I don't think its the same case for hardware.

I know this seems like a lot of gobbeldygook to people not introduced to OO...Sorry about that! I would like to have a nice, heated discussion on this. Comment, suggestions, rebukes, corrections solicited !!

kundi