Future Teensy features & pinout

PaulStoffregen

PaulStoffregen

Well-known member
Now that NXP has publicly announced the IMXRT1170 chip, we can finally start talking about far-future (late 2020 -- EDIT: time frame unknown.....) features and form factors and pinouts.

EDIT Again: every appearance is these new IMXRT117X chips will not be in volume production until the end of 2021 or early 2022.

EDIT Yet Again: these chips are still not in stock at the beginning of 2022, and we're now about 9 months into a severe global shortage of nearly all chips. When PJRC will be able to launch another Teensy model is looking uncertain, but the first half of 2022 is looking extremely unlikely to alleviate the shortages of nearly all chips on the market.

I'm definitely planning to make a larger form factor Teensy with the 1170 chip.

I'm also considering making Teensy 4.1 with the same chip (or 12 mm package size) as we have on Teensy 4.0, but in the Teensy 3.6 form factor so we can have access to more pins and features. If Teensy 4.1 is made (still "if" at this point), it would be early 2020 time frame. EDIT: Teensy 4.1 was released in May 2020 (this message was originally written in October 2019, just shortly after Teensy 4.0 release).

Exactly which pins, what features (like a SD socket vs integrating an ethernet PHY vs maybe SGTL5000 or other codec on SAI3) and how to use the PCB real estate are pretty much a blank slate at this very early stage.

But one thing I'm not looking to do is an Intel Edison style high density connector for all or most of the I/O. The general format of 0.1 inch spacing for outside pins, and more-but-less-critical pins on bottom side pads will remain the basic idea of the Teensy form factor. But for 1170, if the PCB is larger, maybe we'll do dual-rows (similar to Beaglebone) with the outside rows meant to be primary signals for breadboard use. Maybe?

Still so many options to consider. Now that we can talk of 1170 without violating any NDAs, let the conversation begin!
 
I wouldn’t mind having 2 rows of pins on each side, effectively doubling the pin count and still keeping compatibility with a lot of the current addon boards. I wouldn’t mind having the Ethernet PHY if we can have it without affecting the speeds of the processor too much, as it stands if it were for the 1062 it’s already supported in the FNET library I’ve been toying around with so support should be had right out of the gate for native Ethernet. I’m sure it will probably be updated at some point to support the 1170 as well by the time that’s out and ready for testing.
 
I would hope the current 23 pins on the Teensy 4.0 will be the same as the 4.1. I'm sure you don't want to design and stock yet another audio shield variant. Even if they are in a different location, it would be nice if pins 24-33 had the same functionality as with the T4. Possibly the SD pins, if brought out to SD drive.

I would like to see pins 24-27 and 32-33 migrate out to the outer row. This would allow having all 3 I2C buses, both I2S buses (including the OUT1B pin) and 2 of the 3 SPI ports all accessible without having to solder wires underneath or use breakout boards. Pins 28-31 I'm not as concerned about, but I'm sure there are other people that need 7 serial UARTs or 3 CAN buses.

It would be nice if the T4.1 had the 5 pin USB header similar to the T3.6. I would suggest that unlike the 3.5/3.6, that these 5 pins be aligned on a 0.1" grid, so that you could solder these to a standard prototype board. Obviously we need the appropriate capacitors, etc. to run USB safely.

As I use the Adafruit boards occasionally (particular Monster M4SK for the uncanny eyes), I really like them having the flash memory, and their infrastructure for providing a USB removable disk. Now, CircuitPython (well Python in general) leaves me cold, which I suspect it the main reason they include the flash. It is useful to have this flash memory to hold things like sounds to play, and I'm sure people doing logging really like having a fast area to store date. And it is particularly useful in that I don't have to fool around with TeensyTransfer like I do with the prop shield to get data onto flash or off of it.

Obviously, if you can't do flash, having a micro SD card like the T3.5/T3.6 does is ok. I don't know whether people are wanting to use the giant SD-XC cards (64GB) or whether it would add to the cost to support them.

I suspect wifi and bluetooth are out of the question, but it does seem to come up over and over again in the group.

While I've only done light displays for a 30-60 LEDs, it would be nice if there was some support for having something like a 74AHCT125 to bring out some WS2812B's or APA102's. I haven't seen much talk about the large displays for some time, but it may make sense to lay things out so you could do a new Octows2811 board. But maybe people have moved away from boards like Teensy, and now use other solutions.

