Wow, 2017 was an amazing year for CircuitPython. At this time last year I (@tannewt) was working alone on the core while @tdicola did the first guides and @deshipu helped with drivers. CircuitPython didn’t ship on any Adafruit products and none had been designed for it. We had just decided to rebrand Adafruit MicroPython to Adafruit CircuitPython for clarity and announced the first beta.
Over the course of 2017, CircuitPython grew from development of the core codebase to a broad project that involves a community of folks working on the core platform, a variety of hardware, creative tutorials, diverse libraries, and helpful tools. This growth has proven that developing code fast and furiously in the open while encouraging participation from folks with all backgrounds can lead to powerful code and a strong community.
Along the way, we’ve learned a lot and worked hard to improve the beginner experience. As more new coders join in, they sometimes hit bumps as they get started such as connecting to the serial terminal, corruption of the CIRCUITPY file system, running out of memory and mismatched code and documentation versions. Fortunately, our community has been very helpful in getting people past the hurdles through active participation in the Support Forums, Discord (join us!) and Learn Guides. There are a variety of ways these problems can be fixed more permanently and many of them are not simply with core code contributions.
In 2018, as Adafruit continues its commitment to beginner-friendly tech and tutorials, let us think about CircuitPython more broadly. Most contributions to CircuitPython are not changes to the core implementation. The entire project involves building a community, a platform, hardware, tutorials, libraries and tools. Without a consistent, collaborative approach to all of these aspects, we’ll continue to introduce bumps into the road for new coders. Instead, let’s all continue removing these bumps: learning to code should be incredibly easy for anyone to do.
Haven’t tried CircuitPython yet? There is no better time than now! See the awesome Welcome to CircuitPython guide by @kattni for more info.
Would you like to know more? Read more below for the details on community, core platform, hardware, documentation, libraries and tools of the CircuitPython project or jump to quick stats.
In 2017, community became a critical piece of the CircuitPython project. With the beta we laid out the foundation of the community with the Contributor Covenant as a code of conduct. By adding it to all of our code repositories and Discord we set the expectation that everyone is friendly and respectful regardless of others’ background. Right around the launch of the beta, @dhalbert and @jerryn became our first regular participants in the CircuitPython community.
In June, we launched the Adafruit Discord chat server as another avenue for folks to get help on their projects, celebrate their successes and their failures, and participate in rapid, open source development. There are too many awesome people to name individually. So, shout out (aka group hug) to everyone who hangs out there, you all rock.
The Discord community has also helped us find more great people to help build CircuitPython. In September, we started the CircuitPython weekly meeting (Mondays 11am Pacific / 2pm Eastern) on Discord as the central place for folks from all aspects of CircuitPython to coordinate. Since then, we regularly have a dozen or so folks participate in the meeting each week.
In 2018, we’re going to continue building the awesome community on Discord and the forums. We’ll continue to ensure it’s a welcoming space for everyone and continue to encourage folks to participate. We’ll also launch a podcast for the CircuitPython weekly so it’s easier for people to follow along. Keep an eye on the Adafruit Blog for details. And as always, anyone is welcome to join the meeting on Discord.
Check out @kattni‘s awesome Welcome to CircuitPython community for more details.
Going into 2017 we were just solidifying a consistent hardware API foundation for CircuitPython. We introduced it with the launch of the beta but evolved it to 1.0. Since then, it hasn’t changed that much. We’ve made changes to standard CPython module names and also added a few more features like the storage module. @dhalbert has done a great job finding and fixing bugs under the hood. But overall, the core has been stable both in design and implementation. Our ever-increasing library count is proof that the approach works.
In 2018, we’ll be leaving the core APIs the same and focus on supporting new hardware. Supporting additional platforms in a consistent way is very important to support all of the libraries we’re creating. With 3.x we’re refactoring the core to ensure a uniform execution flow (what files run and when the REPL is entered). New hardware will also bring new functionality, such as Bluetooth LE, so expect to see new, uniform APIs for those additional features as well.
The SAMD21 (aka M0) defined the hardware for CircuitPython in 2017. @ladyada released the Feather M0 Express, Metro M0 Express and Circuit Playground Express designed for CircuitPython. The Trinket M0 and Gemma M0 also shipped with CircuitPython by default and were given away for the holidays. Adabox 006 was sent to thousands of people with Circuit Playground Express boards and CircuitPython-specific guides. There were also some awesome community hardware projects including a Trinket M0 Haxpress by @dastels, a supersized Feather M0 Express and @deshipu’s µGame console.
In 2018, CircuitPython is coming to the nRF52 and the SAMD51 (aka M4). These two platforms promise to bring overall better performance with higher clock speeds and more memory. nRF52 will enable folks to use CircuitPython from their mobile devices via Bluetooth. The SAMD51 will enable larger projects that require more memory. The ESP32 is also on our radar as a solution for CircuitPython IoT/wifi connectivity but we won’t focus on it until after nRF52. We can’t do everything all at once… yet.
There many forms of documentation that support a project like CircuitPython. (Here is a great talk on types of documentation from PyCon Australia last year.) In 2017, we focused on tutorials and how-tos in the form of Learn Guides. @kattni and @ladyada led the effort to produce easy welcome & quickstart guides for CircuitPython. @tdicola updated Learn Guides (and their libraries) for a variety of devices that Adafruit sells. @paintyourdragon and @mikeysklar also helped get Gemma M0 guides updated to include CircuitPython code as well. Our community also brought some great tutorials to CircuitPython including @BlitzCityDIY’s videos and article in HackSpace 1 (Page 10), @dastels various projects and an O’Reilly book on MicroPython and CircuitPython by @ntoll (available from Adafruit and Amazon.)
Our reference docs story was a bit weaker in 2017. While we have been good about adding inline docs to library code, we’ve been bad at making sure they are all building successfully on ReadTheDocs and linking to them from the main reference docs.
In 2018, we’re going to continue growing all aspects of our documentation. We’ll have more and more tutorials and how-tos on Adafruit Learn and polish up our reference docs on ReadTheDocs. Our discussions will continue on the forums and on Discord including the Weekly meeting.
Platforms such as Arduino and CircuitPython are defined by the breadth and quality of their libraries. Libraries simplify complicated interactions including working with devices and sensors. Without them, all CircuitPython beginners would need to start by reading a data sheet.
We’ve added more and more libraries to CircuitPython’s bundle throughout 2017. Specifically @tdicola, @ladyada and @mr mcwethy have been a huge help. Not only did we add a bunch of new libraries but we’ve also improved the consistency of the library code. We set up all libraries to use pylint automatically through Travis CI. We also changed library APIs to match the design guide for property names and units.
Lastly, in 2017, we’ve improved the release process for each library and the bundle itself. Now we make multiple zip files for each library release that are built for each major version of CircuitPython. We also record the version number of the library in the code itself so that later (in 2018!) we can automate library updating.
So, in 2018 we’ll continue to expand our catalog of libraries by supporting more and more devices. Consistency across the libraries will also continue to improve as we introduce more automated quality checks. (Thanks Adabot!) For example, all libraries in 2018 will have an `examples` folder with example code! Check out the Adafruit CircuitPython Bundle for the latest libraries.
In 2017, we created a few tools to ease development including Rosie CI, Adabot and the CircuitPython Build tools. We also leverage Travis CI, ReadTheDocs and pylint to help improve the quality of our drivers. In 2018, we’ll continue improving the development tools to make our code more consistent across all of our libraries and hardware.
To help beginners, @ntoll has done great work adding CircuitPython support to the mu editor beta (Help test!). mu makes it easy to edit code and see its output. In 2018, we’ll continue contributing and promoting mu. We’re also working to make it easier to update CircuitPython and the libraries from mu.
Have you got a tool you’d like to see work with CircuitPython? Join us on Discord, we’d love to help make it happen.
Overall, 2018 is going to be epic for CircuitPython. We’ll be working quickly to improve all aspects of CircuitPython, not just the code. Thank you to all of our contributors and community members! Beginners will find it easier and easier to get started writing their first code thanks to you.
CircuitPython Quick Stats
Here are some quick stats about CircuitPython since its creation.
- 611 commits to CircuitPython (separate from MicroPython and its pull requests)
- 13 authors of core platform contributions
- 3,723 members of Adafruit’s Discord server
- 62 libraries in the official bundle
- 37,943 designed-for-CirPy boards sold
- 2 Adafruit-designed CircuitPython boards that ship with CircuitPython (Gemma M0, Trinket M0) (Metro M0 Express, Feather M0 Express, CircuitPlayground Express soon)
- 315 GitHub stars
- 94 CircuitPython-tagged blog posts
- 135 Learn guides that use CircuitPython
Very exciting! I do love Adafruit, and the efforts to bring Circuitpython to more devices! However, what has been the total effect on the Micropython community? I understand the need to fork when different software design decisions are required, but looking at both the Adafruit and Micropython forums, there are a number of posts with criss-crossed driver issues. These are often posts where individuals have a piece of hardware with a Micropython driver, but they want a Circuitpython one, and others who have found a Circuitpython driver but but don’t have the time or skill to port it over to Micropython. As I said, I am very excited to have Circuitpython on more feather boards, and I feel really lucky to have so many options to code with python on microcontrollers, I just wish there was less confusion and inconvenience for all involved.
I think that it would be great if Adafruit also distributed Micropython drivers for the libraries they are porting from Arduino, and this is something I would be willing to pay for, either through Kickstarter or Bountysource, or whatever! Oh, and with that in mind, do the sales of Circuitpython boards send any revenue back to the Micropython project?
Hi Max! Thank you for the very thoughtful comments and questions.
To understand the full effect on MicroPython you’d have to ask Damien. I don’t follow MicroPython closely. I feel we’ve been more successful with CircuitPython than if we tried to stay within the MicroPython repo. However, we’ll never actually know.
I totally relate to the driver problems. I’ve seen it happen too. However, I don’t think we’ve made it any worse with creating CircuitPython. As far as I know, MicroPython still doesn’t have a well defined hardware API that is available uniformly across ports. This means drivers for MicroPython may not work across boards. By creating CircuitPython we have a new namespace, so to speak, where we provide stronger promises that drivers and examples will just work.
Hopefully, in time, it’ll become clearer what MicroPython is and what CircuitPython is and how they relate. Acknowledging our roots to MicroPython while being clear we’re talking about CircuitPython is still something we’re working on.
Maintaining drivers for MicroPython is more difficult due to its inconsistencies across ports. Since we have that consistency with CircuitPython that’s where we focus. It would be possible to get support for our drivers as is in MicroPython but its not a priority for us because we have CircuitPython. I’m happy to give suggestions if someone wants to do the work.
Sales of CircuitPython boards do not directly generate revenue for Damien (the creator of MicroPython). Only pyboard, its accessories and the micropython patch and stickers do. However, sales of CircuitPython boards does support a number of folks working on CircuitPython for Adafruit and everything related to it. This can benefit MicroPython indirectly by bringing more awareness to it and building a wealth of open source code to build on. One example is my long-lived heap improvements I recently did which has a MicroPython issue for discussion (issue 3586). Whether it gets merged into MicroPython is up to Damien and the MicroPython community.
Thank you for your reply. That all sounds pretty good/reasonable, and your noted github issue is indeed a great example of the indirect benefits to Micropython.
Looking forward to messin’ around with Circuitpython on the nRF52!