[Karl] loved his mbed – a tiny little ARM-powered microcontroller platform – but he wanted an interactive programming environment. BASIC just wasn’t cutting it, so he decided to bring eLua to his mbed.
When choosing an interactive development environment for microcontrollers, you generally have two choices: old or huge. Sure, there is a middle ground with Python on an ARM, but why not use something explicitly designed for microcontrollers?
To get eLua running on his mbed, [Karl] downloaded the latest version and plopped it on his mbed. The current version, 0.9, doesn’t have support for an SD card, severely limiting its usefulness. [Karl] got around this by wiring up an SD card to the mbed, giving him gigabytes of space for all his development work.
While the AVRs and PICs of the world are stuck with languages like C or worse, the new ARM boards available are more than capable of running a complete eLua development environment, with everything accessible through a terminal. [Karl] even wrote his own editor for the mbed and he’ll shortly be working on a few dozen embedded projects he has in mind.
18 thoughts on “Bringing ELua To The Mbed”
I remember looking into eLua, but it was very resource heavy. Fitting onto the mbed, but not fitting with all of the other stuff I needed to run. Has this situation improved?
That depends on the last time you might have checked on it and what you were trying to run. We’ve gotten a slow stream of improvements in memory usage/efficiency over time (thanks Bogdan!), some of which arrived with the 0.9 release: http://www.eluaproject.net/news/elua-09-released
The NaN packing patch in particular made a 32 kB platform more usable:
The ability to read bytecode directly from flash should help too, if you pre-compile Lua code and include it in the firmware. Unfortunately that wouldn’t apply to stuff on the SD card or the flash on the MBED that shows up as mass storage since that’s on a separate chip. I believe that should work for the new write-once filesystem, but from what I see we haven’t implemented flash writing for the mbed yet.
Regardless pre-compiled code will have lower overhead in general since Lua won’t have to load the source, parse/compile that and then store the bytecode in RAM.
At the end of the day, while Lua has a pretty small footprint for what it is (parser/compiler & VM) as with any higher level language with a VM it’s always going to have some overhead and it will always be happier with more RAM.
Uhm, PICs are not limited to C.
There is PIC32 Lua http://askrprojects.net/software/pic32lua/index.html, FlashForth http://flashforth.sourceforge.net/ or you can run CP/M on PIC32 http://jaromir.xf.cz/cpm/cpm_intro.html and you can program it in BASIC, TurboPascal, C, Algol, Forth.
I almost forgot to mention retrobsd for PIC32 http://retrobsd.org/wiki/doku.php with UNIX running on PIC where you can run language you need.
I also wrote Brainfuck interpreter for PIC and port of Bitlash.
He obviously means 8-bit families. PIC32 has MIPS core and a ton of RAM, of course it can run a lot of stuff.
Would quite like eLua on my Stellaris Launchpad, would be kinda awesome. But I will stay “stuck with languages like C or worse”
“stuck with languages like C or worse”
Why is C bad? I understand that scripting languages are nice black boxes that enable code to be written quickly, but C is not a difficult to learn or use. Also, C provides a better view of memory and how things actually function than scripting languages.
Maybe some people find handy being able to write a script while connected to the platform without any external compiling. Otherwise C has no disadvantages at all.
BTW, I’m a C guy but also keep an eye on eLua. Those uber cheap ARM mcu boards you find on Ebay seem the right platform to use it with. Some are still unsupported though.
Geez, come on hackaday!
“While the AVRs and PICs of the world are stuck with languages like C or worse”
The mbed environment is C++. Hmmm… .The Arduino ‘language’ (it’s not even a dialect!) is also C++, so that must also feel like ‘being stuck’. Nope, apparently not, because it’s praised all over the place. I know I’m being a sour grape here, but I get really fed up with praising the Arduino while neglecting the merits from other systems.
“the new ARM boards available are more than capable of…”
First: the mbed shown here was released in 2009, runs at 96MHz, is based on Cortex-M3 and has hardware floating point support. This year, a new mbed-board was released, based on CortexM0+, no hardware floating point, and runs at 48Mhz (and only costs $12!). Also released this year: a CortexM0 8-pin DIP processor running at 30MHz (NXP LPC800). Of course more powerful boards are also still developed and released, but to generalize ARM is even more ignorant than generalizing ‘Atmel (tiny or xmega or ARM core?) and Microchip (PIC? dsPIC? 32-bit?)
If you’d like to start programming, and go further than a simple led string or garage door opening device, please DO look at the mbed. You’ll use the same C++ as you do in Arduino, but now with properly documented functions, consistent naming and insight in the code you’re using without having to start a second IDE.
I’ve been in this argument so often I wrote blog post about it in the past: http://www.hackvandedam.nl/blog/?p=762
Phew. I’m relieved I could get this off my chest.
It is either Cortex-M3 *OR* had hardware floating point. Never both. Of the Cortex-M series, only the Cortex-M4F has hardware floating point.
Thanks for correcting me, it is M3, and no hardware floating point….
Thanks for a voice of sanity.
I think you’re right. It’s not that microcontrollers are stuck with C, rather people using them seem stuck with C (and for no good reason, imho). I’ve been coding in C++ for micorocontrollers since I don’t remember when, using classes and templates both on ARM and AVR, and also the STL on ARM, with no problem.
as much as i love lua i dont think id ever want to use it on an mcu. for one its kind of a memory hog, try to use lua tables to build any kind of useful data structure and you will run out of ram fast. couple that with the slow clock and the lack of an fpu and you are it a world of suck.
I agree with many others – the AVRs/PICs aren’t “stuck” with any such thing.
Now I will add one thing – the PIC24’s I’ve been working almost exclusively with can *not* execute native code from RAM, and that does limit interactive development options. Compile/flash/run/debug/stop/repeat isn’t very interactive, or time-efficient; my main complaint with C. Partial recompilation, including JIT of high level languages, doesn’t seem possible in any straightforward manner. Running a bytecode language from RAM or external memory is still possible, but much slower than compiled code; so not useful for performance-critical tasks.
My ARM experience is very limited, but they seem not to have this limitation, and can execute partially or fully from RAM. Not sure about PIC32s, or any of the true AVRs (excluding Atmel ARMs) – if anyone knows I’d be interested to hear.
Chris, if you are into PIC24s, have look at FlashForth.
Its interactive and compiles directly to flash.
On Magic Lantern for Canon we run PicoC for scripting and it will be replaced wit tcc which is faster.
Speaking of embedded languages, I’d like to mention Squirrel:
It has the C-like sintax, supports classes, and doesn’t have dependencies so i was able to use it on my ARM project easily. As any embedded language, you have to understand how to interface it with native code. That’s the hardest part, but the documentation is good and i’m happy with it.
I might have to use this in my next project, just because I love the name.
“What’s it written in?”
Please be kind and respectful to help make the comments section excellent. (Comment Policy)