I'm sure our display wizards (KurtE, mjs513, defragster) have other concerns and issues, particularly in having all of the different memory regions.

I like having the on/off pin on the board, and I hope that will continue. It would be nice if I didn't have to wire up button to use it. But it might confuse people.

As I am doing T4 stuff, it would be really nice if the debug pins were brought out (like in the T3.5/3.6), and somebody wrote the GDB support (unlike in 3.5/3.6).
 
Last edited:
I think a Teensy 4.1 with the same form factor as a Teensy 3.6 would be really great. And to the extent that you can replicate the pins so that existing designs can upgrade to Teensy 4.x from Teensy 3.6 as a drop-in.

That would mean, in my mind, include if possible:

- The USB protection circuitry and the same header for USB host
- A stereo DAC
- JTAG pins
- uSD card slot

As far as a 1170-based design (Teensy 5?) I really like the idea of the dual rows of headers (see my breakout board https://forum.pjrc.com/threads/57672-Another-Teensy-4-0-Breakout-Board ).

I am concerned that a design with a kitchen sink of peripherals would be very expensive. I applaud the approach you took with Teensy 4.0: do the simple, cheaper version first. I also think that continuing to build shields that add functions modularly to the design would be great. That way we aren't stuck with peripherals and board area we don't need, but can expand buying add ons as needed.

That said, it would be great to bring out an LCD interface to be able to take advantage of the graphics capabilities of that chip.
 
My basic wish list for T4.1
- added uSD card
- pins for USB1 (device)
- pins for USB2 (with host protection)
- LDO to allow 6- 16 V Vin
- access to 1 MB of RAM (build in or external)
- NO build-in codec

In general I would not suggest to integrate what is better done with add-on boards, e.g codec, ethernet, wifi, bt, etc.
I have no needs for JTAG, display, etc., but if they could be bottom pads.
 
Going to get confusing here::

Next in 2020 >> Bigger T_4 :: with 1062 ( 1064 worth the cost to double FLASH and save adding external unsecure Flash? )

Later in 2020 >> New Teensy based on 1170 with a Single DAC - but a spare 400 MHz M4

Paul - Of course this dropping 10/2 where the 1170 goes public was not on your schedule to open discussion … - have you thought of Numbers for them to refer too? Should one move to a new thread?

Are there any givens? Both will have SD socket?

Will both have a same size or larger FLASH?

Will either have twin LDO's to support VIN over USB_HOST level 5V and yet provide for higher incoming VIN over that USBHost level? That would also allow that Teensy to drive displays or radio devices
 
Last edited:
defragster said:
Later in 2020 >> New Teensy based on 1070 with a Single DAC - but a spare 400 MHz M4
Click to expand...

It's 1170, not 1070.

While NXP hasn't publicly announced any 1070 part yet, remember we did see a mention of a 1070 (and 1170) by someone at NXP on their community forum. As I recall, that was regarding the hardware bug impacting the FIFO on CAN FD, which they mentioned would be fixed in both these future chips. So we can be pretty sure from info that's disclosed in public that a 1070 chip is also coming. My general plan at this point is to skip that 1070 chip and use only 1062 and 1170.


1064 worth the cost to double FLASH
Click to expand...

Maybe. I'm also considering simply using a bigger flash chip.


Paul - Of course this dropping 10/2 where the 1070 goes public was not on your schedule to open discussion …
Click to expand...

Actually, I was under the impression they has planned to announce it sooner. I don't know why they waited until yesterday. A couple years ago, they had planned to call this chip by a different part number. It was on a confidential road map document before we even started with the 1052 chip. But I have only known the actual specs (like the M4 core) for the last few months.

I take NXP's NDA seriously, so I've been careful not to mention the part number or talk about any details. I waited to start this conversation, since I didn't want to accidentally mention any confidential details.


Will both have a same size or larger FLASH?
Click to expand...

I want larger non-volatile storage on the larger boards, especially for storing sound clips, graphics, fonts and other non-code resources.

A second flash chip dedicated to non-code storage (and allowing writing without pausing code execution) is also a strong possibility. 1062 can support at least 4 QSPI flash chips, maybe even 8, depending on how the FlexSPI signals are used.
 
vjmuzik said:
I wouldn’t mind having 2 rows of pins on each side, effectively doubling the pin count and still keeping compatibility with a lot of the current addon boards. I wouldn’t mind having the Ethernet PHY if we can have it without affecting the speeds of the processor too much, as it stands if it were for the 1062 it’s already supported in the FNET library I’ve been toying around with so support should be had right out of the gate for native Ethernet. I’m sure it will probably be updated at some point to support the 1170 as well by the time that’s out and ready for testing.
Click to expand...

@vjmuzik
It seems that we will never get a native ethernet interface for the teensy...;-) ...but never the less, teensy is great....and it is great to see the future plans for it....
 
