Future Teensy features & pinout

I have a project where I need dedicated analog comparators with digital output that compare an input with a DAC-generated reference from the MCU. I've been using an MCU with three onboard comparators, a DAC and some useful hardware LUT features. I didn't think Teensy units had these features, but now that I read the NXP datasheet, it seems there are four analog comparators. Documentation in the datasheet is light and I don't remember seeing any mention in Teensy docs.

Are these features something that could be enabled at present with a code library? If not, could they be enabled easily in a future release?
 
kdharbert said:
I have a project where I need dedicated analog comparators with digital output that compare an input with a DAC-generated reference from the MCU. I've been using an MCU with three onboard comparators, a DAC and some useful hardware LUT features. I didn't think Teensy units had these features, but now that I read the NXP datasheet, it seems there are four analog comparators. Documentation in the datasheet is light and I don't remember seeing any mention in Teensy docs.

Are these features something that could be enabled at present with a code library? If not, could they be enabled easily in a future release?
Click to expand...

I think the Teensy 4 NXP SDK has examples using the ACMP comparators and DACs, see boards/evkmimxrt1060/driver_examples/cmp/polling/. The T4 "internal" DACs are only 6-bit. Here is a simple proof-of-concept:
https://github.com/manitou48/teensy4/blob/master/acmpdac.ino :D
https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195602&viewfull=1#post195602

and a thread on T4 comparators using XBAR to redirect ACMP output.

you might search the forums for "comparator" ...

the new NXP 1170 has a similar ACMP comparator architecture with 8-bit internal DAC (0 to 1.8v). See 1170 SDK example
boards/evkmimxrt1170/driver_examples/acmp/polling/
 
Last edited:
Future Teensy FreqCount() enhancement
It would be good for those of us wishing to squeeze the last ounce of performance from FreqCount() (and possible FreqMeasure()) if the clock used by those functions could be from an external precision source.


The microprocessor clock on Teensy is derived from a budget price crystal because for most applications the exact frequency does not matter too much, give or take a few dozen parts per million. For my Lab-In-A-Box project I would like the frequency to be more precise and less subject to temperature variation. My typical user would most likely be synchronising most of his test bench equipment to a master 10MHz source derived from a GPS satellite receiver.


The Teensy 5.x clock (??) could ideally be derived from a stable input provide by the user; maybe by including a line of code such as <ExtRefClock(Pin#n,FF)> where 'FF' is the frequency of the external source. The Teensy would start up normally using the on board Xtal, then when it encountered the instruction to use the external input would confirm it was present and switch over to using it.


As an alternative could the clock used by FreqCount() be input on a pin and just that section of the Teensy's logic switched to use it? (Might that could even be possible with the existing Teensy4.x family?) I can foresee problems doing this if sections of the on-board functionality are derived from PLL multipliers from the base crystal frequency.... but if you don't ask you don't get!


As mentioned before, a precision GPS locked 10MHz clock is not uncommon in an electronics lab so 10MHz would be a good fixed frequency to consider if a wide range of values for 'FF' is a challenge.


As a minimum, how about providing an easy-to-do track cut and a pad to allow an input from a GPS locked clock or a temperature compensated oscillator to replace the on-board clock?


PS: I put clock stability ahead of frequency accuracy, a stable fixed error can be calibrated out.


RichardL
(G8CDD)
 
Voting for 6 complimentary pins on a eFlexPWM as to use deadtime insertion for BLDC commutation purposes. The dual core nature of the RT1170 makes it very cool for having the 1Ghz core work on the motor and the M4 do the communication/ HMI Definitely room for future progress in ebike/eMTB optimization. Any news about launch?
 
Form factor idea for the 1170-based Teensy

So I'm new here but after being blown away by the sheer power of my first Teensy, the 4.1, I just had to search for any hints as to the next version which might be released, and found this thread. Thanks Paul and Robin (and whoever else put in time on making these microcontrollers completely mental) for the awesome work!

Ok, on to my two cents:


PaulStoffregen said:
...
I'm definitely planning to make a larger form factor Teensy with the 1170 chip.
...
Click to expand...

Perhaps a 64-DIP footprint, as found on some older CPUs? The Motorola 68000, for example, came in this package, with versions sporting both the standard 2.54 mm pin pitch and a more condensed 1.78 mm pitch, for which adapters could be used to suit applications which originally called for the larger model. Similarly, such an adapter could be made to use a 1.78 mm pitch Teensy with breadboards.

On a side note, it would be pretty humorous to hold the two side-by-side knowing the Teensy could totally obliterate the 68K despite being the very same size lol
 
CC64FF1C-34CB-4F31-B6FC-C5DDE8036038.jpg

Time is supposedly relative, what is a few weeks in a 1Ghz core &#55358;&#56623;
 
mercury0x0d said:
Perhaps a 64-DIP footprint, as found on some older CPUs? The Motorola 68000, for example, came in this package, with versions sporting both the standard 2.54 mm pin pitch and a more condensed 1.78 mm pitch, for which adapters could be used to suit applications which originally called for the larger model.
Click to expand...

I love the idea a 68k footprint :)
suitable sockets are available too.
 
