eLua Development

eeprom

Classic

List

Threaded

12 messages Options

Georges

eeprom

About Lua program and autoboot.

SD Card is the best way to start an Lua program.

Another nice way is to use an I2C Eeprom to store the Lua program.

It is a small ( 8 pins ) low cost component and It need only 2 wires to be
connected ( I2C ).
64 Kbytes Eeprom is easy to find and low cost.

Best regards

Georges

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

Dado Sutter

eeprom

Hello Georges,

On Tue, Feb 17, 2009 at 02:33, georges King <georgestheking at gmail.com>wrote:

> About Lua program and autoboot.
>
> SD Card is the best way to start an Lua program.

Yes, specially now that we have support for it ! :)

The ROM FS, using the same internal Flash used for eLua code, is actually a
very nice option for many cases too.
As it is a read-only fs today, programs are stored at build-time. But it is
an easy process and eLua can start a program directly at boot time. All you
need is to store your program in the ROMFS with the name "autorun.lua". When
eLua wakes up from a reset or power-on, after it's initializations, it looks
for a so called program in the fs, starting the Lua interpreter to run it if
it finds it. If not, eLua starts it's normal shell, from where you can run
any program manually or the stand-alone interpreter too.

> Another nice way is to use an I2C Eeprom to store the Lua program.
>
> It is a small ( 8 pins ) low cost component and It need only 2 wires to be
> connected ( I2C ).
> 64 Kbytes Eeprom is easy to find and low cost.

Sure, this is also an option.
Please note that we began to write our "eLua modules", focusing on support
for internal peripherals usually found in MCUs. This type of external
component support module is welcome too, specially if it can be abstracted
for a generic/portable interface. We have an example of this with a GPS
module written by an under-graduate students, T?o Benjamin, that is beeing
used today in "Manfredo" :) a self navigating robot that wonders thru the
PUC Campus :).
As your idea over the I2C bus, the GPS module wraps the UART interface for
an RS-232 serial com with an external gps. It also illustrates how a module
can be "hybrid", with C code for using a position/distance calc lib we
already had and with Lua code for the NMEA0182 sentences parsing and gps
control.

Another example would be an LCD module that uses 6~7 PIO pins to bit-bang
control an hitachi protocol for an external char LCD. Such a module should
be able to use MCU internal LCD controllers too, when available, offering
full code portability at the Lua level.

Best regards
>
> Georges
>
> Belgium

Regards
Dado

>
>
> _______________________________________________
> 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/20090217/6a91b11d/attachment.html

BogdanM

eeprom

In reply to this post by Georges

Another ROMFS that would work over I2C/SPI memory chips instead of the
internal Flash could be made with very little effort using the already
existing code in eLua. Making it writeable will have to wait a bit longer
though.

Best,
Bogdan

On Tue, Feb 17, 2009 at 7:33 AM, georges King <georgestheking at gmail.com>wrote:

> About Lua program and autoboot.
>
> SD Card is the best way to start an Lua program.
>
> Another nice way is to use an I2C Eeprom to store the Lua program.
>
> It is a small ( 8 pins ) low cost component and It need only 2 wires to be
> connected ( I2C ).
> 64 Kbytes Eeprom is easy to find and low cost.
>
> Best regards
>
> Georges
>
> Belgium
>
> _______________________________________________
> 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/20090217/01318216/attachment-0001.html

John Hind

Microcontroller Filesystem

The discussion of the eLua file system and autoruns is very interesting.
Sorry if this goes over old ground but I have not actually started working
with eLua yet (planning to start with the next release - I'm waiting to see
which hardware to buy!)

One idea I had when I was working on this on my own was to dispense with a
file system altogether and use persistence instead. You would load source
code over a network or serial link into a RAM buffer and compile it from
there. Then there would be a feature added to Lua to back functions in
tables off into flash memory in dump (byte-code) format. The value in the
table would be replaced by a userdata containing a pointer into the flash. A
__call metamethod on the userdata would recover the function into RAM
whenever it was called (this could be a caching system so it would be
retained in RAM until flushed). Alternatively, the runtime could be modified
to execute the function in flash. There could be some flags on each function
dumped to flash including a "run at boot" flag. On boot, the system would
search the flash function store and run any functions with this flag set.

This scheme should be much simpler and less resource hungry than a file
system (it effectively uses Lua tables as the directory structure), easy to
make writable and also by virtue of the cachability, adaptable to slower
serial off-chip memory. Of course, it only stores functions - see my
"engram" proposal on the WiKi for where I was headed with this!

Sorry again if I've just re-invented the wheel!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090217/75edc628/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090217/75edc628/attachment-0001.bin

BogdanM

Microcontroller Filesystem

In reply to this post by BogdanM

> The discussion of the eLua file system and autoruns is very interesting.
> Sorry if this goes over old ground but I have not actually started working
> with eLua yet (planning to start with the next release ? I'm waiting to see
> which hardware to buy!)
>

Currently, the LM3S CPU has the most features implemented for eLua. This
might or might not hold true in the future, I can't give any guarantees on
this.

> One idea I had when I was working on this on my own was to dispense with a
> file system altogether and use persistence instead. You would load source
> code over a network or serial link into a RAM buffer and compile it from
>
eLua can already upload code into RAM via XMODEM. Not exactly what you
meant, but a good start :)

> there. Then there would be a feature added to Lua to back functions in
> tables off into flash memory in dump (byte-code) format. The value in the
> table would be replaced by a userdata containing a pointer into the flash. A
> __call metamethod on the userdata would recover the function into RAM
> whenever it was called (this could be a caching system so it would be
> retained in RAM until flushed). Alternatively, the runtime could be modified
> to execute the function in flash. There could be some flags on each function
> dumped to flash including a "run at boot" flag. On boot, the system would
> search the flash function store and run any functions with this flag set.
>

I'm not sure I understood this, can you give a simple example (maybe
together with an equally simple usage scenario)? I just can't grasp the
concept apparently :)

Sorry again if I've just re-invented the wheel!
>
I don't think you did; on the contrary, you probably came up with something
new that I'm just unable to understand yet :)

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

John Hind

Microcontroller Filesystem

OK, let me try to explain this half-thought-out idea a bit more clearly! I
feel a "hello world" coming on!

Starting with an empty LuaStamp, I load something like the following into
its RAM:

app = flash(function() print("hello world") end, "autorun")

app()

This will print (whatever that means in this context) "hello world"
immediately.

Now I cycle the power on the controller and it powers up and prints "hello
world" again.

The new "flash" library function takes a function and does a string.dump
operation on it saving the resulting byte code string in flash memory along
with an initial "flags" byte which in this case has the "autorun" flag set.
"flash" returns a userdata (app) containing the address of the string in
flash memory and having a metatable with a _call metafunction defined.

The final line of the original chunk calls the app userdata, invoking the
_call metafunction which loadstring's the function from flash and tail-calls
it. (More complexly the userdata might point to the original function cached
in RAM for performance reasons at this stage). This step could be omitted, I
just put it in to show what is going on.

Now we turn power off, killing the original chunk and any cached copy of the
function.

When we power up again, the system looks through the part of the flash
memory used to store functions. It sees the persisted version of our
function and that it's "autorun" flag is set. So it loadstring's it from
flash, re-creates the userdata proxy and executes it printing "hello world"
again.

In a more complex scenario, the autorun function might create whole library
tables of userdata "function proxies" pointing to additional functions in
flash which are not autorun. These get loaded into RAM when they are first
called, and may be flushed at any time to conserve RAM.

From: elua-dev-bounces at lists.berlios.de
[mailto:elua-dev-bounces at lists.berlios.de] On Behalf Of Bogdan Marinescu
Sent: 17 February 2009 14:31
To: eLua Users and Development List
Subject: Re: [eLua-dev] Microcontroller Filesystem

