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?
[deleted]
I like the RP2040
111–120 of 413 posts
Re: I like the RP2040
#112Earlier quoted context omitted.
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…
I'd agree with most of those points, but in my decades of experience here...YAGNI.
Re: I like the RP2040
#113The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.
Where can I learn more about how they are used in console hacking? This sounds very interesting
Here you go. There might be more but these are all I can think of off the top of my head.
Nintendo Switch modchip - PicoFly: https://github.com/rehius/usk. That is the OG source of the firmware behind the already mentioned https://github.com/Ansem-SoD/Picofly
OG XBox Modchip - Modxo: https://github.com/shalxmva/modxo (see initial impressions from ModzvilleUSA at https://www.youtube.com/watch?v=uUsov3i6jL0)
XBox360 NAND reader / writer - Picoflasher: https://github.com/X360Tools/PicoFlasher (used in the RGH3 hack for some versions of the console as described at https://consolemods.org/wiki/Xbox_360:RGH/RGH3)
Gamecube Modchip - Picoboot: https://github.com/webhdx/PicoBoot
Gamecube Optical Drive Emulator - Flippydrive: https://github.com/OffBroadway/flippydrive as described at https://teamoffbroadway.com/
Re: I like the RP2040
#114Earlier quoted context omitted.
It's safe to assume he's talking about the chip in both cases. You can connect either of them to a battery charger, camera, or nuclear reactor but all of those 'peripherals' are completely irrelevant to this comparison.
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?
GP is clearly talking about ESP32 boards, not the chip; they mentioned "LI Battery Controller", and "Display or Camera Connector". People sell RP2040 boards with those too, for example:
- board with a battery charger: https://learn.adafruit.com/adafruit-feather-rp2040-pico/powe...
- board with camera: https://www.waveshare.com/pico-cam-a.htm
Re: I like the RP2040
#115The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.
Things like battery life will probably improve with experience, I was talking to a silicon guy about the RP2040 and they said it's pretty characteristic of a first generation design. The digital logic that can be validated on an FPGA is fine for the most part, but the analog elements are much more difficult to fine tune, hence the poor power consumption, poor ADCs, and lack of internal DACs or opamps in the RP2040, a…
Analog is large area and expensive in general so sticking to good digital and passable analog is a very good strategy to keep costs down.
Re: I like the RP2040
#116How 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?
Just in case you were unaware, the RP2040 is available on dozens of ready-made, arduino-compatible boards like the Pi Pico, the Adafruit feather boards, of the Seeed XIAO RP2040 boards. Those have all (or at least most) of the IO already mapped to pins, USB headers, booatloaders, reset buttons, etc already mapped.
Things like the Pico are really easy to solder onto a designed PCB as well because of the castellations, so it's easy enough to design a board around the footprint and then just solder the entire pico onto your PCB with a soldering iron, avoiding the need to use something like a hot-plate or reflow oven. This has been my preferred way of working with it.
Re: I like the RP2040
#117Earlier quoted context omitted.
Definitely not. My understanding is they got significant market share on lunch - since it was during the pandemic chip shortage and they were the only ones with sub year lead times.
Ok, but does it fulfill military or automotive standards?
I don't know about military standards but there's only ONE automotive standard and it's ISO 26262:
https://en.wikipedia.org/wiki/ISO_26262
There's nothing in ISO 26262 that would prevent someone from using an RP2040 in a car. You'd just have to be redundant about everything which you have to do anyway regardless of the chip you choose.
Also, ISO 26262 is not a law. It's up to the auto manufacturer whether or not they'd require it and no single chip on its own can claim to be "certified" (or similar) for ISO 26262 since the focus is on redundancy and error checking (which means one chip would check the status of the other and vice versa, not some special internal consistency checking feature... That's just marketing).
Most "automotive" versions of chips (e.g. Atmel's stuff) are just branded that way. Atmel will make a claim like, "this chip has been tested to function properly under these sort of extreme conditions..." (that happen to match what car manufacturers are looking for) and then a car company would just trust that and make it so that only chips that are marked "automotive" and manufactured by Atmel will be allowed to be used by their electrical engineers (or suppliers).
It's all entirely arbitrary though: If you can convince the manufacturer that your board works fine under the conditions they require they'll probably buy it. Well, they won't hold it against you that you used one chip or the other. They just want some assurances.
Re: I like the RP2040
#118Earlier quoted context omitted.
Can you go into more details? Most of the criticism I've read tends to be more abstract ("I don't like how ALL my blocking-style calls need to be async"), and doesn't propose an alternative mechanism to async that can provide a similar coding style in the same tight RAM footprint.
I think you'll find details regarding any discussion of async in rust and other languages - I don't mean to casually dismiss your question, but my objections are not unique. The alternative mechanism is to use interrupts, DMA, multiple cores, distributed devices (eg a CAN network) a state machine, an RTOS, or, it sounds like in context of this thread, PIOs! You get the point. Do these provide a similar coding style?…
As I see it, if you need everything to run on a single cpu core, the alternatives are to either implement threads (wasting memory on redundant stacks) or to write the event-driven state machines manually. Whether the state machine is pumped by interrupts or not doesn't change anything IMHO.
Because of RAM constraints, all the bare-metal projects I've worked on have used manually-written state machines, and I'm comfortable enough with this approach. But sometimes these state machines can be hard to understand when the control flow is complicated, and I am seriously considering adding some compiler-generated state machines that will fit nicely into my existing model.
Re: I like the RP2040
#119[deleted]
Re: I like the RP2040
#120I also like the RP2040, but I'd like to explain why I migrated away from it for my current project.
First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling.
Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful placement of about a dozen components, including a crystal. Not only does a module reduce implementation complexity dramatically, standardization skips every engineer potentially making their own dumb component placement mistakes.
Third, the ESP32-S3 has 14 GPIO pins that can be configured to do capacitive touch, while the RP2040 has none. Most of the projects that use RP2040 and capacitive touch rely on the MPR121, an IC that past its EOL and will likely cause a lot of hasty redesigns over the next few months.
It's also worth saying that eventually RP2040 will likely release more or less powerful versions, and hopefully versions in a module format. I doubt they will ever let it become an STM or PIC situation, but the ESP32 product lineup doesn't look so crazy once you are acclimatized to it.