Python & LUA for Pico]OS

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):

poslua1

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:

picopython

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.

Ari Suutari

Father of three 🙂
{ Electronics | Music | Computer | Motorbike } hobbyist.
Factory IT professional.
FreeBSD since day one.

Facebook LinkedIn  

4 Replies to “Python & LUA for Pico]OS”

  1. Nice article. Just to clarify, for MicroPython, size of .bss largely depends on how you make a particular port rather than on MicroPython itself. You can try to build “minimal” port in the uPy distribution and see that it takes 2.5K of BSS. And looking into produced map file, you’ll see that 2K of that is statically configured heap. (So, remaining 0.5K is “hard” size of what uPy requires, you can configure heap dynamically, etc.)

  2. Actually, the .bss size comes largely from Pico]OS as my configuration settings for it were not really tuned at all (16 tasks, 32 priorities, etc.). That results in about 4K bss, however it can be tuned down a lot (smallest configuration I have been able to run is 3 tasks on 0.5 kb MSP430 launchpad). MicroPython’s bss data from my mp_main.o is about 2.3K, and it comes from statically configured heap mostly. I was really surprised that it is possible to have so slim python, quite a small snake indeed 🙂

  3. Really great to see MicroPython being used in more projects! A shame that the build system was difficult for you. It’s not supposed to be hard to build, since it really is just a bunch of C files. The only exception is that you need to generate the interned-string header file using the makeqstrdata.py script, and the version header file using makeversionhdr.py. I intend on streamlining the build system so these steps are easier.

    1. I didn’t think that the build system of MicroPython was bad in any way. There was just this unfortunate conflict with BUILD variable (a directory for MicroPython Makefile and RELEASE/DEBUG knob for Pico]OS).

      I didn’t want to copy-paste parts of MicroPython Makefiles into my project, because that might make tracking of future development in MicroPython harder.

      Although current approach is not the simplest one, it is pretty easily maintainable and doesn’t add much to build times. And it is kind of native to both worlds 🙂

      I wrote yesterday evening first (simple) extension modules for MicroPython, which are just enough to be able to implement ‘blinky’ so that it uses posTaskSleep() from RTOS.

      So this is all very nice. The only wish I have would be possibility for concurrent RTOS threads to access the python environment safely.

Comments are closed.