Suggest next Teensy with Cortex M7

Status
Not open for further replies.
For my uses, I would love to see more RAM and flash and more inter-connectivity options while keeping a small form factor and low price point. Granted the 3.6 (and even 3.2) got pretty much everything covered for me now (although more RAM would always be nice), but I would love to see the onboard Ethernet en SDIO interface working reliably before development attention shifts to the 4.0. I have however no doubt this will be the case :) .

Concerning more RAM, there is the possibility of a T3.6++ with SDRAM capability (as added board)
I was also wondering if someone is coming up with a flexible concept for multi-MCU interconnects? I once tested 3 T3.2 connected with SPI, so it is possible.
 
Concerning more RAM, there is the possibility of a T3.6++ with SDRAM capability (as added board)
I was also wondering if someone is coming up with a flexible concept for multi-MCU interconnects? I once tested 3 T3.2 connected with SPI, so it is possible.

I have a pretty lightweight protocol that I use for connecting Teensys that I can post. I use I2C (i2c_t3) with a 3 MHz clock.
 
It will be interesting to see if you go with a wildly different pin layout or numbering for Teensy 4.0 as opposed to 3.x. You've done an excellent job in maintaining the majority of pin compatibility between the LC, 3.0, 3.1, 3.2, 3.5, and 3.6. But I can imagine it is growing creaky to keep this compatibility.

If possible, I would suggest having VUSB, AREF, and VBAT on the main rows of pins rather than inside and on the back. Reset and program also, but those are more special purpose, and they can live as interior pins. But if not, that is also fine.

If pin config changed, would hope that more consideration given for noise. Aref and analog ground need a little more protection from that evil digital stuff. 600MHz is an order of magnitude greater than what we typically use (22MHz or 44MHz for T3.2). Otherwise, logistics of another pin-out would be significant for some.

But if that what PJRC's adoring fans want, so be it. Will be that cranky old geezer still using my stash of T3.1s and T3.2s while yelling at the rest of you to get off of my lawn (recently used last 2313).
 
I believe you really need to be programming in assembly on an 8 bit chip, perhaps even 8051 or HC11, to qualify for old "you kids get off my lawn" geezer status.
 
Who is the intended customer for that Teensy? I have a hard time filling up the CPU of the 3.5, although I'm out of I/O (again!) Developing applications that use all that power is significant work.

Same here. Developing with a T3.5 for a calibration bench, and out of I/O, but much flash remaining. Will probably go with two or three T3.2s.

Also, if less analog, and 3V only, and external flash, and 600 MHz is important to me, I can get it today in a Raspberry Pi Zero W, cheaper than a Teensy. Then I can use all that power to run Python or something instead of C, and be back at 8 bit AVR speeds...

External memory = noise. So would do serious analog on separate board. External memory, no signal conditioning, high clock rate, media controllers, security systems, etc - this is the stuff of an embedded OS. Schedulers ok, but no want OS. Is running an OS a PJRC design intention?

Freaking amazing what you kids are stuffing into ICs these days.
 
Is running an OS a PJRC design intention?

No, certainly not anything like Linux is planned.

However, the recent work on Arduino event programming and planned improvements in SD, USB Host, Ethernet and other libraries are meant to bring much more functionality similar to some of what you get from an OS.

My current plan is to *not* require an RTOS, but to work towards APIs and reentrant design that can be more easily used with an RTOS.
 
I believe you really need to be programming in assembly on an 8 bit chip, perhaps even 8051 or HC11, to qualify for old "you kids get off my lawn" geezer status.

Actually, it would be "get off of my dirt". My 'museum' drawers have 8080s (curse the 2-phase clock and sequencing of the three power rails) and Z80s from S100 projects. 8051/6502 assembler were easy. Never did anything with the 6811. But M0 and M4 assembly hurts my old brain; so this i.MX RT would probably be a deadly end to my retirement plans. But if you build it, will buy it.
 
Even though it's exactly the same instruction set as M4, still kinda strange to think we'll soon be running with a superscaler processor capable of (sometimes) executing 2 instructions per clock, and with branch prediction in the pipeline where (predicted) branches no longer cost a couple extra cycles.
 
