[ANN] eLua (Lua for microcontrollers) 0.7 released

eLua is an effort to expand the presence of the Lua programming
language in the embedded world, especially on MCU platforms. It is
meant to be a complete MCU development environment. It currently runs
on a number of ARM variants, as well as Cortex and AVR32 (and i386 as
a proof of concept). Version 0.7 was just released, this is the
changelog:

* Compiling eLua under Windows is now officially supported
* Added LuaRPC (remote procedure calls in the embedded world)
* Added generic and portable SD/MMC Card FAT File System support
* New shell cat/type command, lists text file contents
* New ROMFS build modes: compress and compile
* Added support for Olimex STR-E912 board
* Added the STR9 platform specific pio module
* Added Robert Jakabosky's EGC (Emergency Garbage Collector) patch to eLua
* Added support for the PUC-Rio eLua board, NXP LPC2468 MCU
* Added basic CAN module
* New full CSS based site/doc menu
* More portuguese content translations
* ADC module doc enhancements
* More tutorials and general doc enhancements

You can find all the project documentation at http://www.eluaproject.net
Start a New Thread

I don't mean to be rude, but why would anyone want to consider Lua or eLua? I took a brief look at the info available (again) and I still don't get what it has to offer. Most of the statements about it are generalizations like, "fast", "small" with no real info.

One of the reference sites has a poster saying Lua fits into either 128 kB ROM and 64 kB RAM or 256 kB ROM and 64 kB RAM. The targets I am interested in don't have that sort of memory available. Will eLua support small embedded targets with 32 kB Flash and 8 kB RAM?

Rick
--- In A..., Bogdan Marinescu wrote:
>
> eLua is an effort to expand the presence of the Lua programming
> language in the embedded world, especially on MCU platforms. It is
> meant to be a complete MCU development environment. It currently runs
> on a number of ARM variants, as well as Cortex and AVR32 (and i386 as
> a proof of concept). Version 0.7 was just released, this is the
> changelog:
>
> * Compiling eLua under Windows is now officially supported
> * Added LuaRPC (remote procedure calls in the embedded world)
> * Added generic and portable SD/MMC Card FAT File System support
> * New shell cat/type command, lists text file contents
> * New ROMFS build modes: compress and compile
> * Added support for Olimex STR-E912 board
> * Added the STR9 platform specific pio module
> * Added Robert Jakabosky's EGC (Emergency Garbage Collector) patch to eLua
> * Added support for the PUC-Rio eLua board, NXP LPC2468 MCU
> * Added basic CAN module
> * New full CSS based site/doc menu
> * More portuguese content translations
> * ADC module doc enhancements
> * More tutorials and general doc enhancements
>
> You can find all the project documentation at http://www.eluaproject.net
>

Start a New Thread

> I don't mean to be rude, but why would anyone want to consider Lua or eLua?
> I took a brief look at the info available (again) and I still don't get what
> it has to offer. Most of the statements about it are generalizations like,
> "fast", "small" with no real info.
>

Well, you have a full programming language running directly on your MCU, and
the whole development cycle becomes much faster (and easier, if you consider
debugging, for example). You write your programs on the PC, and then you can
run and test them on the hardware in no time. Also, you can fire the
on-board Lua interpreter, then write and run code directly. The hardware is
already hidden behind easy to use Lua modules (with a well documented API).
If you are a hardcore C progammer, I can understand why you don't get this.
But not everyone is a hardcore C programmer :)

One of the reference sites has a poster saying Lua fits into either 128 kB
> ROM and 64 kB RAM or 256 kB ROM and 64 kB RAM. The targets I am interested
> in don't have that sort of memory available. Will eLua support small
> embedded targets with 32 kB Flash and 8 kB RAM?
>
Maybe, but not anytime soon.

Best,
Bogdan

