Semi-random INT count???

[thasatelliteguy]

as has been discussed before when you have a multi-byte variable that's altered in a interrupt routine its true value is indeterminate while the isr is active .
the correct procedure to access the var is to
disable isr
examine var (copy compare or whatever)
enable isr

I'm unfamiliar with this black magic you speak of... tell me more...

[richard]

lets have a word var count and a word var pos
count is the one used in your isr , pos will be the " current " position outside the isr

we have a sub to get pos
getpos:

@ INT_DISABLE INT_INT
POS= COUNT
@ INT_ENABLE INT_INT
RETURN

now whenever you wish to use pos just call getpos first to "refresh" its value


some more thoughts
1 are your encoders mechanically switched ( ie contact bounce could be an issue)
2 isr's should be kept as short a possible , lcd routines in isr may cause unexpected issues
3 have you tesed with only one encoder is connected ?
4 have you a schematic of your setup and a link to the positioner encoder data sheet

[HenrikOlsson]

Hi,
A schematic would be nice but I think we've covered this before. Two encoder signals on the same pin, fighting each other, is most likely not a good solution. You mention a relay, switching between the two, and that should be fine. Just make sure the signal at the PIC input is well defined (pulled up/down) and not floating at any point.

And Richard is spot on. If the frequeuncy of the encoder signal is anything above "a couple of Hz" you definitely do not want the LCDOUT statements within the ISR. Those two statments takes at least 5ms to exectute, then there's the rest of the ISR itself (which isn't much but still...) and the system variable save/restore. But let's say 5ms (and that's probably on the LOW side) then your input frequency can't be higher than 200Hz.

If you have a two channel scope you can test this.
1) Scope the input signal to the PIC with channel 1 on the scope.
2) Set a pin high at the beginning of the ISR. Set it LOW at the end of the ISR.
3) Scope this output of this pin with channel 2 on the scope.

The time between the rising edge on Ch1 and the rising edge on Ch2 is the interrupt latency, the time it takes to save the system vars and "get to" the actual ISR code.
The pulse width on Ch2 is the execution time of the ISR itself.
Then there's the time it takes to restore the system vars and "get out" of the ISR. This is pretty much equal to the measured latency.

Add the numbers together, ie 2*latency + ISR execution time and see what you get. Make sure you do this with a LOW(ish) input frequency to ENSURE you're not "overrunning" yourself. Then remove the LCDOUT statements from the ISR and measure again.

/Henrik.

[thasatelliteguy]

OK, bummer! My debugging was buggy.... Those are only there for the moment to see where I am. My fastest encoder, according to the scope is running about 50-60 hz. So that may be the problem. I'm headed out the door, but I'll try to deal with it when I get back this afternoon and see how it goes. I am still skeptical though, since it was the slow encoder that first showed the problem, and I still cant see how it would go from 3500 counts in say 120 seconds, all the way up to multiple WORD stackoverflows in the same time from this issue, but maybe I just still dont see the big picture....