teensy fast tft display brands

If it will be used outdoors where people wear polarized sunglasses, TFT LCD displays tend to have one orientation where it is hard to read the display (or impossible, depending on the polarized glasses, display, etc.

OLED displays tend to not have problems with polarization, but they tend to only be available in certain sizes. Even if they are available for the same size as a TFT display, they tend to be more expensive. The OLED 128x128 pixel displays that I have experience with have a slower refresh rate than the TFT displays. I found I needed to slow down the display in order to allow to use a Teensy 3.6 at full speed.

Finally if you only update the display occasionally but don"t want the display"s contents to vanish if the display loses power, you might want to look at the e-paper or e-ink displays. These displays take a bit of time to display the screen. Many black & white displays will update in a few seconds, the displays with black, red, and white colors will take at least 15 seconds to display things.

Besides the output type, another factor is whether the display needs to be refreshed from the microprocessor"s memory periodically or whether the display has a built-in microprocessor that takes input in a stream from spi, i2c, or uart, and the microprocessor does the management of the screen. If the Teensy has to buffer the memory, then that limits the size of the display you can use. In addition, if you have to write out the display each time, it can dramatically slow down the frame rate. If you have a display with its own microprocessor, you can speed things up if you are only updating part of the screen (for example time of day).

I2C: You need 2 fixed pins (usually A4/A5). You can have multiple displays as long as each display has a unique address. I2C tends to be a slow protocol;

There are some displays that had people working on them that seem to be abandoned now. You probably should ask here first before going off on lessor known displays.

Finally for full size displays, you are probably better using something like a Raspaberry Pi, which has more memory, a much faster clock rate, an included graphics processor, and has a HDMI port directly.

Paul Stoffregen did it again: the Teensy 4.0 has been released. The latest in the Teensy microcontroller development board line, the 4.0 returns to the smaller form-factor last seen with the 3.2, as opposed to the larger 3.5 and 3.6 boards.

Don’t let the smaller size fool you; the 4.0 is based on an ARM Cortex M7 running at 600 MHz (!), the fastest microcontroller you can get in 2019, and testing on real-world examples shows it executing code more than five times faster than the Teensy 3.6, and fifteen times faster than the Teensy 3.2. Of course, the new board is also packed with periperals, including two 480 Mbps USB ports, 3 digital audio interfaces, 3 CAN busses, and multiple SPI/I2C/serial interfaces backed with integrated FIFOs. Programming? Easy: there’s an add-on to the Arduino IDE called Teensyduino that “just works”. And it rings up at an MSRP of just $19.95; a welcomed price point, but not unexpected for a microcontroller breakout board.

When doing hardware reviews it’s crucial to choose the right comparison hardware. I think the best comparison in this case is between the two boards that share the same form factor; the Teensy 4.0 and the 3.2. I’ve chosen not to make the comparison with the Teensy 3.5 and 3.6, which are priced a little higher, in a larger form factor, and have SD card slots soldered on.

The Cortex-M7 on this board also supports tightly-coupled memory (TCM), which provides fast access like a cache, but without the non-determinism that can complicate hard real-time applications — one of the problems with other high-power microcontrollers. The 64-bit ITCM bus can fetch 64-bits, while two dedicated 32-bit buses (DTCM) can fetch up to two instructions from the TCM each cycle – these buses are separate from the main AXI bus used to communicate with other memory and peripherals. The Teensyduino environment automatically allocates code and statically allocated memory into the DTCM area, which can be up to 512K in size, although you can override the default behavior with some command-line switches. Memory that isn’t accessed by the tightly-coupled buses is optimized for access by the peripherals using DMA.

To see how fast this thing really is, Paul ported the CoreMark embedded-processor benchmark to the Arduino environment. (Note that CoreMark seems to be a registered trademark of the Embedded Microprocessor Benchmark Consortium (EEMBC)). This synthetic benchmark tests performance managing linked lists, doing matrix multiplies, and executing state machine code. He reports the following scores for a number of boards (larger numbers are better).

I was able to verify the Teensy 4.0 and 3.2 numbers; my 3.6 must have sprouted legs and walked off somewhere, and I didn’t have any of the other boards handy for testing. Using my numbers (nearly identical to those above), the 4.0 is around ten times as fast as the 3.2.

One of the new features of the Teensy 4.0 is the automatic recovery process, which restores the board to a known good state without the need for a PC connection. If you press and hold the reset button for 15 seconds, the red LED will flash to indicate you’ve entered restore mode. Once you release the button, the red LED will illuminate while the flash memory is erased and re-written with the traditional Arduino “blink” program. Once the re-write is complete, the blink program is run and the orange LED begins blinking, just like on every Arduino-compatible for the past decade and a half. It’s DFU mode without the need for host computer or known-working binary. These used to be key components for hardware-based restore and now they’re part of the board itself.

Why would you want to do this? In a nutshell, because USB itself is a train-wreck. On top of an insanely sprawling and complex protocol, there are charge-only cables sans data pins lurking in your junk box, operating system bugs waiting to trip you up (looking at you, Windows 7), and a whole host of other issues that cause serious head-scratching when things stop working. This can be especially confusing with native-USB boards like the Teensy 4.0; while the built-in USB functionality is amazingly powerful, and can be used in a wide variety of ways, when something stops working, you’re not always sure how to get back on track. Now, you are – just press the button.

Paul envisions this Teensy 4.0 being used for polyphonic audio synthesis, running moderately complex machine learning algorithms, and real-time audio analysis. In many cases, the first level of processing on data-intensive input devices can now be moved from a host computer to the external microcontroller, narrowing the bandwidth required to the host system. And for projects driving a display, the built-in pixel processing pipeline can also accelerate graphics operations, offloading this work from the CPU.

CC3000 is troublesome, partly because it uses SPI_MODE1, partly because it uses the SPI port from within an interrupt. Adafruit’s CC3000 library has code to backup the AVR’s SPI registers, change them to MODE1, and then restore when it’s done, so the conflicting clock polarity isn’t (usually) an issue on AVR. But on Due, Teensy 3.1 and all other non-AVR chips, their specific SPI registers aren’t also in the code, so you can pretty easily end up with the SPI port left in the wrong mode.

Interrupts are also a huge problem. Using the CC3000 in simple blocking ways, where you fully complete all communication before you try to write to the display or read the touch screen or access the SD card tends to work. But if you use another device while the CC3000 generates an interrupt at just the wrong moment, it can run its SPI code while another device has chip select asserted, causing all sorts of terribly wrong results.

The touch controller on Adafruit’s displays comes in a couple different types, which need different SPI data modes, and some require very slow clock speeds. Again, they have AVR-only register save/restore, so usually you don’t get wrong settings into other libraries, but there’s no hardware specific code in those libs for non-AVR chips.

My recent work on SPI transactions, which will be in Teensyduino 1.20 (already in the latest release candidate and on github) and is planned for Arduino 1.5.8 (already in their github source and nightly builds) aims to solve both the settings and interrupt problems, in a hardware independent way. Adafruit has already merged my patches to their libs, at least for these most common ones, so they use the new SPI transaction stuff when compiled on those new versions.

PJRC is the manufacturer of Teensy, which is a high-powered alternative to Arduino. It’s compact, adaptable, and offers fantastic value for money. The Teensy works well with sensors which output large amounts of data with a fast refresh rate. It’s also relatively easy to get the Teensy to work with touch-screens, mice, and keyboards, which makes getting input into the chip straightforward. Moreover, the chip allows DMA (Direct Memory Access) for speeding up processing time by algorithms that require fast processing (Led strips, Screens, Audio and Movement/Orientation).

There are so many processor board choices when considering the needs of a product or project. One decision point might be, do you choose a microcontroller or a more powerful single-board computer (SBC)? The newTeensy 4.1 from PJRCsimplifies that decision because It combines the real-time nature of an Arduino-compatible microcontroller with the processing and I/O performance of an operating system-based SBC in a slim package.

Teensy 4.1 from PJRC is an update of their already mighty Arduino-compatible board. As the minor revision number suggests, the new board is an extension that builds on the previously introduced 4.0.

To clarify, while we call the Teensy 4.1 an upgrade or improvement to the Teensy 4.0, it is a standalone product. PJRC says this about their differences:Not every project requires so much I/O or extra memory. Teensy 4.0 fills those needs. But when you do need more I/O, more memory, fast ethernet, or connecting USB devices or fast SD card access, the larger Teensy 4.1 brings this extra I/O capability to a platform designed for real-time use with fast 600 MHz M7 performance.

Both feature an NXP iMXRT1062 processor based on an Arm Cortex-M7 running at 600 MHz. On-board there is 1 MB RAM, 8 MB flash, and many I/O options. The larger size, now 61 mm x 17 mm, is the same as the Teensy 3.6. The additional size allows for more I/O pins and features new to the Teensy 4.1: 100 Mbit Ethernet, improved USB host, SD card socket, and memory expansions.

Embedded microcontrollers communicating with Ethernet is not a new idea. The combination the Teensy 4.1 brings is a high-bandwidth, low latency 100 Mbit Ethernet connection without an add-on PCB (shield) or by moving to a full OS-based single board computer.

This capability means taking advantage of the real-time nature of the microcontroller and combining it with a high-throughput data pipe. Fast Ethernet has a raw bitrate of 125 Mb/s. After accounting for physical layer overhead, the maximum wire speed is 100 Mb/s. One beta user on the PJRC forums hassuccessfully tested the link up to 95 Mb/s. Keep in mind, these are benchmarks with early software support, so speed in real applications my vary.

Since an Ethernet jack would not fit on the PCB, PJRC plans to sell a through-hole soldering kit to attach to the header pins. If you need to add a jack today, they have made a version of the adapter shown above, available at thisTeensy 4.1 Ethernet OSH Park project link.

The previous Teensy 4.0 has pads to support a USB host connection. But, those surface mount pads are on the board"s bottom, or back, side. (Third-party products like theTeensy expansion boardgave an option to connect those pads to a physical port.)

With the new 4.1 version, there are through-hole pads and support for hot-plugging. Now you can add a physical port or a cable to plug directly into a device. For speed, the Teensy 4.1 USB port supports up to 480 Mbit per second.

SDIO is an extension of the SD specification that adds I/O capabilities. Teensy 4.1 replaces the 4.0"s SDIO solder points with a microSD card socket. Now it is easy not only to access an SD card but also to use the high-speed SDIO interface.

While the new Teensy moved all of the 4.0"s backside solder points to through-holes, it does not waste the space available on the larger form factor. The 4.1 has a couple of spots for user upgrades.

On the backside, there are two pads to solder additional memories. Remember that the Teensy 4.1 already comes with 1 MB of RAM and 8 MB of flash. One footprint lets you add a QSPI-based flash memory module. The Q in QSPI means quad, making it a fast serial interface. The iMXRT1062"s architecture places it on a separate memory bus making it suitable for loading media files or save large data structures without stalling other processor activity.

A second footprint supports up to 8 MB of PSRAM. PSRAM is dynamic memory with a built-in refresh controller, so as a user, you can think of it as static RAM. Since this chip also gets accessed through QSPI, it would work well as large buffers for tasks like digital signal processing effects or TFT displays.

Starting today, you can order the Teensy 4.1 from PJRC. They sell for $26.85, which is only about $7 more than the 4.0. Visit theTeensy 4.1 product page at the PJRC storefor more information.

I have not tried that. I have been using a Teensy 3.5. The touchscreen on this unit uses an XPT2046 controller, and the Teensy website (pjrc.com) has the necessary librapry. The library doesn"t contain any Teensy specific code (theoretically should work on any Arduino implementation.) The major problem may be process…

I have not tried that. I have been using a Teensy 3.5. The touchscreen on this unit uses an XPT2046 controller, and the Teensy website (pjrc.com) has the necessary librapry. The library doesn"t contain any Teensy specific code (theoretically should work on any Arduino implementation.) The major problem may be processor horsepower. The combination of touch screen and display may be too much for a ATMega 328. The libraries are RAM hungry and if the touchscreen is implemented with by polling in the main event loop rather than by using an interrupt the processor may not be speedy enough. Doesn"t exactly answer your question, but I hope it helps. For what it is worth, I am a huge fan of Teensy, especially 3.5. Cheap, 5V (3.5 but not 3.6) tolerant, small, massive program memory, RAM, and FAST.

I have several 3.5 inch MCUFRIEND touch Screens with the Red Board and are labeled "www.mcufriend.com 3.5" TFT LCD for arduino uno". Using this library the Red board touchscreens work on the Due and the Mega 2560, but on the Teensy 3.6 they do not work.

Using the Blue Board, this library works with Due, Mega 2560, and the Teensy 3.6 (Thank you for this change that allows me to use the Blue Board with the Teensy 3.6, Lightning speed graphics),

On Due and Mega the get ID on the Red Board Comes back as Unrecognized and uses TFT.begin as set to use 0x9486 by default. This does not work on Teensy 3.6.,

On Due, Mega, and Teensy 3.6, the get ID on the Blue Board Comes back as found "0x9486" and uses TFT.begin as set to use 0x9486. This works without issue.

I have a case of the Red boards and would love to use them with the Teensy 3.6" if you can reconfigure the library to work with them. I would be willing to send you a Red Board and a Blue Board for free to keep if this would be helpful with debugging. This is the least I can do for all of your help you are providing to us. Very, Very grateful for being at least able to use with the BLue Board.

Teensy 4.1 is the most powerful Arduino compatible microcontroller available today.  Based on the NXP i.MX RT1062 ARM Cortex-M7 running at 600MHz with the ability to be overclocked.   It is formatted into a very compact ‘teensy’ board outline for easy embedding into projects or for use with solderless breadboards.  Perhaps best of all, it is compatible with the popular Arduino IDE programming environment as well as many of the existing Arduino libraries, so it is very easy to get up and running unlike many other advanced microcontrollers that are available.

The Teensy 4.1 modules are exactly the same except the NE version is missing the Ethernet PHY chip as shown here.  This chip provides the interface between the Ethernet controller built into the NXP microprocessor and the physical Ethernet cable.

Some Teensy 4.1 are now being built without this chip due to on-going PHY chip shortages plus a price increase on the part.  If you don’t plan to use wired Ethernet, the NE version is a good option to consider since it is a little less expensive than the standard version and otherwise identical.

The Teensy product line which is focused on being fast , small and Arduino compatible is developed by the company PJRC.  They have a loyal following of designers and advanced hobbyists that create many libraries to take advantage of some of the more advanced features of the Teensy products or to modify Arduino libraries for compatibility.  Many of them also participate in the excellent PJRC forum.  The forum is targeted towards more advanced users and topics.

Just how fast is it?  The chart below shows the Teensy 4.x series compared to some other popular boards using the CoreMark Benchmark test.  Larger numbers = faster performance.

As another example, the classic Mandelbrot set was calculated and displayed using a Mega 2560 which took between 77 and 105 seconds per image.  Calculating the image is very mathematically intensive.  The Mega 2560 was then swapped out for the Teensy 4.1 and it took 1.24 to 1.26 seconds for the same task running the same software on both.

The Cortex-M7 is the first ARM microcontroller to use branch prediction. On the M4 as used on the Teensy 3.2, loops and other code which must branch take three clock cycles. With M7, after a loop has executed a few times, the branch prediction removes that overhead, allowing the branch instruction to run in only a single clock cycle.

Teensyduino automatically allocates your Arduino sketch code into ITCM and all non-malloc memory use is allocated to the fast DTCM, unless you add extra keywords to override the optimized default.

Teensy 4.1’s Cortex-M7 processor includes a floating point unit (FPU) which supports both 64 bit “double” and 32 bit “float”. With M4’s FPU on Teensy 3.5 & 3.6, and also Atmel SAMD51 chips, only 32 bit float is hardware accelerated. Any use of double, double functions like log(), sin(), cos() means slow software implemented math. Teensy 4.1 executes all of these with FPU hardware.

If you need/want all the horsepower but don’t necessarily need all the I/O and peripherals found on the Teensy 4.1, the Teensy 4.0 uses the same microcontroller in a smaller physical footprint that is also a little less expensive.

To program the Teensy using the Arduino IDE, you must first have the IDE installed if it is not already.  If it is installed but not the current version, now is a good time to update to the latest.

When Teensyduino is running which it should do automatically, a small window is opened on the desktop.  This is the Teensy Loader application that handles the actual download to the Teensy board.  Most of the time you can ignore this window as it defaults to Auto Mode which means it will take care of automatically downloading to the Teensy without needing to press the Teensy Program button, but it does need to be running in order to download to the Teensy boards.

If the setup is correct, the software will compile and download to the Teensy.  The onboard LED should start blinking once per second.  Since the board will already have Blink installed when you receive it, you might want to change the timing of the blink to verify the new download was successful.

The Teensy 4.1 operates at 3.3V internally and expects I/O to not exceed 3.3V.  It is not 5V tolerant on any of its pins except for the VIN and VSUB pins which can be used to supply 5V power to the module.

The Teensy 4.1 can be powered one of 3 different ways, but it is important to note that these are mutually exclusive unlike typical Arduino boards.  Internally the module does not provide any power switching between the different power inputs.  In essence, if you hook up two different power inputs such as through the USB cable and also through the VIN pin, those two power sources will be shorted together.

External power of 3.3V can also be applied to the 3.3V pins to power the Teensy in some cases, but this bypasses the on-board regulator which properly handles the power up sequence.  This option is not recommended without doing some research.  Specifically, VBAT needs a 3V power source such as a coin cell before applying power to the 3.3V pins.

The most likely way to run into trouble with power is by having the Teensy normally powered through VIN and then deciding to hookup the USB cable to download new code without disconnecting VIN first.

The USB port on the Teensy 4.1 has significant functionality not available on a normal Arduino.  For most standard applications it should be set to the default “Serial” mode which is how it works with an Arduino.  If you have problems connecting to the Teensy, check this setting.

The button on a Teensy board is not a typical reset button like on an Arduino.   When pressed, the program button causes the Teensy to enter ‘Programming Mode” where it waits for a download over USB.  If the Teensy is connected to the IDE via a USB cable, the last program will automatically be downloaded again and ran.

You didn’t select the Teensy 4.1 because it has a slow CPU, so naturally you are going to notice the CPU speed selection available in the IDE while poking around.

There are two 8-pin SMD footprints on the bottom of the module under the SD card slot.  The user can add chips to these locations to enhance the functionality or they can buy our preassembled and tested Teensy 4.1 Fully Loaded products near the bottom of the page.

These chips come in the WSON package that have the leads tucked under the body and require decent soldering skills to solder on well.  The Teensy 4.1 Fully Loaded product at the bottom of the page has these parts already installed.

These chips come in the WSON package that have the leads tucked under the body and require decent soldering skills to solder on well.  The Teensy 4.1 Fully Loaded product at the bottom of the page has these parts already installed.

Parts are available for adding a physical Ethernet port to the Teensy 4.1.  This is available as either a kit that requires some soldering or as a fully assembled board.

One of the 2×3 male headers in the kit is soldered to the Teensy 4.1 in the location as shown to the right for connecting the ribbon cable.  This part is a little trickier to solder due to tight spacing of small components on the bottom of the board.

Due to the strong processing power available in the Teensy products, they are a popular target for audio projects whether it is playing multiple WAV files simultaneously, synthesizing music or building sound reactive projects.  The Audio Adapter 4.x (Rev D) is designed for the Teensy 4.x product line and supports high quality 16-bit 44.1kHz sample rate (CD quality) audio.

For anyone that wants to attach probes, logic analyzers or jumpers directly to the Teensy 4.1, we have these high quality extended tail gold headers in 1×40 strips.

If the Teensy 4.1 sounds great but the soldering of SMD chips sounds less great, we have the Teensy 4.1 Fully Loaded.  It has either 8MB PSRAM & 16MB/64M-bit Flash memory, 8MB PSRAM & 128MB/1G-bit NAND Flash, 8MB PSRAM & 256MB/2G-bit NAND Flash or 16MB/128M-bit PSRAM chips installed and fully tested.  It also has the pins soldered on and has the header for the optional Ethernet added as well.

If you are looking for Teensy 4.1s that are configured to work with our Prototyping System for Teensy 4.1 or another baseboard that brings the VUSB, Ethernet, USB Host and VBat headers down from the bottom of the Teensy as well as having the VUSB trace cut and diode added to isolate USB and VIN power we have those as well.  Please note that these will not plug into a solderless breadboard due to the additional headers on the bottom of the module.

You can find the link to the full Teensy 4.1 Fully Loaded for Prototyping System information at the bottom of this page or by clicking on the pic above.

The Teensy line of boards are an excellent product that provides high performance and advanced I/O to tackle even the hardest problems which is why they are often found in advanced hobbyist projects as well as low volume production builds.

The PJRC forum provides access to excellent technical advice that is far more advanced than found on the normal Arduino forums.  It is the best place to find information on how to use the advanced features found in the Teensy.  It is not the place to get basic Arduino type questions answered however, which is good as the forum is not cluttered with ‘how do I blink an LED?’ type questions.

The Teensy 4.1 is currently at the top of the heap for performance and I/O capability.  You do need to take care of properly applying power and keeping I/O limited to 3.3V to avoid possible damage to the module.  If you are brand new to Arduino and programming, you might consider getting your feet wet with a standard Arduino clone board or consider the 5V tolerant Teensy boards like the Teensy 3.2 and Teensy 3.5 which are a little more fool-proof.

There are some other Teensy products that may be better suited depending on the application.  The Teensy 4.0 has the same CPU and basic performance, but in a smaller physical package with less I/O, 2MB of FLASH and is less expensive.  The Teensy 3.5 has a similar I/O footprint as the Teensy 4.1 and provides 5V tolerant I/O and it runs at 120MHz which is still way faster than the typical Arduino board.  The Teensy 3.2 is a mature product with the largest installed base and is in a small package format with 5V tolerant I/O and runs at 72MHz.

Hello all, I’m brand new to LVGL (just found out about it today), and I’m excited at it’s capabilities and flexibility. I was wondering what is considered the best MCU to power a ~5", 800x480 display? Has anybody done any bench markings with side by side comparisons?

For my needs, the speediest most responsive UI is the most important aspect of my project’s user experience. I’d like to see smooth animations, smooth full screen text scrolling, opacity, and constant updating of multiple text\label objects. I’m looking for an Arduino compatible MCU that will be responsible for driving a 5" TFT touch screen. All of my IO and peripherals will be controlled by a lower cost, slower MCU (Arduino nano or mini or something similar like a custom board design) and connected by serial to the display’s MCU (similar to how a Nextion display works).

With the recent announcement of the Teensy 4.1 (a Cortex-M7 processor at 600 MHz) Seems like more then enough power for a display. Is it too much power? Would a less expensive MCU be more comparable and would users even see a difference between the two? Would a Teensy 4.1, with all of it’s IO and speed be enough to smoothly drive a display AND manage peripheral devices, foregoing my second peripheral MCU? I’m most familiar with ESP32, SAMD51 and standard Atmel/Arduino boards. So working with the Teensy would be new for me.

The Teensy 4.0 Triple CAN Bus Board with 240x240 IPS LCD And MicroSD is a Teensy 4.0 board with triple CAN Bus connections, two Classical CAN 2.0B, and one CAN FD. It can be powered by an external +12 VDC power supply with reverse voltage protection. Also included isa 240x240 wide-angle IPS TFT LCD display with microSD holder.

The Teensy 4.0 is an Arduino-compatible board with an Arm Cortex-M7 microcontroller running at 600 MHz. The board is compatible with theand the Arduino library. In most cases, code written for another Arduino board works with a minimum of changes on a Teensy. As the name implies, the board is tiny. For example, the current form factor is only about 18 by 36 millimeters. However, do not let the size mislead you; these boards pack a ton of functionality. For example, the new Teensy 4.0 features a megabyte of RAM, two megabytes of Flash, a bevy of I/O options, cryptographic support, a hardware floating-point processor (FPU), and a built-in real-time clock (RTC).

The brain of the MicroMod Teensy Processor is the NXP iMXRT1062 from NXP Semiconductors. This Arm Cortex-M7 core processor is one of the most powerful microprocessors available today. The MicroMod Teensy Processor board takes advantage of the following properties:

Note: We recommend advanced users looking to take full advantage of all of the features of the Teensy Processor use it with the MicroMod ATP (All the Pins) Carrier Board or their own custom Carrier Board. Many of the pins with extra functionality may be tied to a specific use on other Carrier Boards and therefore essentially unavailable for things like extra UARTs, SPI/I2C or Analog In/PWM.

The MicroMod Teensy Processor uses the W25Q128JV-DTR serial flash memory IC from Windbond Electronics. The flash IC features 128mb of memory. For a detailed overview of the IC, refer to the datasheet.

There are two LEDs on the Teensy Processor. The PROG LED indicates when the HalfKay bootloader is enabled and the programming IC is powered. We"ll cover how to enter the bootloader in the Software Setup and Arduino Example sections. The STAT LED is tied to SCK/13 and can be used as a status LED or as a built-in LED. Control it directly by writing to LED_BUILTIN.

The Measure (MEAS) Jumper can be opened to measure how much current the Teensy Processor is pulling from V_USB. It"s is CLOSED by default and ties the USB_VBUS pins to V_USB. Open it by severing the trace and then using a digital multimeter to measure the current draw.

The Teensy Processor is similar to the Teensy 4.0 and 4.1 with a few notable differences. In order to maintain easy interoperability with MicroMod Carrier Boards, not all of the alternate pin functions are defined for the MicroMod Teensy board variant but we have done our best to make the Teensy Processor as versatile as possible with the right Carrier Board. The sections below outline the various signal protocols available on the MicroMod Teensy.

As you may have guessed from our extensive Qwiic System, we love communicating with devices using I2C! The Teensy Processor features four I2C buses. The main I2C bus has dedicated pins connected to MiroMod pads 12 (SDA) and 14 (SCL) (Teensy pins 18 and 19), along with a dedicated interrupt pin connected to MicroMod pad 16 (Teensy pin 29). The primary I2C Bus will almost always be connected to a Qwiic connector on your Carrier Board.

If you need a second I2C bus, the Teensy has SDA1 and SCL1 on MicroMod pads 53 and 51 (Teensy pins 25 and 24). To use this second bus, initialize it by calling Wire1.begin();.

The Teensy Processor is capable of having seven UARTs available. The primary UART is tied to USB_D± (MicroMod pads 3 and 5) for serial communication over USB. This is used for your standard serial upload as well as serial prints in Arduino. The secondary UART is a hardware UART tied to MicroMod pads 19 (RX1) and 17 (TX1) (Teensy pins 0 and 1). The tertiary UART is another hardware UART tied to MicroMod pads 20 (RX2) and 22 (TX2) (Teensy pins 17 and 16). In Arduino, the three UARTs are called as listed below:

One of the unique features of the Teensy is its ability to communicate with CAN devices. The Teensy MicroMod can receive CAN messages but in order to send them properly you will need a separate CAN transceiver. CAN-RX is tied to MicroMod pad 41 (Teensy pin 30) and CAN-TX is tied to MicroMod pad 43 (Teensy pin 31).

The MicroMod Teensy has all 12 general purpose IO pins available on top of 6 dedicated pins for digital, analog and PWM signals. The dedicated pins are just that, and are not shared with any other pin, unlike the general purpose pins which may be shared with other pins. Take note that not all GPIO pins are broken out or in use on every carrier board. Refer to your Carrier Board"s Hookup Guide for more information on pin use.

As experienced users may know, the pins on Teensy development boards are very versatile and can be used for a multitude of purposes. As we noted above, in order to maintain compatibility with the rest of the MicroMod system, not all of these alternate functions are available on the MicroMod Teensy but some pins can be configured for things like Analog Inputs or Pulse Width Modulation. As mentioned before, the best way to interact with these pins is with the ATP Carrier Board.

The default MicroMod Teensy Processor board definition is limited to these extra functionalities along with a few other pins that can technically be used for PWM signals when not in use for other signal protocols. Keep reading to the next section, MicroMod Pinout, for specific information on these pins.

Refer to the datasheet and user manual for a full overview of the iMXRT1062"s capabilities. The complete pin map can be found in the table below or you can refer to the schematic. PJRC has a wealth of knowledge on their forums with regard to the beta testing of the MicroMod Teensy. Here is a specific post that goes into detail about the pin map.

Heads up! The pin table below and schematic both include the Teensy pin associated with each MicroMod pin and this correlation can be used to identify alternate uses for pins on the Teensy Processor but not all of the alternate Teensy functionalities are available for use with the SparkFun Teensy MicroMod board definition. For many of the General Purpose I/O pins and other pins with multiple signal options, refer to your Carrier Board"s Hookup Guide for information on how those pins are configured what they are used for. Not all pins are used on every Carrier Board.

General purpose pins. Any unused processor pins should be assigned to Gx with ADC + PWM capable pins given priority (0, 1, 2, etc.) positions. The intent is to guarantee PWM, ADC and Digital Pin functionality on respective ADC/PWM/Digital pins. Gx pins do not guarantee ADC/PWM function. Alternative use is pins can support a fast read/write 8-bit or 4-bit wide bus.

The overall thickness of the MicroMod Teensy Processor Board is ~3.10mm. The height of the tallest component (NXP iMXRT1062 labeled as "U1" in the board file) on the Processor side is ~1.28mm. The PCB thickness is ~0.80mm. The height of the tallest component (transistor labeled as "Q1" in the board file) is about ~1.02mm.

Creating a good real-time simulation of a music speaker cabinet generally requires an FIR filter with a large number of taps—more than was possible with the Teensy 3.6. In this project article, Brian builds one using the Teensy 4.1 module, making use of its large memory, faster speed and added features.

In my article “Fancy Filtering with the Teensy 3.6” (Circuit Cellar 346, May 2019) [1], I introduced convolution filtering, which can be used for guitar cabinet simulation, among many other things. By using FFT routines, you can convert a time-domain-based convolution filter into one that is implemented in the frequency domain. As I explained in that article, this allows the filtering to be performed much more quickly. For example, the Teensy 3.6 board that I used at the time could easily handle a 512-tap FIR filter in real time, without taxing the MCU too much.

However, for guitar speaker cabinet simulation it turns out that getting a really good simulation generally requires an FIR filter with a much larger number of taps. Although the Teensy 3.6 board’s microcontroller (MCU) had enough “horsepower” to handle a filter with more than 512 taps, there are other complications. The larger the number of taps in the filter, the larger the RAM memory requirements are. When I started using the Teensy 3.6 board, its 256KB of SRAM seemed huge, but it turns out it’s not enough to handle FIR filters (implemented using floating-point FFT methods) a lot larger than 512 taps.

When the Teensy 4.0 board became available, it sported 1MB of SRAM, which would seem to solve the memory problem. It also ran at 600MHz (more than 3 times the speed of the MCU used on the Teensy 3.6), so it looked like execution time might not be an issue. However, another issue seemed to me to be unsolvable.

I had moved on to other projects. But after writing my earlier article on this subject, Frank, the person with whom I had collaborated on that project, remained interested—mostly from the software-defined radio aspect of it. Frank is a ham radio operator. That’s why I only know his first name and call sign (DD4WH). He had come across some code written by Warren Pratt that implemented a uniformly partitioned, fast-convolution algorithm. This is done in the frequency domain using FFT (fast Fourier transform) and inverse FFT (iFFT) operations (as I did in my earlier article [1]).

The 128-point partition size is not a random choice. The Teensy Audio Library deals exclusively with 128-sample blocks. That is, it buffers the incoming audio samples from the NXP Semiconductor SGTL5000’s ADC into 128-sample blocks, and uses DMA to move these blocks among the other buffers used by the various audio library functions. To provide steady, uninterrupted sound output, any Teensy Audio Library routine must accept a 128-sample block every 2.9ms, and output a processed 128-sample block at the same rate.

The idea of the uniformly partitioned convolution filter previously described sounds easy, and I implemented it in less than 100 lines of code in my library routine. However, that small size was largely due to my extensive use of CMSIS (Common Microcontroller Software Interface Standard) DSP routines, and it wasn’t easy to come up with that code. Frank spent a lot of time studying Warren Pratt’s code to adapt it to a form that would compile with the Teensy’s Arduino-based compiler. I played a small role in this. My contribution was in porting his code into a C++ Teensy Audio Library class, optimizing it a bit and performing some testing.

The Arm CMSIS DSP routines perform many different matrix-style operations, such as complex FFT, iFFT and time-domain convolution routines. These routines make heavy use of the Arm DSP-like instructions that are available on the NXP (formerly Freescale) MIMXRT1062 Cortex M7 MCU used on the Teensy board. The FFT and iFFT routines contain large tables (related to the size of the FFT you are performing) that are used as look-up tables to speed up the FFT operation. I believe these tables are used to eliminate the bit-twiddling operation (swapping all bits MSB to LSB) that is a part of the FFT routine. It would be impossible to independently write code for such routines that ran as fast as the CMSIS ones do!

Every 2.9ms, a 128-sample block of 16-bit audio data (for both Left and Right channels) is made available by the Teensy Audio Library. Since the CMSIS complex FFT routine expects both I (in-phase) and Q (quadrature) values, the Left and Right channels’ samples are used for I and Q, respectively, and are processed independently. For this project, only a monaural guitar signal is available, so the Q channel processing is basically wasted.

I suspect that substituting a real FFT for a complex one would be fine for a monaural signal, but any speed advantages would be negated, because, for some unknown reason, the CMSIS real FFT needs twice as much array memory space as a complex one. For this project, the Cortex M7 MCU is more than fast enough, but available SRAM memory limits the Filter Mask to about 22,000 taps, so this would not be a good trade-off.

The 256-sample audio signal block is then converted into the frequency domain by a complex 256-point FFT. So, we now have both the Filter Mask and the incoming audio signal in the frequency domain. These frequency domain data blocks are stored in a circular buffer in memory, which implements a frequency domain delay line. The convolution process, if performed in the time domain, is a math-intensive process. Its execution time is linearly related to the number of taps in the Filter Mask. Even the very fast Cortex M7 MCU on the Teensy 4.1 board couldn’t handle time domain convolutions (in real time) using Filter Masks with the number of taps in the 2,000+ range. However, in the frequency domain, convolution is reduced to multiplication, and the execution time is now proportional to the log of the number of Filter Mask taps. The Teensy 4.1 probably has enough processing “horsepower” to handle Filter Masks of >50,000 taps. However, the Teensy 4.1 RAM memory is not large enough to accommodate the large arrays needed for such a large number of FIR filter taps.

Figure 2a: I patched my program to pass along the incoming 128-sample audio blocks to the SGTL5000 DAC with the convolution filter routine patched out. The latency here was 6.4ms. This is the minimum latency you could ever achieve, using the Teensy Audio Library with no processing blocks added.

In the Teensy Audio Library, the ADC signals are accumulated into a 128-sample buffer before they are processed. This results in a 2.9ms delay at 44,100 sample rate.

These files must be added to the folder containing the Teensy Audio Library. This folder will be located under whatever folder you have installed the Arduino/Teensyduino IDE. The path is as follows:

Please refer to the schematic shown in Figure 5. The Teensy 4.1 module used for this project contains the NXP (formerly Freescale) MIMXRT1062 Arm Cortex M7 MCU running at 600MHz. This MCU contains 1MB of RAM storage, which is necessary to handle the long impulse files that I mentioned earlier. Unlike the Teensy 4.0 module used in my earlier project article, the Teensy 4.1 contains extra on-board features, some of which are used in this project:

To maximize the size of the impulse files that the project would handle, I mounted one 8MB PSRAM chip on the board. Unfortunately, this QSPI PSRAM memory is not fast enough to be used for the various arrays needed by the real-time convolution routines. Accordingly, the size of the impulse files can’t become so large that they would need this PSRAM. However, I do use the PSRAM to store the files that are loaded in from the SD card, as well as for temporary arrays used when the integer values from the SD card are converted to floating-point for use by the convolution routine.

I use the SD card socket on the Teensy 4.1 to store the impulse files. It is connected to the MCU via a high speed SDIO port. The Teensy Audio Adapter [4] also contains an SD card socket, but it is interfaced via SPI, so it is a lot slower. Using the SDIO-connected SD card socket on the Teensy 4.1, the amount of time it takes to load a 22,500-sample impulse file (the maximum size this project will handle) is about 150ms. This is as fast as you can stomp on the switch to advance from one impulse to the next, so there is no noticeable delay.

The power for the Teensy 4.1 can be provided either by plugging a USB 5V adapter into the micro-USB socket on the Teensy 4.1 module, or supplying 5V to the VIN pin. I supply 5V using a USB 5V adapter. This 5V also feeds out through the Teensy’s VIN pin and that supplies 5V to the FET preamplifier through an LC filter.

There is a Texas Instruments (TI) TLV75733 LDO regulator on the Teensy 4.1. It provides a regulated 3.3V for the MIMXRT1062 MCU, and makes this 3.3V power available for external circuitry, using the “3.3V” pin. The Teensy Audio Adapter board is powered by this 3.3V supply.

In this project, I make no use of the dedicated DSP, though I have used it successfully in earlier projects. The SGTL5000 datasheet doesn’t specifically mention how many bits of resolution the codec supports, but in any case, the Teensy Audio Library supports only 16-bits.

Unfortunately, I found that the noise level that I got using these two devices was more than I preferred. I was using a protoboard with reasonably sized ground and VCC tracks, and did the hand-wiring as carefully as I could. I guess that there was too much noise on the ground bus, or picked up from the MIMXRT1062, but I wasn’t able to reduce it enough for my liking. So, out came my solder sucker, and the ADC/DAC circuitry was replaced by the Teensy Audio Adapter board.

Although the Teensy Audio Adapter board contains most of the mixed-signal circuitry needed for the project, there is one issue. The Line Inputs have enough gain to handle a guitar’s signal properly; in fact, I set the input amplifier for a full-scale amplitude of 560mV. (Its most sensitive setting is 240mV.) However, the Line In input impedance is only 29kΩ. Most guitars, apart from those with an internal pre-amplifier, have a high source impedance. Their tone will be seriously degraded if the input impedance of the amplifier they are plugged into is less than 100kΩ. Commercial guitar amplifiers have an input impedance of 500kΩ to 1MΩ.

I was planning on using the left channel Line Out for the output signal. As I was building/programing the unit, I simply had been plugging headphones into the Teensy Audio Adapter’s headphone output. This had provided an acceptable signal-to-noise ratio. However, when I tried to feed the Line Out signal into my studio mixer, I found significantly more noise. I attributed the difference between the two outputs to ground noise introduced into the Line Output signal.

I used a common 2.8” SPI-based color TFT touchscreen display for the unit. Initially I didn’t plan on having any graphics requirements, but I wanted to be able to display the impulse name in a medium-sized font, and also display an impulse number in a large (72pt) font that could be seen at a distance. The touchscreen display works fine for this, and is only slightly more expensive than common alphanumeric LCD displays, which are not particularly readable in the dark or at any distance.

I wanted to have a descriptive impulse name displayed on the TFT screen. However, the SD card library that I have used in the past could handle only the old DOS-standard 8.3 filenames. It wouldn’t be much use to display only the 8 characters that made up the primary file name. Therefore, I wired up the touchscreen controller and added a feature to the program that would allow the user to enter a descriptive name for each loaded impulse file, using the touchscreen for initial data entry. This descriptive name would be linked to the impulse file name, and stored in the MCU’s EEPROM space (which is emulated in flash memory).

Just after I finished doing this, I read on the PJRC (Teensy) Forum that the latest beta version of the Teensyduino Arduino add-in contained support for long filenames, as part of the new SD card library. Incorporating that feature seemed like a much better solution, since one could merely rename each impulse file with a longer file name that was more descriptive. That eliminated the need to store descriptive impulse names in EEPROM and the use of the touchscreen to enter those names.

I realized, after looking at the mostly empty TFT screen (just an impulse name and a large font impulse #), that it would be interesting to display a picture of the guitar amplifier (or speaker cabinet) that was being simulated. It’s pretty easy to find such images on the Internet, snip them off the screen and format them in a picture editor.

My Windows 10 snipper program saves its screen captures in jpg or png format. I bring this file into Corel PhotoPaint, and resample it so that it is no larger than 250×184 pixels—the space that I have allocated for the image on the TFT screen. Then I export it in bmp format, giving it the same primary filename as the impulse file that it represents (and a .bmp extension). Luckily, a routine in the Teensy library takes bmp files from an SD card and displays them on the same TFT display that I use in this project. I load these image files on the same SD card that the impulse files are stored on. These images require about 200ms to load/display.

To allow me to quickly sequence through the various impulse files (by repeatedly pressing the footswitch on the unit), I delay the display of this image for a few seconds. So, if you keep pressing the footswitch, each impulse will be loaded almost immediately (150ms delay maximum), and will not be slowed down by the image load/display time, since this image won’t show up until a few seconds after you have settled upon a particular impulse file. The unit’s display with a Fender amplifier is shown in Figure 6.

I should mention that the Teensy Audio Adapter is currently available in two versions, Rev. C and Rev. D. Originally, the C revision module was designed to piggy-back on top of the Teensy 3.2 module; that is, the pins matched the pinout of the Teensy 3.2. The Teensy 4.0/4.1 MCU modules have a somewhat similar pinout to that of the Teensy 3.2, but the I2S pins are different. This explains the two versions of the Teensy Adapter. Rev. C matches the pinout of the Teensy 3.2, and Rev. D matches the Teensy 4.0/4.1.

I don’t mount the Teensy Audio Adapter on top of the Teensy MCU module, because it makes it too bulky vertically. Since I am hand-wiring the two modules together, I’ve kept only Rev. C modules, and use them with whatever Teensy module I am using for the project. However, if you are using a Rev. C board with the much faster Teensy 4.0/4.1, you have to place a 100Ω resistor in series with the MCLK line, as shown in the Figure 5 schematic. Table 1 shows the wiring for each of the two revisions (sourced from the PJRC Teensy website).

The last thing I’ll mention about the SGTL5000 CODEC contained on the Teensy Audio Adapter, is that it requires an I2C connection to receive its configuration commands from the MCU. You won’t see the normal pull-up resistors on the SCL and SDA lines in the schematic, since there are 2.2kΩ resistors on the Teensy Audio Adapter module, itself. Figure 7 is a photo of the circuit board, and Figure 6 shows the completed unit in its enclosure.

I have built many music/audio-related projects with various members of the Teensy MCU family of boards. Apart from the powerful MCU that can now be found on the Teensy 4.x modules, the huge number of Arduino libraries that work with these modules is a major consideration. Also, the easy-to-use Teensy Audio Library contains the most comprehensive collection of audio functions that I have found among the four MCU product lines that I routinely use.

That said, I am still amazed that it is possible to do a 22,000-point FIR filter routine in real time on an Arm MCU with a latency in the 10-15ms range. This can be attributed to the fact that the routine is performed in the frequency domain, as mentioned earlier. However, the elegant coding found in the CMSIS DSP routines, together with the high usage of DMA data transfers in the Teensy Audio Library, also contribute to this high performance.

Although I designed this unit to perform only guitar-cabinet simulations, the Teensy MCU is nowhere near fully utilized with that task. The FFT-convolution routine, which is performed for each audio block (occurring every 2.9ms), takes a bit less than 1ms to execute, so about 60% of MCU capacity is free. Using other blocks in the Teensy Audio Library, it would be possible to add effects such as tremolo, reverb, chorus or even a guitar tuner (using the notefreq block).

The firmware for this project can be found on the Circuit Cellar’s article code and files webpage. Note that I used Arduino version 1.8.13 and Teensyduino Beta 1.54. These newest versions are needed to compile the code. My uniformly partitioned convolution filter library is available with the rest of the firmware on the article code and files webpage. It must be added to the Teensy Library as described earlier in the article.

The latest itty bitty powerhouse fromPJRC has been released this week. The teensy line of dev boards has hit 4.0! They have managed to keep a tiny footprint, like you’ve come to expect from the Teensy. They’ve gained some serious horsepower thanks to the ARM Cortex-M7 running running at 600Mhz. Check out these CoreMark scores compared to the previous versions.

I personally have used Teensy for a few years because it was one of the first boards I had easy access to that would do full USB HID emulation, meaning that if I programmed it as a keyboard or mouse, any computer would see it as one without installing additional drivers. That was very useful for the devices I was building at the time, though admittedly I never really needed a ton of processing power.

Polyphonic audio synthesis using the Teensy Audio Library can require considerable processing power, especially with many modulated waveforms and complex effects.  Teensy 4.0 will allow these synth projects to use more advanced synthesis models for more simultaneous voices.

Only fairly simple machine learning models can run on today’s mainstream microcontrollers.  While powerful models will still require single board computers or dedicated hardware, Teensy 4.0 will open up the possibility to run moderately complex models in real time in the small low-power Teensy form factor, for tasks like gesture recognition.

Real time audio analysis, whether using machine learning or traditional techniques like Fourier Transform and correlation & convolution, will also greatly benefit from Teensy 4.0’s performance, which can be easily embedded into costumes or props.

High-res color TFT graphical displays often tax today’s microcontrollers. In addition a fast CPU and larger memory for rendering, Teensy 4.0 includes a pixel pipeline for hardware assisted alpha blending, color space transform, and other graphical operations.  You can add a TFT display and build a user interface with little impact to other real-time using Teensy 4.0.

FPGA-based drop-in replacement for Arduino UNO R3; offers faster clock rates and overall applications speed, higher-performance through vendor-supplied hardware-specific library functions utilizing FPGA; half of FPGA"s space remains available for further customizations including ones written by end user

Arduino compatible board designed specifically for RF mesh network experiments. It features 10 I/Os, a 10-pin ISP programming connector, a connector for a standard LCD display (in 4 bit mode) and a connector for a 2.4 GHz RF module.

Teensy++ 2.0 microcontrollerA slightly more powerful version of the Teensy 2.0. It has 46 I/O pins; 8 KB RAM; 128 KB of flash; 10-bit ADC; UART, SPI, I²C, I²S, Touch and other I/O capability.

Same form factor as Teensy 3.0. Based on the Freescale MK20DX256VLH7 CPU. It has 34 I/O pins; 64 KB RAM; 256 KB of flash; 2x16-bit ADC; 12-bit DAC; 3xUARTs, SPI, 2xI²C, I²S, CAN bus, Touch and other I/O capability. All digital pins are 5 volt tolerant. Teensy 3.2 adds a more powerful 3.3 volt regulator, with the ability to directly power ESP8266 Wi-Fi, WIZ820io Ethernet and other power-hungry 3.3 V add-on boards.

Form factor compatible with Teensy 3.0/3.1/3.2, with more pins directly available. Based on the NXP/Freescale MK64FX512VMD12 CPU. It has 58 I/O pins; 256 KB RAM; 512 KB of flash; 27 analog inputs on 2x16-bit ADC; 2x12-bit DAC; 17 timers (20 PWM outputs); 6xUARTs, 3xSPI, 3xI²C, 2xI²S, CAN bus, On-board Micro SD Card, Touch and other I/O capability. All digital pins are 5 volt tolerant.

Form factor compatible with Teensy 3.0/3.1/3.2, with more pins directly available. Based on the NXP/Freescale MK66FX1M0VMD18 CPU. It has 58 I/O pins; 256 KB RAM; 1024 KB of flash; 25 analog inputs on 2x16-bit ADC; 2x12-bit DAC; 19 timers (22 PWM outputs); 6xUARTs, 3xSPI, 3xI²C, 2xI²S, CAN bus, 2nd USB (Host mode supported); On-board Micro SD Card, Touch and other I/O capability. I/O pins are not 5 V tolerant.

The teensy 4.0 has an NXP i.MXRT1062 ARM Cortex-M7 at 600 MHz with 1024 KB RAM (512 KB is tightly coupled), 2048 KB flash (64K reserved for recovery & EEPROM emulation), two USB ports, both 480 Mbit/s, three CAN bus channels (one with CAN FD), two I²S Digital Audio, 1 S/PDIF Digital Audio, 1 SDIO (4 bit) native SD, SPI, all with 16 word FIFO, 3 I²C, all with 4 byte FIFO, 7 serial, all with 4 byte FIFO, 32 general purpose DMA channels, 31 PWM pins, 40 digital pins, all interrupt capable, 14 analog pins, 2 ADCs on chip, Cryptographic Acceleration, Random Number Generator, Pixel Processing Pipeline, Peripheral cross triggering and more in a tiny 1.4 by 0.7 inch teensy 3.0/3.1/3.2 form factor

A lower cost version of the Teensy 3.1/3.2. It has 27 I/O pins; 64 KB of flash; 12-bit DAC; 3xUARTs, 2xSPI, 2xI²C, I²S, Touch and other I/O capability. I/O pins are not 5 V tolerant. No FIFOs on serial 1 and serial2. Fewer hardware timers.

Pin compatible with Arduino but uses the ethernet enabled PIC microcontroller to connect to the Internet. Allows sending of email, display of javascript enabled webpages, and remote web based access and control from around the world.

The EVAL-ADICUP3029 is an Arduino Uno form factor compatible platform based on the ultra low power ADuCM3029 32-bit ARM Cortex™-M3 microcontroller. The platform is designed to be a development and prototyping vehicle to get design ideas from concept to production with a minimal risk and faster time to market. The EVAL-ADICUP3029 is designed for IOT (Internet of Things) applications in mind, and therefore comes with on board Wi-Fi and Bluetooth 5.0 capabilities. A free version of CrossCore Embedded Studios (an Eclipse-based Analog Devices Interactive Development Environment) is supplied to the designer for debugging and application development. Add-on hardware modules, MCU drivers and software application examples help form a complete ecosystem that designers can leverage into their final product.