Raspberry Pi Pico and RP2040 Microcontroller
raspberrypi.org
raspberrypi.org
It was the first time I'd ever tried MicroPython, and I have to say I'm a huge fan. As a dev who came from PHP/Javascript into Java and Python (heh, not quite the same thing but that's how life was), I find MicroPython a lot more intuitive than the Arduino language or raw C.
I also learned that Adafruit maintains their own flavor, CircuitPython [2].
Definitely worth trying out if you haven't, and know any Python!
I like the idea that the main interface to the device is to program it in some way or another, and I'm sure that was what led my generation to be as computer-literate as they are.
I'm going to order a Pico today!
[1] - https://realpython.com/courses/getting-started-micropython/
Is there any kit that includes a screen (with a case) and a small keyboard, and a manual for (say) less than $100?
It would be great if there was a self-contained kit that you could give to a child, so that it can have that same "home computer" experience as in the old days.
I.e., something like this, but with a modern form factor:
https://en.wikipedia.org/wiki/TRS-80#/media/File:TRS-80_Mode...
https://magpi.raspberrypi.org/articles/the-best-raspberry-pi...
A 7" display + case + mini Bluetooth keyboard could be a good middle ground, too.
Pi 400 really should have some obvious clear low cost screen upgrade option though. Possibly even just an app that it could stream to out of the box? Obviously wouldn't be perfect but if you assume there's a not unreasaonable chance they already have some Android device it could suffice.
https://www.tindie.com/products/ttgo/lilygor-ttgo-t-watch-ke...
- FeatherS2 (runs CircuitPython): https://unexpectedmaker.com/shop/feathers2-esp32-s2
- TinyPICO (runs MicroPython): https://www.tinypico.com/
They're both designed by the same dude. I'm not affiliated with them, I've just tried dozens of microcontroller boards and these two are easily the winners in my book for versatility in hobby projects.
These boards are absolutely jam-packed with features (capacitive touch sensing, RGB indicator LED, Li-Po battery management, ...) but moreover support Bluetooth and Wi-Fi. That's a major problem with the Pi Pico. You'll end up with a mess easily 2-3 times the physical size of the Pico to get Wi-Fi on it in the form of HAT-like boards, whereas the above microcontrollers have everything on-board.
By the way, CircuitPython is for the most part a real pleasure to use. If you slap an Adafruit display on them, with about 4 lines of code you can have the Python interpreter's STDOUT go straight to the display. The boards also emulate a USB drive that exposes all the Python code so you can program them with literally zero additional software.
I don't know too much about its battery management, though. The microusb port seems like a good thing?
For one-off personal projects I'd probably still reach for a TinyPICO or FeatherS2 though because of the additional features they have, and that they have a Discord server you can ask questions to, but if you're deploying a dozen of them in your garden and want to save money then yeah, the Wemos would probably be a good bet. Support and documentation is a little sparse though, in comparison.
The LDO voltage regulator on the D1 Mini is so good that in DEEP SLEEP mode, it consumes only about 200 microamps, so I use it directly in battery-operated applications. In comparison, the ESP-01 goes down to 40 microamps in DEEP SLEEP, so the overhead of the voltage regulator is only about 160 microamps. (Edit: Both of those numbers include the DHT-22 temperature sensor).
My outdoor temperature sensor uses a D1 Mini with 3 x AA NiMH batteries feeding the voltage regulator, and it lasts 4 months. It wakes up for 5 seconds, every 15 minutes, reads the temperature and battery voltage, then transmits the info to an MQTT server. In theory, the ESP-01 (w/ soldering hack) would last 6 months on those batteries, but the difference isn't worth the extra hassle of an ESP-01 for me.
Headers pre-soldered is a big dealbreaker for me. I almost exclusively use JST-EH connectors for personal projects in place of headers. They are 2.5mm spaced so they fit in 0.1" spaced pins, and are much more secure than headers and won't easily get pulled out and jumbled up.
EDIT it even has 4MB PSRAM! Very, very nice.
EDIT2 ok it does have a Proant antenna, and its 20$, so not that cheap. But ok for what you get I suppose.
I also used a TinyPICO's BLE interface to connect a phone with a motor driver for a mini telepresence robot [0] though a TinyPICO was probably overkill for this use case. My thinking was really just future-proofing it in case I wanted to add more stuff to the robot.
BTW the Wi-Fi only seems to support 2.4 GHz. No 5Ghz.
Until recently, the only devkit you could find was the Seeedstudio Wio Terminal. Just came across a devboard on AliExpress for < $6. Looks interesting.
(I think they're all comparable products ... apologies if not)
They're all pretty simple to use, with good documentation. I would probably add an M5StickC to this list, as they come as a nice modular package, with case and screen and a bunch of fun things for experimenting.
Since they can all be programmed using Arduino IDE, which has good documentation and forum support, you don't have to deal with a bunch of external toolchains and whatnot (though I would suggest VSCode with the PlatformIO plugin as soon as you're comfortable with the programming side of things.)
Ordered most to least simple: Nano Feather M5StickC Teensy
Ordered by most to least powerful: Teensy M5STICKC Feather Nano
Ordered by most to least peripherals: M5STICKC Teensy Feather Nano
Ordered by most to least reliable: Nano Teensy Feather M5STICKC
[1] https://www.adafruit.com/index.php?main_page=category&cPath=...
https://docs.micropython.org/en/latest/esp32/tutorial/intro....
https://docs.micropython.org/en/latest/esp8266/tutorial/intr...
Python seems to be growing into the new BASIC.
I wanted to know if the temperature sensor could function like MAX6675 by connecting k-type thermocouple to a terminal; Should have checked the datasheet prior or made the question clearer.
MAX6675 has build in opamp, adc and full microprocessor under the hood doing signal conditioning, digitization, linearization, translation, and cold joint temperature compensation. TLDR: No, you wont be able to connect thermocouple directly to the Pico. You will have to design/copy frontend for it.
> build in opamp, adc and full microprocessor under the hood doing signal conditioning, digitization, linearization, translation, and cold joint temperature compensation.
I stand corrected, thank you.
So, this board takes 90mA in full-speed run mode. That's not better than Raspberry Pi Zero (despite pico having 2000 times less RAM, and 10-20 times slower CPU). So why would one use this over Zero? Am I missing something?
That said, your point about power is well taken. I haven't looked at the Pico. What is the power draw in sleep mode?
0.006W from memory. But do not trust me. Watch the video.
Microcontrollers allow much lower system complexity, more predictable timing and real-time response times, and nearly instant boot times.
Virtually every USB port can supply at least 100mA, so for most applications there’s no difference between using 9mA or 90mA. That said, if you’re making a battery project you’ll almost certainly be able to stretch the microcontroller further. Micros generally have fantastic support for low power sleep modes.
I would add that it really depends on the problem you're trying to solve, though. Microcontrollers are disadvantaged compared to Linux SoCs for many workloads other than low power and low latency (i.e. hard and soft realtime).
A microcontroller like this should be able to sleep for microseconds at a time or possibly even less (but you can obviously sleep for long periods of time too), letting you spend the majority of every second asleep, just waking up for brief instants throughout the second (possibly thousands of times) to do work. This enables huge power savings over something like the Pi Zero.
You can also run the microcontroller at a lower clock speed to save more power, if you don't need to run at maximum speed to get things done.
I would be curious what process node this microcontroller is built on, because I completely understand why these numbers would be discouraging when the microcontroller is running at full tilt.
Keep in mind that's at maybe 2 volts rather than 5 volts. Still, it's 360uA per MHz, counting the two 125MHz M0+ cores as 250MHz total. That's pretty power hungry compared to other Cortex M0+ products which tend to be in the 100uA/MHz range. I think the real product here is the RP2040 SOC and the Pico board is described as a breakout board for it. I like to think the RP2040 will find its way onto future RPi Linux boards, to give them some analog and realtime capabilities.
An 80MHz microcontroller running C can go about as fast as a 800MHz microcontroller running MicroPython, if the benchmarks a friend showed me are accurate.
An 80Mhz microcontroller is a lot cheaper than an 800 MHz microcontroller, though the difference is getting smaller.
I see it as the gateway drug of embedded development, you get pulled in by how easy it looks and then you move one to a more performant language when you need it.
OpenMV has used MicroPython to great effect. It's really impressive what they've done, especially in the realm of porting vision algorithms to constrained platforms like Cortex-M's.
(I work for a company that makes medical devices that use MicroPython.)
For example, all of the machine API is typically very fast. I'd be surprised if you'd notice a significant improvement sending SPI buffers directly from C. But it's way more convenient from MicroPython - especially considering you can do it live at a REPL.
If you're spending a lot of time processing in MicroPython then yes, you'll notice a perf hit. But, if that's the case, carve out the perf-sensitive code and create a C module in MicroPython; it's straightforward.
It's akin to the way that CPython is considered slow but by using libraries like numpy or pandas the real-world performance is decent.
- New RP2040 microcontroller with 2M Flash
- Micro-USB B port for power and data (and for reprogramming the Flash)
- 40 pin 21x51 'DIP' style 1mm thick PCB with 0.1" through-hole pins also with edge castellations
- Exposes 26 multi-function 3.3V General Purpose I/O (GPIO)
- 23 GPIO are digital-only and 3 are ADC capable
- Can be surface mounted as a module
- 3-pin ARM Serial Wire Debug (SWD) port
- The power supply achitecture is pretty simple (you can power the unit from micro-USB, external supplies or batteries)
- Buy price is $USD 4.00
- MicroPython & C++ SDK
- Pinout Diagram: https://files.littlebird.com.au/Shared-Image-2021-01-21-17-39-47-GVzHd.png
- When using MicroPython, the programming model is similar to other boards where you have to unplug and plug back in the board. I hope this is ok on the Micro-USB port.
- The isn't currently a version with header pins, so you'll have to add your own, or get one from a Reseller who will mode them for you (like this one [2]).
It boasts some impressive specs:
- Dual-core cortex M0+ at up to 133MHz
- On-chip PLL allows variable core frequency
- 264K multi-bank high performance SRAM
- External Quad-SPI Flash with eXecute In Place (XIP)
[1] I've had access to prerelease HW and work at: https://raspberry.piaustralia.com.au/products/raspberry-pi-p...
[2] Maddy (with her steady hands) has hand modded 100 of these: https://raspberry.piaustralia.com.au/products/raspberry-pi-p...
The Pico is pretty awesome. Arduino and Micro:Bit need to watch out!
PIO is programmable in the same sense as a processor. There are two PIO blocks with four state machines each, that can independently execute sequential programs to manipulate GPIOs and transfer data.
PIO is highly performant as well as flexible, thanks to a carefully selected set of fixed-function hardware inside each state machine. When outputting DPI, PIO can sustain 360 Mb/s during the active scanline period when running from a 48 MHz system clock. In this example, one state machine is handling frame/scanline timing and generating the pixel clock, while another is handling the pixel data, and unpacking run-length-encoded scanlines.
State machines' inputs and outputs are mapped to up to 32 GPIOs (limited to 30 GPIOs for RP2040), and all state machines have independent, simultaneous access to any GPIO.
Will definitely pick a few of these up to play with.
This has its own assembly language (.pio) to program. Custom peripherals can be implemented by using this assembly.
Raspberry Pi already provides example programs such as custom I2C, SPI, UART (they are different from the hardware peripherals in the chip), logic analyser, LED controller, and etc[1].
[1]: https://github.com/raspberrypi/pico-examples/tree/master/pio
- writes only 32-bit words;
- only at 32-bit-aligned addresses;
- user program only controls lower 16 bits of the word;
- upper 16 bits are written with, basically, garbage (part of program counter).
Second-generation, ESP32-S2 is supposed to have a regular RISC-V low-power CPU core, in addition to the FSM.
All 3 are specialized "secondary" processor cores, but PIO & PRU are fast (faster than main CPU for bit-banged IO), where ULP is much slower (but low-power).
Each PIO is limited to 32 instruction words (16 bit words; the 5-bit address is baked into the instruction format so it can't be expanded without redesigning the ISA), its memory consists of some 4-word (32 bit word) FIFOs and two 32-bit scratch registers, and the instruction set is very limited. It can increment so you can do counted loops, but it has no ADD instruction, so e.g. it can't easily compute a packet checksum on its own, much less anything like an error correcting code. It is nice for basic bit banging of things like the Neopixel LED. Someone did DVI video with it (https://github.com/Wren6991/picodvi) but that was really stretching its capabilities, seemingly more of a flex than something really practical. Impressive though.
It's also odd that they used the M0+ core instead of an M3 or M4F, especially since they then bolted on an external divider/interpolator to speed up audio processing. Maybe future versions will upgrade. Perhaps even to risc-v ;).
I've been wondering whether the RPi foundation designed the PIO from scratch for this chip, or if it's an existing block they got from someplace. It strikes me as clunky and maybe old, coming from an era when transistors cost a lot more. As for the chip itself, it's always nice to have a new cheap MCU board, but it's hard to tell what they have in mind for it. A traditional single-core MCU would have been simpler and probably cheaper, and something aiming for more compute power would have been better off with more powerful cores (future versions might have that, and more cores too).
The coming ESP32c3 will supposedly be priced like the ESP8266 (i.e. $2 or so for a module) and it will have a RISC-V core and 300K of ram or something like that, plus wifi, so it in some ways seems more promising. For boards, I like the Longan Nano on seeedstudio, like a RISC-V based bluepill for $6 including a tiny TFT display. Unfortunately it has just 128KB of on-chip flash so it can't run micropython simply, but it has a microsd slot so maybe there is a way to use that.
https://core-electronics.com.au/raspberry-pi-pico-soldered-h...
Or they will even integrate it into their SOC.
Shame though, that they didn't make the IO ports 5V capable. It's nowadays pretty common for microcontrollers that are meant for industrial and automotive use to have a separate supply for the I/O ports, that can go up to 5V, independent from the core/peripheral voltage.
The main use is to drive (logic-level) MOSFETs directly, interface to 5V buses like SENT, CAN, etc. without having to use level shifters.
[1]: https://www.st.com/en/microcontrollers-microprocessors/stm32...
[2]: https://www.seeedstudio.com/blog/2020/03/10/introducing-new-...
Pimoroni has a range of "packs" (rather than Hats) on the way, including a wireless one : https://blog.pimoroni.com/pico/
The PIOs allow you to offload actions like outputting the VGA leaving the CPU free to do other things.
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n... [2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
One potential advantage would be great documentation for beginners.
PIO also looks interesting, however I wonder how much of a factor it is for the target audience.
None of the projects at my current or previous jobs have had bluetooth or wifi
https://datasheets.raspberrypi.org/pico/pico_datasheet.pdf https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p...
This is a good first version to validate if their customer base is interested in such a product from them, WiFi/Bluetooth can be on V2.
However, it's not like this breaks security of your hobbyist projects.
OTOH, the RP2040 doesn't even have flash encryption or secure boot. Which I guess makes sense, given that it looks like a first mass produced MCU designed specifically for education/makers/hackers.
At that price point you should just be thankful for what you're getting.
The described exploit requires physical access to the device PCB and precisely timed fault injection, so it requires moderately sophisticated attacker have the device entirely in their control in relative privacy to even perform.
As I see it, the Secure Boot bypass is thus only really relevant to those concerned about a supply chain attacker replacing the firmware. I don't really know how large the overlap is in the venn diagram of those with legitimate concerns about such things and those buying ESP-powered products though as the ones I'm aware of are pretty much all consumer-tier IoT things.
The ability to decrypt encrypted firmware is of course a different matter, even if it doesn't contain any real "secret sauce" most companies don't want their code to be accessible to competitors and/or cloners. See ELM327 for an example of what can happen there. That said I still wouldn't call it a "grave" vulnerability from the perspective of anyone but corporate IP lawyers, and in general screw them.
From a hobbyist perspective these are both good things because they enable hackers to modify their own devices to improve them.
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n...
[2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
So I think it's actually good to strip these out. There can be added as external modules or you can choose a board better suited for the job at hand.
Looks like there's an assembler for programming the PIO peripheral; they seem quite capable with two IO registers and two scratch registers.
I've used a similar sort of embedded state machine inside EFM8 microcontrollers before. They're great not just for implementing custom communication protocols, but also for offloading simple tasks: one example I've coded before is that you can offload software key debouncing to the state machine, and even get an interrupt on keypress. This greatly simplifies the main loop as you don't need to dedicate polling time or write debounce calculations!
I'm in love with this documentation. It's not just prettier than other vendors' datasheets, it's also got lots of examples, links, tips, and explanations about the "why" in addition to the "how"
[1]: https://en.wikipedia.org/wiki/1-Wire
[2]: https://toshiba.semicon-storage.com/ap-en/semiconductor/prod... (page 7 in datasheet)
With 360mb/s I/O bandwidth, that equates to more than FullHD at 60hz, with 16bit colour depth. If you attach say a rpi camera to the I/O you can do signal processing on the image. Same for VGA output.
[1] https://twitter.com/bitshiftmask/status/1337944590251331584?...
I think I knew that the M0+ lacks the regular load/store exclusive instructions from larger ARMs, handy for implementing synchronization primitives ... odd that they've build a dual core then? No idea how that is supposed to work, but haven't checked the docs either.
Edit: After browsing the (very nice-looking) RP2040 documents, it seems the only atomic thing on the chip is the special "ghosted" I/O access. That will probably be co-opted to implement atomic data structures, but then it will be at the cost of making access to the actual peripheral whose registers are being "stolen" harder or impossible. Strange, hopefully I'm missing something obvious. :)
Also, the PIO peripherals seem awesome! Can't wait to see all the cool things people will pull off with those. The document mentions them being capable of DVI and VGA signalling, even.
Interfacing with weird/custom hardware is often why we need to use microcontrollers in the first place, and this will make it much easier.
Do you have any numbers supporting that? I see a few people on HN excited about it but the shipments are a tiny rounding error on the volume of ARM devices shipping.
I have used RISC-V professionally mainly because it was easier than worrying about licensing a different soft core for an FPGA. I have the same codebase running on an ARM cortex-m3. The RISC-V code uses far more flash and RAM (near 2x for code in flash and stack space in RAM), as far as I can tell because of awkward decisions made by the ISA (there are extensions which should improve this a little but they aren't available in the core I'm using). If it were a cost sensitive high volume application then ARM would win basically on that front alone, the license fees would be more than offset by the cost in hardware.
To provide just two quick examples:
- https://www.sparkfun.com/products/15594
- https://www.cnx-software.com/2020/12/20/esp32-c3-wifi-ble-ri...
Since Raspberry Pi was going so far as to make their own silicon, they definitely could have opted to include a RISC-V design instead of an ARM design. They simply chose not to.
RISC-V would have made this product an instant buy in my books, but there are numerous Cortex-M0+-based microcontrollers and microcontroller boards out there already.
The Pi Pico is appealing because of all the documentation and the ecosystem that is sure to develop around it, so I'm not here to claim that this product won't be wildly succesful, but the M0+ is just not the choice I would have expected them to make. RISC-V seems like it would have aligned much better with the Raspberry Pi Foundation's mission.
In fact, if they had chosen to integrate the ESP32-C3 into this product instead of their custom silicon, people would be receiving RISC-V, WiFi, and Bluetooth -- and you can imagine how beneficial that would be. The ESP32-C3 is supposed to cost around $1, so it's not like it would have been outrageously expensive or something.
Your point about the ecosystem and the documentation is important here, this is extremely valuable considering their mission and simply would not have existed at the same quality level if using some brand-new ESP chip - is it even available to buy anywhere yet (I can't find a seller)? And if you haven't had a look at the RP2040 datasheet[0] yet, please do - it is really something with multiple real-life examples and hints that goes a long way beyond what you usually get. If they had built something around the C3 it'd be a long while before anything near the same level could be created and in the hands of kids. They want an established ecosystem to build on, not a cutting edge one. I do not think it's a good fit (yet).
[0]: https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p...
Most likely, the real issue is that it would have required them to make a really visionary choice, which does come with a significant level of risk. Hindsight is 20-20, and with perfect clarity we can see now that that RISC-V ecosystem has matured extremely quickly and is now a very compelling place to be. There is a ton of stuff in RISC-V -- it's not some void as you seem to be implying.
Instead, when they set out on this project, they chose to lean on their own internal strengths, which is certainly the ARM architecture. Back then, I'm sure things were less obvious than they are now -- but that's why I want them to do visionary things to move industry and education forward.
Espressif (the makers of ESP32) don't seem to be in nearly as comfortable of a position to try innovative things as the Raspberry Pi Foundation is, yet they managed to release a compelling RISC-V option -- because that industry trend was obvious enough to them, I guess, even if it wasn't obvious enough to the Raspberry Pi Foundation.
As I've indicated, I'm sure this product will be successful, and I'm excited to see what people do with this, but I can still wish the Pi Foundation would have done something more here. I'm not wishing them failure or anything like that at all.
None of us know what was available back then but you are right, maybe there was an option to work with someone and maybe even with results in a similar time frame. But considering the greater risk I don't think there is certainty how a collaboration with an external partner on a new technology would have ended. I am also not convinced we need RISC-V to move education forward meaningfully and I think what they've got here will do the job.
Hopefully people will be able to buy something similar based on RISC-V for <£5 soon and that'll kick-start even more options in this space. But we don't seem to be there quite yet.
See my comment here: https://news.ycombinator.com/edit?id=25861502
It doesn't seem to have any on-chip flash. While this is a common scenario on application processors and FPGAs, this is unusual on a modern microcontroller. It's not really a problem... XIP flash is cheap and ubiquitous... I'm just curious what the reasoning here was. Cost? Process restrictions? Silicon IP licensing issues? Not necessary if 99% of the chips are used on this RPi carrier board?
The (hard) boot rom is open source! I honestly can't remember the last time I saw this.
Regarding the Linux question, the larger cortex M devices can, but this one is probably too small at 264 kB, although not very far from the minimum (I could find boards with ~320 kB claiming some support). The biggest question is wether or not the Cortex-M0 architecture has all the required features for Linux (M4 and M7 can, but are much bigger chips).
2) Sometimes open, sometimes shared source or sometimes supplied as binary blobs.
3) No, there's not enough RAM, nor there is DRAM interface, nor it has MMU with hardware physical-virtual memory translation that Linux requires.
Dmitry Grinberg's "uARM" ARMv5TE emulator[0] might still work if it is absolutely necessary to run Linux on this.
[0]: http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20...
A useful approach for applications that need an OS is to run the OS on a regular computer, and connect it to a microcontroller that handles your custom i/o tasks. Connect them via USB or wireless.
and yeah, you don't want to share anything when doing microcontroller kinds of things.
Think: relatively simple, dedicated, repeatable applications (if/then scenarios)
Controlling lights in your house, simple robotic behaviors (sensor I/O and motor control, nothing ML related), or reading/displaying sensor data (temperature, light, etc), are common applications for microcontrollers.
There isn't enough onboard memory to run anything too complex like an OS. If that is the route you want to go, the Pi Zero might be more suitable for an entry-level board that can handle a Linux kernel.
https://www.st.com/resource/en/user_manual/dm00231744-stm32-...
Also note that there are a number of other integrators (Sparkfun, Adafruit, even Arduino) who are making custom boards. I wonder if one of them may even hack in some sort of wireless module.
You can also get FreeRTOS up on an STM board in 30 minutes and actually doing useful stuff.
Good documentation and, as always, it's kind of "I want no brown M&Ms in the jar". I bet this bug (and many others) will bite someone.
[0] https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p... , page 558
The VSCode environment is a huge upgrade from the stock Arduino UI and the piggybacking on the Pi as a development platform makes a ton of sense.
Anybody knows if translations of the book are planned?
RaspberryPI is a relatively good "PC" for cheap, uses little power and is fast enough for most usecases at home.
RaspberryPi zero is a bit slower, but a lot smaller.... and harder to buy.
Neither of them have any good alternatives on the market (yes i know many other similar boards exist, but software support is really shitty for those "alternative" boards, especially after a few years).
Why PI Pico? What killer feature does it have, compared to esp32 (which has wifi), arduino (which as a gajillion libraries and support), or some other microcontroller (bbc micro, STM,...)?
EDIT: not trying to shit on their effort, but genuinely looking for an answer to "why this, and not something else (arduino, esp,...)?"
> You'll note there's no I2S peripheral, or SDIO, or camera, what's up with that? Well instead of having specific hardware support for serial-data-like peripherals like these, the RP2040 comes with the PIO state machine system which is a unique and powerful way to create custom hardware logic and data processing blocks that run on their own without taking up a CPU. For example, NeoPixels - often we bitbang the timing-specific protocol for these LEDs. For the RP2040, we instead use a PIO object that reads in the data buffer and clocks out the right bitstream with perfect accuracy. Same with I2S audio in or out, LED matrix displays, 8-bit or SPI based TFTs, even VGA! In MicroPython and CircuitPython you can create PIO control commands to script the peripheral and load it in at runtime. There are 2 PIO peripherals with 4 state machines each. [1]
Two M0 cores with M4 speeds and priced lower than usual M0-based boards also sounds exciting:
> The RP2040 is a powerful chip, which has the clock speed of our M4 (SAMD51), and two cores that are equivalent to our M0 (SAMD21). [1]
And official support for MicroPython and USB host and guest for $4 is something rare and could potentially lure some tinkerers into embedded programming.
I personally plan to create an USB ambient light sensor for controlling Lunar [2] with it. It is a very affordable and widely available board which could potentially allow people to reproduce the sensor even in places where I can't ship a pre-assembled board.
[1] https://www.adafruit.com/product/4864 [2] https://lunar.fyi
[0] It's not hard, it's easy. But who wants to do that?
So they obviously have a working I2S implementation working (it's not a hard protocol, but great to be shipping with real proofs of concept)
This way Code Clubs and CodeDojos can use existing IT infrastructure to get their kids into doing some electronics projects, at a very low price.
A more relevant comparison is ESP32.
The biggest thing going for microcontrollers is that they aren't vulnerable to file system corruption if you yank the plug on them, making them extremely useful for IoT devices like smart locks / lighting / air quality monitoring / appliances / electronics designed for use in the field where you don't want to sit around figuring out how to ssh in and type "sudo shutdown -h now" instead of just yanking the plug and get on with your day, which you can do safely with a microcontroller.
(Strictly speaking yes you could design an OS for the Pi Zero W that mounts in read-only mode and avoids this problem but it's a headache)
That said the Pi Pico doesn't look attractive to me; I usually use ESP32s for those projects these days.
For these very small embedded systems a "full nix environment" is a major pain. It is massively overblown and not real-time at all.
OTOH for this kind of board $4 seems like about the right price - RP2040 looks like ~$1 MCU to me.
I am a little bit surprised that they didn't announce a Raspberry Pi HAT to pair a RP2040 with a regular pi. Maybe that's coming soon. (Or, even better, a new pi with one of these alongside the higher-level CPU.
I'd love to be able to buy 3 Pi ZeroW but haven't been able to since the day they were released and I'm loath to pay £2.50+ delivery 3 times to make 3 separate orders.
This makes it much less attractive, indeed...
I'm guessing they expected to sell so many that they'd recoup the tooling costs.
The chip is interesting: it's as if they were listening to my (silent) complaints about the microcontroller industry. Dual core micros exist but dual core, low end, low power is more unique. Having multiple cores can actually simplify firmware since you can dedicate a core to a polling event loop rather than having to design, configure, and debug an interrupt based state machine within the hardware's limitations. The PIO peripherals are very interesting as well and look like a lot of fun. These two features are a half step towards something like the Parallax Propeller. The on board peripherals don't begin to approach the vast quantity and complexity that other manufacturers have accumulated over the years, but the PIO and extra core help to overcome this.
The peripheral to GPIO mapping is not quite any-to-any but it is very flexible. The pinout was specifically designed to be easily and logically broken out on a single layer. These issues are near to my heart since I'm in process of fighting to work around ST's almost random pin assignment and inflexible GPIO alternate functions on a much larger chip. ST does seem to be learning, though, with their newer STM32G0 series.
As expected the RPi foundation put a lot of work into documentation, both beginner level and the datasheet. The datasheet looks quite good, though it's hard to say if it's better than ST's until I use it in anger.
Not having on-board flash feels a bit old fashioned but it's cheap and easy to interface an external SPI flash. As I understand it FLASH can be difficult and expensive to integrate on-die due to the relatively high voltages required for programming (~20V). It takes up a lot of die space and then you need more die space for the programming, read-out, addressing, and control logic [0]. ST's blurb about their manufacturing process always talks about their proprietary on-die FLASH technology which goes to show how big of a manufacturing optimization challenge it is. It makes a lot of sense to avoid for their first chip.
The RPi Foundation has always had one foot in the proprietary world. I've excused this before as a necessity required for them to make hardware, and they've done little bits to push the hardware world in a more open direction. I'm still disappointed that this non-profit has essentially created their own "Intel MKL" of optimized subroutines rather than contributing them back upstream. Even the Intel MKL is licensed to work on other compatible processors.
It's hard to overstate how limiting it feels to only have one chip available in a microcontroller series. The chip part number explanation in the datasheet suggests that they'll release other variants with different numbers of GPIO, different packages, different number of cores and RAM. The foundation will never approach the breadth of the big boys, however. It helps to be part of the ARM ecosystem where at least the code, core peripherals, and debug interface are portable. It's the rest of the custom peripherals that get you stuck, but using a HAL helps with at least the basic functionality of the common peripherals. Also peripherals and configuration aren't always completely identical across a manufacturer's lineup so you should expect a baseline level of porting effort anyway.
So it's a neat chip and I'm glad they're making it. Adding microcontroller-level tech to their curriculum definitely helps their mission, but as the Arduino and BBC Micro:bit have shown it's not necessary to make a custom chip to achieve that goal. It may even be detrimental as students are learning a chip which is less relevant in industry - modulo the mitigating factors in the previous paragraph. However, this is a good first independent project for the RPi chip design team which could be a step towards releasing a better or more open mainline RPi with a fully custom SoC in the future. There's also a point where their volume is so high they don't need that much of a justification.
[0]: http://electronupdate.blogspot.com/2018/08/espressif-esp32-t...
PIO = Programmable IO, a peripheral unit with programmable state machines that manipulate GPIOs. Can be used to implement SPI or similar protocols.
The PIO looks quite interesting, see the datasheet[2] for more details.
[1]: https://en.wikipedia.org/wiki/General-purpose_input/output
[1]: https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p...
Though I'd say it's "only 600 pages". For comparison the STM32F417 reference manual is 1700 pages and in addition you need to read the datasheet which is another 200 pages.
Not a bad thing though, it has less numerous and less complex fixed peripherals compared to the STM32 family.
[1] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
https://datasheets.raspberrypi.org/rp2040/hardware_design_wi...
For professional use, nobody stops you from creating such a board, amateurs are better of using a commercial USB power cell (likely more expensive than the Pi Pico though).
[1]https://www.richtek.com/assets/product_file/RT6150A=RT6150B/...
But for things that don't need wireless connectivity, it's pretty cool, the Programmable IO looks very interesting.
This device is for schools, and it's the thing that happens after BBC Micro:Bit and MakeCode, but before full Python on a PC.
It will have very much better documentation than a DIY ad-hoc collection of sensors.
What we got: An Arduino clone...
I'll pass on this one.
If they are compatible, they should release either a version with all 40 pins on the same side, or an adapter PCB this can be soldered onto. A big part of what makes a RPi boards so useful is the ecosystem of HATs ands Shields that are compatible with the 40 pin header of the Raspberry Pi.
You could probably map most of them up, given that the pins on the Pico are flexible. But not sure if that makes much sense, I imagine you'd only need a single UART/I2C/SPI connection between the regular Pi and the Pico in most cases.
What perhaps could be more interesting would be a Pi+Pico combo board, where most of the IOs come from the Pico.