This is a demonstration project which shows how to create a low-level Native C Module and provide a high-level MicroPython interface module which uses that.
There are five files included -
'stringmath.c' - This is our low-level C code which can be called from the user's MicroPython code which will perform maths on integers and return an integer result. This library is compiled to '_stringmath.mpy' which has to be copied to the target device's file system.
'stringmath.py' - This is our high-level MicroPython library which can be called from the user's MicroPython code which allows maths to be performed on integers expressed as strings and returns a string result. This library has to be copied to the target device's file system.
'stringmath_test.py' - This is a MicroPython user program which proves the 'stringmath.py' library is working along with the underlying '_stringmath.mpy' library. Both 'stringmath.py' and '_stringmath.mpy' must be copied to the target device's file system before the program will run successfully.
'Makefile' - This is the file used by 'make' to turn 'stringmath.c' into '_stringmath.mpy'. Note that running 'make' will create a 'build' directory which does not need to be retained.
'README.txt' - The documentation.
To test the project -That should result in the following output -In this project the functionality of 'stringmath.py' could be moved into '_stringmath.c' because converting strings to integers and vice-versa is not particularly difficult in C and there are even standard C library functions provided to do exactly that.
However, such functions are not always available to Native C Modules and you would then have to implement those functions yourself.
This is also the case for some in-built standard C library functions as seen in the 'stringmath.c' source. The usually invisible functions which division and modulo use need to be explicitly specified. You can comment those out and run 'make' to see what happens when not included.
Thus it is usually preferable to have a MicroPython module between the user code and the Native C Module as it allows more complicated things to be done in the higher-level MicroPython module than in the Native C Module itself.
There may be ways to allow a Native C Module to use standard library functions beyond what are available but I haven't pursued doing that myself; that is an adventure I am leaving to others.
My bottom line advice is to keep your Native C Module code as simple as possible and keep more complicated stuff in the higher level MicroPython module. Most end-users won't notice the difference.
You may also note that in the 'Makefile' it says "ARCH = armv6m" which suggests it is creating a '.mpy' for an RP2040-based MicroPython. The generated '.mpy' file does run on my RP2350B so I am not sure what it should be. That is also an adventure I am leaving to others.
If you have any questions, need help, or identify any issues then please do let me know.
There are five files included -
'stringmath.c' - This is our low-level C code which can be called from the user's MicroPython code which will perform maths on integers and return an integer result. This library is compiled to '_stringmath.mpy' which has to be copied to the target device's file system.
'stringmath.py' - This is our high-level MicroPython library which can be called from the user's MicroPython code which allows maths to be performed on integers expressed as strings and returns a string result. This library has to be copied to the target device's file system.
'stringmath_test.py' - This is a MicroPython user program which proves the 'stringmath.py' library is working along with the underlying '_stringmath.mpy' library. Both 'stringmath.py' and '_stringmath.mpy' must be copied to the target device's file system before the program will run successfully.
'Makefile' - This is the file used by 'make' to turn 'stringmath.c' into '_stringmath.mpy'. Note that running 'make' will create a 'build' directory which does not need to be retained.
'README.txt' - The documentation.
To test the project -
Code:
cd ~/somewhereunzip stringmath-2025-08-26.zipmakempremote fs cp stringmath.py :mpremote fs cp _stringmath.mpy :mpremote run stringmath_test.pyCode:
5 + 3 = 85 - 3 = 25 * 3 = 155 / 3 = 15 % 3 = 2However, such functions are not always available to Native C Modules and you would then have to implement those functions yourself.
This is also the case for some in-built standard C library functions as seen in the 'stringmath.c' source. The usually invisible functions which division and modulo use need to be explicitly specified. You can comment those out and run 'make' to see what happens when not included.
Thus it is usually preferable to have a MicroPython module between the user code and the Native C Module as it allows more complicated things to be done in the higher-level MicroPython module than in the Native C Module itself.
There may be ways to allow a Native C Module to use standard library functions beyond what are available but I haven't pursued doing that myself; that is an adventure I am leaving to others.
My bottom line advice is to keep your Native C Module code as simple as possible and keep more complicated stuff in the higher level MicroPython module. Most end-users won't notice the difference.
You may also note that in the 'Makefile' it says "ARCH = armv6m" which suggests it is creating a '.mpy' for an RP2040-based MicroPython. The generated '.mpy' file does run on my RP2350B so I am not sure what it should be. That is also an adventure I am leaving to others.
If you have any questions, need help, or identify any issues then please do let me know.
Statistics: Posted by hippy — Tue Aug 26, 2025 3:20 pm — Replies 6 — Views 200