Future Teensy features & pinout

I'm wondering if there is a io xbar per core and pins assigned to each core or if there is a system-wide xbar which means pins can be assigned to either core. I'd love to know the details, but given the NDA, knowing that Paul has these details would already be nice.
 
I can see where you're going with that.

One application that seems immediately obvious to me is CNC/3D printer controllers. One core speaks G-code, handles low-level I/O, generates steps, reads encoders (if any are used), etc., while the other runs a fancy GUI. That is basically the same thing as using OctoPrint on a RPi to control a simpler 3D printer controller, and I did that for years. Point being, there will be use cases where the two cores are running code that's so different, and which necessarily has such loose coupling, that it wouldn't matter whether they communicated through shared memory or some kind of IPC mechanism.

If they understand the same opcodes, but have different FPUs, then putting code that can run on either core in the same binary could require the use of macros that say "this code can use 64-bit floats" or "this code can't use 64-bit floats." In this case, I think the architecture dictates the use cases to a fair extent, and it would be simpler to require distinct programs that talk over an IPC mechanism.

This new device has a PXP (pixel pipeline, a simple GPU that does scaling, rotation, and blending) that looks the same as the one in the current T4.x chips. A library that talks to that hardware would be useful.
 
I find useful that one core is for handling the Ethernet (you have at least 3 of them) and the other core for the application.
 
As MCUs do more and more, their timing predictability (and probably code reliability) has been declining. Interrupts, DMA, cache misses, heap use, preemptive threads, etc. So I like the idea of a second processor to return to simple "doing nothing else" loops.
 
jonr said:
As MCUs do more and more, their timing predictability (and probably code reliability) has been declining. Interrupts, DMA, cache misses, heap use, preemptive threads, etc. So I like the idea of a second processor to return to simple "doing nothing else" loops.
Click to expand...

Indeed - seems one big benefit is having a data collector/displayer busily doing those tasks fitfully as needed, and allowing the other processor keep heads down processing ready data and generating output/results.

The UNAV on a T_3.6 managed - but doing the data processing could take some time where it was 'offline' for some ms interrupting gathering new GPS or 9DOF data. When it came to sending out the data for viewing a second Teensy pulling the output over @tonton81's created SPI Transfer to send to the PC for display and not slow processing.

Makes one wonder about USB output if both cores participate - maybe a good use for DUAL USB.

With both of these cores exceeding or quadrupling the T_3.6 processing speed the UNAV work would go much better in that case. Other use cases will present themselves - but for that and similar workflow it looks like a big win.
 
jonr said:
So I like the idea of a second processor to return to simple "doing nothing else" loops.
Click to expand...

But if it's sharing anything with the other core, waiting on semphores or mutexes or other thread synchronization would need to be one of those "nothing else" variable timing things needing to be done.
 
For me, a common use would be one core doing input and calculations and a second core handling high speed asynchronous output. They share a single, atomic ram variable but there is no synchronization. What does that leave for variable timing - a wait state/cache miss for access to the variable?
 
We have the T4's smart peripherals to handle extremely low-level details. In my robotics-centric world I see the M4 as a highly programmable mid-level controller, well positioned to offload processing details from the M7. There's so many other uses for these asymmetric processor pairs!

In terms of Paul's hardware, I'm currently hoping for T4.0 pin compatibility. Or maybe a .2" widening with two rows down each side; the inner rows being usable for stand-alone T4.0 compatibility and the outer rows available for expanded use. I'd love to drop one of these into my existing T4.0 board; I can handle the extra width on the board. Layout for Paul is going to be tough!

I'm ready to put in an order now!
 
This post points out that some people are going to other platforms because the T4.x doesn't expose some pins that are useful to driving an LCD, also rendering the MCU's built-in graphics capabilities moot. I think others have said it earlier in the thread, but some solder pads on the bottom surface could solve this.

I like the extra row idea, but some of us are using fixtures to hold the boards in place, and if the form factor is changed we need new fixtures. If the device is compact, the enclosure itself might have to be redone.

