Skip to content

Conversation

jepler
Copy link
Contributor

@jepler jepler commented Jan 16, 2025

No description provided.

Cycle counting the PIO program, each data word should take 2 PIO clocks of clock_get_hz
while each repetition of the delay loop should take 1 PIO clock.

However, with a non-gamma-corrected ramp, discontinuities (decreases) in brightness were
seen for the bitplanes that needed the additional delay with oe enabled.

Empirically, the value of 128 gives a plausible linear ramp and also fixes the big buck
bunny rendering artifacts with 10 planes.

It also makes the granularity of the on-time twice as fine, by being able to turn off
during either the "clock on" or "clock off" phase of the shift register loading process,
when the output enable time is short. Thus, with 10 bitplanes and a 64x32 panel,
only the most significant bitplane needs any extra delay.
@jepler
Copy link
Contributor Author

jepler commented Jan 16, 2025

there's still a problem where, with a small number of bitplanes, the overall brightness decreases. I think this is because the longest on time is less than the total data transmission time for a row of pixels.

@jepler jepler merged commit b015674 into main Jan 16, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant