eLua and RTOS integration

[Alex Babkin]

Hi all

This may be a silly and not thought out question, but i'll throw it out
there anyway: Has anyone tried to integrate the eLua codebase with something
like FreeRTOS? I.e have eLua running as a low priority process while having
some other higher-priority time critical processes doing their time-critical
stuff and chugging along-side with eLua.
I'd imagine there is a lot of merit for doing this kind of thing for many
projects.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/75b3f35a/attachment.html 

[Dado Sutter]

Hello Guys,,
  On the Lua Programming
Gems<http://www.amazon.com/Programming-Gems-Luiz-Henrique-Figueiredo/dp/8590379841/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1233684596&sr=8-1>,
there are at least two articles discussing nice multithreading models for
Lua.
  It will be nice to read about them here too.

Best
Dado



On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:

> Hi all
>
> This may be a silly and not thought out question, but i'll throw it out
> there anyway: Has anyone tried to integrate the eLua codebase with something
> like FreeRTOS? I.e have eLua running as a low priority process while having
> some other higher-priority time critical processes doing their time-critical
> stuff and chugging along-side with eLua.
> I'd imagine there is a lot of merit for doing this kind of thing for many
> projects.
>
> Alex
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/ebadb50e/attachment.html 

[BogdanM]

Integrating eLua with a RTOS is not on my list of "TODO for eLua", so I'm
waiting for the oppions of other people :)

Best,
Bogdan

On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com> wrote:

> Hello Guys,,
>   On the Lua Programming Gems<http://www.amazon.com/Programming-Gems-Luiz-Henrique-Figueiredo/dp/8590379841/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1233684596&sr=8-1>,
> there are at least two articles discussing nice multithreading models for
> Lua.
>   It will be nice to read about them here too.
>
> Best
> Dado
>
>
>
> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>
>> Hi all
>>
>> This may be a silly and not thought out question, but i'll throw it out
>> there anyway: Has anyone tried to integrate the eLua codebase with something
>> like FreeRTOS? I.e have eLua running as a low priority process while having
>> some other higher-priority time critical processes doing their time-critical
>> stuff and chugging along-side with eLua.
>> I'd imagine there is a lot of merit for doing this kind of thing for many
>> projects.
>>
>> Alex
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/16046311/attachment.html 

[Dean Hall]

I've used both PyMite (a small Python interpreter) and AvrX RTOS on an  
AVR; which might be comparable to running eLua with an RTOS. My belief  
is that the two software systems solve two very different problems.  
If you *need* an RTOS, you probably shouldn't be running an  
interpreted language.  Conversely, if you are programming in a high  
level language, you probably don't care as much about what's going on  
at the silicon level as long as it does what you want it to.  Sure  
there are exceptions, but I'm talking generalities here.

I believe it would be easier to use eLua as the application and write  
any time-critical code in C in an interrupt service routine than it  
would be to try to integrate with an RTOS.  In embedded systems  
(especially real-time systems) simplicity is everything.

!!Dean

On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:

> Integrating eLua with a RTOS is not on my list of "TODO for eLua",  
> so I'm waiting for the oppions of other people :)
>
> Best,
> Bogdan
>
> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>  
> wrote:
> Hello Guys,,
>   On the Lua Programming Gems, there are at least two articles  
> discussing nice multithreading models for Lua.
>   It will be nice to read about them here too.
>
> Best
> Dado
>
>
>
> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
> Hi all
>
> This may be a silly and not thought out question, but i'll throw it  
> out there anyway: Has anyone tried to integrate the eLua codebase  
> with something like FreeRTOS? I.e have eLua running as a low  
> priority process while having some other higher-priority time  
> critical processes doing their time-critical stuff and chugging  
> along-side with eLua.
> I'd imagine there is a lot of merit for doing this kind of thing for  
> many projects.
>
> Alex
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> If you *need* an RTOS, you probably shouldn't be running an
> interpreted language.  Conversely, if you are programming in a high
> level language, you probably don't care as much about what's going on
> at the silicon level as long as it does what you want it to.  Sure
> there are exceptions, but I'm talking generalities here.


That pretty much sums up my take on this subject and explains why I didn't
consider an RTOS for eLua.

Best,
Bogdan

> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>
> > Integrating eLua with a RTOS is not on my list of "TODO for eLua",
> > so I'm waiting for the oppions of other people :)
> >
> > Best,
> > Bogdan
> >
> > On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
> > wrote:
> > Hello Guys,,
> >   On the Lua Programming Gems, there are at least two articles
> > discussing nice multithreading models for Lua.
> >   It will be nice to read about them here too.
> >
> > Best
> > Dado
> >
> >
> >
> > On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
> > Hi all
> >
> > This may be a silly and not thought out question, but i'll throw it
> > out there anyway: Has anyone tried to integrate the eLua codebase
> > with something like FreeRTOS? I.e have eLua running as a low
> > priority process while having some other higher-priority time
> > critical processes doing their time-critical stuff and chugging
> > along-side with eLua.
> > I'd imagine there is a lot of merit for doing this kind of thing for
> > many projects.
> >
> > Alex
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> >
> >
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> >
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/0d5372d2/attachment.html 

[jbsnyder]

I would generally agree with this as well.  Generally, I think the  
only main advantage one might get from something like this is not the  
RT portion of RTOS, but just to have preemptive or cooperative  
multitasking that is outside of eLua.

That said, between coroutines and interrupts, one could probably get  
functionality that covers many of these advantages without wrapping  
everything in an RTOS.

Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs  
could be done?  With Cortex-M3's NVIC it should be pretty easy to  
reconfigure interrupts to call Lua functions, but things could get  
fairly complicated for other platforms where I think you'd have to  
have the default handler check through all the interrupt flags to  
figure out which interrupt fired, or an ISR for each and every  
interrupt whose action could be adjusted through Lua?

-jsnyder

On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:

> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
> AVR; which might be comparable to running eLua with an RTOS. My belief
> is that the two software systems solve two very different problems.
> If you *need* an RTOS, you probably shouldn't be running an
> interpreted language.  Conversely, if you are programming in a high
> level language, you probably don't care as much about what's going on
> at the silicon level as long as it does what you want it to.  Sure
> there are exceptions, but I'm talking generalities here.
>
> I believe it would be easier to use eLua as the application and write
> any time-critical code in C in an interrupt service routine than it
> would be to try to integrate with an RTOS.  In embedded systems
> (especially real-time systems) simplicity is everything.
>
> !!Dean
>
> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>
>> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>> so I'm waiting for the oppions of other people :)
>>
>> Best,
>> Bogdan
>>
>> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>> wrote:
>> Hello Guys,,
>>  On the Lua Programming Gems, there are at least two articles
>> discussing nice multithreading models for Lua.
>>  It will be nice to read about them here too.
>>
>> Best
>> Dado
>>
>>
>>
>> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>> Hi all
>>
>> This may be a silly and not thought out question, but i'll throw it
>> out there anyway: Has anyone tried to integrate the eLua codebase
>> with something like FreeRTOS? I.e have eLua running as a low
>> priority process while having some other higher-priority time
>> critical processes doing their time-critical stuff and chugging
>> along-side with eLua.
>> I'd imagine there is a lot of merit for doing this kind of thing for
>> many projects.
>>
>> Alex
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
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/20090203/f45feb85/attachment-0001.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/20090203/f45feb85/attachment-0001.pgp 

[BogdanM]

> That said, between coroutines and interrupts, one could probably get
> functionality that covers many of these advantages without wrapping
> everything in an RTOS.
>
> Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs
> could be done?  With Cortex-M3's NVIC it should be pretty easy to
> reconfigure interrupts to call Lua functions,
>

Not really. It's not about the hardware, Lua's VM isn't really meant to be
interrupted. Fortunately there is an easy way to do this: you'd just use
Lua's hook support (similar to debug.sethook), maybe slightly modified to
take interrupts into account (although I'm not sure yet that modifications
are really required). lua.c already does something like this to handle
signals (for CTRL+C). There might be better ways to do this, but I can't
think of any.

Best,
Bogdan

-jsnyder
>

> On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:
>
> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
> AVR; which might be comparable to running eLua with an RTOS. My belief
> is that the two software systems solve two very different problems.
> If you *need* an RTOS, you probably shouldn't be running an
> interpreted language.  Conversely, if you are programming in a high
> level language, you probably don't care as much about what's going on
> at the silicon level as long as it does what you want it to.  Sure
> there are exceptions, but I'm talking generalities here.
>
> I believe it would be easier to use eLua as the application and write
> any time-critical code in C in an interrupt service routine than it
> would be to try to integrate with an RTOS.  In embedded systems
> (especially real-time systems) simplicity is everything.
>
> !!Dean
>
> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>
> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>
> so I'm waiting for the oppions of other people :)
>
>
> Best,
>
> Bogdan
>
>
> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>
> wrote:
>
> Hello Guys,,
>
>  On the Lua Programming Gems, there are at least two articles
>
> discussing nice multithreading models for Lua.
>
>  It will be nice to read about them here too.
>
>
> Best
>
> Dado
>
>
>
>
> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>
> Hi all
>
>
> This may be a silly and not thought out question, but i'll throw it
>
> out there anyway: Has anyone tried to integrate the eLua codebase
>
> with something like FreeRTOS? I.e have eLua running as a low
>
> priority process while having some other higher-priority time
>
> critical processes doing their time-critical stuff and chugging
>
> along-side with eLua.
>
> I'd imagine there is a lot of merit for doing this kind of thing for
>
> many projects.
>
>
> Alex
>
>
> _______________________________________________
>
> Elua-dev mailing list
>
> Elua-dev at lists.berlios.de
>
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
>
>
> _______________________________________________
>
> Elua-dev mailing list
>
> Elua-dev at lists.berlios.de
>
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
>
> _______________________________________________
>
> Elua-dev mailing list
>
> Elua-dev at lists.berlios.de
>
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: [phone]
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/6074a54c/attachment.html 

[Mike Panetta]

This biggest issue would be is lua capable of doing the work required in a
typical ISR fast enough?  If I was writing an ISR for a space vector
modulation scheme, the ISR would be running at the same rate as the PWM
frequency (or 2x that in case of symetric SVM).  That can be pretty fast
(tens of KHz, 50us between interrupts at 20KHz) and a scripted ISR surly
could not be called at such a rate.

The advantage to integrating with an RTOS would be that you could have a lua
thread (coroutine, whatever) sleep on a queue or semaphore and the ISR
(written in C) could wake it when its done doing whatever it has to do in a
time critical maner.

Thats my 2c anyway.

Mike

On Tue, Feb 3, 2009 at 3:05 PM, Bogdan Marinescu <bogdan.marinescu at gmail.com
> wrote:

>
> That said, between coroutines and interrupts, one could probably get
>> functionality that covers many of these advantages without wrapping
>> everything in an RTOS.
>>
>> Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs
>> could be done?  With Cortex-M3's NVIC it should be pretty easy to
>> reconfigure interrupts to call Lua functions,
>>
>
> Not really. It's not about the hardware, Lua's VM isn't really meant to be
> interrupted. Fortunately there is an easy way to do this: you'd just use
> Lua's hook support (similar to debug.sethook), maybe slightly modified to
> take interrupts into account (although I'm not sure yet that modifications
> are really required). lua.c already does something like this to handle
> signals (for CTRL+C). There might be better ways to do this, but I can't
> think of any.
>
> Best,
> Bogdan
>
> -jsnyder
>>
>
>> On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:
>>
>> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
>> AVR; which might be comparable to running eLua with an RTOS. My belief
>> is that the two software systems solve two very different problems.
>> If you *need* an RTOS, you probably shouldn't be running an
>> interpreted language.  Conversely, if you are programming in a high
>> level language, you probably don't care as much about what's going on
>> at the silicon level as long as it does what you want it to.  Sure
>> there are exceptions, but I'm talking generalities here.
>>
>> I believe it would be easier to use eLua as the application and write
>> any time-critical code in C in an interrupt service routine than it
>> would be to try to integrate with an RTOS.  In embedded systems
>> (especially real-time systems) simplicity is everything.
>>
>> !!Dean
>>
>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>
>> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>
>> so I'm waiting for the oppions of other people :)
>>
>>
>> Best,
>>
>> Bogdan
>>
>>
>> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>
>> wrote:
>>
>> Hello Guys,,
>>
>>  On the Lua Programming Gems, there are at least two articles
>>
>> discussing nice multithreading models for Lua.
>>
>>  It will be nice to read about them here too.
>>
>>
>> Best
>>
>> Dado
>>
>>
>>
>>
>> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>
>> Hi all
>>
>>
>> This may be a silly and not thought out question, but i'll throw it
>>
>> out there anyway: Has anyone tried to integrate the eLua codebase
>>
>> with something like FreeRTOS? I.e have eLua running as a low
>>
>> priority process while having some other higher-priority time
>>
>> critical processes doing their time-critical stuff and chugging
>>
>> along-side with eLua.
>>
>> I'd imagine there is a lot of merit for doing this kind of thing for
>>
>> many projects.
>>
>>
>> Alex
>>
>>
>> _______________________________________________
>>
>> Elua-dev mailing list
>>
>> Elua-dev at lists.berlios.de
>>
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>>
>>
>> _______________________________________________
>>
>> Elua-dev mailing list
>>
>> Elua-dev at lists.berlios.de
>>
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>>
>> _______________________________________________
>>
>> Elua-dev mailing list
>>
>> Elua-dev at lists.berlios.de
>>
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>>   --
>> James Snyder
>> Biomedical Engineering
>> Northwestern University
>> jbsnyder at fanplastic.org
>> http://fanplastic.org/key.txt
>> ph: [phone]
>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/bdc22115/attachment-0001.html 

[Mike Panetta]

You should take a look at NuttOS.  Its a Posix compliant RTOS (well maybe
uKernel would be better a name?) thats quite light weight.  Porting lua to
it should (in theory) be as simple as a recompile...  In NuttOS the API is
fully Posix compliant, so its threads based.

I have not tried porting it to the STM32 yet, but its something that has
been seriously on my mind as of late.

Another idea would be to take something thinner like ChibiOS and apply a
Posix 'skin' to it to gain the standard threads based API.

Anyway, thats my take on things...  Basically its probably simpler to port
to an RTOS then you might think...  Esp since we would gain things we would
need for ISR->lua synchronization anyway such as queues, semaphors, mutexes,
etc...

Mike

On Tue, Feb 3, 2009 at 1:49 PM, Bogdan Marinescu <bogdan.marinescu at gmail.com
> wrote:

