I started playing with the on board sd slot on the teensy 3.6 with mixed results…
I started with just the smartmatrix animated gifs example and although it does compile as soon as it starts to run it crashes…
Then i tried the example at the below link and it works playing back as usual any gifs found on the card with them complete and looking fine with one issue, there is distortions all over as it plays back… Its hard to explain but it looks like some sort of timing issue as each 16 lines of the display has the same distortion ( ghosting remnants of parts of the display) these distortions involve not only the background layer but also any indexed layer that is used…
Louis can you suggest what might be altered to avoid this? It seems whatever was changed from the first gif example to the gif example below is what i should be looking at…
No fix yet, but I just tried a Teensy 3.5 for the first time, got AnimatedGIFs to work with the SD Card slot onboard 3.5 by just changing the SD_CS definition to BUILTIN_SDCARD, and I do see the ghosting effect.
I’m starting work on a shield that will fit the 3.5/3.6, so this will get fixed at some point for sure.
MatrixHardware_KitV1.h has a line to set the minimum amount of time to transfer a block of pixels. This appears to be longer on the Teensy 3.5, or maybe my calculation involving F_CPU is just wrong. I replaced the line with a hard number of 6000 ns (about double what worked on the Teensy 3.2) and the ghosting went away. Try decreasing the number to see what works without ghosting (a higher number here either limits the maximum refresh rate or maximum brightness, so the lower - without ghosting - the better).
I finally found some time to work on Teensy 3.5/3.6 support. I narrowed down the issue that’s causing glitchy GIFs. Occasionally the time it takes to transfer 32 bits out to the display takes a lot longer (almost double) than usual. I suspect it has to do with the Teensy 3.6 SDIO library using DMA to transfer from the SD card.
There might be something we could do to set the priority of SmartMatrix higher than other DMA channels, but I’m concerned that it could cause problems so I’m leaving it alone for now. For now, the calculation for PANEL_32_PIXELDATA_TRANSFER_MAXIMUM_NS needs to factor in whether other DMA channels are being used at the same time.
This isn’t the only glitchy behavior I’ve seen, I’m also seeing some more minor almost single pixel glitches on the Teensy 3.6, that might have to do with the higher transfer speed.
An additional fix is needed to slow the matrix clock down at the higher speeds on the Teensy 3.5/3.6. I found that glitches start to show up at 140MHz, at 168MHz they’re particularly bad, and at 180MHz they’re a little worse than 140MHz. There’s an option to stall a DMA channel for as few as 4 cycles after each read, which slows the transfer rate so it’s a consistent 3.28us to transfer 32 pixels at 180MHz. There’s already some code to enable this that’s commented out, you can find this in SmartMatrix_Impl.h:
// for debugging - enable bandwidth control (space out GPIO updates so they can be seen easier on a low-bandwidth logic analyzer)
dmaClockOutData.TCD->CSR |= (0x02 << 14);
I’m seeing glitch free GIFs at 140, 168, and 180MHz with these two changes. I’ll package this up unto the next release, hopefully shortly.
I’m using the latest SD library downloaded from https://github.com/PaulStoffregen/SD, but it doesn’t see the card. The SdFat library sees it fine, so I think the card and hardware are otherwise fine. Am I using the wrong library, or do I need to configure something for it to work on the Teensy 3.6?
This should work, so you should work with PJRC to figure out why it’s not working, or switch over to use SdFat (or another library). It’s pretty easy to change FilenameFunctions.c to use SdFat instead of SD. You can use this as a reference:
