Future Teensy features & pinout
- Thread starter PaulStoffregen
- Start date
defragster
Senior Member+
@Paul - have you confirmed the MCU # under consideration for future Teensy is the MIMXRT1176 ?
defragster
Senior Member+
Yeah, the EVK's are overbuilt and extreme - but some have put them to good use for reference ...
mjs513
Senior Member+
This is what happens when I sleep. Just browsing the EVK it looks like it has a 1176 processor, along with a couple of SDRAM chips and a QSPI chip to play with along with all the other stuff. Did notice on Digikey: https://www.nxp.com/docs/en/user-guide/MIMXRT1170EVKHUG.pdf, that the EVK will cost $168 and you can actually order it now on back order. So must be getting close to release.
mjs513
Senior Member+
Agree - but I am so tempted and need a Christmas present
but haven't decided yet. Besides I don't have enough distractions
defragster
Senior Member+
The '1170' is still marked as in 'Development'. While NDA folks may have gotten an EVK board that isn't even publicly available yet.
2 Distributors showing that EVK with the 1176 indicate 15 weeks lead time with no stock and 3rd one shows : "Expected 2/8/2021" and 16 weeks lead time
The 1060 went through two 'edits' of 1061 and then the 1062 that is in use, and the first T_4.0 beta hardware was with a lesser 1050 chip as the 1060 wasn't as far along or close to shipping.
As chip development progresses they'll announce 'availability' - Paul may get enough samples to start development - but may be some time in development and/or general availability and PJRC getting enough chips to enter production.
So release date is TBD for sure and perhaps even the arrival or use of a chip #1176 is still unsure.
2 Distributors showing that EVK with the 1176 indicate 15 weeks lead time with no stock and 3rd one shows : "Expected 2/8/2021" and 16 weeks lead time
The 1060 went through two 'edits' of 1061 and then the 1062 that is in use, and the first T_4.0 beta hardware was with a lesser 1050 chip as the 1060 wasn't as far along or close to shipping.
As chip development progresses they'll announce 'availability' - Paul may get enough samples to start development - but may be some time in development and/or general availability and PJRC getting enough chips to enter production.
So release date is TBD for sure and perhaps even the arrival or use of a chip #1176 is still unsure.
defragster
Senior Member+
NXP posted this 16 page doc Dec 29, 2020 :: Migration guide from i.MX RT1050/60 to i.MX RT1170
I'd like to see usb-c and some ~64mb sdram on the next teensy. There is a competitor called daisy which has 64mb sdram onboard. But the teensy might again feature ethernet and definitely features more solid libraries and community. And I'll need those things for a wicked idea I have.
Yes it would be very handy to have SDRAM option on board. Note that this Daisy board uses STM32H750 microcontroller at @480MHz so it is already significantly slower than existing Teensy 4 @600MHz, and nowhere near to promised speed of i.MX RT1176 @1GHz. I was also recently participating in STM workshop and I asked them specifically if they plan 1GHz microcontrollers anytime soon and the answer was no. The fastest uC ST Micro has now is 550MHz STM32H725/735. It is still slower than Teensy 4. They seem to not like the idea of the microcontroller without on-board Flash and embedded Flash is limiting the manufacturing process and achievable clock speeds. So when it comes to maximum performance NXP controllers (flash-less) are going to keep the leading position for some time.
The Teensy has many advantages over the Daisy. I wish SDRAM would be on par, which is the only pro for the Daisy (aside from pure data support, which should be possible for Teensy). But maybe in the future release that will change. I dig NXP and that m7/m4 really is something to look forward to.
I saw the Teensy being used for many audio projects. So it is a solid choice. But there is this one guy who told me he'd needed something like SDRAM for his project in regards to size and speed. I guess others will, too.
I saw the Teensy being used for many audio projects. So it is a solid choice. But there is this one guy who told me he'd needed something like SDRAM for his project in regards to size and speed. I guess others will, too.
dbuergin
Member
Got my MIMXRT1170-EVK ordered from Mouser. Hopefully i'll get one
My wishes for a future Teensy board:
- i.MX RT 117X
- In principle something like Olimex did with their STM32 boards: https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware
- Ethernet fix on the board (WLAN ?)
- As much ports free to use
- Programmable like the other Teensy boards for the Arduino guys but also open for traditional JTAG programmers
- Arduino headers
My wishes for a future Teensy board:
- i.MX RT 117X
- In principle something like Olimex did with their STM32 boards: https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware
- Ethernet fix on the board (WLAN ?)
- As much ports free to use
- Programmable like the other Teensy boards for the Arduino guys but also open for traditional JTAG programmers
- Arduino headers
How about an RTX1170, mbed and Arduino compatible, with lots of flash and ram, basically an upgraded Teensy 4.1 with the addition of a 10 pin JTAG header, or at least empty drilled pads on 2x5 1.27mm centers. PlatformIO now supports very easy graphical hardware debugging with little configuration. Inexpensive tools like the EDU edition of Segger J-Link or the Black Magic tool can be had for well under $100. There is really no barrier to entry for hardware debugging anymore other than lack of access to the pins. Given the complexity of the teensy NXP processors, JTAG would be a welcome addition.
Another request for the new Teensy.
If you bring out the ethernet interface (please do) to header pins as you did on the Teensy 4.1, it would be desirable for those pins to be on same 2.54mm centers as the IO pins rather than the current 1.27mm centers. Many users have built baseboards or breakout boards that use the Teensy. It’s beneficial to make the board easily removeable for debugging, or replacement in case of failure. The simplest way to do that is to use a male header strip on one side and a mating female header strip on the other, so you can plug-in the Teensy.
Because the ethernet pins are not on the same centers as the IO pins, the height difference of standard headers means you can’t easily mount the boards using pluggable header strips. The only other option is to use extra long 1.27 mm headers soldered on both sides. I understand this may be a real estate issue, but please consider it when you design the new board.
If you bring out the ethernet interface (please do) to header pins as you did on the Teensy 4.1, it would be desirable for those pins to be on same 2.54mm centers as the IO pins rather than the current 1.27mm centers. Many users have built baseboards or breakout boards that use the Teensy. It’s beneficial to make the board easily removeable for debugging, or replacement in case of failure. The simplest way to do that is to use a male header strip on one side and a mating female header strip on the other, so you can plug-in the Teensy.
Because the ethernet pins are not on the same centers as the IO pins, the height difference of standard headers means you can’t easily mount the boards using pluggable header strips. The only other option is to use extra long 1.27 mm headers soldered on both sides. I understand this may be a real estate issue, but please consider it when you design the new board.
The first requirement is that an RTOS would need to be ported/supported fort the 1170 and (possibly?) integrated into Paul's Arduino implementation. Then you would be able to create tasks and assign them to one core or the other. You would still have a single setup() and loop(). See here for example: https://randomnerdtutorials.com/esp32-dual-core-arduino-ide/
You can play with this right now on ESP32 if you want to.
defragster
Senior Member+
Not seen where PJRC committed to RTOS? The 1170 has it's own core comms structure between the two non-symmetric cores (ESP32 and RP2040 are two of the same core). Maybe Paul will adapt for 1170 Arch?
So far the only posted note seen said ' the fast M7 starts first and can then power up the 400 MHz M4 '
Not sure if a single HEX could contain libs as needed for both cores and also differentiate the cores where the instruction set differs (float versus double FPU?) - others? Also if each has sole access to its own 'core' registers/devices independent of the other - clocks , GPIO, ??? ... are devices comingled where : SPI, WIRE, UART, (...) are a common resource or unique like two MCU's sitting side by side with unique pins and internal logic and 'some' shared?
There is a manual now - and some Dev/Ref hardware - perhaps details are available to explain ?
So far the only posted note seen said ' the fast M7 starts first and can then power up the 400 MHz M4 '
Not sure if a single HEX could contain libs as needed for both cores and also differentiate the cores where the instruction set differs (float versus double FPU?) - others? Also if each has sole access to its own 'core' registers/devices independent of the other - clocks , GPIO, ??? ... are devices comingled where : SPI, WIRE, UART, (...) are a common resource or unique like two MCU's sitting side by side with unique pins and internal logic and 'some' shared?
There is a manual now - and some Dev/Ref hardware - perhaps details are available to explain ?
The RP2040 also has no RTOS. Just a FIFO mailbox structure, a mutex lock, and a means to kick off code in the second core using a single program file running on the first.Obviously not ideal but it is enough to be useful without the development overhead of porting a RTOS. Maybe the same here?
defragster
Senior Member+
Seeing how RP2040 works is why that thread was interesting given they are out now and there scheme will get put to use in the C code version. So perhaps it may have some similarities where the it maps to 1170 features.
I haven't read the RT 1170 specs yet but hoping there is shared ram and an API to expose it. The Pico has only mailbox FIFOs and mutex locks. These are both blocking & interrupt driven in the C API. Not sure about micropython, given that it takes around 1mSec to update globals (but not locks) between cores.