The discussion of the eLua file system and autoruns is very interesting.
Sorry if this goes over old ground but I have not actually started working
with eLua yet (planning to start with the next release - I'm waiting to see
which hardware to buy!)

Currently, the LM3S CPU has the most features implemented for eLua. This
might or might not hold true in the future, I can't give any guarantees on
this.

One idea I had when I was working on this on my own was to dispense with a
file system altogether and use persistence instead. You would load source
code over a network or serial link into a RAM buffer and compile it from

eLua can already upload code into RAM via XMODEM. Not exactly what you
meant, but a good start :)

there. Then there would be a feature added to Lua to back functions in
tables off into flash memory in dump (byte-code) format. The value in the
table would be replaced by a userdata containing a pointer into the flash. A
__call metamethod on the userdata would recover the function into RAM
whenever it was called (this could be a caching system so it would be
retained in RAM until flushed). Alternatively, the runtime could be modified
to execute the function in flash. There could be some flags on each function
dumped to flash including a "run at boot" flag. On boot, the system would
search the flash function store and run any functions with this flag set.

I'm not sure I understood this, can you give a simple example (maybe
together with an equally simple usage scenario)? I just can't grasp the
concept apparently :)

Sorry again if I've just re-invented the wheel!

I don't think you did; on the contrary, you probably came up with something
new that I'm just unable to understand yet :)

Best,
Bogdan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090217/af41e43c/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090217/af41e43c/attachment.bin

BogdanM

Microcontroller Filesystem

In reply to this post by BogdanM

This is very interesting, but it seems that is still requires at least a
rudimentary file system (to manage the serialization). And a file system is
much more generic, so it can be used to keep arbitrary data (which is
sometimes very desirable).
Plus, a filesystem doesn't have to be that large. I actually implemented a
very simple R/W filesystem that I plan to integrate into eLua soon.

Best,
Bogdan

On Tue, Feb 17, 2009 at 5:36 PM, John Hind <john.hind at zen.co.uk> wrote:

> OK, let me try to explain this half-thought-out idea a bit more clearly!
> I feel a "hello world" coming on!
>
>
>
> Starting with an empty LuaStamp, I load something like the following into
> its RAM:
>
>
>
> app = flash(function() print("hello world") end, "autorun")
>
> app()
>
>
>
> This will print (whatever that means in this context) "hello world"
> immediately.
>
>
>
> Now I cycle the power on the controller and it powers up and prints "hello
> world" again.
>
>
>
> The new "flash" library function takes a function and does a string.dump
> operation on it saving the resulting byte code string in flash memory along
> with an initial "flags" byte which in this case has the "autorun" flag set.
> "flash" returns a userdata (app) containing the address of the string in
> flash memory and having a metatable with a _call metafunction defined.
>
>
>
> The final line of the original chunk calls the app userdata, invoking the
> _call metafunction which loadstring's the function from flash and tail-calls
> it. (More complexly the userdata might point to the original function cached
> in RAM for performance reasons at this stage). This step could be omitted, I
> just put it in to show what is going on.
>
>
>
> Now we turn power off, killing the original chunk and any cached copy of
> the function.
>
>
>
> When we power up again, the system looks through the part of the flash
> memory used to store functions. It sees the persisted version of our
> function and that it's "autorun" flag is set. So it loadstring's it from
> flash, re-creates the userdata proxy and executes it printing "hello world"
> again.
>
>
>
> In a more complex scenario, the autorun function might create whole library
> tables of userdata "function proxies" pointing to additional functions in
> flash which are not autorun. These get loaded into RAM when they are first
> called, and may be flushed at any time to conserve RAM.
>
>
>
> *From:* elua-dev-bounces at lists.berlios.de [mailto:
> elua-dev-bounces at lists.berlios.de] *On Behalf Of *Bogdan Marinescu
> *Sent:* 17 February 2009 14:31
> *To:* eLua Users and Development List
> *Subject:* Re: [eLua-dev] Microcontroller Filesystem
>
>
>
>
>
> The discussion of the eLua file system and autoruns is very interesting.
> Sorry if this goes over old ground but I have not actually started working
> with eLua yet (planning to start with the next release ? I'm waiting to see
> which hardware to buy!)
>
>
> Currently, the LM3S CPU has the most features implemented for eLua. This
> might or might not hold true in the future, I can't give any guarantees on
> this.
>
>
> One idea I had when I was working on this on my own was to dispense with
> a file system altogether and use persistence instead. You would load source
> code over a network or serial link into a RAM buffer and compile it from
>
> eLua can already upload code into RAM via XMODEM. Not exactly what you
> meant, but a good start :)
>
> there. Then there would be a feature added to Lua to back functions in
> tables off into flash memory in dump (byte-code) format. The value in the
> table would be replaced by a userdata containing a pointer into the flash. A
> __call metamethod on the userdata would recover the function into RAM
> whenever it was called (this could be a caching system so it would be
> retained in RAM until flushed). Alternatively, the runtime could be modified
> to execute the function in flash. There could be some flags on each function
> dumped to flash including a "run at boot" flag. On boot, the system would
> search the flash function store and run any functions with this flag set.
>
> I'm not sure I understood this, can you give a simple example (maybe
> together with an equally simple usage scenario)? I just can't grasp the
> concept apparently :)
>
> Sorry again if I've just re-invented the wheel!
>
> I don't think you did; on the contrary, you probably came up with
> something new that I'm just unable to understand yet :)
>
> Best,
> Bogdan
>
>
>
> _______________________________________________
> 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/20090217/d049e316/attachment.html

