Hello Community,
We have used eTimer function for our speed and direction monitoring since long time. Now we have troubles when we monitor (relative) slow signals. The signal period could be 80 or 240ms. Attached is my configuration. I have used some prescalers to adjust the proper counting range. If overflow happens, it means that for about 850ms I have got no edges and I will determine the stop status (0 speed). The quadrature mode has been used. The priority of eTimer ICF interrupt has been set as 14, which is the highest in the software configuration. There are two problems:
- By a very little chance, no direction can be determined during rotation. I build counter difference of CNTR register to get the direction. In my application if I get no direction during rotation, I will set a fatal error, which will kill the system. It is weird that for fast signals (10ms period) I never had this issue.
l_uscounter = (UINT16)ETIMER_0.CH[0].CNTR.R;
l_sscountdelta = (INT16)(l_uscounter - h_usSrec_spdircounter);
//check if the rotation direction can be determined by the quadrature counter, calculation tolerance is 2
if ((l_sscountdelta > 0) && (l_sscountdelta < 3))
g_usSrec_spdir = 1; //forward
else if ((l_sscountdelta > -3) && (l_sscountdelta < 0))
g_usSrec_spdir = 2; //backward
else
g_usSrec_spdir = 0; //stopped or no direction
//record the counter value of quadrature mode
h_usSrec_spdircounter = l_uscounter;
g_usSrec_spdircounter_old = h_usSrec_spdircounter;
- From 0 speed to accelerate, the first 2-4 edges cannot trigger the ICF interrupt. This has been already mentioned by someone in community forum.
Hi,
1) where is this code called in fact? From some interrupt?
What about to try to use eTimer Watchdog timer to monitor for stalled count?
2) this will be due to capture FIFO watermark I think.
BR, Petr