Python is often touted as a great language for beginner coders to learn. Until recently, however, it simply wasn’t a viable choice in the embedded space. That’s begun to change with projects like CircuitPython, and now it’s available on the Teensy 4.0!
This milestone is thanks in part to [arturo182], who did the ground work of getting CircuitPython to run on the iMX RT series of microcontrollers. This was built upon by [tannewt], who is the lead in charge of the CircuitPython project.
There are some bugs to work out; currently, the project is in a very early stage of development. [Paul Stoffregen], who heads Teensy development, has already pointed out that there needs to be allowance for the 4096 byte recovery partition in the Teensy 4.0’s storage, for example. Development continues at a rapid pace, and those with ideas about where the project should go can weigh in online.
It’s an exciting development, which brings easy Python development to one of the more powerful embedded development platforms on the market. We look forward to seeing many more projects take advantage of the power of the Teensy 4.0 moving forward. If you’re eager to see what can be done with CircuitPython, be sure to check out projects we’ve featured before. Video after the break.
I wish CircuitPython would explain exactly what it is. Do you code in python and it converts that to assembly?
https://en.wikipedia.org/wiki/CircuitPython
While they forked of Micropython, anyone knows why they forked and renamed it? There are forks of MicroPython for various other platforms as well, and they didn’t feel like the need to rename the project.
It is pretty cool if you have an overpowered microcontroller and just want to quickly put something together. And as controllers are cheap these days, there generally isn’t a huge reason not to use micropython/circuitpython for a quick one-off project.
It seems there were slight differences in opinion of what the focus should be, e.g. ease of use vs speed and efficiency, so I take it they renamed it to make it clearer that it’s a fork with a different focus rather than something more minor.
See the discussion and links here: https://forum.micropython.org/viewtopic.php?f=16&t=2894
CircuitPython is a trademark of Adafruit Industries, so that may be a clue.
You’re right. Looks like Adafruit registered it only a few months ago.
http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4801:9i1vmu.5.1
Hi all, I’m Scott Shawcroft. I didn’t say explicitly before but I am the lead for CircuitPython for Adafruit. I’d like to clarify the trademark stuff.
Adafruit is working directly with the Python foundation’s legal team and Damien (MicroPython) to help protect the name “Python” and variants like MicroPython and CircuitPython.
It became an issue because a Chinese seller of MicroPython boards had registered the MicroPython trademark in China and was preventing other Taobao sellers from listing.
It was brought up on the MicroPython forum here: https://forum.micropython.org/viewtopic.php?f=2&t=6971&p=39702 Adafruit publicly documented it on the Adafruit blog here too: https://blog.adafruit.com/2019/10/05/micropython-trademark-in-china/
Adafruit is working with MicroPython, and the Python foundation, to figure out what will help Damien, Adafruit, and the community the most, including registering CircuitPython in the USA and China.
Adafruit is donating time and resources to both Python and MicroPython for this and all of the ongoing Python and MicroPython efforts.
RTFM at circuitpython.org:
“It’s a high-level programming language which means it’s designed to be easier to read, write and maintain. It supports modules and packages which means it’s easy to reuse your code for other projects. It has a built in interpreter which means there are no extra steps, like compiling, to get your code to work”
Yeah but the CPU itself can’t run python. Is it running an OS or bootloader with an interpreter? When the python code changes the state of a pin how is it telling the CPU?
“CPU itself can’t run python”
Why not?
CircuitPython is written in C under the hood. It parses Python code into byte codes which run through a big loop in C. There are also Python modules that are implemented in C for interfacing with the hardware. The VM will call into these C modules based on the Python byte code and the C module will set the pin value (or do whatever) just like regular embedded C programming. This gets us the best of both worlds, the fast iteration of Python plus the fast C code under the hood.
The compiler produce a bytecode for a virtual machine like C python does.
That’s all I was trying to find out. Thank you.
As far as I know MicroPython also supports REPL, which means, you add a serial console, type in text and your uC board interprets it.
Apparently there is also a “Web REPL”, which works over sockets.
I’m not sure, but I have vague memories that REPL has scrapped in circuitpytyhon.
Micropython also runs on an ESP8266, which is probaby a bit cheaper to try it out than those Teensy boards, but you may have to flash the esp8266 (or other supported board) first to get Python on it.
This 10min video seems to be a nice introduction on how a MicroPython board works:
https://www.youtube.com/watch?v=5LbgyDmRu9s
Also: MicroPython is based on Python3, and after a few minutes of searching I gave up on which version of Python that circuitpython is based, but I assume its python 2, which is officially obsolete as of this month.
Pleasy move on (after 10 years!) and try to forget python2. 10 years of 2 incompatible python versions is already much more than should have been.
re: paulvdh
CircuitPython has a REPL as well although it doesn’t include the leftover VM state from main.py. We do not have a WebREPL like MicroPython because we don’t support ESP (wifi) chips.
CircuitPython is a fork of MicroPython so it shares the same VM core and is, therefore, also Python 3.4+.
Ooh, I’ve just bought a Teensy 4. I really like having CircuitPython on boards which also run Arduino/C, my knowledge of Python is much better so I can do a quick prototype in CircuitPython to get the design and function straight in my head and then figure out how to achieve that in Arduino/C. Knowing that my general idea of how peripheral interactions should work is fine because the CircuitPython version works can be a useful reference for debugging my poorer Arduino/C version.
Out of curiosity, aside from performance and memory footprint, is there a compelling reason to re-code it in Arduino/C if you already having it working in CircuitPython? Again, assuming performance is acceptable and it all fits properly into memory…
One area we (CircuitPython) need to improve is power consumption. Right now when “sleeping” we’re busy waiting using the CPU instead of actually idling. It’s on our radar and something we plan on improving this year.
Besides that, I don’t know why you’d rewrite it if it all works ok.
Occasionally performance, partly also a desire to be better at Arduino/C++ for other projects I’d like to eventually do. Python is showing up in a lot of places but C/++ still seems to be the universal language. Plus, if I can talk to I2C/SPI devices properly with Python but not Arduino/C then I know it’s my C code and not my understanding of how to talk to the devices which is wrong. Some chips have fairly odd (to a self-taught amateur) requirements for how you talk to them, and I still feel like my Arduino/C is very clumsy.
Thread on PRC for announcement and about some bugs in ckt py.
https://forum.pjrc.com/threads/59040-CircuitPython-on-Teensy-4
While circuitPython is very cool, I’d very much prefer to see an official MicroPython port for the Teensy 4.0.
Any chance you might elaborate on why you prefer MicroPython over CircuitPython?
Really, seriously do what to hear why, as I’m currently in the process of deciding which I will work towards supporting? (or perhaps a hybrid?)
For starters MicroPython is the original “python for microcontrollers” project. I like the balance of functionality, and compatibility with CPython vs ease of use that Micropython tries to achieve.
CircuitPython is a fork of Micropython that emphasizes even more ‘ease of use’ and was intended (at least initially) to run on a low performance cortex-m0 microcontrollers. It means that the API modules are a bit simpler , giving the programmer less control over the hardware peripherals such as ADC or I2C modules. It also lacks things like concurrency, deep-sleep (last I checked) and interrupt functionality.
Admittedly I haven’t used circuitPython on the teensy 4.0 so this opinion is based on my experience running circuitpython on samd21 vs micropython on the stm32f411
I have been programming uC’s in C and C++ from before Python existed, and don’t have much interest in Python on a uC. Though I can se some use of it (For example generating test signals while breadboarding / testing new electonic circuits)
Just did a search for circuitpython on the MicroPython forum:
https://forum.micropython.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=circuitpython
Results are very likely biased.
It seems that circuitpython is more targeted to absolute beginners, and thereforehas bloated it’s libraries to make them more compatible among different target boards, while MicroPython is apparently more compact and has more functions.
I have no personal experience with either, but if I were to experiment with it, it would definately start with the original micropython instead of adafruit’s fork.
Does anyone know why Adafruit forked micropython into circuitpython?
To me it looks like vendor lockin, as I assume that adafruit made libraries for a lot of their boards for circuitpython.
According to the micropython forum, porting a library from circuitpython to micropython is usually done by “throwing half the code away”.
Teensy 4.0 also seems to be popular on the micropython forum:
https://forum.micropython.org/search.php?keywords=Teensy+4.0
There seems to be a mature port for the rt1050/rt1060 here https://github.com/RockySong/micropython-rocky
“…That’s begun to change with projects like CircuitPython…”
don’t you mean:
“…That’s begun to change with projects like MicroPython…”?
Fair play to CircuitPython and this project, which is great, but credit where its due.
Brand awareness is provided via a bigger marketing budget :)
Ditto,
Since from the first crowd funding campaign a lot of hard work has gone into MicroPython by it’s founders and the community, particularly the initial concept for the adaption which got the project rolling. I find the breathless articles on the wondrous new innovative CircuitPython somewhat tastless and consequently lacking in validity. They took someone elses work, hung a new name on it and did some fiddling to sell their products with it. Adafruit could have provided a branch, shown some ongoing respect by staying with the project and gained some kudos to boot. Now the efforts are divided and the overall impact is to the detriment of the community.
It’s kinda like when arduino.org tried to take control of Arduino. Ironic really, seeing as Adafruit were instrumental in their demise and returning control back to arduino.cc.
exactly. To me it’s not about respect, it’s about actually getting things, done, though. Is this even a brick in the wall, a single brick? I guess so, it should save work for when the real effort to port comes. It is a nice board. But until then it appears to have no actualy use case, as far as I can see.
When you say ‘working’, I’d say barely and even then only on adafruit hardware simply to keep us in their ecosystems. I’m very wary of being locked in like this which is reason enough to avoid CircuitPython. I have a few things that work in micropython (ok, on other boards to be fair) which I’ve tried to port to CircuitPython that simply don’t work. Adding to the frustration is the terrible documentation which is largely incomplete forcing me to dig into the source and examples to try and work out the properties and methods available in modules. In one case I’ve had to take a module that already exist in micropython and port it myself to circuitpython only to find the adafruit_frambuf makes a mess of the text() by outputting dotted lines rather than the text.
The adafruit circuitpython website is so badly organised it’s very difficult to find information that’s needed.
I’m going to switch back to other devices and micropython, or even back to c++ for the projects where I don’t need them to be understood by beginners.
headdesky, facepalm
Although on one level I greatly appreciate the sheer amount of skill and work and how well done things are, we are just doing things so so wrong as a community.
Dozens of different boards and ports and so on, all of them only half working. You say this is “working” when it doesn’t even support interrupts? And as far as I can tell, it still doesn’t, and it’s feb 2022 now.
Micropython was released in 2014 and has changed remarkably little since then. There are absurd limitations and bugs and problems galore.
At the same time, it is amazing how well it does work and I do appreciate it. There is a certain duality.
But the problem arises when you realize just how much successful engineering it takes to actually improve life in any way. When you really see this big picture, you realize how much people are going around in circles and digging over and over again holes that are way too shallow.
For any given challenge or project, there should be at least one good quality, effective way to go. At least one board, one software ecosystem, with a whole set of libraries for what you need to do. We haven’t been working toward that at all. Instead it’s all these random projects, on the one hand the teensy 4.0 is like 40 bucks CAD and tremendously powerful, so good going. But the other parts of the system just so aren’t there. No interrupts?? And any driver or library you need won’t be available.
To the hobbyists this is only an annoyance which makes things less fun, it’s only about the journey to them. To the kids, it’s a problem but they don’t understand it and can’t vote so get ignored. For the people making products, they can afford to spend the ton of time it takes to overcome the insufficiencies.
The people who really get it in the pants are the people who are trying to do real things on a limited budget of time and money, that’s when the issues really show. But fundmentally, better stuff is going to be better for everyone.
Arduino is really the only way to go, and this doesn’t change that. We should. We should come together as a community and fund the porting and fleshing out of an ecosystem of libraries for micropython for a handful of boards in different price ranges, carefully chosen. And we should do this type of thing for the hardware, and the systems that we build with said boards.
Basically I guess what I crave is more smartness on the part of the community, multiplied by time. This is so absurd. It’s not buliding anything anyone can stand upon. This release of circuitpython changes essentially nothing. You can’t really use it for quick prototypes because what you need won’t be supported, or you will run into bugs or insufficiencies that take so long to solve you might as well have just used arduino.
It is a start, I will grant that, but unless we take it further it serves no purpose but to lure people as a marketing gimmick.
I can agree 100% with that. On my latest bigger CircuitPhyton project I used the DMA2DAC for sending audio generated in memory. I found an wrong configuration in the DAC registers. i contributed the correction on Github and the next relaese was fine. The very next realase was not working again. I’am not willing to debug this fault again. Did you ever look at the code for Circuitphyton? To support all the boards there ist so much wrapper code you get lost in it.
In times where C64 and IBM-PC defined standards was the real innovation period.