Future Teensy features & pinout

[kdharbert]

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?

[manitou]

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?

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...er/acmpdac.ino
https://forum.pjrc.com/threads/54711...l=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/

[kdharbert]

Thanks...already tried the search and it didn't look promising. I'll retry..

[tomas]

Just for what it is worth NXP i.MX RT1176 -based products start to emerge: https://coral.ai/products/dev-board-micro/

[RichardL]

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)

[Morphius]

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?

[mercury0x0d]

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:

...
I'm definitely planning to make a larger form factor Teensy with the 1170 chip.
...

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

[Morphius]

Time is supposedly relative, what is a few weeks in a 1Ghz core ��

[u1550]

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.

I love the idea a 68k footprint
suitable sockets are available too.

[frankzappa]

I’d like a teensy 4 with good quality analog inputs. Right now they are quite noisy.

[LenSamuelson]

I’d like a teensy 4 with good quality analog inputs. Right now they are quite noisy.

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.

[frankzappa]

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.

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.