--- In A... , Bogdan Marinescu
> wrote:
> >
> > eLua is an effort to expand the presence of the Lua programming
> > language in the embedded world, especially on MCU platforms. It is
> > meant to be a complete MCU development environment. It currently runs
> > on a number of ARM variants, as well as Cortex and AVR32 (and i386 as
> > a proof of concept). Version 0.7 was just released, this is the
> > changelog:
> >
> > * Compiling eLua under Windows is now officially supported
> > * Added LuaRPC (remote procedure calls in the embedded world)
> > * Added generic and portable SD/MMC Card FAT File System support
> > * New shell cat/type command, lists text file contents
> > * New ROMFS build modes: compress and compile
> > * Added support for Olimex STR-E912 board
> > * Added the STR9 platform specific pio module
> > * Added Robert Jakabosky's EGC (Emergency Garbage Collector) patch to
> eLua
> > * Added support for the PUC-Rio eLua board, NXP LPC2468 MCU
> > * Added basic CAN module
> > * New full CSS based site/doc menu
> > * More portuguese content translations
> > * ADC module doc enhancements
> > * More tutorials and general doc enhancements
> >
> > You can find all the project documentation at http://www.eluaproject.net
> >
> Start a New Thread

Thanks for the reply. I think I get it. No, I'm not hardcore C... I am looking at using a very lean tool called Forth. I am told that I can put a full compiler on my target in 16 kB and can run tethered in 8 kB. I've yet to give it a full tire kick, but when time allows, I plan to push it to the max.

Rick
--- In A..., Bogdan Marinescu wrote:
>
> > I don't mean to be rude, but why would anyone want to consider Lua or eLua?
> > I took a brief look at the info available (again) and I still don't get what
> > it has to offer. Most of the statements about it are generalizations like,
> > "fast", "small" with no real info.
> > Well, you have a full programming language running directly on your MCU, and
> the whole development cycle becomes much faster (and easier, if you consider
> debugging, for example). You write your programs on the PC, and then you can
> run and test them on the hardware in no time. Also, you can fire the
> on-board Lua interpreter, then write and run code directly. The hardware is
> already hidden behind easy to use Lua modules (with a well documented API).
> If you are a hardcore C progammer, I can understand why you don't get this.
> But not everyone is a hardcore C programmer :)
>
> One of the reference sites has a poster saying Lua fits into either 128 kB
> > ROM and 64 kB RAM or 256 kB ROM and 64 kB RAM. The targets I am interested
> > in don't have that sort of memory available. Will eLua support small
> > embedded targets with 32 kB Flash and 8 kB RAM?
> >
> Maybe, but not anytime soon.
>
> Best,
> Bogdan
> --- In A... , Bogdan Marinescu
> > wrote:
> > >
> > > eLua is an effort to expand the presence of the Lua programming
> > > language in the embedded world, especially on MCU platforms. It is
> > > meant to be a complete MCU development environment. It currently runs
> > > on a number of ARM variants, as well as Cortex and AVR32 (and i386 as
> > > a proof of concept). Version 0.7 was just released, this is the
> > > changelog:
> > >
> > > * Compiling eLua under Windows is now officially supported
> > > * Added LuaRPC (remote procedure calls in the embedded world)
> > > * Added generic and portable SD/MMC Card FAT File System support
> > > * New shell cat/type command, lists text file contents
> > > * New ROMFS build modes: compress and compile
> > > * Added support for Olimex STR-E912 board
> > > * Added the STR9 platform specific pio module
> > > * Added Robert Jakabosky's EGC (Emergency Garbage Collector) patch to
> > eLua
> > > * Added support for the PUC-Rio eLua board, NXP LPC2468 MCU
> > > * Added basic CAN module
> > > * New full CSS based site/doc menu
> > > * More portuguese content translations
> > > * ADC module doc enhancements
> > > * More tutorials and general doc enhancements
> > >
> > > You can find all the project documentation at http://www.eluaproject.net
> > >
> >
> >
>

Start a New Thread

