What comes after Teensy 4.0? Teensy 4.1. The new version of the Arduino compatible board is powered by the same NXP i.MX RT1062 Cortex-M7 crossover processor clocked at 600 MHz, but about doubling in length in order to add a 10/100 Mbit Ethernet PHY, a MicroSD card slot, and offer more I/Os.
Teensy 4.1 also increases flash memory to 8 MB (vs 2 MB for Teensy 4.0), and the USB hot-plugging power management circuitry needed to plug a USB device via a USB host cable.
Teensy 4.1 specifications:
- SoC – NXP i.MX RT1062 Arm Cortex-M7 processor at 600 MHz with 1024KB RAM (512KB is tightly coupled),
- Storage – 8 MB serial flash (64KB reserved for recovery & EEPROM emulation), MicroSD Socket, footprints for 2x extra QSPI chips such as flash or 8MB PSRAM chip
- USB – 1x micro USB port for power and programming
- Networking – 6-pin Ethernet header via 10/100 Mbit DP83825 PHY
- Expansion via through-holes and pads
- USB – 2x USB ports, both 480 MBit/sec (5 pins with power management)
- Storage – 1x SDIO (4 bit) native SD
- Audio – 2x I2S Digital Audio, 1x S/PDIF Digital Audio
- Serial – 8x Serial, all with 4 byte FIFO; 3x CAN Bus (1x with CAN FD)
- 35x PWM pins
- 40x digital pins, all interrupt capable
- 18x analog pins, 2x ADCs on chip
- 3x SPI, all with 16 word FIFO; 3x I2C, all with 4 byte FIFO
- Total I/O pins – 55 (vs 40 for Teensy 4.0)
- Security – Cryptographic Acceleration; Random Number Generator
- Misc – RTC for date/time, 32x general-purpose DMA channels, Programmable FlexIO, Pixel Processing Pipeline, Peripheral cross triggering, Power On/Off management
- Power Supply – 5V via micro USB port
- Dimensions – 7.2 x 1.8 cm (TBC)
The software is mostly software compatible with Teensy 4.0, and can also be programmed in Arduino IDE using Teensyduino software add-on.
Plugging an Ethernet cable requires a small adapter board that plugins into the 6-pin Ethernet header on the board. Fast Ethernet was added in order to support low latency & high bandwidth requirements of applications such as Artnet LED projects, streaming audio, open sound control, etc… where SPI Ethernet would just not cut it. The Ethernet port also supports IEEE1588 precision packet timestamping for those who need this feature.
USB follows the same concept as Ethernet, meaning you’d need to connect a cable with USB female port into the 5-pin USB header of the board, before connecting a USB device such as a keyboard, or even a USB hub. The developer – Paul Stoffregen – notes that while Teensy 4.0 already had those USB host data signals exposed on SMD pads, Teensy 4.1 now supports hot-plugging to directly connect a USB device at any time. USB devices are supported by Paul’s USBHost_t36 library in the Arduino IDE.
The new Teensy board supports additional SQPI memory and/or storage if needed. For example, an additional 8MB PSRAM can be required for high-resolution TFT displays, buffering data, some special audio effects, as well as emulation of retro games.
Since not everybody may need those extra features and I/Os, and Teensy 4.0 is still available for $19.95, but if you have specific requirements met by Teensy 4.1, it can be purchased for $26.85 via the product page, where you’ll find documentation and links to accessories including USB host cable and 8MB QSPI flash. However, the Ethernet adapter is not sold just yet and only available as a DIY project.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
This is closing the gap between linux-capable entry-level SBCs and micro-controllers. At some point it’s possible that the extra trouble of getting a TCP and a USB stack to work reliably and with good interoperability outweigh the benefits of working with a micro-controller though. For example, the BeagleBone is a solid competitor when it comes to having many fast I/Os, but it remains a bit larger and more expensive. But it’s also easier to adopt in a number of projects since you only focus on the userland on top of a standard kernel.
The pocket beagle is the answer here I think. It’s around the same price etc.
I think the issue is that the workflow is a bit awkward for people that expect to hook up usb, fire up the arduino ide and have at it. Doing something similar to how micropython works where you plug it in and get dropped right into a python REPL is simple with buildroot but SBC vendors seem to think everyone wants to fumble around with a clumsy Debian based distro for some reason.
I know that there is loads of resources online, but is there anything specific you can recommend around the workflow and usage of these low cost SBCs instead of microcontrollers?
>but is there anything specific you can recommend
Use buildroot to build FIT images with your kernel, root fs and main DT and overlay fragments.
On 32bit ARM around 8MB gets you a kernel, a glibc based environment with python etc that boots in a few seconds.
With everything in a FIT image you can use u-boots built-in overlay support for applying the overlays i.e. bootm $loadaddr#mysbc#pinmuxingoption1#somethingonanspibus#… etc which is so much cleaner and less painful than the attempts to handle it in the kernel.
Once you have a working buildroot config and dt overlays for the stuff you commonly use on your favourite board stash it on github and make a branch each time you want to make a widget.
For my own SBC I’m aiming for it to boot to a python session that can be driven from a comfortable IDE like pycharm so it’s like the micropython experience but better.
Very interesting approach!
A tutorial on this subject would be nice. But I am sure there will be one for the Breadbee 🙂
The Pocket Beagle is indeed really nice but the Ethernet pins are not routed so a SPI to Ethernet chip must be used.
That is the point of the Teensy 4.1.
Wonder if these will get Marlin Firmware support for DIY 3D-printers and CNC-machines?
nice, i see great potential to use this for 3D print controller
Teensy is a nice product, but I’m not convinced this is a great solution. Given a choice between
a) Teensy 4.1 with Ethernet on a single core, single threaded “operating system”, or
b) A quad core headless NanoPi or OrangePi running Armbian
I suspect the latter will perform better (less latency and jitter), assuming multiprocessing is used where the ethernet socket is put on a separate core and Armbian is pruned to remove unneeded processes. Seems like the Teensy is trading away the benefit of Arduino’s psuedo-“real time” character for connectivity. I’d like to see a real world test though.
When you’re using such boards, you’re not even seeking performance, so multi-core has little use. In the best case, you’d run system tasks on one core so that interrupt processing doesn’t add latency to your userland tasks (e.g. when responding to ARP requests etc). But between the two above you have the BreadBee, which is also single core, and probably more suited to low-level tasks than both boards in many aspects: https://www.cnx-software.com/2020/04/14/breadbee-tiny-embedded-linux-sbc-mstar-msc313e-camera-soc/
Modern MCUs like these still have faster for low latency / real-time response needs like example robotics.
Also, there is more things that can go wrong and crash a system when you have a Linux operating system.
You do not want your CNC machine (robot) to crash in the middle of a job just because of something freeze.
>Modern MCUs like these still have faster for low latency / real-time response needs like example robotics.
There’s a reason that SoCs that aren’t phone or tablet focused often come with a Cortex-M? core.
>Also, there is more things that can go wrong and crash a system when you have a Linux operating system.
Once you have something that does as much as Linux with almost everything turned off except networking you have something that has just as many moving parts and usually no separation between them.
>You do not want your CNC machine (robot) to crash in the middle of a job just because of something freeze.
You also don’t want a situation where a debugging assert in your status LED code stops the whole system in a loop. That sort of thing is very common in mcu sdks. If you need fault tolerance you want isolation between your moving parts so that the part blinking an LED can’t crash the whole system while another part is driving a plasma cutter or something.
Linux can be extremely reliable, it’s most often the userland crap that’s installed on top of it that ruins your experience. When you have 1 GB of systemd stuff living its own life in your back plus automatic software updates plus accelerated graphics drivers and a browser on top of that, you’re really lucky when you achieve more than a few months of uptime without trouble and with reproducible boots. But when you’re just serving files, running a few daemons, you’ll see that it can be pretty solid. Example:
$ uptime
17:16:59 up 1134 days, 21:17, 1 user, load average: 0.08, 0.11, 0.19
Yes I know, this one has missed quite a few updates. But it’s actually used and it shows that it can be stable. You’d be amazed by the number of mail servers, file servers etc used in various companies, that are never updated because downtime pisses some users off, and that due to this achieve uptimes in the 3-5 years range. And this has got worse with hotplug disks because in the past at least there was a reason to power-cycle them to replace a failing disk!
Just by picking an LTS kernel that’s at least one year old (i.e. not the latest one but the previous one), you can actually avoid the vast majority of early stability issues and only be left with the security ones. Of course when it’s connected you’d rather keep it up to date. But it’s not a matter of lack of reliability.
Another upcoming board featuring same MCU is the Feather MIMXRT1062 for Adafruit CircuitPython
https://circuitpython.org/board/feather_mimxrt1062/