I can see this as a great platform for prototyping though.
I've got a 1.4inch screen waveshare rp2350 sitting beside me at the moment. I'm currently fighting getting paletted display update via DMA with limited success. As I work through it it does become apparent to me that you could generate a tiled+sprites mode a scanline at a time on demand with PIO and DMA. I'm not convinced it could be run with zero CPU involvement, but it could certainly be done with very little CPU.
It's absolutely doable. There's the beginning of a tile demo (a scrolling brick wall) in the pico-dvi-rs repo.
Here's the gist of it, I haven't implemented it so there will be devils in the details but I think it's doable.
One DMA (1) outputting the current line(unless pixel format change is done at this stage as well)
A bunch of chained DMA to assemble the next line almost like a display list. Sprites/tiles are entries in the display list.
The list entries contain the DMA/PIO setups to manage source, destination, pixel format etc. A DMA(2) transfers a list entry to another DMA(3) to write the required fields a list entry is essentially a series of [destination]<-constant or [destination]<-FIFO. DMA(3) just gets the job of being told by DMA(2) where to put everything. That is sufficient (I think) to set up the other DMA channels arbitrarily from the list data.
Pixel format conversion is done by a PIO writing some number of bits out as a value that gets DMA'd to the low byte of a DMA source register and then triggering a DMA transfer with a length of 1 to read the palette entry and copy the color information into another PIO FIFO. I'm not sure on the best way to do sprite transparency, There's definitely ways to suppress writing on source==0. Would need investigating, worst case scenario would be conditionally triggering one of DMA [destination++]<-color or DMA [destination++]<-[destination]
Once the display list is set up for a mode it wouldn't be touched. All of the dynamic parameters would come from the locations read by list entries. Tile maps, tile images, sprite locations, sprite data etc would not be in the master list, just the locations of where to find those.
Then all that remains is to make a toast to the memory of Jay Miner.
With the vendor SDK driver, yes. The controller can operate in Host mode if you BYO driver.
uses ES8311 'Low Power Mono Audio CODEC' http://www.everest-semi.com/pdf/ES8311%20PB.pdf, Mono DAC with differential output. I dont even understand why someone would do that, yes its a $.3 part but real stereo codec from TI (TLV320AIC320x) is just $.6
Edit: looking at BOM it might be caused by Made in China 2025 and trying to get as close to 100% domestic part list for some subsidies.
The pico-dvi-rs project has an early prototype of race-the-beam video generation, which I think has a lot of potential, it's going to allow much richer content than a framebuffer on this kind of device. One fun thing we've got going is proportionally spaced bitmap fonts, which is fairly unusual in this form factor. Please get in touch with me if you're interested in driving this thing with Rust.
I can't help but feel that you could make almost the same board with 2 or 4 RP2350's without a significant percentage increase in cost.
Couldn't you wire most of the GPIOs together, they start off at high impedance, then let them work out who does what with plenty of options for weird processor sharing arrangements.
I guess if it's open source, I could take a look at doing one myself. What's the worst that could happen :-)
This is a ton of software to build.
Fast Linux-capable SOCs are only $5 with 100x+ the specs.
There are heaps of boring off the shelf options.
I'm working on a project where we might just hand these to customers for a certain function and consider them disposable when the work is done.
nfriedly•7h ago
oytis•6h ago