Pins to bring out on a hypothetical larger Teensy4

Status
Not open for further replies.
Yep this will be fun :D

Looks like some of us will be busy editing pin tables and the like, for all of the different sub-systems... Again sort of like when we went from testing with 1052 to 1062. Not sure if there should be a define that includes all of them like #ifdef IMXRT sort of like how we do #ifdef KINETISK?

Probably will need a new set of #ifdef as __IMXRT1062__ may not be sufficient, especially with dealing with pin mappings.
Too bad it is not something like: __IMXRT1064__ That would make them unique... (and double the memory :D )
 
I'd vote for a #define IMXRT (sort of) and additional define for the new board. The common #IMXRT would save a lot #ifdefs esp. with future chips.
 
I believe Arduino started defining something a couple years ago to distinguish their boards which use the same processor, like Arduino Zero vs MKR1000. I honestly haven't looked at it or worried about this much (yet - still struggling to just route the PCB), but my general plan is to follow Arduino's convention.

Too bad it is not something like: __IMXRT1064__ That would make them unique... (and double the memory )

I'm tentatively planning on using Winbond's W25Q64JV flash chip on Teensy 4.1, which will quadruple the flash memory. But yeah, still the same processor.
 
Paul Quick verification...
They're offset by 75 mils vertical and 50 mils horizontal, so this can probably be done if you're willing to have pads packed tightly together.
With the USB pads on this board:
If board his horizontal with USB on the left, starting at (0,0) the GND pad is at (50, 50). With a T3.6, the USB +5v is at (300, 175),
On the new T4.x it will be at (350, 125) So vertically only 75mm above D2 (i.e. will not line up with where I assume VBat is which I am assuming is at (1850, 150)

These 7 signals will be fairly easy to access, if you're ok with SOIC pads at 50 mil (1.27 mm) pitch.

Code:
EMC_22  PWM3_B3         I2C3_SCL        ENET_TX_DATA0   QTIMER2_TIMER3  GPIO4:22  FLEXSPI2_A_SS1_B
EMC_24  PWM1_B0         UART5_RX        ENET_TX_EN      GPT1_CAPTURE1   GPIO4:24  FLEXSPI2_A_SS0_B      
EMC_25  PWM1_A1         UART6_TX        ENET_TX_CLK     ENET_REF_CLK    GPIO4:25  FLEXSPI2_A_SCLK
EMC_26  PWM1_B1         UART6_RX        ENET_RX_ER      FlexIO1:12      GPIO4:26  FLEXSPI2_A_DATA00     
EMC_27  PWM1_A2         UART5_RTS       SPI1_SCK        FlexIO1:13      GPIO4:27  FLEXSPI2_A_DATA01
EMC_28  PWM1_B2         UART5_CTS       SPI1_MOSI       FlexIO1:14      GPIO4:28  FLEXSPI2_A_DATA02
EMC_29  PWM3_A0         UART6_RTS       SPI1_MISO       FlexIO1:15      GPIO4:29  FLEXSPI2_A_DATA03
Looks like fun to see how bad these will be to grab...
More tables to play with!

And I believe there was no DAC added for whre pin 40 and 41 go
 
Adafruit uses the TinyUSB stack on their M0/M4 boards with flash memory to provide a filesystem. I haven't looked into it, but it may be a starting point. The TinyUSB sources do claim support for the IMX RT1062

Took a look and its reminiscent of that @wwatson was working on with his MSC library: https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments?highlight=MSC. So far we had tested it Hard drives, SSD's, an array of SD cards and flashdrives.

Did just find this lib that may be interesting: https://github.com/Marzogh/SPIMemory/releases/tag/v3.0.0
 
Adafruit uses the TinyUSB stack on their M0/M4 boards with flash memory to provide a filesystem. I haven't looked into it, but it may be a starting point. The TinyUSB sources do claim support for the IMX RT1062

I was indeed looking at tinyusb while waiting for Paul to find time to complete teensy core usb stack. Did not see this particular GitHub site. So will try again, but uses CMSIS philosophy.
in fact @wwatson´s MSC interface did work great, as mentioned by @mjs513.

edit: the adafruit port to Arduino could be a possible point to start porting to teensy.
 
Last edited:
For storage, I see two different use cases:

  • On USB host systems (3.6, 4.0) you could use it to mount removable flash drives with the Teensy driving it;
  • With flash/SD attached to the Teensy, you could make the contents of the flash/SD available to the PC.

I have some Adafruit boards (M4 Express, M0 Hallowing, M4 Hallowing, Circuit Express Playground/Bluefruit), and for apps involving images or sound, it is real convenient to update the images, sounds, and config files by plugging in the board and modifying the files directly, rather than having to re-program them, move the SD card to the PC, or use Teensy Transfer.
 
And I believe there was no DAC added for whre pin 40 and 41 go

Yeah, if you wanted DACs for playing sounds, I suspect the MQS support is the closest. You would want either AD_B0_04/AD_B0_05 or EMC_13/EMC_14 routed to where DAC1/DAC0 are in the 3.6
 
@MichaelMeissner - Thanks

@Paul - I know it is probably way too early to talk about pin numbers and the like, but I started playing with my Excel spreadsheet I did for T4 beta and added a new page for T4.x (not sure yet what you are going to call it? T4.1 or T4.5 or ...

It is an interesting question that I think @MichaelMeissner asked/suggested earlier. With the 8 new pins should they be defined as 34-41, especially since many of us have new used 34-39 on T4. And I would assume we would again define those SD Pins on T4.x as we can still get hold of them by SD Adapter like we did for T3.5/6...

I will next add the bottom pins you mentioned to the excel document as well:
Code:
EMC_22  PWM3_B3         I2C3_SCL        ENET_TX_DATA0   QTIMER2_TIMER3  GPIO4:22  FLEXSPI2_A_SS1_B
EMC_24  PWM1_B0         UART5_RX        ENET_TX_EN      GPT1_CAPTURE1   GPIO4:24  FLEXSPI2_A_SS0_B      
EMC_25  PWM1_A1         UART6_TX        ENET_TX_CLK     ENET_REF_CLK    GPIO4:25  FLEXSPI2_A_SCLK
EMC_26  PWM1_B1         UART6_RX        ENET_RX_ER      FlexIO1:12      GPIO4:26  FLEXSPI2_A_DATA00     
EMC_27  PWM1_A2         UART5_RTS       SPI1_SCK        FlexIO1:13      GPIO4:27  FLEXSPI2_A_DATA01
EMC_28  PWM1_B2         UART5_CTS       SPI1_MOSI       FlexIO1:14      GPIO4:28  FLEXSPI2_A_DATA02
EMC_29  PWM3_A0         UART6_RTS       SPI1_MISO       FlexIO1:15      GPIO4:29  FLEXSPI2_A_DATA03

As I do see us defining these as real pins that some of us will probably use...

And yes way too early, but sort of curious on your ideas on pin numbering..

My guess is you will probably want to go with your new 8 top pins as pins 34-41 as it makes the system/card look cleaner.
Also you could argue that the bottom pin numbers of T3.2 and T3.6 are necessarily the same either...

So I could easily imagine the numbering to be like:
0-41 - Are the top pins like you mentioned.
42-47 - Be the bottom pins mentioned above.
48-53 - Pins that are on SDCard (T4 pins 34-39)

From what you mentioned, did not sound like it makes too much sense to number the Ethernet pins, as they are not accessible...
 
I'm pleasantly surprised to see Ethernet PHY included because there are uses for Ethernet that go beyond embedding small servers that seem to be the more typical use case. And after reviewing the pin and iomux configurations to see if the ethernet PHY could be accessed on the existing Teensy 4.0 (sad face, no), it was great to see that Ethernet is finding a home on the new board. So I give a big thumbs up for Ethernet! And not to assume, so forgive the question, but the library support would minimally include 100 Mb half-duplex? Since the raw SD supports GB of storage, fast Ethernet would be great to move large amounts of data to/from the SD.

In terms of the additional pin mapping, it is hard to argue against keeping compatibility with the existing 3.6 pinout as closely as possible. People expect it and get kind of cranky when things like that change. And for an 'average' user, if there is such a thing, compatibility on the pins would likely be an important feature.

Regarding breakout pads on the back side, my .02 is, wherever possible, allow the signal lines associated with high speed signals to be located closer to edges where they can be picked up by breakout boards via direct soldering to castellated pads. Granted, you can bit bang pretty fast on this guy, but when you need the speed, it is surely better to use existing functional modules and DMA to provide it, rather than using general purpose I/O, bit banging and perhaps PIT-driven interrupt routines. For the general purpose I/O pins, I'm all for getting more I/Os on consecutive I/O rergister bits even if they aren't consecutive pins on the Teensy itself. I'll layout mating PCBs to adjust the physical arrangement if necessary. But when it comes to code, not only am I lazy, but I like to keep any general purpose I/O limited wherever possible to single I/O registers or contiguous chunks of registers. That way masking bits and maintaining shadow registers is centralized for general purpose I/O and hopefully separate from I/O that is allocated for other interfaces, such as Ethernet and SPI.

Finally, I've researched options for implementing both Ethernet and WIFI and although the Ethernet bit looks like it will be available, WIFI is another matter. I am considering using an ESP32 devboard as a co-processor for WIFI. For me at least, the issue is speed. And although there are existing WIFI solutions, they rely on serial or SPI. I'm all for simplicity whenever possible. But SPI and serial, especially polled implementations, aren't fast enough for me. It looks like the WIFI support for the ESP32 devboard is pretty mature, and it can be compiled and uploaded within the Arduino IDE. And there is enough I/O for me to implement data transfers with the T4 over a non-standard 4-bit data interface. So the ESP32 module would accept some pretty basic commands via serial, handle buffered I/O with the WIFI interface, and to maximize the WIFI data throughput, move blocks of buffered data over that 4-bit interface that I have to still design.
 
DMA and ISRs do certainly help to reduce the workload when implementing very fast serial interfaces. But in practical terms, reliable data transmission at 80MHZ using single-ended signals can be problematic without a good understanding of high speed signal behavior and PCB routing. Existing WIFI shields or modules top out at 80 MHZ, but achieving that sort of throughput reliably is harder than it might seem. And even though it is theoretically possible to transfer data at 10MB/S, it requires that the module support block transfers with automatic pointer updating. Some do and some don't. Actual sustained transfer rates can be a bit lower, like 7 MB/S. Adding in overhead from other tasks will drop this rate even more. This rate is fine for many applications, but it isn't fast enough for the cases I am considering.

By contrast, a 4-bit interface with a single handshake line and a fast microcontroller at either end can achieve 10 MB/S sustained at a transfer rate of 50MHZ. This requires some carefully designed code to keep the timing from exceeding 50 MHZ with these fast microcontrollers. But it is definitely achievable, and only uses 1 more I/O than SPI. With 9 lines, the throughput either doubles, or you can drop the transfer rate to 25MHZ, which is quite a bit more friendly when considering making connections between modules.
 
Regarding breakout pads on the back side

It's looking very unlikely that any back side I/O pads will be possible, except the two locations to add 8 pin QSPI memory chips. The BGA escape routing on this PCB is very difficult. Adding the 12 extra signals for ethernet and 15 extra I/O + QSPI, and constraining the PCB to a reasonably priced 5/5 mil spacing & 6 layers imposes limits on how many signals can be routed in the Teensy 3.6 form factor.


...and to maximize the WIFI data throughput, move blocks of buffered data over that 4-bit interface that I have to still design.

If you're looking for maximum performance (and a programming challenge) you might try to make use of the 2nd SDIO port. It's supposed to be fully independent of the 1st SDIO port, which of course is used for the SD card socket.

With Teensy 4.0, two of the signals aren't accessible. But now all 6 signals will be routed to the outside pins.

Code:
AD_B1_04    USDHC2_DATA0     Arduino 40/A16
AD_B1_05    USDHC2_DATA1     Arduino 41/A17
AD_B1_06    USDHC2_DATA2     Arduino 17/A3
AD_B1_07    USDHC2_DATA3     Arduino 16/A2
AD_B1_08    USDHC2_CMD       Arduino 22/A8
AD_B1_09    USDHC2_CLK       Arduino 23/A9

ESP32 has a SDIO slave port. In theory, you could wire them together with these 6 signals. Teensy can do at least 50 MHz, and has a 512 byte FIFO and DMA . Espressif's manual says ESP32 can do up to 50 MHz too, and also supports DMA. So in theory this could give fast transfers between them with low CPU overhead.
 
5/5 is a reasonable limit on both cost and manufacturability. It is easy for us to lose sight of the fact that there are 196 pads on this tiny little part and we users can get a bit caught up in all of that potential I/O. However, if I had to choose, Ethernet would still make the list, way ahead of general purpose I/O. I've been in the data acquisition industry for 30 years, and Ethernet has been, and continues to be the interface with the greatest longevity and tons of infrastructure already in place. Stepping off the soap box now...

Using the 2nd SDIO port is a very interesting idea. I had passed over that as there were missing signals as you pointed out, and I was also unsure of the 4 bit protocol as I believe it is proprietary? But tying two together would eliminate the need to know or care about the protocol itself. And based on another thread regarding the performance of SDFAT on Teensy4, it should achieve 20 MB/S if both ends are using DMA. So that is a very interesting idea for a high speed, low I/O count, block transfer interface. The two would be connected via serial for low-speed communication, leaving the SDIO port for high speed data transfers only and keeping the programming simple. So this sounds like an excellent solution that doesn't rely on home-brew creations.
 
Given that the built-in SD controller on the 3.5/3.6 and the pins available on the 4.0 support 4-bit quad SDIO protocol to access the micro-SD card, the main protocol can't be much of a secret. There may be certain values and such that aren't public.

FrankB released this library 4 years ago to access parallel flash memory:
 
Hi Guys,

I am new to this forum and I am amazed by the Teensy 4.0. Reading this thread I was wondering, what is the current status of the larger T4... Of course each of us has his preferred "additional" pins, I would appreciate the RMII (maybe also a PHY and magnetics - but not on the planned form factor) and an additional FlexSPI (one is already occupied and the other channels are not complete).
My application needs communication over ETH and the memory mapped FlexSPI peripheral would be an FPGA. Currently I plan to use the W5500 chip but for the FPGA I do not know yet, what kind of interface to use - my FPGA simulates a RAM on the uC side. Can you help me with suggestions? I am new to this uC.

Best regards
Jozef
 
what is the current status of the larger T4...

The status is basically too late to alter the pinout or feature set, but too early to predict when it will be released.

Regarding memory mapping a FPGA, plan on the normal 6 SQPI signals (CLK, CS, D0-D3). The very good news for you is the FlexSPI peripheral is very configurable. You're not limited to the specifics of these SQPI memory chips. The FlexSPI chapter in the IMXRT1060 reference manual is a long & difficult read, so best to start now!
 
The very good news for you is the FlexSPI peripheral is very configurable. You're not limited to the specifics of these SQPI memory chips.

Hi Paul,

thank you for the info :) I was studying the uC manual and comparing the pins... can you please confirm that no free QSPI (FlexSPI) channel is available on the current T4 and that there will be one available on the new T4?

If the new pin-out was already fixed, can you please publish it?

Thanks.
Jozef
 
I believe that most of the information is already in this thread: Like posting: https://forum.pjrc.com/threads/5802...larger-Teensy4?p=224111&viewfull=1#post224111
and: https://forum.pjrc.com/threads/5802...larger-Teensy4?p=224119&viewfull=1#post224119

I added a new page to my excel document for Teensy 4... up on github https://github.com/KurtE/TeensyDocuments

Note: until we actually have the new T4.x setup with a alpha/beta build, the actual pin numbers assigned to different things not on top pins of the chip) are probably not fixed yet.
 
