Future Teensy features & pinout

I had signed up with NXP in order to get the 1062 datasheet before Paul made it available on PJRC.COM. I just got mail that NXP's buyout of Marvell is nearly complete (evidently it will be complete on December 6th). Now, this was originally announced in May, but I didn't see it then.

I'm sure Paul can't comment at the moment due to NDAs and such, but I can imagine some Teensy users would like it if there was a variant of the 1170 that included wifi and bluetooth that Marvell might provide.
 
this board has a great layout as a development board - you could get lots of new users involved in Teensy if we had something like this

https://i.ebayimg.com/images/g/4YQAAOSwZvRadiTs/s-l1600.jpg s-l1600.jpg
 
I think NXP has benchmarks using different types QSPI, HyperRAM, HyperFlash for code and data. For code, I think it would be better to use HyperFlash over QSPI, with a 1Ghz processor, the more bandwidth the better. Yes, there is ITCM and internal RAM, but why waste the RAM when HyperFlash is about 2.5x faster?
 
Hi Paul - just wanted to chime in with another +1 for JTAG debugging support. There's amazing work being done on alternative IDEs (specifically PlatformIO for VS Code), but these come with a requirement for a proper JTAG debugger. Would love to see this capability made available in a future Teensy.
 
My thoughts on features for the future Teensy

1. Pinout exposed such that an Ethernet Shield can be added to the Teensy (Teensy would NOT have the RJ45 jack on it, just necessary pins)
2. If I am reading the internet correctly, there is support for multi-threading: put multi-threading on the teensy.
3. The capability to program the Teensy without Arduino IDE, but on the command line. An example use case would be to use GCC 9.x.x and then import the necessary libraries.

First thing:

I know that Ethernet appears to be a niche issue since we all probably have Raspis anyways, but there is a business case for the functionality.

The Raspi has a long boot sequence that requires a password. There is also a GUI process that slows things down (I know there are ways to turn off the GUI service).
The Teensy 4 has a super high clock speed that allows for real-time CAN bus whereas other small linux computers have only a few more Mhz more.

(Given that my focus is more in the robotics area)

I know that there are some control systems that use ethernet to communicate (like a full-fledged desktop) to send sensor data. Sensors like Sick laser scanners or Cognex cameras use Gigabit ethernet for real-time visual processing.
The use case I would want is a gigabit link with a Teensy 4 so that I can then expose a sensor like an IMU to the network.
A real-time ethernet gyro cost multiple thousands of dollars and is far too expensive for hobbyists.
A simple 15 or 20 dollar shield to give the Teensy networking functionality would allow for more real-time control of robots at orders of magnitude less costly parts.

Then, the sensor could be integrated into the new ROS2 framework with DDS (I know, a yuuuuge stretch: I can dream still).

This hardware configuration would allow for any non-robotic system to be converted to semi-autonomous or fully autonomous with little effort.


Second thing:

I find that I am holding up sensor reading processes in the data publishing process.
In my desktop software, I use multi-threading to separate human or sensor input from the computer operation functionality.
This functionality would further speed up software, even without faster clock speeds.
In fact, for my use cases (maybe not for everyone), a 600 Mhz clock is way more than necessary when multi-threading is available.
The separate threads would also both need access to the pinout hardware, not just a separate software thread.


Third thing:

This functionality may already be there, I just don't see any official support.
I have heard both support and negation to the claim that you can program without the Arduino IDE, but I can't figure out which is true.
Some clarity would be great.


A few more side notes:

I also want the newest Teensy to be in a T3.6 form factor. It would be great if the Teensy lineup followed some expected pinouts beforehand.
This would make getting shields to fit across board models easier.


Thanks guys
 
Just my two cents: point 2 can be accomplished with an RTOS, point 3 is a toolchain thing. There are many, many ways to skin both of those cats, but it would be best to make a dedicated thread and ask for help.
 
This thread is about a farther future product using the not-yet-released 1170 chip.

Most of the things you've mentioned exist now, or will come sooner with a 1062-based board in the Teensy 3.6 form factor.


1. Pinout exposed such that an Ethernet Shield can be added to the Teensy (Teensy would NOT have the RJ45 jack on it, just necessary pins)

