top | item 25923491

CircuitPython: Programming Hardware in Python

175 points| optimalsolver | 5 years ago |github.com | reply

83 comments

order
[+] jscholes|5 years ago|reply
I've used CircuitPython for one production hardware project which is in the wild. Safe to say that the increased draw on the included battery and higher memory usage weren't a concern here, but they are both significant. Developer productivity is through the roof though.

I'd say the biggest pain points for me (unless I'm missing something/they've added more stuff recently) were created by the lack of support for what feel like production standards in software development. For example, the logging library is a toy, and unit testing is non-existent unless you isolate all your CircuitPython-specific code and run tests on your dev machine using CPython.

[+] pkolaczk|5 years ago|reply
"Developer productivity is through the roof though."

I learned Python after I learned C, C++, Java, Scala, Rust and a few others. I fail to see my productivity going through the roof with Python. It's quite the opposite. Writing initial code is fast, but making it work well - not so much.

[+] craftinator|5 years ago|reply
Surprised you didn't use at least MicroPython. I think Python on embedded in general is not great in a production setting, but at least MicroPython has widespread usage; CircuitPython is aimed at being a toy language for beginners.
[+] gh02t|5 years ago|reply
Out of curiosity, what about this particular project made you opt for CircuitPython? Was it something targeting hobbyists and wanting to allow them to tinker with it? I'm not trying to put it down because I like CircuitPython, but I would not even consider it for a general production device.
[+] sarusso|5 years ago|reply
It would be very interesting to hear more about your project and, if you did some benchmarks, about the increased draw on the battery.
[+] dialamac|5 years ago|reply
That’s a very misleading headline. I got the impression this was something akin to VHDL or Verilog or SystemC in python. “Programming Hardware” the way it’s used here is pretty much the same as vanilla python, though I suppose a lot in this industry constantly need reminding of that.
[+] senux|5 years ago|reply
I don't think there's any merit to your argument here. If the headline had said "designing hardware circuits", that would be another story entirely.

> “Programming Hardware” the way it’s used here is pretty much the same as vanilla python

One can only hope so, since the project is a fork of MicroPython. Neither CPython or MicroPython are meant to be a long departure from Python itself.

[+] olooney|5 years ago|reply
I wrote a toy digital circuit simulator[1] as part of a personal "NAND to Tetris" style project. It has none of the bells and whistles of a full simulator but does illustrate how you could write you own in only a few dozen lines of Python. It also has a kind of neat "declarative" syntax inspired by VHDL/Verilog where components (i.e., Verilog modules, VHDL entities) are defined as regular Python classes and describe their contents. For example, here's a half-adder component, which is comprised of a XOR gate and an AND gate:

    class HalfAdder(Component):
        def __init__(self, a, b, out=None, c=None):
            super().__init__()
            self.a = self.input(a)
            self.b = self.input(b)
            self.out = self.output(out)
            self.c = self.output(c)

            XOR(a=self.a, b=self.b, out=self.out)
            AND(a=self.a, b=self.b, out=self.c)
having to declare each pin as input or output adds a lot of boilerplate; I was hoping to add a feature where input/output information could be declared using type annotations in the function signature itself. That would look something like:

    class HalfAdder(Component):
        def __init__(self, 
                     a: input, 
                     b: input,
                     out:output = None, 
                     c:output = None):
            super().__init__()

            XOR(a=self.a, b=self.b, out=self.out)
            AND(a=self.a, b=self.b, out=self.c)
which I think is starting to look pretty Verilog-ish, while still staying Pythonic.

[1]: https://github.com/olooney/circuit

[+] sunds|5 years ago|reply
I recently built a project on an ESP32 using Micropython. My project had a web application using web sockets and there were good libraries in Micropython.

My take on Micropython is that it is a small community with just a handful of long term dedicated contributors. It is a little rough around the edges, especially when you get into the details of board support other than the pyboard. For example I had issues with interrupts interacting with Python threads in the web sockets library. The documentation was flat out wrong and I had to figure things out on my own.

