18 comments

[ 4.4 ms ] story [ 54.4 ms ] thread
OT but a question I'm curious about: what features would people who have a lot of experience with the RP2040 like to see on a successor?
Another pair of PIO blocks (and two more DMA channels) is my desire. I think a lot of people would love to see a (slightly more expensive) variant with more uncommitted GPIOs.

My pet projects with the Pico and clones involve interfacing with an 8-bit processor, and the RP2040 just doesn’t expose enough pins for the full data, address, and control busses AND actually doing something interesting with the outside world.

Another dedicated USB PHY peripheral would also be great, a lot of people lose a PIO block to adding a second USB port. Obviously this also shows the power of PIO, but it’s nice to be able to reserve those blocks for more obscure physical things.

I bet a lot of people would like more analog pins, the Teensy provides a lot more, for example.

I haven't done a lot per se, but 480Mb USB would be nice.
(comment deleted)
USBHS is fairly hard to support without an off-chip transceiver. There's a reason why most low-cost microcontrollers are USBFS only.
Memory mappable PSRAM support would be nice.

Or more pins and more PIO as well.

I guess more SRAM wouldn't hurt either.

More than 32 instructions per PIO block: my main current project (PicoGUS) uses 32 instructions on one PIO block and 31 on the other to handle ISA IO, ISA DMA, I2S audio out, and SPI PSRAM access. Having more would let me cut a few less corners in how ISA is handled.

More/more flexible PIO instructions: branching is very limited, you can only arbitrarily SET up to 5 pins or pindirs at once (increasing to 8 would be a godsend), stalling with a sideset repeatedly executes the sideset, etc... I could go on.

Memory mapped PSRAM: I made a library to assist with accessing SPI PSRAM but it's still just functions to get/set groups of bytes. An intelligent cache around it would also mitigate the much higher latency of accessing PSRAM as well.

More SRAM: everyone can always use more RAM!

More GPIOs: everyone can always use more GPIOs!

Better power consumption, especially in deep sleep. Make waking up cheap too, especially for some IOT purposes, like grabbing a sensor reading every couple minutes and storing it in a queue for future burst transmission. Optimize for that sorta thing. Measure in nanoamps.
One more core, one more PIO, and more SRAM.
A DAC, at least 12 bits
This reminds me of the Uzebox [1], a video game console based on an ATMega644, but the RP2040 in this looks far more powerful at a glance. How far could this realistically be pushed?

[1] https://uzebox.org/

At least this far. https://www.youtube.com/watch?v=eDVazQVycP4

RP2040 running Doom, includes VGA, Adlib emulation, PCM sound effects, 4 player "LAN". Pretty much the same experience as Doom on a DOS PC.

264 kB of total RAM is the main restriction.

I have the Adafruit DVI board and have been hacking on it some. It's more fun than should be allowed.

There's a project to get this running using Rust[1]. Currently it outputs the blue channel with sync, but has trouble with the other two channels. I don't have a hardware lab with scope, logic analyzer, etc., so it's not easy for me to debug.

In the meantime, I've been doing some experiments in the C codebase as well[2], mostly in the direction of proportionally spaced bitmap text, using the fonts in the X11 distribution.

[1]: https://github.com/DusterTheFirst/pico-dvi-rs

[2]: https://github.com/Wren6991/PicoDVI/pull/48

Be nice if the board had wireless built in, though I believe adafruit provides a clip on wireless module.