Artifacting on Teensy 4.1

[ric96]

I am trying this library on a teensy 4.1 using a 64x64 RGBMatrix.
I am seeing shimmering led artifacts around any object drawn on the display, moving or static.
I have tried is display with the PxMatrix library as well and had the same issue but they have a MuxDelay function that slows down the A-E channels by 1us or more. This seems to help on my panel. Any way to implement this on protomatter?

Shimmering LEDs

[ladyada]

yeah could be a delay required or something. if you find a fix please submit a PR!

[daveythacher]

Posting your code would be helpful. This library only plans for 12-16MHz. This panel can consume that completely for high bit depth. This library attempts 250Hz, which will be hard for for this panel. It is possible with 4 bit depth.

You have two choices lower the max frame rate or lower the bit depth. If you set your max frame rate to 175 you should be able to get 5 bit depth running at 12 MHz.

This does not look right to me:

Adafruit_Protomatter/src/core.c

Lines 311 to 317 in c2c81de

	// Estimate minimum bitplane #0 period for _PM_MAX_REFRESH_HZ rate.
	uint32_t minPeriodPerFrame = _PM_timerFreq / _PM_MAX_REFRESH_HZ;
	uint32_t minPeriodPerLine = minPeriodPerFrame / core->numRowPairs;
	core->minPeriod = minPeriodPerLine / ((1 << core->numPlanes) - 1);
	if (core->minPeriod < _PM_minMinPeriod) {
	core->minPeriod = _PM_minMinPeriod;
	}

It may not allow enough time for a full column shift in the lower bit planes. This divider should not be less than the number ticks required to update columns. This is tricky as you need to convert the processor speed to timer speed and know the number of instructions required to shift a single column,

I this is why I like hardware. Its a known rate for ticks. This is possible in software, however on multiple platforms, compiler, etc. this gets tricky. Finding platforms with hardware support would solve these problems. Maybe?

Limiting the frame rate will work around this problem. Indirectly this will enable you to increase the timer divider. Lowering the bit depth will do the same thing. Faster cores will automatically find a striking point against bandwidth. That 12-16MHz is the bandwidth, and faster cores will naturally shift to the higher end.

The issue however is shift registers are bandwidth hungry. Other LED drivers exist, which are not supported, solve this problem directly. To roughly guess that, divide the clock by multiplex, columns, 2 ^ bit depth and frame rate. This number must be larger than 1.

Assuming 16MHz, 1:32, 6 bits, 64 columns, and 250Hz. I get a number less than 1. If I reduce the FPS to 200Hz then I am above 1. In theory at least. There is other timing issues which can pop up. I will stop here, since the last time I tried this is it was not deemed appropriate.

I think I would recommend allowing the limit to be configurable. This puts more work for the user, but I think proper documentation can solve that. I see no need to make the code and support complicated for this.