Dado Sutter

Microcontroller Filesystem

In reply to this post by BogdanM

Hello,
John, sorry for the delay on this.
I think we have very interesting sugestions here. I see it more as a
separate persistency/function proxy scheme, that could be
extended/integrated for/with an RPC architecture, than as an alternative
File System.
The overhead of our current FS and the r/w planned ones (we actually have
mmc/sd already ! :) is very small, it is really a lightweight FS, so you
your suggestions could work perfectly well upon any of them.
The scenario for which you plan your sugestions seem to be a more complex
one and I'd like to hear more about it.

Regards
Dado

On Tue, Feb 17, 2009 at 12:36, John Hind <john.hind at zen.co.uk> wrote:

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

John Hind

Microcontroller Filesystem

Hi Dado,

Yes, I am simply amazed at how much you manage to fit into 200MB odd - all
the Lua builds I've done (for x86) have come out around twice that, and that
is using the FS and network stack in the OS. These ARM processors must be
very code-efficient!

I had not thought of this system as requiring a file system at all - just a
basic ability to read/write flash at a physical address. Certainly it would
not do for some apps such as web servers or media players, but it could be
enough for many control and instrumentation apps. A full file system could
then be an option for apps requiring it. An off-line GC / simple compacter
should be adequate to cope with deletions in this scenario. Of course, there
needs to be some way to build the userdata proxies in RAM at startup, but a
simple walk of the chain of persisted functions should suffice here (and the
same walk could process the "autorun" flags).

The set of ideas I am groping towards here is about getting to an embedded
development system that targets a network of processing nodes (physical and
virtual on a PC) rather than a single node. The key concept is "portable
code" or moving code around the network in "byte code" format. The basic
unit stored or moved round the network is the "engram" which is essentially
a serialised or marshalled closure (function in dump format plus runtime
values like upvalues). Each node has a simple scheduler which runs engrams
as they arrive over the network, on time schedules or in response to
hardware interrupts on the microcontroller. There is no "main" program, the
application consists entirely of event responses (scheduled engrams).

Functionality is mapped as follows:

- Application loading: Send some engrams to the node which create and
persist other engrams.
- Data persistence: Persist engrams and auto-load them on startup.
- Messaging: Send an engram from one node to another whence it gets
executed, possibly sending a response engram back.
- Realtime: Run engrams according to a schedule or on hardware interrupts.
- Multiprocessing: See Messaging!

I am still thinking these ideas through, but I do have a feeling that there
is maybe the possibility of doing something elegantly simple and yet getting
a lot of power (like with Lua itself). As a countryman of mine once said
(back in the time when educated Englishmen still spoke Latin) "Non sunt
multiplicanda entia praeter necessitate".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/9138614a/attachment.bin

Andre Carregal-2

Microcontroller Filesystem

In reply to this post by Dado Sutter

On Wed, Feb 18, 2009 at 11:35 AM, John Hind <john.hind at zen.co.uk> wrote:

> Functionality is mapped as follows:
>
> - Application loading: Send some engrams to the node which create and
> persist other engrams.
> - Data persistence: Persist engrams and auto-load them on startup.
> - Messaging: Send an engram from one node to another whence it gets
> executed, possibly sending a response engram back.
> - Realtime: Run engrams according to a schedule or on hardware interrupts.
> - Multiprocessing: See Messaging!
>
> I am still thinking these ideas through, but I do have a feeling that there
> is maybe the possibility of doing something elegantly simple and yet getting
> a lot of power (like with Lua itself). As a countryman of mine once said
> (back in the time when educated Englishmen still spoke Latin) "Non sunt
> multiplicanda entia praeter necessitate".

"Pluralitas non est ponenda sine necessitate" indeed... :o)

Are you thinking in something like actor based messaging? Or are you
talking about a lower level of interaction here?

Have you checked Noemi's work with ALua?
http://alua.inf.puc-rio.br/ftp/papers/alua_pdcs99.pdf
http://alua.inf.puc-rio.br/ftp/papers/alua_elsevier.pdf
http://alua.inf.puc-rio.br/ftp/papers/alua_sbrc02.pdf

You may also want to check Rings if having a way to mix distributed
and local nodes would be interesting. RIngs is for multiple local Lua
states, but the idea could work as a base for distribution:
http://www.keplerproject.org/rings

Finally, me and F?bio have been thinking in a way to sync distributed
repositories using some messaging protocol (maybe XMPP), would it make
sense to try something on this line of thought?

Andr?

John Hind

Microcontroller Filesystem

Thanks for those links Andre, I will need to do some detailed reading!
Certainly ALua is conceptually similar, and at about the same level of
abstraction to what I'm suggesting. However I thing the concepts I've been
developing make some improvements to the ALua model:

1. The concept of the "engram" or distributed closure packages the messaging
of a function together with the messaging of runtime variables such that the
variables are scoped local to the function at the receiving end. This seems
safer and more flexible than recreating them as global variables.

2. ALua seems to transmit functions as source strings. I am suggesting the
use of "byte codes" (I'll start calling these VM Codes as I am aware that in
Lua they are actually 32 bits!). This avoids the need to hold message
definitions as strings and to compile them more than once. Each time the
message is sent, a new closure is created from the same compiled function. I
would like to marshal tables as VM Codes also, so the message can be fully
decoded using the existing chunk reader. The messages are also (maybe)
shorter this way.

3. The concept of effectively just storing a message as a persistence
mechanism and playing it back when the processor node is restarted. (Didn't
the earliest data stores work by delaying messages?)

4. The concept of using this persistence as the sole application storage
mechanism avoids the need for a general filing system (for saving scripts
anyway) and unifies the runtime messaging architecture with the development
architecture.

I was more familiar with Rings. I do not really see the need for multiple
Lua states in the microcontroller nodes - like with ALua, a single-threaded
queued scheduler implemented in C but calling Lua event handlers seems
adequate as long as the event handlers are kept brief, and coroutines can be
used for heavier processing tasks. On PCs there would be (potentially)
multiple "virtual microcontroller" nodes working exactly the same way - each
node single threaded. This would be a "share nothing"
multiprocessing/threading model and there'd be no problem implementing these
with one OS thread or process per node.

