MicroPython Forum (Archive)

Is there any support for SWIG or similar wrapping mechanism?

Not that I've seen.

My experience with using SWIG on other projects is that it adds considerable overhead.

I agree with dhylands, so don't think that will be a direction where MicroPython project itself goes any time soon. But as MicroPython usage grows wider, exploring that direction would be an interesting digression - it doesn't have to be too optimal, but can be a useful tool for quick prototyping or reusing existing code. So, whoever has interest in it, don't hesitate to follow it and share your experiences!

The platform I'm using upy on has this GUI API in C++. I found myself repeating wrap patterns.

SWIG may add overhead but native GUI should still perform better than other python based approaches, I think.

Perhaps I could check how much effort is needed to modify SWIG to support generating code compatible with upy.

Just learnt there are a handful of wrappers out there: SWIG, Boost.Python, SIP... Here is an interesting summary:

http://stackoverflow.com/questions/1492 ... comparison#

http://intermediate-and-advanced-softwa ... pping.html

The line I think works best is using SWIG's XML output and write a generator that reads such XML and outputs C module. Like what was done by this project: https://github.com/ffi/ffi-swig-generator

Great article: http://szelei.me/code-generator/

I had to make a small adjustment to have access to macros:
Works very well. Now I just need to master module creation. Any one willing to help?

To create a micropython module, take a look at:
https://github.com/micropython/micropyt ... #L476-L480

This defines the module. The MP_QSTR_machine is the qstr for the string "machine" and comes from a line that looks like: from a qstrdefs.h file.

If you're going to be generating them, then you'll probably want to create a new file (https://github.com/micropython/micropyt ... ke-pins.py generates a bunch of source files and also generates build-PYBV10/pins_qstr.h

pins_qstr.h gets included into the build by this line: https://github.com/micropython/micropyt ... kefile#L16

You'll then need to create a module dictionary: https://github.com/micropython/micropyt ... #L421-L474 which will contain str's for the keys, and python objects for the values.

If you do: then you'll see the strings that the above link points to.

You'll need to add a reference to the module in mpconfigport.h https://github.com/micropython/micropyt ... ort.h#L102

and add it to builtin modules: https://github.com/micropython/micropyt ... ort.h#L118
and also constants (if it define these): https://github.com/micropython/micropyt ... ort.h#L142

and add it into the build by adding it to the Makefile:
https://github.com/micropython/micropyt ... efile#L140

igorgatis wrote:Works very well.

Care to post what exactly you did, and post an example of the output?

dhylands: this is great documentation. Thanks a lot.

stijn: I wrote a very simple python program which output most of the "important" stuff from .h file I want to create a module for. It prints function names, typedefs and even "enums" built with #define (PARSE_DETAILED_PROCESSING_RECORD required). I'll publish my code as soon as I have a minimal working version.

See also http://forum.micropython.org/viewtopic.php?f=15&t=200 . And mind that a standalone tool to deal with clang stuff (c2ffi), instead of interfacing to it from Python, was done for a reason - LLVM/Clang is known to be very breaky project. Over time I watch it (few years), I saw at least couple of Python binding going out of maintenance (because it's just hard to maintain with all the breaky changes!).

Otherwise, it's possible choice, already tried with MicroPython, as that thread shows. There're other approaches too. For example, having tried the above, I'd now find it interesting trying to implement CPython API in terms of MicroPython's - too see how far that can go at all. Other approach is just to provide some manual, but simplified API for wrapping function - most realistically, "simplification" would require C++ usage, as e.g. Boost.Python does.

So, there're many choices, and to see what's more viable, various choices need to be tried.