Atomic read/clear of QDEC CNT

[eljeffo]

Is there a practical way of reading the FTM1_CNT register and clearing it... without losing any ticks?

For example:

Time 1: Read CNT = 100

Time 2: CNT += 5 (while computing something, incoming "ticks" into QDEC)

Time 3: Clear CNT (Losing 5 "ticks")

[eljeffo]

Thanks a bunch for the pointer!  I'm definitely learning as I go and appreciate the tips.

I'm sure every system has it's pros and cons.  So far when I can get things to work within their limitations, these chips are great!  

[xiangjun_rong]

Hi, Jeff,

As you said that if you only read the FTM_CNT, do not write the FTM_CNT directly, when overflow event happens, the FTM_CNT is updated by the FTM_CNTIN. In the overflow ISR, you can handle the overflow event, in this way, I do not think you may lose the tick.

Hope it can help you

BR

Xiangjun Rong

[egoodii]

In firmware handling of 'overflow', it is not 'one tick' we are worried about losing -- if we 'leave it alone' the hardware can certainly follow the edge events.  What we worry about is if the quadrature input ticks the counter into overflow, but BEFORE FIRMWARE CAN RESPOND AND HANDLE IT, the input ticks the count BACK down thru underflow --- we will see 'one event', interpret that from the 'latest underflow action', and tick down our counter-extension variable, when actually NO extension-change should have occurred.  We have lost not 'one tick', but one 'whole FTM-counter modulo' (normally 65536).  I expect any 'pulse' on the appropriate phase-input of less that 200ns (100MHz core), when the counter is resting at such an end-count, IS going to be impossible for firmware to account for properly, even with my 'non-maskable-interrupt' configuration.  Twenty clocks is a viable estimation for the delay from 'interrupt event' to the first instruction I can get to that reads the FTM status --- 12 cycles are used by ARM hardware for low-level interrupt routine entry alone.

[eljeffo]

Wow... that would make for quite a rough day.

[eljeffo]

I see.   So in short, keep handling timer overflow flag (poll or interrupt) and don't bother trying to clear any counters atomically.  

For me, I need to grab each N ticks and do N things.  If I can clear the counter, the on the next go around, I can simply read the counter and not do math or hopefully not worry about overflow.

If I can't clear the counter, then it's just more math and logic (which I was trying to minimize)

[egoodii]

I will point out that there are other ARM-licensees who have attached 32bit quad-capable timers.  I believe, for instance, some members of STM32 -- start with their AN4013?

[egoodii]

The short answer is 'no'.  ARM has no 'simultaneous read and clear' instructions.  What are you trying to do that requires you to both 'get a count of ticks' AND clear the count to accumulate the 'next-bunch' in a lossless way?  If you are hoping to 'do your own large edge-count accumulation' to avoid overflow-interrupt handling, I'm afraid there aren't any 'absolute fixes' for the 'not really large enough' FTM counter...