I like the RP2040 | Hacker News Reader

I like the RP2040

dgroshev.com

649 pointsdgroshev398 comments

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.

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.

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.

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.

You can't run Linux on DRAM. You need a CPU.

You can't run anything on an RP2040. There's no Flash or code space.

RP2040 sits at an awkward placement. It requires external parts, but low end SPI parts and not the nicer proper RAM like DDR3L or the like.

------

My point is that if you have a design that fundamentally requires external parts like the RP2040, the accurate comparison is against MPUs. Chips that are specifically designed to work with powerful and cost effective external components.

--------

Analog-focused designs like ATMega, ESP32 or STM32 comfortably do things that the real computers or MPUs cannot do. Like read a voltage, work with OpAMPs or other analog stuff that cannot fit on a proper Linux computer chip like SAM9x60D1G. And to do so without any external parts, so that you have the simplest design possible.

Glad you mentioned Microchip. The PIC32MK family is MIPS architecture microcontroller, with hardware floating point unit, running at 120 MHz, with a whole slew of peripherals, like 10 MHz unity-gain op-amp, D/A converter, lots of flexibility in mapping peripherals to pins, fast A/D, DMA, etc..

https://www.microchip.com/en-us/products/microcontrollers-an...

ESP32 chips also need external SPI Flash, and many STM32 have little flash and QuadSPI with execute from external flash capabilities, so I don't see this as a specificity of RP2040.

Some ESP32 chips have in-package flash, e.g. ESP32-C6FH4.

Turns out you can actually run quite a lot with dual core CPU clocked at 250MHz. You can also use part of the flash as file system, but that's not quite as straight forward.

Many devices run entirely from RAM which is completely viable with the ROM bootloader/SWD.

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.)

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...

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.

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.

he said?

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"

I don't think this is the case. Isn't it that "guy" is essentially gender neutral in this context? In the same way you can reasonably say "hi guys" to greet people of any gender.

"Silicon person", "silicon gal" etc would be weirder phrasing. "Silicon specialist" maybe but I don't personally think any of this merits discussion.

Maybe it's used neutrally in greetings (e.g. "Hi guys,") but when referring to someone specific, if you say they're a guy, it will generally be assumed that person is a man.

There's no maybe about it. And it goes beyond greetings. But I do agree it was non-sensical here

You're right, people do use it neutrally in greetings, not just maybe. And in more than greetings, more as a general form of address. More specifically, I would say that when not used to address multiple people in the second person (i.e. when saying "you guys"), then the word "guy" implies that the referent is male.

Except for idioms like "I've got a guy" where you just mean you've got someone in mind. And that's where I was coming from with "silicon guy" or "hardware guy", "software guy" etc. Just as generic terms for your goto person in those fields, no gender implied.

I hadn't heard anyone use the word "guy" like that before now, and didn't know the word was used like that, so I wasn't thinking of those cases. If you said "I've got a guy" or "software guy" I'd assume you meant you had someone in mind who's a guy, i.e., male. I believe you, though. This might be something that differs regionally.

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...

I'll give it a shot, but what about the grammatical singular agreement of the rest of the sentence? Should I leave my second-person verbs in the plural, as in you do, you have, or modify them, as in thou dost, thou hast?

https://en.wiktionary.org/wiki/-est#Middle_English

I guess you're basically asking me to speak dialectical Yorkshire.

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.

Some time around the year 1500, English speakers stopped addressing each other as "thee" in favor of the plural form "you". The singular "thee" is intimate and informal, but might be considered rude in the wrong context. So using the more polite plural form "you" in all contexts is a safer option.

Many young people seem to use the gender-neutral "they" rather than "he" or "she", even when the gender is known and is unambiguous. This may turn out to be a fad, or it may be a similar generational shift in the language.

What I find quite interesting is in the northern irish dialect, plural you is quite uncommon, usually plural you becomes yous or yousins, because irish has seperate words for singular and plural you

I wonder if the 20th century NYC dialect had "yous" from the wave of irish immigrants. As in "Yous guys ova hee". (Speaking as a native new yorker who doesn't hear this dialect much anymore except for maybe at a mechanic in, say, south brooklyn)

> Many young people seem to use the gender-neutral "they" rather than "he" or "she", even when the gender is known and is unambiguous. This may turn out to be a fad, or it may be a similar generational shift in the language.

I don't know if it's generational, but on the internet it's less clear what someone's gender is, and assumptions have a decent chance of being wrong. The result is that I typically try my best to default to "they" for anyone who hasn't asked me to use different pronouns.

The vast majority of real, commercial MCUs do not have WiFi in-package. The ESP32 is unique in this regard and is one of its only redeeming features.

I would rather buy the RP2040 and the NRF7001/NRF7002 for the same or less total cost and have a substantially better wireless solution (5.4GHz WiFi 6).

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

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

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

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/

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)

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

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.

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.

I often just spin a $5 JLC EVM of my own when manufacturers charge too much for theirs. EVM schematics are usually available to clone.

