Hi there, Does anyone know if it's possible to rum multiple threads on 8051 mocrocontroller? Thank you.
Certainly. It's just software. The 8051 architecture doesn't really lend itself well to preemption, though. It's doable, just as with any processor, but it costs more than you might expect given experience with other processors. The compile-time call tree analysis Keil C does becomes far less useful when you can preempt a task at any point in its execution, and thus have to have separate call trees for every task. This tends to increase the amount of space needed for the space, which means you can't fit it into the internal data memory, which means you have to switch to external data for all your temporaries and automatics, which makes all the code bigger and slower. It's not the overhead of a preemptive kernel itself that's a problem, but rather than increase in all the rest of the code. Most of these limitations come from the awkwardness of the DPTR and the instruction set, so it's not a matter of finding better tools.
The 8051 architecture doesn't really lend itself well to preemption, though. No, it's just a awful for that as it is great for what it is intended for Most of these limitations come from the awkwardness of the DPTR and the instruction set, so it's not a matter of finding better tools. limitations imposed in order to make the stuff it is intended for even better. Why are you trying to fit a square peg in a round hole? If you need multitasking (which I doubt) use a processor intended for that such as a pentium. Erik
Why are you trying to fit a square peg in a round hole? If you need multitasking (which I doubt) use a processor intended for that such as a pentium. Perhaps there are cost and time constraints on the project requirements...which is often the case. Assuming this, one doesn't simply opt for a Pentium over a '51 or similar. Now, while I'm not a big proponent of preemptive multi-threading in the '51, cooperative multi-threading isn't unreasonable and can be implement fairly efficiently, if done properly.
cooperative multi-threading is that not just the workloop? Erik
cooperative multi-threading Yes, it's the preemption that's the problem, and that largely because of the secondary effects of the way the stack is (and should be) handled for efficiency's sake. See, for example, the Salvo RTOS from Pumpkin. http://www.pumpkininc.com/ Take a close look at the restrictions those OS-looking macros, and you'll see that they're really just calling void (void) functions from the top level -- the workloop, as Erik puts it, but without having to hand-code it all. This allows the compiler to build a call tree and overlay memory usage as usual. If you want something preemptive, there's CMX RTX, Keil's RTX, uCOS-II, and others.
cooperative multi-threading aka the workloop Next, the saucer will be called an "cup spill damage preventer" Erik
cooperative multi-threading is that not just the workloop? No, its not just an executive loop. Its an OS that provides functions for relinquishing control back to a task management subsystem, where each "thread"s complete context is saved upon doing so. The functions are effectively $REGUSE fn () ... thus allowing the compiler full optimization across the call. Its cooperative in that there is no background preemtion mechanism that switches threads, rather each thread must relinquish control back to the OS on its own accord. It avoids all the resource consumption involved with true preemption, but still allows you to write linear threads.