user11569: I've been playing around with Arduino and understand that the standard runtime provides a single thread essentially.
I was wondering if it is possible to write a thin layer (library) that allows one to write code that is non blocking and one where each task yields control manually which allows the master loop to implement some form of timesharing.
I'd appreciate any:

Comments on existing frameworks that can allow me to write my programs this way
Any comments on how hard implementing anything of this order of magnitude would be.


user7856: I would recommend NilRTOS.
I like the fact that it's really minimal.
However, you might find that some libraries (which you would like to use) work in blocking mode and cannot be used with this RTOS, because they might do bad things (polling) or worse things (polling in interrupt context with other interrupts disabled).
But that will be the case regardless of the thread framework you choose.
You might want to try also femtoos.
I think that the code could be organized far better, which is one of the reasons I preferred NilRTOS.

user10794: My recommendation would be to simply code without needing blocking. I have examples here.
Petri Häkkinen coded a game - Toorum's Quest - without using any real-time library. That game (on a Uno) has multiple sprites, TV output and sound effects, all interleaved.
The basic technique is to know that you have multiple things you need to have done, from time to time, and check in the main loop if it is time to do one of them.
One issue with any sort of real-time library is, you only have limited resources. You need to be really aware, for example, of which bits of hardware are doing what (eg. timers, SPI, I2C, interrupt handlers, serial comms).
Even existing libraries suffer from the problem that one library may require (say) pin-change interrupts, and "requisition" the interrupt handlers needed for that, and another library also uses pin-change interrupts, and they cannot be linked together.

11569: <p>I've been playing around with Arduino and understand that the standard runtime provides a single thread essentially.</p>

<p>I was wondering if it is possible to write a thin layer (library) that allows one to write code that is non blocking and one where each task yields control manually which allows the master loop to implement some form of timesharing.</p>

<p>I'd appreciate any:</p>

<ol>
<li>Comments on existing frameworks that can allow me to write my programs this way</li>
<li>Any comments on how hard implementing anything of this order of magnitude would be.</li>
</ol>
 7856: <p>I would recommend <a href="https://github.com/greiman/NilRTOS-Arduino" rel="nofollow">NilRTOS</a>.
I like the fact that it's really minimal.
However, you might find that some libraries (which you would like to use) work in blocking mode and cannot be used with this RTOS, because they might do bad things (polling) or worse things (polling in interrupt context with other interrupts disabled).
But that will be the case regardless of the thread framework you choose.</p>

<p>You might want to try also <a href="http://www.femtoos.org/" rel="nofollow">femtoos</a>.
I think that the code could be organized far better, which is one of the reasons I preferred NilRTOS.</p>
 10794: <p>My recommendation would be to simply code without needing blocking. I have examples <a href="http://www.gammon.com.au/blink" rel="nofollow">here</a>.</p>

<p>Petri Häkkinen coded a game - <a href="https://www.youtube.com/watch?v=sLvgW_zb6bQ" rel="nofollow">Toorum's Quest</a> - without using any real-time library. That game (on a Uno) has multiple sprites, TV output and sound effects, all interleaved.</p>

<p>The basic technique is to know that you have multiple things you need to have done, from time to time, and check in the main loop if it is time to do one of them.</p>

<p>One issue with any sort of real-time library is, you only have limited resources. You need to be really aware, for example, of which bits of hardware are doing what (eg. timers, SPI, I2C, interrupt handlers, serial comms).</p>

<p>Even existing libraries suffer from the problem that one library may require (say) pin-change interrupts, and "requisition" the interrupt handlers needed for that, and another library also uses pin-change interrupts, and they cannot be linked together.</p>