Normally, I can also test a domain-specific subcircuit or two in my "EVM" as well with no added design risk.

The PIO allows you to bit-bang DVI/HDMI; you can put the RP2040 on any bus imaginable (which is the real reason it's popular for console modding) (from a digital perspective of course); you have two PIOs so you can convert between two buses/signals, etc. You can convert digital video, e.g. RGB as used on consoles or DVI, to VGA or DVI if you wanted to. In the past you would've needed an FPGA or CPLD in the middle.

PIO can be PWM, SPI, I2C, USB, DVI, VGA, ISA-bus, PS1 memory card, that weird protocol some old EL-display uses and hundreds of other peripherals. Lots of exotic protocols for which you would have previously needed an FPGA.

That's why you'd choose RP2040.

Or I would just choose an NXP IMRXT-series MCU with FlexIO (which can do 90% of these protocols) and actually be able to protect my product to some degree (encrypted XIP, high-assurance boot, SWD lockout.)

> encrypted XIP, high-assurance boot, SWD lockout

Yeah, would love these on RP2040.

As well as better ADC, "halved" (half mem, IO, PIO and CPU) cheaper version, "doubled" version (2x mem, IO, PIO and M4f CPU cores), integrated flash version, etc. Better power consumption.

That said, I do like PIO and you can use RP2040 as a PIO-peripheral to something more protected.

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.

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.

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

That's pretty interesting, could you list some?

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.

rp2040 is 64cents @ 1000qty, thats a good price, compatible winbond 16mbit flash is 12cents.

You need to go up way above a dollar to get comparable specs, given the unique nature of rp2040, two cores with fairly high clock, 264kb sram, pio.

The only thing i dont like about rp2040 is the package, not hobbyist home soldering friendly for custom board designs.

  > not hobbyist home soldering friendly for custom board designs

I assume by home soldering friendly, you mean too small. I'll make a case for why this isn't a bad thing...

If it's difficult to solder a QFN package, then it will be equally difficult to solder the passives and flash it requires. Its price, availability, and good documentation make up for the package by creating an ecosystem of cheap boards hobbyists can use instead.

For example, I designed a keyboard around the Solder Party RP2040 Stamp (https://www.solder.party/docs/rp2040-stamp/). It integrated all the difficult components in a package that fit between the arrow keys and delete key.

> If it's difficult to solder a QFN package, then it will be equally difficult to solder the passives and flash it requires.

Compatible winbond flash is available in sop-8 package which are very easy to solder. 1206 and 0805 are not hard to solder. Nobody is forcing you to use 0201 and 0402.

Sop, tssop or even LQFP-64 are still quite fine for hobbyists. Those can be soldered & most importantly examined quite easily.

Yes, there are various RP2040 boards that can be bought for as low as 2-3dollars a piece which makes the QFN package less of an issue.

If I need to design my own board, I would almost certainly likely use something else unless I need PIO or some other inherent quality of rp2040.

> The only thing i dont like about rp2040 is the package, not hobbyist home soldering friendly for custom board designs.

- Use home SMT reflow solutions like toaster ovens or hot sand in frying pans; or

- As the other reply suggested, use 'breakout boards' to turn the RP2040 into a through hole part; or

- Use SMT assembly services, which are getting cheaper all the time

It's not just a problem with the rp2040 - loads of modern parts have very fine pitches and/or hidden pads, gotta find a way to work with them or stick to aging out, larger parts and miss out on things like PIO.

At $1.70 (CN sources) you can obtain a 600MHz NXP IMXRT1011 with an M7 core + FlexIO and a dozen more peripherals of all types.

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.

But then you have to deal with TI’s garbage called CCStudio

Which is sad, because on paper the TI Sitara MCUs are unbeatable for peripherals and cost.

TI, if you're reading this:

- Give me standard ARM SWD facilities / CoreSight

- Give me an accurate SVD

- Give me a 10,000 page document detailing the register maps and behavior of all peripherals

- Get out of my way

And nobody else will be able to compete. (Who has USB SS/PCIE/N GMACs in one product? PRU?)

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.

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.

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

4 units per block, 2 blocks per RP2040.

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 :)

> 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.

> PCNT on ESP32

Damn TIL, never heard of that. I'll have to try it, thanks!

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

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.

Add a $2.80 ICE40 with built-in NVM and your problems are solved.

Considering the RP2040 is only $0.70, not exactly an attractive option.

If an RP2040 doesn't fit the task because it has a pitiful amount of IO, you're now into using two anyway. Two chips, two SPI flashes, two crystals - likely more than the FPGA.

If it matters for the task, that FPGA will be able to achieve nanosecond-order IO/clock-to-clock skew times - PIO is painfully bad at this (and is executed serially.)

If the task will fit FlexIO's restrictions, the NXP IMXRT1011 at $1.70 blows away the $0.70 RP2040 in basically every metric.

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.

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?

Don't worry. No one is bothering with it outside of the hobbist market because it needs an external SPI flash chip, which one cannot protect by programming fuses. Your code is left unprotected, the Chinese can easily clone your product and put millions of units on the market. The ESP chips are a better pick even with all the bugs involved. It's quite typical of the Chinese manufacturers to have like 30 models of some product and release a few new ones every few years. The ESP is no different.

External SPI flash can be encrypted on-the-fly with most real commercial MCUs - the issue is that this was not designed to be a commercial MCU for use in products.

Relative to other offerings, it's pretty nice (not a fan of ESP32 Xtensa or their new RV32 offerings - ARM chips are so much better) as a DIY/hobbyist/open source chip.

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

No love for NXP in this thread? They make a very similar peripheral called FlexIO [1] on devices like the K32.

>[FlexIO is a] Highly configurable module providing a wide range of functionality including emulation of a variety of communication protocols

It is extremely capable! I have used it to hack together an octo-SPI... which stretches the definition of the S in SPI ;)

