DSP 56F8367 Timers delayed to get Speed ...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

DSP 56F8367 Timers delayed to get Speed ...

1,982 Views
TroyCorser
Contributor III

Hi all,

I’m trying to use DSP timers to get the speed of 4 wheels. I use the register B0, B1, D0, D1.

I set the register of the timers as I saw in the processor expert “capture” bean. (both edge, interrupt enables, prescaler set to 5). The frequency I try to get is between 40Hz and 2.5 KHz.

The problem I have is that:

when the speeds of the wheels are about the same I get a delay in the timer values.

This means that I read 4 different values of speed. The smallest one is the correct.

When an interrupt is detected the sequence of code is this:

- Reset the counter

- Verify if an overflow occurred, and in this case I manage the overflow

- If no overflow then enalbele highest level interrupt (level 3), read the capture register and reset the interrupt flag.

In my opinion the problem is that: when the B0 interrupt occurs and the program is inside the handling routine of B0, happen that B1, or other timers, interrupt occurs… and It is delay handled, so the reset of its timer is done with a delay and this introduce the problem.

One solution could be to force the DSP on the interrupt events to automatically reset the timer after saving the timer value in the capture register. But I don’t know how to do it, and if is it possible.

How can I overcome this?

regards

Labels (1)
Tags (3)
0 Kudos
Reply
1 Reply

889 Views
rocco
Senior Contributor II
Hi, Troy:

I have not used the 56F8367, but I have done this sort of thing on other processors. I have a few suggestions, but I cannot say for sure whether they will help in your case.

First, I would not do anything that could affect the measurement inside the ISR. For example, I would not clear the counter, but allow it to keep running. I would then make my measurements by subtracting the previous input-capture from the new input-capture. This would insure a correct measurement regardless of the interrupt latency.

Second, I usually handle any possible timer overflows by expanding the counter. I do this by allocating additional bytes in ram that I increment with the timer-overflow interrupt, therefore implementing a larger counter. Typically, I will make a 32-bit timer from the 16-bit free-running counter and an additional 16-bits from ram. I can then make 32 bit measurement and compares (being mindful of the asynchronous nature of the timer overflow interrupt).

Hope that helps a little.
0 Kudos
Reply