I ordered a couple accessory boards off Amazon, a high precision ADC and a real time clock. Both were fakes. They had swapped out chips with lower grade components. When I ordered from Adafruit I got the real things.

The big downside of the Circuit Python fork is that Adafruit deprecated their Micropython libraries for their boards. That seems like it will have long term impact to Micropython.

[+] selykg|5 years ago|reply
> I ordered a couple accessory boards off Amazon, a high precision ADC and a real time clock. Both were fakes. They had swapped out chips with lower grade components. When I ordered from Adafruit I got the real things.

sort of off topic, but, I never buy anything from Amazon anymore unless it's a last resort. The convenience is no longer there if I end up having to send stuff back due to it being fake or damaged in shipping (particularly books that are put in large boxes with no packing material, which is sucky given Amazon used to be the primary way I'd buy books).

I'm excited to give MicroPython a try with the new Raspberry Pi 2040 microcontroller. I have a couple project ideas lined up and really looking forward to getting into this space a little as a hobby.

[+] Uhrheber|5 years ago|reply
CircuitPython is a toy language made for running on Adafruit's halloween/cosplaying gadgets.

It doesn't even support interrupts.

Better use Micropython.

[+] bmitc|5 years ago|reply
What I don’t understand is: what features of Python encourage its use in embedded systems in the first place? Why not F# or Elixir?
[+] Ecco|5 years ago|reply
To be fair, this is really mostly just a rebranded MicroPython...
[+] genmud|5 years ago|reply
While yes, its forked from MicroPython, saying it is just rebranded is almost like saying Ubuntu is just rebranded Debian.

The biggest difference is how they handle core modules... rather than having a per-port/board they have a common set of core modules. There are also a lot more of those modules and it seems to have a fairly robust set of hardware/boards that are supported.

I'll be the first to admit that I don't do a whole lot in either since the boards I work on are a bit resource constrained.

The other thing to note is that Adafruit is putting a ton of resources into CircuitPython, I see updates/improvements all the time from them in their git repo. The velocity in CircuitPython vs MicroPython appears to be significantly higher (and that by no means is a dig at MicroPython, I love their project and they have so much cool stuff going on).

[+] systemvoltage|5 years ago|reply
Support MicroPython. Adafruit has commercial interests - they're building CircuitPython so that people buy their stuff. They're a multi-million dollar corporation, not your mom and pop hobby shop.

Instead of doubling down on MicroPython, Adafruit decided to fork it so they can have the right HALs. They should have made a library, contributed to MicroPython and grown the ecosystem.

Unrelated, I absolutely despise Adafruit customer service - they're demeaning and belittling. I wanted to return items because they were not as described in the pictures - their response was we don't guarantee that. OK. So, you buy stuff off of AliExpress and put a 3x markup and you can't guarantee your supply chain? I now buy all my electronics from DigiKey and Sparkfun.

[+] animal_spirits|5 years ago|reply
It has 7,000 more commits than MicroPython, to say it is a rebrand is unfair.
[+] wt8008|5 years ago|reply
I like to think that MicroPython is more like a base project without a standard hardware library/abstraction layer. CircuitPython took MicroPython and built a hardware abstraction layer on top. It makes hardware level access more standardized and you can take your project to a different microcontroller board. CircuitPython only supports a limited number of boards.

If scripting for microcontrollers become more mainstream, it can enable new applications and use cases that do not require a forced firmware re-flashing to change the code.

[+] dkjaudyeqooe|5 years ago|reply
Sure and they provide support for it, also so they can configure and customise it whichever way they see fit.

For most non-programmers (which is the target) support is much more important than issues with forks or OSS politics.

