Raspberry Silicon update: RP2040 on sale now at $1(raspberrypi.org)
raspberrypi.org
Raspberry Silicon update: RP2040 on sale now at $1
https://www.raspberrypi.org/blog/raspberry-pi-rp2040-on-sale/
84 comments
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).
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.
[deleted]
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.
While your point in general stands, I do want to point out that 1080p video from a RP2040 has actually been done, and is mind-blowing.
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.
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.
I don't have the need for a FHD display driven by a MCU, but 'racing-the-beam' seems feasible with a RP2040.
(which would allow using the screen at high resolution for, say, game graphics -- actual video is a different story)
(which would allow using the screen at high resolution for, say, game graphics -- actual video is a different story)
the chip can do some video, but low res:
- https://excamera.com/sphinx/store.html#gameduino-3x-dazzler-... - https://www.adafruit.com/product/4984
- https://excamera.com/sphinx/store.html#gameduino-3x-dazzler-... - https://www.adafruit.com/product/4984
Nah, for C64 or SAM coupé class hardware would be quite alright.
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.
What I would really like to see is a ESP32/ESP8266 competitor. A small 32bit uC with built in WiFi. That would be really awesome.
There are new RISC-V chips that aim to do that:
https://www.cnx-software.com/2020/10/24/bl602-bl604-risc-v-w...
Here is a recently announced board: https://www.cnx-software.com/2021/05/28/rv-debugger-plus-uar...
Here is a recently announced board: https://www.cnx-software.com/2021/05/28/rv-debugger-plus-uar...
They're starting to have boards with RP2040 + Wifi (Wio RP2040 mini, Arduino Connect RP2040) but they seem more expensive than ESP32 boards...
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 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.
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.
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.
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.
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.
For secure applications, on-board wireless makes your life hell. I'm actually pretty happy they didn't.
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 believe the point is "no wifi whatsoever".
If you need wifi, by all means, go integrated. But not everybody does.
If you need wifi, by all means, go integrated. But not everybody does.
The problem with onboard wireless is that this adds a boatload of complexity regarding certification in various regulatory domains, trademark compliance, ...
...not to mention massive code size increase, for wifi/bt driver. And that driver is likely to come as an inscrutable binary blob.
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.
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.
For instance: https://launch.arduino.cc/nano-rp2040
For instance: https://launch.arduino.cc/nano-rp2040
yes! I found these on sale at digikey. Search for "arduino nano rp2040". They cost about $28.
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).
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
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?
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).
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).
Either way it's no longer cost effective.
Either way it's no longer cost effective.
I use my RPi 4 quite a bit, but what are the uses of this, and of the RPi Pico?
Same as Arduino, just not technologically obsolete.
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.
How can the Arduino boards be obsolete? I still use nano clones because they are cheap AVR m328p boards with a fine power regulator and a sane quartz.
What's the point of using an eight bit microcontroller if you can get something that's order of magnitude more capable for the same price?
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.
AVR is much simpler architecture-wise, and this has the more impact the more you actually need to read the processors datasheet.
Have you actually compared the datasheets for AVR and RP2040?
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.
Power usage, for one.
AVR chips are among the worst for power consumption. An Atmega328p will draw ~24mA at 16MHz.
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.
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.
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.
Isn’t that mainly due to process nodes?
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 is still fine for many uses but it's a 16bit controller.
Isn't it 8-bit?
Isn't it 8-bit?
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.
Cool. The RP2040 can put up to 12mA, and it's adjustable per pin.
Arduino runtime library is C++, and you can go as modern C++ as you feel like it, provided it fits into the memory.
And there is plenty of modern C++ one can even put inside an obsolete C64, let alone an Arduino.
And there is plenty of modern C++ one can even put inside an obsolete C64, let alone an Arduino.
$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 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!
2 cores and 264KB ram and I/O do you know of anything else competitive for the price?
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.
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).
Doable to solve on an STM32 by bitbanging, but PIO makes more elegant solution (start the PIO program, read acquired samples via DMA).
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.
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.
Here it's used to implement ethernet:
https://www.raspberrypi.org/blog/how-to-add-ethernet-to-rasp...
And DVI:
https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry...
https://www.raspberrypi.org/blog/how-to-add-ethernet-to-rasp...
And DVI:
https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry...
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 wish there is a socket available to experiment with it on a breadboard.
The Pico[1] is pretty much the RP2040 on a breakout board, and is breadboard mountable (also includes the necessary usb interface).
[1]https://www.raspberrypi.org/products/raspberry-pi-pico/
[1]https://www.raspberrypi.org/products/raspberry-pi-pico/
Just solder pins to it and plug it in to a breadboard.
It is kind of a bummer that it seems to be 0.1" wider than a DIP socket.
It is kind of a bummer that it seems to be 0.1" wider than a DIP socket.
What prevents you from using the Raspberry Pi Pico for that?
I wish that would be a RISC-V instead of Cortex-M0+.
The ESP32-C3[1] might be of interest to you. Also includes 2.4GHz Wifi & Bluetooth 5.
[1]https://www.espressif.com/en/news/ESP32_C3
[1]https://www.espressif.com/en/news/ESP32_C3
$1 but you have to buy them by 500 units at a time...:
https://www.kubii.fr/raspberry-pi-microbit/3328-microcontrol...
https://www.kubii.fr/raspberry-pi-microbit/3328-microcontrol...
Single unit, Limit to 3 unit(s) per customer.
https://www.cytron.io/p-raspberry-pi-rp2040-dual-core-microc...
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.
What am I missing?
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?
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.
Having one chip, with the RaspberryPi branding, and great documentation, should allow for development of families of development / educational boards.
Huh, that is indeed truly weird - and I would've thought this would not be all that good from a security perspective either.
I'm pretty happy with the nRF ecosystem, it has to be said.
I'm pretty happy with the nRF ecosystem, it has to be said.
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...
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.
I buy from all of those places, but when they are sold out I also check digikey (https://www.digikey.com/en/products/detail/raspberry-pi/SC09...) and canakit (https://www.canakit.com/raspberry-pi-pico.html). They both have it now. Digikey says "2 in stock" but I think this really means "2 per customer" because there is another view I found where it looks like they have 14000+ in stock (https://www.digikey.com/en/products/filter/evaluation-boards...)
Can someone familiar with the subject speak on the state of the TrustZone in this chip?
Not gonna buy a RPi unless it comes with quality flash memory.
What's the power draw like? I couldn't find anything in the datasheet
Some example power draws are in Section 5.4 of the RP2040 datasheet: https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.p...
Thanks! I'd only looked as far as section 2.9 (Power Supplies) and then gave up when a search for mAh turned up nothing.
Missing detail: only 40ku for sale, not serious amounts.
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).
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).
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.