Hi people,

sorry for the late post, I was on a longer trip. So anyway to get it right. The API is for a mixed signal radio transreciever ASIC chip.

The digital part of the chip is based on the 8051 core and
it has plenty of features implemented inside. So the idea behind an API is to create a library that supports:
1. the whole radio configuration
2. the protocol stack
3. routing, encryption
etc.

The API will contain macros like Russ mentioned in his post, but also functions to save codespace.
I think it is quite usefull for the application developer. Because for example to send a message several stuff must be done: configure synthetisrer, choose frequency, set datarate, switch on A/D convertor, configure sleep mode, fill sendbuffer, etc...

The API should also offer some protection so the APP developer with a way that it will not set a HW configuration that is not "allowed" (i.e. clear the sending buffer while the data is transmitted or use the timer that is intended to be used during transmission). So the API actualy SHOULD reduce the errors which the APP developer can make.

Another advantage of using an library for an ASIC is the HW indipendence. The API should have an hardware abstraction layer with drivers and a SW layer. In case there will be another ASIC chip with a little bit modified HW structure, it is enough to change the drivers and let the other code intact.

This is what I actualy mean under abstraction. Not generating a code from a flow charts or simmilar stuff.

Of course the APP developer must still know how the HW works, and he is not forced to use the API, he can access the HW directly.

I have just read the book Embedded System Architecture from Tammy Noergaard and in the chapter SW design there are similar ideas as in Russ and Russel's posts.

greetings
Attila