Raspberry Pi Pico and RP2040 Microcontroller(raspberrypi.org)
raspberrypi.org
Raspberry Pi Pico and RP2040 Microcontroller
https://www.raspberrypi.org/products/raspberry-pi-pico/
270 comments
Personally I really like the following boards for general projects:
- 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.
- 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've only just got started in electronics, and I have to say I find the range of options to be bewildering - what do you think of the Adafruit Feather, Teensy, or Arduino Nano?
(I think they're all comparable products ... apologies if not)
(I think they're all comparable products ... apologies if not)
As stated elsewhere, all are great. If you just want to get going with CircuitPython on some hardware, I really recommend Adafruit’s CircuitPlayground series[1]. They have things like LEDs, temp sensor, speaker, mic, gyro, buttons, switches, and touch-capacitive pads all in a tiny form factor which means you don’t have to get into breadboarding, soldering, or wiring anything up to do an amazing variety of things and get your feet wet.
[1] https://www.adafruit.com/index.php?main_page=category&cPath=...
[1] https://www.adafruit.com/index.php?main_page=category&cPath=...
Nope, these are all pretty comparable. And from the beginner point of view, they're all similar. They can all be programmed using the Arduino IDE and language, and all except the Nano can also be loaded up with Circuit Python and programmed in scripts rather than binary.
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
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
I haven't used all of these products. I have used several generations of Teensy for projects. I'm a big fan! They're powerful, well thought out, and inexpensive. Paul Stoffregen (creator of the Teensy products), is amazingly responsive to users.
The only downsides (for some) is that you have to know C to program them. You can use the Arduino libraries if you want, which provides you with a lot of functionality with very little effort.
If you have a specific project you'll be manufacturing, you won't want to use something like this. You'll want to design your own board that only has what you need. But for prototypes, small run, or one-off projects, it's hard to beat the power of a Teensy 4.
FYI there are already new Feather and Nano versions in the works that will have the RP2040 chip!
What do you think of Wemos D1 in comparison? They also seem to have onboard WiFi and Bluetooth, and support micropython.
I don't know too much about its battery management, though. The microusb port seems like a good thing?
I don't know too much about its battery management, though. The microusb port seems like a good thing?
The D1 Mini is my favorite ESP8266 board right now. It has built-in WiFi of course. It is physically smaller than a NodeMCU, but still exposes enough GPIO pins to allow interesting peripherals. The built-in micro-USB connector and USB-Serial chip means that programming it is easy, it doesn't need a separate programmer like the ESP-01. Unlike the ESP-01, the D1 Mini exposes the GPIO16 pin (aka D0) which is required to wake the board from DEEP SLEEP. The ESP-01 requires a soldering hack to enable DEEP SLEEP.
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.
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.
My biggest gripe about the NodeMCU honestly is that it's almost impossible to find one without the headers pre-soldered. The D1 Mini and the other microcontrollers I recommended all can be bought without headers soldered.
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.
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.
I used a Wemos D1 ESP8266 in this project [0]. Plenty good for the project at hand. I heard they have an ESP32 version now?
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.
[0] https://github.com/dheera/shadow-clock
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.
[0] https://github.com/dheera/shadow-clock
A great thing about the ESP32 in my experience is the 5v out. 3.3v can often power things that claim to need 5v, but bad things happen, like reboots. Some claim to have had damage too, but that hadn’t been my experience.
Oh wow, the TinyPICO is awesome! Back when I was hacking on the ESP32, this form-factor was uncommon and very expensive (a single guy on Tindie sold them). How is the antenna performance? I'm suspicious of anything that doesn't have one of those Proant thingies.
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.
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 haven't had any major issues with the antenna, although I've only really used it around my home Wi-Fi. It occasionally blips and I have some reconnection logic for that but overall it's been fine for indoor use. I have a DIY smart lock and DIY smart thermostat (that literally sit over the real lock and real thermostat -- I rent my apartment so I can't change those out) running off a TinyPICO each and they've been doing fine as far as the Wi-Fi connection goes. They just run a HTTP server on my LAN and I can set the lock and thermostat states with a simple REST API. (I can't stand the complexities around interfacing with Google Home and Alexa ...)
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.
[0] http://github.com/dheera/robot-tethys
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.
[0] http://github.com/dheera/robot-tethys
Yeah still waiting for a new chip that has at least as much SRAM, number of cores and clock frequency as the original ESP32, but with integrated USB and 5Ghz WiFi. What Espressif have released so far are just cost-optimized variations.
One alternative with both 2.4/5GHz wifi+BLE is the RTL8720DN. More here: https://www.cnx-software.com/2020/01/17/realtek-rtl8720dn-du...
Until recently, the only devkit you could find was the Seeedstudio Wio Terminal. Just came across a devboard on AliExpress for < $6. Looks interesting.
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 have briefly experimented with Mediatek and RTL wifi SoCs, but found SDK and documentation severely lacking / buggy. What’s your experience?
Is 5GHz matter for IoT use case?
Yeah, the TinyPICO has everything you'd want for building your own IoT device (e.g. a smart switch) but at $20 you might as well buy a pre-made device for the same price. If they could get the price down a bit more it could hit a real sweet spot. Still an awesome board though, kudos to them.
MicroPython is also a lot slower than Arduino style C++. Like, a LOT. So much slower that I am sort of amazed that MicroPython has any traction at all.
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.
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.
The maker landscape is insanely wide these days, MicroPython has traction because someone with little prior experience can look at the script, say "I understand some of that" and get hacking.
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.
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.
Totally agree here - IMO MicroPython is great for simplifying embedded development for beginners and broadening the group of people who are interested in taking the plunge. Arduino had/has the same impact (both the hardware simplicity and C SDKs in the IDE). It's intimidating jumping into embedded if step 1 is "use the vendor-supplied startup code to enter into `main()`, then start writing baremetal C with so-so (and in some cases no) C lib support owing to being on a resource constrained platform." MicroPython doesn't offer a full Python standard lib implementation, but the standard Python syntax is definitely more accessible to a broader group of developers who may not be familiar with C or Rust.
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.
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.
...or not and realise that professional development is not only possible in MicroPython but can significantly reduce development time - and costs - to your client.
(I work for a company that makes medical devices that use MicroPython.)
(I work for a company that makes medical devices that use MicroPython.)
Did not want my comment to come across as discrediting people legitimately using MicroPython. It was more of a comment on how embedded dev was a wide field that encompasses a lot of use cases.
I'm not particularly surprised. Many hobbyists just need their microcontroller to periodically poll some sensor data, or actuate a servo when a button is pressed, etc., and the convenience of programming in Python trumps a 10x speed improvement.
It may not always trumps a 10x shorter battery lifespan, though.
The difference in real-world use isn't nearly so pronounced in my experience. MicroPython is written in C, so whenever you're using modules implemented natively then you're only paying for a small boundary crossing.
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.
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.
I think hardware cost is secondary for hobby projects compared to learning curve cost. C is very intimidating (and annoying sometimes) compared to Micropython. It definitely promotes bad coding hygiene but I don’t really care if I just want something quick and dirty for my own small project.
I'm not surprised. I don't doubt you one bit about the performance difference, but, given how much fun I've had toying with MicroPython the BBC micro:bit (16MHz ARM Cortex-M0), I just don't care. I'm comfortable with C, and have had plenty of fun with Arduino, and I would happily switch to it if my performance needs required it. But, insofar as MicroPython lets me get from idea to working thing much more quickly, and insofar as my ideas are never something that require much performance, MicroPython boards have become the thing I reach for first when I'm looking to have some fun after dinner.
Memory is also gonna be far smaller as well.
x10 slower is better than I expected.
I did some micropython for a video series I made [1], and I have to say, it took me right back to the days of owning a ZX Spectrum - accecssing a REPL directly over a USB serial connection was very much like these machines, although I know it's not something that everyone thinks is a good idea...
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/
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/
> it took me right back to the days of owning a ZX Spectrum
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...
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...
Raspberry Pi 400 is almost that- more like a Commodore 64 in that it doesn't include a monitor.
Yes, it should be sub $100, and include a monitor.
Buy a Raspberry Pi and take a look at your local recycling center. You can find some quite decent monitors (even HDMI), keyboards, and mice in their electronic scrap bin for free.
@amelius: there's a bunch of RPi-based laptops, but at those price points you might as well go with a T60.
https://magpi.raspberrypi.org/articles/the-best-raspberry-pi...
A 7" display + case + mini Bluetooth keyboard could be a good middle ground, too.
https://magpi.raspberrypi.org/articles/the-best-raspberry-pi...
A 7" display + case + mini Bluetooth keyboard could be a good middle ground, too.
I think the one thing RE: used laptops that always has to be accounted for is it requires a fair bit of technical knowledge and some learned experience of what a good used device should have.
I'm related to a few teachers and used laptops were always an issue because they couldn't afford to take the punt of getting used ones so they had to pay a premium from established resellers instead at which point you're approaching budget new laptop price territory.
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.
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.
While it’s double your budget, perhaps the Clockwork Pi DevTerm is worth a look?
https://www.clockworkpi.com/
https://www.clockworkpi.com/
Not OP but this looks amazing. I'm very excited that this product exists.
I'm pretty pleased with the Lilygo products. Here one with a an ESP32, case, screen, and keyboard for $45:
https://www.tindie.com/products/ttgo/lilygor-ttgo-t-watch-ke...
https://www.tindie.com/products/ttgo/lilygor-ttgo-t-watch-ke...
[deleted]
Great video. And thank you so much for your continuing work measuring power consumption!
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?
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?
I think the major difference is that a microcontroller can rapidly enter and leave sleep mode, and will likely spend most of its time sleeping. The other Pi products do not support sleeping at all to my knowledge, which makes them an awful fit for battery powered devices.
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.
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.
It's built on 40nm by Sony.
Generally, if you can get away without using a full Linux SoC then it’s better to use a microcontroller platform like this.
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.
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.
These are some really great points for when it can be better to use microcontrollers over microprocessors/applications processors. Agree that generally simpler is better, and microcontrollers are simpler than Linux SoCs for many things (maybe not in getting from zero to main(), but after that).
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).
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).
> 90mA in full-speed run mode.
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.
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.
It's 5V micro-USB mode according to "3.1.1 Popcorn" section in https://datasheets.raspberrypi.org/pico/pico_datasheet.pdf this datasheet.
[deleted]
[deleted]
It's apples and oranges a bit: instead of linux you're going to need a bare metal or RTOS like FreeRTOS. Linux is not always the right platform.
That said, your point about power is well taken. I haven't looked at the Pico. What is the power draw in sleep mode?
That said, your point about power is well taken. I haven't looked at the Pico. What is the power draw in sleep mode?
[deleted]
Watch the video
0.006W from memory. But do not trust me. Watch the video.
0.006W from memory. But do not trust me. Watch the video.
Costs of development/maintenance of the use case as well as the unit itself.
Probably because of smaller size and better integration. Also, while I am not sure, I suspect the price is better, only if by 10%.
What many miss nowadays, is that most modern microcontrollers are more powerful than 8 bit home micros.
Python seems to be growing into the new BASIC.
Python seems to be growing into the new BASIC.
If anyone wants to play with MicroPython, check out Wasp-OS for the PineTime and the Colmi P8 smart watches (~$20). I've learned a lot about embedded development since I got them.
Whaat, I can get a <100 USD usable out-of-the-box that I can program in Python? Quite interesting!
The ESP32 and ESP8266 can use micropython. They are very inexpensive and are often sub US$5.
https://docs.micropython.org/en/latest/esp32/tutorial/intro....
https://docs.micropython.org/en/latest/esp8266/tutorial/intr...
https://docs.micropython.org/en/latest/esp32/tutorial/intro....
https://docs.micropython.org/en/latest/esp8266/tutorial/intr...
[deleted]
Thanks for your video. This no doubt foreshadows the Raspberry Foundation eventually moving away from the Broadcom SoCs to their own custom SoC for future Raspberry Pi iterations as well.
This makes a ton of sense. The GPU IP will be the tricky part. Will they build or buy?
If they're sticking with ARM I would bet on them using an ARM Mali GPU, since they would almost certainly be licensing the microarchitecture from ARM anyway.
I guess mRuby missed the train again.
[deleted]
Hi Jeff, Can a thermocouple be used with the built-in temperature sensor of RP2040?
I didn't down-vote you, but I suspect you've been down-voted because your question doesn't make much sense. A thermocouple is a temperature sensor, in that it transforms a temperature difference into a potential difference (voltage). You might be able to use the built-in ADC to digitize that voltage, but you likely need a sensitive low-noise, low-offset amplifier. For high temperatures (high temperature differences) and low accuracy requirements, you might use the built-in semiconductor temperature sensor as (not quite so) cold-junction reference. Does that answer your question?
It does, thanks.
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.
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.
You dont connect thermocouples to "temperature sensors", you connect them to ADCs after appropriate amplification.
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.
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.
I assumed/misunderstood RP2040 also had -
> 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.
> 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.
Some high level info on the Pico [1]:
It boasts some impressive specs:
[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...
- 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 programmable IO blocks look very interesting.
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.
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.
PIO is definetly interesting stuff.
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
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
Note that 10Mb Manchester encoding is in there - just what you need for very basic Ethernet.
ESP32 has something like this, where the low-power core executes a state machine. I'd be interested how similar they are.
https://www.youtube.com/watch?v=-QIcUTBB7Ww
https://www.youtube.com/watch?v=-QIcUTBB7Ww
First-generation ESP32 has an exceptionally weird low-power core. Retroactively, espressif called this "FSM ULP". For example, among other weirdness, this core has only one way to write memory that:
- 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.
- 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.
That sounds like an incredible engineering war story. I guess it was done to somehow cut down RAM access? Or a bug in the registers?
RP2040's PIO is more like TI's [PRU] than ESP32's FSM ULP.
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).
[PRU] https://beagleboard.org/pru
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).
[PRU] https://beagleboard.org/pru
I wonder how similar the PIO's are to the PRU's on the Beagleboard.
The PIOs are much smaller and less powerful/flexible than the PRU. The PRUs are 200 mhz 32-bit cpus with DSP-like capabilities and 8k of memory (partly shared with the application cpu). They can directly access the analog ports too. I don't know if the PIOs can do that.
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.
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.
A Gameboy ROM only requires 28 pins so I’m super excited to play around with this PIO feature!
At 360mbps you may try implement basic SDR with PLL trickery.
Oh nice, it actually has fully programmable USB device and host modes built in, as opposed to the basic USB-to-serial bridge in an Arduino.
I've put some guides on the Raspberry Pi Pico here: https://littlebird.guide/lessons
The Pico is pretty awesome. Arduino and Micro:Bit need to watch out!
The Pico is pretty awesome. Arduino and Micro:Bit need to watch out!
Another place in Australia selling them with headers:
https://core-electronics.com.au/raspberry-pi-pico-soldered-h...
https://core-electronics.com.au/raspberry-pi-pico-soldered-h...
Would be perfect to have ble/wifi connectivity on the same board.
Yes, that in combination with Micro Python would make it an esp32 killer for me.
I bet that future Raspberry Pi boards will have a RP2040 or successor chip onboard, to do the bit banging/realtime jobs on the I/O port.
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.
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.
Yeah, would be interesting if they integrated it ala STM32MP1[1][2].
[1]: https://www.st.com/en/microcontrollers-microprocessors/stm32...
[2]: https://www.seeedstudio.com/blog/2020/03/10/introducing-new-...
[1]: https://www.st.com/en/microcontrollers-microprocessors/stm32...
[2]: https://www.seeedstudio.com/blog/2020/03/10/introducing-new-...
It's huge compared to the various ESP boards and lacks WiFi or Bluetooth. Costs about the same as a D1 Mini.
The accompanying blog post [1] mentions the Arduino Nano RP2040 Connect [2], which includes "a highly efficient power section, a powerful WiFi/Bluetooth module, and the ECC608 crypto chip, enabling anybody to create secure IoT applications with this new microcontroller". It also looks quite small.
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n... [2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n... [2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
Yeah I was excited by that one too, but no mentions of the price and seems like the Wifi chip alone on there can reach 15$... and there's more than that on that board. Knowing Arduino, this will be a 30$+ board.
Other vendors are making dev boards based on the RP2040 at different sizes. SparkFun looks to have some smaller form factors, though I can't see wireless listed on board: https://www.sparkfun.com/news/3707
Pimoroni has a range of "packs" (rather than Hats) on the way, including a wireless one : https://blog.pimoroni.com/pico/
Pimoroni has a range of "packs" (rather than Hats) on the way, including a wireless one : https://blog.pimoroni.com/pico/
The VGA one (not available yet) looks fantastic https://shop.pimoroni.com/products/pimoroni-pico-vga-demo-ba...
Thanks! We're really proud of it, and it's a heck of a lot of fun too - there's something a bit magic about running an old VGA monitor off this little piece of silicon.
The PIOs allow you to offload actions like outputting the VGA leaving the CPU free to do other things.
The PIOs allow you to offload actions like outputting the VGA leaving the CPU free to do other things.
Do you guys sell a VGA to HDMI adapter? You might need to!
And that's how the Demo scene came back to life in 2022...
Yes, I wonder what the main advantages are of the Pi Pico versus the various ESP boards that also run MicroPython and are well established.
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.
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.
Documentation and software support often seems to be Raspberry's major advantage. While more niche but powerful hardware existed for a long time in between generations of the Pi the lack of software support/community around it left it buggy and inconsistent. In this case time will tell if it continues to hold true.
Is that as important for a microcontroller, though? It's not like Linux on an SoC, where the pain is vendor kernels that are buggy, incomplete, and/or outdated.
Just look at all the plug and play breakout boards available for this at launch. This is going to be huge for kids learning microcontroller programming (which is of course the pi foundation's raison d'etre.
Yes.
Here is a little list of different products based on that same chip https://www.cnx-software.com/2021/01/21/third-party-raspberr...
Not all (in fact I'd guess even a minority) of embedded systems use bluetooth or wifi.
None of the projects at my current or previous jobs have had bluetooth or wifi
None of the projects at my current or previous jobs have had bluetooth or wifi
At first glance the data sheets look very thorough:
https://datasheets.raspberrypi.org/pico/pico_datasheet.pdf https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p...
https://datasheets.raspberrypi.org/pico/pico_datasheet.pdf https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p...
In times of IoT I do not get why they do not offer a version with Bluetooth and WiFi. However a nice product that may be able to push the whole microcontroller hobby space forward.
They don't directly, but Arduino are apparently making an RP2040 board with Bluetooth and WiFi. The accompanying blog post [1] mentions the Arduino Nano RP2040 Connect [2], which includes "a highly efficient power section, a powerful WiFi/Bluetooth module, and the ECC608 crypto chip, enabling anybody to create secure IoT applications with this new microcontroller".
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n...
[2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
[1] https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-n...
[2] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
Adding Bluetooth and WiFi would be an order of magnitude more complicated, and not just from a technical point of view - you also have licensing and compliance to deal with. Silly to try and do that on the first version. There's a reason the firs RPis didn't have WiFi.
Bluetooth and Wifi add to cost, size, and power consumption and are actually not needed for many applications, including when a wireless link is needed (for decent range and battery-powered devices there are better options if your device is mostly for remote control/sensing).
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.
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.
Especially when ESP32 is a thing. You can grab boards with small LCD screens and battery connectors included for under 10 monetary units.
I was curious and looked the ESP32 up, seems as if there are some grave vulnerabilities: https://limitedresults.com/2019/11/pwn-the-esp32-forever-fla....
This exploit is about loading your own code to, and reading existing code from, a locked (encrypted) ESP32 - which is pretty bad, as it lets someone with physical access to a device to replace firmware on it, but also if you store the same secret in flash of devices you ship, someone can take one of them and get the secret (potentially compromising them all). A single secret, shipped to users is never a good security architecture, as we have learned multiple times.
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.
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.
> OTOH, the RP2040 doesn't even have flash encryption or secure boot.
At that price point you should just be thankful for what you're getting.
At that price point you should just be thankful for what you're getting.
Eh, "grave vulnerabilities" seems like quite the overstatement to me for a lot of ESP32 use cases.
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.
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.
If someone walks to my living room, inside my house, with a laptop and start flashing the ESP32 in there measuring and displaying my house temperatures from BLE sensors - I've got bigger issues than a hacked microcontroller.
I'm more interested in where they go from here. This is their own silicon, so it's (hopefully) only up from here.
Presumably the licence cost on radio chips would increase unit price and this was a bit of a gamble.
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.
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.
The PIO peripheral looks incredibly powerful. State machines connected directly to IO pins!
Yeah! Docs start on page 323 here: https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.p....
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!
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!
TI's PRU is a similar concept, but the PIO here is simpler. Parallax Propeller also has a similar flavor with lots of small cores doing different things. It's not a new idea, but the PIO looks like a nice balance between capability and complexity.
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"
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"
Can you give some examples of why this would be useful?
Should help to avoid bitbanging when implementing protocols like the 1-wire[1] protocol, or say generating IO pulse sequences for interfacing with non-standard ICs, like this linear CCD sensor[2].
[1]: https://en.wikipedia.org/wiki/1-Wire
[2]: https://toshiba.semicon-storage.com/ap-en/semiconductor/prod... (page 7 in datasheet)
[1]: https://en.wikipedia.org/wiki/1-Wire
[2]: https://toshiba.semicon-storage.com/ap-en/semiconductor/prod... (page 7 in datasheet)
Any situation where you have tight timing requirements could benefit from this. The datasheet has several examples demonstrating how the PIO can be used to generate serial clocks based on data output.
The ability to have all inputs available to all state machines is really useful - they also mention a port of tensorflow lite to the board.
So, one example would be preprocessing inputs for feeding directly into tensorflow applications, for ML at the edge (I think that's the buzzword bingo won there!).
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.
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.
It's not. 60 * 1920 * 1080 = 124.416MHz pixel clock. (and that's without any space for blanking times)
Someone managed 640x480 pixel doubled DVI bitbanging: https://github.com/Wren6991/picodvi
The Cortex-M0 instruction set has some rather unfortunate limitations [1] that can make it difficult for compilers to generate good code for shared/concurrent data structures. I can understand why they took this route on a first silicon project, but I hope to see a CM3/4 core or maybe even a riscv core in the near future.
[1] https://twitter.com/bitshiftmask/status/1337944590251331584?...
[1] https://twitter.com/bitshiftmask/status/1337944590251331584?...
This is a very minor nit, but it's actually a Cortex-M0+ (the plus is significant). Unfortunately the tweet you referenced got that right, so the criticism still stands. See [1] for a short description.
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.
[1] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M0+
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.
[1] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M0+
There are a couple of FIFO "mailboxes" and spinlock registers between the two cores - I imagine they expect most of the synchronization to happen via that. It is a bit weird of a configuration though - is this the first dual core M0+? Does it count as SMP?
Just disable interrupts while accessing shared data, it's two instructions and the critical section should not be long.
It has two cores, so I don’t believe disabling interrupts would be sufficient unless you’re only using one core.
So far, it sounds like a pretty good alternative to many other newbie-friendly microcontroller kits (like Arduino). However, for more complex tasks or advanced users, in my opinion, there are better (and cheaper) options, such as ESP8266/ESP32.
The PIO (programmable hardware) is the most exciting aspect of this device! I think this might be a key technology differentiator in the future of microcontrollers, especially as the industry settles in on similar cores (ARM Cortex M0/4).
Interfacing with weird/custom hardware is often why we need to use microcontrollers in the first place, and this will make it much easier.
Interfacing with weird/custom hardware is often why we need to use microcontrollers in the first place, and this will make it much easier.
Except that the industry is settling on RISCV, for reasons of cost and flexibility. It's quite disappointing that Raspberry Foundation chose a clunky and limited legacy platform like M0+ for this silicon, given their educational mission.
Eh, RISC-V is gaining popularity in some areas but it's very far from settled. ARM is still extremely dominant and it's not likely to go away in the near future. For this class of processors specifically there are basically no competitive RISC-V versions available today, and I would not expect to see any for a few years.
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.
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.
> Except that the industry is settling on RISCV, for reasons of cost and flexibility.
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.
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'm glad they shipped this today, rather than in n years time when RISC-V might be a real option.
RISC-V is a real option today. In fact, it has been a real option for awhile now.
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.
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.
I do recognise what you say about there being a choice. But this project was surely years in the making and the tech had to be available back then. This isn't a huge company. This is a charity's first attempt at creating a low-cost microcontroller with first class documentation and support. And considering Upton's ARM background I think the ARM choice is the obvious one.
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...
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...
Your comment is predicated on the assumption that they couldn't have worked with the other RISC-V design teams in this space for the past few years -- that they would have had to wait until products hit the shelves in order to start, which is simply not true. They could have started design collaboration with others whenever they started this project, and they would have almost certainly ended up where they are now today, except with RISC-V.
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.
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.
> which is simply not true
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.
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.
They've been working on this for years. I'm not sure RISC-V would have been a viable option when they started.
Your response is basically the first part of another response that was submitted minutes before yours.
See my comment here: https://news.ycombinator.com/edit?id=25861502
See my comment here: https://news.ycombinator.com/edit?id=25861502
RISCV is the clunky one here. As you correctly ascertained RISCV is being adopted due to cost and licensing, but its technically inferior.
A few more interesting observations:
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.
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.
The Parallax Propeller has an on-board boot ROM, but no E(E)PROM. Not much an issue for the intended audience (hobby and educational sector it seems), but the delay between reset and program start (while it is being loaded into internal RAM via I2C from external memory) would be for some hard real-time use cases. Something to be aware of.
Sorry for the possibility dumb question: do those microcontroller board have some kind of operating system? Is that operating system open source? Could it, in theory at least, run some trimmed down Linux kernel?
1) Your program to run is the operating system. This board has USB bootloader but probably can be erased.
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...
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...
Usually you don't run an operating system on those, or maybe what is called a Realtime Operating System (RTOS). That's basically glorified thread scheduler, with some basic synchronization primitives.
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).
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).
I would actually venture so far as to say that the purpose is to not run an operating system. Programming i/o intensive stuff that has to work in real time, on a computer with an OS can be hard, especially for a beginner. The OS "gets in the way" if you will.
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.
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.
I was told in school "the job of an operating system is to share resources"
and yeah, you don't want to share anything when doing microcontroller kinds of things.
and yeah, you don't want to share anything when doing microcontroller kinds of things.
These boards are designed to run whatever script you flash to it in a loop and will do so as long as the board has power. The script your write is the operating system.
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.
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.
Thanks everyone for the answers!
There are already plenty good boards in that format. I have a bunch of STM32Nucleo32s from Cortex-M0 to Cortex-M4 on them.
https://www.st.com/resource/en/user_manual/dm00231744-stm32-...
https://www.st.com/resource/en/user_manual/dm00231744-stm32-...
Aside from the amazing Raspberry Pi ecosystem, the big appeal of this chip is for gpio-heavy applications that don't need wireless connectivity. If you need wireless you'd want an ESP8266 or one of its siblings. Of course the history of the Pi Zero and the Zero W suggests they might release a connected version in the future.
What if mid project you realise you need more I/O? If you choose stm32 for your project you can just choose bigger controller, then you can easily even run your own board. It seems like RPi starts building a walled garden. Not cool.
Yeah I wouldn’t even look at this with STM32 on the market. Much larger choice and plenty of different dev boards available.
You can also get FreeRTOS up on an STM board in 30 minutes and actually doing useful stuff.
You can also get FreeRTOS up on an STM board in 30 minutes and actually doing useful stuff.
There is ample board space on the Pico...
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.
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.
> Due to a logic error, the watchdog counter is decremented twice per tick. Which means the programmer needs to
program double the intended count down value. The Pico SDK examples take this issue into account. See RP2040-E1
for more information.
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
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
Come in Arduino, your time is up!
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.
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.
PlatformIO and the vscode plugin makes for a comfortable development experience for Arduino
Worth mentioning as well that there's a good CLI for Arduino these days, at https://arduino.github.io/arduino-cli/latest/. It's written in Go, and shares config etc with the traditional Arduino UI. I have no affiliation with it, but have used it happily along with vim, and not needed to drop back into the traditional UI.
Well, I was completely wrong! So the new Pi strategy is selling chips. Curious old world!
The complement book "Started with MicroPython" at https://www.raspberrypi.org/products/micropython-pico/ looks like a nice present for kids. Would be great if it was available in other languages (for example, german).
Anybody knows if translations of the book are planned?
Anybody knows if translations of the book are planned?
For kids? I am over 40 and it's a nice present to me as well :D
Why? Why should I need/buy one?
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,...)?"
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,...)?"
PIO state machines programmable in Python sound pretty neat:
> 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
> 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
For anyone who's ever had to bitbang a protocol (say, RS232), after you've done it once, the "Oh, cool" factor wears off[0], so what they've done here sounds really nice.
[0] It's not hard, it's easy. But who wants to do that?
[0] It's not hard, it's easy. But who wants to do that?
It actually sounds sort of difficult on those PIOs. All the timing stuff, start and stop bits, parity, flow control, ideally a FIFO, etc. You only have 32 words of instruction memory in each PIO. I wish they had made the PIOs more capable. It's not like they take a lot of die area compared to 264k of ram etc. The Beaglebone PRU's are closer to the right thing.
Presumably for any well-known protocol you'll be able to use a ready-made implementation. Which basically turns them into super-flexible IO modules.
I2S was a blocker for me (ESP32 has a dedicated I2S peripheral). Then I saw this: https://shop.pimoroni.com/products/pico-audio-pack
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)
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)
IO accelerators allow it to bitbang DVI 720@30 https://github.com/Wren6991/picodvi This means you should be be able to bitbang a ton of slower stuff with ease. 1Gbit (RGMII) ethernet, IDE PATA, SCSI, all kinds of parallel camera and display interfaces.
Price wise the gap to a zero W is rather small. Fun as this sounds paying a little extra for a full nix environment and wifi is a better fit for me. I can see it being useful for low power applications though
I'll take this over a zero for most of my applications, purely because of power cuts. While there plenty of io on both, not having to worry about my SD card getting corrupted because the power got pulled is really important.
They're not really in the same category though. This is a bare metal microcontroller. The Pi Zero is normally used with Linux. I guess maybe you can use it bare metal but nobody does.
A more relevant comparison is ESP32.
A more relevant comparison is ESP32.
I like the idea of using it from an educational point of view. One of the big problems our coding clubs face, when using a Raspberry Pi, is that they need all the peripherals disconnected from their standard PCs and used with the Pis.
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.
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.
Yeah, from what I can tell the previous Raspberry Pi approach of a completely separate, full-on computer was ill-suited to its stated educational purpose for multiple reasons. The trouble is, the climate of, well, fanboyism around the Pi meant that this tended to be dismissed as an issue. I wonder if now everyone will discover how much better microcontroller-based boards are for this, just like everyone discovered the performance benefits of not having an ancient version of ARM when the Pi 2 came out and the practical benefits of integrated wifi when the 3 came out...
You can never get RPi Zero at $5 in volume. It's always one per household, etc. It's a subsidized educational price.
OTOH for this kind of board $4 seems like about the right price - RP2040 looks like ~$1 MCU to me.
OTOH for this kind of board $4 seems like about the right price - RP2040 looks like ~$1 MCU to me.
Ehh there are lots of cases where I'd rather have a microcontroller than a full OS.
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.
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.
It's not hard to make a read-only OS image and use a full blown Unix for microcontroller tasks. It's actually easy. It's just silly because 1) high power usage, high overhead of everything and 2) lack of real-time guarantees usually.
A proper embedded microcontroller like this offers things a system running Linux never can.
You can run the Zero as bare metal too.
You can, but the peripherals leave a lot to be desired.
> Fun as this sounds paying a little extra for a full nix environment
For these very small embedded systems a "full nix environment" is a major pain. It is massively overblown and not real-time at all.
For these very small embedded systems a "full nix environment" is a major pain. It is massively overblown and not real-time at all.
The Pico is also much smaller which sometimes does matter, and probably uses much less power including sleep states.
Having grown coding for 8 bits, this is more relevant to me. nix clones abound, whereas this kind of boards bring back the hardware/software machine soul back, with Python as the new BASIC.
Skip coffee for two days and buy both! I have an Arduino nano, a Pi Zero, a Pi Zero W, but this looks neat too
[deleted]
$4... that's just sweet!
With $1 more you can get a Pi Zero (assuming it's stocked) which is comparatively an 800 pound gorilla to Pi Pico, yet Pi Zero is not great for real time job unlike Pico.
Pi zero will also consume magnitudes more energy
Starter kits and with-header variants are always in stock though, it’s just that $5 price is promotional.
So you’re saying to buy both.
It can be. You can use Pi Zero as the master device and leverage the Pico(s) as real time sensor metric collectors. Zero should be powerful enough to handle Prometheus streaming I guess.
This thing looks awesome! I also love that there are already a couple of feather/thing+ boards available, which means hundreds of pin compatible add-on boards.
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 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.
Let's see the availability of these. The Pi Zero is hopeless in that regards, for some reason.
There are various new boards using same chip poping out everywhere (Adafruit, Sparkfun...) so availablity should not be a problem here as batch sizes of chips are huge. I am actually looking forward to see what the price of chip is going to be. This might be a great contender to STM32 familly.
I just ordered 3 from Pimoroni this morning (3 per user limit).
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.
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.
It's limited to 1 per order at the moment, like the Pi Zero.
This makes it much less attractive, indeed...
This makes it much less attractive, indeed...
Reminds me of the Parallax BASIC Stamps:
https://en.wikipedia.org/wiki/BASIC_Stamp
Looks like they followed in Sophie Wilson's footsteps by designing their own ARM chip! Maybe this will feed into their next iteration of the Raspberry Pi, one hopes?
They did not. They designed the SoC but the ARM part is just a regular Cortex M0+.
It's odd, I can't figure out why they designed their own silicon (obviously not from scratch)
I'm guessing they expected to sell so many that they'd recoup the tooling costs.
I'm guessing they expected to sell so many that they'd recoup the tooling costs.
They most likely just licensed the ARM IP.
I wonder how much does just RP2040 cost, I assume the board is just to test some stuff and later in a project you just solder in RP2040 + few components to make it work.
My first impression is that the RPi foundation has finally jumped the shark. There is a vast, vast number of microcontrollers available in every possible configuration. How can this chip possibly differentiate? How is custom silicon necessary to make a microcontroller dev board? How does this support their educational mission? I'm starting to come around.
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...
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...
What's the difference between PIO and GPIO?
GPIO = General Purpose IO[1], can be used for bitbanging or via dedicated peripherals like I2C, SPI etc.
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...
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...
That's awesome, seems like it could be really helpful for interfacing with hardware (or maybe a low power mode analogous to using the ULP in an ESP32?). Sidenote, that's one helluva datasheet, over 600 pages! Great to see such thorough documentation
Datasheet does look nice indeed. It's clearly written to be more approachable, which I like.
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.
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.
[deleted]
How straightforward is it to swap out the 2MB flash for something larger, say 16MB flash?
On the Pico itself? Unsure. But Arduino is already set to release a Nano version with the RP2040 and 16 MB of flash [1], so it's probably not crazy hard :)
[1] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
[1] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
I've just ordered two picos. Hopefully they still have some in stock as they're flying off the shelves !
Woo hoo, they arrived today!
There's a datasheet that covers it.
https://datasheets.raspberrypi.org/rp2040/hardware_design_wi...
https://datasheets.raspberrypi.org/rp2040/hardware_design_wi...
So what is the 100ku cost and lead time for the RP2040, or is it only a toy?
The limits on the input voltage are a little frustrating. Not being able to go over 5.5v means you can't just strap it to a 2S li-po and drive servos off the pwm outputs. Anyone know how strict that 5.5v limit is, and what's likely to go pop if you gave it 7.4v?
If you configure the PWM outputs as open-drain, then you might be able to run the servos from a higher voltage than the MCU, depending on how much current the ports can sink.
Yeah, that's at least another part though, even if it is just a regulator to get the 7.4v down to 5v. Just seems like a bit of a miss.
With batteries you'll want a buck/boost regulator (DC-DC converter) in any case. At a $4 retail price, that would be a significant share of BOM for a specialized use case.
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).
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).
There's already a buck/boost on the board. It's just limited to 5.5v max. It's also not that specialised, given that we've got people like adafruit advertising that the pwm is for servos, and lithium polymers are a hugely common power source.
Indeed. The schematic shows a Richtek rt6150b-33gqw, which is a buck-boost converted [1]. I fully would have expected a buck converter or LDO there. Well, pity then. Take it up with the RPi foundation ;-} On the plus side, this should allow you to run the Pi Pico from a single lithium cell on Vbus.
[1]https://www.richtek.com/assets/product_file/RT6150A=RT6150B/...
[1]https://www.richtek.com/assets/product_file/RT6150A=RT6150B/...
[deleted]
Are there any similar boards with built-in accelerometers and BT5.0?
Finaly! hobby-ready-and-popular arm board instead of weird AVR.
Why? What is the strategy behind competing with Arduino?
Arduino just announced a new board based on the RP2040. Not competition, collaboration.
https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
[deleted]
They're not just competing with Arduino. They're also making their own silicon!
Also why, though? Why should I use this over an ESP8266?
This doesn't do wireless, so you shouldn't use it over an ESP, generally. What you should use is Nordic nRF52 :)
But for things that don't need wireless connectivity, it's pretty cool, the Programmable IO looks very interesting.
But for things that don't need wireless connectivity, it's pretty cool, the Programmable IO looks very interesting.
You can buy an ESP8266 and a bunch of sensor boards from China and you'd know how to connect them up and get them working.
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.
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.
ARM vs xtensawhatever
They compete with stm32 and teensy
What I wanted: Pi Zero W with buffered/protected GPIO (robust like an arduino) and a few analog inputs.
What we got: An Arduino clone...
I'll pass on this one.
What we got: An Arduino clone...
I'll pass on this one.
The Arduino Team may not be happy about this.
I beg to differ - https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-t...
They say "RP2040 microcontroller chip designed by Raspberry Pi in the United Kingdom", but they won't mention where it has been manufactured?
So the institution wants to get the praise of being "western", without committing to pay their fair share by hiring local engineers and factories?
I understand then the piece wouldn't cost £3.40, but you can't have your cake and eat it, can you?
I wish they were more honest about it.
The chip is made in Japan, according to the comments on the post. However, most of their products sold in the west are made in Wales.
In that case, respect! I didn't know. I wish they were more open about it what comes from where.
So, heres my biggest question, this has 40 pins of IO, are these the same 40 pins of IO as a "normal" Raspberry Pi? I wont be the last to ask this question, so they should really document this so that people don't need to pull up pinout lists and compare them to answer this kind of obvious question.
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.
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.
As can be seen from the datasheet, the pins on the Pico are not the same.
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.
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.
I actually have a few different Arduino Raspberry Pi hybrid boards (a few are passive pin mapping type things, but others are full Arduino boards built to use the Raspberry Pi as a host) and this was the sorts of use cases that had me thinking about pin compatibility.
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!
[1] https://www.youtube.com/watch?v=dUCgYXF01Do
[2] https://circuitpython.org