 |
lua-l archive |
|
|
||
|
On Tue, Dec 10, 2013 at 11:13 PM, Tony <luatony@gmail.com> wrote:
Hi John,On Tue, Dec 10, 2013 at 2:48 AM, John Hind <john.hind@zen.co.uk> wrote:
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.
I have some skepticism the MicroPython developer can really deliver on all of his promises. Full Python 3.3 compatibility in 192K SRAM / 1024M flash (including the interpreter)? At least he's not including networking (the uPy board only has USB). Near C-like speed? (At least he add some qualifies: with <31-bit integers in tight loops). Easy to port all the libraries?I had a couple of chats of Damian (the author of MicroPython) and he _really_ knows what he's doing. If the code is properly written, it can emit assembler code instead of Python VM instructions (somewhat similar with how LISP code with proper attributes can be compiled to machine code), which speeds up things quite a bit. He even has a nice implementation of an in-line assembler. His code is really good. About "easy to port all libraries" ... this is a different story. Inevitably, some of the desktop libraries will be impossible or very hard to port. But as far as Python on MCUs goes, I don't think it gets much better than MicroPython.
Best,Bogdan
To be fair, if he delivers only a part of what he promises, it'd still be a useful project -- and I'm very tempted to back it to check out the reality, and compare the results with eLua (although the closest eLua board I currently have is a L3S9B95 -- I'll probably have to budget for a STM32F4 Discovery or Olimex board).--Tony---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com