This will be coming, using the TI DP83825I Ethernet PHY chip and 6 pins for the connection to the magnetics & RJ45 connector.


2. If I am reading the internet correctly, there is support for multi-threading: put multi-threading on the teensy.
3. The capability to program the Teensy without Arduino IDE, but on the command line. An example use case would be to use GCC 9.x.x and then import the necessary libraries.

Limited support for threading already exists, using the TeensyThreads library. However, many Arduino libraries are not fully reentrant or designed to be safe to access from more than 1 thread. Teensy is only a small part of the huge Arduino ecosystem, so that situation is unlikely to change anytime soon.

The sample makefile for Teensy 4.0 was recently updated. Other people have published makefiles too. There is a command line only Teensy Loader, if you don't wish to use the GUI one. You certainly can do everything only from the command line if you really want.

Eventually Teensyduino will migrate to a newer gcc toolchain. But that's not going to happen while so much other stuff is in rapid development. I believe Frank or Manitou did some benchmarking with the newest (at the time) toolchains during the Teensy 4.0 beta test and saw the coremark benchmark was slightly slower than we have now. So we're probably going to keep things stable on the older version we use today, until gcc performance improves on newer versions.

Of course, there's no reason why you can't try using a newer toolchain. Many things do work. Obviously they were able to get coremark to run, and enough of the USB stack to see the results. But with newer toolchains usually bring lots of minor breakage and annoyance. So far they seem to come with a slight hit in performance of optimizations. Maybe you *really* want some specific newer C++ dialect feature? Other than that, don't assume newer is always better.
 
3. The capability to program the Teensy without Arduino IDE, but on the command line. An example use case would be to use GCC 9.x.x and then import the necessary libraries.
Platformio provides a terrific command line build environment for all the Teensies and hundreds of other boards. It also works with VisualStudio, if that's your preference.

Highly recommended.

https://platformio.org
 
For teensy 4.{something} with 1170:

The ESP guys are using a function named "xTaskCreatePinnedToCore()" to assign a task to a specific core. I like this idea.
It will be interesting to know how the 1170 handles the memory, espcially the stack for both cores.
The easiest, for users, would just be something like loopCore1() for the 2nd core..
 
For teensy 4.{something} with 1170:

The ESP guys are using a function named "xTaskCreatePinnedToCore()" to assign a task to a specific core. I like this idea.
It will be interesting to know how the 1170 handles the memory, espcially the stack for both cores.
The easiest, for users, would just be something like loopCore1() for the 2nd core..

Very interesting to see how it resolves. With twin CPU's one each of M4 and M7 core type and speed - versus two equivalent same speed cores like ESP32 where they built with a version of RTOS to hide under Arduino it can more directly support that having a task pinned or float between them with shared memory pool. On 1170 the two cores have IIRC unique memory areas and a defined overlap area? It seemed like it would take building of two HEX files and tasks would be programmed and dedicated to one core or the other?

As far as command line building - at least on Windows - FrankB resolved a command line batch file usable from 'editor of choice' that can execute a batch file from the current file folder. It fully builds just like the IDE from same tools and sources - using TyCommander for Upload and SerMon. I tweaked that to allow building the command file for a given teensy and boards settings as github.com/Defragster/Tset. A common TSET batch file prompts and creates a local batch file that runs from a DOS box, Windows file explorer, or editor of choice ( tested and used on SublimeText ). AFAIK that 'batch file' should be adaptable to Linux script - but not made or seen any effort to do that.
 
It will be interesting to know how the 1170 handles the memory

Today with with 1062 we get 512K is TCM for M7 and the remaining 512K is accessed by slower AXI bus.

Soon with 1170, we'll get the same 512K as TCM for M7, and 256K as TCM for M4, and the remaining 1280K on AXI bus for both of them to use. The M7 side appears to be pretty much the same as we have now in Teensy 4.0, but with 1280K of OCRAM2 instead of only 512K, and of course 1 GHz clock.

The M4 situation with RAM is pretty similar to Teensy 3.6, except at 400 MHz. All of the 256K ram in Teensy 3.6 is TCM. The ram in Teensy 3.6 at 20000000 and above can be considered DTCM, and the ram at 1FFFFFFF and below can be considered ITCM. The M4 core uses 2 buses which map into those RAM banks. M4 has no separate bus for other stuff, so the situation isn't quite analogous to M7 with 3 buses.

