drspangle
commented
6 years ago So, after a bunch of experimentation, it seems that the show(), hide() and clear() methods don't solve my problem. Something else getting called (perhaps during the destruction of the previous class instantiated by get_device()?) is resetting the devices and cleaning up the glitch. I'm hoping it's something that can be done rapidly because it seems that the show(), hide() and clear() methods introduce a non-trivial delay in rendering, but if they're not the necessary part of the get_device() call then perhaps my hypothesis that the display could be reset on a regular interval to fix the glitches is still correct.
thijstriemstra
isjerryxiao
rm-hull
I'm in the process of trying to figure out why my large (>100 matrices) MAX7219 display board is encountering glitches. I've spent a lot of time experimenting with clock speeds, bus transfer rates, and I've got something very close to a stable state. Despite being stable for minutes or hours, the most common glitch is that single matrices seem to shut off and on, get stuck pixels, or change contrast for some reason, and it's not clear why. I'm fairly certain this is not a memory leak or something on the software side causing corrupted signals. That is to say, I don't think the software is the problem, but that doesn't mean that there isn't a software solution to my problem.
Resetting the display fixes the problem. I want to do some debugging to investigate what about the reset process fixes the problem, but aside from running the high level
get_device()(fromdemo_opts), the only methods that I can find to reset the display are themax7219class'sshow()andclear()methods. I'm really not sure which one of the two, or both one after the other, are responsible for resetting the device to a stable state again. It would be great if I could figure out what mechanism is actually "fixing" the devices and cut away any extra cruft that slows down this process so that it could potentially be run repeatedly with minimal latency added to the rendering of subsequent frames.So, if I can find a way to meet this requirement, my hypothesis is that if I'm rendering frames on the display at a constant rate, I could inject the command that successfully cleans up the glitches every second (framerate+1 frames) or so and it would hopefully be fast enough prevent the glitched matrices from appearing glitched to the human eye, with minimal impact on performance in terms of overall average framerate.
I'm also analyzing the signals using a protocol analyzer and oscilloscope to see if there's some other reason why the MAX7219 modules are doing this strange behavior. From this perspective, the hypothesis is that the devices being affected by the glitch are missing a clock cycle or something similar and that's making their shift registers go out of sync from the others in the cascade. Not sure about this yet. Power reads clean on the oscilloscope, signals are 5V0 using a boost converter from the pi's 3V3 outputs, everything is wired in parallel except the DOUT to DIN pins on each module which are wired in series. I'm using PCBs with 4x MAX7219 chips each, the typical ones found on Amazon and Ebay with 8x8 LED dot matrices. There's no significant ringing or any other analog weirdness on any of the signal pulses as far as I can see. At this point there's nothing I can really change with respect to wiring, the clock speed, or the SPI MTU chunk size that seems to make the display glitch less, so I'm hoping I might be able to get closer to a sustainable solution by resetting the devices as quickly as possible on a regular interval.