The status is basically too late to alter the pinout or feature set, but too early to predict when it will be released.

Regarding memory mapping a FPGA, plan on the normal 6 SQPI signals (CLK, CS, D0-D3). The very good news for you is the FlexSPI peripheral is very configurable. You're not limited to the specifics of these SQPI memory chips. The FlexSPI chapter in the IMXRT1060 reference manual is a long & difficult read, so best to start now!
Paul, will there be pads to access USB like on teensy 3 boards, no USB pads have been the only buzzkill for me on the 4.0 specially when i have custom breakouts that have usb type B for use on stages where i just yank the cable off without worrying
 
[...] The very good news for you is the FlexSPI peripheral is very configurable. You're not limited to the specifics of these SQPI memory chips. The FlexSPI chapter in the IMXRT1060 reference manual is a long & difficult read, so best to start now!

Hi Paul,

I am impressed by what you have done here. Getting these powerful microcontrollers into the hands of users who do not like to solder large BGA devices is a good thing.

I saw from your Teensy 4.0 product description that
But a cache miss does require many clock cycles to fill a cache row from the Flash chip.
Is this something that causes a lot of problems for users?
The FlexSPI interface allows you to do something about it.

The huge HyperFlash device that NXP put on their starter kits costs more than the MCU itself, and is clearly overkill for a lot of applications. But that is not the only option you have for taking full advantage of the bandwidth of the FlexSPI interface.