I think a poll would be a good way to find out some numbers on whether people want solder pads or more rows.
 
I really appreciated the idea to solder extra ram and flash devices at the bottom of the T4.1. May be same can be done to extend pins via an smd connector?
 
Pin compatible with t4.1 but extra outside rows seems ideal to me! maybe change sdcard to pins instead of the slot.
 
Every so often I check NXP for information on the 1170 family and they released a new fact sheet a few days ago that also has some ordering information for the evaluation board. So after a little bit of Google searching I found the Mouser page for it as well as their expected date of getting some stock in on 2/8/2021. Once I found that I did a little more searching on Mouser and found the expected date for the 1176 chip by it self which they expect to get some stock in on 3/30/2021 for that. So if the COVID situation clears up some time soon we may be testing an 1170 based Teensy within the next year or so. If it's anything like the Teensy 4 beta was I suspect a few people will get the evaluation board some time after it's released and do some preliminary testing on their own even before the Teensy version is released.
MIMXRT1170-EVK: https://www.mouser.com/ProductDetail/NXP-Semiconductors/MIMXRT1170-EVK?qs=rkhjVJ6/3EKncoHHhXsh7Q==
MIMXRT1176AVM8A: https://www.mouser.com/ProductDetail/NXP-Semiconductors/MIMXRT1176AVM8A?qs=DPoM0jnrROX6oQJA2LlTTQ==
 
Funny on 10/28 ARROW had listing for the 1176-EVK - with perhaps similar expected dates - now that shared link and any new search comes up #404:not found

And their page had actual picture and more detail than the mouser page - matched the Fact Sheet.

Looks like they reformatted the Fact Sheet and called it REV1 - not seeing anything but layout changed?
 
It has a little bit more information of the different 1170 processors that they will have available, though I suspect the Teensy will be using the 1176 that has all the features, as well as what their evaluation board consists of.
 
Had Rev 0 and 1 PDF side by side - before overwriting Rev0 - and both seemed to have the same details and tables - though maybe something was missed in that scan. Last update NXP sent an email where checked a box asking for updates - this one they did not.

Not sure why Arrow took info offline - except maybe to update for new Fact Sheet - but oddly all imxrt 1170/1176 searches were 404'd
 
That would make more sense, I missed Rev 0 and thought you were referring to the i.MX RT Series Crossover MCU Fact Sheet .
 
Might be a good idea to extend the RTOS support, and to begin adding support to the most important libraries...
COVID gives some/most of us some more time now.. :)

A dual core Teensy will not be very useful without software.. the questions is, what direction Paul decides to go.
We have a big plus now - we can take a look at the (now stable) ESP32 libs. If we make it compatible to ESP, user can switch to Teensy without too much hassle.

Even the most basic things need some adjustment. i.e. basics like malloc(), Serial.print(), spi, i2c..


I think it is clear that this is too much work for a single person.
 
Last edited:
Having compatibility is nice to have but as the family of features are most definitely growing what is to decided features to chop and what to keep just because of some silly format compatibility. they all seem very important to me and it of course makes sense to have the Cadillac and a VW bug. the family is growing so the Cadillac can transport the whole family but the VW bug is still nice to drive. sorry for the lame analogy but trying to keep the genie in the bottle from this point on is really becoming a burden and or stress to to many people.
it is all part of growing so the possibility of a standard format and a pro format seems a very viable option in my book which would most likely require Paul to receive some help in the near future. i have read some amazing posts and observed very gifted coders on this forum that i am sure would be darn happy to assist the legacy and expansion of the Arduino and most definitely the Teensy tradition of being the best in my book.

I for one would vote for a pro version or a breakout version like the Tall Dog breakout board i bought for my T3.6 and with that said my future project would require such a chip/features and breakout board.

Thank you very much Paul for your talents and contribution to the Arduino community and lets not forget the unsung hero's, the gifted coders, i thank you all....

Regards,
Marathonman
 
You must log in or register to reply here.
Back
Top