Thanks @gamblor21. Also don’t have the hardware so it will be good if someone else can run it on their FunHouse board.

I ran this on a Funhouse and it does appear to eliminate the "glitches"
before

after

.

Here's a Thing that we can add - its a bit more effort
when setting the window/address/command for the TFT - it should be at 1 MHz max - but when sending data, it can be much faster. it would require a kwarg for different frequency however would allow us very fast display updates.

Here's a quick first look at what it might take to split out the sending of "setup" vs "bulk data" with different speeds.

Data is sent to the display using a structure displayio_display_core_t with a begin_transaction function. Currently, the same begin_transaction function is used for both "setup" and "bulk graphic data" (for bulk graphic pixel data see Display.c _send_pixels).

One option is to add a flag to the begin_transaction function for "low-speed" or "high-speed". These two frequencies could be configured in the displayio constructors. Then when the begin_transaction function is called, you can specify which speed to use. The begin_transaction function should reconfigure the SPI bus frequency prior to sending the SPI transaction (see FourWire example here).

Will need to consider how far-reaching this change will be, since all displayio bus types use a begin_transaction function.

I think there is already a command/data flag that could be used for this?

I think having two baudrates would be the best fix for this (and 7.x is a good time to do it!). data_baudrate and command_baudrate could provide two knobs and baudrate could set both and be deprecated in 7.x.

command vs data is given with display_byte_type_t to send. the configure line should be moved from begin_transaction to send so it can change the speeds for each.

I talked to @kmatch98 and I am going to take a look at a new PR with the baud rate change. I will update the issue as well.

If a short term fix is required this PR would still be a good idea.

I remember there was some further testing with dynamic baud rate changes, but I don't remember the results. Could you record them here?

The variable baud rate for commands vs display was found to have no affect on the reliably of the display so I stopped work on that aspect. The overall baud rate can still be controlled. I need to update the original issue with some more findings but still no solution. This PR would fix the issue but is more of a band aid then a long term solution.

@ladyada should we merge this for now to fix existing FunHouse (et al) issues temporarily while we explore further?

I will test this again.