[1] https://www.nxp.com/docs/en/supporting-information/FTF-ACC-F...

The NXP IMXRT1011 is $1.70 from CN and much more powerful/featureful than any of the more-expensive K32 chips, by the way.

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/

Why custom and not use NXP stuff?

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).

"(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...))

Ooops, you're right! Fixed & attributed.

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.

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

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

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

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

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/

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.

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.

15 years ago it was maybe $50-$150. As recently as 4 years ago it was more like $200+ and hope for a sale. Top of the line around a decade ago was a madcatz te or razer panthera for $200. The DIY aspect and ease of changing internal parts got harder with most sticks released in the past 5 years.

Brook boards alleviated some of that but that was still an extra $50-$100 depending on the vendor and available supplies and some hardware hacking that a lot of people were unprepared to do. Those who were willing to hack were hit hard because most fight sticks were taken off the market from back then and people got a bug up their butt about value during lockdown these old fight sticks started showing up for as much as $400 on Craigslist or Facebook marketplace. A 9 year old panthera was being sold for as much as a brand new Victrix. The market was rough. It still is for secondhand fight sticks.

This is why gp2040 was reinvigorating. With cheap pcbs and ready made firmware came cheap controllers. $50 gets you a 3d printed leverless. $150 gets you an aluminum leverless. There are mini boards that are just keypads with thumb sticks running the same firmware as full sized fight sticks with dual analog levers. You’re starting to see the same explosion in ideas and customization we saw in the keyboard space like 8 years 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.

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.

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.

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

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.

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.

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...

This and the shitty HDMI connectors.

I love the tiny RP2040 boards. I’ve got a few little projects based on the adafruit QT Py. I do wish there was a wireless version. There is if you use the ESP32 QT, but not RP2040 as far as I can see.

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.

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

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.

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...

I have - it does not avoid the structural and compatibility problems of Async in other contexts.

Can you go into more details? Most of the criticism I've read tends to be more abstract ("I don't like how ALL my blocking-style calls need to be async"), and doesn't propose an alternative mechanism to async that can provide a similar coding style in the same tight RAM footprint.

I think you'll find details regarding any discussion of async in rust and other languages - I don't mean to casually dismiss your question, but my objections are not unique.

The alternative mechanism is to use interrupts, DMA, multiple cores, distributed devices (eg a CAN network) a state machine, an RTOS, or, it sounds like in context of this thread, PIOs! You get the point. Do these provide a similar coding style? No, and that's the point. The coding style is the objection.

I find the "how else would you do it" style questions that come up frequently re Async rust (embedded or not) amusing. It's as if there is a new method of accomplishing a task, and asking a world that has been accomplishing this task for decades how it's possible to accomplish the task without the new thing!

As I see it, if you need everything to run on a single cpu core, the alternatives are to either implement threads (wasting memory on redundant stacks) or to write the event-driven state machines manually. Whether the state machine is pumped by interrupts or not doesn't change anything IMHO.

Because of RAM constraints, all the bare-metal projects I've worked on have used manually-written state machines, and I'm comfortable enough with this approach. But sometimes these state machines can be hard to understand when the control flow is complicated, and I am seriously considering adding some compiler-generated state machines that will fit nicely into my existing model.

none of this will be news to you, but it's probably of interest to other people reading the discussion. you can do stuff inside the interrupt handler itself, and while what you do there does have to be an event-driven explicit state machine, interrupts introduce two key differences:

- the rest of your program doesn't have to be an explicit state machine; it can use structured control flow with nested loops and conditionals and subroutines

- the interaction between the interrupt handlers and the rest of the program is almost completely asynchronous, because as long as interrupts are enabled, the interrupt can fire between any two instructions of the rest of the program; if you look at it as multitasking, it's preemptive multitasking rather than cooperative multitasking. preemptive multitasking introduces a lot of hairy error cases, and this is only moderately simplified by the fact that the rest of the program can't preempt your interrupt handler, only vice versa. arguably that makes the problem worse rather than better because you can't solve the problem with locks (except by disabling interrupts as a sort of global lock)