>
> If you *need* an RTOS, you probably shouldn't be running an
>> interpreted language.  Conversely, if you are programming in a high
>> level language, you probably don't care as much about what's going on
>> at the silicon level as long as it does what you want it to.  Sure
>> there are exceptions, but I'm talking generalities here.
>
>
> That pretty much sums up my take on this subject and explains why I didn't
> consider an RTOS for eLua.
>
> Best,
> Bogdan
>
>
>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>
>> > Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>> > so I'm waiting for the oppions of other people :)
>> >
>> > Best,
>> > Bogdan
>> >
>> > On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>> > wrote:
>> > Hello Guys,,
>> >   On the Lua Programming Gems, there are at least two articles
>> > discussing nice multithreading models for Lua.
>> >   It will be nice to read about them here too.
>> >
>> > Best
>> > Dado
>> >
>> >
>> >
>> > On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>> > Hi all
>> >
>> > This may be a silly and not thought out question, but i'll throw it
>> > out there anyway: Has anyone tried to integrate the eLua codebase
>> > with something like FreeRTOS? I.e have eLua running as a low
>> > priority process while having some other higher-priority time
>> > critical processes doing their time-critical stuff and chugging
>> > along-side with eLua.
>> > I'd imagine there is a lot of merit for doing this kind of thing for
>> > many projects.
>> >
>> > Alex
>> >
>> > _______________________________________________
>> > Elua-dev mailing list
>> > Elua-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > Elua-dev mailing list
>> > Elua-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >
>> >
>> > _______________________________________________
>> > Elua-dev mailing list
>> > Elua-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/2ae7161a/attachment.html 

[Mike Panetta]

On Tue, Feb 3, 2009 at 1:41 PM, Dean Hall <dwhall256 at gmail.com> wrote:

> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
> AVR; which might be comparable to running eLua with an RTOS. My belief
> is that the two software systems solve two very different problems.
> If you *need* an RTOS, you probably shouldn't be running an
> interpreted language.  Conversely, if you are programming in a high
> level language, you probably don't care as much about what's going on
> at the silicon level as long as it does what you want it to.  Sure
> there are exceptions, but I'm talking generalities here.


Yeah that's a pretty big generality, and here is where it would break
down...  I have a system that is used to control a 3 phase induction motor
(lets say its a VFD).  The system is composed of several parts, such as the
PID control loops and SVPWM output routines, and some sort of UI, lets say a
serial or CAN port, and an LCD+Keypad interface for setup.  Lets say we also
want to be able to let the user script the motion control profiles on a PC
and upload them to the device.

