I need some serious help here, so, I have been using the Hall effect sensors to count gear teeth and get an RPS for the wheels. It works pretty well. I was told to check the sensor every millisecond, so I set an interrupt to fire every millisecond and do a little math.
// this function will be called when a timer 2 interrupt occurs
static unsigned char lastHighL = 0; //The last value seen was a high
static unsigned char lastLowL = 0; //The last value seen was a low
static unsigned char lastHighR = 0; //The last value seen was a high
static unsigned char lastLowR = 0; //The last value seen was a low
msClock++; // increment the millisecond clock
if(msClock > 0 && msClock % 26 ==0)
return;
//Count the changed between highs and lows
if(Get_Analog_Value(rc_ana_in01) > 900 && lastLowL)
{
lastHighL=1;
lastLowL=0;
leftTicks++;
}
else if(Get_Analog_Value(rc_ana_in01) < 100 && lastHighL)
{
lastHighL=0;
lastLowL=1;
}
else if(!lastHighL && !lastLowL && Get_Analog_Value(rc_ana_in01) > 900)
{
lastHighL=1;
lastLowL=0;
}
else if(!lastHighL && !lastLowL && Get_Analog_Value(rc_ana_in01) < 100)
{
lastHighL=0;
lastLowL=1;
}
if(Get_Analog_Value(rc_ana_in02) > 900 && lastLowR)
{
lastHighR=1;
lastLowR=0;
rightTicks++;
}
else if(Get_Analog_Value(rc_ana_in02) < 100 && lastHighR)
{
lastHighR=0;
lastLowR=1;
}
else if(!lastHighR && !lastLowR && Get_Analog_Value(rc_ana_in02) > 900)
{
lastHighR=1;
lastLowR=0;
}
else if(!lastHighR && !lastLowR && Get_Analog_Value(rc_ana_in02) < 100)
{
lastHighR=0;
lastLowR=1;
}
if(leftTicks == GEAR_TEETH)
{
leftTicks=0;
leftRevo++;
}
if(rightTicks == GEAR_TEETH)
{
rightTicks=0;
rightRevo++;
}
//Every second, increment secClock
if(msClock%1000 == 0 && msClock>0)
{
secClock++;
}
//Calculate RPS every 4 seconds
if(secClock>0 && secClock % 4 ==0)
{
leftRPS=leftRevo/secClock;
rightRPS=rightRevo/secClock;
}
This is what I have going right now in that interrupt, most of it is just incrementing variables and such, so it shouldn’t be too much, though I am worried that the division is taking too long. Is there anything I can do to optimze this? Or am I overlooking something? I told the interrupt to return immediately after starting if the number of milliseconds is divisible by 26, so every 26ms, return without doing any processing (I’m concerned that all that code may take more than .2 ms, and I think the 1ms check should be more than enough to skip once without too many detrimental effects, though I could be wrong). I then plugged it into the dashboard to try and get more details, as the manual suggests, and it tells me “User violation: Invalid CONTROL or CURRENT_MODE byte”. Any clue what that means? I sure have no clue… Any help would be wonderful, or ideas, or better ideas. :’( :’( :’( :’( I’m going nuts, and I have an angry teacher glaring at me and breathing down my neck… That would be grand if any of you can help
Use the Hall sensor as a digital input and interrupt on the rising edge.
I strongly suggest that you use Kevin Watson’s RC encoder example as a guide. Just eliminate the part where he looks at the quadrature input to determine direction.
Perhaps my problem is not having a good grasp on how to set up interrupts. I understand how they work, but I’m not entirely sure on setting them up… I’ve read the innovationfirst documentation on them, and I’ve looked at kevin’s code, but its still not very clear. Any places I can get help on them? This may help solve my problem
Not an easy answer here… I have met quite a few degreed engineers who did not understand the intricacies of interrupt timing, latency, context saving, priorities, et cetera.
The important thing to remember is that an interrupt is like a separate program which runs on your processor. It can occur at any time, therefore it must have it’s own variables, do its thing, come to completion quickly and give control back to your background process.
Any variables it uses which are shared with the background process must be treated very carefully. Read the timers white paper from the IFI site for a fairly good side by side comparison of implementing a timer with and without interrupts.
Meanwhile, feel free to post specific questions here and I (or other knowledgeable people) will try to help you.
Instead of looking at the encoder phase-b signal, you could look at the motor’s commanded direction and increment/decrement the counters as necessary. One problem that comes to mind, though, is what is sometimes the robot won’t have a commanded direction when the interrupt fires off. You may be able to get around this by keeping track of the last commanded direction in a state variable.
Thank you all so much, I’ll try this out tomorrow and see if that helps. I really think I was doing too much during that interrupt handler. The part of interrupts I don’t understand is the setup, I don’t see any clear documentation on that. One of our software engineers explained how they work and everything, he specializes in integrated control systems and deals with PIC processors alot, it was just the syntax of setting one up that seems to get me. If perhaps someone could show the setup code, then expain what each line of it does , and how that changes for each interrupt, thats I think what I’m looking for. I mean, I can copy and paste code just fine, but I really want to learn it, not just smile and not know whats going on.
But I will try the digital thing, the thing is, I need both an accurate timer, and the counter, thats not too tolling on the processor is it? And what happens if an interrupt is raised while you’re in an interrupt handler? I figure its possible, do I miss that tooth, or does it interrupt the interrupt handler? Ok, thats all for now.
Interrupts are nested. While you are servicing one, the next will wait for you to be done unless you are doing prioritized interrupts. In that case, the higher priority will interrupt the lower priority. This is why Kevin’s code disables interrupts within the handler. Bottom line, you will not miss an interrupt unless you try doing too much within the interrupt OR try servicing too many interrupts.
As to your question on “tolling”. This is very implementation specific. How often does the timer interrupt? how many teeth and how fast does the gear tooth sensor need to service? And lastly, how much code is implemented within the interrupt? We can not answer this for you. It needs to be derived numerically or verified experimentally.
If you have a competent mentor, ask him or her. I’m sure they will be glad to help (depending on how busy they are).