> the rest of your program doesn't have to be an explicit state machine; it can use structured control flow with nested loops and conditionals and subroutines

This works well until the requirements change and you have to run two structured control flows simultaneously. If I find myself in such a situation and have no SRAM for a second thread, rust async may be the quickest way to accomplish the goal without a major rewrite into manual event driven code.

i don't have experience with rust async, although i used to maintain a csp protocol stack in python async, which is pretty similar, so tell me if this is wrong

i feel like the same kind of thing can happen even if you start entirely async, because something that was previously synchronous may have to become asynchronous, which leads to having to revalidate all your concurrency assumptions all the way up its (static) call stack. wherever you were depending on not getting preempted, you need to change the code to not depend on that anymore. but if ram is so tight that you're concerned about the sram for a second stack, maybe that's a pretty small task rather than a major rewrite

that said, i don't recall having actually had that problem

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

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.

If I get your question right, you still need some host software (like a rust compiler)! It's not exactly micropython experience.

The bare minimum would be one of the examples [1] compiled with a Rust compiler and then transformed into a .uf2 file with elf2uf2 [2]. You can then just drag and drop the .uf2 file into the "mass storage device" presented by the bootloader. To get the bootloader to mount, you press a button on a Raspberry Pico (or short two outputs if you're using bare RP2040) while plugging it in.

You'll probably want a debug probe [3] driven by probe-rs [4] at some point, it's just much more convenient to flash and debug with it.

[1]: https://github.com/embassy-rs/embassy/tree/main/examples/rp/...

[2]: https://github.com/JoNil/elf2uf2-rs

[3]: https://www.raspberrypi.com/documentation/microcontrollers/d...

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

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.

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

> 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.

STM32 is great if you choose to use the community-maintained Embassy HAL for these chips. Zero vendor code, async/await - it's a dream.

The same code will more or less run abstractly on an RP2040, as well (for common peripherals/traits.)

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

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

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

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

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

> 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.

Embassy is next-level in terms of developer experience.

If you must use C, ESP-IDF/Arduino aren't terrible. But you still don't really have a package manager or means to abstract anything, especially across devices.

The cohesion present in Embassy between the HALs, probe-rs, etc. is really amazing.

With Embassy for example, I can run the same async/interrupt-driven I2C driver code on any number of different MCUs across various manufacturers. This holds true for many, many different types of peripherals in the ecosystem. For the unique peripherals, implementation style and interface are extremely consistent and high-quality.

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.

The RP2040 only has one QSPI port.

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

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

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

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.

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.

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.

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.

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?

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.

Maybe look at the ESP32 chip's datasheet? [1] This is the first sentence in it: "ESP32 is a single 2.4 GHz Wi-Fi-and-Bluetooth combo chip designed with the TSMC low-power 40 nm technology." That's the chip. Not the development board.

1: https://www.espressif.com/sites/default/files/documentation/...

What part of that contradicts my comment?

To be clear, GP is the one saying the ESP32 is more than just the chip itself, complete with battery controller and camera connector.

Hmm. You are right.

On a second re-read it seems we agree.

The Espressif chips are available as cheap modules, and frequently used as such.

People generally refer to the module, not the isolated chip. The modules are effectively like a chip that you solder to the board.

Modules are "just" chip + all necessary hardware to start + antenna connector/pcb antenna. Those modules don't add any functionality to the chip.

The main benefit of those modules is: it's already certified with FCC and others, so you don't have to re-certify your design for radio communication. Since RP2040 does not have a radio, this is unnecessary.

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

ESP32 is available as a tiny module that is soldered to the board as if it was a chip.

Ignoring the module results in a flawed comparison. The module is chip and frequently used.

If they encased the module in plastic and called it a chip, it would be the same. You can think of it as a chip.

Do they sell chip-like modules with camera connectors and battery controllers, though? I don't deny that ESP32 modules look like and are soldered as though they were chips, but to me it's clear that GP was mixing up chips (and chip-like modules) with boards.

Espressif sell bare chips, modules with castellations for soldering to a PCB, and complete boards that typically contain a module. Some 3rd-party boards use a bare chip. Some 3rd-party boards also have castellations, as do Picos sold without pre-soldered headers. 3rd-party modules are also a thing.

Here's a pic of a module and several boards that demonstrates all of that.

https://imgur.com/a/yxjG8vh

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.

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.

> 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.

The RP2040 has one of the shortest datasheets of any MCU.

Look at any Nordic part or NXP part to see what a datasheet is supposed to look like. 3000+ pages with register documentation and behavioral examples.

To be fair, RP2040 also has the least features compared to those.

I’m not talking size of documentation, but it’s “bio-availability”.

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.

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.

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

If you do not need basic WiFi connectivity, the ESP32 is an overpriced, underpowered chip for which dozens of cheaper, more feature-rich alternatives exist.

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

no, of course not

I dont see why that's obvious.

many new chips don't even have non-chinese datasheets

You're making a probabilistic argument against the existence of an American made (or designed) equivalent to a Wifi+MCU module on a chip?

how is america in any way relevant here? we were discussing china

you might be able to find american-designed (or european-designed, african-designed, antarctica-designed, etc.) chips that do something similar, but you can be pretty sure they will be made either in taiwan or in the rest of china

in a now-deleted response to this comment, you asked, 'How is it relevant in the thread I started by asking for american designed chips?'

you didn't ask for american-designed chips. you asked for non-chinese chips, but many chinese chips are american-designed (in some sense, all of them, since transistors and integrated circuits are both american inventions). literally what you said was

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

i just went back to see if you'd edited your comment, but no, that's literally what you said, byte for byte

That's very helpful.

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.

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.

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

> 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.

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.

Raspberry pi was originally an educational non profit

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.

Ooh, good point! I should definitely look into that.

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.

The USB version doesn't directly imply link speed - USB 2.0 devices can be LS, FS, HS. The RP2040 can handily saturate LS/FS links.

With PIO or the SPI master and DMA you could absolutely make use of a USB HS PHY.

A PHY for the USB PD communication over the CC wires. That makes it possible to negotiate things like Alt Modes for a USB-C connector. DIYing one is surprisingly hard due to the voltages and timing involved.

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

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

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

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

AVR64DD14 is $1.20 qty25 for 64kB of Flash and 8kB of SRAM (and quite a bit more analog features, like dual-power supplies, more ACs, DAC, Differential ADC...).

So I'm pretty sure NOR Flash remains quite cheap. TI's MSP430 are all cheapest with FRAM though, so your question is curious. I admit I don't know where to go or how to investigate your question however. I don't really use MSP430 myself, I just know thats what is commonly associated with FRAM in the literature I've read.

huh, I wonder why it wasn't coming up in my search

just as a perspective point on 'quite cheap', nor is still about a thousand times more expensive than nand

i would never buy from ti. they hate hobbyists and have since at least the 70s. they put limor fried on a blacklist

The main application here would be that the RP2040 only has a single XIP QSPI bus. If you extend its memory by hooking up PSRAM to that bus, you can't boot because the chip loads all its code from QSPI. If you hook flash up to that bus, you don't have any way to add extra memory.

FRAM would allow you to have your cake and write it: your application code survives a reboot, and (if the chip were to gain write support) the remaining space could be treated like PSRAM.

i see, that makes a certain amount of sense, thank you. normally you can share a single spi or dual/quad spi bus between multiple peripherals with different /cs lines, but i guess that would be pretty tough to make work for instruction fetches. older chips like the 8086 had a pin to tell the memory system when it was fetching an instruction, but i haven't seen that feature in a long time, not even enabled by a fuse

you can probably use qpi that way (with both psram and flash) if you sacrifice xip and settle for loading overlays? you could even store them on qpi nand

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?

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.

I haven't found a lack of documentation, examples, or available experts with most of the microcontrollers I use. It's great the RP2040 has those, but it's not a unique advantage to them.

The RP2040 does have a great advantage for people who are new to the microcontroller game, though! For me, personally, that doesn't matter much because I'm not new at this.

I agree, in a one-off or small run project, the cost of the microcontroller is usually irrelevant. I only mentioned it because when all else is equal, I'll go for the least expensive option anyway.

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.

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

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.

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...

> 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?

> Ultimately maintaining things isn't free.

This is a hypocritical stance for any project that accepts free contributions from the public. Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?

> Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?

Platformio I suspect.

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.

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.

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

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

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

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?

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/...

> 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.

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.)

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...

