3 ms·
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
by dragontamer 2y ago
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.
- jsheard 2y ago> 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.