CircuitPython reached a major milestone last week as it welcomed its 100th board into the fold: the wristwatch form factored badge designed for the 10th annual Open Source Hardware Summit, which takes place March 13th in New York City. Although CircuitPython — an open source derivative of MicroPython — was born at Adafruit, more than half of the boards on this list were produced outside of the company. That just goes to show the strength of the community in support of the snake.
The OSHW 2020 badge joins a litany of familiar boards happy to drop you into a Python interpreter. Among them there’s the Adafruit Feather ecosystem, the ItsyBitsy, specialized boards like the Edge Badge that was in some goodie bags at Supercon, and the CircuitPlayground — that Swiss army knife of sensors which now comes in a Bluetooth version. The first 100 boards were rounded out in strong fashion with [Joey Castillo]’s OpenBook e-reader and the Teensy 4.0.
Watch the Future of OSHW Begin
If you were at Supercon 2019 and ran into Drew Fustini, chances are good that you got to see a prototype of this awesome wrist watch badge as it was being passed around.
The OHS board is based on the Nordic nRF52840 inside the Rigado BMD340 module. It has a ton of features including environmental sensors, a gesture sensor, and a 9-DoF IMU. To give you some scale, that’s a 1.54″ LCD on the front. There’s also a built-in LiPo charger and a Sparkfun QWIIC connector for easily interfacing other sensors, relays, etc over I²C.
According to the IO page, contributors and comments are still welcome for this project, as the board is still in development. Unfortunately for many of us, the badge won’t be for sale, but everyone who attends OSHW Summit 2020 will be handed one of these beauties. On the other hand, the open source nature of the project means if you really want one, you can assemble your own.
CircuitPython’s Impact on Microcontroller Projects
The ease of CircuitPython makes it a good platform for beginners of all ages. Games are always a fun way to learn anything, and if you’re new to CircuitPython, [de∫hipu]’s PewPew Standalone puts a learning environment for game programming in your pocket. From the Shut Up and Take My Money department, CircuitPython lead Scott Shawcroft is working on a Game Boy-compatible cartridge for CircuitPython. Scott gave a talk at the 2019 Supercon 2019 about this very subject, which we’ll be featuring in the coming weeks.
CircuitPython is a fork of MicroPython, which is built on C. CircuitPython works by parsing Python into byte code, which makes it powerful at both ends — empowering to the programmer, who doesn’t have to learn C, while taking advantage of C’s processing power. It also means you can move from one chip architecture to the next without having to relearn all the underpinnings of each specific system.
There’s a little something for everyone, so if CircuitPython hasn’t snaked its way to your bench just yet, check out the list of officially-supported boards.
“If you were at Supercon 2019 and ran into Drew Fustini, chances are good that you got to see a prototype of this awesome wrist watch badge as it was being passed around.”
FYI – this was the card10 badge from Chaos Communication Camp:
https://hackaday.com/2019/08/29/hands-on-cccamp2019-badge-is-a-sensor-playground-not-to-be-mistaken-for-a-watch/
We took inspiration from that awesome design! @schne1der_ from the card10 team was at Supercon and has been providing us with advice.
So what’s the difference between circuit and micro python??? Which should we use for new MCUs? Why have they diverged, don’t we have enough divergence already??
I’m sure someone will clear up the confusion by forking a further optimised version, embedded Python which will get too bloated leading to the tiny Python fork, and not featureful enough leaving to embedded Python ++ Pro. In the meantime standard Python has descended into development anarchy and confusion leading to Visual Python becoming the de facto standard Python, even though everybody says they hate it.
“I’m sure someone will clear up the confusion by forking a further optimised version, ”
I LOL’d!
I’ve never heard of Visual Python and use Python almost every day…
Well it was a forward looking statement (Insert boilerplate disclaimer)
Sad to know that Python is already in a state of development anarchy and confusion, because it didn’t seem you even raised an eyebrow at that :-D
MicroPython is the original project, created to run on PyBoard and Unix systems, and later ported to ESP8266, ESP32 and a few less supported platforms. As the authors say, it’s not supposed to be for microcontrollers specifically, but any environments with limited resources, and it is targeted at experienced programmers who want to fully use the hardware, just in a more convenient way (but still requires quite a bit knowledge).
CircuitPython is built on top of that as a language for small microcontroller projects written by beginners. The authors say that the most important part of the experience are the first 10 minutes of using it. It has cleaned up and consistent standard library, and a large selection of ready-to-use libraries with examples, and a lot of documentation.
So you should probably use CircuitPython for learning and for projects targeted for beginners, and MicroPython for hardcore hacking. They diverged because the authors of MicroPython wanted to focus on features and implementation, while the authors of CircuitPython wanted ease of use and documentation.
Interestingly, MicroPython seemed easier to deal with than CircuitPython. Which made me think that making it easy was not there whole reason for forking. The differences in the libraries and syntax are significant, and will make it hard to switch without a lot of headache.
Why didn’t AdaFruit just contribute to MicroPython to add the supposed ease of use features instead of creating unnecessary fragmentation?
tl;dr: micropython prioritizes performance, CiurcuitPython prioritizes portability.
More specifically, CircuitPython allows you to run identical code for (e.g.) I2C access on 100+ boards. and its libraries can be run on the Raspberry Pi and Jetson Nano.
Damien George (creator of micropython), sees the CircuitPython fork as a positive step, likening the two versions to different Linux distros: same underlying core optimised for different environments.
This page has a decent high level overview about the differences: https://www.digikey.com/en/maker/projects/micropython-basics-what-is-micropython/1f60afd88e6b44c0beb0784063f664fc and this is an official docs page that outlines the technical differences: https://circuitpython.readthedocs.io/en/latest/README.html#differences-from-micropython Circuit Python attempts to maximize the “beginner friendliness” so that the devices can (hopefully) be used people with all different skill levels, and even those with no prior experience without some of the pain points that can dissuade some people from continuing to learn about a thing if they start to feel like they can’t even get going.
Thanks for the clarification Drew. We used strikethrough above to make a correction.
It is nice to see that it doesn’t have a PIC processor!
Does anybody know if either MicroPython or CircuitPython can do easy bluetooth communication on ESP32 yet?
(as in as easy as using the arduino library on ESP32).
CircuitPython does not support ESP32.
The lattest version of MicroPython has a BLE stack and run on ESP32.
Bluetooth on the ESP32 is the one thing I’ve been waiting for to really start using micropython. This is just fantastic news.
I stopped using Circuitpython when I needed interrupts and timers, and had to learn that Circuitpython simply doesn’t have them.
So yeah, maybe a decent learner’s toy, but as so often a dead end, as soon as you advance.
It’s not like switching to MicroPython at this point is very difficult.
That’s true, and while it’s less likely that you’ll hit a dead end with Micropython, you’ll sooner or later wish you had started with C from the beginning.
I’m waiting for Monty Python where all keywords are replaced by spelling variations of Darles Chickqennnns
or various menu items, spam eggs spam & spam etc.
Terence Graham Parry Jones.
1 February 1942 – 21 January 2020.
RIP.
RIP
Didn’t catch that before I posted, everyone must have been thinking Monty Python really loudly.
This need a correction. Kristina’s summary may falsely give the reader an impression that CircuitPython is a Python interpreter for microcontrollers. It is actually a _derivative_ of MicroPython, which is the interpreter. Reference:
* https://learn.adafruit.com/micropython-basics-what-is-micropython/overview
There’s an opportunity here to _not_ repeat past community reporting errors we saw back when Arduino was launched (nary a mention it was a fork of Wiring — stripped of attribution).
Unlike Arduino, from the very start AdaFruit was completely open about their relationship with MicroPython (see link). AdaFruit have an easier MP distribution, have ported to more hardware platforms, know how to promote, and contribute lots of documentation to their own website. All excellent stuff, they deserve credit for their contributions and in no way are they responsible when people conflate the two.
A HaD feature describing the genesis of Python on microcontrollers would be an excellent original feature. It would also help to dispel some myths that are (organically) developing.
What is the accepted protocol (or legality) for this kind of re-badging and forking in open source projects? Supposing the micropython project creates some new functionality in future, can adafruit just take it and put it into their version? Presumably this is legal (depending on the micropython license), but is it the done thing? If Adafruit are making money out of it somehow, they will hopefully want to donate to the micropython project financially?
I can summarize, tho I will mess up some detail :-)
So there’s a year+ thread about this on the MP forum:
https://forum.micropython.org/viewtopic.php?t=2894
Basically AF is well within their legal rights: it’s MIT-licensed which I understand to mean “it’s yours; do what you want, just don’t remove the Copyright+license”. Pretty much it is “Wild West” except for that copyright notice clause.
Without being compelled to do so (see above), AF is providing source for their changes. Their changes are available in 2 forms: 1 compatible with CP and 1 with MP. Part of the reason MP isn’t 100% compatible at every level has to do with MP’s goals of widespread hardware compatibility, and their (MP) approach would impose complexity and risk-of-API-breakage onto vendors like AF. AF is making good faith attempts to keep MP at feature parity with CP. So they’re taking steps to not create a rift.
There’s nothing unethical about forking. Someone who forks _could_ have ill intent, but the issue is self policing: Developers walk away from ill-managed projects, and healthy projects attract users who become contributors.
IMO it looks like MP has a process burden on how contributions are made, for the good reason of remaining faithful to their larger goal of widespread device support.
Not exactly the same but reminds me a little of the controversy years ago between Ubuntu and Debian:
Debian releases were being delayed by CPU platform bugs, as their charter required them to do do simultaneous releases across architectures. Not just ARM, but others: SPARC, MIPS, PowerPC etc.
Ubuntu ignored all that and simply provided an X86 release in a polished, release ready form (which Debian couldn’t do until all the platform bugs were worked out) and as a result became bigger than Debian. Bigger than all the distros combined. There were args that Ubuntu should have directly helped Debian. But if they did, I don’t think they would have been as successful because they would have taken on more scope and their releases would be controlled by folks who have greater agendas than an X86-only release.
I think history shows this worked out well for both Ubuntu and Debian. Not everyone was convinced at the time. :-)
Hopefully my answer attracts someone with more knowledge on this topic than I, and who can correct anything I got wrong.
There is a lot of good in both these projects. And you can’t go wrong with either, or with Arduino. All the communities are so healthy and that there should be no such concerns in choosing a platform.
Interesting and informative answer. I wasn’t really aware of the Debian/Ubuntu situation. Thanks.
CircuitPython doesn’t put much store by compatibility: code I wrote for the Circuit Playground Express in 2017 just flat-out doesn’t run any more, and the inbuilt cp library is too slow to be useful. CircuitPython can also be a little memory-leaky: assistive controllers based on M0 boards that we develop and use at work require resets as the system fails to manage memory.
It would be nice if the CircuitPython project fed back changes to MicroPython: I’d rather it ran *well* on 10 boards than was half-useful on 100.