> 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.)

Part of hardware design is letting go of your neuroses. The real world isn't a perfect place. You operate with the situation you have for the design at hand.

Ask yourself why you really need everything to be the exact same.

Laying down a handful of capacitors, a single of QSPI flash, and a crystal should become second nature to anyone professionally practicing in this field.. it should take 30 seconds to position and rotate these components near the appropriate pins and not too much longer to route (minutes at most if you've done it before for this MCU.)

what is the drama with platformIO ?

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

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.

> 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?

>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.

> 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!

I've been through the full FCC certification process for an intentional transmitter, and it is pretty labyrinthine, on top of being very expensive (I recall $30k, but I don't have access to that company's financials anymore).

Its certainly true that a module can save you a lot of money for small volumes. Its actually pretty easy to figure out where the tipping point is: Its the difference in certification costs divided by the difference in BOM costs. Its a little bit more complicated when you factor in economies of scale, but by and large, module costs don't fall off as steeply as individual components do.

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.

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

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

Why is placing a single component with massive pads next to the two relevant MCU pins "too much?"

I expect to do this exact same exercise with absolutely every single semi-complex IC (MCU or not) I use - it's a routine activity.

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.

> 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.

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.

> 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...

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.

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.

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.

Ambiq Apollo4s run at <1mA from RAM.

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

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.

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.

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.

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.

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.

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

How is ESP-IDF "suffering for it"?

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.

> 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?

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.

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.

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

I don't disagree, but it leads to the question from the security guy: how do you fix CVEs in the bootloader after it's shipped (aka in the field)?

If you anticipate the need to update the bootloader, you would use a multistage bootloader approach where the first is never altered (as the bootloader should never be altered) and its main function is to select which updatable second stage bootloader to load from multiple options (multiple so that even if one is interrupted mid-update by the application, there is a valid fallback).

My gut says if you're worried about this in the bootloader, it might be doing too much.

Particularly neat approach to both reducing the attack surface of the bootloader and improving the reliability of the actual OTA update process is to have only the bootloader flash the active application/second-stage flash partition. The idea is that the normal application code somehow acquires the new version, verifies it and writes it into separate flash partition and then reboots, bootloader sees that record and, does minimal check for correctness and flashes that to right location. That way the bootloader does not have to know anything about how to get the new firmware image and does not process any untrusted input.

You don't.

When I actually have these conversations with security guys, it's because they've either missed their window on contributing to part selection (in one case because that team hadn't been hired yet!) or no one consulted them in the first place. In both cases the solution is to write some guidelines and get the EEs to use them during part selection in the future.

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.

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

Or you can just write/add a second-stage bootloader after the ROM bootloader and get the best of both worlds?

By the way - real commercial MCUs have boot ROMs with connected watchdogs, trial boots, and recovery boot processes.

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.

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.

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.)

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.

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/

I can use things like dfu-util or esptool for quick iterative loops without any additional hardware. Hence my point - mass storage is a downgrade over what other µCs on the market were already doing with their ROM bootloaders before RP2040.

Just to note: with the RP2040 you don't need additional hardware (debug probe) for quick iterative development, you can use picotool[1] (using -f allows you to flash and reboot without needing to get it to bootsel mode).

[1] https://github.com/raspberrypi/picotool

...and it doesn't use mass storage at all, blocking access to it in a clunky way to prevent simultaneous usage.

UMS seems like a nice idea when you first hear about it, but it doesn't really offer much once you look at it closer. The only proper argument for it is "no special software needed", but it a world where picotool is `apt install picotool` away that's not very advantageous anyway and only causes automount annoyances.

UMS shines where you have a device with a filesystem in its flash that you can access to actually manage the files stored there. Super useful for stuff like MicroPython. In contrast, pseudo-mass storage like on RP2040 doesn't seem very useful at all. It makes it appear more approachable, but only superficially.

The whole UF2 idea has to do with the educational background of RaspberryPi. The protocol was invented by Microsoft for use in some kind of similar educational board with the express purpose of not needing drivers, being reasonably crossplatform and crucially not needing any special permissions to access the device. The end result is that in some kind of educational setting you can use some kind of cloud/remote IDE on iPad, stick the RPi-Pico into the iPad and flash it, no blessing from Apple needed.

Oh. So it's just a result of locked-down walled gardens being so widespread that they influence the world around them. Depressing, but thank you for pointing it out anyway; on my phone I can just run picotool itself and it's easy to forget how dystopian it all got outside of the niche I'm in.

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.

> 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.

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.

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.

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.

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.

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.

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

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

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.

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

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.

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 ).

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

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

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?

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

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

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.

