Teensy 4.0 Released

Hi easone.
So there is something that I think is wrong in the new selection of pins, if I have understood correctly what you indicate.

In Flexio2, we would have to choose pins from the same contiguous 16-pin block, that is, block1 D00 to D15, or block2 D16 to D31 (according with picture attached). CLK can be chosen from any of the two blocks but it must be the first or last.

So the selection of pins 7, 8, 9, 32, 36, 37, for RGB, would not be correct, since pins 9 and 32 are in the first 16-bit block, and the rest of the pins are in the second block. 16-bit Flexio. Also the original pin configuration would be incorrect since pins 6, 9, 11, 12, 32 are on block1 and pin 8 is on block2. Is this correct ?.

So a correct selection of pins for RGB would really be this? 7, 8, 34, 35, 36, 37 of Flexio block2, and pin 6 for CLK of Flexio block1.

There is no need for the 16 pin block to start at pin D00 or D16. FlexIO allows you to pick any pin as the start of the 16 pin block, so you can choose D01-D16 or D11-D26.

The selection you indicated should also work.

Ok, thanks, now I understand, everything is already clarified.

Aha! These changes fixed the pixel flicker issues I was having when using SPI. I can run things at 600MHz now :smiley:

Hi folks,

Apologies if I’m missing something obvious here, but I’m stumped.

I got Louis’ OshPark adapter and a 4.1 a few days ago, and I pulled down the “teensy4” branch from the repo. I can’t seem to get it to compile at all. Here’s what I’m seeing:

In file included from [fullpath]\Arduino\libraries\SmartMatrix-teensy4\src/SmartLEDShieldV4.h:5:0,
                 from [fullpath]\Local\Temp\arduino_modified_sketch_373068\FeatureDemo.ino:6:

[fullpath]\Arduino\libraries\SmartMatrix-teensy4\src/SmartMatrix3.h:44:19: error: No MatrixHardware*.h file included - You must include one at the top of your sketch

 #pragma GCC error "No MatrixHardware*.h file included - You must include one at the top of your sketch"

I was able to roll back my library to “master” and switch over to a Teensy 3.2 on the same hardware which compiled with a few warnings. For reasons I can’t understand, the “teensy4” branch gives me that weird error. (That forward slash in the error message path looks ominous fwiw)

I’m on Arduino 1.8.12 / Teensyduino 1.52 if that helps. Please advise.

@Louis is changing how things work, see SmartMatrix Library 4.0 - Changes to MatrixHardware #includes - #4 by Louis

Right now, with the Teensy4 branch, you need to include one of the following headers before you include SmartMatrix:
MatrixHardware_KitV4T4.h (if you are using jumpers to rewire the shield)
MatrixHardware_T4Adapter.h (if you are using the OSHpark adapter)
SmartLEDShieldV4.h is not used anymore.
We are testing a new version of the shield designed specifically for T4.x, which will probably have a different named header.

I need to bring the examples in the teensy4 branch up to date to show how to include the MatrixHardware*.h file. Most examples in the NT branch show how to include the file. I’ll merge these over to the teensy4 branch at some point, hopefully soon:

Thanks, all. I got it working by using the proper include. I’m going to order a teensy 4.1 so I can use the onboard SD card. I’ll put it thru its paces soon.

I am also preparing my own board for testing, I already received the Teensy 4.1, and today the PCB of my own board with a different pin assignment to have the LPSPI4 port free.

I also ordered some 8MB PSRAM chips, to add two to Teensy 4.1, so I will have an extra 16MB of RAM. Any variable or array can be assigned to that PSRAM by adding the EXTMEM prefix to the variable definition. PJRC Store

I have yet to finish another design of my own board with the RT1062 microcontroller, instead of using a Teensy, but first I want to try the Teensy because it is easier. It will be my first board with BGA chips.

