eLua and RTOS integration

[BogdanM]

> Hmm.. how are you suggesting this be implemented?  Should the module just
> have a setup routine that registers a handler on load, or with some sort of
> init function?  It might be nice to have a C API that abstracts this a
> little to where code changes between platforms are minimized.
>

Exactly, it's all in the API. I only have the big picture in my head at this
point, no details. In other words, I just know it can be done, but I can't
tell you how right now :)


> Ah, I see two parts to this.  Having dynamically loadable libraries is
> useful, but there are also a number of facilities that would make doing
> RT/IS routines easier.  I think suggesting this sort of behavior as a
> solution makes me lean even more towards having semaphores / mutexes to make
> sure that these ISRs aren't being stepped on, or are stepping on stuff going
> on in Lua.  The other thing that would be highly useful would be queues, or
> something like them since you cannot count on the VM picking up data
> products necessarily at a fixed rate.
>

Of course you're right, you'd need some sort of event queues in this
situation. Semaphores and mutexes would be an welcomed addition.
In the particular case of the ADC, I think you could use the buffering
mechanism from src/buf.c, have you looked at that? Very basic, but it might
be enough for you.


> All of these things certainly should be balanced against flash and RAM
> requirements in terms of whether they are worth it.  I think FreeRTOS and
> ChibiOS are pretty small though in both areas, and even if we didn't go full
> RTOS they might have useful examples for how to implement some of the
> features they provide.
>

FreeRTOS is minimal enough as it is, and I _think_ you can even choose not
to compile all its features.


> I think these discussions are interesting.  I've done most of my previous
> microcontroller coding on bare metal with no RTOS.  These discussions, as
> well as working on some implementations are helping me to understand the ins
> and outs of different implementations.
>

I only did RTOSes once or twice (once with the very good uC/OS-II package)
but it was mainly for instructional purposes. I build a few medium
complexity embedded systems, and never felt a real need for an OS. YMMV, of
course :)

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090205/e5d5dd56/attachment.html 

[BogdanM]

> What happens if an ISR fires during this time that makes a block of data
> ready to be processed in Lua? Actually turning it off may make latencies
> worse, since it will take longer to run when you do get around to running
> it.
>

For sure. The idea was to turn the GC off, and keep it off. This is why I
mentioned "if you have enough RAM". You probably couldn't do much with only
64k.


> Ahh, I would never do an ISR in Lua.  Way too slow.
>

It depends actually. If all you need is to have an interrupt firing when you
push an external button, a Lua ISR would be probably more than enough for
your needs. If you need to filter a signal from the ADC ... well ... :)

> Lets not forget that just by adding Lua we in fact *are* increasing the
> complexity of the system, by quite a bit.  The whole purpose (in my mind) of
> adding something like Lua to an embedded system is to make tasks like UI
> creation and such easier, not to replace any of the RT parts.  The easiest
> way to connect the non RT domain of Lua to the RT domain is through an OS.
> Just having C code running that blocks the Lua code while it waits for a new
> piece of data to display is not going to be enough I think.  You still need
> some method of synchronization between the ISR and the C code that presents
> the data to Lua, else what do you do if the ISR gets called twice (or more)
> while the Lua code is waking up?
>

You queue your data, of course. It's a very reliable way of connecting two
pieces of code running at different speeds. If your queue overruns, then
you're pretty much out of luck, because your consumer can't consume the data
that the producer is queuing fast enough. And in this case, I don't think an
OS could help.
Also, I think I created some confusion when I said "The Lua VM can't be
interrupted", so I'd like to clarify that. What I meant was that you can't
interrupt the Lua VM and force it to execute some other code, like you'd do
in a very simple implementation of a Lua ISR: the hardware interrupt handler
calls a Lua function directly. This is a big problem if the Lua VM instance
you're using was already executing some code, and it won't work. But if you
interrupt the Lua VM because of an external event (like an interrupt handler
that doesn't touch the Lua state at all, think "timer interrupt" or "UART
receive interrupt" or anything like this) everything is 100% safe.


> What I would invision for eLua is more along the lines of simple Lua
> interfaces to the system provided synchronization primitives, and maybe some
> sort of event system where you register callbacks in Lua that get run when
> data is available on the C side of things.  This way you would only need one
> Lua thread.  An event driven system like glib and Gtk provide is kinda nice.
>

Once Lua ISRs are implemented, we'll see if we really need this or not. I
really don't know what to think at this point.

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090205/e4c60596/attachment-0001.html 

[jbsnyder]

On Feb 5, 2009, at 12:35 AM, Bogdan Marinescu wrote:

>
> What happens if an ISR fires during this time that makes a block of  
> data ready to be processed in Lua? Actually turning it off may make  
> latencies worse, since it will take longer to run when you do get  
> around to running it.
>
> For sure. The idea was to turn the GC off, and keep it off. This is  
> why I mentioned "if you have enough RAM". You probably couldn't do  
> much with only 64k.
>
> Ahh, I would never do an ISR in Lua.  Way too slow.
>
> It depends actually. If all you need is to have an interrupt firing  
> when you push an external button, a Lua ISR would be probably more  
> than enough for your needs. If you need to filter a signal from the  
> ADC ... well ... :)

