I guess, this chip comes on time. The other vendors have difficulties with providing enough similar chips on time. If RP2040 is reliably available it will be large success.
I have been playing with the Pico for a couple of weeks now, though I haven't incorporated it into any big projects yet.
The quality of the documentation is phenomenal. Very competent people clearly put serious effort into making it great.
Another stand out is the Programmable I/O feature. Basically, you have eight separate, programmable state machines that can manipulate I/O pins and do DMA. This lets you offload bit banging from the main cores. Details are in Chapter 3 of the C API docs: https://datasheets.raspberrypi.org/pico/raspberry-pi-pico-c-...
I'm a total amateur when it comes to embedded development, so I have no idea how the RP2040 sits in the competitive landscape.
The documentation is excellent, and the Programmable I/O (PIO) is a unique feature. Still, the lack of WiFi and Bluetooth makes the RP2040 uninteresting for me compared to the ESP32 in a DIY project. With the ESP32, I can quickly throw in a web interface and use Over-The-Air updates. I think they missed the opportunity to position them against the ESP32.
Totally agree. Their release seems to make it seem that dual core with multiple hundred K of RAM is unique. The elephant in the room is while it has nice GPIO interfaces for sensors, you want onboard wireless for backhaul. Espressif have had this space for a couple of years now.
Depending on application and how you define "secure", you might find that having an easily sniffable SPI/SDIO/UART connection between main MCU and wifi chip can be a weakness.
I can think of many application with no need for wireless backhaul, or where wireless becomes a liability. It boils down to cost, power, noise, security, frequency used, and complexity. LoRa or similar is probably better than Wifi for many applications. I like that it isn't opinionated about the wireless stack.
I'm guessing that lots of Picos will see use as enhanced GPIOs for Pi "motherships," which provide backhaul to multiple wired-in Picos.
In fact I have a project which could use a decidedly non-wireless USB GPIO, for use on an airplane imaging system.
The problem with onboard wireless is that this adds a boatload of complexity regarding certification in various regulatory domains, trademark compliance, ...
What you say is true, however, $1 is a killer feature.
It can replace many IC and will make a very good addition to ESP32 which lacks pins for many projects. And, sometimes you want external chip so output is not affected by ESP32 reboots or freezes.
Pair it with ESP32-SOLO or nRF5. That’s what ESP8266 was originally meant for, a wireless modem chip. Remember back when ESP-01 came with AT command firmware?
I agree what would have been really interesting for me is if the pico board had had wifi and support for pi camera… then you’d have a board to compete nicely with the Esp32 cam
If you do want bluetooth/WiFI, agreed, it's annoying to not have it, true. I rarely need either capability, so I don't mind too much. (And it's remarkable that ESP32's are so cheap that I find myself using them even if I don't use those features).
On the other hand I often find myself missing USB-related features on the ESP32, such as being able to act as HID device or even a USB host. The ESP32-S2 fixes that, although software support for that is still relatively immature.
There are some other solutions based on the RP2040 that will include wifi and bluetooth. So you'll just have to pickup one of those if you want them. I suspect they will be more expensive but probably not prohibitively so.
The PIO is a very neat feature, allowing (limited) hard real time programming (even when using MicroPython) and while perhaps uncommon, it's not exactly unique: TI Sitara MCU (as used e,g, in Beagle Bone Black etc.) offers more capable Programmable Realtime Units (limited functionality co-processors). The Raspberry Pico board is however much cheaper (not sure about the price of the MCUs).
It's very competitive for applications that can make good use of the programmable IO feature. Other chips with similar capabilities are substantially more expensive.
It's also clearly going to have a great developer community building up around it, which has great value in itself.
It's also great value as a "easy to integrate cheap module" which is what they initially pitched it as.
Of course these days many applications need a wireless interface (wifi/BLE) and you can get competitive parts at similar prices to the RP2040 (ESP32 or a BLE MCU).
I guess they could have added the RPi WiFi chip for about USD 1.5 in BOM cost (assuming common industry prices based on distributor price/quantity matrix)
It would probably make more sense to add an ESP32 rather than a BCM4335 like on the RPi since that chip is intended to run with a full host OS and needs a large binary driver blob (yes the ESP32 also has a binary blob).
> With 264KB of RAM, you can concentrate on implementing features, not optimising your application for size.
I love this comment.
Anyone old enough to have coded for 8 and 16 bit home computers, or older mainframes knows how this is true, but it feels quite funny on the day and age of multi-GB heap sizes.
This device doesn’t do video but for a computer like device you’d want it to drive a 1920x1080 display, which is about 6 mb of framebuffer already. And then you need content to put on it.
This definitely isn't the sort of programming where you can just wastefully allocate ram for a full uncompressed frame buffer, but that also opens the door to sub-frame latencies.
RAM for microcontrollers is another name for cache on our modern processors, and even today we only measure that in megabytes since it takes up a ton of silicon area.
Indeed, 264KB is super luxurious for a M0 class device. For measure, I recently fit an IPv4 stack (UDP, IP, DHCP, AutoIP), USB MIDI device stack and audio processing threads with 35ms audio buffer in ~90KiB RAM (M4 class device).
Why is Arduino technologically obselete?
Isn't arduino supposed to be a framework on which you build various applications using wide range of microcontrollers?
I believe what most people think of when they say "Arduino" are the boards themselves, not the IDE. And the thing with the boards is, they are either obsolete, or expensive. RPi Pico is neither. And it comes with a modern language support, not a Java frontend to C compiler.
Assuming I hadn't failed at basic maths, the absolute max power consumption for RP2040 (implementing a media player) is 130mW, but the average power consumption in a more typical scenario would be 14mA at 48MHz.
RP 2040 is a board, not a processor. Did you compare an AVR datasheet with the ARM Cortex M0 Datasheet? ARM generally can't win this specific game against AVR.
Why not the other way around? What's the point of using a dual core 32bit with hundreds of K of ram for, let's say, a simple automated irrigation controller? There are applications for both.
Yeah, it's funny how long-lived chips are in the embedded world. I think a lot of it comes down to inertia and familiarity. "If it ain't broke...". I see that with keyboards, for example, that like you said often still use atmega 328s. That said, if you just look at features versus price (specially if you're not buying at volume) there's a lot of nice things you can get for basically no extra cost (or even negative cost) in newer versus older chips.
AVR is still fine for many uses but it's a 16bit controller. You can now get 32 bit ARM boards for about the same price, with more memory and better tooling. If starting from scratch, there's no reason to go with AVR.
AVR can run at 5V and has 10mA drive on it's pins. Sometimes that matters for what you need to interface with. The newer chips with integrated USB have nice features like a high speed 64MHz timer and the serial port is free of conflicts.
$1 is a competitive price for a cortex m0+ processor, especially with single quantities!
The QFN package is slightly painful for prototyping, but certainly isn't an issue for automated production. I will definitely add the RP4020 to my drawer of dev kits and microcontrollers!
The only thing that comes to mind is the ESP32, but that isn't directly comparable. Something like the SAMD21 is about $1 at 5k quantities but only has one core and about 32-128k of RAM
Does anyone have any interesting applications of the programmable IO? I want to use it for something but I'm struggling to come up with good ideas. Driving WS2012B LEDs could be fun but basically any microcontroller can already do that.
Tons. This is great to slap in temperature controllers, actuators, control loop things and the like. I would probably use this in lieu of the Pi Automation Hat for things like my greenhouse controller, if I didn't already have the parts for it.
It would also be great for making into RS232 driven GPIO boards using a simple protocol.
Actually I'd love to see someone develop a daisy-chainable automation IO board using these. Auto-sense the neighbors, assign registers to I/O pins, and make a protocol based on Msgpack or a subset.
I really like the flexibility of having advanced I/O capabilities on almost any pin, specially when I'm not designing the PCB from the ground up. With the older atmegas I find myself sometimes constrained by having to use this pin or that pin for a specific function. A lot of newer chips like ESP32 or the SAMD's are also fairly flexible when it comes to I/O, though maybe less so.
I found an excuse to learn PIO in sampling linear CCD sensor. The gist of it is: sensor needs accurate (us) shutter signal, then a strobe on another signal to start clocking the data out. On each clock you'd like to acquire an ADC sample (but ADC sampling should happen some time after clock edge, as that's when the sensor changes it's output multiplexer to select next pixel).
Doable to solve on an STM32 by bitbanging, but PIO makes more elegant solution (start the PIO program, read acquired samples via DMA).
You really don't. That's a small reel, most resellers are making it available in cut tape (single unit, or 10 chip) quantities. 500 and 3,400 unit reels will be available later in the year (in the autumn). They aren't generally available now.
Maybe I'm old-fashioned (the first microcontroller I used was the venerable Microchip PIC16F84, back in the late 90s) but I still think they label it "perfect" when it has no on-board program storage (i.e. flash).
To me, that just makes things so much more complicated than most of the competition, since any board has to go multi-chip in order to add external flash.
I guess the intended audience for the chip are board / module designers, who can customize various interfaces and parameters to suit the final requirement.
Having one chip, with the RaspberryPi branding, and great documentation, should allow for development of families of development / educational boards.
I love the work of the Raspberry Pi foundation. They have changed the market with their innovation and the fact that their hardware has staying power and a huge amount of support.
Some will object that none of this is the best hardware or that there are cheaper solutions but it doesn't really matter because basically none of the alternatives have such breadth of support.
You can get and Orange Pi or Banana Pi or cheap arduino clone for cheaper and some have better spec but invariably you will end up with a partially implemented SDK, linux images that won't be updated and drivers that often don't really work.
There are exceptions but with things like the Compute Module 4, you get all the advantage of a widely supported platform with the flexibility of building it in your product and knowing it will be supported for many years (if you can get your hands on it though).
The Pico is in the same vein: it has some innovative aspects, like the PIO and lots of RAM but it's basically a dual core Cortex M0+, just like another gazillion micros.
The difference is that it's extremely well documented out of the box; it took years for the ESP chips to get any decent documentation. It also comes with a boot loader and has support for at least C SDK, CircuitPython and MicroPython and there is basically no limit to implement other interpreted language platforms. Switching from one system the other is as easy as copying a file onto a USB drive and rebooting the pico.
Most small projects don't need Wifi. The ESP32 is great for that if you need it.
The RP2040 is also cheap. The Rpi foundation doesn't make a profit and they work hard at ensuring the hardware is as cheap as it can be. At USD1 it's a very competitive offering for something so versatile.
Now the main issue is going to be availability. They only make 40,000 units available for the next 3 months. It's basically a box of a few dozen rolls. A drop in the ocean.
With their usual success and the current supply chain issues, it's going to take months before it becomes widely available. Pretty sure we'll still be struggling to by more than 10 units at a time at this time next year...
That's great, except they're already relatively hard to find as-is. (If you click on the links on that page -- Adafruit, Sparkfun and Pimoroni -- the RP2040-based products are pretty much all out of stock). Sort of reminds me of the Pi Zero, which in theory costs $5, but was pretty hard to find at that price for a long time.
There is one other elephant in the room that doesn't seem to be discussed much - lack of a code read protect feature (primarily, I guess, because lack of onboard flash).
I've ordered my first pico, and am really looking forward to playing with it (having done a lot of ARM work commercially lately), and from a maker's point, I think the foundation have it absolutely nailed feature-wise. In fact, I'm considering using the pico for a (potentially commercial) side project I've been wanting to do for years, but haven't found a cheap, powerful platform to do it on.
However, for anything that wants to transition to a commercial product, lack of CRP is a major roadblock. Yes, I know we all should/want to make our code open source, and have a support model for revenue. For most embedded sellable products, the core IP is the code that runs on the micro, the development of which will be the main driver for product cost. If someone can easily lift that, hardware is easy(ish) to copy, and can potentially significantly undercut your product cost (and your ability to run a viable business).
84 comments
[ 1.9 ms ] story [ 141 ms ] threadHere is a recently announced board: https://www.cnx-software.com/2021/05/28/rv-debugger-plus-uar...
The quality of the documentation is phenomenal. Very competent people clearly put serious effort into making it great.
Another stand out is the Programmable I/O feature. Basically, you have eight separate, programmable state machines that can manipulate I/O pins and do DMA. This lets you offload bit banging from the main cores. Details are in Chapter 3 of the C API docs: https://datasheets.raspberrypi.org/pico/raspberry-pi-pico-c-...
I'm a total amateur when it comes to embedded development, so I have no idea how the RP2040 sits in the competitive landscape.
If you need wifi, by all means, go integrated. But not everybody does.
I'm guessing that lots of Picos will see use as enhanced GPIOs for Pi "motherships," which provide backhaul to multiple wired-in Picos.
In fact I have a project which could use a decidedly non-wireless USB GPIO, for use on an airplane imaging system.
It can replace many IC and will make a very good addition to ESP32 which lacks pins for many projects. And, sometimes you want external chip so output is not affected by ESP32 reboots or freezes.
On the other hand I often find myself missing USB-related features on the ESP32, such as being able to act as HID device or even a USB host. The ESP32-S2 fixes that, although software support for that is still relatively immature.
For instance: https://launch.arduino.cc/nano-rp2040
It's also clearly going to have a great developer community building up around it, which has great value in itself.
It's also great value as a "easy to integrate cheap module" which is what they initially pitched it as.
Of course these days many applications need a wireless interface (wifi/BLE) and you can get competitive parts at similar prices to the RP2040 (ESP32 or a BLE MCU).
Either way it's no longer cost effective.
I love this comment.
Anyone old enough to have coded for 8 and 16 bit home computers, or older mainframes knows how this is true, but it feels quite funny on the day and age of multi-GB heap sizes.
- https://excamera.com/sphinx/store.html#gameduino-3x-dazzler-... - https://www.adafruit.com/product/4984
https://youtu.be/mjFwR3feyV0
This definitely isn't the sort of programming where you can just wastefully allocate ram for a full uncompressed frame buffer, but that also opens the door to sub-frame latencies.
(which would allow using the screen at high resolution for, say, game graphics -- actual video is a different story)
Compare that to an Atmel SAM-L that draws ~400uA (0.4mA) at the same 16MHz, and is on a 32-bit Arm Cortex platform.
So, have you?
If you want to be more specific, AVR has no exceptions/faults and the interrupt priority is hardwired.
Edit: And AVR has only one encoding for instructions, not a big and a small one.
Isn't it 8-bit?
And there is plenty of modern C++ one can even put inside an obsolete C64, let alone an Arduino.
The QFN package is slightly painful for prototyping, but certainly isn't an issue for automated production. I will definitely add the RP4020 to my drawer of dev kits and microcontrollers!
It would also be great for making into RS232 driven GPIO boards using a simple protocol.
Actually I'd love to see someone develop a daisy-chainable automation IO board using these. Auto-sense the neighbors, assign registers to I/O pins, and make a protocol based on Msgpack or a subset.
Doable to solve on an STM32 by bitbanging, but PIO makes more elegant solution (start the PIO program, read acquired samples via DMA).
https://www.raspberrypi.org/blog/how-to-add-ethernet-to-rasp...
And DVI:
https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry...
It is kind of a bummer that it seems to be 0.1" wider than a DIP socket.
[1]https://www.raspberrypi.org/products/raspberry-pi-pico/
[1]https://www.espressif.com/en/news/ESP32_C3
https://www.kubii.fr/raspberry-pi-microbit/3328-microcontrol...
To me, that just makes things so much more complicated than most of the competition, since any board has to go multi-chip in order to add external flash.
What am I missing?
Having one chip, with the RaspberryPi branding, and great documentation, should allow for development of families of development / educational boards.
I'm pretty happy with the nRF ecosystem, it has to be said.
Some will object that none of this is the best hardware or that there are cheaper solutions but it doesn't really matter because basically none of the alternatives have such breadth of support.
You can get and Orange Pi or Banana Pi or cheap arduino clone for cheaper and some have better spec but invariably you will end up with a partially implemented SDK, linux images that won't be updated and drivers that often don't really work.
There are exceptions but with things like the Compute Module 4, you get all the advantage of a widely supported platform with the flexibility of building it in your product and knowing it will be supported for many years (if you can get your hands on it though).
The Pico is in the same vein: it has some innovative aspects, like the PIO and lots of RAM but it's basically a dual core Cortex M0+, just like another gazillion micros.
The difference is that it's extremely well documented out of the box; it took years for the ESP chips to get any decent documentation. It also comes with a boot loader and has support for at least C SDK, CircuitPython and MicroPython and there is basically no limit to implement other interpreted language platforms. Switching from one system the other is as easy as copying a file onto a USB drive and rebooting the pico.
Most small projects don't need Wifi. The ESP32 is great for that if you need it.
The RP2040 is also cheap. The Rpi foundation doesn't make a profit and they work hard at ensuring the hardware is as cheap as it can be. At USD1 it's a very competitive offering for something so versatile.
Now the main issue is going to be availability. They only make 40,000 units available for the next 3 months. It's basically a box of a few dozen rolls. A drop in the ocean.
With their usual success and the current supply chain issues, it's going to take months before it becomes widely available. Pretty sure we'll still be struggling to by more than 10 units at a time at this time next year...
I've ordered my first pico, and am really looking forward to playing with it (having done a lot of ARM work commercially lately), and from a maker's point, I think the foundation have it absolutely nailed feature-wise. In fact, I'm considering using the pico for a (potentially commercial) side project I've been wanting to do for years, but haven't found a cheap, powerful platform to do it on.
However, for anything that wants to transition to a commercial product, lack of CRP is a major roadblock. Yes, I know we all should/want to make our code open source, and have a support model for revenue. For most embedded sellable products, the core IP is the code that runs on the micro, the development of which will be the main driver for product cost. If someone can easily lift that, hardware is easy(ish) to copy, and can potentially significantly undercut your product cost (and your ability to run a viable business).