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

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.

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

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.

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.

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?

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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.

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

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.

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

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

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!

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.

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

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

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.

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

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.

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

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.

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.

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

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

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.

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.

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.

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?

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.

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

https://imgur.com/a/yxjG8vh

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.

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

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.

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

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

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

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

Platformio I suspect.

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.

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

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

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?

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.

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

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.

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!

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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?

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.

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.

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.

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.

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

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.

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

-----

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.

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.

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 love the generic PIO though, I really hope other manufacturers pick up on that.

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.

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.

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.

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 care more about the cost to manufacture boards with the part, than the cost to get sample parts mailed to me in the US :)

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

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.

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

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/

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.