I just realized that when wait I/O is all over the place using a RTOS is a feasible workaround. Even the 'C' library is wait I/O ARGH. Is it the average coders inability to make no_wait_I/O that is the reason that so many state "I need a RTOS" ?
Erik
Cross-posted at 8052.com
I wouldn't call it a workaround but yes, partitioning your code around I/O tasks is a reasonably efficient way to organize your code. If all your I/O is non-blocking you'll have write big chunks of RTOS-like functionality to manage properly sequenced completion of all that pending I/O. Doing it once for one project you may be able to do better but from project 2..n you might be better off with a RTOS.
Of course there are reasons other than I/O to use or not to use an RTOS as well.
Andrew
If all your I/O is non-blocking you'll have write big chunks of RTOS-like functionality to manage properly sequenced completion of all that pending I/O.
an example of a "big chunk"
state 47: if I/O ready start I/O, set state 48 else exit
state 48: if I/O done set state 49 else exit
large chunk my ass
Shades of RTOS. A Co-operative, non-pre-emptive, round robin RTOS as defined by Erik.
Unless you have very few states, I believe that RTX-Tiny would use less code and run faster than your home built state machines.
RTX ran on the MIR in less than 600 bytes total program. The program controlled dynamic displays as a slave under control of a fantastic x386. Both display and communications ran under RTX if I remember correctly.
I did not write the code but someone that you know personally Erik wrote the code.
Oh! The MIR did fall eventually. May be a bad example, you think?
Bradford
View all questions in Keil forum