Disable Encoders Problem

[mftaberner]

This is the first year our team has used the encoders and we have discovered you need to disable any inactive encoders. Kevin's readme in the encoder project sais that instructions to disable encoders are in the encoder.h file. After checking the latest code, no instructions were found.

Are the instructions in another file or can someone give help on disabling the encoders.

[Jared Russell]

All you need to do is the following:

1. Open "encoder.h"

2. Find the lines that look like:

#define ENABLE_ENCODER_1
#define ENABLE_ENCODER_2
#define ENABLE_ENCODER_3
#define ENABLE_ENCODER_4
#define ENABLE_ENCODER_5
#define ENABLE_ENCODER_6

3. Comment out any line that corresponds to an encoder you aren't using. For example, if you are only using encoders 1 and 3, you should make the section look like the following:

#define ENABLE_ENCODER_1
//#define ENABLE_ENCODER_2
#define ENABLE_ENCODER_3
//#define ENABLE_ENCODER_4
//#define ENABLE_ENCODER_5
//#define ENABLE_ENCODER_6

4. Re-compile. Voila!

[TimCraig]

Originally Posted by mftaberner

This is the first year our team has used the encoders and we have discovered you need to disable any inactive encoders. Kevin's readme in the encoder project sais that instructions to disable encoders are in the encoder.h file. After checking the latest code, no instructions were found.

Are the instructions in another file or can someone give help on disabling the encoders.

Just disable the interrupts the encoder is attached to. The encoder will continue to generate the signal but the processor will ignore it and the interrupt routine will not be executed.

[Jared Russell]

Originally Posted by TimCraig

Just disable the interrupts the encoder is attached to. The encoder will continue to generate the signal but the processor will ignore it and the interrupt routine will not be executed.

Tim,

I would still recommend that he comment out the #defines in the header file. Doing so would both disable irrelevant interrupts, and eliminate code that won't be called anyway from the hex file.

[TimCraig]

Originally Posted by Abwehr

Tim,

I would still recommend that he comment out the #defines in the header file. Doing so would both disable irrelevant interrupts, and eliminate code that won't be called anyway from the hex file.

When he said he wanted to disable an inactive encoder, I took it to mean the encoder was to be active for a while, possibly during autonomous, and then be disabled, not that the encoder was totally absent.

[Qbranch]

Originally Posted by TimCraig

Just disable the interrupts the encoder is attached to. The encoder will continue to generate the signal but the processor will ignore it and the interrupt routine will not be executed.

Remember.... watch out though. Make sure to && your interrupt flag with the interrupt enable bit. When interrupt enable is off there will be no jump to the interrupt vector, but the flag will still get set. Didnt know if your encoder code already had this or not.

good luck, and if I can help, gimme a yell.

-Q

[TimCraig]

Originally Posted by Qbranch

Make sure to && your interrupt flag with the interrupt enable bit. When interrupt enable is off there will be no jump to the interrupt vector, but the flag will still get set.

I've never understood the && with the enable bit in the interrupt handler. If the interrupt isn't enabled, there will be no jump to the interrupt vector so that test will never be executed. Without the interrupt enabled, it's just an ordinary input pin.

[Kevin Watson]

Originally Posted by TimCraig

I've never understood the && with the enable bit in the interrupt handler. If the interrupt isn't enabled, there will be no jump to the interrupt vector so that test will never be executed. Without the interrupt enabled, it's just an ordinary input pin.

Yes, it's weird but Qbranch/Alex is correct. The interrupt flag gets raised (set to one) even if the interrupt is disabled.

-Kevin

[Alan Anderson]

Originally Posted by TimCraig

I've never understood the && with the enable bit in the interrupt handler. If the interrupt isn't enabled, there will be no jump to the interrupt vector so that test will never be executed. Without the interrupt enabled, it's just an ordinary input pin.

There is only one (low-priority) interrupt handler. It will be called when any interrupt occurs, and the handler has to check all the possible sources in order to service the interrupt properly. The program won't know not to deal with a flag for a disabled interrupt unless you also check the associated enable bit. You don't really want a serial port interrupt to end up running the service routine for a "disabled" encoder.

[mftaberner]

Thanks for all the help.

[TimCraig]

Originally Posted by Alan Anderson

There is only one (low-priority) interrupt handler. It will be called when any interrupt occurs, and the handler has to check all the possible sources in order to service the interrupt properly.

Yes, I understand this part. Not as nice as processors that have a separate vector for each interrupt but beggars can't be choosers, I guess.

Originally Posted by Alan Anderson

The program won't know not to deal with a flag for a disabled interrupt unless you also check the associated enable bit. You don't really want a serial port interrupt to end up running the service routine for a "disabled" encoder.

This is where I part company with MicroChip's implementation. If you don't enable the interrupt, it should never set the interrupt flag for that interrupt, in my opinion, because an interrupt should not have occurred. I guess one more reason I'll probably opt for something other than PICs for my personal projects.