Back

I like the RP2040

590 points1 daydgroshev.com
MegaDeKay1 day ago

The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.

jsheard1 day ago

Things like battery life will probably improve with experience, I was talking to a silicon guy about the RP2040 and they said it's pretty characteristic of a first generation design. The digital logic that can be validated on an FPGA is fine for the most part, but the analog elements are much more difficult to fine tune, hence the poor power consumption, poor ADCs, and lack of internal DACs or opamps in the RP2040, and why the Pico Ws radio is a separate off-the-shelf part rather than fully integrated like it is on the ESP32.

dgacmu22 hours ago

Though it's a continuing puzzle to me why ESPs have worse ADCs than the rp2040, given their relative maturity. (Neither is particularly good, mind you, but I'm generally ok with the rp for my toy applications.)

rkagerer3 hours ago

If you read through errata and compare editions of the tech docs, it becomes apparent ESP32 has a history of silicon problems with its ADC's - through a few generations of their chips. In some models they removed huge swaths of related functionality from their documentation because it was bugged.

They're slowly getting better but analog is hard and I suspect they haven't prioritized it as much, historically.

datameta15 hours ago

Speaking of relative maturity, I just had a heap corruption debug for a few days. Imagine my surprise when fixing the issue involved switching from the default ESP32 BLE library to the NimBLE library...

Ballas9 hours ago

I have been having an intermittent issue as well, but only when using BLE, so I was suspecting the Espressive drivers. I was wondering if it would be worth switching over to NimBLE, so thanks for that tip, I'll try it out and see if the problem goes away. Luckily, it's a very low priority.

nimish23 hours ago

Analog is large area and expensive in general so sticking to good digital and passable analog is a very good strategy to keep costs down.

dragontamer22 hours ago

Modern Microcontrollers focus on analog because modern microprocessors start at like $5, maybe even cheaper.

If you need digital girth, don't mess with lol 264kB RP2040 systems. Just buy $3 of DDR3L RAM (aka: 128MB) and run Linux for goodness sake.

---------

Even ESP32 is a glorified Bluetooth/Wifi chip first and everything secondary. You have to have a niche at this price point to be competitive.

RP2040's niche is the 264kB of SRAM, but not much else. It needs a bunch of external parts before it can become a reasonable solution as well, so its not really cost optimized IMO.

+1
immibis19 hours ago
konstantinua009 hours ago

he said?

triyambakam7 hours ago

I was thinking about this. I think there is a trend in English to use they even when the gender is known to indicate a kind of distance from that person. E.g. my guess about the parent poster is that they (he or she in this case, a different usage) may not be very close to the "silicon guy"

teytra4 hours ago

This confuse us foreigners trying to use the English language even more than it must confuse regular english speakers.

Not only did you (you guys, y'all, plural you, whatever...) mix up ye with you, using only the object form, but also started using it for thou and thee. Also, it was thy/thine not yours in the singular form.

I suggest you "fix" your language by reintroducing these words, they (plural they) are not completely lost yet (ref: dialects and the Bible).

https://langeek.co/en/grammar/course/8/archaic-pronouns#revi...

+1
loudmax3 hours ago
lioeters4 hours ago

I agree with this take. How the word "they" was used in the sentence implies a kind of "anonymous other", especially when they're a part of a group like a company. It could have been any member of that group, male or female. And there's a lack of individuality or familiarity, it doesn't matter so much the exact person.

+1
nsteel5 hours ago
baybal218 hours ago

[dead]

crote21 hours ago

The most annoying part about the PIO is that there are only two of them (though with 4 sub-units each), they only have space for 32 instructions, and they don't have an external clock input.

They are great for implementing very basic peripherals, but more than once I've started to implement something more complex just to realize it would be unacceptably slow and run out of space. If they were to beef them up just a little, they could easily replace the more trivial FPGA applications.

boznz17 hours ago

Availability is the star of the show for me. One IC, long product lifetime, always in stock, after the shitshow that was 2021/2022 I'm not going to bother trying to shave a few cents to compromise this again.

jsbdudh8 hours ago

The RP2040 was only available during the last component shortage, since it was a newly released design, not yet implemented in many products.

The IC will be unobtainable in the next shortage, too.

I mean, don't you remember the shortage before where even capacitors were only hardly available?

nkozyra17 hours ago

Don't cycle sleeps help on the esp32? I typically run on power but I know a lot of people get all day with wifi on reasonable LiPo

dvdbloc24 hours ago

Where can I learn more about how they are used in console hacking? This sounds very interesting

MegaDeKay23 hours ago

Here you go. There might be more but these are all I can think of off the top of my head.

Nintendo Switch modchip - PicoFly: https://github.com/rehius/usk. That is the OG source of the firmware behind the already mentioned https://github.com/Ansem-SoD/Picofly

OG XBox Modchip - Modxo: https://github.com/shalxmva/modxo (see initial impressions from ModzvilleUSA at https://www.youtube.com/watch?v=uUsov3i6jL0)

XBox360 NAND reader / writer - Picoflasher: https://github.com/X360Tools/PicoFlasher (used in the RGH3 hack for some versions of the console as described at https://consolemods.org/wiki/Xbox_360:RGH/RGH3)

Gamecube Modchip - Picoboot: https://github.com/webhdx/PicoBoot

Gamecube Optical Drive Emulator - Flippydrive: https://github.com/OffBroadway/flippydrive as described at https://teamoffbroadway.com/

nick__m2 hours ago

I had look at the code (except flippydrive because it the source for a website) and I don't understand why the PIO would be needed if the RP2040 had more peripheral. None of them use the PIO for something that the STM32F401RBT6 doesn't have a peripheral for.

The RP2040 real advantage its name, its price and its availability during the pandemic chips shortage. It lacks peripherals and it's power consumption is awful.

jvanderbot2 hours ago

Analogous complaints were echo'd against the RPI boards, which are also just kinda meh when viewed from an industry / hardcore perspective. Hobbiers gonna hobby, and the ecosystem will eventually build winners / losers for each niche case.

For me, the existence of a MCU/MPU with better features at better price is irrelevant if I can't get known parts on small form factor eval boards using top links on google. Yes, I'm that lazy, but we live in a world with an embarrassment of really good options compared to 20 years ago.

mewse-hn22 hours ago

The flippydrive is such a nice, clean install on a gamecube that it leaves me wondering if the rp2040 could make better ODE's for every other console (psx, saturn in particular)

MegaDeKay12 hours ago

Interconnecting the flippydrive by squeezing a flex PCB between the optical drive and its motherboard connector was a stroke of genius.

morsch19 hours ago

Related: retro PC stuff.

https://github.com/polpo/picogus

Emulates all kinds of sound cards, including the Gravis Ultrasound.

https://github.com/FreddyVRetro/ISA-PicoMEM

Emulates a memory extension, but also so much more stuff.

nereye24 hours ago

One use case is related to the Nintendo Switch, as mentioned in another post.

E.g. see https://github.com/Ansem-SoD/Picofly.

JAlexoid24 hours ago

Comparing ESP32 to RP2040 is like comparing oranges to apples.

If you need a lot of IO - you're probably not looking at ESP32. It's just cheap and has WiFi builtin.

There are many options for other MCUs, that compare favorably to with RP2040... though majority aren't for the hobbyist market.

vardump18 hours ago

> There are many options for other MCUs, that compare favorably to with RP2040

That's pretty interesting, could you list some?

jayyhu18 hours ago

The STM32 F0/G0/C0 lines come to mind. More I/O, more peripherals and built-in flash.

For hobbyist levels, buying 1-10 pcs they are comparable in price to an RP2040 + SPI flash. However at volume pricing, the STM32 MCU's can be cheaper than just the RP2040 itself. I do think Raspberry Pi needs to figure out volume pricing if they want to be competitive for anything that's not just hobbyists.

+2
Johanx6417 hours ago
guenthert6 hours ago

Not sure about favorably, but if it's PIO you're after, there is TI's Sitara family with their PRU. afaics, more functionality for a higher price.

moffkalast23 hours ago

Ditto for robotics. 8 PIO units are enough to read and log four quadrature encoders at practically no interrupt cost, so it's possible to build a perfectly performant closed loop controller in something as slow as Micropython.

Teknoman11718 hours ago

You don't even need the 8 :), 4 quadrature inputs will fit on one PIO block.

Some lovely person got a quadrature decoder into 24 instructions, so you can potentially still do something useful on the same PIO block if you only need one or two quadrature encoders.

moffkalast17 hours ago

I mean yeah one block is 8 units right? Two pins per encoder which both need a unit each.

057 hours ago

Many, many cheap MCUs have peripherals that can decode quadrature in hardware. E.g, PCNT on ESP32, timer modes on STM32 etc. Might as well use PIO to implement I2C or UART :)

fest6 hours ago

> Might as well use PIO to implement I2C or UART :)

PIO actually came in handy for me when interfacing with an x-ray sensor which had 12 or 14 bits long UART data frame- not many micros have such a flexibility in their UART peripherals.

m-ee7 hours ago

It’s also possible to build a perfectly performant closed loop controller with micropython on an STM32

smcameron23 hours ago

We've been using the RP2040 in the electronic badges[1] for the RVASec security conference[2] for the past several years, and it's been very nice to write software for. Here's the github repo for this year's badge (there's a software-only badge simulator so you can kind of play around with it even without the hardware, although some of the multi-player things that rely on infrared badge-to-badge communication won't be any fun): https://github.com/HackRVA/badge2024

[1] Video of the 2023 badge: https://www.youtube.com/watch?v=KWZriUMNpLc [2] https://rvasec.com/

brcmthrowaway18 hours ago

Why custom and not use NXP stuff?

smcameron11 hours ago

