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.
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.
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 :)
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.
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.
Right?... Right?!?
DFN-8 ICs take up 2x3mm and take 30 seconds to route.