Interupts on the Pic18

[Andrew Schreiber]

We are trying to use interupts with our gear tooth sensors. And looking at the data sheet i see about 9 types of interupts. After asking a mentor he was as confused as I.

In short, does anyone know which inputs (other than 1&2) are interupt driven?

[CyberWolf_22]

Digital Inputs 1-6 all can be interrupts. I would suggest reading Interrupts for Dummies and Kevin Watson's Interrupt code (yes the code it is commented very well).

[Jared Russell]

www.kevin.org/frc. Check the encoder code...a gear-tooth sensor really isn't much different, aside from how it keeps track of direction.

Keep us posted on how those gear-tooth sensors work. We've been able to use them in the past to get a good reading of raw speed, but direction is another beast altogether. Measuring the pulse width seems difficult given the overhead of interrupt calls and other factors.

[Kevin Watson]

Originally Posted by Abwehr

Measuring the pulse width seems difficult given the overhead of interrupt calls and other factors.

Yes, this is proving to be difficult. I kinda have it working, but I fear it will all spectacularly fall apart in different interrupt configurations. When I mean spectatular, I mean robot controllers rebooting themselves, going into programming mode and staying there, red-light-of-death, etc. I have at least one more possible solution to investigate, but for now, just use the first two channels of the encoder code.

-Kevin

[Joe Hershberger]

Originally Posted by Abwehr

www.kevin.org/frc. Check the encoder code...a gear-tooth sensor really isn't much different, aside from how it keeps track of direction.

Keep us posted on how those gear-tooth sensors work. We've been able to use them in the past to get a good reading of raw speed, but direction is another beast altogether. Measuring the pulse width seems difficult given the overhead of interrupt calls and other factors.

Is your interrupt overhead still bad? We had excellent results timing the sensors using external interrupts. If you continue to have trouble, you can always use an external processor that has capture capabilities.

This year you also have the ability to time an event (using dig input 02 and the ECCP module in capture mode). In addition, you can use dig input 14 to count events on timer 1 or 3.

Just a few possibilities. They are quite limited because almost all of the pins related to useful modules on the processor are not exposed.

I think the most reliable way to approach this is with an external processor that has all of it's modules available. If you are using a quadrature encoder (like the ones that Kevin suggests on his site), then Microchip has processors that can decode that signal for you (I think those processors can decode 3 of those signals simultaneously in hardware). Since it decodes it for you, it counts in the registers. There's no worry about latency. It just happens in hardware. When you want to know how many you have, just go read it.

There are many possibilities, but the external interrupts on the RC should be good enough to measure for the direction.

Cheers!
-Joe

[Joe Hershberger]

Originally Posted by Kevin Watson

Yes, this is proving to be difficult. I kinda have it working, but I fear it will all spectacularly fall apart in different interrupt configurations. When I mean spectatular, I mean robot controllers rebooting themselves, going into programming mode and staying there, red-light-of-death, etc. I have at least one more possible solution to investigate, but for now, just use the first two channels of the encoder code.

-Kevin

Kevin,

What are you trying to do that is causing those problems?

-Joe

[Kevin Watson]

Originally Posted by Joe Hershberger

Kevin,

What are you trying to do that is causing those problems?

-Joe

The 2.4 compiler is brain-dead when it comes to automatically saving data when a low-priority ISR is called. You have to pretty much manually tune the ISR with different compiler #pragma statements. Because I can't anticipate how someone will use my code, I have to err on the conservative side and save quite a bit of data, which introduces a bunch of latency. Trying to capture a 38us pulse when you've got ~50us of latency is a problem. Yes, I know that I don't necessarily have to time the width of the pulse, I could simply check to see if the output is still high when my ISR code finally executes and if it's low, conclude the pulse width is narrower than my latency and therefore one of the 38us pulses flew by. But the problem is this solution is half-arsed and I don't do anything half-arsed <grin>. This and other possible solutions are being explored.

If you'd like to see the RC malfunction, load up the ADC code I posted and change this line in user_routines_fast.c from:

#pragma interruptlow InterruptHandlerLow save=PROD,section(".tmpdata")

to:

#pragma interruptlow InterruptHandlerLow save=PROD

And you should see the RC do things it shouldn't.

-Kevin

[BradAMiller]

Originally Posted by Kevin Watson

Trying to capture a 38us pulse when you've got ~50us of latency is a problem. Yes, I know that I don't necessarily have to time the width of the pulse, I could simply check to see if the output is still high when my ISR code finally executes and if it's low, conclude the pulse width is narrower than my latency and therefore one of the 38us pulses flew by. But the problem is this solution is half-arsed and I don't do anything half-arsed <grin>. This and other possible solutions are being explored.
-Kevin

Just to add... I have had the same experience as Kevin. The problem is that even if you did the "half-arsed" solution (and I wouldn't recommend it either), one would still have the problem that the whole timing thing is offset by other interrupts that may be happening in the system.

I believe Kevin's right when he said to have hardware between the gear tooth sensor and the microprocessor to discriminate the pulse width and not leave it to the program.

[kevlarman]

Originally Posted by Kevin Watson

The 2.4 compiler is brain-dead when it comes to automatically saving data when a low-priority ISR is called. You have to pretty much manually tune the ISR with different compiler #pragma statements. Because I can't anticipate how someone will use my code, I have to err on the conservative side and save quite a bit of data, which introduces a bunch of latency. Trying to capture a 38us pulse when you've got ~50us of latency is a problem. Yes, I know that I don't necessarily have to time the width of the pulse, I could simply check to see if the output is still high when my ISR code finally executes and if it's low, conclude the pulse width is narrower than my latency and therefore one of the 38us pulses flew by. But the problem is this solution is half-arsed and I don't do anything half-arsed <grin>. This and other possible solutions are being explored.

If you'd like to see the RC malfunction, load up the ADC code I posted and change this line in user_routines_fast.c from:

#pragma interruptlow InterruptHandlerLow save=PROD,section(".tmpdata")

to:

#pragma interruptlow InterruptHandlerLow save=PROD

And you should see the RC do things it shouldn't.

-Kevin

speaking of which: does the comment preceding that still have the wrong page number in the compiler manual

[eugenebrooks]

Does anyone understand the significance of the INT3IP bit field being turned into a place holder in the p18f8722 header file? I am trying to get code rooted in Kevin's interrupt template code going. After including the different header, I got an error that INT3IP was not defined. An examinatinon of the header, compared to the one for last years controller, revealed a place holder for the bit corresponding to this portion of control register 2. The data sheet for the 18f8722 processor family shows this as a valid field in the control register, so I am wondering what is going on.

Eugene

[Astronouth7303]

Originally Posted by eugenebrooks

Does anyone understand the significance of the INT3IP bit field being turned into a place holder in the p18f8722 header file? I am trying to get code rooted in Kevin's interrupt template code going. After including the different header, I got an error that INT3IP was not defined. An examinatinon of the header, compared to the one for last years controller, revealed a place holder for the bit corresponding to this portion of control register 2. The data sheet for the 18f8722 processor family shows this as a valid field in the control register, so I am wondering what is going on.

Eugene

Kevin's post on the subject.

There is also a similar error with the Timer0 structure. (At least in the full 2.40 compiler they gave us last year.)