Teensy 4.0 (hypothetical) pin assignments

The first board will target the same form factor as Teensy 3.2, with 24 I/O and 4 power pins on the breadboard-friendly edges. It's looking like bottom side pads may end up having 10 signals, plus a set of pads for SD card (6 signals + 2 power). The plan is still the signals from msg #20.

Will the SD pins be a small pitch array to bottom mount an adapter like used on the top side T_3.6?
 
So at least for part of the board this would probably be close - T3.2 form factor. Not sure what some of the pinouts are on the side but I will get there. As for the underside eventually.
Picture1.jpg
Sorry if I am jumping the gun here but to me a picture is worth a thousand words :) Besides - got tired of debugging and coding for a little while.
 
The current plan (which is firming up... but still could change) is to keep VBAT for the RTC, and put the on/off button signal where the DAC is on 3.2. Right side PROGRAM, GND and VCC(3.3V) to remain the same, as they've been on every Teensy.
 
Thanks Paul.... Just have some fun. Will do the other side for another post. Hope you don't mind.

Update: Heres the other side of the board

Picture1.jpg

Just noticed that MOSI3 and CLk3 are on the underside pins? Wouldn't it be better to move them to the top? Maybe where pins 2 and 3 are? LED Pin gone? Have an idea but still working layout

Oh, forgot MQS_right and left will add them on next revision.
 
Last edited:
The quad timer pins also have PWM capability, so 8 more PWM pins. :) Pins 0 & 1 also have FlexPWM.

For the final Arduino support, we're doing to do stuff like call UART6 the Serial1 port, so every gets a familiar Arduino experience.

I'm still debating whether/how to show the crossbar and flexio pins, and what the Arduino APIs should look like.
 
Thanks a lot to show. I wasn't sure what some of nomenclature meant on the pins without looking at the manual, so I try to put what was familiar.

Figured you were going to rename the ports eventually but just wanted to match what was on the list for now.

BTW. The whole layout is in powerpoint so when I get done playing with it I will post that as well in case anyone wants to have fun with it. All still a draft but easier to visualizer what you were talking about with the pin layout.
 
Ok. Think I am done for night now.
Picture1.jpg

All I can say is wow when you look at it this way.

Cheers
Mike


EDIT: before you say it I forgot XBAR
 
Ok. Last topside update:
Picture1.jpg

EDIT: Here's a rough out of the backside, just a thought.
Picture2.png
 
Last edited:
SPI will be doable on the flexio I take it? I can’t beleave how fast this thing will be running code.
 
Not an expert here but from the manual for flexIO, it does allow for a lot of customization for the user to develop additional library support. If you use a lot of the FlexIO pins you loose the other functional assigned to those pins. So you will have to mindful of that. I am sure others with a lot more experience will jump in if I said anything wrong. :)

27.2.1 Overview
The FlexIO is a highly configurable module providing a wide range of functionality
including:
  • Emulation of a variety of serial/parallel communication protocols
  • Flexible 16-bit timers with support for a variety of trigger, reset, enable and disable conditions
  • Programmable logic blocks allowing the implementation of digital logic functions on-chip and configurable interaction of internal and external modules
  • Programmable state machine for offloading basic system control functions from CPU

27.2.2 Features
The FlexIO module is capable of supporting a wide range of protocols including, but not
limited to:
  • UART
  • I2C
  • SPI
  • I2S
  • Camera IF
  • Motorola 68K/Intel 8080 bus
  • PWM/Waveform generation

The following key features are provided:
  • Array of 32-bit shift registers with transmit, receive and data match modes
  • Double buffered shifter operation for continuous data transfer
  • Shifter concatenation to support large transfer sizes
  • Automatic start/stop bit generation
  • 1, 2, 4, 8, 16 or 32 multi-bit shift widths for parallel interface support
  • Interrupt, DMA or polled transmit/receive operation
  • Programmable baud rates independent of bus clock frequency, with support for asynchronous operation during stop modes
  • Highly flexible 16-bit timers with support for a variety of internal or external trigger, reset, enable and disable conditions
  • Programmable logic mode for integrating external digital logic functions on-chip or combining pin/shifter/timer functions to generate complex outputs
  • Programmable state machine for offloading basic system control functions from CPU with support for up to 8 states, 8 outputs and 3 selectable inputs per state
 
The more I read on FlexIO and XBAR the more mushy my brain gets, but they look very interesting. I already can see where they would provide low level hardware support for coordinated motion control in a robot or 3D printer even if you have more degrees of freedom than one MCU can handle.

I do like the idea of a later uncommitted version that can be tailored as desired.

#20 looks good.

I would think it would be great if you tucked a third row of small round pads along one side of the bottom rectangular pads. Personally I'd stick as many XBAR outputs on them as possible. If the SD use is via a daughter card, then the bottom contacts could be a 10x2 or 11x2 array of rectangular pads. Even more pins could be outed in an additional row of dots to one side. So 24 IOs via the edges, 20 or 22 via center header, and 9 to 11 more via small circular pads. I have been direct soldering wires to the bottom pads, both rectangular and circular. I strain relieve those wires by binding them to wires soldered into the pin holes.

Code:
| = card edge
o = in location
* = dot pad
## = rectangualr pad

So from edge to edge it looks like this:
|o*## ##o|

My personal preference would be for more SPI with DMA compared to regular serial ports due to my current designs being high on SPI driven LED arrays. I only ever use one serial device, and that is a GPS unit. Most of my serial is I2C or SPI, with a few special serial protocols in there. FlexIO and XBAR can help with them. 2 to 8 FlexIO shift registers strobed in and out by the same clock can drive some high resolution ADC and DAC converters made for instruments. It looks like the 32 bit shift registers may be loaded and unloaded via DMA as a block. That would make driving wide arrays of LEDS easy.

