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
You are going to apps get so simple and RTOS with one task is silly. To so many tasks you should have used and RTOS.
In the middle Your state machine becomes straight code easy to write and easy to read. And easy to add more tasks to.
For many apps it is a preference like ASM vs C. The one you are most familiar with is quicker.
Personally I have never need a RTOS with an 8 bit CPU, but that is just me.
I just re-read my last post.
RTX ran on the MIR in less than 600 bytes total program.
That's plainly false. Not intentional, just dumb on my part. I meant to say the RTOS and communications ran in less than 600 bytes. The actual display code in several threads was a bit larger. Sorry about my mistake. Bradford