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

"is there any way to declare a function that doesn't automatically save registers (acc, b, dptr, r0-r7...)"

What makes you think that C51 does save these - or any other - registers??

http://www.keil.com/support/man/docs/c51/c51_ap_regusage.htm

Because it really does in some case.
One example: open CSAMPLE project in Examples folder, build it, start debug session, open disassembly window, go to line: C:0x02DF you will see:

PUSH   ACC (0xE0)
LCALL  C:003E
....
POP    ACC (0xE0)

The code you reference is in the middle of the printf library routine. It is not in C code that the compiler has compiled.

Jon

Oh, sorry for wrong reference. But I have another example for my evidence:

Open the project Infineon C517 in Examples folder. The popval() function in the example is called 2 times and actually push R4-R7 after the first call to save the return values and pop them to R0-R3 after the second call. (now R0-R3: result for the first call and R4-R7: result for the second call).

I know that this is the push and pop example but it proves that in some cases, before calling a fucntion, sometimes it save some registers. Thanks,

Originally, you asked, "is there any way to declare a function that doesn't automatically save registers (acc, b, dptr, r0-r7...) when called?"

The answer to that is that C51 functions do not save registers.

Because C51 functions do not save registers, anything that calls a C51 function must assume that all registers will be destroyed by the called function:

http://www.keil.com/support/man/docs/c51/c51_ap_regusage.htm

Therefore, anything that calls a C51 function must save any registers that it needs!

Perhaps if you Just explained what you are actually trying to achieve, people might be able to offer informed suggestions?

Oh, thanks for the quick answer. What I am trying to do is to port the FreeRTOS to 8051 MCU with Keil compiler. On the website of FreeROS.org, they have an example with 8051 but using the SDCC compiler. In SDCC, they can use the "_naked" attribute for the TaskSwitch function which saves the context of the MCU. Because calling TaskSwitch function can destroy the register, they need to use _naked attribute to avoid this problem. So, I think I have to do it all manually by ASM. That's a painful work!!!!!!!!

"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