On Thu, Jan 21, 2010 at 12:49 AM, Dan Lyke wrote:

> On Wed, 20 Jan 2010 23:25:02 +0200
> Bogdan Marinescu >
> wrote:
> > Also, you can fire the on-board Lua interpreter, then write and
> > run code directly.
>
> So, silly question: Does this also include a small editing environment
> (ie: line editing, or an object/code store of some sort)? I almost
> always end up with some sort of little home-grown scripting language to
> tie a bunch of hardware test sequences together with slightly different
> parameters (ie: let's try that again using this input sequence and
> these different motor acceleration ramps), and last time I was doing
> that I was very close to tossing a small BASIC environment on the board
> because I wanted to be able to save and load these command sequences.
>

I understand your scenario very well. And the answer is no. we don't really
have an on-board editor. You just fire up the Lua interpreter and write
commands from there, but you can't recall lines, or do anything else more
complex than writing and erasing characters as a matter of fact :) However,
we do have some use scenarios that might cover your needs:

1. RPC (Remote Procedure Call): you write your Lua programs on the PC, and
they run on the PC, but you can also easily execute code on the eLua board
(connected to the PC, of course) via a well integrated RPC mechanism. For
example, suppose you run this program on the PC:

local pio = remote.pio
pio.setpin( pio.P0, 0) -- the "pio.setpin" call will actually run on the
eLua board (via RPC) and will set P0.0 to logical 1

2. remote file system (not officially released yet, but already running
properly): you use a program on the PC to "share" a directory on the PC. On
the eLua board (connected to the PC) you have a special file system, the
"remote file system", which acts just like a regular filesystem, except it
redirects all the calls to the PC. For example, if you do this on the board:

local f = io.open( "/rfs/test.lua", "rb" )

you'll actually open the /test.lua file on your PC. Of
course, all the other file operations (read, write, close, seek ...) will
also be redirected. And, of course, you can easily edit the files from the
shared directory on your PC. Very helpful for developing.

3. write your test programs on a FAT formatted SD card, plug it in the eLua
board, and simply execute "lua /mmc/test.lua" :) Not as convenient as the
rfs for developing, but still OK.

Hope this answers your question. FYI, I actually wrote a small on-board
editor for eLua at some point, and also disconnected the eLua board from the
PC completely by attaching a PS/2 keyboard and a graphical LCD to it. It
felt very nice to program without any PC connection using the on-board
editor, but in the end I came to the conclusion that it's simply not worth
it. A text editor running on a microcontroller is very limited in
functionality, and in my experience this starts to show sooner or later.
I'll probably release the code of the editor at some point, but I seriously
doublt it will catch on.

Best,
Bogdan
>
> Type a string, let a 5 minute operation run, type another string and if
> you get it wrong you have to start from scratch is a pain in the tail.
> Even when copying and pasting from a host terminal. And often I'll have
> an SD card buried somewhere in the machine so I've got plenty of
> storage, it's just a pain to pull it out, mount it on another machine
> and so forth.
>
> Dan
>
> Start a New Thread

On Wed, 20 Jan 2010 23:25:02 +0200
Bogdan Marinescu wrote:
> Also, you can fire the on-board Lua interpreter, then write and
> run code directly.

So, silly question: Does this also include a small editing environment
(ie: line editing, or an object/code store of some sort)? I almost
always end up with some sort of little home-grown scripting language to
tie a bunch of hardware test sequences together with slightly different
parameters (ie: let's try that again using this input sequence and
these different motor acceleration ramps), and last time I was doing
that I was very close to tossing a small BASIC environment on the board
because I wanted to be able to save and load these command sequences.

Type a string, let a 5 minute operation run, type another string and if
you get it wrong you have to start from scratch is a pain in the tail.
Even when copying and pasting from a host terminal. And often I'll have
an SD card buried somewhere in the machine so I've got plenty of
storage, it's just a pain to pull it out, mount it on another machine
and so forth.

Dan
Start a New Thread