The asker has a 3D printer controlled exclusively through a touchscreen (MKS PI-TS35, driven by an ILI9488 controller over SPI at 20 MHz) and wants to add remote control. The plan: use an FPGA to passively sniff the SPI framebuffer data going to the display, reconstruct the image for streaming, and also inject synthetic touch events back into the system — effectively building a remote KVM for an embedded device that was never designed for one.

This is a genuinely compelling problem because it sits at the intersection of several non-trivial challenges:

• SPI bus sniffing at speed. Passively capturing a 20 MHz SPI stream requires careful timing. The FPGA must sample MOSI, MISO, SCK, and CS lines, decode the ILI9488 command protocol (distinguishing register writes from pixel data), and reconstruct a coherent 320x240x16bpp framebuffer in real time. That is roughly 2.5 MB per full frame refresh, and the ILI9488 protocol includes windowed writes, partial updates, and command sequences that must be tracked statelessly.
• Frame reconstruction ambiguity. The ILI9488 supports column/row address windowing (CASET/RASET commands followed by RAMWR), meaning the host MCU rarely sends a full frame. The FPGA must maintain a shadow framebuffer and apply partial updates to the correct pixel regions. Missing or misinterpreting a single command/address packet corrupts the entire display state until the next full redraw.
• Touch injection. The touch controller (likely XPT2046 or similar, also SPI) is a separate device on the bus. Injecting touch events means the FPGA must either act as a man-in-the-middle on the touch SPI lines — pretending to be the touch controller when injecting, and passing through real touches otherwise — or multiplex between the real controller and a synthetic source. Bus arbitration and timing here are delicate: the host MCU polls the touch controller at a specific rate, and the FPGA must respond within its expected timing window.
• Upstream transport. Once you have pixels and can inject touches, you need a channel to a remote client. Most approaches use a soft-core or hard-core processor on the FPGA (or a companion MCU) to stream JPEG-compressed frames over Ethernet or USB and receive touch coordinates back. This adds a whole second system to design.

A practical approach would be to start with an iCE40 or ECP5-class FPGA, implement the SPI sniffer as a passive tap (high-impedance on the display SPI lines), decode the ILI9488 command stream with a state machine tracking CASET/RASET/RAMWR sequences, and write decoded pixels into a dual-port block RAM framebuffer. For touch injection, a separate SPI slave module can intercept the touch controller's CS line via an analog mux, allowing the FPGA to respond with synthetic coordinates when remote input is active. An ESP32 or RP2040 companion over a fast SPI or parallel link could handle the network side.

The biggest gotcha is protocol synchronization on startup: if the FPGA starts listening mid-stream, it may misinterpret data bytes as commands. A robust design needs a resynchronization mechanism — watching for known initialization sequences or CS deassertion boundaries to re-establish framing.