Superscalar is not so bad. When the embedded chips start doing out-of-order memory transactions, I will throw up my hands in resignation :)
 
I think it would be really nice to have a very small teensy (without any header pins) that has a high-density connector to get all the available pins.
This would make it much easier to create small products that still have the bootloader built-in.

You could do all your testing on the breadboard-friendly teensy, move to small-to-medium production with the teensy-HD (high-density) version, and then build your own custom teensy for large production volumes.
Possible?
 
Last edited:
@ Linuxgeek - is there that much gained having a Teensy PCB with a special connector that you have to source and mount to your PCB over rolling the parts directly onto your PCB?

Not disputing a better method from prototype to product would be great but not sure if special connectors and mounting hardware are they way.
 
Doesn't help everyone, but for those that need to keep it small, it would really help.
And I would think it might not be too complicated for pjrc to dump all (or subset) the connections to the connector.

If size doesn't matter, then I don't think there's any gain, unless you use it to get connections that are left off the board.
 
its not so bad using 4 rows of headers on the 3.5/3.6
but having access to the busses is what makes us wanting to use that many pins, even though the others are not used

add some flat FPC cables to open more possibilities, for different setups/custom breakouts ;)
 
By the way:

don't for one second imagine I'm going to abandon breadboard compatibility for a high density connector like Intel did with Edison

I hear you on the Edison fiasco!

I was thinking of something like the Teensy 3.2 form factor along the top/bottom edge, with "one of each" of all the important ports (and maybe two of some,) and then a HD connector on the back of the board for all the additional goodies.

Also, regarding 5V being "old tech," that may be true, but I'm currently interfacing with the following 5V devices:
- SPI RGB LED strips (newer than NeoPixels and WS2801!)
- Ultrasonic range finders
- TFT touch display
- RC PWM receiver with telemetry

These are all good value-for-money, readily available, not-discontinued parts.
 
Not sure if the M7 is going to fit on the normal size teensy 3.2 or 3.6 form factor. I have a OpenMV cam that uses a M7 and its a bit wider and adding support chips, not sure final size. My guess its going to have to be a bit wider and longer. Don't mind a HD connector but would like to see an option where PRJC offers units with the underside pins already soldered on :). As for 5v tolerance on the pins. I agree that there are still a lot of robotic sensors that use 5v like the Ultrasonic Range finders, RC PWM, both of which I use. Motor shields are a hit and miss depending on power requirements. I have seen some that can use 3v but most I think (this is just seat of pants) would probably still use 5v. Servo's I believe the signal can be as low a 3.3v. Power would definitely have to be a separate. GPS and my 3dr radio are serial so I would assume that would still work but power, again would have to separate unless there will be 5v out supplied on the new teensy like now.

These are just some random thoughts.
 
Not sure if the M7 is going to fit on the normal size teensy 3.2 or 3.6 form factor. I have a OpenMV cam that uses a M7 and its a bit wider and adding support chips, not sure final size. My guess its going to have to be a bit wider and longer. Don't mind a HD connector but would like to see an option where PRJC offers units with the underside pins already soldered on :). As for 5v tolerance on the pins. I agree that there are still a lot of robotic sensors that use 5v like the Ultrasonic Range finders, RC PWM, both of which I use. Motor shields are a hit and miss depending on power requirements. I have seen some that can use 3v but most I think (this is just seat of pants) would probably still use 5v. Servo's I believe the signal can be as low a 3.3v. Power would definitely have to be a separate. GPS and my 3dr radio are serial so I would assume that would still work but power, again would have to separate unless there will be 5v out supplied on the new teensy like now.

These are just some random thoughts.

Let me just confirm from years of experience at the University of Minnesota UAV Labs, that the RC PWM signal can be 3.3V. Also, many GPS receivers and radio modems can use 3.3V TTL with a 5V source (i.e. a 5V power source and a 3.3V TX and RX signal). Many RC receivers operate this way as well, they use a 5V power source, but send 3.3V PWM and SBUS signals.

So far, since the Teensy 3.6 has been released, I haven't run into any issues being limited to 3.3V signal voltages. But I am careful to check before connecting devices.
 