There’s hasn’t been any updates in a while but there’s a lot going on:

  • The SmartLED Shield for Teensy 4 prototypes were manufactured, received, tested, and they’re working great
  • Eric has been making improvements to the Teensy 4 HUB75 code
  • I’ve been working on other SmartMatrix Library code aiming to a SmartMatrix Library 4.0 release
  • I’m improving the Animated GIFs code, turning Adafruit’s adaptation of the AnimatedGIFs sketch into a generic GifDecoder Library with SmartMatrix Library examples
  • I’ve started working on a Crowd Supply campaign for the SmartLED Shield for Teensy 4, and hope to launch this month, the sooner the better

The Teensy 4 is really powerful, and able to push a lot of pixels to the panels. I’m going to need to update SmartMatrix Library to make sure some of the uint8_t types used in older code (when any dimension of the display approaching 256 seemed far out of reach), are replaced with uint16_t so displays wider/taller than 256 pixels can be driven. 128x128 pixel Animated GIFs can be decoded and driven to a 128x128 36-bit color 240Hz refresh display at 100% speed.

From what I’ve tested so far, 128x128 with high color depth and high refresh rate doesn’t seem to be pushing the limits of the Teensy 4. (edit: see next post)

What does push the limits? @marcmerlin I tried your use case of 128x192 pixels, wanting a high refresh rate and willing to sacrifice color depth. Best it can do so far is 24 bit color, 130 Hz refresh, decoding the 128x192 GIF I tested at 77% of full speed. Eric added some code to lower refresh rate below 24 for the Teensy 4, but for some reason I get lower refresh rate with that code. Not perfect, but at least promising!

1 Like

Looks like I made a mistake while testing and 128x128 isn’t actually able to do 240Hz refresh.

Summary of max refresh seen when testing GIF (128x128) decoder sketch with matrix.setRefreshRate(240):

  • 128x128/32 36-bit color: 157Hz
  • 128x128/32 24-bit color: 202Hz
  • 128x192/32 24-bit color: 130Hz
  • 96x96/32 36-bit color: 240Hz

128x128/32 36-bit color: 157Hz isn’t a bad result, but I got used to seeing no tearing when taking pictures or video of panels running at 240Hz refresh, and now I can’t go back! I think the limit is mostly to do with the time it takes to shift out pixels to the panels, with some pauses between to make sure all pixels make it out before the latch signal toggles. At 20MHz HUB75 clock speed, just the time to clock out 256 pixels x 12 times for 36-bit color, across 32 rows gives a theoretical max refresh rate of only ~203 Hz, add in pauses before and after each latch, and the refresh rate is down to 157Hz. 1/(1/20000000*256)/12/32 = 203.45

1 Like

I was curious about Louis’s comment about lower color depths, so I did some more tests with the latest library. Here’s some results running a plain bitmap test (no GIF decoding) with a background, scrolling, and indexed layer. These results are for Teensy 4.1 running at 600 MHz on the “Fastest” optimize setting. I’m using 32-row/mod16 panel size.

128x128 128x192 128x256
48-bit 121 Hz 82 Hz 62 Hz
36-bit 163 Hz 109 Hz 82 Hz
24-bit 244 Hz 164 Hz 123 Hz
15-bit 327 Hz* 220 Hz* 171 Hz*
9-bit 412 Hz* 278 Hz* 208 Hz*

With the lower bit depths (starred), I found that if I tried to set a refresh rate higher than the max stable value, the buffers would under-run and the driver would adjust the refresh rate all the way to 50-65% of the max before stabilizing. This probably explains why Louis was seeing lower refresh rates.

It looks like the 24-48 bit settings are HUB75 clock speed limited since they all are pushing about 96 million bits per second. But the lower color depth settings appear to be CPU speed limited instead. (If I overclock the Teensy to 816 MHz, I can get higher refresh rates for < 24 bit.)

I did some further digging and I think that the processing bottleneck is the code that extracts pixel data from all the layers (which is the same speed regardless of display color depth). Interestingly, it appears the majority of the CPU time is used decoding the scrolling and indexed layers.

