Quadrature Counters on T3.5 / T3.6

[luni]

Does anybody know if the T3.5 / T3.6 processors have more HW quadrature counters than Teensy 3.1? I need at least three, four would be perfect.

Thanks a lot
Lutz

 

[KurtE]

My guess is that it does support more than 2, between the FTM timers and the TPM timers, but have not looked through all of the pin numbers and the like to see how many you can uniquely get pins for.

That is there is overlap in which pins are available for the different timers.

You should take a look through the processor speces for those sections. You can find the documents I believe on the kickstarter page or the K66 beta thread, I believe about the 3rd posting.

Warning the 3.5 I don't believe has TPM timers, so may need T3.6 for more.

Also in that very very long thread, I posted an excel document that shows the different capabilities for the different pins. I beleive it is posting #1091 Warning, I forgot to rename the boards in the tab names. Used to be 3.4/3.5, but now 3.5/3.6

 

[PaulStoffregen]

I believe it's still just 2.

 

[tni]

My guess is that it does support more than 2, between the FTM timers and the TPM timers

No, only the two TPM timers have quadrature capability.

What kind of frequency are you looking at? The encoder library is quite fast, it uses pin interrupts (so you can get as many encoder channels as you have pins available). As long as there is only noise/bouncing on a single channel at a time, it counts reliably without debouncing.

 

[luni]

I'm developing a digital readout for optical encoders (lathes, mills and precision measurement systems) and would like to get about 1 MHz count frequency. My current software solution is good for about 200kHz (4 counters) which is good enough for lathes and mills. For high precission gauges with 0.25µm/step 250khz is somwhat limited.

The HW counters of the T3.1/2 work perfectly ( https://www.youtube.com/watch?v=ZLVXQfjfS6Q ) but having only 2 counters is not good in a 3 dimensional world

 

[PaulStoffregen]

Maybe use two Teensy 3.2s?

 

[KurtE]

No, only the two TPM timers have quadrature capability.

Sorry I have not double checked how all of the things interact. Here is/was my guessing.

The manual shows FTM1 and FTM2 have Quadrature capabilites, likewise as mentioned TPM timers.

Then looking at my Excel document I see pins:
3/4 : Show ALT7 3(FTM1_QD_PHA/TPM1_CH0) and 4 (FTM1_QD_PHB/TPM1_CH1)
16/17 : Alt6 FTM1_QD_PHA/TPM1_CH0, FTM1_QD_PHB/TPM1_CH1
29/30 : Alt6 FTM2_QD_PHA/TPM2_CH0, FTM2_QD_PHB/TPM2_CH1

So it looked like the pins overlapped between the two clock subsystems, But was nto sure if you might be able hypothetically configure either 3/4 or 16/17 to use TPM1 and the others to use FTM1/FTM2 or other way around.

Again I am only guessing as I have not tried it.

 

[tni]

I'm developing a digital readout for optical encoders (lathes, mills and precision measurement systems) and would like to get about 1 MHz count frequency. My current software solution is good for about 200MHz (4 counters) which is good enough for lathes and mills. For high precission gauges with 0.25µm/step 250khz is somwhat limited.

Optical encoder sounds like you will have a clean signal. 1MHz should be very doable with optimized interrupt code. However, if any other code disables interrupts even for a relatively short time, you will loose ticks.

What should theoretically work is using DMA to sample the encoder signals, e.g. at 2MHz. You would use a timer to trigger a DMA read of an IO port (put all encoder signals on a single IO port), basically the reverse of this:
https://mcuoneclipse.com/2015/08/05...ith-the-freescale-frdm-k64f-board-part-5-dma/

Then you can run post-processing on the DMA buffer to figure out the encoder transitions. DMA can use a ring buffer, so you should be able to have it continuously running.

EDIT:
Actually, the IO ports themselves should be able to trigger the DMA transfer (pin change), no need to use the timer.

 

[luni]

Maybe use two Teensy 3.2s?

It is supposed to be a low cost replacement of commercially available DRO's which you can get for about $100. Two teensies would probably be too expensive.

1MHz should be very doable with optimized interrupt code. However, if any other code disables interrupts even for a relatively short time, you will loose ticks.

Hm, 4 encoders each generating interupts at a frequency of about 1 MHz sounds like overloading a T3.2. Additionally to doing the counting it has to run a webserver and maintain a websocket connection to get the data to the display. But I'll try that with a T3.6 as soon as it is available.

The DMA idea sounds interesting, never did anything with DMA though. I'll try to read into the relevant chapters of the data sheet.

 

[tni]

Hm, 4 encoders each generating interupts at a frequency of about 1 MHz sounds like overloading a T3.2.

You are right. I did a bit of testing, a 1MHz interrupt rate seems to be about the absolute maximum the Teensy can handle. The USB serial console stops working reliably at around 300'000 interrupts per second (I gave my interrupt the highest priority).

 

[PaulStoffregen]

You might be able to get a little more by going through quite a bit of effort to access the raw hardware instead of using attachInterrupt().

First, use FASTRUN on the interrupt routines. That may only help a little.

Select pins on different physical ports. Each of the 5 ports has a single vector, so if you use only one interrupt per port you can eliminate the need for the attachInterrupt code which checks all the pins and calls. Then you can use attachInterruptVector() and avoid the need for code to check which pin on the port caused the interrupt.

Of course, overclocking or using the new Teensy 3.6 at 180 MHz will help too.

 

[tni]

My test code is using a timer interrupt and my ISR is called directly. With FASTRUN, it can do 1.4MHz (Teensy running at 96MHz) and interestingly USB serial also works.

typedef uint32_t buffer_t[256];
volatile buffer_t buffer;
volatile uint8_t buffer_idx = 0;
volatile uint32_t counter = 0;

FASTRUN void ftm1_isr(void) {
    uint32_t sc = FTM1_SC;
    if (sc & 0x80) FTM1_SC = sc & 0x7F;
    buffer[buffer_idx] = GPIOC_PDIR;
    buffer_idx++;
    counter++;
}