The SVPWM and PID routines more then likely (and definitely in the case of
the SVPWM, as any jitter would cause unwanted harmonics in the drive
waveform) would be run as real time tasks in your RTOS (or just straight
ISR's as they are not very complex), but the UI routines and definitely the
scripting part are not RT critical (well not hard RT anyway) and could be
run as a lua script for easy coding and customization. LCD menuing systems
in specific are a great fit for a lua script.  The advantage of using an
RTOS here is we would still need some sort of synchronization mechanism to
get data between the UI (lua) and the RT tasks, and an RTOS would provide
these for us in the form of queues, mutexes and semaphores etc so you don't
have to reinvent the wheel and write your own (at which point you might as
well have already written an RTOS).

This is not a rare occasion in the embedded world, there are quite a few
embedded systems that have RT background processes and semiRT foreground
ones that are used to drive a UI or whatever.


>
> I believe it would be easier to use eLua as the application and write
> any time-critical code in C in an interrupt service routine than it
> would be to try to integrate with an RTOS.  In embedded systems
> (especially real-time systems) simplicity is everything.


Easier maybe (that's debatable) but probably not a good idea, and definitely
not a complete solution.  There would still be the issue of how to get data
between the ISR's and lua in a time critical manner (and calling the lua
interpreter from an ISR is definitely NOT the way to do that).

With the availability of at least 2 RTOS's that support POSIX interfaces
(NuttX and RTEMS) and one that is probably simple enough that we could graft
a small one on to it (ChibiOS), porting lua to an RTOS might be quite a bit
easier then you think.  Also, all the above mentioned RTOS's are open
source, 2 with a modified GPL (well RTEMS was modified GPL last I looked)
and one with a BSD license.

Mike

>
> !!Dean
>
> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>
> > Integrating eLua with a RTOS is not on my list of "TODO for eLua",
> > so I'm waiting for the oppions of other people :)
> >
> > Best,
> > Bogdan
> >
> > On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
> > wrote:
> > Hello Guys,,
> >   On the Lua Programming Gems, there are at least two articles
> > discussing nice multithreading models for Lua.
> >   It will be nice to read about them here too.
> >
> > Best
> > Dado
> >
> >
> >
> > On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
> > Hi all
> >
> > This may be a silly and not thought out question, but i'll throw it
> > out there anyway: Has anyone tried to integrate the eLua codebase
> > with something like FreeRTOS? I.e have eLua running as a low
> > priority process while having some other higher-priority time
> > critical processes doing their time-critical stuff and chugging
> > along-side with eLua.
> > I'd imagine there is a lot of merit for doing this kind of thing for
> > many projects.
> >
> > Alex
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> >
> >
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> >
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/3fd31e62/attachment.html 

[Mike Panetta]

OOPS!  I meant NuttX not NuttOS.  Sorry about that!

Mike

On Tue, Feb 3, 2009 at 5:34 PM, Mike Panetta <panetta.mike at gmail.com> wrote:

> You should take a look at NuttOS.  Its a Posix compliant RTOS (well maybe
> uKernel would be better a name?) thats quite light weight.  Porting lua to
> it should (in theory) be as simple as a recompile...  In NuttOS the API is
> fully Posix compliant, so its threads based.
>
> I have not tried porting it to the STM32 yet, but its something that has
> been seriously on my mind as of late.
>
> Another idea would be to take something thinner like ChibiOS and apply a
> Posix 'skin' to it to gain the standard threads based API.
>
> Anyway, thats my take on things...  Basically its probably simpler to port
> to an RTOS then you might think...  Esp since we would gain things we would
> need for ISR->lua synchronization anyway such as queues, semaphors, mutexes,
> etc...
>
> Mike
>
>
> On Tue, Feb 3, 2009 at 1:49 PM, Bogdan Marinescu <
> bogdan.marinescu at gmail.com> wrote:
>
>>
>> If you *need* an RTOS, you probably shouldn't be running an
>>> interpreted language.  Conversely, if you are programming in a high
>>> level language, you probably don't care as much about what's going on
>>> at the silicon level as long as it does what you want it to.  Sure
>>> there are exceptions, but I'm talking generalities here.
>>
>>
>> That pretty much sums up my take on this subject and explains why I didn't
>> consider an RTOS for eLua.
>>
>> Best,
>> Bogdan
>>
>>
>>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>>
>>> > Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>> > so I'm waiting for the oppions of other people :)
>>> >
>>> > Best,
>>> > Bogdan
>>> >
>>> > On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>> > wrote:
>>> > Hello Guys,,
>>> >   On the Lua Programming Gems, there are at least two articles
>>> > discussing nice multithreading models for Lua.
>>> >   It will be nice to read about them here too.
>>> >
>>> > Best
>>> > Dado
>>> >
>>> >
>>> >
>>> > On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>> > Hi all
>>> >
>>> > This may be a silly and not thought out question, but i'll throw it
>>> > out there anyway: Has anyone tried to integrate the eLua codebase
>>> > with something like FreeRTOS? I.e have eLua running as a low
>>> > priority process while having some other higher-priority time
>>> > critical processes doing their time-critical stuff and chugging
>>> > along-side with eLua.
>>> > I'd imagine there is a lot of merit for doing this kind of thing for
>>> > many projects.
>>> >
>>> > Alex
>>> >
>>> > _______________________________________________
>>> > Elua-dev mailing list
>>> > Elua-dev at lists.berlios.de
>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Elua-dev mailing list
>>> > Elua-dev at lists.berlios.de
>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > Elua-dev mailing list
>>> > Elua-dev at lists.berlios.de
>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/97d7630a/attachment-0001.html 

[jbsnyder]

On Feb 3, 2009, at 4:17 PM, Mike Panetta wrote:

> This biggest issue would be is lua capable of doing the work  
> required in a typical ISR fast enough?  If I was writing an ISR for  
> a space vector modulation scheme, the ISR would be running at the  
> same rate as the PWM frequency (or 2x that in case of symetric  
> SVM).  That can be pretty fast (tens of KHz, 50us between interrupts  
> at 20KHz) and a scripted ISR surly could not be called at such a rate.

Right.  I'd agree.  That said, there would be a rate up to which it  
would be useful.

> The advantage to integrating with an RTOS would be that you could  
> have a lua thread (coroutine, whatever) sleep on a queue or  
> semaphore and the ISR (written in C) could wake it when its done  
> doing whatever it has to do in a time critical maner.

Yeah, that would pretty much take care of the same functionality I'd  
be after.  I was thinking about that more in the sense of, if there  
weren't an RTOS there, using ISRs would be one way to trigger behavior  
without just endlessly polling.

NuttX looks fairly nice, including the license.  If I'm reading  
correctly it does add a fairly decent amount of flash usage, but it  
also has a graphics library and a few other nice facilities.

ChibiOS is only 2.11 KB with a decent set of APIs configured.

One question is:  do we specifically need something that is fully  
POSIX compliant if we use an RTOS?  What are the advantages of this,  
aside from maybe that they could be applied back to mainline Lua or  
would make porting between different RTOSs easier?

--
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/20090203/99690850/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/20090203/99690850/attachment.pgp 

[Alex Babkin]

Hi

Dean,
Absolutely agree that eLua and time-critical are on two sides of spectrum.
As Mike has conveniently illustrated (great example Mike), my line of
thinking was to get the best of both worlds. Systems requiring good
real-time performance can very much benefit from the ease of configurability
that eLua brings to the table, and the easiest way to marry the two sanely
would be to use RTOS to take care of scheduling, priorities, etc

Mike,
I got a couple of 64k ram / 512k flash stm32 chips from digikey recently, so
hopefully these resources will be enough for this ambitious project if i
ever decide to experiment with this.


Alex





On Tue, Feb 3, 2009 at 5:56 PM, Mike Panetta <panetta.mike at gmail.com> wrote:

> OOPS!  I meant NuttX not NuttOS.  Sorry about that!
>
> Mike
>
>
> On Tue, Feb 3, 2009 at 5:34 PM, Mike Panetta <panetta.mike at gmail.com>wrote:
>
>> You should take a look at NuttOS.  Its a Posix compliant RTOS (well maybe
>> uKernel would be better a name?) thats quite light weight.  Porting lua to
>> it should (in theory) be as simple as a recompile...  In NuttOS the API is
>> fully Posix compliant, so its threads based.
>>
>> I have not tried porting it to the STM32 yet, but its something that has
>> been seriously on my mind as of late.
>>
>> Another idea would be to take something thinner like ChibiOS and apply a
>> Posix 'skin' to it to gain the standard threads based API.
>>
>> Anyway, thats my take on things...  Basically its probably simpler to port
>> to an RTOS then you might think...  Esp since we would gain things we would
>> need for ISR->lua synchronization anyway such as queues, semaphors, mutexes,
>> etc...
>>
>> Mike
>>
>>
>> On Tue, Feb 3, 2009 at 1:49 PM, Bogdan Marinescu <
>> bogdan.marinescu at gmail.com> wrote:
>>
>>>
>>> If you *need* an RTOS, you probably shouldn't be running an
>>>> interpreted language.  Conversely, if you are programming in a high
>>>> level language, you probably don't care as much about what's going on
>>>> at the silicon level as long as it does what you want it to.  Sure
>>>> there are exceptions, but I'm talking generalities here.
>>>
>>>
>>> That pretty much sums up my take on this subject and explains why I
>>> didn't consider an RTOS for eLua.
>>>
>>> Best,
>>> Bogdan
>>>
>>>
>>>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>>>
>>>> > Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>>> > so I'm waiting for the oppions of other people :)
>>>> >
>>>> > Best,
>>>> > Bogdan
>>>> >
>>>> > On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>>> > wrote:
>>>> > Hello Guys,,
>>>> >   On the Lua Programming Gems, there are at least two articles
>>>> > discussing nice multithreading models for Lua.
>>>> >   It will be nice to read about them here too.
>>>> >
>>>> > Best
>>>> > Dado
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>>> > Hi all
>>>> >
>>>> > This may be a silly and not thought out question, but i'll throw it
>>>> > out there anyway: Has anyone tried to integrate the eLua codebase
>>>> > with something like FreeRTOS? I.e have eLua running as a low
>>>> > priority process while having some other higher-priority time
>>>> > critical processes doing their time-critical stuff and chugging
>>>> > along-side with eLua.
>>>> > I'd imagine there is a lot of merit for doing this kind of thing for
>>>> > many projects.
>>>> >
>>>> > Alex
>>>> >
>>>> > _______________________________________________
>>>> > Elua-dev mailing list
>>>> > Elua-dev at lists.berlios.de
>>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Elua-dev mailing list
>>>> > Elua-dev at lists.berlios.de
>>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Elua-dev mailing list
>>>> > Elua-dev at lists.berlios.de
>>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>> _______________________________________________
>>>> Elua-dev mailing list
>>>> Elua-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090203/deadcc9f/attachment.html 

[BogdanM]

> This biggest issue would be is lua capable of doing the work required in a
> typical ISR fast enough?  If I was writing an ISR for a space vector
> modulation scheme, the ISR would be running at the same rate as the PWM
> frequency (or 2x that in case of symetric SVM).  That can be pretty fast
> (tens of KHz, 50us between interrupts at 20KHz) and a scripted ISR surly
> could not be called at such a rate.


It won't be able to do it, which is fine from where I'm looking. Remember
that we're talking about an interpreted language on a microcontroller :). It
can do many things,  but magic is not one of them.

The advantage to integrating with an RTOS would be that you could have a lua
> thread (coroutine, whatever) sleep on a queue or semaphore and the ISR
> (written in C) could wake it when its done doing whatever it has to do in a
> time critical maner.


I understand the point, but it's not the idea around which eLua was built.
Rather, it follows the same principle of Forth: everything in a single
system, without the need for an OS (Forth has also a form of built-in
threads IIRC). Lua is the controller of everything, not a separate thread
waiting for something to happen. To solve the kind of problems you're
having, I can see only one way to go with the current design: use loadable C
modules. I've come to believe that this will be possible one day, as I have
a more and more complete idea on how this can be done with few resources.
Just don't ask me when :)
Also, your approach seems to require more than one VM instance. Remember,
you can't interrupt a Lua VM that executes some bytecode and force it to
execute a different bytecode sequence (from an ISR for example). You'd need
a separate VM for that ISR. And then you'd need to take care of how to pass
data between your ISR VM and your "regular" VM. Doable, but quite a bit of a
headache if you ask me.

Best,
Bogdan

>
> Thats my 2c anyway.
>
> Mike
>
>
> On Tue, Feb 3, 2009 at 3:05 PM, Bogdan Marinescu <
> bogdan.marinescu at gmail.com> wrote:
>
>>
>> That said, between coroutines and interrupts, one could probably get
>>> functionality that covers many of these advantages without wrapping
>>> everything in an RTOS.
>>>
>>> Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs
>>> could be done?  With Cortex-M3's NVIC it should be pretty easy to
>>> reconfigure interrupts to call Lua functions,
>>>
>>
>> Not really. It's not about the hardware, Lua's VM isn't really meant to be
>> interrupted. Fortunately there is an easy way to do this: you'd just use
>> Lua's hook support (similar to debug.sethook), maybe slightly modified to
>> take interrupts into account (although I'm not sure yet that modifications
>> are really required). lua.c already does something like this to handle
>> signals (for CTRL+C). There might be better ways to do this, but I can't
>> think of any.
>>
>> Best,
>> Bogdan
>>
>> -jsnyder
>>>
>>
>>> On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:
>>>
>>> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
>>> AVR; which might be comparable to running eLua with an RTOS. My belief
>>> is that the two software systems solve two very different problems.
>>> If you *need* an RTOS, you probably shouldn't be running an
>>> interpreted language.  Conversely, if you are programming in a high
>>> level language, you probably don't care as much about what's going on
>>> at the silicon level as long as it does what you want it to.  Sure
>>> there are exceptions, but I'm talking generalities here.
>>>
>>> I believe it would be easier to use eLua as the application and write
>>> any time-critical code in C in an interrupt service routine than it
>>> would be to try to integrate with an RTOS.  In embedded systems
>>> (especially real-time systems) simplicity is everything.
>>>
>>> !!Dean
>>>
>>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>>
>>> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>>
>>> so I'm waiting for the oppions of other people :)
>>>
>>>
>>> Best,
>>>
>>> Bogdan
>>>
>>>
>>> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>>
>>> wrote:
>>>
>>> Hello Guys,,
>>>
>>>  On the Lua Programming Gems, there are at least two articles
>>>
>>> discussing nice multithreading models for Lua.
>>>
>>>  It will be nice to read about them here too.
>>>
>>>
>>> Best
>>>
>>> Dado
>>>
>>>
>>>
>>>
>>> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>>
>>> Hi all
>>>
>>>
>>> This may be a silly and not thought out question, but i'll throw it
>>>
>>> out there anyway: Has anyone tried to integrate the eLua codebase
>>>
>>> with something like FreeRTOS? I.e have eLua running as a low
>>>
>>> priority process while having some other higher-priority time
>>>
>>> critical processes doing their time-critical stuff and chugging
>>>
>>> along-side with eLua.
>>>
>>> I'd imagine there is a lot of merit for doing this kind of thing for
>>>
>>> many projects.
>>>
>>>
>>> Alex
>>>
>>>
>>> _______________________________________________
>>>
>>> Elua-dev mailing list
>>>
>>> Elua-dev at lists.berlios.de
>>>
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Elua-dev mailing list
>>>
>>> Elua-dev at lists.berlios.de
>>>
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Elua-dev mailing list
>>>
>>> Elua-dev at lists.berlios.de
>>>
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>>   --
>>> James Snyder
>>> Biomedical Engineering
>>> Northwestern University
>>> jbsnyder at fanplastic.org
>>> http://fanplastic.org/key.txt
>>> ph: [phone]
>>>
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090204/46492954/attachment-0001.html 

[BogdanM]

> NuttX looks fairly nice, including the license.  If I'm reading correctly
> it does add a fairly decent amount of flash usage, but it also has a
> graphics library and a few other nice facilities.
>
> ChibiOS is only 2.11 KB with a decent set of APIs configured.
>

Have you considered FreeRTOS? Never used it, but I heard good things about
it.


> One question is:  do we specifically need something that is fully POSIX
> compliant if we use an RTOS?  What are the advantages of this, aside from
> maybe that they could be applied back to mainline Lua or would make porting
> between different RTOSs easier?
>

I'd say we don't need a POSIX compliant RTOS, any is fine as long as it has
a good set of primitives. That said, I don't see this RTOS integration
happening on the official eLua tree too soon. Besides of the fact that this
doesn't really follow the current design principles of eLua (as explained in
my previous e-mail), it has another big drawback: portability. It would mean
that for any new platform that we add to eLua, we'd also have to make a port
of the RTOS if it doesn't exist.
As usual though, I'm opened to suggestions on this, we might find a good way
to release eLua with both "models", and one could simply choose what he
needs at compile time. Or even dynamically. The posibilities are endless :)

