Am I stupid? Goto does not GOTO??? Where's the bug??

[xnihilo]

I don't know because I changed the code meanwhile but anyway, as there is an LCDOUT $fe,1 the next LCDOUT would overwrite "0pin..." and it does not.
"finish" is the label at the bottom of the int handler and nothing else will overwrite what is displayed so it shows the GOTO is ignored.

Ever worse, in another part of the code I'm checking what pin has triggered the interruption and I can read port 0 to 3 but not port 4.

I was wondering,... is there a limit to the number of GOTO we can use in a program? Is there such limitation?

"Also, make sure when you GOTO another routine from your interrupt
that the routine isn't outside the DISABLE/ENABLE block. If you do it returns
to the beginning of your interrupt handler. "
-> actually I don't GOTO to something outside the int handler.

[Jerson]

the problem may not be so obvious with just the code fragment you posted. I suggest you post your entire interrupt code so that we can see what else is in there which can affect your desired outcome. I usually consider it a bad idea to have functions like LCDOUT in the interrupt handler. If the interrupts are not disabled, that statement itself, in the interrupt, may cause immense pain to a coder.

Jerson

[xnihilo]

the problem may not be so obvious with just the code fragment you posted. I suggest you post your entire interrupt code so that we can see what else is in there which can affect your desired outcome. I usually consider it a bad idea to have functions like LCDOUT in the interrupt handler. If the interrupts are not disabled, that statement itself, in the interrupt, may cause immense pain to a coder.

Jerson

Yes, I will post the code but the entire interrupt code is pretty huge.

As far as I know, using
DISABLE - (int handler) - RESUME - ENABLE should take care of the INT disabling while in the interrupt routine, am I wrong?

About LCDOUT, they are especially useful to debug the code but can lead to unexpected behaviors, I agree. They are to be deleted when debugging is finished because it woud slow down my handler anyway.

What is so weird is that I seem to be able to get an interrupt on RA4 like I do with the other pins on this port but when in the int handler, it's dead, as if it cannot read the incoming pulses.

Now I'm reading again the fuctions for this pin and I see CLOCKOUT (which should not be a problem as I disabled CLOCKOUT in the CONFIG words and this pin is an input anyway).
I also see 'T1G_' (TIMER1 GATE INPUT)! As I'm using TIMER1 to measure/time the pulses incoming on the pins, IF I didn't set the TIMER1 registers right, then this pin is thinking a LOW going pulse is a Timer1 gate input...?
My current TIMER1 settings are:
T1CON = %00011100 '1:2 prescale for 1US increments, timer 1 is stopped

I'm not sure exactly what settings I should use as the datasheet is not very clear to me.
BIT7: I will invert the gate (which is by default: low) so it will not interfer with my pulse (my TSOP IR sensors pulls low the pin when getting IR signal)
BIT6: (Time1 gate enable bit): it says if TIMER1 is on, "0" is 'Timer1 is on', "1" is 'Timer1 is on if Timer1 gate is not active'... what a strange and complicated way to say things... !!! Well, I think I should clear this bit...
I will try with the register set to : T1CON = %10010100

Why do the datasheet have to be soo intricate...

[Acetronics2]

Hi

And what about changing "==" to "=" ???

Just an idea ...

Alain

[xnihilo]

Hi

And what about changing "==" to "=" ???

Just an idea ...

Alain

? Why? If I remember well, it is supposed to be exactly the same.

Manual says:
"4.18. Comparison Operators
= or ==
used for
Equal"



Manual says also:
"2.6.4. GOTO
Try not to use too many GOTOs. While GOTOs may be a necessary evil, try to minimize their use as much as possible. Try to write your code in logical sections and not jump around too much. GOSUBs can be helpful in achieving this."

What do they mean "as much as possible"??? How many? What problem may arise otherwise?

[rmteo]

GOTO's (and GOSUB's) can cause "spaghetti code" to be the end result. Unfortunately, if the compiler does not support functions and procedures (what is commonly referred to as "structured programming") you may not have a choice.

Best to follow what the manual says "While GOTOs may be a necessary evil, try to minimize their use as much as possible."

[xnihilo]

GOTO's (and GOSUB's) can cause "spaghetti code" to be the end result. Unfortunately, if the compiler does not support functions and procedures (what is commonly referred to as "structured programming") you may not have a choice.

Best to follow what the manual says "While GOTOs may be a necessary evil, try to minimize their use as much as possible."

Right, but I need them to have bypass when multiple IF statements are used so not all IF are checked.

[xnihilo]

What is so weird is that I seem to be able to get an interrupt on RA4 like I do with the other pins on this port but when in the int handler, it's dead, as if it cannot read the incoming pulses.

Now I'm reading again the fuctions for this pin and I see CLOCKOUT (which should not be a problem as I disabled CLOCKOUT in the CONFIG words and this pin is an input anyway).
I also see 'T1G_' (TIMER1 GATE INPUT)! As I'm using TIMER1 to measure/time the pulses incoming on the pins, IF I didn't set the TIMER1 registers right, then this pin is thinking a LOW going pulse is a Timer1 gate input...?
My current TIMER1 settings are:
T1CON = %00011100 '1:2 prescale for 1US increments, timer 1 is stopped

I'm not sure exactly what settings I should use as the datasheet is not very clear to me.
BIT7: I will invert the gate (which is by default: low) so it will not interfer with my pulse (my TSOP IR sensors pulls low the pin when getting IR signal)
BIT6: (Time1 gate enable bit): it says if TIMER1 is on, "0" is 'Timer1 is on', "1" is 'Timer1 is on if Timer1 gate is not active'... what a strange and complicated way to say things... !!! Well, I think I should clear this bit...
I will try with the register set to : T1CON = %10010100

Why do the datasheet have to be soo intricate...

Well.
I've tried the T1CON = %10010100 and it works.
I will test again but it seems to be the solution. My signal pulse was pulling the pin low as it would have been TIMER1 INPUT.
Always check the various functions of a pin.
I already had the surprise when connecting an I2C EEPROM to ports that would be set as ANALOG or DIGITAL and using a bigger PIC I didn't expect anything else than ANSEL but there was ANSELH too