Adafruit's New CircuitPython 'Turbo' Brings Native Code To Tiny Boards (adafruit.com) 45
Targeting students and beginners, Adafruit released "CircuitPython" in 2017 (as a derivative of the MicroPython microcontroller-optimized programming language).
Now Adafruit managing director Phillip Torrone (also long-time Slashdot reader ptorrone) brings this update: Adafruit has published CircuitPython Turbo, a workflow that compiles selected Python functions into native machine code on a computer, then loads them onto compatible microcontroller boards.
It builds on MicroPython's Native and Viper emitters. In a documented Metro RP2040 fixed-point Mandelbrot test, Viper cut computation time from 8.335 seconds to 0.423 seconds, a 19.71x speedup over bytecode. The rest of the application stays in Python. The guide includes benchmarks, source code and hardware demos. The speedup is for the measured computation, not the whole application.
"Turbo support is now included in the latest official CircuitPython builds for RP2040 and RP2350 boards..." explains Torrone's announcement at Adafruit.com. "The new Turbo in CircuitPython helps when the board spends time calculating: making neopixel effects, drawing fractals, processing audio, filtering sensor readings, or preparing lots of pixels. Those projects can get smoother animation, quicker responses, or room to do more things at once." With Turbo, it's easier, better, and now even faster to make LED light up costumes that also reacts to sound at the same time, a sensor dashboard with animated graphics, or a tiny game doing physics while drawing the screen. Turbo speeds up the busy Python parts. It won't make a slow sensor or display connection faster... Your computer turns selected functions into instructions the chip can run directly. Python still handles the rest.
We have measured speedups, real display captures, and examples you can pull apart to see what happened. None of this arrived alone. CircuitPython, MicroPython, PyMCU, compiler tools, open hardware, and people sharing their work gave us pieces to connect. The Bao experiments take that idea somewhere else, handing calculations to four helper cores. Now we get to make those paths easier to use, compare results, and find the next useful thing. Maybe that's smoother animation, a responsive instrument, or an idea we haven't tried yet.
That's what I like about open source. Someone shares a piece, someone else sees a possibility, and we get to keep building it together.
Now Adafruit managing director Phillip Torrone (also long-time Slashdot reader ptorrone) brings this update: Adafruit has published CircuitPython Turbo, a workflow that compiles selected Python functions into native machine code on a computer, then loads them onto compatible microcontroller boards.
It builds on MicroPython's Native and Viper emitters. In a documented Metro RP2040 fixed-point Mandelbrot test, Viper cut computation time from 8.335 seconds to 0.423 seconds, a 19.71x speedup over bytecode. The rest of the application stays in Python. The guide includes benchmarks, source code and hardware demos. The speedup is for the measured computation, not the whole application.
"Turbo support is now included in the latest official CircuitPython builds for RP2040 and RP2350 boards..." explains Torrone's announcement at Adafruit.com. "The new Turbo in CircuitPython helps when the board spends time calculating: making neopixel effects, drawing fractals, processing audio, filtering sensor readings, or preparing lots of pixels. Those projects can get smoother animation, quicker responses, or room to do more things at once." With Turbo, it's easier, better, and now even faster to make LED light up costumes that also reacts to sound at the same time, a sensor dashboard with animated graphics, or a tiny game doing physics while drawing the screen. Turbo speeds up the busy Python parts. It won't make a slow sensor or display connection faster... Your computer turns selected functions into instructions the chip can run directly. Python still handles the rest.
We have measured speedups, real display captures, and examples you can pull apart to see what happened. None of this arrived alone. CircuitPython, MicroPython, PyMCU, compiler tools, open hardware, and people sharing their work gave us pieces to connect. The Bao experiments take that idea somewhere else, handing calculations to four helper cores. Now we get to make those paths easier to use, compare results, and find the next useful thing. Maybe that's smoother animation, a responsive instrument, or an idea we haven't tried yet.
That's what I like about open source. Someone shares a piece, someone else sees a possibility, and we get to keep building it together.
Re: M5Stack ran fine with Python 10 years ago (Score:2)
Re: (Score:1)
Why, does it not work?
The classic argument is that we are dealing with embedded devices with limited resources and possibly need real-time like responses.
But we're largely talking about educational projects, hobbyists projects, so such problems are probably a lesser concern. Wiring up a breadboard with devices and getting things to work is the important thing here. The language an implementation detail.
Will it burst into flames when I say : Turbo Turbo (Score:2)
Wat een goei!
https://www.youtube.com/watch?... [youtube.com]
Press turbo (Score:2)
Why? (Score:3, Interesting)
Re: Why? (Score:5, Insightful)
Re: (Score:3)
This. I’ve seen plenty of seasoned engineers with breadboards on their desk, and you certainly don’t find those laying around in live production.
If the tool needed for a job is a training tool, who cares. It’s the right tool. CPR class always uses a dummy. Doesn’t make the teacher a moron.
Re: (Score:2)
Re: (Score:2)
That is a false equivalency. Breadboards are great for both education and prototyping (though primarily the former). But python on a microcontroller is just _silly_ and teaches the wrong thing. If you want to learn to code, great - learn python, on a non-embedded system. If you want to learn embedded systems, great - learn to code, then learn embedded basics. But trying to shoehorn python into an embedded environment is like going out of your way to tie yourself into a pretzel, just so you can do something that doesn't make sense.
Fine. Then justify it with cost then. They sure as hell justified breadboards in education due to cost.
Seems to me they’re trying to teach Python AND embedded systems. It’s not like Python is a controlled classified language only to be used in the secured classroom on approved hardware. Any student is capable of putting it on other hardware to learn. At their cost.
Re: Why? (Score:4, Insightful)
Re: (Score:3)
Not sure I see the cost argument? I don't think I ever paid more than $15 for a breadboard.
I was referring to materials cost in education. They can be cheap. Microcontrollers are an inexpensive solution, and meeting a need seen by a very large and influential organization that clearly sees the demand when developing a microcontroller specific variant of Python.
Yes. I see your point. Do we see theirs?
interpreted language on a microcontroller requires too much suspension of disbelief, especially when learning a more embedded-appropriate language requires only marginal additional effort.
Regarding goals..
With Turbo, it's easier, better, and now even faster to make LED light up costumes that also reacts to sound at the same time..
Python is one of the most used languages on the planet. And it doesn’t sound like you’re getting deep in the coding weeds with those use cases. Speaking of Code Lite
Re: (Score:2)
An interpreted language on a microcontroller requires too much suspension of disbelief,
It is not interpreted. Learn to read.
Re: (Score:2)
It is not interpreted. Learn to read.
I read TFS, and it says some of it is compiled and some of it isn't.
Re: (Score:2)
It clearly says it is compiled to C and then to machine code.
Re: (Score:2)
Dude.
Back in the 80s I was running basic on a machine with a tenth of the RAM and less than a thousandth of the computing power. It did not "confound the learning process". These days I also often use the Arduino environment because the performance is adequate for me needs and so it's a waste of time to slog through the datasheet and do it all by hand.
Who cares if they are a bit different from python? I don't write C++ on an MCU in the same way I'm writing it on the server because I'm writing very differen
Re: (Score:2)
Re: (Score:2)
Fine. Then justify it with cost then. They sure as hell justified breadboards in education due to cost.
What are you talking about? Breadboards are used both in education, hobbyist, and professional environments for variable prototyping where possible due to their flexibility. The only time they aren't used is if a specific design doesn't function on breadboards (high speeds, high currents, noise, etc). Breadboards have nothing to do with being a training tool nor have they anything to do with cost.
Re: (Score:2)
Fine. Then justify it with cost then. They sure as hell justified breadboards in education due to cost.
What are you talking about? Breadboards are used both in education, hobbyist, and professional environments for variable prototyping where possible due to their flexibility. The only time they aren't used is if a specific design doesn't function on breadboards (high speeds, high currents, noise, etc). Breadboards have nothing to do with being a training tool nor have they anything to do with cost.
I was referring to the cost of materials in education. Also known as that training place you go to find out what the fuck you DO with a breadboard that is a training tool in that environment.
Everyone else found out rather quickly the cribbage pegs don’t fit.
And if the worlds most infamous micro-puter maker has announced their efforts to build and support a microcontroller specific version of Python, then there’s obviously demand for those types of end solutions. The answer isn’t always a
Re: (Score:2)
I was referring to the cost of materials in education.
So completely off topic and irrelevant post then? Got it.
then there’s obviously demand for those types of end solutions
False. Not all products meet a demand. In fact the vast majority of novel products actually create the demand in the first place. There is zero demand for Python on a microcontroller. But that doesn't mean it's not a good idea, and that on release of the product it will become adopted. Take for example the Arduino platform. There was no demand for a simplified abstracted C API for Atmel microcontrollers, ... until someone made it. The idea created the
Re: (Score:2)
There is zero demand for Python on a microcontroller. But that doesn't mean it's not a good idea, and that on release of the product it will become adopted. Take for example the Arduino platform. There was no demand for a simplified abstracted C API for Atmel microcontrollers, ... until someone made it. The idea created the demand.
So, a company is quite literally copying what has been proven to create demand in the past, and we're questioning their actions..why again?
Fine. We'll boil it down to Greed outside of education; Microcontroller manufacturer pushes microcontroller-specific version of software used the world over. Society chokes on the wafting stench of profit motive. Demand is shat out the end. News at 11.
Re: (Score:2)
Not all products meet a demand. In fact the vast majority of novel products actually create the demand in the first place.
Correct.
There is zero demand for Python on a microcontroller.
Incorrect.
Re: (Score:3)
Why is it silly? It's perfectly reasonable for lots of things.
The reason it's used a lot in education is because you're not teaching kids to write embedded programs for microcontrollers. You're teaching them how to program computers. The computer they're programming just happens to be a $5 one that can do things kids thing are cool like making animated patterns with LEDs.
Re: (Score:2)
Well, there are thousands of interesting micropython projects out there, hardly any of them appear forced.
I needed a custom motor controller that I can talk to over a webserver. It performs closed loop control via an encoder, controls DC auxillary motors and now ran without hiccups for years.
A "real" solution was estimated by an engineer to take four weeks. Micropython allowed to iterate on this in the field very quickly, and within a few days the system was completed.
Could a smaller microcontroller do t
Re: (Score:2)
Indeed. I built a Raspberry Pi Pico based controller for some flashing LEDs on my drone. It has red and blue LEDs and I wanted them to flash with the cycle of three short flashes then a pause; alternately the red LEDs then the blue LEDS. Took barely a minute to code that in python and dump it onto the board. In such cases it doesn't matter that the language is interpreted because the task is not demanding of the hardware.
The "Police Drone" still flies to this day! :-)
Re: (Score:2)
I've seen plenty of Python used in production... My question though is that I've found Python can be quite heavy on memory bandwidth, doing a lot of copying and transforming data so it can be processed. I guess that is less of an issue with embedded, but is it still an issue?
Re: Why? (Score:3)
Re: (Score:3)
Because:
a) the language does not matter
b) it is an easy to teach and easy to learn language
It's the wrong thing in production
No it is not. As it is COLMPILED! Are you stupid or what?
Your micro controller does not care if it runs compiled C, ADA or Python.
Re:Why? (Score:5, Insightful)
This is for fun, not "production." If someone hacks up something and got to play with pretty lights for 10 minutes before getting bored and building something else, that's great. And if they learned any engineering, that's a bonus. It's ok to stack your legos however the fuck you want to. I don't fucking care if a kid in 1982 did the "wrong" thing on his TI-99/4A or VIC-20. Been there, done that, got a 40-something year long career out of it despite my youthful unorthodox amateur whims.
Use python on quasi-embedded systems all you want to. Whatever figuratively gets you off your ass, is a good thing.
Re: (Score:3)
It's the wrong thing in production
Based on what? What makes something wrong or right in production providing the toolkit works and exists to allow it to be widely adopted and mass produced, and the end goal of the device is achieved?
I've seen similar complaints before: "Arduino has no place in production, it's too heavy on flash for microcontrollers, blah blah blah blah". Yet it too does the job, and does in fact get used in some production cases as well.
If you want to gatekeep, fine. Justify your position with points specifically relevant
Re: (Score:2)
Based on what? What makes something wrong or right in production providing the toolkit works and exists to allow it to be widely adopted and mass produced, and the end goal of the device is achieved?
Exactly. About the only thing that matters for "in production" is "meets requirements", whatever those may be. It's pretty rare that one of those is "squeeze the maximum possible performance out of a single-cycle multi-hundred MHz MCU". Sure for mass, low cost consumer products, it's worth pending a lot to save
Re: (Score:2)
Engineers need to remember that time exists.
You have three months to teach a teen how to control a robot with a microcontroller.
OK, how much of that do you budget to CS and assembly?
Month 1: Architecture and data structures? You have 18 40 minute periods and maybe homework assignments.
Half of the class won't even gain mastery in that time. By time your class is over they will still be having memory management problems.
So then you've failed to achieve the goal.
There are engineers who remember that time exi
Re: (Score:2)
Engineers are well aware that time exists. The thing they forget is that people who don't know the specific set of tools they learned in university or were forced to learn for their job exist.
I remember the horrors of engineers writing large GUI programs in Matlab.
Re:Why? (Score:4, Interesting)
Today's microcontrollers may be more powerful than you realize. It's not just the 8-bit processors running at 2MHz anymore. An ESP32 is a dual core processor running at 200 or 400MHz. They don't run a high level OS (just FreeRTOS).
And the RPi Zeros are really powerful 32-bit ARM or RISC-V processors running at several hundred MHz as well.
Python is perfectly fine for these processors. And you might think it's overkill, but so what? Most of these tasks are one-offs. Perhaps someone doing a bit of cosplay wants to have some lights on their costume, or drive an LCD. You expect them to contract out someone to do the software which is likely just displaying a bunch of graphics or cycling some LEDs?
Heck, some things in the maker world have become ubiquitous - like a CYD. It stands for "Cheap Yellow Display" because it's a stupidly cheap 2" LCD (in a yellow frame) that can be hooked up to a ESP32 board and with a few libraries you're drawing graphics on it with a total spend of under $10. One off projects.
The high end microcontrollers are pushing out the old 8-bit AVRs and PICs (which mainly hang around for legacy use nowadays), and the RPi Zero ones RP3050 and 2050 processors are pushing down the ceiling of 16-bit and even 32-bit ARM microcontrollers.
Heck, you mourn the day because it's easier to blink an LED with a 3 cent Chinese microcontroller than it is using "traditional" methods (e.g., a 555).
Re:Why? (Score:4, Informative)
Re: (Score:1)
I think you are assuming microcontrollers are only for professional use and are ignoring the hobbyist market (a big part of Adafruit's market). There are a lot of people who don't need to care about the most efficient, reliable, or cost effective use of resources. I'm one of those people and use CircuitPython/MicroPython for my simple, one-off needs all the time.
Re: (Score:3)
Reminds me of colleges using Java in their 100 level computer science courses.
Re: (Score:2)
Why do you think it is the wrong thing?
The marginal cost of a billion transistors on a mature node is about five cents.
The marginal cost of free time for someone skilled enough to program this hardware is at least $1 per minute.
If using a compiled Python and throwing devices at the problem can save you at least one minute for every twenty instances you deploy, you're ahead.
In other words... (Score:2)
> That's what I like about open source. Someone shares a piece, someone else sees a possibility, and we get to keep building it together.