Best,
Bogdan

>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: [phone]
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090204/3e15fbaf/attachment.html 

[Mike Panetta]

On Wed, Feb 4, 2009 at 3:19 AM, Bogdan Marinescu <bogdan.marinescu at gmail.com
> wrote:

>
> This biggest issue would be is lua capable of doing the work required in a
>> typical ISR fast enough?  If I was writing an ISR for a space vector
>> modulation scheme, the ISR would be running at the same rate as the PWM
>> frequency (or 2x that in case of symetric SVM).  That can be pretty fast
>> (tens of KHz, 50us between interrupts at 20KHz) and a scripted ISR surly
>> could not be called at such a rate.
>
>
> It won't be able to do it, which is fine from where I'm looking. Remember
> that we're talking about an interpreted language on a microcontroller :). It
> can do many things,  but magic is not one of them.
>

That was pretty much my point. ;)

>
>
> The advantage to integrating with an RTOS would be that you could have a
>> lua thread (coroutine, whatever) sleep on a queue or semaphore and the ISR
>> (written in C) could wake it when its done doing whatever it has to do in a
>> time critical maner.
>
>
> I understand the point, but it's not the idea around which eLua was built.
> Rather, it follows the same principle of Forth: everything in a single
> system, without the need for an OS (Forth has also a form of built-in
> threads IIRC). Lua is the controller of everything, not a separate thread
> waiting for something to happen. To solve the kind of problems you're
> having, I can see only one way to go with the current design: use loadable C
> modules. I've come to believe that this will be possible one day, as I have
> a more and more complete idea on how this can be done with few resources.
> Just don't ask me when :)
> Also, your approach seems to require more than one VM instance. Remember,
> you can't interrupt a Lua VM that executes some bytecode and force it to
> execute a different bytecode sequence (from an ISR for example). You'd need
> a separate VM for that ISR. And then you'd need to take care of how to pass
> data between your ISR VM and your "regular" VM. Doable, but quite a bit of a
> headache if you ask me.
>

I don't see how you could ever meet any sort of hard (or maybe even soft) RT
requirements with lua being the controller of everything.  Unlike forth, lua
has a GC, and with it comes many issues, the biggest of which is  non
deterministic execution time.  Also, I don't see forth running in very many
RT applications, but thats just my limited exposure...

How will loadable C modules fix this issue?  I'm not quite sure I understand
where your coming from with that.

Actually it only requires one VM.  The lua thread that is waiting on the
semaphore will block in C land.  No need to interrupt the VM.  Basically it
would be Lanes for eLua with a well defined c->lua lua->c API.  At least
that was my idea anyway. :)

As for taking care of how the data is passed between the ISR and the VM,
also see Lanes... ;)

Mike