BTW: FlexIO can get you an 1,2,3,4,8,16, or 32 bit wide 6800 or 8080 type parallel IO bus provided you have the pins to do it.
 
FlexIO and XBAR do seem cool and mushmaking for the brain thing.

Paul has noted what he expects he can present on the 1.4" T_3.2 sized board. One thing mjs513's mock up doesn't express - AFAIK the MCU package is like the K66 on the T_3.6. It fits pin to pin on the board's middle area and creates a no go region underneath where the BGA signals are routed. As note on the larger T_3.6 - to route the pins takes all the layers and putting a round hole through violates usable space on all of them.

Here is a quick update showing some of the scale effect of that updated on the image from above with a clip of the T_3.6 bottom. Not presenting another couple dozen pins like the T_3.6 may make it somewhat less busy - but still not open to more round pins and having any hole free pads presented:
T4Moq.jpg
 
That sucks. I know ways around it, but they all make the PCB cost more, and I don't see that being done. I very likely wouldn't make the decision to add that much cost to the PCB.
 
Sadly, no, the new chip doesn't have any capacitive touch feature.



I will endeavor to port my lightweight touch library that uses an approach that works on any digital pin with pullup or pulldown resistor: https://github.com/adrianfreed/FastTouch
I might get higher dynamic range measurements on this new chip because of the higher clock rate.
Also Admar has developed a library with a range of techniques including using the ADC inputs for capacitive sensing: https://github.com/admarschoonen/TouchLib
 
If the data sheet is to be believed they have a schmitt trigger option and a 100KOhm pull up option which I can use to increase range of capacitance measurements.
 
Morning all.

I would just like to reiterate something that defragster stated in his post. The mock-ups I posted are just that, mock-ups of the pin layout shown against a T3.2 since I believe that is the relative form factor for the T4 based on previous posts including post #20.

PLEASE DO NOT TAKE THE MOCK-UP AS A FINAL DESIGN FOR THE T4 as Paul (PRJC) is still in the design process for the board and the board layout. It was just to give me and others what the pins identified in post 20 would look like pictorially.

In post #1 to this thread it was stated: "First, one important ground rule. Do NOT suggest a larger form factor, high density connectors, or ANY other ideas for more than 24 pins!" This is the one hard design ground rule that Paul stated in that post. The underside pins are extra and subject to change.

Respectfully
Mike
 
I'm sorry I broke the rules from post one but assumed that they were for the outside pins. You can't have everything and that being the case having a clear idea of what the goal is like Paul has is much more important than feature creep. I know several programs I used to love that I don't use anymore that just kept adding stuff until what made them great was lost. The same can happen with hardware.
 
@DaQue. I apologize if you thought you broke the rules. I added that just to make sure folks were aware of the purpose of the pictorials and not taking taken as cast in stone. If you further read the post and post 20 it was the design rule for the first release of the T4. Next versions of the T4 will probably have different rules :)

respectfully
Mike
 
@PaulStoffregen

A question and suggestion on CAN pin locations. Was wondering if it possible to get CAN on pins on 3&4 to align more with the T3.2. Looking at the pin assignments in post #20 I don't think so but wanted to throw it out there?

EDIT: This probably applies to a few other pins but more I look at it not sure its going to be possible with the new functions each pin is assigned.

Respectfully
Mike
 
Last edited:
@DaQue. I apologize if you thought you broke the rules. I added that just to make sure folks were aware of the purpose of the pictorials and not taking taken as cast in stone. If you further read the post and post 20 it was the design rule for the first release of the T4. Next versions of the T4 will probably have different rules :)

respectfully
Mike

It's all good, after T4 if nothing protrudes from the back I may even suggest the hated castellatede edges. A lay out with a thru hole and a castellated edge like this on the outside edge.

OC
OC
OC
OC
OC
OC
OC
OC


I expect it won't fly. It would end it making the board 0.1” wider and I bet few would understand you you could mount it like a Wroom module.
 
@DaQue.
may even suggest the hated castellateded edges. A lay out with a thru hole and a castellated edge like this on the outside edge.
I think castellateded edges was already discussed in a previous post - may want to read the previous ones. Not sure which one.
 
I haven't been partaking in this discussion very much up to now. As a classic "mixed signal" guy, I've been deeply disappointed to see that the T4.0 wouldn't have any DAC outputs. After the T3.1/2 with one, the T3.5/6 with two, I had secretly expected to see at least four of these on a newer and more powerful MCU. A higher bit depth for the ADCs and DACs would have been a "nice to have", too. I'm perhaps late with everything, but I started only a few years ago to think about re-creating all that pure analog and sometimes discrete CMOS stuff which I had created in the audio and music domain until 2013 on a mixed signal MCU, where the Teensy product line appeared the most appealing to me. My (naive) idea was to have really everything in one.single.chip.

Now, after having swallowed my disappointment and after having seen that it's not only PJRC or NXP, but that other manufacturers like Cypress, Ti, and Analog Devices(!) don't go the mixed signal way I had wished either, and that for example simple and nice components like the I2C audio volume controllers/drivers from Princeton Technology have become rapidly obsolete, too, I'm forced to re-think and to retry things again and in a still more digital way than I initially intended.

Thus, please don't take my temporary silence here as a disapproval of whatever happens actually, it's just that I felt somewhat left behind by the actual technical evolution and I'll need most probably still a little time to catch up.
 
Back
Top