Compatibility layer for Adafruit CircuitPython drivers on Micropython

Discussion about programs, libraries and tools that work with MicroPython. Mostly these are provided by a third party.
Target audience: All users and developers of MicroPython.
Post Reply
cefn
Posts: 228
Joined: Tue Aug 09, 2016 10:58 am

Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by cefn » Wed Mar 07, 2018 2:43 pm

As many of you know, CircuitPython is an Adafruit-commissioned remix of Micropython.

I don't speak for Adafruit, but I understand the differences are about being more accessible and easy for learners (sometimes at the cost of performance or relevance for 'industrial' use cases). Currently CircuitPython is maintained for the target platforms which Adafruit ships (see https://github.com/adafruit/circuitpython/releases ) meaning there are Micropython platforms for which no CircuitPython build is available.

Alongside CircuitPython, Adafruit supports learners also by commissioning and maintaining a whole load of hardware drivers (see e.g. https://github.com/adafruit/Adafruit_Ci ... es/drivers ) which do not run on Micropython, and which would need specialist work to fork a Micropython flavour.

Adafruit commissioned some of my time to experiment with a proof-of-concept compatibility layer, called adafruit-blinka ( the name of the CircuitPython snake https://www.adafruit.com/product/2600 ) which might allow CircuitPython driver code to run directly on a Micropython official build. Assuming your application can accept the marginal increase in RAM, flash and processor overhead, a stable compatibility layer would give Micropython users the benefit of using tested CircuitPython modules without modification.

This is just an informal announcement that early experimentation is positive. I have learned it may be possible to run nearly all CircuitPython code on a Micropython official build, with several drivers having been proven to work with the proof-of-concept compatibility layer. At this stage, interested experimenters working in education who are willing to put up with very beta code might be able to offer feedback or contributions to achieve the CircuitPython conformance which they need for their projects on Micropython platforms.

Currently, there is support for Pin enumeration, I2C and UART support, but as-yet-untested SPI support. You can engage with the public Github repo at https://github.com/adafruit/Adafruit_Micropython_Blinka

Turbinenreiter
Posts: 288
Joined: Sun May 04, 2014 8:54 am

Re: Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by Turbinenreiter » Wed Mar 07, 2018 7:14 pm

This is truly a great move to battle the drawbacks of forking.

User avatar
pythoncoder
Posts: 3725
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by pythoncoder » Thu Mar 08, 2018 6:22 am

Agreed. :D
Peter Hinch

fpp
Posts: 64
Joined: Wed Jul 20, 2016 12:08 pm

Re: Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by fpp » Thu Mar 08, 2018 6:55 pm

Great move indeed, if it walks the whole mile !

Adafruit have invested hugely in CircuitPython, not only in the software itself but in its documentation and user support.

Enough at least to give the impression that the original micropython has been stagnating in comparison (not being backed, of course, by a comparable business activity).

So this specific way of "giving back to the upstream" could be seen as a win/win, bolstering both the micropython ecosystem and Adafruit's standing in the community.

Stock up the popcorn :-)

Picasso
Posts: 39
Joined: Fri Mar 22, 2019 12:13 pm

Re: Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by Picasso » Fri Mar 22, 2019 12:24 pm

The idea of "giving back upstream" is good. The way to do that is by submitting pr's in the upstream repo's. The compatibility layer sounds nice, but any incompatiblity that exists is created by Adafruit per definition. That is were the incompatible code comes from. I simply cant stop this sense of utter hypocrisy I got from the Adafruiteers that are reasoning like this.

The proper way to do this (if adfaruiteeers would be interested at all) is to simply make the drivers available for MicroPython, tested and all, and have some adaption layer for CircuitPython. That way, MicroPython receives the respect it deserves. If Adafruit did that, than they can talk, with their backs straight, and say : "Look, we are giving back upstream!".

mosi
Posts: 26
Joined: Tue Oct 07, 2014 12:07 am

Re: Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by mosi » Fri Sep 06, 2019 8:59 pm

I am trying to understand the source of incompatibility.

On an example of ADS1015 adafruit:

the only line I found through a 30s look at the code is the import of specialized I2C:

https://github.com/adafruit/Adafruit_Ci ... x15.py#L35

Does adafruit micropython utilize their own hardware abstraction layer for I2C on different boards?

What could the other sources be for instance?

User avatar
pythoncoder
Posts: 3725
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Compatibility layer for Adafruit CircuitPython drivers on Micropython

Post by pythoncoder » Sat Sep 07, 2019 7:21 am

My personal view, having ported a few CircuitPython drivers to MicroPython, is that the best way is to rewrite them. The Zen of MicroPython is performance while that of CircuitPython is beginner-friendliness. For example in CircuitPython SPI and I2C access are wrapped in special classes. These do clever things like arbitrating between accesses to different devices on the bus. In my opinion the MicroPython way is to drive the interface directly. If the user has multiple devices connected to the same bus, it is assumed that they have the expertise to avoid conflict. Both approaches are valid; my personal preference is for the MicroPython way.

One reason apart from performance is that I find MicroPython device driver code more readable: Adafruit tend to have a module giving symbolic names to device registers. Reading their code in conjunction with a hardware datasheet involves regular lookups to determine the mapping between symbols and addresses. Doubtless some coding guru more clever than me recommends this, but I find it a pain. And the special classes tend to hide important details like the manipulation of the CS line - for all that they add to beginner friendliness they detract from being able to understand the driver at the hardware level.

As an example I recently ported their RA8875 display driver to here - see driver/ra8875.py. In a display driver performance is paramount so my version uses techniques like the Viper and Native emitters and other optimisations - notably to support the rendering of arbitrary fonts. It was basically a line-by-line rewrite, studying the datasheet, the Adafruit CircuitPython and Arduino drivers, and other sources of code and information. All made more interesting by the fact that the RA8875 itself has bugs...

I'm less convinced by the idea of a compatibility layer than when I last commented.
Peter Hinch

Post Reply