Developing OS Abstraction Layer

This is not my preferred way of doing it. You could end up with #define hell.

A way I find to work well is to have a common header file that defines the abstracted function prototypes, then have a separate C file that implements the OS specifics for the abstracted function. Then when creating a project you just include the correct C file.

For example, if wanting to have a simple delay function.

In RTOS.h include the prototype:

void Delay( unsigned long );

RTOS.h is then included in your source files, and as it is not dependent on the actual RTOS being used never requires modification.

Then for RTOS A create the source file RTOS_A.c, and implement:

void Delay( unsigned long ) { ____/* RTOS A specifc code here. */ }

and similarly for RTOS B create a separate source file RTOS_B.c and do the same thing.

When building for RTOS A you include RTOS_A.c in your project, and obviously when building for RTOS B you include RTOS_B.c in your project.

No #defines required, except maybe one in your makefile.

Regards, Richard.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC .... and soon AVR32

If you think you can do it with just a layer of #defines you're a braver man than me ;) -- think about it, all that's doing is creating a thin renaming layer between your POSIX API and the 'real' one. You're taking no account of semantic differences...

pete

Legacy products ?! Sorry to hear about your upcomming retirement ....

We do new ,....Old dont pay wages , its uncompetitive ...