Page 1 of 3

Adafruit CircuitPython

Posted: Thu Jan 12, 2017 5:40 pm
by slzatz
I am interested in the views of those experienced in open source and the forking of projects to understand the implications of the Adafruit CircuitPython fork of Micropython.

I am particularly focused on the ESP8266 since that is one of the main target platforms for Micropython and of course was the subject of a successful kickstarter program. I suspect that many of us are now completely dependent on the terrific work of Damien and Paul and that of the numerous other contributors to the code and documentation. Particularly given the fact that the Micropython kickstarter project identified the Adafruit HUZZAH boards as its only officially supported boards, it is interesting that there is now another version of Micropython targeting the same hardware. Maybe the answer is the more the merrier but with limited resources it does feel like a missed opportunity to combine efforts v. separate initiatives. Again, with limited experience in this arena, I am curious as to how others see this.

Re: Adafruit CircuitPython

Posted: Thu Jan 12, 2017 8:52 pm
by marfis
Maybe the answer is the more the merrier but with limited resources it does feel like a missed opportunity to combine efforts v. separate initiatives
well it has started already with pycom's forks of uPy and adafruit is now the next one. I feel it has something to do with the machine API and its endless discussions about "proper" interfaces - whatever that means. Adafruit apparently feels that it should be split into different modules. They do mention that they will continue to update the uPy core though.

Well why not? Instead of discussing all the time and not coming to a conclusion, fork it and go on your own. Let's be positive about it and see what they achieve - it seems as they are really start using uPy on their products so that's great!

And hey - they have a nice looking snake too :D

Re: Adafruit CircuitPython

Posted: Thu Jan 12, 2017 10:13 pm
by deshipu
That fork is actually older than pycom's, I think. It's a way to do development faster, experiment without having to argue, test things and come up with better solutions.

I think it has more to do with the fact that Adafruit has different goals than the MicroPython project -- they need it to be easy to learn and use, consistent, compatible with Python as much as possible and encouraging good, readable code. MicroPython currently seems to be more focused on making it fast, fitting it in as little resources as possible, and making it as similar to Unix as possible. It doesn't make sense to try and reconcile such goals, so a fork is warranted.

The good news is that since the license is the same and both projects are developed in the open, there is no reason why improvements from one can't be moved over to the other, and vice versa. Who knows, perhaps at some point the goals of those projects will change enough to be compatible again and a merge will happen?

Re: Adafruit CircuitPython

Posted: Fri Jan 13, 2017 7:21 am
by pythoncoder
marfis wrote:...I feel it has something to do with the machine API and its endless discussions about "proper" interfaces - whatever that means...
I think this stems from a desire to make MicroPython portable between different hardware platforms, which is not a commercial focus for organisations like Adafruit and PyCom.

I share your frustration with the machine module whose code and docs remain incomplete. Until the arcane discussions reach a conclusion it's hard to contribute to it or even to use it effectively. I still use pyb because it's well documented, supports a wide range of interfaces and works.

Producing a device independent abstraction of hardware is an ambitious goal. I suspect it will forever remain vulnerable to edge cases where a manufacturer releases hardware with features not anticipated in the design. But I'd be happy to be proved wrong.

Re: Adafruit CircuitPython

Posted: Sat Jan 14, 2017 12:37 pm
by slzatz
Here's the explanation for what Adafruit is doing from Tony Dicola. A few reasons given: they want a simpler interface that would be easier for their target audience, they would like a uniform API across the processors/boards that they support and they want to be a strict subset of CPython. Sounds like their approach to the the ESP8266 will support both full Micropython as well as the simplified CircuitPython code. ... 0aA4VzcWSi

And here is their blog post about CircuitPython: ... thon-beta/

(edited original post with blog link and a little additional info)

Re: Adafruit CircuitPython

Posted: Sat Jan 14, 2017 2:30 pm
by jpj
slzatz wrote:(edited original post with blog link and a little additional info)
Thanks for the URLs. I like the direction Adafruit is going with MicroPython / CircuitPython. Tony takes seven minutes or so to share some reasoning and strategy at the beginning of the video. Creating more uniform code across multiple chips / hardware platforms will make the end user's (like me) experience much easier and more enjoyable.