>
> Best,
> Bogdan
>
>
>>
>> Thats my 2c anyway.
>>
>> Mike
>>
>>
>> On Tue, Feb 3, 2009 at 3:05 PM, Bogdan Marinescu <
>> bogdan.marinescu at gmail.com> wrote:
>>
>>>
>>> That said, between coroutines and interrupts, one could probably get
>>>> functionality that covers many of these advantages without wrapping
>>>> everything in an RTOS.
>>>>
>>>> Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs
>>>> could be done?  With Cortex-M3's NVIC it should be pretty easy to
>>>> reconfigure interrupts to call Lua functions,
>>>>
>>>
>>> Not really. It's not about the hardware, Lua's VM isn't really meant to
>>> be interrupted. Fortunately there is an easy way to do this: you'd just use
>>> Lua's hook support (similar to debug.sethook), maybe slightly modified to
>>> take interrupts into account (although I'm not sure yet that modifications
>>> are really required). lua.c already does something like this to handle
>>> signals (for CTRL+C). There might be better ways to do this, but I can't
>>> think of any.
>>>
>>> Best,
>>> Bogdan
>>>
>>> -jsnyder
>>>>
>>>
>>>> On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:
>>>>
>>>> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
>>>> AVR; which might be comparable to running eLua with an RTOS. My belief
>>>> is that the two software systems solve two very different problems.
>>>> If you *need* an RTOS, you probably shouldn't be running an
>>>> interpreted language.  Conversely, if you are programming in a high
>>>> level language, you probably don't care as much about what's going on
>>>> at the silicon level as long as it does what you want it to.  Sure
>>>> there are exceptions, but I'm talking generalities here.
>>>>
>>>> I believe it would be easier to use eLua as the application and write
>>>> any time-critical code in C in an interrupt service routine than it
>>>> would be to try to integrate with an RTOS.  In embedded systems
>>>> (especially real-time systems) simplicity is everything.
>>>>
>>>> !!Dean
>>>>
>>>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>>>
>>>> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>>>
>>>> so I'm waiting for the oppions of other people :)
>>>>
>>>>
>>>> Best,
>>>>
>>>> Bogdan
>>>>
>>>>
>>>> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>>>
>>>> wrote:
>>>>
>>>> Hello Guys,,
>>>>
>>>>  On the Lua Programming Gems, there are at least two articles
>>>>
>>>> discussing nice multithreading models for Lua.
>>>>
>>>>  It will be nice to read about them here too.
>>>>
>>>>
>>>> Best
>>>>
>>>> Dado
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>>>
>>>> Hi all
>>>>
>>>>
>>>> This may be a silly and not thought out question, but i'll throw it
>>>>
>>>> out there anyway: Has anyone tried to integrate the eLua codebase
>>>>
>>>> with something like FreeRTOS? I.e have eLua running as a low
>>>>
>>>> priority process while having some other higher-priority time
>>>>
>>>> critical processes doing their time-critical stuff and chugging
>>>>
>>>> along-side with eLua.
>>>>
>>>> I'd imagine there is a lot of merit for doing this kind of thing for
>>>>
>>>> many projects.
>>>>
>>>>
>>>> Alex
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Elua-dev mailing list
>>>>
>>>> Elua-dev at lists.berlios.de
>>>>
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Elua-dev mailing list
>>>>
>>>> Elua-dev at lists.berlios.de
>>>>
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Elua-dev mailing list
>>>>
>>>> Elua-dev at lists.berlios.de
>>>>
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Elua-dev mailing list
>>>> Elua-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>>   --
>>>> James Snyder
>>>> Biomedical Engineering
>>>> Northwestern University
>>>> jbsnyder at fanplastic.org
>>>> http://fanplastic.org/key.txt
>>>> ph: [phone]
>>>>
>>>>
>>>> _______________________________________________
>>>> Elua-dev mailing list
>>>> Elua-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090204/16a34390/attachment.html 

[Alex Babkin]

I think Bogdan was talking about the need for more than one VM for the case
of Lua ISRs, not the eLua+RTOS

Also, as for conceptual level concerns, using an OS should not taint
"everything is a single system" moto of eLua, at least not in "it's own
world". After all, the whole idea of OS is to give this illusion to the
processes that they own the whole system. eLua should not care that it gets
preempted once in a while to yield for other processes or ISRs. This should
be transparent to eLua (if designed and implemented appropriately of course)
.

As for compatibility concern, FreeRTOS already supports many platforms, but
there still can be (now or in future) a supported platform delta with eLua,
so this concern is valid
One potential solution i can think of is to isolate and standardize a
particular interface between eLua and RTOS, as opposed to merge the two into
one (addressing Bogdan's concern). Merit of this solution will need to be
determined looking at the two code bases, of course, but i suspect this is
doable with another RTOS specific eLua backend and maybe a thin 'back end'
layer of glue code on the RTOS side to provide needed hooks.

FreeRTOS seems like it's rather minimal, which is a great starting point
IMO.

Alex

On Wed, Feb 4, 2009 at 8:33 AM, Mike Panetta <panetta.mike at gmail.com> wrote:

>
>
> On Wed, Feb 4, 2009 at 3:19 AM, Bogdan Marinescu <
> bogdan.marinescu at gmail.com> wrote:
>
>>
>> This biggest issue would be is lua capable of doing the work required in a
>>> typical ISR fast enough?  If I was writing an ISR for a space vector
>>> modulation scheme, the ISR would be running at the same rate as the PWM
>>> frequency (or 2x that in case of symetric SVM).  That can be pretty fast
>>> (tens of KHz, 50us between interrupts at 20KHz) and a scripted ISR surly
>>> could not be called at such a rate.
>>
>>
>> It won't be able to do it, which is fine from where I'm looking. Remember
>> that we're talking about an interpreted language on a microcontroller :). It
>> can do many things,  but magic is not one of them.
>>
>
> That was pretty much my point. ;)
>
>
>>
>>
>> The advantage to integrating with an RTOS would be that you could have a
>>> lua thread (coroutine, whatever) sleep on a queue or semaphore and the ISR
>>> (written in C) could wake it when its done doing whatever it has to do in a
>>> time critical maner.
>>
>>
>> I understand the point, but it's not the idea around which eLua was built.
>> Rather, it follows the same principle of Forth: everything in a single
>> system, without the need for an OS (Forth has also a form of built-in
>> threads IIRC). Lua is the controller of everything, not a separate thread
>> waiting for something to happen. To solve the kind of problems you're
>> having, I can see only one way to go with the current design: use loadable C
>> modules. I've come to believe that this will be possible one day, as I have
>> a more and more complete idea on how this can be done with few resources.
>> Just don't ask me when :)
>> Also, your approach seems to require more than one VM instance. Remember,
>> you can't interrupt a Lua VM that executes some bytecode and force it to
>> execute a different bytecode sequence (from an ISR for example). You'd need
>> a separate VM for that ISR. And then you'd need to take care of how to pass
>> data between your ISR VM and your "regular" VM. Doable, but quite a bit of a
>> headache if you ask me.
>>
>
> I don't see how you could ever meet any sort of hard (or maybe even soft)
> RT requirements with lua being the controller of everything.  Unlike forth,
> lua has a GC, and with it comes many issues, the biggest of which is  non
> deterministic execution time.  Also, I don't see forth running in very many
> RT applications, but thats just my limited exposure...
>
> How will loadable C modules fix this issue?  I'm not quite sure I
> understand where your coming from with that.
>
> Actually it only requires one VM.  The lua thread that is waiting on the
> semaphore will block in C land.  No need to interrupt the VM.  Basically it
> would be Lanes for eLua with a well defined c->lua lua->c API.  At least
> that was my idea anyway. :)
>
> As for taking care of how the data is passed between the ISR and the VM,
> also see Lanes... ;)
>
> Mike
>
>
>>
>> Best,
>> Bogdan
>>
>>
>>>
>>> Thats my 2c anyway.
>>>
>>> Mike
>>>
>>>
>>> On Tue, Feb 3, 2009 at 3:05 PM, Bogdan Marinescu <
>>> bogdan.marinescu at gmail.com> wrote:
>>>
>>>>
>>>> That said, between coroutines and interrupts, one could probably get
>>>>> functionality that covers many of these advantages without wrapping
>>>>> everything in an RTOS.
>>>>>
>>>>> Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs
>>>>> could be done?  With Cortex-M3's NVIC it should be pretty easy to
>>>>> reconfigure interrupts to call Lua functions,
>>>>>
>>>>
>>>> Not really. It's not about the hardware, Lua's VM isn't really meant to
>>>> be interrupted. Fortunately there is an easy way to do this: you'd just use
>>>> Lua's hook support (similar to debug.sethook), maybe slightly modified to
>>>> take interrupts into account (although I'm not sure yet that modifications
>>>> are really required). lua.c already does something like this to handle
>>>> signals (for CTRL+C). There might be better ways to do this, but I can't
>>>> think of any.
>>>>
>>>> Best,
>>>> Bogdan
>>>>
>>>> -jsnyder
>>>>>
>>>>
>>>>> On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:
>>>>>
>>>>> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
>>>>>
>>>>> AVR; which might be comparable to running eLua with an RTOS. My belief
>>>>>
>>>>> is that the two software systems solve two very different problems.
>>>>> If you *need* an RTOS, you probably shouldn't be running an
>>>>> interpreted language.  Conversely, if you are programming in a high
>>>>> level language, you probably don't care as much about what's going on
>>>>> at the silicon level as long as it does what you want it to.  Sure
>>>>> there are exceptions, but I'm talking generalities here.
>>>>>
>>>>> I believe it would be easier to use eLua as the application and write
>>>>> any time-critical code in C in an interrupt service routine than it
>>>>> would be to try to integrate with an RTOS.  In embedded systems
>>>>> (especially real-time systems) simplicity is everything.
>>>>>
>>>>> !!Dean
>>>>>
>>>>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>>>>
>>>>> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>>>>
>>>>> so I'm waiting for the oppions of other people :)
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Bogdan
>>>>>
>>>>>
>>>>> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Hello Guys,,
>>>>>
>>>>>  On the Lua Programming Gems, there are at least two articles
>>>>>
>>>>> discussing nice multithreading models for Lua.
>>>>>
>>>>>  It will be nice to read about them here too.
>>>>>
>>>>>
>>>>> Best
>>>>>
>>>>> Dado
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>>
>>>>> This may be a silly and not thought out question, but i'll throw it
>>>>>
>>>>> out there anyway: Has anyone tried to integrate the eLua codebase
>>>>>
>>>>> with something like FreeRTOS? I.e have eLua running as a low
>>>>>
>>>>> priority process while having some other higher-priority time
>>>>>
>>>>> critical processes doing their time-critical stuff and chugging
>>>>>
>>>>> along-side with eLua.
>>>>>
>>>>> I'd imagine there is a lot of merit for doing this kind of thing for
>>>>>
>>>>> many projects.
>>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Elua-dev mailing list
>>>>>
>>>>> Elua-dev at lists.berlios.de
>>>>>
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Elua-dev mailing list
>>>>>
>>>>> Elua-dev at lists.berlios.de
>>>>>
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Elua-dev mailing list
>>>>>
>>>>> Elua-dev at lists.berlios.de
>>>>>
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Elua-dev mailing list
>>>>> Elua-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>>   --
>>>>> James Snyder
>>>>> Biomedical Engineering
>>>>> Northwestern University
>>>>> jbsnyder at fanplastic.org
>>>>> http://fanplastic.org/key.txt
>>>>> ph: [phone]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Elua-dev mailing list
>>>>> Elua-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Elua-dev mailing list
>>>> Elua-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090204/936946a2/attachment-0001.html 

