Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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


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


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


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.


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


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


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


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


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.


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


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.


seeking patents to then open source it?

Right?... Right?!?


That's really disappointing :/


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.


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: