In the final days at the Supplyframe Design Lab, I got one of the latest Teensy 3.6 microcontrollers to test.

It is a very nice piece of kit, and with double the speed (more so if you overclock!), 4x the RAM, 4X the flash memory, more I/O, and FLOATING POINT SUPPORT, and mostly code and hardware compatible with our previous Teensy 3.2 efforts, for just $10 over the price of the old one, it seems natural to switch development to the new board. The additional I/O lines alone save me from having to use my MEGSY pin expander board, which almost makes up the additional cost there.

This is wonderful, but since I did base my previous designs around my own MEGSY expansion board, I can't just drop the 3.6 into the circuit and have it work. I'm going to have to design a new board for the different pin arrangement. And before doing that, I need to test the Teensy 3.6 and make sure that my assumptions on how it is going to work are correct. Can I really use the pins I need for what I want them to do?

So I'm back at the breadboard, shoving pins in holes.

The first test was get the screen running. I used PJRC's $12 TFT touch screen, wired up to the same pins as before. Now, on the Teeny 3.2 I had some issues with frame rate. Running flat out on an overclocked 95Mhz Teensy 3.2, a straight screen clear took 56239µs, giving about 17 frames per second. If you are doing a lot of stuff, that even interrupts audio calculation, which is not good.

So I ran the same test on the Teensy 3.6, overclocked to a blazing 240MHz, and only got it down to 44936µs, or about 22 FPS. That is not nearly the gain I expected.

So I looked at the ILI9341_t3 library code. It showed an SPICLOCK speed of 30Mhz. I tried raising it up, but it didn't help at all. It turns out that value is just used to calculate a frequency divider off of the CPU clock, which can't be lower than /2, so raising it couldn't make the value any higher.

Some digging in the PJRC forums found a thread on the topic and so I asked. Kindly Mr. Frank Boesing pointed out that I needed to increase the bus speed using F_BUS. I searched around and finally found that value in "kinetis.h" in the avr/cores/teensy3 directory. Paul was kind enough to put a little note "Uncomment these to try peripheral overclocking. All the usual overclocking caveats apply..." and had two additional speeds for F_BUS available for each processor type.

Of course, I had no idea which value of F_CPU matched my CPU, but I added some Serial.printf commands to my code to output it and knew exactly where to be (240000000 is correct for the Teensy 3.6).

So I tried the 80 MHz F_BUS speed first, and my frame rate went up to 29 FPS ( 33711µs per screen draw). A lot of games run at 30 FPS, so that isn't too bad.

The 120 MHz setting gave 44FPS ( 22492µs ). That still isn't the 60Hz rate that videogames like, but it might be ok for my UI if I am careful.

Ultimately, I've got processor to spare, but if I am blocking waiting to send SPI data to the video, I'm wasting most of my CPU doing nothing. So I'll probably have to be careful about when and how much I draw. While I was never intending to draw the screen flat-out all-the-time, sometimes, like when turning knobs, it needs to update a part of it fairly quickly. So I'll have to be careful to structure my code to eliminate blocking while waiting for graphics to render and to only update the parts of the screen that need it. Well, my UI needed a rewrite anyway...

Another nice thing with the Teensy 3.6 is that it actually has enough RAM to store an image of the entire screen, unlike the Teensy 3.2. Frank Boesing is working on a fork of the ILI9341 library that does just that and then uses DMA to send the data to the screen all at once. I will probably end up using at least some of this for my own screen updates.

There is also another version of the library forked by Kurt E. who added support for different SPI busses on the Teensy 3.6's ARM chip. I don't think I need that capability, but...