Micropython And C Play Together Better

Python is a versatile, powerful language but sometimes it’s not the best choice, especially if you’re doing work in embedded systems with limited memory. Sometimes you can get away with MicroPython for these cases, but the best language is likely C or assembly. If you’re really stubborn, like [amirgon], and really want C and Python to play well together, you can make use of his new tool which can bring any C library to MicroPython.

As an example of how this tool is used, a “Pure MicroPython” display driver for ILI9341 on the ESP32, which means that everything was implemented in MicroPython. [amirgon] wanted to see how the Python driver would compare to one that’s already been written in C, and use it to showcase MicroPython binding. This tool also automatically converts structs, unions, enums and arrays to Python objects, and provides a means to work with pointers which is something that Python doesn’t handle in the same way that C requires.

[amirgon] hopes that this tool will encourage the adoption of Micropython by removing the obstacle of missing APIs and libraries in MicroPython. Since most libraries for systems like these are written in C, a way to implement them in Python is certainly powerful. We featured one use case for this a while back, but this is a much more generic fix for this coding obstacle.

20 thoughts on “Micropython And C Play Together Better

  1. I just ported MicroPython to the Renesas S7G2 (ARM Cortex-m4) processor this very week. I’ve been looking for a decent GUI toolkit to go with it but haven’t found anything suitable yet. (Yes, I have framebuf working.) I may have to try this approach out on the GUIX header file to see if I can build my GUIs from Python.

    And then see if I can get MicroPython to cross build under Windows 10, which Renesas’ Synergy platform requires. :-(

    1. I’ve used GUIX on S7G2 and S5D9 a lot and also thought about implementing some interpreter to meake GUI & behavior changes controllable separately from the rest of the application but in the end couldn’t decide between mp, espruino and nodemcu.

    2. I’ve tried building under Windows myself before, your best bet might be to try and use MSYS2 although I still had issues even with that under Windows, eventually I just used a VM

      I did look into replacing the make system with scons at one point, the current make scripts seem fairly convoluted and seem to have duplication in some places, but didn’t get around to finishing it off

  2. One of the big attraction of Python to me is the large number of standard packages just an ‘import’ away. When I first tried playing with MicroPython, I was put off by everything being a statically linked package in MicroPython. In my mind, that seemed to defeat the main advantage of Python: it’s flexibility. Sure, the base language is nice but it’s not anything special.

    But that was two years ago. Now the build system is a LOT cleaner. It’s easy for me to include by Python code via ‘freeze’. And my S7 port is looking for import packages in the LFS filesystem. (I haven’t put any there yet so I’m not entirely sure it’ll load them. Should be able to load Python files anyway.) So I think Im close to having a “real” Python implementation running on my ARM m4.

    But don’t hold your breath for Numpy anytime soon!

  3. I’m the weirdo that wishes Lua really took off to handle these situations. I got sick of using all those Python libraries and eventually just started rolling my own in Lua. For me, Python is the overly-bloated dynamic equivalent of C++. And like C++ apps, Python apps usually come burdened with an unholy amount of dependancies. But, the masses have spoken, and as a whole they prefer languages with everything and the kitchen sink thrown in.

    1. Yeah, Lua is a pretty nifty tool, first and foremost and extension language you can embed into your application. The performance of LuaJit is really amazing; that’s some really fine work done in that platform. Much of the optimization done by that JIT compliter is easier to perform when the language doesn’t have a many corner cases (e.g., Javascript).

    1. I wonder why Zerynth never got the spotlight uPy enjoys? Seems to be a technically superior product. My guesses are 1.) Not memorable name. Perhaps picoPython would have been better? When I go to search for it the name does not come top of mind. I actually first think of Viper. 2.) Not open source. Though Z licenses are cheap, free does beat cheap. Arguably though the company is likely earning more than the company who created microPy. So that’s good for them.

      With the ability to import C libraries the competitive advantage of Zerynth is diminishing.

    2. With Zerynth, can you define structs in C and use them in Python in a convenient way? (create a struct instance “x” and access a netsted field with x.f1.f2) .

      I got the impression that Zerynth only allows calling C functions, and also requires these function to have a special prototype, so if you want to migrate a large library you have to wrap every function in it one by one, much like Micropython’s way of adding an external module (https://micropython-dev-docs.readthedocs.io/en/latest/adding-module.html)

Leave a Reply to Bill FlynnCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.