Why would someone want to run an interpreted scripting language on a real time system ?
Well, most tasks must be executed in real time with predictable behaviour. But modern systems tend to have user interfaces and communication (TCP/IP for example) to other systems, which really don’t need hard realtime stuff. If those tasks can be developed in Python or LUA instead of C or C++ one will sure see a boost in development agility and speed.
I really wanted to use Python for scripting language, as it is the language of choice for my Unix development activities. However, when browsing around, I stumbled upon LUA which seemed easier to port to Pico]OS than the stuff at Python.org. So I started with it.
First, I needed more standard C runtime environment because Pico]OS didn’t provide things like stdio streams in it. All my microcontroller ports which have chips big enough for scripting languages use newlib (or newlib-nano) currently (well, PIC32 uses it’s own library, but it isn’t too different from newlib). Newlib provides stdio stuff and integrates nicely to underlying operating system by some syscalls, which I added to picoos-micro library.
After that, compiling LUA 5.3.0 distribution was quite easy. I added also simple modules that were necessary for ‘blinky’ application, ie. posTaskSleep() is available as pos.task.sleep() and GPIO ports can be controller by gpio class.
Here is the result (on Texas Instruments MSP432 launchpad):
After running simple loop to blink led, 62% of system heap was used. So more than half of RAM was used by LUA, which is quite a lot (many boards I have used have less RAM than 64Kb of launchpad). I noticed that there is a patch for LUA (LTR = Lua Tiny RAM), but it was for older version, so I didn’t bother with it (yet). Size information from optimised build is:
text data bss dec hex filename 132840 232 4424 137496 21918 lua-test.elf
Both picoos-lua library and test application are available at Github.
After completing work with LUA, I was pointed out about the existence of MicroPython project, which seemed as much more embeddable project than “big” python. I had some trouble with it’s build system, as both Pico]OS and MicroPython have Makefile frameworks that can be used to build things. Unfortunately, there was a conflict with at least BUILD variable in Makefiles. After some tinkering I ended up with a system that builds MicroPython in three steps. First, Pico]OS makefiles are used to figure out build directories and compiler flags. Second, MicroPython makefiles are used to compile it into object files, using flags from first step. Third, Pico]OS makefiles are used to build a library from object files created by previous step. This results in a nice module that can be included into Pico]OS applications in same way as other modules.
To be able to test things out, I created a small test application by taking pieces of code from minimal and unix MicroPython ports (this test application is very unpolished now, as I just wanted to see how well things would work, if all).
Today I got it running on TI Launchpad:
Very nice ! Only 14% of heap used with simple loop test (but data segment is a about 2.5 Kb bigger). To be fair to LUA, one must remember that this test didn’t have posTaskSleep() nor GPIO integrated into it (but that would be only a small amount of code, however). Size information from build is:
text data bss dec hex filename 107560 104 7120 114784 1c060 mp-test.elf
Both picoos-python library and test application are available at Github.
Now I have two different scripting languages that can be used to implement non-critical parts of a real time system. To be able to put together something meaningful, I’ll have to integrate picoos-net and picoos-ow libraries to either of these environments.