No doubt with CPU-intensive rendering, the maximum refresh rates are going to be lower.

After disabling the indexed and scrolling layers, and making a minor speedup to the background layer I am now getting clock speed limited refresh rates at 9 and 15 bit:

128x128 128x192 128x256
15-bit 392 Hz 263 Hz 198 Hz
9-bit 654 Hz 439 Hz 331 Hz

Eric, thanks for looking into this. Scrolling I’m aware is inefficient, I wasn’t aware of indexed. I’ll have to take a look at some point.

If anyone thinks improving the efficiency of these layers is important for the next major release, please let me know. It’s not a high priority for me personally.

Big Announcement! SmartLED Shield for Teensy 4

1 Like

Tl;dr there’s a lot of updates to HUB75 code, and any existing projects using stacked panels need to be updated as SMARTMATRIX_OPTIONS_BOTTOM_TO_TOP_STACKING logic is now reversed.

The teensy4 branch has a lot of new updates:

I added the missing C-shaped stacking to all platforms, and added MultiRowRefresh to Teensy 4. In the process of adding these I realized that the SMARTMATRIX_OPTIONS_BOTTOM_TO_TOP_STACKING option was reversed. By default stacking was bottom to top, and enabling SMARTMATRIX_OPTIONS_BOTTOM_TO_TOP_STACKING would stack top to bottom. I fixed the logic, but anyone using stacking in the Teensy 4 branch will end up with reversed stacking logic when they update, so be careful there.

It turned out to be difficult to support MultiRowRefresh panels with C-shaped stacking, so they aren’t supported. MultiRowRefresh panels can only use Z-shaped stacking.

@easone’s loadMatrixBuffers() refactoring for the Teensy 4 is a lot easier to read, and is more efficient (~30% more) than my old code for Teensy 3, so I refactored the Teensy 3 loadMatrixBuffers() to get the improved efficiency, and also allowing kRefreshDepth to be any multiple of 3 instead of just 24, 36, 48.

I also added the hardware files for SmartLED Shield for Teensy 4 V5 (the production version that will be shipping to Crowd Supply backers).

I pushed some more updates today. A few things that will break existing sketches unfortunately, but hopefully the long term benefits are worth the temporary issues. Major changes that may break existing sketches, or cause some merge issues with forked code:

  • I renamed a bunch of files and classes to fit in this pattern SmartMatrix-Platform-LEDType-ClassType, e.g. SmartMatrixTeensy4Hub75Refresh
  • I renamed the MatrixHardware files to have a similar pattern, and to be more descriptive with the names e.g. MatrixHardwareKit_V1.h is now MatrixHardware_Teensy3_ShieldV1toV3.h
  • I replaced all instances of “Multiplexed” with “HUB75” in both file and class names as in the past few years calling these panels “HUB75” has seemed to caught on, and “multiplexed” is rarely used

I wasn’t perfectly consistent with using HUB75 vs Hub75, and I think I like the latter better e.g. SmartMatrixTeensy3HUB75Calc_Impl vs SmartMatrixTeensy3Hub75Calc_Impl so I’m going to do another renaming pass.

I still need to figure out what to do with the class and library name, as I foolishly named both “SmartMatrix3” instead of just “SmartMatrix”. I’m planning to rename them and request Arduino Library Manager to change the library name. I hope this doesn’t cause problems where people have an out of date “SmartMatrix3” library folder and a current “SmartMatrix” library folder, but I think changing the top of the sketch from #include <SmartMatrix3.h> to #include <SmartMatrix.h> and using the new MatrixHardware file name will sort things out, as these names will be unique to SmartMatrix Library 4.0, and the teensy4 development branch.

SmartLED Library 4.0 has been released on GitHub and Arduino Library Manager

4 Likes

Thanks for all your hard work here. I appreciate it.