MicroPython & pic32

After getting MicroPython to run on Pico]OS in MSP432 Launchpad environment, there was a next step I absolutely had to take: See if the same system would work on Microchip PIC32.

I’m using the free version of XC32 compiler, which comes with it’s own runtime library. It is rather complete, ie. has stdio streams with similar idea for low-level device integration as newlib has on Arm environments. But to simplify things for now, I left file input/output out from the build.

After compiling with -O1 the resulting binary size is:

text     rodata    data   bss     dec      hex   filename
148960   28736     220    7324    185240   2d398 mp-test.elf

The free XC32 version doesn’t allow optimization with -O2, so the resulting binary is larger than it could be with a proper compiler.

Unfortunately I have currently only PIC32 chips with 128 Kb of flash available now, so this won’t fit into them. But MPLAB X has a simulator, which can be used to run the resulting binary. And here it is:


I’ll have to get some bigger PIC32MX chips to try this out with real hardware. I think that PIC32MX270F256B might be a nice choice, it has 256 Kb of flash and 64 Kb of ram and is available in DIP28 package!

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


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.

MSP432 LPM3 (deep sleep) mode

I got MSP432 LPM3 mode (deep sleep) working. Actually everything else was OK, but it seems that RAM retention was not enabled by default. After adding


to startup things look much better (obviously, as RAM contents was lost before). I was able to run Pico]OS test application with EnergyTrace+ monitoring enabled:

CPU states


This shows that CPU is spending about 5 seconds in active mode and 5 seconds in sleep, which looks what one would expect from this application.

Power usage


When looking at power graph it is possible to see that HZ is 1 second, there are short spikes when WDT interrupt that drives Pico]OS clock is processed.

Overall energy statistics
Overall energy statistics

Overall statistics show that about half of time is spent in active mode. However, almost 70% energy is used in active mode, mainly because it turns the led on.


MSP432 launchpad

msp432_launchpadsI think that Texas Instruments MSP430 family is really nice low-power MCU for all kinds of projects. After finding out that TI has released new MSP432 chip, which has Cortex-M4 CPU, I had to order the launchpad board as soon as it was available. After receiving boards a few days ago, I have been experimenting with Pico]OS Cortex-M port on those boards.

MCU has similar peripherals as older 16-bit MSP430 family, also documentation is similar so it was easy to get started with it. I usually like to use Eclipse CDT with MCU work, but I figured that it might be easiest to use TI CCS for starters (as it was unclear to me if OpenOCD would work with this board).

I had some problems with board resetting after I loaded by application into it, but that turned out to be the WDT resetting the chip because it took too long before execution hit “main” (which would have disabled the watchdog). I got this fixed by disabling watchdog very early in Reset_Handler.

I now have Pico]OS running on the board, along with serial console provided with eUSCI peripheral. I ended up in using MSP432 driverlib (BSD licensed version), which also contains CMSIS headers (which is really nice as it made working with existing code much easier).

I still have to work with LPM3 (or DEEPSLEEP in arm terminology). I tried to implement Pico]OS clock tick by WDT, but doesn’t want to keep running reliably in LPM3 mode.

There is a simple blinky example at github.


Pic32 port for Pico]OS

When I started toying with microcontrollers several years ago, I kind of ignored Microchip’s PIC family completely. I think it was 8-bit stuff only those days. Although having some history with 8-bit Z80 in my early years, my real job with 32/64-bit unix servers made me look for something “bigger”, which lead me to the LPC2000 series from Philips (NXP today).

But when NPX released some Arm Cortex-M0 chips in hobbyist-friendly DIP packages they made me look around what else might be available in similar packages. I knew about PIC32MX family from Microchip before, but wasn’t really interested in it, because I thought that Arm Cortex-M stuff would dominate the world (maybe it will, maybe not). But breadboarding is really nice during prototyping and PIC32MX chips in DIP packages have much more flash and ram than those offered by NXP. Continue reading “Pic32 port for Pico]OS”