Saturday, January 13, 2007

The old good C and embedded

It is a little strange that guys like me still prefer procedural ANSI C to things like C++ ( although I have to program in C++ at my job) but then I am just commenting on what I do like best. I might add that a real good embedded system might benefit of C++ classes in the OS level, but for the lowest level or the application level I still insist in using C. Because it is funnier? No. It is easier.

It is a little weird to think that people see embedded systems as a single man's tasks. Rather complex systems require a ton of complexity that a single soul could not handle alone. Today, you have people that make the architecture, the design, and people that integrate large portions of the project. It is crazy to see people wondering why such a small thing is so complex.

For example, check a Palm system. A few guys create the hardware. Other guys write the low level code that access its I/Os ( USB, bluetooth, whatever, etc ) and display. Other guys integrate them on OS making probably avail APIs to access them.

Then, another group of people write applications to run at it.

The designer leaves just the hints and joinings for every group.

Complexity is an issue that does not hit regular people. Although they might say that "I don't have a clue how it works" they could claim that, "for those who know it, it might be no big deal".

Suppose you have a real good RTOS and it allows you to create tasks ( I assume that you are a hardcore tech fan from now ), a real simple and ingenous skeleton for your application would be:

int main( void )
/* OS does it, untill now the start up code set tons of things*/
/*Good do it*/
while ( true )


void StartYourTaks( void )
createTask1( functionthatdoes it, stacksize , priority);
/* the list goes on */

The OS will handle the tasks, interruptions and access to shared memory contents, I/os like printers, or serial ports.

I am lazy now.

I will stop.

No comments: