Developing MicroPython libraries for different boards

[jimako]

Hello. First post and my first reaction is hats off to the admins for choosing such original captcha!

I would like to write contribute to the MicroPython community by authoring some libraries for components I use. I would like to ask for advise on how to write libraries which can be extended to the different microcontrollers that MircoPython is available for. For example, I am using ESP8266 but I would like to make it easy for people to extend the library for other boards.

Is there a standard way to do this? I am not a programmer by trade so please share your knowledge.

Thank you.

[deshipu]

This is an excellent question, and I'm afraid that at the moment the answer is "we are still figuring out how to do it".

Personally I spent considerable time porting some of the libraries/drivers originally written for pyboard in such a way, that they may work on other boards (for example on the ESP8266), and I also wrote a dozen or so new drivers, trying to invent and follow good practices for them. They are all going to break following the nearest release, and I'm not sure I will have the time and energy to update them and their documentation to reflect the changes.

So my personal advice would be "check back in a year".

[pythoncoder]

On the other hand a contribution is surely better than no contribution Say @jimako posts a Python driver for a bit of hardware but it only runs on the ESP8266. If you or I wanted to use it on the Pyboard we'd fix it far quicker than writing it from scratch. I believe in "post early and post often" rather than waiting for perfection. This can be like waiting for Godot...

Some of the drivers I wrote don't follow what I now know to be "best practice". But it doesn't stop them working. And it's a dilemma whether or not to fix them thereby breaking user code.

[jimako]

Thank you both for your replies.

Yes it would be useful to have a "template" for publishing code that is easily portable between boards. I saw this LCD library (https://github.com/demestav/python_lcd) which decouples the boards from the core logic of the LCD screen communication, and I was wondering if this was standard practice. I have to admit it was somewhat hard for me to follow the __init__ part but after a while I was able to port this to the nodemcu/ESP8266 board successfully. I think this is my first contribution to MicroPython (?) but my pull is not yet accepted .

@pythoncoder I would be more that happy to contribute to the project. My only concern is the correctness/pythonicness (!) of my code, as I am not a professional programmer. In fact, last night I wrote a library which I will post in a minute on another thread (viewtopic.php?f=16&t=2814) for your feedback. I am not posting it here to keep this thread relevant.

Thank you.

[wminarik]

In order to have a common code base across a number of different boards using the SAMD21 processor, Adafruit seems to have decided to make a permanent fork of MicroPython. In this fork they've depreciated the machine module, and implemented two modules for hardware abstraction (board and microcontroller) and two for common code (nativeio and bitbang). Initially this fork will only be for SAMD21 boards, with their ESP8266 boards supported in the future.

Code written for the master MicroPython trunk will have to be modified to run on Adafruit's version.

Documentation is at: http://tannewt-micropython.readthedocs. ... ontroller/

[dhylands]

Yes it would be useful to have a "template" for publishing code that is easily portable between boards. I saw this LCD library (https://github.com/demestav/python_lcd) which decouples the boards from the core logic of the LCD screen communication, and I was wondering if this was standard practice.

I wrote the original. If I know that a piece of code will be reused then I try to factor it out. It does tend to use a bit more memory, but it means that if you find a bug in the core portion, then it gets fixed for all "clients". If you wanted to make things more compact, you could combine the core and specific portions of the code.

I have to admit it was somewhat hard for me to follow the __init__ part but after a while I was able to port this to the nodemcu/ESP8266 board successfully. I think this is my first contribution to MicroPython (?) but my pull is not yet accepted .

The init code for that LCD is peculiar anyways in order to handle both 4-bit and 8-bit paths.
Sorry about missing your PR (I see another one from March). I must have missed the email (I see it if I look back). I've merged your changes in (and @mcauser's PR)

[deshipu]

I tried to add some of the good practices I discovered to https://github.com/micropython/micropyt ... Guidelines
, however, you can see that almost every advice has a "but..." added by the core developers, so it's really hard to come up with any definitive advice.

EDIT: wrong link

[jimako]

@dhylands: Thanks for merging my PR. I consider it as my first contribution to MicroPython.

@deshipu: I am already seeing how I can improve my library based on those practices.