Thanks for the info Brian. Don't have much experience with 3.3v systems. Always made me nervous, getting less nervous now.
 
Let me just confirm from years of experience at the University of Minnesota UAV Labs, that the RC PWM signal can be 3.3V. Also, many GPS receivers and radio modems can use 3.3V TTL with a 5V source (i.e. a 5V power source and a 3.3V TX and RX signal). Many RC receivers operate this way as well, they use a 5V power source, but send 3.3V PWM and SBUS signals.
My years of experience at the Ghent University Electrical Energy Lab have left me a bit more worried though ;) . Most 5V TTL parts I use (serial transceivers, LCDs, power ICs etc) are of course happy to receive input at 3.3V, but output signals at their VCC level. This could easily destroy a non 5V-tolerant MCU. Nothing some resistors or a level shifter can't solve, but the engineer must keep an eye out for signal levels. Luckily nowadays most TTL parts are drop-in replaceable with a 3.3V version. LCD's, especially the cheaper ones, in my experience tend to stay at 5V but luckily only require one-way communication in most cases.
 
Are you at liberty to elaborate on this point a little?

Nope, sorry, anything that's not on NXP's public website is covered by NDA. They will publish all the info (unlike certain Chinese chips...) but probably not until the chips are actually for regular sale.

But just from looking at the "fact sheet", you can see there's no DAC and the ADC is only claimed to be 12 bits.
 
Last edited:
But just from looking at the "fact sheet", you can see there's no DAC and the ADC is only claimed to be 12 bits.

I think this makes sense given the noise problem & the target market, and would say that alongside the release of a Cortex M7 it would make sense for the community (or Paul, time permitting) to release a small reference board in the same form factor as the Teensy (perhaps piggybacking the DIO pins with DIO pins set to high impedance) with an ADC/DAC/Reference (2 channels of each with a multiplexer on the ADC to 8-16 pins) with decent software support.

I'm excited to think about this being released in a few years but I am in the fortunate position that the Teensy 3.6 has just enough horsepower for my most demanding projects. :)
 
Hello all,

I would like to add few thoughts to this interesting thread:

not so many are aware of the application differences between a realtime hardware and a Linux OS board with a scheduler, my job is electronic engineer, independent contractor and almost all my new customers, they usually come with the request to implement every kind of products you can imagine with the Raspberry PI and Linux, even for robots, controllers, UAV, all applications typical of the realtime world. This attitude is largely influenced by hackers/makers community, which I support of course, but not beyond the scope of exploration, testing ideas and laboratory to earn knowledge, industrial products requires appropriate design.

Even if exists a Linux kernel version with a pseudo realtime scheduler, its proper applications are still limited to video/medias processing, VOIP, audio processing, applications typical of a shared OS environment as desktop or industrial appliances. Deep learning or OpenCV are software applications for an high level OS for instance.
Realtime MCUs are designed for other kind of applications where deterministic interruptions are crucial, GPIO events or timed functions needs to get executed at precise moments, examples are self balancing robots or UAV controllers such as the Pixhawk. Recently BleagleBone came out with a Blue version specific for robotics, the Linux OS is running on the ARM cortex-A8 core but all the realtime stuff get executed inside 2 integrated PRU 32-bit realtime microcontrollers specific for those kind of applications, there is no way to achieve the execution of realtime tasks inside an OS running on a Raspberry PI for instance.

So different applications require different hardware architectures.
The Teensy 4.0 aims to improve and expand the design possibilities in the realtime world, maybe with a realtime OS such as NUTTX or FREERTOS, there are many more..

These days I am designing a device with RTK+PPK GPS capabilities based on Teensy 3.6, it needs to have a maximum acceptable latency in order of the ms, added with other heavy processing of the readings from sensors.
The future Teensy 4.0 will be useful in my case, because one day I need to add an integrated crypto hardware accelerator in order to support encrypted datastream in realtime and at the same time, to integrate all the features of an UAV controller.

I feel we are just at the beginning with these high performances realtime MCUs, there are plenty of real world applications for the next Teensy 4.0, applications that finally can be implemented with just a single MCU, so I am happy to hear about this new version.

Best luck Paul!
 
Last edited:
Status
Not open for further replies.
Back
Top