On Teensy 3.6, we currently have an 8K cache for code, and there's no cache for data (and we don't have any other memory which could use such a cache). On 1170 we'll get a 16K cache for non-TCM code and 16K cache for non-TCM data, which is the 1280K of RAM shared between to M4 and M7. Historically we've never worried about caching on M4 because all memory was TCM or peripherals. But 1170 will bring 1280K of memory shared, with caching to manage on both sides.

On the 1280K shared RAM, it's not clear to me if it's all created equal. Looks like it may be in 3 independent banks, which is a good thing if you want to have both cores access the memory by their DMA controllers. Two banks of 512K may be intended for the M7 and the remaining smaller 256K bank may be intended for the M4. It's still not clear to me whether these RAM banks will truly support concurrent access. Seems like they should, but that might also be just wishful thinking on my part. The available info (even the stuff under NDA) isn't all that clear...

Every indication I'm seeing so far says the M7 core probably can not access the M4's 256K TCM, and the M4 probably can not access the M7's 512K TCM. So if you use only the M7, you get 1792K RAM, and if you use only the M4 you get 1536K.

Looks like there might also be some other small chunks of RAM, sort of like how we get an extra chunk of RAM in Teensy 3.6 for the FlexNVM and chunks of RAM in the CAN controllers on Teensy 4.0. But even if the early info weren't under NDA, it's so obviously a copy & paste job from other NXP chips that I would would wait until we have the real hardware to check.

But the main info is clear. M7 gets 512K TCM, same as we have now on Teensy 4.0, the M4 gets 256K TCM similar to what we have now on Teensy 3.6, and the remaining 1280K will be a big pool of somewhat slower memory shared between to 2 cores. Both have caching for that 1280K, so cache management functions will be needed on both sides.
 
So both cores have each their own DMA and don't share it.
The Block diagram shows they have their own FPU, too. Are they the same, or is there a technical difference I.e. can both calculate double values?
(I guess periphals like GPIO are shared?)
 
Probably parroting a few comments on here, but the larger form factor would be nice, larger flash along with flex spi flash would be amazing I think and really bring the T4.1 into its own for audio projects. Specifically being able to reliably store more wavetables and accessing them at high speeds for the purposes of creating a wavetable style synthesizer like Serum would be amazing. I would buy at least two immediately :)
 
So both cores have each their own DMA and don't share it.
The Block diagram shows they have their own FPU, too. Are they the same, or is there a technical difference I.e. can both calculate double values?
(I guess periphals like GPIO are shared?)

Frank - assuming the public details are limited to the NXP link on p#1. There is the same single DOCUMENTATION on that link that was there with minor added details to the main page. Looking there the two cores are unique - each with an FPU so like two "Teensy's" on one board. It isn't made clear on the FPU precision of each MCU M4/M7 in re-reading. Also the pin count jumps nearly 100 pins - no details provided on linked NXP page - but the idea seemed to be that the 1170 portion would be like the 1062 with it's pins and functions and the added pins were perhaps mostly tied to the added 400 MHz M4 core? So it looks like two non-symmetric MCU's in one package each with full unique feature sets - but as Paul notes they overlap with memory access to what will be slower RAM if like on the 1062 where that non-TCM RAM runs at F_CPU/4. Didn't see an indication if they have any other direct connection bus.
 
Last edited:
IF the core-features are identical, with identical FPUs, it might be possible to use one sourcefile (*.ino, *.c or *.cpp) for both... ? (M7+M4 are the same then, regarding machine-code)
They can use the same GCC switches in this case, the rest can perhaps be done with a little linker magic.. ?
@MichaelMeissner, what do you think?
 
Sorry if this is not the place for this kind of requests, Im a big noob when it comes to electronics.

I would definitely bet on JavaScript.

I ended up using Teensy and not something else because it offers an easy way to have a USB device and flash code to it using just standard Arduino environment without going into more "hardcore" things like a JTAG programmer or god knows what. This lower barrier of entry for HID USB MIDI device was extremely appealing. Due to the amount of MIDI controller projects, I would assume its the same for a lot more people, they want to make a MIDI controller and Teensy offers the least obstacles.