I agree here.  That said, if it isn't possible to really interrupt the  
VM, you could accomplish this indirectly with semaphores, and have  
handlers in Lua which execute when it next gets a chance to check them.

> Lets not forget that just by adding Lua we in fact *are* increasing  
> the complexity of the system, by quite a bit.  The whole purpose (in  
> my mind) of adding something like Lua to an embedded system is to  
> make tasks like UI creation and such easier, not to replace any of  
> the RT parts.  The easiest way to connect the non RT domain of Lua  
> to the RT domain is through an OS.  Just having C code running that  
> blocks the Lua code while it waits for a new piece of data to  
> display is not going to be enough I think.  You still need some  
> method of synchronization between the ISR and the C code that  
> presents the data to Lua, else what do you do if the ISR gets called  
> twice (or more) while the Lua code is waking up?
>
> You queue your data, of course. It's a very reliable way of  
> connecting two pieces of code running at different speeds. If your  
> queue overruns, then you're pretty much out of luck, because your  
> consumer can't consume the data that the producer is queuing fast  
> enough. And in this case, I don't think an OS could help.
> Also, I think I created some confusion when I said "The Lua VM can't  
> be interrupted", so I'd like to clarify that. What I meant was that  
> you can't interrupt the Lua VM and force it to execute some other  
> code, like you'd do in a very simple implementation of a Lua ISR:  
> the hardware interrupt handler calls a Lua function directly. This  
> is a big problem if the Lua VM instance you're using was already  
> executing some code, and it won't work. But if you interrupt the Lua  
> VM because of an external event (like an interrupt handler that  
> doesn't touch the Lua state at all, think "timer interrupt" or "UART  
> receive interrupt" or anything like this) everything is 100% safe.

So, is the only way to "interrupt" Lua (without making major changes)  
to use some sort of polling of state (be that register, semaphore, bit  
flag, whatever...) where Lua periodically checks for any pending  
notifications it should pay attention to?

> Of course you're right, you'd need some sort of event queues in this  
> situation. Semaphores and mutexes would be an welcomed addition.
> In the particular case of the ADC, I think you could use the  
> buffering mechanism from src/buf.c, have you looked at that? Very  
> basic, but it might be enough for you.

I have looked at it, and I think, with some adaptations, I could shift  
some responsibilities from custom buffering code in the adc code to  
general buffering.

One way or another I'll have something fairly feature complete coming  
up soon.


--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090205/c24caca6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090205/c24caca6/attachment.pgp 

[BogdanM]

>
> I agree here.  That said, if it isn't possible to really interrupt the VM,
> you could accomplish this indirectly with semaphores, and have handlers in
> Lua which execute when it next gets a chance to check them.
>

How would that be different from a "Lua ISR"? It would use the exact same
mechanism. See below, maybe I wasn't very clear (this seem to happen a lot
lately :) ).

So, is the only way to "interrupt" Lua (without making major changes) to use
> some sort of polling of state (be that register, semaphore, bit flag,
> whatever...) where Lua periodically checks for any pending notifications it
> should pay attention to?
>

Lua already does that via its hooks mechanism:

http://www.lua.org/manual/5.1/manual.html#5.9 (look at "sethook")

So, an "ISR" in eLua would be exactly a "poll" coming from Lua's VM, a
"poll" that checks if hooks are enabled and executes them if they are. A C
ISR would just enable the hook, then the VM would call it. From what I could
gather, this is the safest way to "interrupt" Lua, because you don't
actually interrupt it at all, the VM's main loop already checks for hooks
and knows how to handle them properly.


> I have looked at it, and I think, with some adaptations, I could shift some
> responsibilities from custom buffering code in the adc code to general
> buffering.
>
> One way or another I'll have something fairly feature complete coming up
> soon.
>

Can't wait! :)

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090206/9c253f5a/attachment.html