CircuitPython: Programming Hardware in Python(github.com)
github.com
CircuitPython: Programming Hardware in Python
https://github.com/adafruit/circuitpython
86 comments
"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.
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.
Presumably the parent is comparing Python to C. There’s no way anyone is more productive in C than in Python.
I’ve been working on altimeters for model rockets using both C and Micropython on Adafruit’s feather series and a couple other boards. The thing with C is the tool chain setup is 3/4 the battle. It’s a huge LOE to go from nothing to a blinking led (the embedded hello world) with C. With micropython it’s 5 lines, drag/drop a file, and reboot.
I appreciate C and I’ve learned a lot of things like peripheral clock multipliers and all the work that has to be done before you can even jump to main. However, I set out to make an altimeter heh.
Edit: oh and with C, writing your own device driver for every single thing is a pit of a pita too. There are open source drivers for some breakouts but they all seem to require serious hand fitting.
I appreciate C and I’ve learned a lot of things like peripheral clock multipliers and all the work that has to be done before you can even jump to main. However, I set out to make an altimeter heh.
Edit: oh and with C, writing your own device driver for every single thing is a pit of a pita too. There are open source drivers for some breakouts but they all seem to require serious hand fitting.
Have you tried PlatformIO? New projects get set up in about 30 seconds.
If you are forced to write pure C (or a very low level subset of C++) , then that is often because:
- you need every tiny bit of performance,
- you optimize for low executable size or low memory footprint (e.g ATTiny13)
- you have an exotic architecture that offers only a C compiler or ancient C++ compiler from 90s,
- you need to use C for other reasons like safety certification, e.g. MISRA C.
In all of these cases Python wouldn't work at all.
And in the others your can use modern C++ which can be just as productive as Python (in my case it is more productive, but I have probably spent more time with it than with Python, so I'm biased).
- you need every tiny bit of performance,
- you optimize for low executable size or low memory footprint (e.g ATTiny13)
- you have an exotic architecture that offers only a C compiler or ancient C++ compiler from 90s,
- you need to use C for other reasons like safety certification, e.g. MISRA C.
In all of these cases Python wouldn't work at all.
And in the others your can use modern C++ which can be just as productive as Python (in my case it is more productive, but I have probably spent more time with it than with Python, so I'm biased).
For twiddling GPIO pins, I can be most productive in C (or the C subset of c++ for pedants).
Twiddling GPIO pins and doing other bit gymnastics is a fair bit of simple sensor interface microcontroller projects, which is a large overlap with the target for CircuitPython.
Twiddling GPIO pins and doing other bit gymnastics is a fair bit of simple sensor interface microcontroller projects, which is a large overlap with the target for CircuitPython.
That's a really disappointing attitude to see in the wild.
How so?
I've been plenty productive in C, as are a multitude of people who would pick type safety over the lack of it.
I know a lot of people for whom both are much more productive in python than in any other language, including myself. If that's not true for you, you must have different preferences.
Let's just find our own language each one and not bash others' choices, maybe?
Let's just find our own language each one and not bash others' choices, maybe?
This is for embedded programming which is totally different to the sort of programming your thinking of.
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.
CircuitPython describes itself a fork of MicroPython, with the major difference being its deployment workflow. What makes it a “toy” by comparison in your book?
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.
> Out of curiosity, what about this particular project made you opt for CircuitPython?
It was a nonprofit-style project without much wiggle room. We wanted to prove that an idea would or would not work in a small amount of time, which happily overlapped with the fact that the target environment for the device wouldn't require long periods of battery life. I'm happy to say that the project was a success so who knows, maybe one day we'll have someone port it to C and continue from there.
Sorry I can't be more specific.
It was a nonprofit-style project without much wiggle room. We wanted to prove that an idea would or would not work in a small amount of time, which happily overlapped with the fact that the target environment for the device wouldn't require long periods of battery life. I'm happy to say that the project was a success so who knows, maybe one day we'll have someone port it to C and continue from there.
Sorry I can't be more specific.
No worries, that was plenty of detail, thank you. I fully understand working on things you can't discuss the specifics of.
It would be very interesting to hear more about your project and, if you did some benchmarks, about the increased draw on the battery.
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.
There's MyHDL. Turns Python into a hardware description and verification language:
https://github.com/myhdl/myhdl
https://github.com/myhdl/myhdl
See also the list from my low-level hardware description language unification idea[1]. There are mostly active projects.
[1] https://github.com/SymbiFlow/ideas/issues/19
[1] https://github.com/SymbiFlow/ideas/issues/19
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.
> “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.
At a minimum it's unnecessarily vague--hardware is far too broad when it's really just microprocessors. For that matter, in the way they use it, "programming hardware" applies to all code that runs on a computer.
Anyway, my first impression was same as parent's, write Python get hardware.
Anyway, my first impression was same as parent's, write Python get hardware.
> If the headline had said "designing hardware circuits", that would be another story entirely.
It almost does though. The name of the project has "circuit" in it (I guess because of Arduino applications or something?), and if you are confused why we're talking about circuits, well you can read on where the title goes on to double down on being about "programming hardware".
It almost does though. The name of the project has "circuit" in it (I guess because of Arduino applications or something?), and if you are confused why we're talking about circuits, well you can read on where the title goes on to double down on being about "programming hardware".
> 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.
One does not "program hardware" except maybe in a CPLD. You cannot write code for a resistor or a tranzistor. You program maybe the microcontroller which is present on the board.
One does not "program hardware" except maybe in a CPLD. You cannot write code for a resistor or a tranzistor. You program maybe the microcontroller which is present on the board.
Neither CPython or MicroPython are meant to be a long departure from Python itself.
CPython IS the normal Python you get from python.org, It's only ever called CPython when discussing it in the context of other pythons like MicroPython, PyPy, Jython, etc.
CPython IS the normal Python you get from python.org, It's only ever called CPython when discussing it in the context of other pythons like MicroPython, PyPy, Jython, etc.
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:
[1]: https://github.com/olooney/circuit
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)
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)
[1]: https://github.com/olooney/circuit
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.
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.
> 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.
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.
CircuitPython is a toy language made for running on Adafruit's halloween/cosplaying gadgets.
It doesn't even support interrupts.
Better use Micropython.
It doesn't even support interrupts.
Better use Micropython.
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?
Python is everywhere in education, F# and Elixir are niche languages.
If you want to use F#, you might get lucky with Meadow boards, yet their focus is mostly getting C# to run on their runtime.
If you want to use F#, you might get lucky with Meadow boards, yet their focus is mostly getting C# to run on their runtime.
Lots of developers already know python, and if you don't it's easy to get rolling.
For pyboard, it's STM32F4 with about 200Kb of RAM. AFAIK, F# and Elixir target VMs (CLR and BEAM) and it seems unlikely that those VMs plus your code will fit on such a chip.
Ease of use and familiarity to people who aren't principally interested in programming. These are people who want to make things work using microcontrollers.
To be fair, this is really mostly just a rebranded MicroPython...
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).
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).
I have played a bit with MicroPython and I had heard of CircuitPython but wasn't across the differences and reasoning behind the fork. Limor actually did the Sunday morning Keynote at the the Linux.Conf.Au conference held over last weekend where she went into into a lot of things that were around repeatability and accessibility especially for novice programmers. The video will have been recorded but yet to be published and I would expect it to be linked from the abstract page [1] soon and/or on the LCA YouTube [2] channel.
[1] https://linux.conf.au/schedule/presentation/122/ [2] https://www.youtube.com/c/linuxconfau/featured
[1] https://linux.conf.au/schedule/presentation/122/ [2] https://www.youtube.com/c/linuxconfau/featured
[deleted]
As promised, here is the keynote speech at linux.conf.au last weekend by Limor Fried from Adafuit on the reason and drivers behind CircuitPython https://youtu.be/jZnDCs80b_A
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.
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.
Out of curiosity which products did you buy and what was different about them?
Also, multi million could mean $2m/year which if you pay your employees well would translate to like 25 employees if you make no profits and only pay salaries.
Lastly, having bought loads of stuff from AliExpress and recently from AdaFruit, the latter absolutely has higher quality items. They are not simply reselling what’s available directly from China but are legitimately designing their own boards which are better thought out than the generic parts you can get for cheaper.
Also, multi million could mean $2m/year which if you pay your employees well would translate to like 25 employees if you make no profits and only pay salaries.
Lastly, having bought loads of stuff from AliExpress and recently from AdaFruit, the latter absolutely has higher quality items. They are not simply reselling what’s available directly from China but are legitimately designing their own boards which are better thought out than the generic parts you can get for cheaper.
It has 7,000 more commits than MicroPython, to say it is a rebrand is unfair.
You probably looked at the 'xxx ahead, yyy commits behind miscropython' bit here and subtracted them to get that number?
Even though I agree CP is definitely more than just a rebrand (in fact it's fairly interesting what they did), relating number of commits to the rebranding statement is not entirely correct.
Because you're measuring features and/or amount of work done in number of commits, and that is not a simple fixed relationship.
Just browse the first couple of commit pages [1] to see what I mean (just 2 examples: a commit with message 'pre-commit' which deletes 4 newlines, a commit with message 'alphabetical' which moves 2 statements around). Could also take a look at the MicroPython commits [2] in turn to see what a, in my opinion, very sane git tree looks like)
[1] https://github.com/adafruit/circuitpython/commits/main [2] https://github.com/micropython/micropython/commits/master
[1] https://github.com/adafruit/circuitpython/commits/main [2] https://github.com/micropython/micropython/commits/master
I read the readme differences, but any obvious benefits to one or the other?
I was just having a chat w/ a contributor yesterday and he told me a large aim of Circuit Python over MicroPython is to make the code you are writing in Circuit Python more transportable.
I.e. You write code in circuit python, and that same code will run on a little micro, and also a full blown Raspberry Pi.
This is apparently done at the expense of some prettiness.
I.e. You write code in circuit python, and that same code will run on a little micro, and also a full blown Raspberry Pi.
This is apparently done at the expense of some prettiness.
Core modules are a bit better laid out, meaning you will have a more unified experience across different dev boards. Additionally, there are more boards that appear to be supported, but don't quote me on it. Things like os/time/filesystem stuff act how you would expect running cython. IIRC the big selling point is anything that you can run on CircuitPython you can run in cython, whereas with MicroPython some of the OS and time functions act differently, so might not work without code changes.
Point of clarification: By Cython do you mean Cython or CPython?
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.
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.
Then it should have been a library, not a fork.
[deleted]
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.
For most non-programmers (which is the target) support is much more important than issues with forks or OSS politics.
Yep. AFAIK CircuitPython focuses more on low memory microcontrollers and less on connectivity.
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.
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.
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.
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".
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".
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.
What adafruit board would be best for a beginner (at circuit python but long time developer otherwise) dad and his 8 year old kid?
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.)
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.)
This is a fantastic write-up. Thank you.
Are the details of your classes online anywhere?
Are the details of your classes online anywhere?
Thanks. I don’t, but you don’t need the structure of a class. My Circuit Playground stuff all happens as an after school club.
I let the kids riff, then review their project before showing them a new idea. It’s like they are learning a modern era computer game where there are no manuals, only self discovered game mechanics.
(CS classes have much more structure but are more niche and for the older pupils.)
I let the kids riff, then review their project before showing them a new idea. It’s like they are learning a modern era computer game where there are no manuals, only self discovered game mechanics.
(CS classes have much more structure but are more niche and for the older pupils.)
What do you think of LEGO Boost and LEGO Mindstorms?
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...
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...
It's not Adafruit (although they make lots of kits for it) but I'd advise the micro:bit v2 (https://microbit.org/new-microbit/)
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
[1]: https://www.adafruit.com/product/4333
Seconded. Pick something with wireless connectivity and lots of on-board sensors/LEDs.
any add-ons that you’d recommend? or other stuff for kids playing with Python?
maybe an arduino board plus a raspberry pi?
maybe an arduino board plus a raspberry pi?
Depends on the level of abstraction you and your kid are willing to get into.
Arduino's are lower-level C/C++ which may be a little more complex than CP, but have much broader library support (better intro to EE/embedded).
RPis are much higher level which could be programmed in any language (better intro to CS/Linux).
Arduino's are lower-level C/C++ which may be a little more complex than CP, but have much broader library support (better intro to EE/embedded).
RPis are much higher level which could be programmed in any language (better intro to CS/Linux).
for kids, so ideally not as low as C++
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
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...
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...
> 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.
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.
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.
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
Several ESP boards are supported [0].
[0] https://circuitpython.readthedocs.io/en/latest/shared-bindin...
[0] https://circuitpython.readthedocs.io/en/latest/shared-bindin...
A circuit python is basically an ouroboros. This should be its name.
I can't tell if you're serious or just joking but they do have a variant of their logo that's an oroboros [0]
[0] https://www.dropbox.com/sh/l6tp9ym5nf8h5v9/AABC0Zd7_v4BWmBaZ...
[0] https://www.dropbox.com/sh/l6tp9ym5nf8h5v9/AABC0Zd7_v4BWmBaZ...
This certainly feels like magic... until you run out memory.
It's probably more useful on microcontrollers with more than 32 kB of RAM.
It's probably more useful on microcontrollers with more than 32 kB of RAM.
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.
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.
Adafruit also have a python library called Blinka that enables you to use Circuit Python on devices such as the Raspberry Pi
right but you can just use... regular python... there, with the entire ecosystem.
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.
It becomes very limiting for bigger embedded applications. Is the chip and are all peripherals supported? Probably not.
Good! I'm happy to see more progress here.
I wish these technologies were around when I was a kid.
Just pretend you're still a kid.
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.