Hacker News new | ask | show | jobs
by dragontamer 970 days ago
Pico has its own problems:

1. VQFN package is a pain to deal with. You can't use a soldering iron, so its reflow-only and therefore requires hotplate + reflow hot air to deal with. Due to the difficulty of rework, you likely can't use the soldering iron+solder wick technique to fix solder bridges, for example... and therefore also require a soldering stencil to work with (gotta deposit the correct amount of solder-paste and hope everything works out good). Inspection requires X-Rays as well because everything is "under" the package, so you can't even visually inspect your joints.

I definitely prefer TQFP (seems to be the package with the biggest inventory in practice), and enjoy even the larger SSOP or even SOIC packages available from some competitors. All competitors offer VQFN as an option as well, in case you are truly size-constrained. But in my experience, a 9mmx9mm TQFP-32 is perfectly fine (7x7mm raw, but the leads take up another 1mm for total of 2mm added on the two sides). Your 32-traces are going to take up like half an inch of routing space anyway, so its not like the 5mmx5mm VQFN saves much space in practice IMO (IE: You'll need 6-layers or something... and/or to cut out lines to really take advantage of the space-savings from a VQFN)

Note: Hobbyists _should_ be using hotplates to do the bulk of their surface-mount soldering jobs. But accessibility to soldering iron for rework / touching up problems is a huge advantage to TQFP.

2. 0kB of on-board flash. RP2040 requires external components to boot, complicating the flashing / loading / bootup process.

3. Poor sleep specs, for a microcontroller. Your typical AVR DD (modern ATMega), or STM32G0, or Ti MSP430 / MSPM0 are all in the dozens or low-hundreds of microamps sleep (with some competitors in the ~hundreds of nanoamps for deepest sleep states). RP2040 sleeps at ~0.5mA to 1mA, an order of magnitude more power.

4. Poor power specs, for a microcontroller. Your typical AVR DD, SAMD, STM32G0, Ti MSP430 / MSPM0 are maybe single-digit mA (under 10mA across the board). RP2040 is like 20mA. I kid you not: an 8-bitter like AVR DD can be going full-tilt at like 4MHz or 8MHz and still have less power-usage than RP2040 *at idle*.

5. Lack of peripherals. RP2040 has PIO and SRAM as superpowers... but its got fewer timers, ADCs, DACs, OpAmps, Comparators, than all of its competitors.

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

RP2040's main superpower is its 264kB of SRAM. If you need gobs and gobs of SRAM, RP2040 is probably the right choice.

All other situations? I'm pretty sure you'd prefer a 12-bit differential ADC with 16x gain (ex: AVR64EA48), or 12-bit differential ADC (no PGA) + 3x OpAmps (ex: AVR128DB64) and multiple comparators and 4x onboard Vref, or 2x Zero-drift OpAmps + 1x general-purpose OpAmp (ex: TI's MSPM0 line).

Honestly, I'm not impressed by the Pico for general purpose use. The Pico works as a specialized compute-device (high SRAM, high MHz and dual-core), but this is simply impractical for many applications. You'd really rather have ADCs or Comparators in more typical electrical designs. Combo'd with the high-power usage (probably from all that redundant RAM the RP2040 has), and its difficult to recommend.

--------

Going in the other way: Cortex-M4F cores with a floating-point unit, even at 64MHz, will be much-much-much faster than a 200MHz RP2040. Why?

Because hardware float32 matter.

Why do you have 264kB of SRAM when you don't even have a floating-point unit? The RP2040 can't even be a good DSP-like system with all that compute power because you gotta software-emulate floats.

So if you _actually_ need compute power, you'd probably should be picking an STM32F4 (aka: Cortex-M4F) processor instead. RP2040 sits in this awkward zone where its got gobs of SRAM + MHz but is stuck on Cortex-M0+ (lacking floats, and other key instructions), so it doesn't actually have very fast compute in a very common case that matters...

So yeah, RP2040 works if you're willing to rewrite to integer-fixed point... if you don't need peripherals like ADCs or ACs, if you're willing to spend more power and complexity (due to the lack of on-board Flash), and are willing to use leadless VQFN packages. Its... quite a niche IMO.

5 comments

Just a note on soldering: I’m perfectly capable of soldering VQFN at home, but these days it’s so easy to order fully assembled boards from JLCPCB that I think lost hobbyists would start with the Pico and then go straight to turnkey assembly once they have a custom design. I stopped assembling my own boards two years ago (after a decade) once I placed my first turnkey order at JLCPCB. Ten pieces of a simple RP2040 board including shipping is like $80.

I agree the lack of floating point and the poor ADC are an issue. I designed a high power brushless motor controller using the RP2040 and the FOC loop only runs at 8kHz which is fast enough for my use, but much slower than a higher end board. I just love this processor too much to use something else.

The main advantage to this processor is that it seemingly will never go out of stock (until it’s EOL date). When I started designing the motor controller in early 2022 during the chip shortage, I went to the Digikey “microcontroller” category with no filters and sorted by most in stock. They had millions of RP2040’s - it was the most in stock microcontroller on Digikey. I guess since Raspberry Pi only have a single SKU for their microcontrollers they can just churn them out in huge quantities.

My goal is to stay invested in this product line until an updated rev comes out with a better ADC and floating point. I bet they’re working on it.

Hmm.

You have a point about RP2040 being a thing that JLCPCB's assembly service benefits from. A singular chip that you "plan to use in most projects", along with pre-loaded pick-and-place machines that have common I2C attachments, makes sense in the scheme of factory design. (While something like Microchip's AVR DA vs AVR DB vs AVR DD vs AVR EA loses out, because SKUs are the enemy of such an assembly line as you'd be forced to manually swap-out reels in between production runs).

Still, RP2040 is a compromised part with plenty of downsides that I've listed above. And as far as a "centerpiece jack-of-all-trades" microcontroller goes, I'm not convinced that the RP2040 is the best to keep preloaded in such a configuration yet anyway to be mass produced into many designs.

But your point stands. It is a production / prototyping issue that intrigues me and I wasn't thinking about earlier.

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

> Just a note on soldering: I’m perfectly capable of soldering VQFN at home

Well yes. I did say that Hotplate + Reflow Hot Air Gun works. But *soldering iron* is an advantage IMO.

Personally speaking, I don't see any of the chips I use on a regular basis on JLCPCB's list, so I've never felt the need to experiment with it. I can see how its advantageous if those preloaded pick-and-place machines have the chips / components you use though.

Sure I agree with all that.

I’ve moved to a model of only designing with parts available at JLCPCB (or LCSC, which you can have JLC order internally for you). It requires a change in mindset, but being able to spend $300 on QTY 10 fully assembled complex PCBAs delivered in two weeks is a revelation. No more boxes of components sitting around my lab. No more hours spent doing microscope and tweezer placement. No more orders split across Digikey and Mouser. I order the PCB and everything else from the same place. Hell I got my first CNC machined parts from JLCPCB recently and their quote was 20% cheaper than the other Chinese CNC house I was using.

It’s real nice. I focus on design and testing and not doing assembly.

Actually, they did a huge buy of RP2040 right out of the chute, in order to get decent prices. Heck, in not huge quantities, the chip costs $ 0.70 --- not so bad.

But if you want super cheap, 'standard'-type uC chip, look at the $ 0.10 https://github.com/openwch/ch32v003/tree/main

VQFN is quite possible using a soldering iron (the difficulty is the soldering pad underneath, but that isn't necessary and doable with suitable PCB design) . IMHO QFN is much easier to solder (and rework) than LQFN because bridges between two pads are easier to get away than bridges between the pins of QFP.

Pretty much no MCU in the same price range contains a DAC and most comparable MCUs don't have integrated OpAmps. The external flash has it's disadvantages, but it's also much cheaper to have huge amounts of flash. Typical 1$ MCUs can't include external flash in their address range, so it also can't be added in a similar way.

The RP2040 isn't suitable for a lot of floating point tasks, but floating point tasks on MCUs are not that common. FPGAs are often used as DSP-monsters and floating point isn't very nice on them.

If you need fast processing, with real multitasking, flexible (digital) pheriperals (PIOs can also simulate timers and up to ~22 total timers are nothing to scoff at), some nice fixed point DSP stuff (hardware divider, interpolators), gobs of (external) flash & RAM and great software support the rp2040 is pretty much the way to go as a default micro-controller.

For ~1$ it's a pretty compelling offer which is hard to beat with non-chinese chips.

> Pretty much no MCU in the same price range contains a DAC

https://www.digikey.com/en/products/detail/microchip-technol...

10-bit DAC and Differential ADC at $1.00 right now at Digikey.

> most comparable MCUs don't have integrated OpAmps

STM32, AVR, and MSPM0 all have OpAmp chips in their family. No, not every chip. But this means that your assembly code / c-code and drivers just transfer over to the OpAmp family (Ex: AVR128DB48) when you need OpAmps.

So my code I wrote earlier on the AVR16DD14 $1 earlier just magically upgrades to the OpAmp version inside the family.

Bonus points to MSPM0 for having higher quality chopper/zero drift OpAmps even. (Though negative points for TI chips to be out of stock right now lol)

All of these are rail-to-rail in my experience as well. So.... Yeah... The competition is tough these days.

> If you need fast processing, with real multitasking, flexible (digital) pheriperals (PIOs can also simulate timers and up to ~22 total timers are nothing to scoff at)

Spend $5 more and get a real chip if you're actually processor limited. The Linux Capable SAM9X60 is sitting there at like $8. That's a full bore Linux 6.x kernel.

Anyone at the $1 to $3 market ain't doing this for cost/performance efficiency... but instead overall cost optimization. The 600MHz to Ghz class chips are all available at $10 and are a better choice for processor limitations.

If you're scared of BGA, then I'm still willing to bet that STM32F7 or STM32F4 are better choices with hardware Floats and like 200MHz to 800MHz.

But yeah, 8-bitters and Cortex-M0+ chips aren't here to win performance or compute benchmarks. They're here because a potato-chip is all you need to run an ADC + send data over SPI or I2C and/or react to a UART. For all deeper needs, please for good gracious... please buy a $3 or $5 or $8 chip instead.

---------

I do think the $1 to $3 market is mostly about "Making sure you don't have to buy something else". Like having on-board flash (cutting off another $1 from the BOM / assembly), or whatever.

RP2040 goes a different approach, $1 is very cheap and 264kB is a very large amount of SRAM, but it really doesn't contain anything else worth noting (I guess a single-ended ADC and the PIOs like you mentioned). But all the SRAM/PIO in the world isn't enough to get you to output a 10-bit analog signal through a DAC.

The pico's float support is actually quite good, highly optimized. Sure, not as good as having hardware floating point. https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-... page 24
How do you feel about the esp32's? I know there's a few variants of the 32 with different capabilities, but how do you feel about using that as a general purpose MCU including projects that might not need wifi/bt?

I'm somewhat surprised they didn't go with these as they seem relatively powerful+low deep sleep, with builtin wifi/bt, etc? Their analog input I think is limited though

ESP32 honestly feels like its a WiFi/Bluetooth chip that people are hacking into a kinda-sorta usable uC. Probably because... that's what it actually is...

If you need WiFi/Bluetooth, it seems like ESP32 is a good fit. If not, its kind of awful with regards to integration.

---------

I know that not everyone's doing mixed-signal projects. But ADC, Comparators, OpAmps, Timers are just so damn useful. And STM32, AVR, TI all offer a huge amount of analog-components in practice (with pros/cons to each).

Given how absurdly cheap uCs are today, the minute you say "Oh, lemme just get an I2C ADC to add to the ESP32", and suddenly you realize that the AVR64EA32 chip over there is probably the best "I2C ADC" under $2 (16x PGA, 12-bit Differential 350kSample/sec), and you're suddenly wondering what the ESP32 was supposed to be doing if you're not using WiFi/Bluetooth.

Do hobbyists typically need more ADC than what the ESP32 provides? Granted, it's limited to essentially one 12bit split on 8 channels, but with well calibrated dividers, that probably meets many needs.

I think the ESPs are really the perfect balance of functionality to (low) cost. That and the excellent beginner-level documentation and community.

I haven't tried it yet (or checked the datasheet), but I've heard that the ESP32 has a really crappy ADC. It's nonlinear to the point of only getting 10 of 12 useful bits out.
It is 12bit but the bottom 0-0.1v and 3.2v-3.3v just read as the min-max.

Honestly for many projects needing analog it might be "good enough", but it leaves a lot to be desired, and like the parent said, the moment you're looking for a a i2c adc you end up looking at another MCU anyway.

That's if you need an analog adc which my projects don't (sensors are all i2c anyway) but definitely takes away from being used as a general purpose chip.

It is a shame espressif didn't put a better adc in there.

Some ways to use ADCs...

* The recent AVRs are all differential ADCs, which is highly useful as "voltageA - voltageB" is a common measurement in practice. And its quite different than ChannelA (read a fraction-of-a-second earlier) - ChannelB (read right now), for multiple reasons. (Common-mode noise for one, you'll want to sample at the same time to negate common-mode noise)

* Anti-aliasing filters should be applied for best-practice design against your expected sampling rate... but RC 1st order filters have poor performance. The free-opamps you get from STM32G4 / AVR DB / TI's MSPM0L are easily turned into Sallen-key 2nd order filters, or chained together into 4th order filters or beyond. Or in more practical terms, an RC filter achieves -80db (aka: 10-bits of attenuation of aliased signals) after 4 decades. So a 100Khz sampling rate only has an effective bandwidth of 10 Hz.

Meanwhile, a 2nd order filter gets 80db in 2 decades, so you have a bandwidth of 1Khz.

Yes, despite having a 100Khz sample rate (or beyond) in the digital realm, it only has accuracy and efficacy in a much smaller domain. You have to perform basic analog analysis if you care about any bit of accuracy.

* In the case of STM32 or Ti (which have only single-ended OpAmps), you can build a differential OpAmp to perform VoltageA - VoltageB as a preprocessing step before the ADC.

* I'd say the most common use of differential signals is probably current-measurement across a 0.1 Ohm resistor. If 1-amp is flowing the resistor will have 0.1V across it. Furthermore, there's a common-mode voltage of unknown (ex: the resistor might be 2.3V to 2.4V on the two sides one second... but another time it will be 1.5V to 1.6V), so a single-ended measurement is not ideal. So you need to get rid of the common-voltage while simultaneously taking this difference-measurement.

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

So basically... OpAmps win so hard its not even a fair fight. Free OpAmps on your microcontrollers (STM32G4, AVR DB, and TI MSPM0L) chips just win in all things analog, even in the most basic case of just sampling into an ADC in practice.

Of course, for precision design, you need to build an analog circuit out of precision parts (ie: a dedicated precision OpAmp rather than the general-purpose ones you find for free on a uC). But many basic designs can be solved with the free opAmps from these uCs, as long as you taper your expectations. (In any case, its far better than what ESP32 will accomplish without opamps of its own)

You really end up with "the sum is greater than each of the parts". ADCs are so much more useful when you have an OpAmp or two at your disposal.

----------

Note: many uCs have analog comparators which perform "VoltageA > VoltageB" vs "VoltageA < VoltageB" comparisons... which might be sufficient and simpler than using the ADC. I don't think the ESP32 has any Voltage-comparators though.

So its really the mix: an ADC here, a Voltage Comparator there, a few OpAmps for free, a Zero-crossing detector here... suddenly you can build many designs from these $1 or $2 chips with incredible amounts of accuracy. (Well, incredible for $1 or $2 of course. These parts can't replace more expensive analog chips...)

That makes sense thank you!
Yeah, that sleep current is inexcusable for an MCU. So is the lack of onboard flash. Weird design all around.
The "killer-app" for the RP2040 is some kind of larger display controller IMO.

Displays use tons of power anyway, so 20mA power consumption of RP2040 is fine. And you need 264kB of SRAM for a good frame-buffer, and dual-core means one core can be dedicated for the display and the 2nd core can do all the other functions of your application.

Graphics are likely too large to fit on a typical on-board Flash, so you'll need QSPI (or larger) amounts of Flash anyway, so the weird bootup / requirement of Flash is made redundant.

---------

But general purpose use of RP2040? Uhh... no? Honestly, the RP2040 feels very much like a cut-down microprocessor in its design.

I guess RP2040 has the advantages of Micropython and more than enough SRAM to run larger sets of Micropython code for beginners... which is an advantage for some folk.

---------

I kind of wish that the bottom-tier of microprocessors became more commonplace for hobbyists. Full Linux 6.x kernels and 128MB with a variety of ADCs / Comparators on the SAM9x60 (ARMv5 Microprocessor with on-board DDR2 with ~50mA power usage at downclocked 200MHz)

Why run microPython? Just run Python 3 and G++.

Bonus points: idles at 2.1mA and sleeps at 200uA, so this Linux-capable microprocessor is comparable to the RP2040's idle/sleep specs. (I'm cheating though: DDR2 uses a substantial amount of power and I'm only counting CPU-power. But it still goes to show how absurdly high-power the RP2040 is in practice).

It makes sense, if the Pi Foundation is known for anything it's for giving zero thought to power management and their over-reliance on SD cards for flash memory.