Raspberry Pi Pico - What a Weird MCU!

My thought's on Raspberry Pi's new Pico board, based around their RP2040 Dual Core ARM Cortex-M0+ MCU.

Links
-------------------------

Social
-------------------------

[SLLabsKamilion]

4:25 The dormant and sleep numbers you spoke are *picoamps* not microamps. Nought point one eight, and Nought point three nine micro amperes. one hundred and eighty pico amperes and three hundred and ninety pico amperes. With a maximum typical average current of 10.9mA running popcorn at stable room temperature. Yeah, it's confusing, especially when you show the other datasheet and it shows the column of units for STANDBY in picoamps. The RP2040's is annoyingly consistently micro amperes across all columns, so the nought point threw you off, it appears.

Also, do note that the Pico board has it's own buck boost SMPS supply with an extremely "low" input of 1.8V to a reasonable 5.5V high out to the RP2040's 3.3V rail. This thing can probably steal current from a coin cell clock backup or LIF2430 rechargable, or even a 2.5V supercap bank, and end up practically everywhere as the go-to lidswitch/chassis intrusion peripheral. Or lithium titanate oxide cells, a lower voltage, but safer chemistry... now PCB mountable in 50/900/1300mA capacity and a two lead electrolytic capacitor footprint. Heck, this could even end up to be the power rail management chip for the Pi5... *chuckles*

Err, actually, I just put a bit of thought into it -- wouldn't this end up to be a pretty open hardware root of trust implementation? Due to the lack of on-die flash, and all.. This thing in theory would be able to share a host platform's SPI NOR flash chip. Like that 'EEPROM' they whacked on the bottom of the pi4 to netboot/USB boot. Wouldn't surprise me to see something like a die-unique ID being used as a per-platform key derivation material used to present some form of security manifest to a host platform on demand. More or less an open TPM chip... Huh. Now that makes me curious how hard LPC would be to get working on the PIO peripherals.

The other thing that just occurred to me; none of the work to support this "day one" publicly was done in a vacuum. It's clear they've been sampling this out to certain developers for something like about six months or longer to have this much production code ready for the launch. Just about the only thing missing is hearing about an official arduino runtime port. So it's quite possible they've been using this microcontroller design internally for production testing the system-on-board line. That's about the only thing I can think of that would explain the choice of the USB1.1 controller -- unless licensing fees prevented them from a USB2.0 PHY, but that just doesn't smell right considering the SoCs have 2.0 and 3.0 PHYs... Then again, those items are under broadcom's umbrella, not the foundation's... So it's hard to say. The other thing distinctly missing is camera or display interfaces using differential signalling internally. So the only differential signalling on the whole device appears to be the USB 1.1 controller... But one thing I can say for sure -- using Cypress in a design is extremely costly; while it's free for hobbyists registering PSoC creator, using any of their IP blocks commercially ends up with some pretty insane license fees. The FX2's USB IP block license starts at USD$11K, for example. That's one of the biggest things keeping cypress from being seen in hobby-grade projects, short of china's saleae logic clones in sigrok/pulseview. Companies in china just sort of laugh in Cypress's face with the usual "Find us if you can, we've moved addresses and changed company names three times in five years on taobao" shenanigans. Having a flexible, open chip like the RP2040 is going to make a lot of projects that were annoying and expensive, less expensive and easier to pull off.

Personally, I'm going to be using the two PIO blocks to interface with IDE/PATA, more specifically to a JMicron JMS20330 3.3v/5v PATA to SATA bridge. Low resolution SPI display and a pair of rotary encoders. Should be able to send the ATA Secure Erase command sequence and wait for it to return to ready, or if the drive refuses, just start writing zeros to sequential LBAs until the drive balks.

Current devices on the market that do this are around seventy to two hundred US dollars, frequently being based on a FPGA so they can use the SERDES for SATA differential serial packets directly.
Pico could do it for $8-20. I'm sure someone will come along, see my code, toss out the disk wiping sequence and invert it into a 16 bit PATA emulator target. Or 8-bit ACSI for the good ol' Atari ST.
Someone else will most assuredly turn this thing into a floppy disk emulator as well, cheaper than a flashfloppy reflashed gotek with oled mod goes for on ebay.

[JernD]

Onboard USB 1.1 is a huge improvement over the usb to serial chips on traditional arduinos. Not sure what application will require more than 11 mbps that you have in mind for a tiny microcontroller? I think a $4 micro with built in usb host and usb device capability is very useful for e.g. HID peripherals.

[markburton]

I think the PIO stuff is really interesting

[wolfgangneudert]

I really can‘t see the benefit of a Pi Pico ... there is already an ESP32-S3 out there with much more features.... at a compareable price