We at Adesto have octal xSPI devices available in 4, 8 and 16 MBytes densities. These EcoXiP devices will run 4-5 times faster than the quad devices you are currently looking at.
https://www.adestotech.com/products/octal/

This also opens up the option of getting a lot more RAM available without adding more external RAM chips.
By running the system in XiP mode, it becomes like having 4/8/16 MB of embedded flash, and you have all the internal RAM of the MCU available for data.
In this case the startup time of your system becomes almost zero, as you do not have to copy everything from flash to RAM before you start running code. The average execution speed gets a bit slower when running from external memory than from on-chip RAM, but thanks to NXP's excellent cache controller we still get close to 2000 coremark in this mode.
(NXP get 3000 when running from on-chip RAM. Running from external SDRAM gives the same coremark number as running from EcoXiP flash. If you want to get to that 3000 number for parts of your code, you are of course free load some of your code to on-chip RAM to speed it up.)

Some of the EcoXiP devices also support Read-While-Write, which means that you can do over-the-air updates of your code while it is running.
 
We at Adesto have octal xSPI devices available in 4, 8 and 16 MBytes densities.

It's too late to consider a different flash chip for Teensy 4.1. Winbond W25Q64JV is already designed in and parts have been ordered.

But maybe a different flash chip would make sense for the next Teensy (after 4.1) with the 1170 chip?

However, I'm less concerned about flash chip performance. We use a mix of ITCM RAM and QSPI XIP today, which works very well.

The chip I *do* really want to find is an affordable external RAM we can use for a graphics frame buffers. The 1170 will give us MIPI DSI and a 2D GPU, but those aren't really useful unless we have several megabytes of RAM for frame buffers. Does Adesto have any octal SPI RAM chips?
 
I haven't looked now at the details of coremark, but I think that I remember it's small and fits into the cache completely(?) So it wouldn't be a good test for memory speed, and you might get even better numbers with a different benchmark.

But yes, the cache is very good.
 
Status
Not open for further replies.
Back
Top