My current project seems just complicated enough that I've been looking at a few simple RTOSes. Since the 8051 architecture is a bit peculiar, I was curious if anyone had any experience they'd like to share. In particular, I'm interested in how the RTOS interacts with Keil features to cope with 8051 limitations. Each task will have to be a new root for overlay analysis, and it's more likely that routines will have to be declared reentrant. And in that case, the RTOS has to deal with the compiler-specific simulated stacks, as well as the 8051 SP. So, I'm interested in how much havoc using an RTOS wreaks on the code size and space, as well as how smoothly the RTOS integrates with Keil conventions. I've looked at four options so far. I presume Keil's RTX51 works well with their own compiler :) The third-party libraries are a bit more of a concern. CMX has a number of recommendations on the board for their TCP/IP stack, but I didn't see any discussion of the RTOS kernel (RTX) itself. Their documentation is less than encouraging, but the answers to my pre-sales questions seemed to indicate they did understand the problems. u/COS has some advantages, but generic, and seems a bit more "traditional" in its expectations from the processor. (Not to mention some unfortunate choices for variable names like "pdata", making it a bit more of a chore to port.) Salvo looks like a good option for simple systems, especially ones that you might not consider for an RTOS, but the fact that many of the functions can only be called from the top level of a task (instead of inside a function) seemed to me like it would be a problem in more complex systems. Anyone have some thoughts they'd like to share?
<quote> The code automatically gets bigger -- not because of the RTOS itself Well, I think it does, </quote> Yes. I should have said "not JUST because of the RTOS", which of course is library code like any other library. I meant to point out that preemption, itself, is fairly expensive on the 8051 due to the overlay analysis for parameters and locals. With a cooperative scheduler, you've got some relatively well-defined points where switches can occur, which means you can successfuly overlay more of your call tree. You won't be "in the middle" of most functions when the switch occurs. With true preemption, the call trees of each task must remain distinct, as you could interrupt them at any point. Preemption deprives the compiler of the knowledge of which functions are called "at the same time", so it has to make pessimistic assumptions. That costs you lots of memory space, and code space where extra reentrant declarations become required, over and above the relatively small costs just for the RTOS (context switch code, task control blocks, etc.) I guess my original question was really directed toward people that had used an RTOS with the Keil tools, to get an idea of just how painful this effect is.