[+] sarusso|5 years ago|reply
Yep. AFAIK CircuitPython focuses more on low memory microcontrollers and less on connectivity.
[+] ogou|5 years ago|reply
Adafruit’s goal is the success of Adafruit. They built an increasingly closed ecosystem on the shoulders of a constellation of open source projects. Success is no sin, but I’m tired of their branded bloatware being touted as groundbreaking. Their development choices are commercially expedient and designed to capture market share instead of contributing to the greater success of the open source maker movement that enables their existence.
[+] sokoloff|5 years ago|reply
This is a much more negative take than I have on Adafruit. Adafruit is, to me, a great provider of breakout boards and gives generously to the community while trying to stay in business. They might be slightly more profitable if they closed off everything they could. I’ve used their libraries on a lot of projects without using their hardware.

Their stuff works, is open, and when I used one of their LSM6DS dev boards on a 32-bit micro, it had an underflow bug; because that board and library was open-source, I could fix it the same afternoon I got the package. The fix was simple and obvious, they accepted my pull request, and now no one else has to waste that hour. That’s the power of open source to me.

I hold Adafruit and Limor in a positive light and think their “bloatware” is very effective in making electronics accessible to many more people than before, much the same as the $30 Arduino did for the $2 AVR. The ecosystem and accessibility matter.

I agree that they’re seeking success of Adafruit, and agree that’s not a bad thing, but I don’t see how they’re going closed. What is “closed” about their ecosystem? The article we’re discussing is about MIT-licensed software on their GitHub.

[+] ntoll|5 years ago|reply
I'm an open source contributor. I've worked/collaborated with Adafruit. They support the ecosystem. Perhaps they don't blow their own trumpet in this respect (and should, so you could see how the do give back).

My experience is a counter example of your comment, "...instead of contributing to the greater success of the open source maker movement that enables their existence".

[+] amelius|5 years ago|reply
You can say the same thing about Apple, which, by the way, is also a kind of fruit. It looks like the fruity companies are reaping all the fruits from open source software.
[+] xrd|5 years ago|reply
What adafruit board would be best for a beginner (at circuit python but long time developer otherwise) dad and his 8 year old kid?
[+] gorgoiler|5 years ago|reply
Circuit Playground is the hardware product that goes hand in hand with CircuitPython, but you’ll probably want to program it using makecode instead.

Version 2 called “Circuit Playground Express” is currently very popular. V1 is obsolete, and there’s a version 3 with Bluetooth. All of them are pre-built with sensors, RGB LEDs, and buttons. This removes a huge hurdle: no soldering required. (Soldering is a fun skill but so is baking bread and cross country hiking — most kids are usually 100% focused on making blinking lights and don’t want to do anything tangential.)

Right now, only version 2 is supported by http://makecode.adafruit.com. makecode is different to CircuitPython: you write your code in JavaScript either using a visual block language or directly in the online JS IDE — both of which are very high quality dev environments with excellent discoverability — and compile everything into a new .UF2 firmware for the device to load each time. The site provides an emulator which is another killer feature. You can go there right now and start programming a board.

CircuitPython on the other hand is itself a pre baked UF2 firmware with a Python interpreter built in. Because your dev tools (runtime, debugger) are now on the device you have less memory to play with and it’s less stable, in my experience. It’s also not immediately obvious how to get things done, compared with the makecode IDE.

With my teenage pupils it was only the makecode JS / block programming that lit up their eyes. The Python tools were too weird. Devices like this are about playfulness and doing weird stuff, and only tangentially about programming, I’ve found.

The killer feature of Circuit Playground was the v2/“Express” (CPE) board with its infrared transmit and receive functionality. Connectivity turns these things from toys into real hacking platforms. I spent the holidays making IR “WiFi” for a pool of 8 CPEs.

The v3 Bluetooth-enabled board sounds great but it won’t be as popular with my classes if it doesn’t support makecode (which it currently does not.)

[+] kylepdavis|5 years ago|reply
Great timing. I just showed my kids some of the things you can do with this on the Circuit Playground Bluefruit[1] earlier today. It comes with a lot of sensors and is full of possibilities.

