Using RP2040 PIO to drive a poorly-designed displa

The last time I worked with DMA was on an Atmel cortex-M7. Definitely a higher end MCU, though. It supported arbitrarily complex DMA chaining via linked lists in RAM. That being said, doing ~10Khz or so IRQs just to kick off a DMA transfer wouldn't have been much CPU in the grand scheme of things.

For the touch input, is it necessary to truly sample at a high rate continuously, or is it more a need to oversample and take an average? If it's a need for oversampling, you could sample the touch screen between frames rather than interleaved between scanlines. Likewise, you could read from the SD card between frames as well. Writing to an SD card would be pretty terrible, given that cards often block for hundreds of milliseconds.

Once again, awesome work with the PIO. I imagine you're running the display at its theoretical update limit unless you try overclocking?

You could use the DMA engine to reconfigure the function routing using a pair of DMA channels.

Just for the fun of it, I've been reading a bit about the STM32H7 since you mentioned it. One half baked idea I have to achieve only one interrupt per scan line would be to use multiple DMA channels to drive the same SPI peripheral, one for the display SS and the other for the touch SS. Have a scanline ISR start both transfers at the same time, and rely on the well defined DMA channel priorities to deconflict them. It seems like this could possibly work given that the high level DMA documentation says it can control SS.

What I don't know at the moment is how exactly the DMA channel actually controls SS. Does the channel itself have knowledge of the signal, or does it just poke the SPI peripheral at the right time? Said another way, are SS pins assigned to DMA channels, or are they assigned to the SPI peripheral? There's also clock frequency and data mode that would need to be associated with the DMA channel. My guess is it's the latter and my idea wouldn't work.

Both options seem like they would have been reasonable from a design perspective. Being able to associate a specific slave device with a DMA channel and letting the hardware arbitrate the bus would certainly be a beneficial feature. The implementation would be more complicated than just letting the SPI peripheral do all the configuration and state management, and simply enabling DMA to shovel bytes in and out of the FIFO seems the simplest. My guess is that it's the absolute simplest implementation, and the SPI peripheral just has a setting to automatically de-assert SS when its TX FIFO and shift register is empty.

Once again practically, though, I don't think it's too crazy to drive this particular display and touch screen with per-scanline interrupts. Assuming 30Hz 240 lines, that's a baseline of 7.2Khz IRQs. If you want 400Hz touch samples, that's only 400Hz more IRQs. Go crazy and sample the touch screen at 2.8Khz as long as there's enough bus bandwidth. While it feels a bit inelegant to not have the scanlines be harmonic with the touch updates, the resulting jitter is at a sufficiently short timescale that it doesn't matter. Also, for this class of hardware, you're devoting a significant chunk of RAM to any sort of framebuffer. Expecting to budget a modest amount of CPU to push the framebuffer to the display seems completely reasonable.

As you mentioned, it seems like the original intent of the designers were for folk to treat the display hardware as a SPI accessible frame buffer. They were probably targeting 8-bit AVRs popularly used in 3D printers? Update rate was probably the last of their requirements. They probably didn't even consider someone trying to drive the display with DMA. The fact that you're able to drive 50fps is quite remarkable, on top of your achievement of fully offloading it on the rp2040.

Marlin barely fits on the Arduino anymore, and that's why recent releases also target ARM and ESP32.

In any case, my point is that the Atmel Arduino architecture is old and limited, and imposes a number of design constraints. There's hardware that's both better and cheaper out there now.

RepRapFirmware was better designed for more powerful CPUs.

Modern CPUs can do microsecond accurate timing just fine. You do need to design the software correctly, however, not just shove something into an RTOS thread.

Another solution that in my experience seems to work pretty well is what mainsail does. The motion planner runs on a raspberry pi. Theoretically this needs to be a realtime thing, but in practice the RPi is fast enough to where it's never a bottleneck. The actual stepping of the motors is handled by a more traditional microcontroller board with some very basic firmware. As far as I understand the RPi is sending it (step count, direction, rate) commands.

This solves a lot of issues since the microcontroller is doing some really basic things it's well suited for, and the RPi is freed from having hard realtime responsibilities.

I think a lot of legacy 1980s style systems already had an 8 bit external data bus (think z80, 80xx, 68xx), so if you wanted to upgrade with more I/O, uart, seven segment displays and the like, the atmega is a flexible choice that could be tacked onto the bus. That's my understanding.

Welll.... the RP2040 is a dollar and can be overclocked to 300MHz (peripheral clocks get a little weird around that point, but they can be clocked down).

Possibly "is the Waveshare display really that bad?" — as someone who's implemented a few projects with it but suffered from its terrible existing driver support... I know it's nice to see a more in-depth explanation of what makes it bad (and creatively working around that) in this post.

If it was possible to drive a touch interface and SPI display of that size from an MCU of that size/speed and still be responsive. I have only driven them from Pi Zeros, PocketBeagles and other much larger/faster systems, and still noticed some drag. Up to now, I've stuck to smaller displays without a touch layer for projects where I'm using the RP2040. [caveat: I am _not_ an embedded systems SWE so still figuring out where limitations are hardware vs. my knowledge]

Is there anything wrong with the ubiquitous ILI9488 3.5 in displays? I see some on aliexpress with resistive touch screen for below 6 dollars not including shipping. These are not integrated on a board but has 40 pin standard FPC connector, with some passives on the ribbon. (I personally prefer this over waveshare's pcbs) EDIT: 320 by 480 btw