Future Teensy features & pinout

[isaacjacobson]

I have a lot of mixed feelings about any new form factor. It's not completely out of the question, to answer directly. But it's absolutely the sort of thing that's much easier said than done (well).

Thanks for the detailed and direct response. I appreciate hearing about the specific challenges–– it shows that a lot of thought has gone into the consideration of such a form factor; and therefore, shows a lot of intention and wisdom has gone into the decision of not pursuing a new form factor (that is more integratabtle) yet.

I might be giving the MMOD another chance here soon. I know Sparkfun was (and still is) really dedicated to solving the issues. For all the reasons you listed, there's a high number of variables for what can cause issues and where things can go wrong. It seems that most of the issues of the MMOD are centered around proper positioning into the receptacle. It seems that tolerances and pcb slot shape variances can pave way to extra 'wiggle room' that cause some units to have a slightly increased probability of user error and positioning the MMOD barely out of alignment. The misalignment being so slight, that it only periodically affects a few pins (depending on tolerances of both the component and receptacle).

All in all –– appreciate the commitment of strategy and quality for current and future products. Trying to please everyone often pleases no one, so obviously you have say 'no' to some things to say 'yes' to the right things.

 

[PaulStoffregen]

Paul, would you be ok with another manufacturer going that route?
...
probably closer to an Edison footprint with the wider temperature range chips.

Yes, this would be ok. It must have a distinctive name not "Teensy" but could of course be described as built upon Teensy bootloader or technology. It would need to grow organically starting with PJRC-provided bootloader chips we have today which identify it as Teensy 4.0 or Teensy 4.1 in Teensy Loader. If it were to become popular and grow to enough sales (a very fuzzy goal to predict at this hypothetical stage) then we could look at more specific support in the software and bootloader, as MicroMod currently has, and at that time look at officially adding "Teensy" to the brand name. At some point even farther along a hypothetical growth curve, we could look at closer and more direct business cooperation. The key to crossing those hypothetical thresholds would be sustained volume sales.

Really just thinking about it since the higher volume could help us lower the costs to manufacture our products.

That certainly could be a benefit, but if this is your main motivation, I would urge you to consider carefully the hidden risks and challenges like discussed in msg #624 and also think carefully about whether you wish to continuously support customers building their own products. Consider carefully how you will balance carrying inventory versus the lead times you will offer your customers at different volume. Even if you are lucky to avoid all manufacturing issues, there are still many basic business challenges to consider, which may or may not be worthwhile if your main goal is only to lower cost on your existing products.

 

[brtaylor]

Yes, this would be ok. It must have a distinctive name not "Teensy" but could of course be described as built upon Teensy bootloader or technology. It would need to grow organically starting with PJRC-provided bootloader chips we have today which identify it as Teensy 4.0 or Teensy 4.1 in Teensy Loader. If it were to become popular and grow to enough sales (a very fuzzy goal to predict at this hypothetical stage) then we could look at more specific support in the software and bootloader, as MicroMod currently has, and at that time look at officially adding "Teensy" to the brand name. At some point even farther along a hypothetical growth curve, we could look at closer and more direct business cooperation. The key to crossing those hypothetical thresholds would be sustained volume sales.




That certainly could be a benefit, but if this is your main motivation, I would urge you to consider carefully the hidden risks and challenges like discussed in msg #624 and also think carefully about whether you wish to continuously support customers building their own products. Consider carefully how you will balance carrying inventory versus the lead times you will offer your customers at different volume. Even if you are lucky to avoid all manufacturing issues, there are still many basic business challenges to consider, which may or may not be worthwhile if your main goal is only to lower cost on your existing products.

Hi Paul, thanks! That's super helpful to have a better understanding of what that flow might look like. I'll certainly post here or reach out via email if / when we get to a more detailed design stage. Likely early next year.

 

[sicco]

On pinout for a next Teensy, the UARTs have hardware features for automatically controlling line direction for RS-485. That functionality can also be implemented in interrupt driven software that drives a GPIO pin, but sometimes that's just not fast enough. For example when code also uses SNVS GPR or RTC that can freeze the core for ~100 us because SNVS is clocked by 32kHz.

With the hardware feature in the iMRXRT1062 the LPUARTs RTS_B output can control the line mode between receive and transmit. As per section "Transceiver driver enable using RTS_B" in the iMRXRT1060 manual. However, on the current T4 I cannot use this because these are the only pads that would work and none are Teensy 4.1 pins (except GPIO_EMC_27, GPIO_EMC_29, but they're not real pins and used for the extra memory chips):

Serial6 = LPUART1_RTS_B GPIO_AD_B0_15​

Serial3 = LPUART2_RTS_B GPIO_AD_B1_01​

Serial4 = LPUART3_RTS_B GPIO_AD_B1_05 or GPIO_EMC_16​

Serial2 = LPUART4_RTS_B GPIO_EMC_18​

Serial8 = LPUART5_RTS_B GPIO_EMC_27​

Serial1 = LPUART6_RTS_B GPIO_EMC_29​

Serial7 = LPUART7_RTS_B GPIO_SD_B1_07​

Serial5 = LPUART8_RTS_B GPIO_SD_B0_03​

Rewiring through XBARs to other pins is not supported in the iMRXRT1062 it seems (?).

So if a future Teensy41++ would ever be designed, can we then get all these pins as 2.54" header pins please?

 

[jrraines]

https://arstechnica.com/gadgets/202...-faster-than-sata-speeds-for-microsd-devices/

Something to think about for a 4.1 successor.

 

[DrM]

I dunno, peripheral connectivity can be useful, it might have a cost in power and heat.

So, as always, you have to think about what it is for, and what other platform might be appropriate,

And, as a corollary, the broader the range of use cases, the more challenging it is to manage cost, size, power, heat, etc. and not overlap to a disadvantage with other possibly better suited platforms.

MCU's of course run cell phones, and at the other end they are displacing FPGA's in some markets where they overlap in performance and reducing cost and time for firmware development is important.

And yet, DSP's continue to exist even at 10's of MHz because of the still low power requirement and cost for certain classes of signal processing functions.(*)

So, let's think about how many different things it is for, what else is in that space, and what makes sense, whether one or several.

(*) That some companies try to build in pc-os-like features and VC-like IDE's for DSPs, is a feature of lawyers, inverstors and MBA's running those companies rather than engineers who actually work with the device.

 

[DrM]

MCUs are incredibly versatile and are used in a wide range of applications,

Yes, and therefore, even more so, it is important to decide what this platform is for, or if perhaps there should be more than one platform.