QDEC/FTM QDEC Maximum Expected Count/Decode Speed?

[eljeffo]

It seems clear enough that the maximum count frequency for the KV4x series directly relates to the Peripheral Bus Clock rate (for Example 100MHz).  Can I really expect anything at all near 100MHz, or should I derate for some reason?

However, I wasn't able to find any relative method of estimating the maximum count frequency for a FTM based Quadrature Decoder. 

I assume it has something to do with the chosen clock.  but perhaps it takes several "clock cycles" to sample/debounce/filter the incoming signal.  Is there a good FTM "derating" that I should apply?  

[xiangjun_rong]

Hi, Earl,

I agree with you that there are application which require more higher frequency encoder signals. For 32 bits counter, i think you can use ENC module, it's position counter is 32 bits instead of 16 bits.

BR

Xiangjun Rong

[egoodii]

How do I discover which family members have this ENC module?  It doesn't seem to be a selection-option in the 'MCU selector'...

[eljeffo]

Yup, looks like only the higher level KV parts have it.  "Interestingly" enough, the 32 bit counter is split up as 2 16-bit registers that need to be read separately.  Must be something going on with 16 bit counter reuse.

[xiangjun_rong]

Hi, Jeff and Earl,

The KV4x and KV5x in  KV family and MC56F84xxx in DSC family have ENC module, which  focus on motor control.

BR

Xiangjun Rong

[eljeffo]

xiangjunrong‌ Thanks for the insightful answer.  Much appreciated.

And yes, egoodii it would be wonderful to have a 32 bit counter on a 32bit CPU :smileyhappy: 

And yes, it is definitely a challenge if the encoder goes back/forth over the overflow point unless there is "ample time"/CPU cycles to continually monitor such changes.

[egoodii]

As the NXP rep pointed out, your KV part should have an ENC module,which is not only 32 bit but ALSO has a 16-bit 'distance moved since last read' register....

[egoodii]

I put overflow as the 'only, at highest possible, never-masked' interrupt and 'hope for the best'!  I read 'direction' in there, and try to confirm with the current count 'near top' or 'near bottom'.  Still seems like 'microsecond sized' holes exist in that logic...

[xiangjun_rong]

Hi, Jeff,

Regarding the quadrature module input signal frequency, for the quadrature part of FTM module of KV4x, the FTM external driving clock frequency must not exceed 1/4 of system clock frequency, for KV4x, the system clock frequency is 150MHz, so the FTM driving clock frequency must be less than 150MHz/4=37.5Mhz. For the quadrature input signal PhaseA/PhaseB, the FTM has to count the rising/falling edges of both signal, so the PhaseA or PhaseB signal frequency should be less than 37.5Mhz/4=9.375MHz. Regarding the ENC module, I think we should follow up the same rule.

Assume that the motor is run in 10000rpm, and the motor polar pair is 1, the phaseA/phaseB output 2048 edges per revolution, the phaseA signal frequency is 10000*2048/(2*60)=170KHz, so i think it is okay that the phaseA/phaseB signal frequency can not exceed 10MHz.

Hope it can help you

BR

Xiangjun Rong

[egoodii]

NXP should be aware that there are other sources of quadrature position information beyond simple motor-shaft-rotary.  Here is a datasheet-screenshot for a linear-position-encoder, which resolves 0.1um information over 30mm (other models are longer).  The stated 80m/min potential slew-rate implies an edge rate (at 10million-steps/m) of 13.33M/s --- and the extended info indicates a minimum 50ns between quadrature events.  So quadrature-decode-speed is NOT a 'moot point'.

The other serious trouble I have using these things on Kinetis is the limited 16bit counters in FTM, even though these are inherently 32-bit processors.  A 100mm probe at 10million/m comes to 1 million steps, or about 20bits needed.  I use the 'overflow' to extend the count, BUT have a 'serious limitation' in that the overflow interrupt doesn't differentiate which DIRECTION of overflow, or buffer multiple events should the encoder quickly jitter right at the overflow point.

As mentioned in the discussion linked above, I DID manage to get the 'reference point' signal from these devices to cleanly trigger encoder-count-capture thru the 'comparator input' option.

[egoodii]

I don't know why this kind of detail is not 'obvious' somewhere in product data.  I have come to the 'general conclusion' that the minimum time between incoming edges is the 1.5 bus-clock 'minimum detection interval for GPIO events' from the datasheet, as a process to come in to the internal bus-clock-domain synchronizers.

QEI inputs, and index capture 

My need was to pick up quadrature from two RS422 links, so 'technically' limited to 10MHz each (40Medges/s), which I can 'just guarantee' from a 60MHz bus-clock.  I work in the K22 domain, so your KV bus-clock-limits may be higher, as I can't tell either if said synchronizers for timer-input-controls would run from Bus Clock or Fast Peripheral Clock (as for FTM itself).  The datasheet still says for timer I/O to 'refer to general I/O characteristics', which do mention the 1.5 bus-clock synchronous requirement.  It seems hard to believe you'd be limited to 16.66Medges/s (max 25MHz bus clock) for this 'advanced controller'...