I started my MicroPython experience with the Adafruit Huzzah and a few weeks later began working with the Pyboard v1.1. There are enough implementation differences that I had to relearn a lot. Moving towards simplification and uniformity is very good, though I realize there will always be hardware differences that require exception coding.

This is a good video from Tony and worth watching, IMO.


Re: Adafruit CircuitPython

Posted: Sun Jan 15, 2017 9:54 am
by Turbinenreiter
In the video, the reason to fork was given with two arguments:
1. create a uniform API
2. create a simpler API

ad 1)
creating a uniform API by forking is ... not how you create a uniform API. However, the shared bindings model they use is, I think, a very good idea. A lack of such a thing is what broke the uniformity of the MicroPython API, creating enough pain to make a fork reasonable.

ad 2)
I don't think the CurcuitPython API is any simpler than the MicroPython API. In fact, if you look at i.e. I2C and SPI, CircuitPython pretty much is a subset of MicroPython, providing only the calls that take a buffer as argument - which isn't easier to use at all (it's like passing pointers in C). It also makes you deal with locks, which I don't know what they do and you have to deal with initializing and deinitializing the hardware. Object creation works by passing in the Pins instead of ID.
All of this doesn't look to me like a simpler API. It looks like an API simpler to write. The Pin as argument allows for bitbang and native to work the same. Also, it reflects how the SAMD21 handles serial protocols with sercoms. Same for the init/deinit stuff.

In my opinion, MicroPython can learn from what is happening at the moment and the things to learn have already been discussed before: Move to a shared bindings concept for the Hardware API and move the ports to their own git repositories.

I spent an hour yesterday rewriting an BMX055 to work with the CircuitPython API and I have previously dealt with adapting code from pyboard to esp8266 as well as from pyb to machine. I'm happy to patch my code to move to a updated, better, API each day if need be, but I'm really happy when I have to change my code from board to board. A uniform API needs to be our focus. Sadly, this is what makes it so hard and slow going, because we have to have long discussions and to me it feels like we as community haven't yet figured out how to have those productively.

Anyway, I'm very happy about atmel-samd and Adafruits involvement.

Re: Adafruit CircuitPython

Posted: Mon Jan 16, 2017 10:54 am
by pythoncoder
Adafruit strike me as being prone to the Not Invented Here syndrome. Why develop Ampy rather than contribute to Dave Hyland's excellent rshell? Why not contribute to the machine module rather than pursuing the same ends (a unified API) by different means (another API)? I also think it's a shame that they haven't taken on board the views of Damien and Paul on API design. For example, there is a good reason why methods should be used in device drivers rather than properties.

They also advocate the use of USB mass storage for transferring files to target devices. This can be troublesome because USB mass storage device isn't designed for concurrent access. File corruption can occur. Further, since the ESP8266 doesn't support USB mass storage the goal of using the same code and tools across devices is compromised. If I were a beginner that video would have failed to convince me that the whole enterprise was particularly simple what with hidden whitespace bugs, platform specific access methods, Unix command line invocations and dependency problems ;)

On the plus side it's great that they are using MicroPython and he evidently understands the needs of the education market.

Re: Adafruit CircuitPython

Posted: Mon Jan 16, 2017 11:16 am
by deshipu
I think you need to put yourself in their shoes: they are investing a great deal into this project, they are going to have a large stock of hardware depending on this firmware, and they are going to have a lot of documentation and support staff working on this. It's obvious, that they want to have at least some control over it. What would they do if someone suddenly decided to merge a patch that would completely break their ports, because the code is cleaner that way? Or if a decision to completely overhaul the API was suddenly made -- something that happened at least twice already -- and all their libraries, docs and tutorial suddenly became obsolete?

If you are sitting on a pile of hardware that depends heavily on some software, you really *have* to have control over that software, and that means forking -- and that's why every company that is selling MicroPython-based boards has their own fork: PyBoard, OpenMV, PyCom, and now Adafruit (and also Micro:bit, which is not strictly controlled by the seller, but it is a fork for a single device). I expect that the number of forks will only grow as we have more companies joining the party, and I think this is a good thing.

Re: Adafruit CircuitPython

Posted: Mon Jan 16, 2017 11:51 am
by pythoncoder
Agreed. But you can have a fork without reinventing API's. You can fork and contribute.