I think I represent an example of the (electrically ignorant) web programmer demographic which is big and very eager to break out from the computer screen to make physical devices. We dont know crap shit about C++ or memory management or anything of that sort, we want to write some code and move some stuff or turn on some LEDs. I know we should learn to go deeper, but I do that at work, not on my electronics side-projects. I can also see how there are lots of cases of people who can build their circuit but cant write their code and depend on copy pastas from the internet.

A powerful Teensy big enough to store and run a JS interpreter could suddenly lower the barrier of entry even more, making it so more crappy web developers like me can discover the joys of Teensy. It also allows Teensy to leverage the countless libraries and packages built on the JS ecosystem. It would also make Teensy the only HID support, JS support microcontroller in the market.
 
This is probably not the best place for this question...... I'm migrating a project from Teensy 3.2 to Teensy 4.0. The compiler is generating a lot of errors like TFmini.cpp:13: error: 'Serial3' was not declared in this scope
NumBytesAvail = Serial3.available();


and error: 'interrupts' was not declared in this scope
interrupts();


and error: 'Wire' was not declared in this scope
Wire.begin(I2C_MASTER, 0x00, I2C_PINS_18_19, I2C_PULLUP_INT, I2C_RATE_400, I2C_OP_MODE_DMA );


and even error: 'delay' was not declared in this scope
delay(25);


I did solve a compiler error for sprinf by including stdio.h, but the code compiles nicely for Teensy 3.2, where I didn't have to include it. So.... I wonder if there is anything else I have to include to get this to compile for T4.0? Thank You for any advice.

Here are my included files at present......
#include <stdio.h>
#include <i2c_t3.h> // PJRC for timing functions and I2C, replaces <Wire.h>
 
Usually start at the top most error to solve problems, the remaining ones usually follow the initial cause. A full report should be posted of compiler as well as a test sketch so people can check it on their own Teensy 4

Rule is posted at the top of the forum in red
And yes, start a new thread as this one is reserved for the future pinouts of new teensy :)
 
This is probably not the best place for this question...... I'm migrating a project from Teensy 3.2 to Teensy 4.0. The compiler is generating a lot of errors like TFmini.cpp:13: error: 'Serial3' was not declared in this scope
NumBytesAvail = Serial3.available();


...

Indeed this is out of place here - though seems like an issue that needs attention/resolution. Please start a new thread with this commentary and ideally a sketch that runs on T_3.2 as written but gives this compile grief when compiled for the T_4.0.
 
How to start a thread?

Drop one level under the main forum to one of the sub-groups there and a new thread can be started there.
 

Attachments

  • Capture.jpg
    Capture.jpg
    35.5 KB · Views: 123
Last edited:
I'm a noob and I'm sure there are really good reasons for design decisions and limitations of the Teensy product line, so I hope I don't sound like I'm griping. I only started getting interested in micro-controllers again in an effort to find uses for Golang (learning a new language is easier if there's a fun project to use it for) after seeing a video on youtube of someone running Tinygo on Arduino's. What annoyed me with microcontrollers in the past was having to convert IP to serial with a bridge. The main benefit that I find on ESP32 is that the code running on the controller can talk MQTT or RestAPI via IP directly, and no translation of UART or I2C connections are needed. So my list would be ...
1) WIFI on the board with similar capabilities as ESP32
2) Ethernet expansion without too much duct tape.
3) As much RAM as possible. I assume Intel/Micron Optane type chips can't be sourced cheap enough, or integrated cheap enough, but if this is a wish list, then non-volatile RAM that runs as fast as the slow SRAM add-on chips would seem cool.
4) MicroSD slot.
5) USB 3.1-C connector
6) Sharks with frickin' lasers ... and RAM > 128 MByte to be able to run WRT
 
I thought I would link this, since it appears to be somewhat affiliated with Adafruit, which seems to be a friend of PJRC: https://hackaday.io/project/169387/gallery#d161a3aee96abef2a8e17e2aa7789a8f

Looks like an RT1062, some kind of flash chip, USB C, and a high density connector in the Feather form factor. The bootloader would not be the Teensy bootloader... but I think this kind of shows some interesting possibilities for striking a balance between ease-of-use and also having access to additional IO.
 
Back
Top