Spyy said:
It seems that we will never get a native ethernet interface for the teensy...;-)
Click to expand...

I'm seriously considering some way to offer the gigabit native ethernet of 1170. How, I'm not sure? Not sure it putting the PHY chip on the Teensy board and have some sort of connector for an add-on with the magnetics and RJ45 makes sense.

Of course there's also the matter of software support. I really don't see any serious work happening on that anytime soon, since so much other stuff is still in need of my attention....
 
Hi Paul,

glad to hear this...appreciate this very much....sure...there must be some peace of code on the sw side...lets see...

Again, great work what you are doing....

Torsten
 
For the things I do, a native ethernet option would be interesting for those cases where you just want a networked device that does one thing well without needing to secure a full linux install. Suspect the economics are pretty hostile though with Pi's and openWRT devices around.
 
Exactly,

I am doing cockpit devices for flightsimulators....with bare metal programming and connectivity with ethernet...at the moment i am using the SPI solution together with a WIZ IO...but for that i have to "waste" one SPI channel and perhaps, not sure, i have more CPU load for the ethernet communication...
 
Personally I think it would be great to have the ++ version of the 4.0, as there are already so many things we barely scratched the surface on with T4...

For me, all the normal suspects:
Easy access to SD pins and/or SD socket like T3.5/6
Easy access to USB Host pins: With power chip like T3.6
Other bottom pins made easier to get: Like the SPI pins LPSPI3...
Maybe add Pins associated with LPSPI2
Can not have to many UARTs

Like others have mentioned: maybe nice to have a beefier 3.3v output if possible, to drive displays...
Would be great to have debug support.

Would be great to have some form of remote capabilities like Wifi. Even if it is simply saying you can connect up a ESPxxx to UartN and then have some way to say program the teensy using that remote connection...

Again lots of possibilities and again I think I would aim for low hanging fruit, like T4.1, before going to T5 or...
 
Suggestion: Upgrade connector to USB-C.

I have a Teensy with a failing micro USB connector and have been impressed by the mechanical improvements of USB-C, not the least of which is that it works either orientation.

Also, it's more compact and can run as a host or device. A pair of these on the 1170 based device would be awesome.
 
As long as we have the pins available for either the gigabit or the megabit interface I’ll be fine without having a PHY built onboard as at least those who want it will have access to it for an add on board.
 
Of course if we are really blue skying things, it would be nice if there were pads underneath the PCB to solder surface mount pull-up resistors for the things that generally need them (i.e. I2C SDA/SCL, SPI CS/DC, etc.). Or even better, having the resistor in the PCB, and just being able to join it with a solder bridge. Obviously the traditional pins still need to be in the same location, and given the T4 is a 6 layer board, I have to imagine there isn't room to do such things.
 
KurtE said:
Personally I think it would be great to have the ++ version of the 4.0, as there are already so many things we barely scratched the surface on with T4...

For me, all the normal suspects:
Easy access to SD pins and/or SD socket like T3.5/6
Easy access to USB Host pins: With power chip like T3.6
Other bottom pins made easier to get: Like the SPI pins LPSPI3...
Maybe add Pins associated with LPSPI2
Can not have to many UARTs

Like others have mentioned: maybe nice to have a beefier 3.3v output if possible, to drive displays...
Would be great to have debug support.

Would be great to have some form of remote capabilities like Wifi. Even if it is simply saying you can connect up a ESPxxx to UartN and then have some way to say program the teensy using that remote connection...

