Future Teensy features & pinout

Ah, thank you both.
It has hardware semaphores and messaging..
So many features. wow.

Edit. So what does this mean for us "consumers" - if the M4 core has NO body biasing?
 
Tim, for sure the EVKs are nice.
But I'd prefer a simple "Breakout". And to be able to use all these HW-Modules.

2020-12-20 23_33_32-Start.png
^^^^^^ that would be nice ;)

If we get a few GHz more we can do it in Software, someday..
 

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.
 
ERR050643: GPIO: During initial power-up, a brief pull-up pulse could occur on theport pins
Description:By default (reset state), the GPIO pins are in the high-Z state and typically stay high-Z until theapplication code changes its state. The internal pull-up and internal pull-down resistors aredisabled by default.During power up, the internal pull-up resistor on the GPIO_AD, GPIO_LPSR, and DISP_B2pins may enable during the early part of the IO ramp up, resulting in a brief pull-up currentpulse on some port pins that drops to zero before the VDD supplies reach the minimumoperating voltage.
Workaround:
A pulldown resistor (~10K) can be added to the GPIO pin(s) to minimize the peak voltagewhere the application is sensitive to potential pulses

Time to redesign my flamethrower ;)
I wonder how short the brief pulse will be.
 
I also would like to know if part number to be used in future teensy will be i.MX RT1176 and what is planned release date of 1GHz Teensy, please?

Happy festive season to everyone!
 
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.
 
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.
 
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.
 
I'm curious how the dual core will be realized (the i.MX RT1170 has both a 1ghz and 400mhz core). Will it be two main loops or will one have to upload two firmwares/address both cores separately?
 
I'm curious how the dual core will be realized (the i.MX RT1170 has both a 1ghz and 400mhz core). Will it be two main loops or will one have to upload two firmwares/address both cores separately?

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.
 
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 ?
 
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?
 
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?

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.
 
Back
Top