[BogdanM]

> I don't see how you could ever meet any sort of hard (or maybe even soft)
> RT requirements with lua being the controller of everything.  Unlike forth,
> lua has a GC, and with it comes many issues, the biggest of which is  non
> deterministic execution time.
>

That's only partially true. Remember that you have full control over the GC,
so you can turn it off completely. If you have enough RAM, you can run your
program with the garbage collector completely turned off.

How will loadable C modules fix this issue?  I'm not quite sure I understand
> where your coming from with that.
>

I wasn't clear on this, I was talking about "loadable C modules" on a more
general level, closer to o loadable dynamic library that exposes a number of
functions that can be called. If you combine the ability to turn off the
garbage collector with the ability to use loadable C modules that can do
most of the intensive processing work (in theory you could register them as
interrupt handlers, for example) you might have something that is "quite
RT". It will never match the RT capabilities of a system written in C or
some other medium-to-low-level language, and it won't even be RT from a Lua
standpoint (since all the "real stuff" happens in C), but it might still be
RT enough for you :)


> Actually it only requires one VM.  The lua thread that is waiting on the
> semaphore will block in C land.  No need to interrupt the VM.  Basically it
> would be Lanes for eLua with a well defined c->lua lua->c API.  At least
> that was my idea anyway. :)
>

I was talking about having to do ISRs from Lua itself. If you just want to
block in C, you might not need threads at all, just block in a C module and
let your interrupt handlers do all the work. It's a limited model, still
pretty usable in my experience. Also in my experience, there are (too) many
times when people rush to use an OS when they could do very well without it
(by "very well" I mean that the added code complexity would not be
significant). If your CPU has a modern interrupt controller that supports
priorities and interrupt nesting, you'd probably go the OS way only for
quite complex applications (remember that I'm still talking about
small-to-medium complexity embedded systems here).

As for taking care of how the data is passed between the ISR and the VM,
> also see Lanes... ;)
>

I know about Lanes, it's an excellent package. I didn't look at its code
though, so I don't know how the data is passed between states. All I
remember is seeing a relatively large numbers of threads where people
complain about this stuff on the Lua mailing list.

Best,
Bogdan

>
> Mike
>
>
>>
>> Best,
>> Bogdan
>>
>>
>>>
>>> Thats my 2c anyway.
>>>
>>> Mike
>>>
>>>
>>> On Tue, Feb 3, 2009 at 3:05 PM, Bogdan Marinescu <
>>> bogdan.marinescu at gmail.com> wrote:
>>>
>>>>
>>>> That said, between coroutines and interrupts, one could probably get
>>>>> functionality that covers many of these advantages without wrapping
>>>>> everything in an RTOS.
>>>>>
>>>>> Regarding ISRs and eLua:  Has anyone given any thought to how Lua ISRs
>>>>> could be done?  With Cortex-M3's NVIC it should be pretty easy to
>>>>> reconfigure interrupts to call Lua functions,
>>>>>
>>>>
>>>> Not really. It's not about the hardware, Lua's VM isn't really meant to
>>>> be interrupted. Fortunately there is an easy way to do this: you'd just use
>>>> Lua's hook support (similar to debug.sethook), maybe slightly modified to
>>>> take interrupts into account (although I'm not sure yet that modifications
>>>> are really required). lua.c already does something like this to handle
>>>> signals (for CTRL+C). There might be better ways to do this, but I can't
>>>> think of any.
>>>>
>>>> Best,
>>>> Bogdan
>>>>
>>>> -jsnyder
>>>>>
>>>>
>>>>> On Feb 3, 2009, at 12:41 PM, Dean Hall wrote:
>>>>>
>>>>> I've used both PyMite (a small Python interpreter) and AvrX RTOS on an
>>>>>
>>>>> AVR; which might be comparable to running eLua with an RTOS. My belief
>>>>>
>>>>> is that the two software systems solve two very different problems.
>>>>> If you *need* an RTOS, you probably shouldn't be running an
>>>>> interpreted language.  Conversely, if you are programming in a high
>>>>> level language, you probably don't care as much about what's going on
>>>>> at the silicon level as long as it does what you want it to.  Sure
>>>>> there are exceptions, but I'm talking generalities here.
>>>>>
>>>>> I believe it would be easier to use eLua as the application and write
>>>>> any time-critical code in C in an interrupt service routine than it
>>>>> would be to try to integrate with an RTOS.  In embedded systems
>>>>> (especially real-time systems) simplicity is everything.
>>>>>
>>>>> !!Dean
>>>>>
>>>>> On Feb 3, 2009, at 12:18 , Bogdan Marinescu wrote:
>>>>>
>>>>> Integrating eLua with a RTOS is not on my list of "TODO for eLua",
>>>>>
>>>>> so I'm waiting for the oppions of other people :)
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Bogdan
>>>>>
>>>>>
>>>>> On Tue, Feb 3, 2009 at 8:16 PM, Dado Sutter <dadosutter at gmail.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Hello Guys,,
>>>>>
>>>>>  On the Lua Programming Gems, there are at least two articles
>>>>>
>>>>> discussing nice multithreading models for Lua.
>>>>>
>>>>>  It will be nice to read about them here too.
>>>>>
>>>>>
>>>>> Best
>>>>>
>>>>> Dado
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 3, 2009 at 16:05, Alex Babkin <ababkin at gmail.com> wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>>
>>>>> This may be a silly and not thought out question, but i'll throw it
>>>>>
>>>>> out there anyway: Has anyone tried to integrate the eLua codebase
>>>>>
>>>>> with something like FreeRTOS? I.e have eLua running as a low
>>>>>
>>>>> priority process while having some other higher-priority time
>>>>>
>>>>> critical processes doing their time-critical stuff and chugging
>>>>>
>>>>> along-side with eLua.
>>>>>
>>>>> I'd imagine there is a lot of merit for doing this kind of thing for
>>>>>
>>>>> many projects.
>>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Elua-dev mailing list
>>>>>
>>>>> Elua-dev at lists.berlios.de
>>>>>
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Elua-dev mailing list
>>>>>
>>>>> Elua-dev at lists.berlios.de
>>>>>
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Elua-dev mailing list
>>>>>
>>>>> Elua-dev at lists.berlios.de
>>>>>
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Elua-dev mailing list
>>>>> Elua-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>>   --
>>>>> James Snyder
>>>>> Biomedical Engineering
>>>>> Northwestern University
>>>>> jbsnyder at fanplastic.org
>>>>> http://fanplastic.org/key.txt
>>>>> ph: [phone]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Elua-dev mailing list
>>>>> Elua-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Elua-dev mailing list
>>>> Elua-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>>
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090204/8212925d/attachment.html 