NXP Kinetis analog: OK for medium precision...

frankzappa said:
I’d like a teensy 4 with good quality analog inputs. Right now they are quite noisy.
Click to expand...

My coworkers and I have been using Kinetis (K60, K61, approximately Teensy 3.6-generation) parts for a fairly large data acquisition system. During early design, we were optimistic that the board-space vs noise tradeoff would be acceptable. It is but just barely. We are finding that noise is an issue. If/when we do a future generation of the product we are seriously considering off-chip ADCs, using either SPI or I2S. That would allow us to shrink the analog signal chain to allow improved isolation of analog from digital signal paths.

IMHO, NXP's decision to change the labeling of their ADCs from "16-bit" to "12-bit" is an indication of the challenges they face in integrating mixed signal analog and high speed digital circuitry. Integrated analog will likely be noisy for analog measurement beyond 12 or 13 bits ENOB ("effective number of bits").

YMMV... For example, a project with low bandwidth requirements could use software-based signal conditioning to improve the picture.
 
LenSamuelson said:
My coworkers and I have been using Kinetis (K60, K61, approximately Teensy 3.6-generation) parts for a fairly large data acquisition system. During early design, we were optimistic that the board-space vs noise tradeoff would be acceptable. It is but just barely. We are finding that noise is an issue. If/when we do a future generation of the product we are seriously considering off-chip ADCs, using either SPI or I2S. That would allow us to shrink the analog signal chain to allow improved isolation of analog from digital signal paths.

IMHO, NXP's decision to change the labeling of their ADCs from "16-bit" to "12-bit" is an indication of the challenges they face in integrating mixed signal analog and high speed digital circuitry. Integrated analog will likely be noisy for analog measurement beyond 12 or 13 bits ENOB ("effective number of bits").

YMMV... For example, a project with low bandwidth requirements could use software-based signal conditioning to improve the picture.
Click to expand...

Yeah I also think it has to do with the separation of analog and digital components. The T3.6 has analog ground which the T4 doesn’t have. I think paul said it wasn’t possible to separate them.

I’m getting around the problem with software filtering but it would have been even better to have both a clean signal AND filtering.
 
The teensy 4/ 4.1 schematics show there is a separate power pin for the ADC, and the iMXRT1060 (VDDA_ADC_3P3) which is also the voltage reference for the ADCs. documentation about it seems a bit contradictory though.

NXP Semiconductors
Data Sheet: Technical Data
Document Number: IMXRT1060IEC
Rev. 3, 03/2022

1:page 25

VDDA_ADC_3P3 must be
powered even if the ADC is not
used.
VDDA_ADC_3P3 cannot be
powered when the other SoC
supplies (except VDD_SNVS_IN)
are off

2: page 30

NOTE
USB_OTG1_VBUS, USB_OTG2_VBUS, and VDDA_ADC_3P3 are not
part of the power supply sequence and may be powered at any time.

Anyway, if the new chip has the same power scheme, it could get filtered power or even a separate "clean" regulator for that pin, and ADC performance would likely be less noisy. I can't really test it myself because the chip is BGA, and i don't want to destroy a teensy.
 
neutron7 said:
The teensy 4/ 4.1 schematics show there is a separate power pin for the ADC, and the iMXRT1060 (VDDA_ADC_3P3) which is also the voltage reference for the ADCs. documentation about it seems a bit contradictory though.

NXP Semiconductors
Data Sheet: Technical Data
Document Number: IMXRT1060IEC
Rev. 3, 03/2022

1:page 25

