121–130 of 413 posts
How are people using this in practice? 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?
Although it looks like BGA, it actually uses a QFN package where all the contacts are accessible at the edge. With a little practice they are relatively easy to hand solder (I've done many, not just rp2040)
If you are an electronics hobbyist but don't want to make/design your own surface mount boards (like me) there are lots of very accessible RP2040 boards at very low prices. 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. Thes…
The Pico is really good at pin interoperability at least, in the land of ESP, what appears to be lots of IO pins quickly turns into barely enough if you're lucky, with pins connected internally to flash or the bootloader or whatever. I really wonder why they even bother breaking those out. The ESP32-CAM comes with 10 data pins, and only 4 of them are actually generally usable lol.
How are people using this in practice? 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?
It's not a BGA, it's a QFN with a ground pad.
Earlier quoted context omitted.
I was on the fence about using it for a small commercial project I'm doing, but the lifetime has been put out long enough (2041 at this point), and it's so freaking cheap that I'm going to do a one-time buy of 10 years worth of parts. Lack of code security and onboard flash weren't dealbreakers for me here, but others will have more stringent requirements. QSPI is so incredibly cheap now.
Ok. One thing I'm worried about is that the tooling is made for hobbyists only. Is there a way to do everything from the commandline with FOSS tools and without installing e.g. the Arduino-IDE?
Earlier quoted context omitted.
So is GP. 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?
No, that's both "just the chip", the chips have different peripherals. They both have the usual SPI, I2C, UART, ADC, etc., and they have their differences too. 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 developm…
1: https://www.espressif.com/sites/default/files/documentation/...
Many of those listed are the same controllers in various modules. Espressif has a bunch of different µC series, but not that many. In contrast, aside of the whole Pico dev board, Raspberry Pi does not offer any ready-made module with RP2040.
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.
Earlier quoted context omitted.
Hence they made the Pico Debug Probe [0]. It makes it super easy to reflash firmware to the Pico in a quick iterative loop. 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/product…
I can use things like dfu-util or esptool for quick iterative loops without any additional hardware. Hence my point - mass storage is a downgrade over what other µCs on the market were already doing with their ROM bootloaders before RP2040.