Flex timer use with a Rotary Encoder

[PHXFAE]

I have a customer who is using the K21 and wants to use the FlexTimer in the Quadrature Mode with an rotary encoder.

He wants to read the direction and count every 100 millisec and output the count to the 12bit Digital to Analog Converter.

Is it possible to read the FTM counter (reference manual pg 1061)?

Is it possible to directly output to the 12 bit DAC without DMA, and multiple buffers?

[dave408]

Alex, in my past experience with the FTM module and QD, you will need to be sure to disable FTM, then set your MOD value and then re-enable FTM.  If you don't do this, when you read the QD counter value, it will always be zero, and this will drive you nuts.

Fortunately, Earl is on this thread - he is the expert with Kinetis and QD as far as I can tell from earlier posts.  :smileyhappy:  Which reminds me, I might need to post up a question regarding my current issue where I believe I have the QD set up correctly, but I'm only getting 1/2 the number of encoder ticks per rotation...

[egoodii]

I'm not quite sure how you would get 1/2 your counts.  IF you had 'count/direction' mode for the QD(QUADMODE = 1,), I would expect only 1/4, as that only counts rising-edges on 'A', whereas the 'normal quadrature mode' will count ALL edges on both A and B.

[dave408]

Exactly!  There are only two settings, and 2x isn't one of them.  At first, I thought i was going crazy because the manufacturer's site says 2048 PPR, but I'm getting 4096, and there's no way to get double.  But then I hooked up the hardware to my motion control system and ran the encoder test there as a sanity check, and it came up with 8192.  So the mfg meant 2048 lines, not pulses.  But yeah, I'm getting 4096 instead of 8192, so I figure that I've got a mistake in my code somewhere, but not FTM settings related.

Though it's interesting because I could have sworn that the pic33F I used recently supported 1x, 2x, and 4x quadrature decoding in it QEI module.

Thanks for your input!

[egoodii]

'2x' is certainly a 'valid' QEI mode for 'operations in general' -- use one channel for 'direction', BUT count BOTH edges of the 'other channel' (falling while low or rising while high being 'one direction', the other conditions the other direction).  I have certainly found this mode 'necessary', for instance, for some 'knob encoders' where the detents were directly ON the edges of one of the channels, and so 'unusable' as a counting edge.  Now, that all being said, I am not aware either of any such '2x' decode mode for the Kinetis QD module.  I can also not imagine how else your 'test system' would find 8192 counts other than 'every edge of 2048 lines' -- and thus I am also stumped as to why Kinetis fails to get the same results.  I guess I would want to see a scope-shot of a 'few cycles' from a SHORT move, and count-register-reads before and after, to have something to look at...

[dave408]

Thanks, Earl.  I agree with everything you're saying.  I don't want to hijack his thread, so I'll create a new post later this week and will mention you so you know I'm calling.  :smileywink:

[egoodii]

Just one more quick question while you're here(!):  What do you get if you FORCE 'count/direction' mode QD(QUADMODE = 1,):  I should HOPE the 2048 pulses-per-revolution-of-one-phase?

[dave408]

From what I can recall, I got 1024, which is why when I fixed the count mode and got 4096 I thought I was good to go.  But this was a while back and now I can't remember for sure.  I'm quite positive that it's something I messed up with MOD and handling of the overflow interrupt, but I just need to dig into it.  Unfortunately, right now I'm busy trying to figure out why the working lwIP app I have upgraded from KSDK 1.1 to KSDK 1.2 no longer works.

[egoodii]

Certainly, the counter can be read at any time (as well as the status bit indicating the 'latest' direction).  But sure, SOME particular 'activity' will be necessary to read the counter and write it out to the DAC.  If not via 'system tick' code, then sure -- a triggered DMA can copy the count -- how is 'direction' to be represented in the DAC?