BGAs generally call for more complicated reflow profiles (including vapor phase reflow for very large BGAs - think 40mm+ FPGAs) and require X-ray inspection (if doing inspection at all.) BGA balls can have under-body solder voids, etc. BGA devices also generally specify a specific solder to use (leaded or lead-free won't be interchangeable.)

Generally, all single-row package pin layouts are easier than double-row (BGA, WLCSP, 2-row QFN) to reflow.

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)

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.

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

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).

i wonder if you could use the vias trick for the regular pins too, and bga balls

I have in fact seen the via trick used for 50mil pitch BGAs, but cannot remember where. I even vaguely recollect some board where that was used for CGA, which seems like really ridiculous idea (you don't use CGA packages and then invent some weird kludge pseudo-process).

wow, i'd never even heard of cgas

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.

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.

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.

> 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.

> 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.

> Decoupling capacitors need to be placed "close" to the chip

All of these rules are just rules of thumb.

The "rule" is that your Power Delivery Network (PDN) needs to have low-enough impedance to function properly. High parallel capacitance and low series inductance/resistance. Longer leads increases inductance and resistance so closer is preferred.

But for even 100MHz designs, you're well under the size where 100mil or 0805 would cause any serious problem.

-------------

So the "secret" is that all faster designs (100MHz to 300MHz) have substantial on-package capacitance.

Take a look at this design, which I admit is Microchip/Atmel MCU, but its running at 300MHz and not just the relatively low 133MHz of the RP2040.

https://lcamtuf.coredump.cx/bob-the-cat/

Those are LARGE 1206 1uF capacitors. Which is actually scary to me because we're not looking at tight 100nF decoupling caps anymore but instead substantially relying upon "on-package" capacitance.

Still, it shows that lcamtuf was confident in this 300MHz processor handling far-away 1206 capacitors, showing how much wiggle room we have in practice in these designs.

You shouldn't worry about 100mil of movement of 0805 caps on a 133MHz design. After all, there are real designs that are closer to 500 mil that use 1206 caps on a 300MHz MCU.

--------

I'm honestly scared for lcamtuf here and would never design a board like this. But I'm really not worried about 0805 caps on relatively low speed 100MHz (or even 133MHz) MCUs. Especially if you're properly "teaming" them up so that their resistances are paralleled and inductances are paralleled. (Notice that lcamtuf's 300MHz design doesn't even have the 10x recommended parallel 100nF capacitors close to any of the pins!! He's really stretching the specs)

