Future Teensy features & pinout

I am now designing a mainboard for a design that include Teensy 4.0 and would appreciate this method of soldering the teensy to a PCB.


As for the bottom pads of the T4.0, it's not obvious how to connect to them. My point is to design the next Teensy as a component that can also be assembled on a PCB, being low profile and being able to use all the advertised capabilities and I/O.

The breakout board discussed here https://forum.pjrc.com/threads/57672-Another-Teensy-4-0-Breakout-Board uses castellated pads like in that photo.

If you are using KiCad, the footprint used by that breakout board is available here: https://github.com/blackketter/teensy.pretty

I originally designed that footprint for my own mainboard design and ended up making some breakout boards to test. I do hope that any future Teensies make this process easier.
Thanks Blackketter, this is very useful.

I am designing my own PCB so I can make the teensy 4.0 area similar to your breakout board.

PJRC, please consider for next designs ease of low profile mounting on a PCB and suggest at least one good way of doing it. This is an important aspect of using your modules.
Last edited:
My preferences in descending order:

* Larger form factor with SDRAM and flash onboard (SOM like this is fine: https://wiki.somlabs.com/index.php/File:VisionSOM-RT-v_1_1.png)
* Dual row .1" header pins, microSD, with all IO on the dual row headers and nothing on the bottom of the board.
* T3.6 form factor with microSD, and some IO on the bottom of the board.

Other thoughts...

The 1GHz clock of the M7 would be neat, but actually being able to utilize the M4 as a coprocessor, that would be far more useful IMHO. Especially if the M4 can access GPIO... For example, the M4 could do 'slow' things like reading GPIO, clocking out SPI data to a display, etc, leaving the M7 to do some heavy computing without being hamstrung by any blocking IO operations.

I'm not sure if the software support for such a thing is realistic at this point in time though.

If we add a RAM chip, which is still a very big "if", one of the lower pin using formats like Hyperbus (12 signals) or QSPI (6 signals) would be much more likely.

I have to admit I'm not familiar with the new and different flavors of RAM. I believe SDRAM is commonly used, for example, in the SOM that I linked to above. I think SDRAM comes with the unfortunate need to be periodically refreshed to maintain state, and perhaps there's newer technology that would be more suitable for embedded use.

edit: A quick search revealed this: https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/

Okay... wow! That is really interesting, good performance, low price, and it comes in a simple SOIC package. I'd wind up needing to develop software support for what I have in mind, but I don't think that's the end of the world.
Last edited:
I'm not sure if the software support for such a thing is realistic at this point in time though.

It is one of those chicken and egg scenarios. If you don't have the hardware, you likely won't get the software. If you have the hardware, depending on people's motivations, you may or may not get the software.
My preferences in descending order:

* Larger form factor with SDRAM and flash onboard (SOM like this is fine: https://wiki.somlabs.com/index.php/File:VisionSOM-RT-v_1_1.png)

This is one of the areas where there is no one answer.

  • Some people need as much read/write RAM as possible to run their sketches, but they don't need to use the RAM to write to high speed devices;
  • Some people need to be able to buffer large frame buffers, and they do need the memory to be coherent for DMA transfers (preferably without having to invalid the caches);
  • Some people need lots of read-only memory, but they don't need the memory to be super fast; (and)
  • Some people need lots of non-volatile memory that is preserved across power cycles -- usually it doesn't have to be fast, but it does need to be faster than micro SD cards.

Case 1 has to be handled via normal pointer accesses. Case 2 either needs to be handled via a normal pointer access or you need to use a bounce buffer that you copy the data into and then do the I/O. Cases 3 and 4 can be handled with external calls, but particularly #3 is simpler if a pointer works.

The division between the first 512K and second 512K in the Teensy 4.0 has showed up a number of issues.
I'd wind up needing to develop software support for what I have in mind

Maybe you could explain what you have in mind for the RAM, especially if it would require special software support.

If you're not familiar with the FlexSPI controller (and really, it's so incredibly powerful but complex that probably very few people really understand it), the general idea is for these sorts of memory chips to get memory mapped. The 1062 chip has 2 FlexSPI controllers, each of which can theoretically handle 4 different chips and make them appear withing a 256 Mbyte range of the ARM's memory space. FlexSPI1 makes chips appear from 0x60000000 to 0x6FFFFFFF. FlexSPI2 makes chips appear in the range 0x70000000 to 0x7EFFFFFF.

The hardware has powerful 2 level caching. L1 is on the ARM M7 core, with 32K for data access and 32K for code access. L2 caching happens in the FlexSPI controller, though perhaps buffering would be a better word than caching. The FlexSPI controller has fairly large FIFOs that allow the ARM core to rapidly flush its L1 cache rows. Likewise, since all access is through the L1 cache, reads tend to be in bursts (which is best for these sorts of memories) and the FlexRAM controller can use its FIFO to read ahead. But ultimately the QSPI interface isn't fast compared to the incredible speed of M7 at 1 GHz, so cache misses will be painful.

Anyway, on the software side, these sorts of RAM chips should require only a small amount of code to initialize the FlexSPI controller and program its LUTs for this chip's specific commands. We'll also need an addition in the linker script and probably another keyword like DMAMEM and perhaps another version of malloc(), so your code can allocate variables & buffers in the external RAM. Then you just access them with your code as if they're normal memory. That's how FlexSPI works... the chips are just mapped into the ARM's address space.

FlexSPI also provides a 2nd "IP Bus" path to the memory, which lets you issue single commands under more traditional software control. It has an arbitrator, so you can even mix these into the stream of accesses generated automatically from memory mapped access, assuming you don't put the memory chip into a state where those accesses would fail. So you can get that sort of more traditional programming access, but the hardware is much more complex to use than a normal SPI interface (even the complex ones in this chip with deep FIFOs and other advanced features). If you want to learn more about FlexSPI, it's documented in chapter 26 of the reference manual, stating on page 1727.
That's how FlexSPI works... the chips are just mapped into the ARM's address space.

That would be incredible... I have been away from this stuff long enough that I didn't expect memory mapping.

The RAM use case that I am considering is 'multi-track' recording capabilities for my synth. So DMAMEM and an external RAM malloc() would take care of it.

Anyway, with these developments, I'd say the upshot is I would be happy with just about any bigger form factor for the updated T4 :)

edit, shown below is my microSD solution for my synth. Not ideal at all... bleh.

Looking at the latest Arduino modules, they are designed so they can be soldered directly to a PCB, for a lower profile.


PJRC, please design similar capability in future Teensy modules.

+1 for this! I really like these hybrid castellated / through-hole pads on the edge. I do understand that there will be parts on the bottoms of teensy 4.x board requiring a cutout in the base board.
I just ditched the 4.0, because of the low pin count, and missing SD socket.
Even if I use an external SD socket, the flex socket used in Teensy 4.0, Is very difficult to source, especially in Europe.

I wold like:
1) Teensy 3. 5/6 pinout compatibility (as much as possible) and same PCB size.
2) MicroSD socket.
3) If on board ethernet is to be used, do it with a flex connector (and NOT the type used in T 4.0)
4) External reset pin, as in 3.5/6
5) 1 to 2A buck/boost vreg, maybe with Li-ion batt charge possibility. 2. 5 to 15V in.
6) 2 to 4 pcs of 74LV125 or similar used to isolate multiple MISO pins on the SPI bus, controlled from specific CS pins.