Again lots of possibilities and again I think I would aim for low hanging fruit, like T4.1, before going to T5 or...
Click to expand...

I really like this list.

For the SD, make UHS-I support possible. Here are some requirements from this post.

The uSDHC supports DDR50/SDR50/SDR104 with 1.8V signaling. I can put an SD in 1.8V mode with the uSDHC.

The problem is that switching from 3.3V to 1.8V signaling requires switching the GPIO power rail, NVCC_SD0, from 3.3V to 1.8V. This requires a 1.8V supply and switch.

The uSDHC controller assumes the NVCC_SD0 power on ball position J6 will be switched when the VSELECT bit is set/cleared in the uSDHC. VSELECT is associated with a GPIO pin.

A good choice for VSELECT is GPIO_B1_14.alt6 since that is the boot config. There are four choices so any would do.

You need lots of power to support UHS-I and there can be large pulses. See this. Here is the max current spec, 800 mA in UHS104 mode.

Code: 
6.6.3 Current Consumption
The current consumption is measured by averaging over 1 second.
• Before first command: Maximum 15 mA
• During initialization: Maximum 100 mA
• Operation in Default Speed Mode: Maximum 100 mA for SDSC and SDHC
  100mA (XPC=0) or 150mA (XPC=1) for SDXC
• Operation in High Speed Mode: Maximum 200 mA
• Operation in UHS-I Mode: Maximum 400mA (UHS50,DDR50) or 800mA (UHS104)
• Operation with other functions: Maximum 500 mA.

These are averages so expect large pulses while programming 512KB flash pages in a modern uSD.

I have designed the SdFat Teensy 4.0 driver to do infinite transfers since the uSDHC controller has support. I have done single writes of hundreds of MB to a pre-allocated exFAT file.
 
JTAG pads (could even be some tiny, solderable test-pads) would be wonderful
 
A usable 16bit port. eg; d0-15. This is beneficial when controlling parallel displays.
SD card as with T36 but not so near to the edge that the card is easily damaged.
Could possibly make the board a little wider (4mm?) to accommodate extra functionality.
 
MichaelMC said:
A usable 16bit port. eg; d0-15. This is beneficial when controlling parallel displays.
Click to expand...
Second that. I have no idea if this would even remotely possible on Teensy, but
here Qt is running on an i.MX RT1050 with a RK043FN02H-CT LCD that uses even 24bit parallel signals...
 
I read through a press release on the 1170 today. All I can say is WOW! When I read of the dual-cores: 1GHz M7 + M4, I am already wanting to sign up! @Paul - are you taking pre-orders? I'm drooling, I'll take two :D

But seriously, as things stand with the T4.0, I have a real need for it, but am unable to use it as is because of the lack of pins. I need SPI, I2C, serial, board, display, and lots of GPIO pins for encoders, switches, etc. The two breakout board development projects that I'm aware of (@loglow and @blackketter) have both hit snags and are being redesigned as we speak. So, as of now, for me the T4 has a great deal of potential that is just beyond reach. For me, small size is of no importance whatsoever, while processing, function, expandability, and ease of interfacing is my primary concern.

I concur with those above who are advocating for a new (larger) T4 form factor that exposes all the available pins.
 
I wonder what the M4 is for, and whether it would have things lost in the M7 (touch pins, DACs, differential analog inputs, etc.). Now in hosted situations, I could imagine the M4 being used to off-load I/O from the M7. It could certainly be used for things like independent ethernet/wifi processing, but it doesn't really fit into the Arduino way of doing things.

I recall when I briefly worked at Metrowerks, one of the Sony Playstations the compiler was targeting had two processors in it like this, with one core being the beefy processor, and the other one being the earlier processor that was used in previous Playstations. If you ran an earlier game, it would use the earlier processor, otherwise it would mostly sit idle.
 
vjmuzik said:
I would certainly use the other core to offload the gigabit ethernet and/or USB host.
Click to expand...

Sure, I'm sure it is designed for things like that. But the Arduino infrastructure does not really seem like it would support dual cores, particularly dual cores with different processors. In the Teensy infrastructure, it my be an interesting challenge to download code to the M4 (it depends on whether the two can share memory or not).
 
You must log in or register to reply here.
Back
Top