Test different wait-states for GPIO outputs

[hzeller]

Right now, we only have a single parameter to control GPIO slowdown. But maybe some panels can deal with faster clocking, but need more time for latching ? So instead of a single paramter gpio-slowdown, we should have multiple that define the wait-states for various transitions.

[depili]

Also when I did some logic analyzer captures a while back I noticed that some of the signal hold times seemed quite short in comparison to other pulses and the timing needs.

You can find capture (with --gpio-slowdown=2) at https://github.com/sigrokproject/sigrok-dumps/tree/master/led/hub75 and you need pulseview https://sigrok.org/ to inspect the capture.

[hzeller]

Ah neat, thank you! I should probably get myself a logic analyzer as well; for these kind of things to see things in context my poor little oscilloscope doesn't cut it :)

What signals were you concerned w.r.t. timing ?

[depili]

For example the clock signal seems to be going high for 2-3 samples and staying low for 5 samples, the latch is also 2 or 3 samples long. Sampled on 100MHz sample rate (max this LA could sample 16 channels).

Individual 1 bits in the color channels seem to be 5 samples with 010 pattern and 13 samples for two consecutive 1 bits with 0110.

So maybe the high pulses with the clock and latch could be longer by default?

[hzeller]

I also think it can't harm if the latch would be a little bit longer, because the chips dealing with the latching seem to be generally a bit slower (which is why I do the full BCM per line and not in multiple passes through the panel - the address line changes can't keep up with that properly).

There is an optimization that does not toggle bits when there is no change in bits, which might be the thing you see with consecutive bits being different length. Most important is that the positive edge of the clk signal is sufficiently after the data has settled. The longer delay you see in the 'low' section of clk is because this is when the Pi is busy putting out the next data block.

I am wondering though if the timing gets off with further chains: when the clk signal is just passed through from panel to panel, but the data is delayed due to being shifted through the shift registers, then after a few panels the timing can be off - which is what I think is happening when further away panels start to have noise; one would hope that there is a sufficient added delay of the clock signal per panel so that they line up, but maybe that is not always what happens.

Anyway, some timing experiments shall help to optimize the refresh-rate and stability for long panels

[depili]

If I remember I can wire one matrix I have, which has 3 chains of 32x64 1/16 scan modules, to the logic analyzer and capture the signal after 3. 6 or 9 chained modules.

[hzeller]

Oh, that would be helpful!