Only wishes 1 & 2 is essential for my next product using Teensy.

Poul, thank you for some fantastic products.

Br Gigabyte.
Hi Paul,

I really like the smaller form factor of the T4.0 - my only request would be easier access to the SDIO pins, but I am managing fine so far. I'd probably be very interested in a 4.1 (3.6FF) variant it anything became available.

If you were doing a bigger version, which the RT1170 would have to be, which is heading into SOM territory, here are the things that I thing would make a difference to me:

-Expose the DSI and CSI - could be high density connector for a mezzanine etc. The 1170 will be the first affordable bare metal, Arduino compatible micro that has a fully functional MIPI DSI interface, there are so many great, cheap screens that are not accessible to hobbyists because there has never been a good (relatively open) controller that supports MIPI DSI. Most parts that are available don't have the required documentation, exposed interface or are many hundreds of dollars. I don't know the architecture or how the peripherals would be mapped, but the idea of the co-processor just taking care of graphics and the main core having a processing routine would be amazing. The specs have 1080P @ 30Hz which would open up a whole new range of ux and embedded display ideas.

-In the use case above - a single 1080p frame at 16bpp is ~4Mb - so something like 16Mb of memory mapped ram (QSPI?) would allow a decent frame buffer and scratch space.

-On-board SD with UHS-I compatible interface.

-I like the ideas of a mezzanine of the small main module (Edison, or any other SOM really style connector) and a breadboard compatible breakout board, if we want to integrate this part into our own products this really improves the situation.

-USB-C connector - they now don't add any cost to the BoM over a micro usb and are really so much better. Follow the rules and they are bullet proof.

-OTA firmware updates: I know this has been a tricky point in the past, but how well it works on the ESP8266/ESP32 really makes that an amazing package if that is your requirement.
Keep the Teensy bootloader closed-source, protect your IP and the products from being copied, that is 100% reasonable, and has resulted in an amazing product, community and has kept PJRC a leader in the space.
My Proposal; if it was possible; expose a TTL serial port on the MK02 with a documented protocol (half-kay?) that allows flashing of firmware, Eeprom, fuse configuration (where required) and reboot of the main Teensy uC.
For those that are interested, they can interface with this with a hypervisor/loader of their choice. ESP8266, ESP32, Any Ethernet Enabled uC, Any CAN enabled uC, the implementation is up to the user, but there is a possibility to do it without having to use USB which is where the problems start.
Any number of end user OTA requirements can be achieved then, and I am sure that this would be utilized by many - myself included.

