teensy fast tft display quotation

I sorry, the microSD with the ILI9341 nope at this moment. But with FT813 + gameduino library + SdFat_beta, work it surprisingly well in teensy 4. Later I share the library; It is work in process.

I have been working with a similar library: the ILI9488_t3. Until a few minutes ago, the XPT2046 touch chip did not work on the Teensy-4. The key is the file HW_ARM_defines.h inside of the path: URTouch\hardware\arm

I have a 128x128 ST7735 display that I"m driving with a Seeeduino Xiao (SAMD21). I"d like to draw static fuzz, of the type found on old televisions - i.e. random pixels or squares of black and white.

(EDIT: And going even further, I"m open to using a board with a different TFT driver if it helps, provided similar pricing and availability and drivers for the samd21.)

Another technique I plan to try next is write a bitmap image of pre-rendered static to the screen (since it seems to be faster than doing random() + drawing a pixel 128x128 times), then just use every spare cycle to write a random pixel. I"m guessing it will look a bit too static in appearance, but I"ll give it a try.

Due to the number of pixels, it would be a good idea to call an update for every two pixels. With a teensy 4 @ 600 Mhz, I have used the ST7735_t3 library.

If yours looks good in real time, then either the "_t3" library or the teensy itself is the difference. I came across the library but haven"t tried it yet since I assumed it wouldn"t work with a SAMD21 seeeduino xiao. But perhaps I should try.

I created a sketch for the Uno with a nameless 320x240 TFT display shield, ILI9341 controller, using the tft.writePixel (x,y,COLOR) instruction, combined with the random function.

Actually I would like on my 320240 TFT bigger grains (22 blocks of pixels) creating the impression of random (pseudo)noise. That would imply the use of small bitmaps or some complicated stuff remembering previous positions of displayed pixels; I am not sure whether my Uno is fast enough to create a realistic effect. Any suggestion?

The speed definitely seems to be an issue. The first sketch on #10 is simply too static looking. i.e. not enough pixels are changing fast enough and it looks more like a static image than an animation.

I think for now I"ll pull the plug on the static snow noise. I"m creating a series of animated simple "tv shows" and wanted to show this static for a moment between changing channels, but it"s proving to be more trouble than it"s worth. Either that or I"ll see about switching to a faster processor.

The cell phone camera is not synchronized to the speed with which the pixels appear on the screen, this generates a sloping cross band and an apparent increase in speed, which do not really exist in the TFT. Keep in mind that 128x128 = 16,384 pixels are drawn in each step

It is possible to "overclock" the ST7735 so that faster screen updates are then possible. The data sheet gives a 16MHz maximum but they work at 27MHz reliably and often at 40MHz.

The ESP32 manages 96fps when every pixel of the 128x128 display is updated per frame, not bad for a $5 processor board. This is at a 26.66MHz SPI clock, so the theoretical maximum is 102fps with no looping delays. This is clearly faster than an old TV frame rate so delays could be added, other code run or a lower SPI clock rate used.

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.

Hi guys, over the past few tutorials, we have been discussing TFT displays, how to connect and use them in Arduino projects, especially the 1.8″ Colored TFT display. In a similar way, we will look at how to use the 1.44″ TFT Display (ILI9163C) with the Arduino.

The ILI9163C based 1.44″ colored TFT Display, is a SPI protocol based display with a resolution of 128 x 128 pixels. It’s capable of displaying up to 262,000 different colors. The module can be said to be a sibling to the 1.8″ TFT display, except for the fact that it is much faster and has a better, overall cost to performance ratio when compared with the 1.8″ TFT display. Some of the features of the display are listed below;

TheTFT Display, as earlier stated, communicates with the microcontroller over SPI, thus to use it, we need to connect it to the SPI pins of the Arduino as shown in the schematics below.

Please note that the version of the display used for this tutorial is not available on fritzing which is the software used for the schematics, so follow the pin connection list below to further understand how each pin of the TFT display should be connected to the Arduino.

When connecting the display, ensure that has a voltage regulator (shown in the image below) before connecting it directly to the 5v logic level of the Arduino. This is because the display could be destroyed if the version of the display you have does not have the regulator.

In order to allow the Arduino to work with the display, we need two Arduino libraries; the sumotoy TFT ILI9163C Arduino library which can be downloaded from this link and the popular Adafruit GFX Arduino library which we have used extensively in several tutorials. Download these libraries and install them in the Arduino IDE.

For today’s tutorial, we will be using the bigtest example which is one of the example codes that comes with the sumotoy ILI9163C Arduino library to show how to use the TFT display.

The example can be opened by going to File–>Examples–>TFT_ILI9163c–>bigtest as shown in the image below. It should be noted that this will only be available after the sumotoy library has been installed.

Next, an object of the ILI9163c library named “display” was created with CS and DC parameter as inputs but due to the kind of display being used, we need to include the pin of the Arduino to which the A0 pin of the TFT display is connected which is D8.

With this done, we move to the void setup() function. Under this function, we issue the commands that initialize the display then create a time variable updated by millis, after which we issue a command to clear the screen and display some random text on it.

Some of the functions which perform actions ranging from displaying fastlines, drawing rectangles etc are then called with a delay after each function so the text or graphics stays long enough on the screen to be visible.

Up next is the void loop function. The void loop function also calls some of the same functions called under the void setup() function to display circles, rectangles etc including the testline function which is essentially used to test the screen.

With the libraries installed, open an instance of the Arduino IDE, open the examples as described initially, don’t forget to make the A0 pin (D8) correction to the code then upload to the Arduino board. You should see different kind of text and graphics being displayed on the screen. I captured the screen in action and its shown in the image below.

That’s it for this tutorial guys, what interesting thing are you going to build with this display? Let’s get the conversation started. Feel free to reach me via the comment section if you have any questions about the tutorial.

In this Arduino touch screen tutorial we will learn how to use TFT LCD Touch Screen with Arduino. You can watch the following video or read the written tutorial below.

As an example I am using a 3.2” TFT Touch Screen in a combination with a TFT LCD Arduino Mega Shield. We need a shield because the TFT Touch screen works at 3.3V and the Arduino Mega outputs are 5 V. For the first example I have the HC-SR04 ultrasonic sensor, then for the second example an RGB LED with three resistors and a push button for the game example. Also I had to make a custom made pin header like this, by soldering pin headers and bend on of them so I could insert them in between the Arduino Board and the TFT Shield.

Here’s the circuit schematic. We will use the GND pin, the digital pins from 8 to 13, as well as the pin number 14. As the 5V pins are already used by the TFT Screen I will use the pin number 13 as VCC, by setting it right away high in the setup section of code.

I will use the UTFT and URTouch libraries made by Henning Karlsen. Here I would like to say thanks to him for the incredible work he has done. The libraries enable really easy use of the TFT Screens, and they work with many different TFT screens sizes, shields and controllers. You can download these libraries from his website, RinkyDinkElectronics.com and also find a lot of demo examples and detailed documentation of how to use them.

After we include the libraries we need to create UTFT and URTouch objects. The parameters of these objects depends on the model of the TFT Screen and Shield and these details can be also found in the documentation of the libraries.

So now I will explain how we can make the home screen of the program. With the setBackColor() function we need to set the background color of the text, black one in our case. Then we need to set the color to white, set the big font and using the print() function, we will print the string “Arduino TFT Tutorial” at the center of the screen and 10 pixels  down the Y – Axis of the screen. Next we will set the color to red and draw the red line below the text. After that we need to set the color back to white, and print the two other strings, “by HowToMechatronics.com” using the small font and “Select Example” using the big font.

I have two different noise sources, one I assume is from the power supply but it is very low. I have a 2nd issue with a lot more noise (hum/buzz, video with noise below) coming from a TFT display connected via SPI. This is not my area and wanted to see if anyone has run into this before. I thought it was the backlight but its the chipset 3.3V that seems to be the cause it. I"m using the Teensy 4.0x audio hat but I had to solder jumpers from it to a breadboard to test. Removing the 5V and GND for the backlight does not change anything, as soon as the 3.3V is removed the noise stops, backlight on with no 3.3V chipset connected, no noise. Not sure how to go about filtering this? I added some extra caps on the 3.3V output from the teensy, no change. Tried driving with a separate 3.3V supply, no change, separate 3.3 volt with caps no change. Powered with a bench top regulated power supply , no change. A 2nd switch mode 5V power I had lying around did not help either. I have seen some PT8211 examples using output drivers, but I assume that will just boost the noise. It"s possible its noise from the breadboard, I gave everything the wiggle test but made no difference. I tried a 2nd 4.1 and a second brand new display, no change. Note, I have the trace cut so I can use the USB with the bench supply, disconnecting USB does not change anything. Open to any advice.

After creating an Internet connected digital clock using the Adafruit RA8875 driving an Adafruit seven inch LCD display (Figure 1), my thoughts turned to making a different model that didn’t use a slave Arduino Nano to drive the LCD display. (Refer to my previous article

My desire was to include several additional features as well, which would require more program space in the microcontroller that drives the LCD display. This new program would also make use of the LCD touch screen to allow a user to select different features of the device.

Using this design, I wrote a lengthy program that included several additional features besides a digital clock: the ability to set an alarm; a countdown timer for uses like monitoring an exercise program; a weather display to provide brief conditions at 10 different cities; a real time stock market report that gives the changing prices for a selection of stocks; and lastly (just for fun), a Mandelbrot fractal generator to produce those wonderful images.

After having built this project with the single Arduino MKR Wi-Fi 1010, I was unhappy with it. Yes, that’s correct, I didn’t like it. The goal of having only one microcontroller in the project was achieved but, in my opinion, it was a mistake. There is something to be said for using a separate microcontroller for Internet connectivity and another one to drive the RA8875 and LCD display.

The microcontroller driving the LCD display doesn’t have to deal with the relatively slow Internet retrieval. Receiving data from the Internet takes some time; at least a fraction of a second and sometimes longer than a second or two. With the digital clock needing to be updated once a second, this can be a problem.

There was also another option I wanted to add: an SD card interface to allow me to store and display images on the LCD similar to a photo frame. An SD card interface utilizes the SPI library which is also used to drive the Adafruit RA8875. With Adafruit’s warning about needing to tri-state at least one SPI pin when sharing the SPI interface, a better solution would be a microcontroller with at least two SPI interfaces.

The Teensy 3.5 microcontroller looked like a good choice since it has three SPI interfaces, with one used by the built-in microSD card socket. It also has 512k Flash memory, 120 MHz clock speed, and is compatible with the RA8875 driving the LCD. The Arduino MKR Wi-Fi 1010 could still be used for the Internet connectivity, but an ESP32 has a faster clock speed and is one third the cost.

Instead of having the ESP32 sending updated information to the Teensy 3.5 on a regular schedule, the Teensy 3.5 sends requests for specific data to the ESP32. The ESP32 waits for these requests and when one arrives, it fetches the information from the Internet and returns it to the Teensy in a concise data string.

It’s similar to a simple client-server architecture except the two microcontrollers are connected by their serial ports running at 38,400 baud. Serial3 on the Teensy 3.5 is connected to Serial2 on the ESP32 (Figure 4).

When one of these request strings is received, the ESP32 sends its request through the Internet for the appropriate data. When the data is received, it’s parsed and then sent to the Teensy 3.5 as a concise string, which is then parsed by the Teensy to retrieve the data it requested.

While this might seem a little convoluted, it leaves the ESP32 waiting for the response from the Internet while the Teensy program can continue and update the clock display every second with time to spare. The ESP32 also continuously checks that it has Internet connectivity from the wireless router it’s using. If it loses its connection, it goes into a loop to reconnect.

When the Teensy 3.5 sends a radio string, the ESP32 connects to the current radio station and then enters an endless loop to read the continuous stream of the digitized radio signal sent from the Internet.

At this point, the ESP32 can’t read any requests sent from the Teensy 3.5 since it’s locked in the tight loop to read the radio stream. The only way to break out of the loop is through an external interrupt request.

The Teensy pin 14 is tied to the ESP32 pin 13, and pin 17 is tied to 14. You only need to go from a HIGH to a LOW state on pin 14 or 17 of the Teensy 3.5 for a few milliseconds to initiate an interrupt on the ESP32:

When you try to download a program into the ESP32, pin 12 will be held HIGH by the Teensy 3.5 in its default state unless you remove it from its socket on the PCB. With pin 12 held HIGH, the ESP32 will not be able to receive a download.

A flowchart for the ESP32 program is shown in Figure 5 and the Teensy 3.5 program in Figure 6. The bulk of the software resides in the Teensy 3.5 — about 2,000 total lines, including blanks and comments. However, that only uses 14% of the program space available.

The vast majority of the Teensy program code deals with writing to the LCD screen and reacting to the touch screen. Moving from graphic to text mode has a lot of overhead. After declaring text mode, you must set the size, set the color, place the cursor where you want to write the text, and then finally write the text from a character array.

The software for both the Teensy 3.5 and ESP32 can be found in the download section for this article. Both programs contain several comments and Serial.print statements to help with understanding and debugging.

The Teensy 3.5 program operates in eight different modes. For example, Mode 0 displays the default time, temperature, humidity, and weather screen, while Mode 1 allows you to set and display a timer. A description of what each mode does follows.

Mode 0 is the default mode and does a lot of additional things besides displaying the time in large numbers at the top of the LCD display. One of the little tricks in this program is to only draw one of the large numbers if it changes. If we re-draw every number, it takes too long, and the result is a noticeable flicker in the time display. During seconds 0 through 3, we do specific things. Otherwise, we just wait for the next second to occur and then redraw the time:

If the LCD screen is touched while in Mode 0, it will display a simple menu screen allowing the mode to be changed. Touching the LCD screen or an Exit button when in one of the other modes will return you to Mode 0.

Mode 1 allows you to set a timer and then display it. This can be used to time an activity like an exercise program, for example. The set time counts down using the same style large numbers for the normal time display in Mode 0. At the end of the countdown, the alarm line is toggled and the radio turned on. A keyboard is displayed for entry, along with buttons to start the timer or exit.

The weather at 10 different chosen locations is displayed. The format is the same as the local weather display in Mode 0. The screen fills with the first five locations and then clears and displays the second five. The display hesitates between drawing each brief weather condition as a request is made to the ESP32 for each location, and then waits until the ESP32 returns the weather data.

Setting this mode displays a series of bitmap images that are stored on a microSD card. The Teensy 3.5 has a slot for the microSD card on the end opposite of the USB connector. These bitmap images can be any size that doesn’t exceed the LCD screen size. I purposefully made mine exactly 800x480 pixels. File names need to be restricted to eight characters and adhere to the 8.3 file naming system.

This mode does something similar to Mode 2, except it displays 10 different stock quotes in real time. The stocks were selected and their symbols added to the ESP32 program.

The number of options this site has for requesting data is almost overwhelming. I chose something simple, and although it sends a compact format, there is still a lot of information returned. I only extract the current price, but there is a lot more potential here. The program loops through the 10 chosen stocks and displays the current price. It then clears the LCD and repeats the display.

This PCB mounts the Teensy 3.5 and ESP32 along with a few other parts. In addition, it also has connectors to five other small breakout boards. These are the: RA8875 LCD driver; BME280 temperature and humidity sensor; DS3231 real time clock (RTC); VS1053 MP3 decoder; and the PAM8403 audio amplifier. The PCB pads for the ESP32 have been doubled up on one side allowing the use of an ESP32 with pin spacing across the board of either 0.9 or 1.0 inches wide.

Pins 2 and 4 on the Teensy 3.5 have been brought out to drive an NPN transistor. One of these can be used to drive an optional speaker for the clock alarm or timer and the other is a spare. I also elected to turn the radio on for the alarm or timer ending. Additional unused pads of both microcontrollers were also brought out on the PCB for optional future use.

There are places to mount three LEDs: one from the Teensy connected to pin 33; and two from the ESP32 connected to pins 2 and 4. These can be used to denote a good Internet connect or other testing or debugging functions.

The RA8875 LCD driver board is also a tight fit. There is a hole for a 4-40 machine screw on the PCB near pin 1 of the Teensy 3.5; a single stand-off was used here to mount the RA8875 driver board under the main PCB. Unfortunately, the Adafruit RA8875 board uses 2-56 size mounting holes, so a small printed tab with 2-56 and 4-40 holes was 3D printed to connect the RA8875 board to the 4-40 stand-off beneath the main PCB. This is illustrated in Figure 18.

For the project box itself, I designed and used my 3D printer to produce the custom design. Sketchup files along with object files are included in the download material. Also included are a back cover, the tabs for mounting the LCD display, the knob for the audio amplifier, and the tab to connect the RA8875 to the stand-off.

Care needs to be taken to not press down on the LCD display too hard as the touch panel may register a continual touch, making reading it impossible. In retrospect, this box should have been made larger, allowing for an easier fit of the components. The two inch speakers just fit; anything larger will require a larger project box.

A skilled builder could eliminate the PCB and use a breadboard with solder pads as well as a standard project box, but it will be a challenge — especially the mounting of the LCD display.

In reviewing the two programs that run this project, a lot more time could be spent on giving them more polish. No doubt programmers with more skill and artistic talent than I have could improve the overall appearance of the individual screens. The Internet radio portion of the code could also use some improvement, like displaying the radio station.

Given the program size available on both the ESP32 and Teensy 3.5, I suspect most of the ideas mentioned above could be programmed into this project without any hardware changes.

Had access to logic analyzer, and also found out what other sources have documented, that sending each byte (8 bits) has an extra 1 bit idle time overhead on the bus when DMA is not used (which is not possible to be used in this update method), meaning that overall throughput is then a factor of 8/9 less, translating to theoretical maximum of 59.26Mbit/sec. In practice I find that the maximum I"m able to achieve is around 50Mbit/sec. The difference seems to be caused by that whenever a new display command is sent, there"s an around one byte long stall to wait for the SPI FIFO to flush. Not too bad though, simpler games run well at 60fps progressive, and in the more complex ones the worst case performance was in Sonic the Hedgehog, which updated at 74fps interlaced at worst, i.e. the content updates at 60fps, where ~14 frames per second are progressive, and ~46 frames per second revert to interlaced.

The Teensy 4.1 is the newest iteration of the astoundingly popular development platform that features an ARM Cortex-M7 processor at 600MHz, with a NXP iMXRT1062 chip, four times larger flash memory than the 4.0, and two new locations to optionally add more memory. The Teensy 4.1 is the same size and shape as the Teensy 3.6, and provides greater I/O capability, including an ethernet PHY, SD card socket, and USB host port.

When running at 600 MHz, the Teensy 4.1 consumes approximately 100mA current and provides support for dynamic clock scaling. Unlike traditional microcontrollers, where changing the clock speed causes wrong baud rates and other issues, Teensy 4.1 hardware and Teensyduino"s software support for Arduino timing functions are designed to allow dynamically speed changes. Serial baud rates, audio streaming sample rates, and Arduino functions like delay() and millis(), and Teensyduino"s extensions like IntervalTimer and elapsedMillis, continue to work properly while the CPU changes speed. Teensy 4.1 also provides a power shut off feature. By connecting a pushbutton to the On/Off pin, the 3.3V power supply can be completely disabled by holding the button for five seconds, and turned back on by a brief button press. If a coin cell is connected to VBAT, Teensy 4.1"s RTC also continues to keep track of date & time while the power is off. Teensy 4.1 also can also be overclocked, well beyond 600MHz.

Tightly Coupled Memory is a special feature which allows Cortex-M7 fast single cycle access to memory using a pair of 64 bit wide buses. The ITCM bus provides a 64 bit path to fetch instructions. The DTCM bus is actually a pair of 32 bit paths, allowing M7 to perform up to two separate memory accesses in the same cycle. These extremely high speed buses are separate from M7"s main AXI bus, which accesses other memory and peripherals. 512 of memory can be accessed as tightly coupled memory. Teensyduino automatically allocates your Arduino sketch code into ITCM and all non-malloc memory use to the fast DTCM, unless you add extra keywords to override the optimized default. Memory not accessed on the tightly coupled buses is optimized for DMA access by peripherals. Because the bulk of M7"s memory access is done on the two tightly coupled buses, powerful DMA-based peripherals have excellent access to the non-TCM memory for highly efficient I/O.

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.

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.

The Teensy 4.1 is newest iteration of the astoundingly popular development platform that features an ARM Cortex-M7 processor at 600MHz, with a NXP iMXRT1062 chip, four times larger flash memory than the 4.0, and two new locations to optionally add more memory. The Teensy 4.1 is the same size and shape as the Teensy 3.6 (2.4in by 0.7in), and provides greater I/O capability, including an ethernet PHY, SD card socket, and USB host port.

When running at 600 MHz, the Teensy 4.1 consumes approximately 100mA current and provides support for dynamic clock scaling. Unlike traditional microcontrollers, where changing the clock speed causes wrong baud rates and other issues, Teensy 4.1 hardware and Teensyduino"s software support for Arduino timing functions are designed to allow dynamically speed changes. Serial baud rates, audio streaming sample rates, and Arduino functions like delay() and millis(), and Teensyduino"s extensions like IntervalTimer and elapsedMillis, continue to work properly while the CPU changes speed. Teensy 4.1 also provides a power shut off feature. By connecting a pushbutton to the On/Off pin, the 3.3V power supply can be completely disabled by holding the button for five seconds, and turned back on by a brief button press. If a coin cell is connected to VBAT, Teensy 4.1"s RTC also continues to keep track of date & time while the power is off. Teensy 4.1 also can also be overclocked, well beyond 600MHz!

Tightly Coupled Memory is a special feature which allows Cortex-M7 fast single cycle access to memory using a pair of 64 bit wide buses. The ITCM bus provides a 64 bit path to fetch instructions. The DTCM bus is actually a pair of 32 bit paths, allowing M7 to perform up to two separate memory accesses in the same cycle. These extremely high speed buses are separate from M7"s main AXI bus, which accesses other memory and peripherals. 512 of memory can be accessed as tightly coupled memory. Teensyduino automatically allocates your Arduino sketch code into ITCM and all non-malloc memory use to the fast DTCM, unless you add extra keywords to override the optimized default. Memory not accessed on the tightly coupled buses is optimized for DMA access by peripherals. Because the bulk of M7"s memory access is done on the two tightly coupled buses, powerful DMA-based peripherals have excellent access to the non-TCM memory for highly efficient I/O.

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.

CircuitPython is now available for Paul Stoffregen’s Teensy 4.0. This port of CircuitPython is super-early, not optimized, cutting-edge… there is a ready-to-use HEX file to experiment with. Open it with Teensy Loader and program onto your Teensy 4.0, for CircuitPython at 600 MHz.

In 20 minutes, actually less than that, we were able to make an IoTeensy project. Scott and Artur have done an amazing job bringing CircuitPython to the NXP iMX RT1062. This chip holds a lot of promise! We threw together a quick IoT project to test I2C and SPI – the OLED is an I2C device, and the AirLift FeatherWing provides WiFi over SPI. This demo connects to our AP, then queries the Adafruit quote service to get an inspirational quote every 3 seconds. The JSON is parsed, split, and displayed on the OLED by scrolling. This was really fast to put together, only about 20 minutes and 100 lines of code – YouTube.

The Portenta H7 is a powerful STM32H747XI dual Cortex®-M7+M4 32bit chip that runs pretty fast – SDRAM was added, and flash storage. If you’re going to want to get TinyUSB running on this thing, we have support for the STM32 H7 series. The board is Feather-like, and has a STEMMA/QWIIC-like connector, that’s good to see that direction as that is where the market went.

The Portenta kinda reminds us of the Pyboard D-series with STM32F767 and WiFi/BT from MicroPython. It has similar connectors on the bottom, a fast chip, WiFi/BT, etc.

Just in time for #OrcaCon! Kaltazar’s electronic communication badge, made with Circuit Playground Bluefruit, TFT Gizmo, and a 3D printed lanyard clip – Twitter.

On the first of 2020 we kicked off the #circuitpython2020 planning. I’ve been posting all of the awesome responses on the Adafruit Blog. Our end date is January 13th’s CircuitPython Community meeting (join Discord for details). I’ve also been wrapping up BLE work on packet aware protocols like the Apple Media Service and BLE MIDI. We swapped the CircuitPython HID library to take in a list of devices as well so that BLE HID devices can be used in place of USB HID devices. I’ve been meaning to write my own #circuitpython2020 post and talk about the need for focus, buuuuuuuttt I got distracted by @arturo182’s PR for iMX RT support in CircuitPython. It is very exciting, the chips are faster and some have more RAM (1MB!). In my distraction, I’ve added support for more dev boards including the Teensy 4!

CircuitPython’s hardware-ready design makes it easier than ever to program a variety of single-board computers, and this course gets you from no experience to working prototype faster than ever before. Codecademy’s interactive learning environment, combined with Adafruit’s highly rated Circuit Playground Express, present aspiring hardware hackers with a never-before-seen opportunity to learn hardware programming seamlessly online.