For getting started fast I can't recommend MakeCode[2] enough. It's a web IDE with a compiler and device simulator for programming microcontrollers with blocks or JavaScript/Python.

That said, for more complex projects CircuitPython might be a better choice. There are tons of docs and lots of great examples. It re-runs your code every time you save so you get instant feedback. Also, the vscode-circuitpython[3] plugin has been really nice too.

[1]: https://www.adafruit.com/product/4333

[2]: https://maker.makecode.com

[3]: https://marketplace.visualstudio.com/items?itemName=joedeviv...

[+] riq_|5 years ago|reply
from a programming point of view, all are the same. But if you want to introduce your kid to play with sensors and other stuff, I'd get Playground Blefruit[1]

[1]: https://www.adafruit.com/product/4333

[+] raykamp|5 years ago|reply
Adafruit’s line of “featherboards” are pretty neat and user friendly. For circuit python, you plug the board in over usb. It’s detected as a mass storage device like a usb drive. You drag and drop a python file over to it that you want to run. https://www.adafruit.com/product/4516
[+] decko|5 years ago|reply
I have a few of their boards and my experience with them could have been a lot better.

Their documentation is rather poor. Parameters to function/constructors are often left out, leaving you to go through the source to figure out how stuff works.

The standard modules can have different functions/variables between different boards. It makes sense since some boards have capabilities others don't. However there is no documentation on this.

Finally, in my opinion, some of the adafruit_* libraries are not well designed. There are many "kitchen sink" libraries that try to do everything. I also noticed that while they do appear to use pylint to enforce good standards, almost all source files have at least one check disabled...

[+] brennen|5 years ago|reply
> I also noticed that while they do appear to use pylint to enforce good standards, almost all source files have at least one check disabled...

I haven't touched any of the CircuitPython hardware libraries in... Well, something close to two years by now, I think. A lot has probably changed. Still, when I was last involved, placating pylint was consistently a hassle.

As I recall it squawks about things like identifiers that don't conform to snake_case. All well and good as a general stylistic suggestion, but not especially helpful when that's what the thing is called.

There may be some bad ideas lurking in places where those checks are disabled, but in general I blame no one for disabling one or more of its checks in service of greater readability or better code layout.

[+] jonwest|5 years ago|reply
I know there’s some half decent support for ESP boards with MicroPython, is that also the case for Circuit? Getting Adafruit gear in Canada is prohibitively expensive in comparison unfortunately, as much as I’d like to support the creator.
[+] aweb|5 years ago|reply
I looked at it in depth, they unfortunately don't seem to support anything else than ESP32-S2. To be honest, MicroPython is pretty good and you can use it without missing CircuitPython
[+] cozzyd|5 years ago|reply
This certainly feels like magic... until you run out memory.

It's probably more useful on microcontrollers with more than 32 kB of RAM.

[+] musingsole|5 years ago|reply
I built a really fun library to represent I2C modules as a collection of classes to interface with them at various levels that equated to a whole lot of class instances (an instance per register, and an instance per interesting group of registers, and so on)

Really fun in dev...really fun with my small test device. Then I loaded the config for a complicated I2C module and quickly blew out my memory. I was sad that I had to revert to more mundane means of I2C, but whatever.

A newer version of that same board has more memory. Perhaps it could support my mammoth I2C model.

[+] hellweaver666|5 years ago|reply
Adafruit also have a python library called Blinka that enables you to use Circuit Python on devices such as the Raspberry Pi
[+] mrwoggle|5 years ago|reply
CircuitPython and MicroPython are great for hobbyists or if you need to prototype something quickly.

It becomes very limiting for bigger embedded applications. Is the chip and are all peripherals supported? Probably not.

[+] voicedYoda|5 years ago|reply
Good! I'm happy to see more progress here.
[+] Dowwie|5 years ago|reply
I wish these technologies were around when I was a kid.