VDDA_ADC_3P3 must be
powered even if the ADC is not
used.
VDDA_ADC_3P3 cannot be
powered when the other SoC
supplies (except VDD_SNVS_IN)
are off

2: page 30

NOTE
USB_OTG1_VBUS, USB_OTG2_VBUS, and VDDA_ADC_3P3 are not
part of the power supply sequence and may be powered at any time.

Anyway, if the new chip has the same power scheme, it could get filtered power or even a separate "clean" regulator for that pin, and ADC performance would likely be less noisy. I can't really test it myself because the chip is BGA, and i don't want to destroy a teensy.
Click to expand...

Hmmm… is this something one could test? I have a few spare teensies.
 
@paulstoffregen Hi Paul, how is it going on this project? Are we likely to see boards in the coming months? There is some nifty stuff I am looking forward to using it for.
 
Power delivery idea for future Teensy 4.x

Also, I'd love to see the possibility of getting more power out of the board via the USB port using the USB-PD standard or a STUSB4500 (or similar chip). Being able to power more stuff directly would be awesome!
 
mercury0x0d said:
Also, I'd love to see the possibility of getting more power out of the board via the USB port using the USB-PD standard or a STUSB4500 (or similar chip). Being able to power more stuff directly would be awesome!
Click to expand...

I'm not Paul, but I suspect it won't go into the Teensy proper, as it likely will raise the costs that relatively few people would use.

I've seen various USB C-PD trigger cables that when plugged into a USB C-PD system will ask for a fixed voltage (5v, 9v, 12v, 15v, 20v). Adafruit just announced their own version of the cables that ask for 5 amps at each of the different voltages. However, I don't recall any trigger cable that asks for specifically 5 volts (in order to get higher amps). If you need one of the other voltages for motors and such, then use that voltage and drop the voltage to 5 volts with a buck converter for the Teensy to use.
 
MichaelMeissner said:
I'm not Paul, but I suspect it won't go into the Teensy proper, as it likely will raise the costs that relatively few people would use.

I've seen various USB C-PD trigger cables that when plugged into a USB C-PD system will ask for a fixed voltage (5v, 9v, 12v, 15v, 20v). Adafruit just announced their own version of the cables that ask for 5 amps at each of the different voltages. However, I don't recall any trigger cable that asks for specifically 5 volts (in order to get higher amps). If you need one of the other voltages for motors and such, then use that voltage and drop the voltage to 5 volts with a buck converter for the Teensy to use.
Click to expand...

It'd be trivial to add 5v/3a since there's an entire secondary microcontroller on the board. Hook up the required 5.1k resistors and measure the voltages to see if you can draw more than 500mA.

If that cortex-m0+ KL02 has the space an entire PD stack could be loaded but you'd really want input protection.
 
I was just looking at the STM F7, 2.4MHz ADC, DAC, some offer 16 bits, and typically 1M each Ram and Flash. I think that might work out well for my uses, linear ccd and analog data acquisition with outputted waveform. Would it make sense to base a teensy product on that series?
 
Since wish dates are approaching... Would it be possible for the new teensy to come with a USB-C connector instead of the usual microUSB?
 
USB-C +1

Also:
It would be good for those of us wishing to squeeze the last ounce of performance from FreqCount() if the clock used could optionally be from an external precision source (See #555 in this thread)


 
wish.png
I'd personally like the future Teensy to use the 1176 which has the 2nd CPU and 2D GPU with Vector Acceleration and OpenVG capabilities.
(i.MX RT1172 has only the 2D GPU. i.MX RT1173 has both the 2nd CPU and 2D GPU, but is Industrial only. i.MX RT1176 has both the 2nd CPU and 2D GPU.)
Big wish, I know, since it would probably increase the cost by a lot. However, I feel like the future Teensy should have a 2D GPU at the very least using the 1172, if the 1176 is too expensive.

(I read the entire thread and didn't see anyone else request this, so it probably won't happen. Though, it would be really cool to use OpenVG.)
 
I can see an embedded application with high level graphics, the firestick for example. But at what point should we just get a pc?

BTW, I have been working with the Teensy 4.0 this week, finally. It is absolutely fantastic! The faster usb makes all the difference in the world for me. And he ADC at 1usec/12bits is just fine for my work at the moment. If only it had a DAC...
 
You must log in or register to reply here.
Back
Top