Declare function that doesn't automatically save register when called.

"I am trying to ... port the FreeRTOS ... I have to do it all manually by ASM. That's a painful work!!!!!!!!"

Yes; there is no such thing as a Free Lunch - you are either going to have to do the hard work yourself, or you could pay Keil for their ready-made RTOS which is specifically designed, documented, and supported to work with their tools!

Before committing yourself to this task, are you sure that an RTOS (any RTOS) is really necessary?
In most cases of most projects suited to an 8051, an RTOS is overkill.

"I am trying to ... port the FreeRTOS ... I have to do it all manually by ASM. That's a painful work!!!!!!!!"

Yes; there is no such thing as a Free Lunch - you are either going to have to do the hard work yourself, or you could pay Keil for their ready-made RTOS which is specifically designed, documented, and supported to work with their tools!

Before committing yourself to this task, are you sure that an RTOS (any RTOS) is really necessary?
In most cases of most projects suited to an 8051, an RTOS is overkill.

Thanks for your advice.

My project is not only on 8051 MCU but also on other architecture such as ARM, 68HC, AVR... So I need the RTOS that can port to alot MCU architect. I know that Keil has a very good RTOS but it only supports 8051 and ARM, and I have to pay 2 times for 2 architectures. One more disadvantage, as I know, Keil doesn't provide source code of their RTOS.

Maybe you can give me a suggestion about some other RTOS.

Thanks,

"My project is not only on 8051 MCU but also on other architecture such as ARM, 68HC, AVR... So I need the RTOS that can port to alot MCU architect"

I think you missed the point there!

I said, "In most cases of most projects suited to an 8051, an RTOS is overkill"

That can generally be re-stated as, "In most cases of most projects suited to a small 8-bit microntroller, an RTOS is overkill"

I think 68HC, AVR, and 8051 all count as "small 8-bit microntrollers".

Therefore the question is, do the parts of your project that run on the 68HC, AVR, and/or 8051 really need any RTOS at all?

Yes, it's quite likely that the ARM-based part(s) could warrant an RTOS; but a lot less likely for the 8-bitters.

Maybe you can give me a suggestion about some other RTOS.

PK51 comes with RTX51 Tiny. This is tuned for the Keil C51 Compiler and small enough for an 8051.

"RTX51 Tiny ... is ... small enough for an 8051."

Maybe - but its size is still non-zero; in most cases, zero is quite big enough for an 8051 RTOS! ;-)

My project is not only on 8051 MCU but also on other architecture such as ARM, 68HC, AVR...

That sounds like total utter confusion.

I may be able to see a project running on two of the above, but A project running on 4 ... sounds crazy.

Is the truth that some routines of "My project is not only on 8051 MCU" ? In that case, just isolate them and forget about using a RTOS (at least for the '51)

Erik

Yes Erik,
My project is a software architecture for a product line and independent with the hardware. Of course, with different MCU, I have to build a device drivers to control their peripherals... So I don't want any part of my "software architecture" accesses directly to the device drivers because it can make the "architecture" losts it generality. I intend to use the "message transfer" and "semaphore" in the RTOS to solve this problem.

Maybe I need to review my approach to find another solution.

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