Because it's kind of a group project for the local hackerspace and it's evolved over a bit more than a decade (didn't always use rp2040, obviously).

axoltl1 day ago

"(This is the same microcontroller, just two bugfix revisions.)"

It is exactly the same microcontroller! They're just two different packaging options. One is a 7" reel with 500 units the other is a 13" reel with 3400 units. (See "Ordering code" in the datasheet (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...))

jsheard24 hours ago

That said they have done a few bugfix revisions, RP2040-B0 is the original, -B1 has some refinements to the ROM code, and -B2 has further ROM changes and also fixes some silicon bugs from the earlier versions. If you're using the official SDK you probably don't need to care too much about which version you have though, because the standard high level libraries detect the hardware revision at runtime and enable or disable workarounds as needed.

dgroshev24 hours ago

Ooops, you're right! Fixed & attributed.

uncletaco22 hours ago

RP2040 has single handedly reinvigorated a really niche market: custom controllers. Due to the wonderful work done on gp2040[1] which is open source game pad firmware, people can buy cheap, quality, fightsticks and leverless controllers for a lot cheaper than they can from vendors like Victrix or Razer. Not only that but because its open sourced the hobbyist side of the controller community are building RP2040 pcbs to accommodate all kinds of projects and weird controller ideas.

[1] https://gp2040-ce.info

crote22 hours ago

I do wonder how much of that can be accounted directly to the RP2040. Projects like QMK[0] have been using a technically quite similar codebase for making DIY keyboards for quite a while now.

At first glance I'm not really seeing anything in GP2040 which couldn't have been done with any other somewhat-modern MCU. The RP2040 has undoubtedly been the catalyst leading to GP2040's widespread adoption, but it seems the same could've happened with a Pro Micro instead.

[0]: https://github.com/qmk/qmk_firmware

CarVac19 hours ago

Not to mention PhobGCC (I'm the lead dev) and its less-Gamecube-specific descendents such as ProGCC V3 and GC Ultimate and Phizard...

uncletaco17 hours ago

I'll mention it. PhobGCC is awesome and thank you for making it!

opello19 hours ago

Doesn't this discount things like the Brook boards (e.g., Zero-Pi[1]) that came before? I only take issue with "single handedly" because it seems not quite true to the history here.

[1] https://www.brookaccessory.com/detail/53169470/

uncletaco17 hours ago

It doesn't. Brook boards always added like an extra $100 dollars to any custom or DIY fight stick. The reinvigoration came because sticks that used to be $250 new are now closer to $100 and in some cases less, particularly leverless controllers. If you've heard of the Haute 42 or any of the countless leverless controllers that have been flooding Ali Express, Amazon, and other sites they're possible because of the firmware gp2040. For a lot of these new makers all they have to do is get the pcb printed and build an enclosure.

opello8 hours ago

I remember spending $75-$200 for MadCatz/Hori/... sticks when I was more involved with the fighting game scene around 10 years ago. Customizing an OEM stick or doing something DIY for an arcade cabinet was doable with a donor controller.

This all hangs on what "reinvigorated" means and I'm fine conceding the ground of not paying close attention in the intervening decade. I didn't think it was prohibitive back then, maybe it was in between then and now, and perhaps the barrier to entry is so low now that it's even better for gamers.

nickcw1 day ago

If you are an electronics hobbyist but don't want to make/design your own surface mount boards (like me) there are lots of very accessible RP2040 boards at very low prices.

I've used it in the Raspbery Pi Pico ($5) which comes on a nice board with lots of IO. There is a W version for a bit more with WiFi.

If you don't mind slightly less IO then you can order an RP-2040 Zero. I got 6 off AliExpress for about $12. These only have 23 IO pins but they have a reset button, USB-C and are tiny (1.5cm x 2.5cm).

The nice thing about all of these is that they use the standard Raspberry Pi dev tools, micropython, C++ just works with convenient USB loading of the firmware.

willis93623 hours ago

I like to shout out the pico ice. Most of the $30 price tag is for the UP5K tied at the hip, but for embedded projects where you have some sub-microsecond activities it's a (relatively) inexpensive option with open source tooling.

crote21 hours ago

I also highly recommend shopping around for alternative RP2040-based dev boards. The official Pi Pico is surprisingly bad, and just about every alternative out there is better in one way or another.

I mean, come on: no reset, huge form factor, only 2Mbit flash, micro USB - in 2024? Just about the only pro it has is that it is widely available.

joemi19 hours ago

The Pi Pico is not a "huge form factor". It fits better on breadboard than pretty much anything with an ESP32 on it (since it's less wide), and it provides access to most of the RP2040 pins. Since the PIO can drive a lot of pins at once, this lets you really unleash the RP2040's power to do things like DVI output. Having access to more pins is something many people consider a plus not a minus.

As to your other points, I wouldn't mind more flash but I don't think the amount it has is particularly small. The micro USB, though, is a disappointment, though.

KennyBlanken11 hours ago

Given the incompetence in hardware design with nearly every Pi ever released, I'm not sure why anyone would be surprised that the official Pico board is terrible as well.

I mean come on, how do you fuck up USB-PD that badly? Unless you're doing it on purpose to force people to buy special power supplies sold by your vendors...

moffkalast23 hours ago

Unless you're incredibly space constrained I don't really get the point of that 2040 Zero, it just costs more for fewer features. The Pico is already pretty tiny.

The Pico is really good at pin interoperability at least, in the land of ESP, what appears to be lots of IO pins quickly turns into barely enough if you're lucky, with pins connected internally to flash or the bootloader or whatever. I really wonder why they even bother breaking those out. The ESP32-CAM comes with 10 data pins, and only 4 of them are actually generally usable lol.

dgacmu22 hours ago

I think it's about the clones on aliexpress, which are about $2.50, vs $5 for the pico.

antirez1 day ago

I switched from ESP32 to the RP2040 because it's a much more reliable and documented device. My only concern right now with the RP2040 is that there are many ESP32 models with SPIRAM but it's not so simple to find a SPIRAM equipped RP2040 board. To be honest, given that the C development environment of the RP2040 is so good, you can make good use of the memory, but when one wants to develop a large MicroPython project, the SPIRAM is really a great asset. Other than that, everything about the RP2040 is just great.

j-krieger19 hours ago

I heavily disagree. I‘ve been working with the Espressif ecosystem for a couple of months now and it‘s the best documented microcontroller platform out there.

casept6 hours ago

Only if you use their SDK. Quite a few parts of the chip lack actual register-level documentation, not so on the 2040.

throwaway1596818 hours ago

Completely agreed. ESP-IDF is incredible and the dev experience is miles beyond STM32 (my opinion).

dailykoder6 hours ago

> STM32 (my opinion).

STM32 is horrible, if you don't want to use the HAL.. Everything I used (Atmel, ESP32, rp2040) was better than that - Tho I heard NXP is bad.

1515515 hours ago

Meanwhile NXP is producing 3000+ page PDFs with behavioral examples.

1515516 hours ago

The RP2040 only has one QSPI port.

JLC will assemble a RP2040 board for you for <$3/pc at quantities of 5.

shadowpho14 hours ago

I think it’ll be more expensive. When I was looking at jlc it seemed to be $100/10 was starting point if you want assembly

1515513 hours ago

You need to carefully select JLC basic parts. QSPI, XOSC, etc. can all be had without paying fees. I've ordered 5+ boards with RP2040s that have come out to "cheaper than Pico" prices.

MartijnBraam13 hours ago

It all depends on how you select the parts. I've ordered a set of 5 boards for $12 total including shipping and assembly.

dgroshev24 hours ago

I ended up cutting a section on Rust support from the post, but if you're open to Rust (iirc you were sceptical at some point?), async Rust is really pleasant to use in embedded. Dario Nieuwenhuis, one of the main people behind Embassy, gave a great overview talk at RustNL: https://www.youtube.com/watch?v=H7NtzyP9q8E

galangalalgol2 hours ago

A bit late to the thread but it is still on the front page. I've got some esp32 risc-v eval boards I've meant to mess with, but I'm nervous about their availability due to political instability and also while the rust support seems pretty great, I don't really know what is going on down in the hal and whatnot. Is rust on the 2040 well supported? Is it too well supported? Is it well enough documented that I could start with no software of any sort and load a pure rust blob and have it do some uart or something? My motivation is to recapture the feel of the c64 or Amiga1k wherebthe only mmu is optional page protection at most and you know what everything in memory is doing.

the__alchemist23 hours ago

I disagree. Rust on embedded is fantastic (I do STM32 programming on rust all the time, and have used the RISC-V ESP chips and nRF-52 as well), but Async Rust on embedded suffers from the same problems of contagion and coloring that non-embedded async rust has.

fleventynine23 hours ago

Everything had tradeoffs, but the composability of the state machines built by the compiler's async support allows you to easily build multi-tasking bare-metal systems with thousands of "tasks" and no RTOS (or SRAM-wasting threads). I highly recommend playing with Embassy for a week before discounting this approach for embedded software.

If you care about RAM consumption, you need to share the stack between tasks, forcing you to write event-driven code. Rust async makes this easy, and a bit of function coloring is no big deal compared to converting blocking code into event-driven code the traditional way...

+1
the__alchemist23 hours ago
antirez23 hours ago

Thanks, I prefer using C :) But happy that there are options out there.

mardifoufs18 hours ago

Did you use esp-idf? Or the Arduino libs?

reassembled12 hours ago

You can use Arduino libs via ESP-IDF. The IDF environment comes with a lot of libraries on its own but it is a development environment first and foremost. The design of IDF is very open and easy to understand throughout the stack. It is very easy to integrate external libraries via CMake as well.

antirez17 hours ago

ESP-IDF, Arduino IDE is untouchable for serious stuff IMHO.

orphea4 hours ago

> Arduino IDE is untouchable for serious stuff

Yes, but AFAIK you don't have to use Arduino IDE for Arduino stuff? e.g. there is PlatformIO.

mardifoufs14 hours ago

Yeah agreed, that's why I was wondering! But esp-idf has been great recently. It used to be very patchy and undocumented but I prefer it over everything else now. I'll check the rp2040 docs and try out the dev board I've had for a while, because now I'm wondering if I'm missing something haha

crote22 hours ago

I have mixed feelings about the RP2040.

On the one hand, it's a great chip for hobbyists. It's cheap, it's easily available, it's easy to build a board around, and it offers plenty of stuff for your average application.

On the other hand, it's definitely a bit lacking from a professional perspective. The peripherals are fine, but once you start looking into the details it's easy to run into limitations. That XIP interface is great - but it doesn't support writing so you can't hook up an FRAM chip and expand your memory. That PIO interface is amazing - but having only 2x32 instructions is quite limiting once you try to implement more complex interfaces. And where are my Timer/Counters? No capacitive touch? Analog on only four pins? No 5V tolerance? No high-speed clock input for the PIO modules? Why can't I run the bootloader off the internal ring oscillator? Hmm, a USB-C PHY sure would've been helpful...

I was also surprised about its poor ESD performance. An Atmega or STM32 can handle the occasional zap just fine - ESD protection is more of a nice-to-have on external-facing ports. The RP2040? If you don't add external protection to every single pin you are basically guaranteed to see a few of them die due to day-to-day use.

To summarize: neat chip, great for hobbyists, wouldn't be my first choice in professional environments.

ChiefNotAClue21 hours ago

Well said. I'll add that, as a hobbyist, you'll eventually work on more involved projects and run into those exact limitations.

kragen20 hours ago

i'm curious what kinds of applications you've found fram most useful for. it seems like a really cool technology, but the price point is so high that i struggle to understand when you'd use it rather than a combination of sram (or psram) and nand

dragontamer18 hours ago

I assume that most people's use of FRAM is when its integrated into TI's MSP430 microcontrollers

IE: if FRAM comes free with your MCU, might as well use it and take advantage of its benefits. For example: MSP430FR4132, just picking one such MCU off of Digikey (https://www.digikey.com/en/products/detail/texas-instruments...)

------

Most of what I know of FRAM comes from TI's marketing pages. https://www.ti.com/document-viewer/lit/html/SSZTA32

kragen18 hours ago

probably so, but crote was talking about external fram chips

the msp430fr4132 you linked costs 160¢ in quantity 35, which is actually considerably cheaper than comparable flash-based chips like the msp430f233 https://www.digikey.com/en/products/detail/texas-instruments... which is 500¢ in quantity 25. so that's maybe one reason people would use fram: evidently it's cheaper than nor? but i'm pretty sure there are μcs with 8k of nor flash that are cheaper than that and in fact cheaper than the price difference. is this pricing policy some sort of loss leader by ti to drive fram adoption? it seems unlikely. does using fram instead of nor make it cheaper for ti to make the chip? surely 8k of nor couldn't account for such a large cost

on further investigation, i don't find μcs with 8k of nor flash that are cheaper than that, at least in stock at digi-key and still in production. https://www.digikey.com/en/products/filter/embedded/microcon... is the link to my search, which i trust hn will abbreviate in a useful way. but lcsc has the ch32v203 in stock for 39¢ in quantity 100 https://www.lcsc.com/product-detail/Microcontroller-Units-MC... and that has 20k of sram, 64k of flash (presumably nor!), and 24 gpios. that's half the gpios of the ti chip, but i believe my digi-key search linked above was not limited by pin count

so maybe the only reason fram costs more is that ti doesn't license the fram patents to chinese companies? it still beggars belief that ti (and microchip, st, etc.) would be spending three dollars a chip on 8k of nor, or even three dollars a chip divided by two layers of profit margin

+1
dragontamer16 hours ago
dfox21 hours ago

I suspect that the Synopsys DesignWare SSI macro in RP2040 can in fact be used for R/W PSRAM or FRAM, but the abridged documentation of it in RP2040 datasheet is not sufficient for one to configure it that way.

stefan_21 hours ago

What do you mean by USB-C PHY? USB-C is the connector, and you can run USB 1.1/2.0/3.0/3.1 through it, but realistically a RP2040 can not feed even a USB 2.0 PHY.

doubloon22 hours ago

Raspberry pi was originally an educational non profit

flohoff23 hours ago

The issue is that its a comparison about apples to peaches. The RPI2040 is JUST the chip whereas the ESP32 come with tons of peripherals for your liking.

From Wifi/Bluetooth Antenna, LI Battery Controller, Ethernet whatever, Display or Camera Connector - You choose.

And then we have a multitude of even CPU choices and when running on a coin cell it makes a difference powering a second, unnecessary core or even wifi.

And with the C6 variants, Espressif even switches ISA again, from 8266, to ESP32 to a RISC-V based ISA.

So you are comparing the first of its kind SOC with a decade old Family of SBCs.

Youden19 hours ago

> The RPI2040 is JUST the chip whereas the ESP32 come with tons of peripherals for your liking.

I think you're mistaking the ESP32 devkits for the ESP32 itself. The thing that comes with an antenna, battery controller and any kind of connector whatsoever is a devkit or at least a module. The ESP32 itself is a small IC just like the RP2040.

For example you might be thinking of a devkit like this: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s...

Which is itself based on a module (e.g. ESP32-S3-WROOM-1), which just bundles the ESP32-S3 IC with a few niceties (like wifi antenna or connector).

The equivalent for the RP2040 would be the Raspberry Pi Pico, which does come with some minor niceties (like a wifi variant). There are other products that package it with different peripherals.

> So you are comparing the first of its kind SOC with a decade old Family of SBCs.

Neither the RP2040 nor ESP32 series are SBCs and neither has any SBC lineage. The Raspberry Pi SBCs were all Broadcom based, the RP2040 is a brand new IC developed by Raspberry Pi and afaik has no IP licensed by Broadcom.

snufkin9723 hours ago

You're right about the technicals, but I think its about the use cases. RP2040 is indeed one of its kind and is suddenly a great choice for so many projects, both hobby/educational and proffessional embedded devices. With its price vs possibilities it just covers soooo much when You know it's just one single chip version. To me, this is what tech progress is all about.

HyulianGrader23 hours ago

It's safe to assume he's talking about the chip in both cases. You can connect either of them to a battery charger, camera, or nuclear reactor but all of those 'peripherals' are completely irrelevant to this comparison.

milesvp22 hours ago

FYI. In the embedded space, peripherals refer to the chip's built in capabilities. Typically there is a peripheral that handles SPI, a peripheral that handles I2C, a peripheral that handles USART. There might be a peripheral that handles USB, or I2S, or any number of different abilities. It's either transistors or microcode on more sophisticated MCUs that allows these peripherals, and not every pin is connected to every peripheral, which can make chip selection even trickier. It really sucks to start designing around a chip that looks like it does everything you need with enough pins to only find out that once you start doing pin layouts you can't use both USART2 and I2C because they use the same pins. Worse, is when the datasheet makes this difficult to discern, and you only find out when doing some firmware work on a devboard.

g15jv2dp19 hours ago

Except it's not at all how GP used the word:

> From Wifi/Bluetooth Antenna, LI Battery Controller, Ethernet whatever, Display or Camera Connector - You choose.

None of those are in-chip peripherals. Besides, the RP2040 comes with a lot of peripherals too. Not as much as an ESP32 by a wide margin, but still.

zik5 hours ago

The ESP32 modules are available with or without the antenna built in, and the chips have an on-chip ethernet MAC peripheral, display support via on-chip LCD, I2C, or SPI peripherals, and camera via the on-chip CAM peripheral.

Not all versions have all these features. You can pick one based on the features you need.

0x45721 hours ago

> Worse, is when the datasheet makes this difficult to discern,

That's why I like RP2040 so much. Datasheet is amazing and clear, even for someone like me who hasn't spent too much time in embedded world.

There is a special, much shorter document just for hardware design that makes designing a board that uses RP2040 even easier.

+1
1515515 hours ago
HyulianGrader21 hours ago

FYI the RP2040 has peripherals too, a lot of the same ones.

It's very clear that GP has an odd misconception that an ESP32 is some kind of development board complete with "connectors" and possibly a battery charger, while an RP2040 is just the SoC itself.

croes20 hours ago

But if it's about the chip then just grab any ESP32.

sophacles23 hours ago

So is GP.

The silicon chip itself for an ESP has:

bluetooth, ethernet, wifi, SD/EMMC, and a bunch more "peripherals" built into it.

The RP2040 does not.

To make this painfully clear:

For an esp32 to do wifi you wire the esp32 to an antenna.

For an RP2040 to do wifi you wire the 2040 to another chip, and that other chip to an antenna.

Do you see the difference?

moefh23 hours ago

GP is clearly talking about ESP32 boards, not the chip; they mentioned "LI Battery Controller", and "Display or Camera Connector". People sell RP2040 boards with those too, for example:

- board with a battery charger: https://learn.adafruit.com/adafruit-feather-rp2040-pico/powe...

- board with camera: https://www.waveshare.com/pico-cam-a.htm

+1
Aurornis22 hours ago
HyulianGrader23 hours ago

No, that's both "just the chip", the chips have different peripherals. They both have the usual SPI, I2C, UART, ADC, etc., and they have their differences too.

I could just as well say "For an RP2040 to do USB you wire the RP2040 to the connector. For an ESP32 to do USB you wire the 32 to another chip, and that other chip to a connector."

It's clear to me GP has the impression that ESP32 is something more (a development board with an ESP32?) than the ESP32 "chip" itself.

+2
krisoft23 hours ago
jvanderbot22 hours ago

Is there a non-Chinese equivalent of ESP that compares in terms of module integration re: Wifi et al? (but perhaps not cost)

squarefoot14 hours ago

Non Chinese as in not made in China? Pretty hard I believe. As for near equivalent, I recall about the old (and now possibly hard to find) WiFiMCU modules and the W80x MCUs by Winnermicro.

http://wifimcu.com/

https://github.com/SmartArduino/WiFiMCU

https://www.aliexpress.com/item/1005003456975478.html

Youden18 hours ago

There aren't a whole lot of options for wifi specifically; there's tons of choice for Bluetooth though.

For Wifi, the only competition I'm aware of is the wireless STM32 series from ST Microelectronics: https://www.st.com/en/microcontrollers-microprocessors/stm32...

For BT, Nordic's nRF series is pretty popular. In the DIY world, I mostly know it in the form of the nice!nano, a keyboard controller.

jvanderbot18 hours ago

I see some microchip offerings, but am not clear on how they fit into this trade space. https://www.microchip.com/en-us/products/wireless-connectivi...

These range from $4 to $14 for MPU + Wifi.

kragen20 hours ago

no, of course not

jvanderbot20 hours ago

I dont see why that's obvious.

+1
kragen18 hours ago
peteforde23 hours ago

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project.

First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling.

Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful placement of about a dozen components, including a crystal. Not only does a module reduce implementation complexity dramatically, standardization skips every engineer potentially making their own dumb component placement mistakes.

Third, the ESP32-S3 has 14 GPIO pins that can be configured to do capacitive touch, while the RP2040 has none. Most of the projects that use RP2040 and capacitive touch rely on the MPR121, an IC that past its EOL and will likely cause a lot of hasty redesigns over the next few months.

It's also worth saying that eventually RP2040 will likely release more or less powerful versions, and hopefully versions in a module format. I doubt they will ever let it become an STM or PIC situation, but the ESP32 product lineup doesn't look so crazy once you are acclimatized to it.

geerlingguy22 hours ago

It seems like Espressif are in the same situation as Pi w/r/t PlatformIO[1]. As an outsider, it sounds like PlatformIO was trying to extract a very large annual payment from RPi and Espressif, and that was after the initial support was added in, and some of the community started adopting it.

It's a weird situation, but I think PlatformIO built up a dominant position by supporting all these platforms and accepting community contributions to do so, then tried extracting value from the manufacturers directly after the fact, blocking further community PRs that would add new board revisions or fix bugs. See related: [2]

[1] https://github.com/platformio/platform-espressif32/issues/12...

[2] https://github.com/platformio/platform-raspberrypi/pull/36

peteforde22 hours ago

Thanks for all of your rational contributions to those many threads, Jeff.

It is an extremely weird situation, and a deeply bad look. If I was pressed for an opinion, I would say that I wish Eben had taken the high road and gone all in on supporting PIO despite the tangy mystery aftertaste for the simple reason that it would be a net-positive for developers.

The way things stand, migrating away from the Arduino IDE to using VSCode with RP2040 feels like you're being actively messed with; there's so many projects and forum posts that sound like the right path, when it seems like the actual answer should be super simple. This is super painful for newcomers.

gchadwick21 hours ago

> It is an extremely weird situation, and a deeply bad look

I never followed all the ins and outs but from having a quick look through the comments on https://github.com/platformio/platform-raspberrypi/pull/36 the following happened:

  - Developer independent of RPi opens PR to add RP2040 support to PlatformIO

  - PlatformIO don't want to merge it, expecting some financial contribution to help maintain the support (seems reasonable)

  - They discuss this with RPi, ultimately RPi don't want to pay the asked contributions so that PlatformIO are happy maintaining support (this also seems reasonable)

  - End result is no RP2040 support in PlatformIO
Ultimately maintaining things isn't free. RPi have chosen the development environment(s) they wish to support and it hasn't included PlatformIO. What's weird or a bad look?
moefh8 hours ago

The problem (to me) is that they welcomed that PR and requested corrections until it was in a good enough shape to be accepted, without any indication that it wouldn't be accepted unless/until they had financial support from RPi. That only became clear almost a year after the PR was opened.

+1
sangnoir21 hours ago
throwup23821 hours ago

Can you provide a TLDR to what the state of things are? I was under the impression that ESPHome was built on top of PlatformIO so this sounds scary...

crote22 hours ago

> The RP2040 requires careful placement of about a dozen components, including a crystal.

To be fair, the chip is designed to make these really easy to place. There's pretty much one single layout which makes sense, and it provides easy access to all the pins you could possibly want. Combine that with the excellent documentation they have provided, and it's essentially just a multi-part drop-in design you don't ever have to think about again.

It did look a little bit intimidating at first, but it was a genuinely pleasure to implement.

peteforde22 hours ago

You're kind of making my point for me; when every engineer has to place a dozen components, a non-zero number of them are going to make facepalm mistakes.

Even if you create a sub-module layout that you include in every project you work on... that's still n slightly different permutations of the same thing, even if they are all perfect. (They aren't.)

petsfed17 hours ago

A non-zero number of engineers will implement "hello world" wrong when they're first learning a language. That's not an argument against any given programming language either. "I made a design error that the documentation specifically calls out as something to avoid" doesn't hold much water as a legitimate criticism. Especially when the design error is "I didn't put the decoupling cap very close to the pin it's supposed to be decoupling for". (as an aside, you should read the "minimal design example" chapter from the RP2040 Hardware Design Guide[0], even if you have zero intention of designing with the chip. It's a literal masterclass in beginner-level pcb design.)

Literally none of this is actually a hazard if you design more than one PCBA with a microcontroller on it in your entire life. I'd argue that designing around a castellated-edge module is much MUCH harder to get right on the first try than discrete components, even though the parameter space is apparently much smaller.

0. https://datasheets.raspberrypi.com/rp2040/hardware-design-wi...

adriancr21 hours ago

> First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling.

I'm out of the loop, have been using rp2040 since launch and never used platformIO.

How did you use it and what rubbed you the wrong way?

Developing locally either with cmake and pico sdk or micropython seems very easy... why add platformio in the mix?

zbrozek20 hours ago

I really don't think there's any significant value to be gained by turning this into a module. Everyone wants a slightly different form factor and the thing is so easy to design around that a module isn't meaningfully achieving anything.

Touch is a niche single tasker. I'm glad they didn't include it. Using another ic for that makes sense, and folks being lazy and sticking to an EOL part to provide that functionality isn't RPi's problem. Or do it in software.

I'm with the OP on this one, I really think the foundation nailed the product definition.

aswanson20 hours ago

The pico board is the de facto module for me. Very cheap and breaks out every useful signal.

mordae8 hours ago

> The RP2040 requires careful placement of about a dozen components, including a crystal.

I have had 14yo kids do the PCB layout for RP2040 on our custom handheld console. They had no trouble.

Nor did I with my ~10 boards.

Crystal is the simplest, decoupling can be a chore, but only if you add them too late. Power can be 90% done with a pour under the package.

danhor22 hours ago

The Pi Pico is intended to be the module format (and can be delivered on reels and used with some PnP machines), though it is much larger than it needs to be for this purpose (and this might be why you didn't mention it).

I have only implement touch buttons for hobby projects using a different MCU, but is there a reason to not just use the PIOs for touch sensing?

peteforde22 hours ago

I can appreciate intentions, but a Pi Pico does not compare favorably to a chip module in any regard.

It's huge, it only exposes 26 GPIOs.

I'm not saying Pico sucks by any means. It has uses and places. It's just very not this: https://www.digikey.ca/en/products/detail/espressif-systems/...

petsfed21 hours ago

>Not only does a module reduce implementation complexity dramatically, standardization skips every engineer potentially making their own dumb component placement mistakes.

And we've never found a way around that for the decades we've been putting Atmel, STM, TI, Ambiq, Nordic, etc chips in our designs... There's an intern 2 yards away from me who will be wrestling with getting the right components in place around an STM, for his very first pcb design. This is not a hard problem for anyone who has been doing this for any period of time.

And anyway, those dozen or so components are the oscillator/crystal circuit, the reset holdup, and the 3.3v supply. And then like a bazillion decoupling caps. Certainly, antenna tuning can be hard, but if you can use chip antennas, its not that hard.

All of those are so bog standard that when I looked at e.g. the adafruit RP2040 Feather's schematic, I was sort of surprised at how much is just lifted wholesale from all of their other feathers. Like, the only difference between the RP2040 feather and the nRF52840 feather is the micro itself, the timing circuit (all 5 components of it for the RP2040), and the antenna circuit for the Nordic board.

As to the convenience of modules, I submit that they are very handy for sale to the hobbyist market, but if you want to actually sell your products, you still have to go through the process of RF certification (although at a lower cost. Only you can decide if the higher upfront cost of using a module vs. spinning your own is offset by the lower certification cost), so the benefit is a lot more mixed. Even so, you're only saving the antenna tuning step, which is usually done as a BOM variation, not a major trace adjustment.

As to the dozens of STM and PIC chips, TI has the same situation. Customers want to pay for only what they need and those manufacturers have the manufacturing capacity to support that desire. Its not daunting if the difference matters. This is very much akin to complaining that Home Depot sells too many different kinds of lumber.

As for capacitive touch ICs, sure Adafruit only carries one. But mouser carries 199 that are not end of life. To keep that functionality going, adafruit need only pick up one of them. The cheapest one is even in a TSOT package, so the DFM will be pretty easy. Hell, if I'm not too tired from my job designing and programming these things, I might go home and spin one up tonight. Ought to only take me an hour or so. And the I2C driver another couple hours.

floating-io15 hours ago

> but if you want to actually sell your products, you still have to go through the process of RF certification (although at a lower cost. Only you can decide if the higher upfront cost of using a module vs. spinning your own is offset by the lower certification cost)

I doubt it was your intention given the disclaimer there, but based on my own research into this issue, this is a highly misleading statement, especially for small volume products.

Full FCC RF certification is not only very expensive, but also very complex from what I understand. It is NOT an easy process. That is why these modules are so popular in many actual commercial products.

If you need FCC certification for your product and use a pre-certified module (and presuming no other radio hardware is present), you only have to undergo the testing for an unintentional radiator I believe, which is a much simpler prospect.

The difference in cost is said to be in the neighborhood of $5K to $10K, though I haven't gotten any actual quotes yet, so I can't give anything definitive there.

Disclaimer: IANAL of any description, and I have not yet gone through this process myself; I'm just researching it as I get ready to produce a product. Do your own research, or better yet, hire someone who truly knows this stuff!

12722 hours ago

You can do capacitive touch with RP2040 just fine. Turn on, turn off, measure time. Plus I don't like modules as they seem pointless complexity when I just want to order a ready-assembled, self-designed PCB.

_Microft20 hours ago

I also did not understand this complaint. On a Pico, any GPIO can be used for touch (using PIO of course).

Example with 23 touch buttons if I counted that correctly:

https://github.com/todbot/picotouch

peteforde18 hours ago

Thanks for this! I am happy to have been wrong about the touch stuff, because I'm learning a lot.

_Microft18 hours ago

The same user has also got a board with touch sliders, consisting of inversely tapering touch areas that allow to compute the touch position along the axis (same for rotary sliders that use three of these in a circle configuration).

https://github.com/todbot/picoslidertoy

SAI_Peregrinus21 hours ago

I did manual capacitive touch on an ATMega328. Peripheral support is easier and more reliable, but not strictly necessary. You "just" need a GPIO with analog input and a timer.

g15jv2dp19 hours ago

Honestly you just don't need platformio for programming esp32. I tried, and it was just easier to deal with esp-idf than have a middleware with its own quirks on top of esp-idf's own quirks.

olabyne22 hours ago

what is the drama with platformIO ?

aswanson20 hours ago

Pico board is the module. I agree that placing the xtal etc is too much.

JohnFen23 hours ago

The RP2040 is pretty cool. I've used them in a half dozen projects now.

> Raspberry Pi pulled a Henry Ford and boldly went with just one microcontroller.

However, this one size fits all thing doesn't work for me. I prefer to use the least microcontroller that will do the job I need done.

> There is no choice, no right sizing, but that might be OK! An RP2040 costs ~70 cents, and not all gizmos are produced by the million.

The reason I like to use the wimpiest microcontroller possible is not related to monetary cost. It's related to my power budget. Most of my projects are battery-powered, and having them use the least possible amount of juice is a huge advantage.

But even so, why use a $1 microcontroller when a 20 cent one will do the job equally well?

samatman17 hours ago

A much larger pool of online documentation, example code, and experienced hobbyists who like answering questions, is worth a great deal more than eighty cents.

Getting more use out of the battery is a good and sufficient reason to use a less powerful controller, though. It being cheaper is nice in theory, but almost meaningless for a one-off project, in practice. I can't remember the last time I made a purchase which was a fraction of a dollar, it just doesn't move the needle.

weinzierl21 hours ago

I think the PIO state machines are pretty cool and relatively unique. I am also glad the Foundation resisted the temptation to market them as extra cores and sell the RP2040 as 10-core processor.

When it comes to the Raspi Pico and similar devices[1], I think UF2 flashing is the best thing since sliced bread. This alone lowers the barrier for beginners significantly.

Things I don't like: power consumption.

But you can't have everything...

[1] I know it is not restricted to RP2040 boards, but I think it is nowhere as common as there.

mdp202121 hours ago

> Things I don't like: power consumption

I understand it could use ~0.08W, given it draws 3.3V at ~24mA... I am not a specialist, is that a lot?

Ref.: https://learn.sparkfun.com/tutorials/rp2040-thing-plus-hooku...

dragontamer21 hours ago

TI's MSPM0G350x (also a low-cost Cortex-M0+ design) runs full-tilt at 8mA, STOP-sleeps at 400uA, STANDBY-sleeps at 5uA, and SHUTDOWN-sleeps at 80nA.

https://www.ti.com/lit/ds/symlink/mspm0g3507-q1.pdf

--------

RP2040's full-speed is okay. 20+mA is a lot but it is easily explained by the absurdly huge SRAM banks it has.

But RP2040's sleep states are absolutely AWFUL. The Cortex-M0+ chips are all extremely power-competitive vs each other, because Cortex-M0+ is extremely low-end with regards to core-design.

You're pretty much only getting a Cortex-M0+ because its the absolute minimum 32-bit processor on the market. (8-bitters and 4-bitters exist if you're willing to go even lower-end, but Cortex-M0+ is the bottom of ARM's offerings). So low-power seems to be a must in this market, IMO anyway.

If you're willing to use higher amounts of power, you really should get a few more features, like an FPU on the Cortex-M4.

seba_dos121 hours ago

Yes, it's a lot. It will empty a 1000mAh battery in about two days. In sleep states, you'll find it challenging to reach a single month on RP2040 while you can build things with other controllers that would last years on the same battery.

vbezhenar19 hours ago

The main issue is that there's no low power sleep mode. There are sleep modes, but they consume tremendous amount of power, so there's no way to build a battery-powered device.

1515516 hours ago

Ambiq Apollo4s run at <1mA from RAM.

Lots of variables go into this figure, but 24mA isn't great.

djfergus24 hours ago

For hobbists buying dev boards note that an ESP32 comes with WiFi and maybe Bluetooth depending on the model, whereas a vanilla Pi Pico has no radio - you need a Pi Pico W for that, which in my experience is double the cost of an esp32 board.

I agree with the authors points that the RP2040 is a great chip would love to see the Pico W pricing come down as popularity grows.

HyulianGrader1 day ago

nit: There are 6 different espressif microcontrollers in that table, not "dozens".

Espressif also went many years with only the ESP8266, then many years more after introducing the ESP32 before this recent binge of releasing a new series every time they blink. ESP-IDF is really suffering for it, so I hope Raspberry avoid this fate or at least find a better way to support them all.

rdlw23 hours ago

https://products.espressif.com/#/product-selector?language=e...

This is the official Espressif "ESP Product Selector". I checked everything in the ESP series, and limited to "Mass Production" status, and then it showed me a list of 175 products.

I'm sure some of those are doubled up, or just the same chip with different packaging options or whatever, but as a potential customer I'm still presented with 175 things and told to pick one.

dfox21 hours ago

Most of that are not bare microcontrollers (or “SoC”s as Espressif calls it), but entire modules with different combinations of SoC, Flash, PSRAM, antenna configuration and packaging. If you filter only SoCs, you get 39 products, which in fact are 9 different chips and rest are packaging variants and versions with package-on-package Flash.

em3rgent0rdr1 day ago

Considering how many different Raspberry Pis are out there now, I wouldn't be surprised if the Raspberry Foundation makes a plethora of newer microcontrollers.

g15jv2dp19 hours ago

How is ESP-IDF "suffering for it"?

HyulianGrader12 hours ago

Complexity. It's now playing catch up trying to support all of these different chips with all of these different peripherals, capabilities, and errata in quick succession.

As a developer, it's much more difficult to navigate when there are 8 files with the same name, 5 registers with the same name defined in different files, etc. A lot of code is heavily punctuated by ifdefs to selectively include and exclude lines for different targets, making it more difficult to follow. Intellisense struggles, no matter how well it's configured.

I could deal with all that but it's the runtime cost that is the worst. ESP-IDF is constantly getting bigger and slower. All of these abstractions, structs half-full of pointers being handed about at runtime, dead code being linked in for features the chip doesn't even support, it all has a cost.

This is even worse in binary blobs where conditional compilation is more difficult to do. I'm not convinced they're even trying though. A single commit that only mentioned WiFi 6 changes increased my binary size by over 10kB. On a chip that doesn't support WiFi 6.

ajsnigrutin23 hours ago

Many of the variants listed are the same chip but with different amounts of storage, oboard vs external (vs both) options, etc.

Otek4 hours ago

So how can one start with doing something useful with this sort of things. Let’s say I have backend experience, some spare cash and time to try to get into embedded

felipemesquita3 hours ago

For tutorials and hardware, check out Adafruit. If you’re okay with less polished documentation, also look into M5Stack (they are really cheap on AliExpress).

I currently work in e-commerce using Ruby on Rails, which I really enjoy. However, I do miss my previous work on the weird side of software and electronics for art installations on galleries and events[0]. If anyone wants to chat about or pair on embedded development, feel free to reach out to me at my username at hey.com. [0]https://vimeo.com/389519079

cockings1 day ago

> The RP2040 is impossible to brick. It comes with a read-only bootloader that can either mount as a USB mass storage device (firmware updates can just be copypasted to the "storage device"), or use its own simple USB protocol.

Can anyone explain what this means? How is it both read-only and updateable? If the latter, how is it unbrickable?

ndiddy1 day ago

He's saying that the bootloader is in ROM so it's unbrickable, but the application code that the bootloader jumps into can be updated over USB. Most mid-range and higher microcontrollers have a similar feature, but they almost always have a custom protocol that requires a specialized flashing program rather than showing up as a mass storage device.

seba_dos11 day ago

To be frank, I don't get its appeal at all. Most hobbyist uCs were already unbrickable, and using mass storage mode for flashing is rather cumbersome and clunky to automate as soon as you're past hello worlds.

timenova24 hours ago

Hence they made the Pico Debug Probe [0]. It makes it super easy to reflash firmware to the Pico in a quick iterative loop.

However, the appeal of mounting as a mass storage device is not for iterative development (as you mentioned). Invariably something breaks, and the easiest way to get back on track is to reflash their default blank firmware using the mass storage interface.

[0] https://www.raspberrypi.com/products/debug-probe/

+1
seba_dos123 hours ago
jrockway1 day ago

I've never had great luck with the mass storage flashing. It works fine, but boy is it slow. I bought a J-Link a few years ago and haven't looked back.

(It just takes a long time for the OS to recognize a USB device. And you have to press the reset button yourself in order to enter the bootloader. With something like J-Link, your build script can handle pressing the reset button and sending the code, saving you quite a bit of time between iterations.)

drrotmos23 hours ago

A debug probe is nice (quite possibly a must) if you're actively developing, but for deploying in a hobbyist environment, USB is hard to beat.

I make open source espresso machine hardware (github.com/variegated-coffee), and it's nice to be able to give users a wired way to update firmwares that doesn't require extra hardware.

crote21 hours ago

Interesting, I've got the exact opposite experience.

Small to medium production runs are always a bit of a pain, because you have to do a lot of coordination with the factory when it comes to tooling. You have to ship a custom programmer, get them to install the drivers on whatever OS they are using, and then find a way to write custom code to interact with the programmer and deal with all the possible error conditions.

The RP2040? A simple script which detects the presence of a RPI-labelled flash drive, copies a file, and repeats. Written in half an hour. Drivers? Not an issue. Hardware? Everyone has a USB cable lying around already. Error conditions? It either succeeds, or it doesn't - the OS handles the rest.

dgroshev24 hours ago

I completely agree that it's inconvenient as a developer tool, a debug probe is much, much nicer.

I just think that despite all testing and care bugs are still possible, and the ROM bootloader is a backup that's always there. Plop a tiny switch on the PCB, and even if I screw up an OTA update customers will still be able to flash with no special tools (if the device has a USB port, that is).

I also use it as a recovery state for panics, makes the device impossible to brick by a panic loop.

seba_dos123 hours ago

> I just think that despite all testing and care bugs are still possible, and the ROM bootloader is a backup that's always there.

That's orthogonal to mass storage mode. ROM bootloaders were standard in this class of microcontrollers for years, but they usually don't use UMS. One could argue that UMS is perhaps better than some custom incompatible solutions, but then that's what DFU is there for - a standard way to flash things over USB.

numpad03 hours ago

Looks like there are docs that states RP2040's USB code is on an internal mask ROM, which can't be overwritten if true. The RP2040 don't have a user code storage at all, and it resides in external SPI Flash, so those can be written over without having to have an all-Flash architecture.

I've never seen other uC accidentally blowing out bootloaders, though. They have clever tricks that prevents write access on a firmware area while also allowing such firmware area updates.

I suspect the author might have heard about some horror stories like AVR's intentional in-circuit programming disabling feature accidentally triggering due to configuration errors upstream to developers or sporadic errors in data transfer, which "just" needs requires +12V input to unlock. Presumably the 2040 won't have such gotchas that scares hobbyists.

orlp1 day ago

The bootloader is read-only. What the bootloader loads isn't. If the thing you're trying to boot into is faulty, it doesn't matter because you can just replace the thing the bootloader is trying to load.

If the bootloader itself was faulty, the device would be bricked.

sshine1 day ago

To elaborate on the alternative:

When the bootloader is not read-only, you can upload another bootloader.

This is great in a different way because custom bootloaders allow for more flexibility.

For example, you may want to keep two copies of your firmware on the chip: One that you're uploading, and one you can fall back to if the most recent one has problems. This protects you against failure during firmware upload or post-deployment failure, because you only overwrite one of the two. So if the device switches off while flashing it, and you boot back up, a custom bootloader can just default to the older copy.

But... what if you update the bootloader and it fails?

Then you can't use the bootloader to upload new firmware. Bricked.

To unbrick a bootloader you need to overwrite the bootloader using alternative methods that don't involve the bootloader, which usually involves attaching wires to the print. This is highly inconvenient in a production setting: Maybe your hardware is encased, embedded in a bigger thing, or located on a pole on a mountain top in a different country.

So a read-only bootloader is a safe choice, and you can make other workarounds wrt. flexibility.

HyulianGrader1 day ago

Nobody in their right mind is updating a bootloader in the field OTA, let alone one inaccessible on a mountain top.

dave7824 hours ago

I used to work on a product where we did exactly that, and the devices literally ran on mountain tops. Our development and testing process was very rigorous and would be unrecognizable to most developers today, however. We certainly weren't shipping new code to those devices after every sprint.

+2
freedomben24 hours ago
dgroshev23 hours ago

You can have several bootloader stages, and in fact that's how the RP2040 works [1]!

Stage 1 bootloader is the one in ROM and it normally just reads stage 2 from the flash chip. Stage 2 then initialises the flash properly, and you can have further stages like [2] to implement the trial-rollback procedure.

Stage 1 is a safety net, even if the trial-rollback procedure goes terribly wrong the device can still be unbricked over USB.

[1]: https://blog.usedbytes.com/2021/12/pico-serial-bootloader/

[2]: https://embassy.dev/book/#_bootloader

perbu1 day ago

The bootloader is read-only, the firmware it boots is updateable.

The bootloader allows you to update the device with new firmware. MCU are different than computers. And since you can't overwrite the bootloader, you can't brick the MCU. You can always just reset it.

fwiw; I've never bricked an MCU buy flashing something weird onto it. The hobbyist MCUs sold are typically quite easy to re-flash with new firmware.

cryptonector24 hours ago

I think it's saying that firmware updates are not persistent. You have to apply them every time at boot time. So if it boots once, it will boot every time. If you ever get bad firmware, you just rollback or roll further forward in your boot media.

mkj24 hours ago

Unbrickable for the RP2040 itself, but most SPI flash chips (including ones on the RP Pico) have permanently lockable regions. You can lock them open though.

cide11 day ago

The lack of security features really limits where this can be used in commercial designs.

ndiddy1 day ago

In general, read-out protection provides a very limited level of protection that I wouldn't rely on to stop cloning. There's quite a few firms that will extract the firmware from protected microcontrollers for a couple thousand dollars (i.e. https://russiansemiresearch.com/ ) which is a drop in the bucket considering the potential profit from industrialized cloning. Lots of microcontroller series also have exploits that can allow hobbyists with very little funding to bypass read-out protection (here's one for the STM32F0 series for example: https://github.com/racerxdl/stm32f0-pico-dump ).

1515516 hours ago

Crypto key storage fuses and high-assurance boot are often more important than readout protection.

hitekker1 day ago

Can you explain how? Genuinely curious. The author only refers to "security theater" which seems to be when a product or system around a product makes people feel like they're safer, when actually it's not making anything more safer or more secure.

https://en.wikipedia.org/wiki/Security_theater

kj4ips1 day ago

I suspect this mostly refers to "Code Protect" or similar functions, that are designed to stop the user for extracting the firmware from a device in the field. Typically, when this is enabled, large parts of the debug interface stop working, and turning it off requires a "secure" erase, that clears the loaded firmware.

While many CP implementations are flawed, or can be bypassed by a skilled attacker (power glitching, &c), I wouldn't say they are purely theater, as they raise the required investment from a <$10 ISP to $$$+ for something like a chipwhisperer.

relaxing24 hours ago

Consider that in other fields of computer security we treat a device where attackers have physical access to be de facto compromised.

riskable23 hours ago

Even with chip security features this is still the case (if an attacker gets their hands on it it can be compromised). There's no chip that exists that I'm aware of that can't be compromised to have its firmware dumped.

It's like locks: Every time a manufacture claims to have made an unpickable lock someone goes and picks it. It's the same for chip security features.

Microcontroller "security" features really are security theater and not actual security. The only real reason they exist is because certain vendors/"big buyers" will require it as part of their parts checklists (which is silly) and it provides a way for chip manufacturers to wriggle more money out of each sale.

the__alchemist24 hours ago

I suspect the use cases where MCU security features are useful is dwarfed by those that are not.

Havoc1 day ago

How are people using this in practice?

I’ve never worked with a BGA device. I’m guessing you need to design a board send it to say pcbway and then have the equipment to solder the bga in?

dave7823 hours ago

I built a custom RP2040-based board by designing it KiCad and then sending it off to JLCPCB to be fabbed and they assembled the SMT components. I didn't do a direct comparison, but it was cheap - cheap enough that it's possible that getting the board pre-assembled from JLC was cheaper than buying the raw parts in low quantities from Digikey and assembling it myself (which, given my experience level, would be pushing the edge of my capabilities). I made a second run recently and even added some through-hole to the assembly and the board cost was still single digit dollars per board. The major problem was that shipping prices from JLC seem to have gone up significantly in the past year.

Keep in mind that it's not just the RP2040 that is difficult to solder. To do a decent PCB layout you'll need to use very small passives in order to get the placement right. I did my layout with mostly 0402 resistors and capacitors - I know plenty of people are capable of hand-soldering those but I think it would be difficult for most. Perhaps easier if you had a decent microscope, which I do not have yet. I don't think my magnifying visor would be nearly enough.

dragontamer21 hours ago

> To do a decent PCB layout you'll need to use very small passives in order to get the placement right.

0402 (inches) is small but doable. They really start to feel like grains of sand at that point.

But I personally stick with 0805 and 0603 when doing my own board layouts. I can't say I've ever felt space constrained. The placement of decoupling capacitors can be a few mil off, and in fact the "extra space" for placement helps your tweezers anyway, so you don't really want to push everything so close together.

Especially for hobby projects, I don't think anyone is really in the business of counting up the savings of 0.01" in the hobby world. Like, how small are you actually aiming for, and is it really so bad that you can't add another 0.5" to your board?

--------

Professionals use 0201 (inches) for maximum flexibility and minimal sizes. So even 0402 is larger than professional projects. If we're all accepting "larger hobbyist sizes" anyway, might as well go all the way up to the much easier 0603 or 0805 parts.

While a 0402 is slightly larger than a grain of sand, I'd say 0805 is approximately the size of a grain of rice. So yeah, doable with tweezers and solder paste. Just imagine lining up dry rice and its well within the capabilities of most hobbyists.

Its just problematic when you get smaller than that.

dave7821 hours ago

> Especially for hobby projects, I don't think anyone is really in the business of counting up the savings of 0.01" in the hobby world. Like, how small are you actually aiming for, and is it really so bad that you can't add another 0.5" to your board?

It's not really about saving board space. Decoupling capacitors need to be placed "close" to the chip, and at higher clock frequencies this can be an issue. There's enough decoupling caps needed on a RP2040 that doing them in 0805 would require moving them quite a bit further away from the chip just to have room to place them all.

An ATmega (Arduino) at something like 8MHz is really forgiving and you can take a lot of liberties with the layout. The RP2040 runs much faster at 133MHz, so presumably the tolerances are much tighter. Admittedly, I didn't try a doing a design with 0805s for the RP2040 but I read enough from people more experienced than me that gave me the impression that compromising the layout with larger passives had a greater chance of things not working right.

Since assembly is so cheap at places like JLC these days, even in small quantities, it really wasn't worth the hassle. I've done many other boards by hand with 0805s and and agree they're pretty easy to deal with.

+1
dragontamer20 hours ago
dragontamer22 hours ago

RP2040 is QFN, not BGA.

QFN is doable at home, though more difficult than TQFP leads or larger SOIC-chips. Still, far too many components are QFN today so its a good skill to pickup.

------

The techninque is:

1. Reflow soldering brings the _whole_ board to soldering temperatures, and then relies upon surface-tension to pull all the devices into proper place.

2. Solder paste is applies ahead of time. You can cleanup solder paste with a toothpick before you bring the board up to temperature. Solder paste tends to go bad pretty quickly however. When doing prototypes, opt for the more expensive low-melt solder paste to minimize potential heat damage.

3. Prefer to use a stencil to apply solder paste. But its more than doable to be sloppy with a syringe and then rely upon the solder mask + surface tension to magically cleanup things during reflow temperatures.

4. Use a hot-air gun to fix any issues. The #1 issue you'll have is tombstoning, QFNs or TQFP chips are usually pretty good about settling into place. For TQFP issues (ex: bridging), you'll need solder-wick + soldering iron. EDIT: And flux: lots of flux helps. Also, flux goes bad, so throw away Flux all the time and keep buying new batches.

---------

BGA is also doable at home btw, thanks to the above principles. But its even harder than QFN. The real issue of BGAs is that you're looking at 4-layer minimum, maybe 6, 8, or 10-layer designs. There's also substantial grounding and other advanced PCB concepts you need before you can layout a BGA-capable PCB.

Its not so much the physical activity of soldering that's hard or difficult for BGAs. Its all the theory you need to study to breakout BGAs + minimize inductance + deal with impedance matching and trace-length matching.

morio21 hours ago

I find hand soldering QFN is faster, easier and more reliable than (T)QFP once you got enough practice. If you need to rework the QFN part the key is to FLOOD the footprint with good solder flux from a syringe. Do not use one of those flux pens, those do not dispense enough flux.

dragontamer21 hours ago

> If you need to rework the QFN part the key is to FLOOD the footprint with good solder flux from a syringe.

I've never tried this but this makes a lot of sense in my mind's eye. I'll try this next time I have such an issue.

-------

TQFP seems nice because I can sloppily shove tons of solder down, and then just wick up all the excess solder with solder wick. In fact, I purposefully over-solder all the TQFP joints for this practice. (Too much solder during reflow, and then just a quick cleanup step with a soldering iron later).

KaiserPro20 hours ago

Yeah I've been seeing a bunch of chip swaps that use this method, its wild how forgiving it appears to be.

neilo401 day ago

Although it looks like BGA, it actually uses a QFN package where all the contacts are accessible at the edge. With a little practice they are relatively easy to hand solder (I've done many, not just rp2040)

dvdkon23 hours ago

QFN packages are very nice to hand-solder in my experience, considering the pitch. Better than the bridge-prone pins of QFP. The bottom pads do need some preparation, but you don't need hot air or reflow.

kragen23 hours ago

i admit to being intimidated by qfns still. any tips for hand-soldering them successfully?

dfox21 hours ago

Kind of cheating trick for the QFN substrate pad is to put a grid of somewhat higher diameter vias in there and solder the pad from the other side of the board through these vias. Another approach is to just ignore the substrate pad altogether (in many devices it should not be connected to anything anyway and has no real thermal management purpose).

+1
kragen21 hours ago
GlibMonkeyDeath1 day ago

Almost universally a hobbyist would purchase the RP2040 mounted to a pcb with other i/o components (e.g. the Seeeduino Xiao https://wiki.seeedstudio.com/XIAO-RP2040/) There are other versions which bring out more lines to accessible solder points.

Of course you can design your own custom board, but I'd wager most people don't need or want to do this.

floxy23 hours ago

You would probably be surprised what you can do with a $65 hot plate [0], no-refrigeration-required solder paste[1] and the matching laser-cut solder stencil[2].

[0] -- https://www.amazon.com/Soiiw-Microcomputer-Soldering-Preheat...

[1] -- https://www.chipquik.com/store/index.php?cPath=470&osCsid=8t...

[2] -- https://www.pololu.com/product/446/

dragontamer22 hours ago

Pololu's stencils leave much to be desired. They do work but I feel like https://www.oshstencils.com/ makes a higher quality stencil instead at similar prices.

-----

Note that BGA chips mostly come pre-soldered / solder balls. You also design PCBs so that there is a "well" for the balls to melt into and settle into place, and molten-solder has a significant amount of surface tension, so you can magically watch the solder "pull" your designs into place. Of course, the OP is likely talking about QFN not BGA, but... just in case people are worried about BGAs its not terrible... (its just impossible to inspect a BGA XRays).

The surface-tension can be harmful in the case of tombstoning (ex: a resistor or capacitor with two leads, especially a "sideways" low-inductance capacitor, will get "pulled up" by one side, lifting off the 2nd pad).

If you have a solder-plate + hot-gun, you can "feel" the surface tension by just grabbing a toothpick and pushing on these components as they're still hot. You'll find the pressure to be far higher than you expect.

floxy21 hours ago

Funny, I had the exact opposite experience. For OSH Stencils, they had a scaling issue with their setup that I pointed out to them, and they just shrugged and said that was the nature of the beast essentially and they couldn't do anything about it. They might have said something about Kapton shrinkage or some such. (I don't currently have the exact numbers, but it was off a couple of percent linearly, which doesn't matter for a tiny board, but for a 4" board, the difference adds up, so that if you align the apertures on one end of the board, they don't on the other side of the board. Like the aperture was off by a whole 0603 pad or more). I went back to Pololu for that same board, and everything was spot on. And I have had zero complaints with them since. If I had to complain about something, I might slightly ding them slightly on the super-tiny aperture shapes and the kerf width of their laser. But everything has always worked. Apparently YMMV.

+1
dragontamer21 hours ago
botdan23 hours ago

Just in case you were unaware, the RP2040 is available on dozens of ready-made, arduino-compatible boards like the Pi Pico, the Adafruit feather boards, of the Seeed XIAO RP2040 boards. Those have all (or at least most) of the IO already mapped to pins, USB headers, booatloaders, reset buttons, etc already mapped.

Things like the Pico are really easy to solder onto a designed PCB as well because of the castellations, so it's easy enough to design a board around the footprint and then just solder the entire pico onto your PCB with a soldering iron, avoiding the need to use something like a hot-plate or reflow oven. This has been my preferred way of working with it.

Havoc20 hours ago

Yeah I've got a variety of dev boards already, but thought moving away from that as part of a move to PCBs might make sense. Esp given the cost diff - raw rp2040 seems to be at least 1/5 of the dev boards. Dev boards are probably the better deal overall, but also less scope for learning

eulgro1 day ago

It's not a BGA, it's a QFN with a ground pad.

Havoc23 hours ago

I see. What does that change in terms of process needed?

a1o22 hours ago

BGA you need hot air and reflow but a QFN I think you can just position and solder by the side with a simple solder iron with a knife like tip.

the__alchemist1 day ago

That's the desired approach, yes, but... hot take incoming!

I think BGAs are easier to "hand" solder than other footprints (QFP, QFN etc). You drop the item in place, place it on a hot plate and or heat gun, and start melting it. Of course, if you screw it up, you are screwed. (Reballing sounds not worth it for most cases). And, you can't visually inspect.

I think this is because, at least for me, most of the soldering faults I have are due to uneven application, or improper amount of solder. BGA solves this.

seba_dos122 hours ago

> Dozens of slightly different controllers. Why?

Many of those listed are the same controllers in various modules. Espressif has a bunch of different µC series, but not that many. In contrast, aside of the whole Pico dev board, Raspberry Pi does not offer any ready-made module with RP2040.

pcdoodle41 minutes ago

I'm a little bit late to the party here.

The rp2040 is a great chip at a decent price point.

However the internal ADC is quite bad for wide range readings. There's a few points around 512 / 1536 etc where it gets a "personality" in the readings.

AVR seems to have this down much better along with internal references for even more accuracy.

childintime2 hours ago

To me the RP2040 just screams "Hello, Zig!".

ta98819 hours ago

Posted yesterday, info about the successor to the RP2040: https://news.ycombinator.com/item?id=40642268

jcalvinowens24 hours ago

The lack of built-in flash kills it for me. STM32 M3s with comparable throughput are cheaper and don't require an external flash chip (example: STM32F103C8T6 for $1.20 from jlc).

I love the generic PIO though, I really hope other manufacturers pick up on that.

riskable22 hours ago

I used to have the same beliefs but the flexibility of being able to use just about any pin for any purpose really sold me on the RP2040. When I decide to add a new feature to my boards I don't have to spend an hour examining the minutiae of the data sheet to see if I can use a given pin for SPI (oops: no, I can't because I enabled alternate function 3...). It saves a TON of track routing time and simplifies boards considerably.

Once I decided to start using the RP2040 I realized the "strange" flash situation turned into a feature, not a drawback! With STM32 you pick your part and then you can order an expensive version (if it's available!) with the max RAM of say, 512Kb or you can save a few bucks and go with say, 64Kb. Either way you're paying like $2.50-4 for a single chip.

Now compare that with the super fast, dual-core RP2040 which costs $1 (yeah it's technically $0.70 in bulk) paired with a 16 FUCKING MEGABYTE SPI flash chip (W25Q128JVSIQ, basic part at JLCPCB :thumbsup:) that costs $0.60. You get a vastly more capable MCU with so much goddamned flash space you could fit a truck in there!

You can even partition that flash chip's space so that your RP2040 firmware is reserved to the say, the first 2MB (or wherever you wish!) and the rest can be used for storing stuff like settings. It eliminates the need for an EEPROM! Not to mention there's enough storage space in there to store all your settings in something absurdly inefficient like JSON and the chip is fast enough to parse it too!

Working with the RP2040 in reality is just SO NICE. Seriously, try it! You won't be disappointed.

diydsp21 hours ago

Haven't used the RP2040 yet, but having worked with SPIRAM and SPIflash on the ESP32, and also on many different STM32s, I can say this: if your project reaches a certain size, lots of tasks or multiple chunks of discontiguous memory, then the caching of the SPI memories becomes a traffic jam and things that should be really fast get really slow. And you start running into lots of weird error messages from inside the esp-idf drivers that you can't do much about. It will drive you crazy. You have to start strategically partitioning your memory, create/delete tasks dynamically, adjust lots of params in menuconfig, etc etc.

Not a problem for most hobbyist projects, but when you start to push the limits the ESP32 feels like a chipboard apartment building compared to STM32's concrete and rebar. Hopefully the RP2040 doesn't suffer the same problems.

jcalvinowens15 hours ago

I'm speaking from experience, I built two boards with the rp2040 before I decided to stop using it.

The pin flexibility is nice, I agree with you there. But I spend more time dealing with the flash chip than that saves me.

I don't want more capability. An STM32 M3 has far far more processing throughput than I need for 99.9% of what I do. I want the smaller thing, even if it isn't cheaper. It is sufficient.

I love stm32s because I can write bare metal C without using any of stmicro's libraries at all (except the one header defining the register offsets). Here's an example: https://github.com/jcalvinowens/ledboard/blob/master/firmwar...

The rp2040 is not set up to easily let you do minimalist stuff like that. And after all, why would they go to the trouble? You have 16MB of flash to waste on library code you never call... it's like buying a mack truck to commute to work.

I'll also echo the other comment about the cache: if you actually have megabytes of .text, you're gonna have a bad time.

jcalvinowens12 hours ago

I forgot another win for the STM32: no crystal.

dave7822 hours ago

I agree with all that and would add that the documentation is fantastic, and the software tooling and SDK is well-done. That's a big advantage that vastly outweighs small differences in cost (unless you're selling millions of something).

bangaladore24 hours ago

That chip has over 10x less RAM and only 60k flash. It has only one core and that core is clocked at half the speeds compared to both the RP2040 cores.

And it cost six bucks from US distributors. I can buy a single RP2040 chip from Digikey for 70 cents. Even if you add another dollar for flash memory, you are still far better off.

jcalvinowens23 hours ago

I mean, that's sort of my point: the rp2040 has an absurd amount of RAM for a micro, I don't need it and don't want to pay for it.

I care more about the cost to manufacture boards with the part, than the cost to get sample parts mailed to me in the US :)

jsheard24 hours ago

> I love the generic PIO though, I really hope other manufacturers pick up on that.

Unfortunately the Pi Foundation is seeking patents on the PIO architecture. I don't think they've been granted yet though.

amelius23 hours ago

Isn't that already covered by FPGAs? I mean, it is just a way of configuring ports. And FPGAs are much broader (also configuring computation).

crote21 hours ago

No, FPGAs work substantially different.

You can think of an FPGA as a bunch of "programmable transistors". You've got a whole bunch of basic logic building blocks, and you program the wires between them to build a logic circuit. This means it is great for building relatively simple but high-speed logic (grab sample from sensor, do some additions and multiplications, store result in external DRAM chip, repeat at 5GHz). However, they are really inflexible: getting them to do different operations depending on some condition is extremely costly.

The PIO, on the other hand, is essentially a really basic CPU core. It reads and executes a stream of instructions, and it can do (very simple) math and conditional logic. This means it is great for building some kind of state machine, which dynamically adjusts it behaviour based on some kind of external condition. The unique selling point of the PIO is that the instruction set is completely designed around super-fast IO, so reading or writing two dozen pins can be done in one or even zero(!) instructions. And because every instruction executes in exactly one cycle, you've got really good control over the exact timing. This makes it ideal for implementing hardware-level protocols in software.

amelius19 hours ago

In that case, it sounds like they reinvented the coprocessor. I don't see any fundamental difference between that and what they did.

arlort21 hours ago

The same features of pio can be implemented via FPGA, but it's a lot more complicated to do so, and probably you won't find FPGAs as cheap as on the pi

nereye19 hours ago

One example (PIO implemented in Verilog for use in FPGAs):

https://github.com/lawrie/fpga_pio

1515515 hours ago

This core is probably less than 1000 lines of RTL (the verification suite probably being far more.)

KaiserPro20 hours ago

Source? I've not seen a patent for that, plus I suspect its not actually patentable

jsheard20 hours ago

https://forums.raspberrypi.com/viewtopic.php?p=1837408&sid=6...

I haven't seen a more recent update, unsure if they abandoned the patent bid or if it's just taking a while to go through the system.

vitiral24 hours ago

seeking patents to then open source it?

Right?... Right?!?

jcalvinowens24 hours ago

That's really disappointing :/

joezydeco24 hours ago

Are you gated on PCB real estate, or cost? 8 megabits of QSPI is under 50 cents. I really don't care that it's external if the entire chipset is under 2 bucks.

the__alchemist24 hours ago

Not the OP, but I'll say, whenever designing a fresh board, this sort of convenience built-in is nice. Individually, it's not a huge deal, but when you start adding things that are sometimes built in (external crystal vice internal? flash? PDs on USB or a bus?), you appreciate when it's one less component to allow spacing for, that might be out of stock at a given order etc. Also note that QSPI flash has a number of connections, you have to check the datasheet etc to know what to wire where, if you are changing MCU footprint you have to re-wire it each design etc.

joezydeco23 hours ago

I'd agree with most of those points, but in my decades of experience here...YAGNI.

jcalvinowens23 hours ago

Exactly this, it's just another thing to deal with and I save a little time by not having to.

12722 hours ago

PIO is fantastic. Revolutionary. Not trivial to use but extremely powerful and adaptable. Too bad about the ADC. To be clear: the ADC is not "OK". It' s BAD.

GeorgeTirebiter19 hours ago

Unfortunately, the poor ADC performance is due to a design / simulation error; at least you have to give them credit that they 'came clean' on the crappy performance, and explained it in the official documentation: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... section 4.9

See https://pico-adc.markomo.me/ for a thorough analysis of the problems.

Especially look at the DNL.

AtillaBosma22 hours ago

I want to shout out the fighting game community with: https://gp2040-ce.info/

It has been using the RP2040 to create cheap and easy to make controllers for fighting games while providing the lowest possible input delay.

The RP2040 does a great job acting as a chip for the base of a gamepad, so it doesn't even have to be for a fighting game controller, but any controller you want to create.

tiku1 day ago

My Switch is unlocked by a rp2040. A lot of devices could be modded with it, given the size etc.

snvzz9 hours ago

Dreaming about a smaller, lower-power yet faster RISC-V CPU (many cores exist that are strong against cortex-M0+) with the RP2040's peripherals.

fxtentacle22 hours ago

The real competition is the STM32 line-up, in my opinion. Much more computing power at a comparable price. Or half price if you only need a few MHz.

Teknoman11718 hours ago

Admittedly this is from a hobbyist perspective, but I'm hard pressed to reach for an ATmega for basically anything these days due to the RP2040, the Pico, and its clones.

I do wish there were more ADC channels though. Even an external analog mux costs more than the whole RP2040...

dheera18 hours ago

I much prefer the ESP32, the RP2040 doesn't even have WiFi or bluetooth, you would think every microcontroller should have those things these days.

snufkin9724 hours ago

YES! TL;DR: its more powerful yet cheaper than most of MCU market, well documented and very straightforward yet extendable on many levels

I agree with the post in 100%, I use RP2040 for both hobby projects and my keyboard startup project (arrowmechanics.com in case sb was interested).

IMHO What RP foundation did is the greatest breakthrough in the world of embedded tech projects since the popularization of atmegas.

dragontamer22 hours ago

RP2040 is awkward in my experience.

Everyone needs Flash, and RP2040 has none. Very few projects need more than 32kB of SRAM (especially on an anemic Cortex-M0+ core). You're missing an FPU (like on Cortex-M4 or higher chip), so DSP capabilities are awful even if your clock speed is high.

RP2040 has awful power consumption: 20mA. The M0+ competitors are 10mA, 5mA, or even sub 1mA. Once we get to more recent Cortex-M23 or Cortex-M33 (or the 8-bitters)... many competitors sleep in the under 1uA (!!!) regime, meaning "always on" chips (when you're under 15uA or so, you're undercutting many battery's internal leakage currents, so your chip's current usage becomes a rounding error). RP2040 is incapable of "always on" computation like this, so this limits applicability.

RP2040 has some peripherals, but its missing common modern components. Many competitors (AVR DB, TI's MSP430 and MSPM0, STM32G4) have OpAmps for mixed-signal conditioning. Most competitors have multiple analog-comparators. DACs are somewhat uncommon but AVR and TI offer them.

-------

So comes the question: what kind of project are people using RP2040 for? It can't be cost-optimized, because by the time you buy a flash-chip and external oscillator you've overrun the costs of the competitors.

Its not power-efficiency, because RP2040 is a power-hog. You're getting far less battery life compared to competitors. (Case in point: the microcontroller that handles your wireless credit-card transactions is battery-less, running purely off of the energy of latent energy waves in the NFC protocol. RP2040 will never reach these low levels of power consumption).

Where I see RP2040 as useful, is utilizing its absurd 264kB SRAM (far, far larger figure than most chips). If you need a graphics framebuffer for a small 300x200 8-bit color screen or something, then RP2040 is probably the right choice. (60kB for the framebuffer, and likely 2 or 3 of them for various computations on the frame buffer).

But outside of a display driver, its difficult for me to find projects where RP2040 is actually the correct choice. Besides, screens are relatively expensive (in both $ and in power consumption), so if you're getting a screen you probably can upgrade to a SAM9x75 with full 2D GPU, DDR3L 800MHz and Linux support for like $12 for those SiP packages.

-------

At a minimum, the next version of RP2040 needs to include on-board Flash / on-board programming. This is something _every_ project needs (RP2040 needs to run its code off of _something_ anyway). The fact that it ships flash-free is incredibly absurd to me at least.

RP2040 forces a microprocessor-mindset ("one chip" where you add a bunch of addons) inside of the low-cost microcontroller market segment. Its very strange.

jsheard18 hours ago

> At a minimum, the next version of RP2040 needs to include on-board Flash / on-board programming. This is something _every_ project needs (RP2040 needs to run its code off of _something_ anyway). The fact that it ships flash-free is incredibly absurd to me at least.

You might get your wish there with their next chips, their last investor report revealed that it will be the "RP235x family". Based on the naming scheme they established with the RP2040 that would be two Cortex-M3 cores with ~512kb RAM, and the "X" placeholder being the amount of onboard flash where the RP2040 had a "0" for "no flash", so that implies there will be a range of models with different amounts of integrated flash.

a1o22 hours ago

Well it's still young so of course there's only RP2040. I remember the 8051, 8052, 80C51, up to the recent ADuC845...

amelius24 hours ago

I have just one question: is this product meant for the "hobbyist" space only?

joezydeco24 hours ago

I was on the fence about using it for a small commercial project I'm doing, but the lifetime has been put out long enough (2041 at this point), and it's so freaking cheap that I'm going to do a one-time buy of 10 years worth of parts.

Lack of code security and onboard flash weren't dealbreakers for me here, but others will have more stringent requirements. QSPI is so incredibly cheap now.

amelius24 hours ago

Ok. One thing I'm worried about is that the tooling is made for hobbyists only. Is there a way to do everything from the commandline with FOSS tools and without installing e.g. the Arduino-IDE?

dave7822 hours ago

> Is there a way to do everything from the commandline with FOSS tools and without installing e.g. the Arduino-IDE?

Yes. In fact, the official getting started guide[0] is all command-line based, with an optional chapter later on about using VS Code if you wish.

I have a low volume product in production using the RP2040 and I've never once opened up any sort of GUI for developing the software or programming it.

[0] https://datasheets.raspberrypi.com/pico/getting-started-with...

riskable23 hours ago

Since the RP2040 uses external flash you can pre-program the flash chips before they even get soldered on to the board. Other standard methods still work like breaking out the debug pins to some spot on your PCB so you can quickly "pogo flash" it as part of an assembly process.

joezydeco23 hours ago

I'm using the CircuitPython environment. I'm editing in vi and writing directly to the USB storage on the RP2040, which reboots upon write and runs the code. It's no big deal. There's also a virtual UART off that USB connection for light debugging.

mordae23 hours ago

Yes. Pico SDK is C with CMake and Rust is bare metal (I think).

silvanocerza23 hours ago

Maybe with the Arduino CLI?

dgroshev23 hours ago

I'm not sure how things are in the C land, but if you write Rust take a look at this book [1], Embassy has a very good support for the RP2040.

Probe-rs [2] works perfectly well with GDB and the CLion debugger.

[1]: https://embassy.dev/book/

[2]: https://probe.rs/

mmoskal24 hours ago

Definitely not. My understanding is they got significant market share on lunch - since it was during the pandemic chip shortage and they were the only ones with sub year lead times.

amelius24 hours ago

Ok, but does it fulfill military or automotive standards?

riskable23 hours ago

I don't know about military standards but there's only ONE automotive standard and it's ISO 26262:

https://en.wikipedia.org/wiki/ISO_26262

There's nothing in ISO 26262 that would prevent someone from using an RP2040 in a car. You'd just have to be redundant about everything which you have to do anyway regardless of the chip you choose.

Also, ISO 26262 is not a law. It's up to the auto manufacturer whether or not they'd require it and no single chip on its own can claim to be "certified" (or similar) for ISO 26262 since the focus is on redundancy and error checking (which means one chip would check the status of the other and vice versa, not some special internal consistency checking feature... That's just marketing).

Most "automotive" versions of chips (e.g. Atmel's stuff) are just branded that way. Atmel will make a claim like, "this chip has been tested to function properly under these sort of extreme conditions..." (that happen to match what car manufacturers are looking for) and then a car company would just trust that and make it so that only chips that are marked "automotive" and manufactured by Atmel will be allowed to be used by their electrical engineers (or suppliers).

It's all entirely arbitrary though: If you can convince the manufacturer that your board works fine under the conditions they require they'll probably buy it. Well, they won't hold it against you that you used one chip or the other. They just want some assurances.

+1
aaronmdjones22 hours ago
mordae23 hours ago

Probably yes, but it doesn't have the paperwork AFAIK.

dgroshev24 hours ago

Personally I wouldn't put it into a toothbrush (the benefit of right sizing is too high when you produce tens of millions of those), but for lower volumes I'd go for it.

Fwiw I'm working on my own consumer product/dev tool and I'm very happy with the RP2040.

demondemidi3 hours ago

Does the RPI boot rom have DFU built in? If not, it can be bricked.

vardump2 hours ago

It's literally a ROM. You can't overwrite a ROM. There's no flash or EEPROM on the chip at all.

1515515 hours ago

Give me a USB high-speed PHY.

Otherwise, NXP FlexIO is very similar to PIO and these are much more capable chips.

gbin21 hours ago

Indeed the software support is awesome, even using rust on it is a pleasure!

robomartin18 hours ago

Back a few years ago, due to chip shortages I was forced to use the RP2040 on an industrial project. No option really.

The first problem with the chip is that it has zero security. Not important for hobbyist, I get it, however, for professional applications, this can be very important.

Not, it isn't always about not wanting people to read your code. The application in question was a networked industrial controller with a thousand nodes. At a minimum, there's a need to ensure that the code and data cannot be altered. External memory does not allow for this. Our customer understood supply chain issues and agreed to accept the RP2040 design provided we replaced all nodes (at a cost) once a non-RP2040 node could be manufactured.

Before I talk about the other problem I have to admit not having looked at the RP2040 ecosystem for about two years. No idea if this has changed.

The other problem is that the RP2040 team was --again, don't know if this changed-- down-right hostile about Windows. They would respond to requests for better Windows support with moronic statement like (paraphrasing) "Just switch to Linux. It isn't that difficult".

These statements were both tone-deaf and ignorant of realities out there. When you start dealing with non-trivial, non-hobby designs, there's a need for practices such as PLM (Product Lifecycle Management). When your entire engineering organization is using CAD, CAM, EDA and other tools rooted in the Windows ecosystem, you might not have the freedom to switch to Linux just because you bought a little $0.50 chip. It doesn't work that way.

Even worse, if we did that, we would be forced to store a full VM with the working Linux distribution and RP2040 toolchain with every single release of the design. Note I did not say "software". I am talking about mechanical, electrical, optical, multi-board firmware with different processors, tests, manufacturing, manufacturing testing, etc.

In other words, the ill-informed "just switch to Linux" attitude simply revealed that --at least at that time-- this organization did not understand the professional/industrial embedded world in the way companies like ST and others actually do.

The net result was that, as much as the chip was super-interesting, we dropped it like a hot potato as soon as we could and moved back to the STM ecosystem, where the chip provider doesn't think that asking us to upend our entire workflow for single chip is a sensible suggestion.

IshKebab24 hours ago

TL;DR: he likes it because there's only one version available, whereas most microcontrollers have many more than one variant.

This seems like a very weak argument.

IMO (just based on the specs; haven't actually used it), the main reason to use this is for the PIO stuff. That's a very niche use case though.

t4356224 hours ago

...because that means there's a lot of support and documentation for that 1 variant and lots of people have solved problems and written about it,

This is like the iPhone strategy against Nokia. When I worked at Nokia it produced many variant phones - each with a little more ram or a bit less or a better screen or a different chipset. This was because they thought that people bought on price and wanted to have a product at every price point.

The builds took more than a week to finish, the bug fixing was horrendous. The software sometimes had to work with not enough RAM sometimes with different chipset bugs, different graphics limitations. It was a nightmare to produce a quality product. Then out of e.g. 18 phone models we had to customise each one for 1000 operators in the world which intensified the pain and effort.

At that time Apple had one iPhone. It was over specified - lots of RAM, great graphics etc. They only had to test their code once - not 18 times.

SillyUsername23 hours ago

The ESP8266 and ESP32 from what I've seen have got far more documentation and support (also due to library compatibility between the two chips). I've personally not come across any lack of documentation or compatibility issues, which I guess only happens if you need to target many versions of a chip, which isn't a problem for most people unless you're an API developer.

miunau23 hours ago

Making software for all those models was exhausting. It took an entire team just to profile phones and make configurations for compilers (what is the screen resolution? does it have feature x? is there a physical keyboard, and how many buttons does it have? where are the crucial buttons located? ...), and then you ended up with hundreds of targets taking days or weeks to make a build. I know many programmers that quit the industry altogether during those times.

vitiral24 hours ago

... and because they designed the chip to be a jack of all trades, which he really likes.

dragontamer21 hours ago

> IMO (just based on the specs; haven't actually used it), the main reason to use this is for the PIO stuff. That's a very niche use case though.

PIO is interesting but I'm not fully convinced they're better than a suite of dedicated timers, especially in the realm of power-efficiency.

The _real_ wtf?!?!? spec here is 264kB of SRAM. At this price point / power-consumption, that's a _LOT_ of SRAM. Any application that needs a ton of SRAM (ex: 300 x 200 pixel 8-bit LCD screen) will find good use in the RP2040.

A lot of the other parts of the RP2040 are quite lackluster. PIO is "interesting" but seem somewhat overhyped to me.

CamperBob223 hours ago

The real risk with the chips that offer the same die in dozens of slightly-different packages is the supply chain. Rest assured about 80% of those variants will be out of stock more or less permanently in a few years, once a few major customers have settled on a few specific parts. Good luck guessing which ones you'll be able to get.

tianleli8 hours ago

[flagged]

cide11 day ago

[flagged]

written-beyond1 day ago

Inb4 esp32

cockings1 day ago

It's mentioned in the article.

topspin21 hours ago

That bit of snark is about the ESP32 brigade that plagues every project or story that involves any non-ESP32 MCU, including this one. Yesterday I watched a long live video by the engineer of a open source engine management system, and he too had to deal with the ESP32 brigade in live chat. He has entirely reasonable technical justifications for his choices, and his explanation had about as much impact with the ESP32 brigade as I've come to expect.

written-beyond20 hours ago

Look my comment was just a place holder for that brigade, I was just trying to keep it isolated to this comment so it doesn't plague the rest of the article. I genuinely find other MCUs very interesting and love reading about them and exploring them. However I do this Espressif has earned the fans and following they have.

I've had the liberty of working with older platforms like the PIC32, and while I agree that every MCU has it's own use case, the developer community Microchip has no comparison to Espressifs. I will admit that I may be comparing apples to oranges.

topspin14 hours ago

> keep it isolated to this comment

Thoughtful, I suppose. Entirely futile, however, as you can see.

metadat23 hours ago

If this RPi main chip costs $0.70, why does the finished product currently cost $93.00 (RPi 5)? They're quite expensive nowadays, I miss when you could purchase them for ~$30.00.

Meanwhile, Expressif chips are literally everywhere and becoming ever more ubiquitous.

Edit: Thanks friends for the correction. It is cool you can still buy an RPi Pico for $13.00 :)

wheybags23 hours ago

Because it's not the same chip? https://en.m.wikipedia.org/wiki/RP2040 read the the specs and it's clear that is not the main chip in an rpi 5

oakesm923 hours ago

The main chip in a Raspberry Pi 5 is a Broadcom BCM2712.

The main chip in the Raspberry Pi Pico is the RP2040, which costs $4.

smcameron23 hours ago

The RP2040 is not what the RPi 5 uses.

seveibar23 hours ago

A raspberry pi 5 doesn’t use this chip (at least as the main chip). The RP2040 is for microcontrollers/embedded applications.

j_leboulanger23 hours ago

Because the RP2040 is not the main controller of the RPi.

It's a micro controller, on which the Raspberry Pi Pico is based, at $4