Overall the biggest thing for me has been support - which PJRC/Teensy excels at - the implementation and library support is fantastic, as it the community. So you could probably ignore all of the above and keep doing what you are doing and I will still buy your stuff. :D
i would say make a 4.1 as close to the t36 format, sd card, usb host pins with hot plug circuit, usb client pads, as many pads on the bottom for pogo pins, i love the idea of a double row board, with the inner row being identical to the single row version and the outer row having all other gpio available, this would make it much easier to instal it into a larger board with all additional circuitry need for custom projects.

Seriously Paul, thank u for the Teensy platform, u r like the elon musk of the arduino world, i dont know how u can make the time to maintain code and work on hardware ��
I personally wouldn’t mind if it got a 0.1” wider. It’s not like I plug them into actual IC sockets. It probably would make routing a whole lot easier. That would eliminate 3.5/3.6 pin location matching so you could go longer too and count out most of the pin headers on that back. If you keep the same size as a T3.6 .6 05” smt headers for pins on the back since breadboard comparability to squeeze more in. goes away with back side pins. 64 or 80 pin dip size works for me too and would be my preference over backside connections.
While my requests are small, here goes--please continue to keep this class of units small (non T3.6 foot print)

1. 100% of my projects utilize a DIP socket for teensy replacement so i'd like to see a larger board to fit cheap readily available 16 x 2 sockets
2. 1 pin should be the backup battery, 2 high-speed digital pins for multiple display support, pin to force a manual restart (and not a code-based restart) this will let user restart teensy if for some reason it locks up (say pin low restarts)
3. add the RTC crystal even if it increases the board price for the upgrade
4. add an on-board temp sensor
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.

Does this mean that, current T4 form will be discontinued if T3.6 form is introduced, or existing T4 layout will be still available, regardless update?
This won't mean the end of Teensy 4.0, just like Teensy 3.6 didn't cause Teensy 3.2 to disappear.

In fact, we're *still* making Teensy 2.0 and Teensy++ 2.0 and have enough inventory to go well into 2020. But if anything is likely to be discontinued in the foreseeable future, it's the old 8 bit boards.
..im sorry, maybe my question was misleading..what i wanted to know is, regardless new layout of T4 (T3.6 size), is it going to be available T4 in current size, as it is right now?
Hello Paul and all,

I'm a new registered user, but already a long-time (multiple) Teensy owner, and reader of this excellent forum. I never had a need to post, because I always found what I needed (thanks to Paul, Robin and his forum).

Given that the Teensy 4 is a game changer in terms of power and an enabler for circuits that previously required a DSP, I think the focus should be on fast interfaces. A fast Teensy is only as good as it can communicate fast with the outside world. A one-lane SPI as an example is too slow.
The Teensy 4 can be used in many professional products.
So I would see a.o. a need in more than one quad-SPI, available via standard pins (not a special-difficult-to-find connector like now on the back of the Teensy 4).
I also doubt the need to have an onboard SD-card reader. If a Teensy is built into a product, the location of the on-board SD-card will most likely be in the wrong physical place (from experience). The SD-card need to be located at the physical edge of the box, where the Teensy cannot always be located. So instead Sd-card pins need to be available.
Removing the SD-card would free up valuable PCB space on the larger Teensy, available for other important communication interfaces, like Ethernet PHY.
I understand there could be many people wanting to preserve an on-board SD-card, but thinking critically, the place that the Teensy 4 has on the market is different than a Teensy 3! That different (high-end) place has different needs, and fast interfaces and communication is one of them.
Just some thoughts to consider…

I'm a big T3.5 and 3.6 customer. I have not purchased a T4 because of the small GPIO form factor, but will definitely obtain several T4.1 modules when ready. But I may purchase a T4 sooner than later if the 4.1 release is far out.

On the 1170 chip, it's a very good step, but a teensy step. I'd like to see a giant leap into the world of single-board-computers. I'm hooked on the Jetson Nano because of the 128-core 64bit processor, and the ability to program artificial intelligence. This field is exploding. I'd like to see PJRC come up with an SBC using an Nvidia chip or the Intel Movidius VPU chip, etc. Or at least come up with an accessory or shield that would integrate a T4 or T5 with an SBC. This would be very cool.

Just curious, what's the best selling teensy board? Is this the order from best to not-best: T3.2, T4, T3.5, T3.6, LC, T2.0, T++2.0?
I'm hooked on the Jetson Nano because of the 128-core 64bit processor, and the ability to program artificial intelligence. This field is exploding.
Correction: Jetson Nano is a 4core ARM and 128GPU system.
but you are right, AI is (again) very trendy.
I would like to see some effort to use the GPU on the T4 for processing, if it can be accessed.