Re: Lua on Microcontrollers

[Bogdan Marinescu <bogdan.marinescu@...>]

On Tue, Dec 10, 2013 at 8:11 PM, Doug Currie <doug.currie@gmail.com> wrote:

On Dec 10, 2013, at 5:48 AM, John Hind <john.hind@zen.co.uk> wrote:

> I have been wondering how difficult it would be to modify the Lua memory allocator so it could split the Lua State between Flash and RAM. This way, most of the less volatile memory such as strings, function bytecodes and library tables could be located in more plentiful flash memory reserving RAM for what really needs it.

See: http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html

for a description of the eLua LTR (Lua Tiny RAM) patch. It implements ROM based

        • lightfunctions: these are "simple" functions, in the sense that they can't have upvalues or environments. They are just pointers to regular C functions. Other than that, you can use them from Lua just as you'd use any other function.

        • rotables: these are read-only tables, but unlike the read-only tables that one can already implement in Lua with metamethods, they have a very specific property: they don't need any RAM at all. They are fully constant, so they can be read directly from ROM.

I will refactor the LTR patch in the context of Lua 5.2, which provides something similar to "lightfunctions", implemented much more elegantly. And then move on to other optimizations.

About memory, 2M or even 1M of RAM is enough to implement quite a bit of functionality with eLua. And there are also MCUs that can work with SDRAM memory:

http://www.embeddedartists.com/products/boards/lpc4088_qsb.php

That thing has 32M of SDRAM, which is more than enough for any embedded Lua application that I can think of.

And there is also this:

http://am.renesas.com/products/mpumcu/rz/rza/rza1/index.jsp

All in all, internal RAM is evolving in the correct direction for eLua.

Best,

Bogdan

 

e