Hi all, In Keil C51 compiler, is there any way to declare a function that doesn't automatically save registers (acc, b, dptr, r0-r7...) when called? I want to do it manually. In SDCC, I can use the attribute "_naked" or use #pragma callee_saves". Thanks,
I have to build a device drivers
I hope that what you are making is in no way critical timing wise. "device drivers" are considered an advantage in "large embedded", in "small embedded (such as the '51) they are considered a major drag.
I think you are applying "large embedded" thinking to "small embedded.
erik
A "driver" can be nothing more than a collection of routines that manipulate the registers for a device. It doesn't necessarily imply a task, a message queue or sometimes even an interrupt handler. There's not necessarily a lot of overhead involved.
Modularity is a good idea even in small systems. There's no particular reason to embed direct register writes all over your code, particularly if you know in advance that you will have to support several alternative devices for the same function.
"A 'driver' can be nothing more than a collection of routines that manipulate the registers for a device. It doesn't necessarily imply a task, a message queue..."
Quite so. However, the OP has previously said, "I intend to use the 'message transfer' and 'semaphore' in the RTOS..." - which does tend to suggest that he is, in fact, thinking in "Big System" terms rather than 8051-scale terms...
A "driver" can be ....
"Driver" is, I agree, a very ambigous name. When I hear "driver" I 'see' a "driver" that is 'device independent as in "assign output to driver 3".
Some would name "set a byte in x and it will be output on the serial port", a driver, I would not.
However, from the original post I surmise that the OP is talking about a driver similar to the first one (RTOS approach).
Modularity is a good idea even in small systems. There's no particular reason to embed direct register writes all over your code Now, while I wholehardedly agree with you on this point, locating all related to a given I/O in a single, separate module would not make me call it a driver.
Erik