[jbsnyder]

On Feb 4, 2009, at 9:30 AM, Bogdan Marinescu wrote:

>
> I don't see how you could ever meet any sort of hard (or maybe even  
> soft) RT requirements with lua being the controller of everything.  
> Unlike forth, lua has a GC, and with it comes many issues, the  
> biggest of which is  non deterministic execution time.
>
> That's only partially true. Remember that you have full control over  
> the GC, so you can turn it off completely. If you have enough RAM,  
> you can run your program with the garbage collector completely  
> turned off.
>
> How will loadable C modules fix this issue?  I'm not quite sure I  
> understand where your coming from with that.
>
> I wasn't clear on this, I was talking about "loadable C modules" on  
> a more general level, closer to o loadable dynamic library that  
> exposes a number of functions that can be called. If you combine the  
> ability to turn off the garbage collector with the ability to use  
> loadable C modules that can do most of the intensive processing work  
> (in theory you could register them as interrupt handlers, for  
> example) you might have something that is "quite RT". It will never  
> match the RT capabilities of a system written in C or some other  
> medium-to-low-level language, and it won't even be RT from a Lua  
> standpoint (since all the "real stuff" happens in C), but it might  
> still be RT enough for you :)

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.

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.

This and related issues are on my mind currently because I'm finding I  
have to keep track of a fair amount of state to do all I'm  
implementing with the ADC module.  I don't explicitly need queues or  
semaphores as a system-provided tool, but I could certainly make use  
of them :-)

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.

>
> Actually it only requires one VM.  The lua thread that is waiting on  
> the semaphore will block in C land.  No need to interrupt the VM.  
> Basically it would be Lanes for eLua with a well defined c->lua lua-
> >c API.  At least that was my idea anyway. :)
>
> I was talking about having to do ISRs from Lua itself. If you just  
> want to block in C, you might not need threads at all, just block in  
> a C module and let your interrupt handlers do all the work. It's a  
> limited model, still pretty usable in my experience. Also in my  
> experience, there are (too) many times when people rush to use an OS  
> when they could do very well without it (by "very well" I mean that  
> the added code complexity would not be significant). If your CPU has  
> a modern interrupt controller that supports priorities and interrupt  
> nesting, you'd probably go the OS way only for quite complex  
> applications (remember that I'm still talking about small-to-medium  
> complexity embedded systems here).

Right, and while you may not have actuall Lua ISRs you could expose  
functionality to Lua allowing it to control whether interrupts are  
enabled/disabled and what is called when said interrupt fires.  I also  
think some general primitives (queues, semaphores) would be useful as  
Mike describes, although I'm not sure if we need all that Lanes does.

>
> As for taking care of how the data is passed between the ISR and the  
> VM, also see Lanes... ;)
>
> I know about Lanes, it's an excellent package. I didn't look at its  
> code though, so I don't know how the data is passed between states.  
> All I remember is seeing a relatively large numbers of threads where  
> people complain about this stuff on the Lua mailing list.


I've heard that complaint as well.  The author states that a large  
number of threads are generated through time, but that there are only  
a few that are running at any given time.

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.

--
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/20090204/50824eff/attachment-0001.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/20090204/50824eff/attachment-0001.pgp 

[Mike Panetta]

On Wed, Feb 4, 2009 at 10:30 AM, Bogdan Marinescu <
bogdan.marinescu at gmail.com> wrote:

>
> How will loadable C modules fix this issue?  I'm not quite sure I
>> understand where your coming from with that.
>>
>
> I wasn't clear on this, I was talking about "loadable C modules" on a more
> general level, closer to o loadable dynamic library that exposes a number of
> functions that can be called. If you combine the ability to turn off the
> garbage collector with the ability to use loadable C modules that can do
> most of the intensive processing work (in theory you could register them as
> interrupt handlers, for example) you might have something that is "quite
> RT". It will never match the RT capabilities of a system written in C or
> some other medium-to-low-level language, and it won't even be RT from a Lua
> standpoint (since all the "real stuff" happens in C), but it might still be
> RT enough for you :)
>

This does sound interesting, and a definite possible solution.  As another
reply stated, I would still like to have semaphores and mutexes to keep
things in line however.

I don't know how much I like having to turn the GC off though.  With it on
Lua can run on a small 64K system very well, with it off things get a little
hairy.  And even with it off things will still be non-deterministic, as when
you do finally get around to calling the GC, you still don't know how long
it will take to run. 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.

>
>
>> Actually it only requires one VM.  The lua thread that is waiting on the
>> semaphore will block in C land.  No need to interrupt the VM.  Basically it
>> would be Lanes for eLua with a well defined c->lua lua->c API.  At least
>> that was my idea anyway. :)
>>
>
> I was talking about having to do ISRs from Lua itself. If you just want to
> block in C, you might not need threads at all, just block in a C module and
> let your interrupt handlers do all the work. It's a limited model, still
> pretty usable in my experience. Also in my experience, there are (too) many
> times when people rush to use an OS when they could do very well without it
> (by "very well" I mean that the added code complexity would not be
> significant). If your CPU has a modern interrupt controller that supports
> priorities and interrupt nesting, you'd probably go the OS way only for
> quite complex applications (remember that I'm still talking about
> small-to-medium complexity embedded systems here).
>

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

I agree about rusing to use an OS.  None of the embedded controllers I have
done have used or needed one.  Of course none of them have had a script
language running on them either. :)

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?

>
> As for taking care of how the data is passed between the ISR and the VM,
>> also see Lanes... ;)
>>
>
> I know about Lanes, it's an excellent package. I didn't look at its code
> though, so I don't know how the data is passed between states. All I
> remember is seeing a relatively large numbers of threads where people
> complain about this stuff on the Lua mailing list.
>

Ahh, I have never actually used it, just looked at the site and the source a
little bit.  To me it basically seemed like a wrapper for pthreads, maybe
its not.

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.



>
>
>
> Best,
> Bogdan
>

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090204/9d55eeeb/attachment.html