-----------

But yeah, my personal preference is majority of 0805s and 0603s for the "close" decoupling capacitors. I know there's plenty of wiggle room here (even if I'm not as aggressive as lcamtuf's designs).

If you're using PCBA from another shop, I guess its all "free" to you to use 0402s or whatever they got loaded in their chip-shooters. So might as well take your free pre-loaded resistors. But if I'm assembling a board myself, I definitely prefer the larger size.

Fair enough. I've taken digital logic classes etc. in college but when it comes to practical circuit design I'm mostly self-taught, having worked my way up from all through-hole components with ATmega and similar devices to dipping my toe in the SMD waters with larger TQFP parts to now doing a few designs with the RP2040. I've tried to educate myself on best practices and follow recommended layouts and things like that where possible, to try to learn to do things the "right way" - but I definitely don't have enough experience to know when the rules of thumb can be broken or not.

It's good to know that the "closeness" requirement of decoupling caps is perhaps not as important as I had believed.

The professionals use PCB-design software with physical modeling / FEA to calculate estimates to all of the important parameters of the circuit board (including how much trace lengths matter... but also board-capacitance, resistances, and resonance frequencies of the board itself, etc. etc.)

In contrast, we hobbyists deal with "rules of thumb", because none of us will spend $4000+ on professional PCB software that run these calculations for us. And furthermore, we aim very conservative because its very difficult to debug a PCB layout issue... as we hobbyists are functionally blind to all of these issues (ex: trace inductance, trace capacitance, or other issues).

I think spending a good bit of time on PDN / grounding / etc. etc. study is very worth your while.

https://www.youtube.com/watch?v=ySuUZEjARPY

2+ hour talk on just the issue of good "grounding" design in PCBs, but it does relate to this issue of capacitors, trace-lengths and the like. I feel like you'd benefit from this talk.

The "correct" way of thinking is exceptionally complex, far more complex than what is taught in colleges. But you have all the basic ideas thanks to the old rules of thumb. You just need to take the next step to see what the problems are.

--------

And as you'll see, traces on the same side of a board are cake. Its things like vias that actually wreck you.

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/

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.

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.

Hmmm, maybe my designs have been small enough that it hasn't been an issue.

I'll keep your experience in mind then. Thanks for sharing your experience.

Who knows, it may be fixed by now.

JLC's polished stencils will happily work at 0.2mm pitch for ~$10.

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.

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

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.

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.

> 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).

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

> 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.

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.

> 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.

That's really disappointing :/

seeking patents to then open source it?

Right?... Right?!?

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).

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

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

https://github.com/lawrie/fpga_pio

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

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.

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

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

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.

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.

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.

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

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

QSPI NOR flash pins are labeled basically the same on every single MCU, routed using the same guidelines, etc.

DFN-8 ICs take up 2x3mm and take 30 seconds to route.

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.

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 :)

Try the PY32 series MCUs for better bang-for-your-buck: https://www.lcsc.com/products/Microcontroller-Units-MCUs-MPU...

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.

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).

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.

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.

I forgot another win for the STM32: no crystal.

