TeensyTimerTool

Success. I downloaded your latest from GitHub, and the PIT now runs at expected frequency, without any compensation factor required. thank you :)
 
Great, I'll do some testing these days and generate a new release for the library manager afterwards.
 
The overview description of the GPT timer module in the I.MX RT1060 Reference Manual includes this:
External hardware can send the GPT a "capture event" signal on an input pin
AFAIK the TTT doesn't support this, but is there a way to hook an attachInterrupt() pin sequence into TTT ? Or IntervalTimer ?
Suggestions appreciated ...
 
The overview description of the GPT timer module in the I.MX RT1060 Reference Manual includes this:

AFAIK the TTT doesn't support this, but is there a way to hook an attachInterrupt() pin sequence into TTT ? Or IntervalTimer ?
Suggestions appreciated ...
You can configure GPT input capture on pins 15 and 40. This is outside the scope of TTT, which is only concerned with periodic timers
 
I recently posted a sketch that is based on Manitou's work with GPT input capture. I had some trouble with his test sketch, but I know that what I posted does work. Link below.


@ninja2, what I meant in my comment is that TTT focuses on one use of timers, which is periodic interrupts. Some of the T4 timers also support use with external inputs (input capture or pulse counting) or external outputs (output compare or PWM). As far as I know, TTT does not address those uses. For input capture, Paul's library FreqMeasureMulti is a great resource, and for pulse counting, search for his FreqCountMany sketch. There are fewer examples of output compare, but Manitou's test sketches provide a start there, too.
 
Thanks for the good info, will give it a serious go later.

I see low level terms like IOMUXC_GPT2_IPP_IND_CAPIN1_SELECT_INPUT are listed in the 1060 Reference Manual.
Question: Is that document the main/only resource for details on such terms?
 
I see they're #defined in cores\teensy4\imxrt.h altho it doesn't provide any detail beyond the manual.
I think the manual is the ultimate resource.
 
This library doesn't seem to work in PlatformIO. I tried both their library manager way to install and just manually copying the library into my project. Any plans to make it work there?
 
@luni I have a case where I need to count the time elapsed between PHASE A pulses of an encoder
I was wondering if I could use the TeensyTimerTool do this without loading on the main CPU cycles

I currently count the time today using an attachInterrupt on a pin, and count the time delta between each trigger - but when the encoder is moving fast enough it can slow down some other tasks (LCD updates, LVGL renders) by a very small but sometimes noticeable delay.

I'm using the QuadEncoder library to provide me with an indication of movement and the direction of movement, but have also bridged PHASE A pin to MicroMod pin 63 (Teensy pin 32 - EMC_07)

Would this be possible? Is the pin above suitable for such a use case, or should I route to a different pin?
 
@luni I have a case where I need to count the time elapsed between PHASE A pulses of an encoder
I was wondering if I could use the TeensyTimerTool do this without loading on the main CPU cycles

I currently count the time today using an attachInterrupt on a pin, and count the time delta between each trigger - but when the encoder is moving fast enough it can slow down some other tasks (LCD updates, LVGL renders) by a very small but sometimes noticeable delay.

I'm using the QuadEncoder library to provide me with an indication of movement and the direction of movement, but have also bridged PHASE A pin to MicroMod pin 63 (Teensy pin 32 - EMC_07)

Would this be possible? Is the pin above suitable for such a use case, or should I route to a different pin?

You could use the FreqMeasureMulti library, which uses the input capture capabilities of FlexPWM and QuadTimer to measure the time between specified edges of an input signal. There would still be an interrupt associated with the measurement, but you wouldn't have to actually measure the time in your own code. If you look at the source file FreqMeasureMultiIMXRT.cpp, you'll see a large table that shows which T4.x pins can be used. 32 is not among them, but it does include 33-39 and 42-47. On each specified edge, the capture register will contain the value of the timer's clock. The ISR reads the capture register, computes the delta from the previous capture and writes it to a queue that you access via available() and read() functions, similar to a serial port, so your loop() can read and process the period measurements as time allows.

What is the highest frequency you would expect for your phase A signal? If it's very high, it is possible to capture every Nth edge, where N can be 1 to 254. This feature is not exposed in the library, but I have implemented it for my own projects, and if you're interested I can make that code available on my github.
 
So in my case, the sensor is attached to the jog wheel of a Pioneer CDJ1000

When it’s turned or spun, the original HW would output the time in uS between each pulse on in a 16 bit range;
When it’s still it would read out UINT16 MAX, and as it starts to move it will go down to 0
So that fastest It would read is 0
microseconds between pulses.

Anything lower in the nanosecond range is not needed.
 
So in my case, the sensor is attached to the jog wheel of a Pioneer CDJ1000

When it’s turned or spun, the original HW would output the time in uS between each pulse on in a 16 bit range;
When it’s still it would read out UINT16 MAX, and as it starts to move it will go down to 0
So that fastest It would read is 0
microseconds between pulses.

Anything lower in the nanosecond range is not needed.
Sounds like the frequency is probably not very high, nor is it about high accuracy. Still you can use FreqMeasureMulti, which is nice because of the queued data, but if you already have it working with a GPIO interrupt, maybe you don't care.
 
Back
Top