-----Original Message-----
From: elua-dev-bounces at lists.berlios.de
[mailto:elua-dev-bounces at lists.berlios.de] On Behalf Of Andre Carregal
Sent: 18 February 2009 18:26
To: eLua Users and Development List
Subject: Re: [eLua-dev] Microcontroller Filesystem

On Wed, Feb 18, 2009 at 11:35 AM, John Hind <john.hind at zen.co.uk> wrote:

there
> is maybe the possibility of doing something elegantly simple and yet
getting
> a lot of power (like with Lua itself). As a countryman of mine once said
> (back in the time when educated Englishmen still spoke Latin) "Non sunt
> multiplicanda entia praeter necessitate".

"Pluralitas non est ponenda sine necessitate" indeed... :o)

Are you thinking in something like actor based messaging? Or are you
talking about a lower level of interaction here?

Have you checked Noemi's work with ALua?
http://alua.inf.puc-rio.br/ftp/papers/alua_pdcs99.pdf
http://alua.inf.puc-rio.br/ftp/papers/alua_elsevier.pdf
http://alua.inf.puc-rio.br/ftp/papers/alua_sbrc02.pdf

You may also want to check Rings if having a way to mix distributed
and local nodes would be interesting. RIngs is for multiple local Lua
states, but the idea could work as a base for distribution:
http://www.keplerproject.org/rings

Finally, me and F?bio have been thinking in a way to sync distributed
repositories using some messaging protocol (maybe XMPP), would it make
sense to try something on this line of thought?

Andr?
_______________________________________________
Elua-dev mailing list
Elua-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/elua-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090218/35e3b6e0/attachment.bin

Andre Carregal-2

Microcontroller Filesystem

In reply to this post by Andre Carregal-2

On Wed, Feb 18, 2009 at 5:47 PM, John Hind <john.hind at zen.co.uk> wrote:
> 1. The concept of the "engram" or distributed closure packages the messaging
> of a function together with the messaging of runtime variables such that the
> variables are scoped local to the function at the receiving end. This seems
> safer and more flexible than recreating them as global variables.

Would this be closer to Erlang then?

> 2. ALua seems to transmit functions as source strings. I am suggesting the
> use of "byte codes" (I'll start calling these VM Codes as I am aware that in
> Lua they are actually 32 bits!). This avoids the need to hold message
> definitions as strings and to compile them more than once. Each time the
> message is sent, a new closure is created from the same compiled function. I
> would like to marshal tables as VM Codes also, so the message can be fully
> decoded using the existing chunk reader. The messages are also (maybe)
> shorter this way.

Sure, this makes a lot of sense. My mention of ALua was more as a
reference of previous work, not as a direction per se.

> 3. The concept of effectively just storing a message as a persistence
> mechanism and playing it back when the processor node is restarted. (Didn't
> the earliest data stores work by delaying messages?)

This is really interesting, and it could eventually be used to restore
node state for hot swapped processors. Not an easy task depending on
the playback history... :o)

> 4. The concept of using this persistence as the sole application storage
> mechanism avoids the need for a general filing system (for saving scripts
> anyway) and unifies the runtime messaging architecture with the development
> architecture.

I agree, nice.

> I was more familiar with Rings. I do not really see the need for multiple
> Lua states in the microcontroller nodes - like with ALua, a single-threaded
> queued scheduler implemented in C but calling Lua event handlers seems
> adequate as long as the event handlers are kept brief, and coroutines can be
> used for heavier processing tasks. On PCs there would be (potentially)
> multiple "virtual microcontroller" nodes working exactly the same way - each
> node single threaded. This would be a "share nothing"
> multiprocessing/threading model and there'd be no problem implementing these
> with one OS thread or process per node.

True, and that's why I asked about Erlang up there. :o)

Andr?