Why are the STM32 ring oscillators any different than the one in the RP2040? (If you mean crystal-free USB FS - yeah, that's a nice little feature, but this is the only difference that I am aware of.)

How much time does it take to place a DFN-8 flash chip and 6 routes in reality?

The RP2040 is absolutely usable from simple registers and documentation, not sure where you got this idea.

The reason you want multiple megabytes of space in a professional product: identically-sized bootloader partitions for trial boots.

It takes more time than doing nothing, so it's a waste of time unless I require it.

Obviously it's usable that way, I said it wasn't as simple (the hardware is more complex to initialize).

Using "megabytes of space" for "trial boots" sounds like a rube goldberg machine that would cause more problems than it would ever solve on a chip you can't OTA, but feel free to argue with me :)

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

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.

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.

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.

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

> Raspberry Pi pulled a Henry Ford and boldly went with just one microcontroller... In return, Raspberry Pi ensured that everyone on the planet works with the same part. Compared to more traditional wide lineups, there is a disproportionate number of StackExchange questions, blog posts (including this one), experience, Github issues, libraries, and tools for the RP2040.

I'm not personally convinced. Most of the ESP32 series is cross-compatible (at least for the shared pinout counts).

I'd argue the brand recognition and marketing to hobbyists is more likely what brought the "community" around the RP2040.

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

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

The RP20240 is not only available for embedded development in C, C++, Rust but also interpreted languages like Python and JavaScript. Super versatile.

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.

The real competition are Chinese WCH MCUs and STM32 clones (PY32 series.)

Add $1.00 and you're into Cortex M7s with vastly more peripherals/power (NXP IMXRT1011.)

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.

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.

> 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.

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.

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

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...

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.

https://www.lcsc.com/product-detail/Analog-To-Digital-Conver...

Commercial 16-bit/4ch ADCs can be obtained for <$0.90 in modest quantities.

The RP2040 ADC is not good, and I am not often sampling something close to my noisy MCU. I'd rather route I2C anywhere than worry about signal integrity routing my analog signal a mile across the board.

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

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.

Ok, but does it fulfill military or automotive standards?

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

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.

There are several automotive standards for electronic components. GP was probably asking about e.g. AEC-Q100, AEC-Q101, and/or AEC-Q200. These establish that the device is going to work in automotive environments (temperature, humidity, vibration & shock) by verifying functionality while subjecting them to those conditions. A component may work without these tests, but you are merely hoping that that is the case if they haven't been tested. Hope is not a viable strategy for product design.

The AEC standards aren't enforced by anything and are mostly just promises that chip manufacturers make (the AEC itself is a private entity). Specifically, that any given chip will still be available in 15 years and that it'll operate fine within certain temperature ranges.

If some part claims to be AEC compliant it's basically just the manufacturer saying so. There's no independent body or even standardized tests to prove a part adheres to any given AEC document. Their own docs state as much:

    AEC Certification
    
    Note that there are no "certifications" for AEC-Q100 qualification and there
    is no certification board run by AEC to qualify parts. Each supplier
    performs their qualification to AEC standards, considers customer
    requirements and submits the data to the user to verify compliance to Q100

In other words, it would be up to any given car manufacturer to verify the claims of any chip vendor using their own testing methods. Since they're going to have to do that anyway, slapping AEC-(whatever) on a product doesn't mean much.

If you test your part in similar conditions and make some availability promises you too can slap an AEC-Q100 label on to your chip!

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.

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.

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?

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/

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

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.

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.

Maybe with the Arduino CLI?

> 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...

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.

data sheet: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...

I currently design a product that needs to be battery powered and its just not possible in the same way on the 2040 as esp32 with the ULP and the deep sleep current.

I also happen to be working on an ultra-low power project with an ESP32.

It is hard to beat that 5uA deep-sleep current!

Try <1µA/MHz active current consumption on the Ambiq Apollo4 chips.

Thanks for that, looks interesting. One note, their website [1] claims 5uA/MHz, not 1

[1] https://ambiq.com/apollo4/

Yes, that's correct. I had confused it with the total consumption at rated speed - ~1mA and mixed up my figures.

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.

Zero of these MCUs have anything resembling the quality of CoreSight/CMSIS-DAP/Keil/etc.

Of course not, those are proprietary technologies specific to ARM.

If anything, they implement RISC-V debug and trace specs, or earlier vendor-specific, as these specs are relatively new.

Which is why I stated "resembling." TIL about the RV debug/trace specs, this has been one of my major complaints. The vendor-specific stuff is plainly terrible.

I don't see anything like SWD being consistently defined by this spec, though?

I advice to join the RISC-V Foundation, participate, and get what you want.

Give me a USB high-speed PHY.

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

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

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

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

You don’t understand. If there is no DFU the next application cannot be fixed if it broken. Hence bricked. If the boot rom goes right to the sd card image then there is no problem.

Almost all embedded devices have a secondary boot loader.

Do you understand my question now?

Sorry, misread your question.

Yes, it has a DFU on the boot ROM.

Ahh... thank you.

Not "DFU" as in an implementation of the USB DFU 1.1 class, but a hardware boot ROM with spiritually the same mechanisms exists.

I absolutely love the RP2040, and the PIO is extremely useful.

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

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.

...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.

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

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.

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.

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.

> 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.

PIO-like speeds (50MHz+ - easy) are unobtainable across parallel GPIOs in any MCU without a similar core (NXP FlexIO, TI PRU) or an FPGA.

PIO has its use cases.

Inb4 esp32

It's mentioned in the article.

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.

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.

> keep it isolated to this comment

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

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 :)

The RP2040 is not what the RPi 5 uses.

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

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

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

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.

If you're paying $13 for a Pico, you're getting fleeced.

These are $4 or less at most vendors, and JLC will assemble 5 for you for <$3/ea.

Reply on news.ycombinator.com