Potentially better PIO program to drive ST7789 with parallel protocol

[antirez]

Hi, and thanks for this repo!

I believe that by forcing the pull where there would be a NOP instead, a race condition is avoided, and the WR clock line is kept in consistent state.

.program st7789_parallel
.side_set 1

.wrap_target
    out pins, 8  side 0
    pull ifempty side 1
.wrap

[Gadgetoid]

Happy to test a PR if you make one, I think I've got most of our ST7789 based displays handy for testing- albeit the PIO for the parallel bus only affects (IIRC) Tufty 2040.

Is there a repro for the race condition, or is this just a straight forward it's-better-to-fix-it-than-wait-for-it-to-break thing?

[antirez]

Hi @Gadgetoid! I didn't submit a PR because my findings are with code different than the one in this repository, however I used the same PIO program that you are using, and what I discovered is that it may leave the WR clock in the wrong state the first time the VM is started. Forcing the pull when WR is high apparently fixes the issue. However perhaps because of differences in the actual implementation of the C code, the program you are using will not cause any issue.

Some other random info:

Using DMA + PIO I also have other issues I can't address, that don't happen with a version using bit banging I also wrote. For instance the ST7789 does not have any maximum timing for the clock, it only asks you to keep certain signals up/high at least 16 nanoseconds. Yet, if I use a very large clock divider with PIO+DMA it stops working, while with bit banging it works even if I put usleep(1) between each tick. Similarly with certain overclocks, even with the appropriate frequency divider I can't get DMA+PIO working reliably. And I suspect this driver can have the same issue as well as the approach is identical to what I am using.

Don't bother to change your PIO code if you don't have issues, but I wanted to ping you about those issues I'm experimenting as we could see other using this code that have similar problems. Cheers.

[antirez]

P.S. in practical terms, what you often see because of the PIO desync in WR state is that when you fill the display for the first time, the color is wrong. Or sometimes this may show up as the first pixel drawn to be of the wrong color.