 |
lua-l archive |
|
|
||
|
This is interesting:
http://micropython.org/
If only it was Lua! I know there has been some work on this sort of thing (i.e. http://www.eluaproject.net/) but nothing as elegant as this hardware implementation of Python. Just plug it into any USB host computer and edit the scripts as if on a flash drive, whilst a virtual com port gives you a console channel over the same USB.
The main issue for these single chip systems is RAM - typically at the highest end you are working with 100-200KiB of RAM and 1-2MiB of Flash. This is plenty for a basic "bare metal" Lua implementation running a test script, but not enough RAM to do really serious work. Problem is there is a huge complexity step between the top end of on-chip RAM and boards with separate RAM chips such as the Raspberry Pi and Beaglebone Black - the RAM interface requires a lot of chip pins reducing the IO availability, and much more complex PCB routing. In practice a large RAM approach only becomes cost effective with very big production runs.
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. Damian George (of MicroPython) has a very clear view of the priorities:
"When design decisions were made, the first priority was to minimise RAM usage, then minimise code size, and, finally, to execute quickly."
I realise that Lua was not designed with precisely these priorities, but neither was Python. I'm interested in views of the feasibility of adapting Lua in the same direction that Damian has adapted Python.
- John Hind.
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com