16f84a running interrupt PICBASIC code

[skimask]

But do you mean that the code is really working for you on the chip as expected?
Then what could be the problem with mine?
Is it something to do with my power supply?
As soon as I make the first press of the button (RB7), the chip seems to reset. (Of course the WDT was off!)

Why don't you post a schematic of EXACTLY what you've got...

And the code that Joe posted is different than the code that you posted...so does it work?

[Archangel]

Why don't you post a schematic of EXACTLY what you've got...

And the code that Joe posted is different than the code that you posted...so does it work?

I have to agree w/Skimask post your schematic, It is really hard to determine what it is supposed to do. It does turn on the ports and turns them off, not sure if it does as "expected".
Some things to keep in mind,(you probably know already) All unused inputs must be terminated to VCC or VDD through resistors, in this case to ground. The RA4 is open drain so it needs a PULLUP resistor to supply +.

[skimask]

Let's take another look at the last program posted:

-code-removed-here
............................
if CNTL_BUTTON = 1 then spacing = 30
goto direct        'If button is released before 2 secs
                   'code goes directly into the default spacing 
-more-code-removed-here
............................
direct:
spacing =  255 - (spacing * 4)
OPTION_REG = %00110000 ' TMR0, counter set option_reg<5> clear for timer
                       ' Option_Reg<4> set for falling edge clear for
                       ' rising edge detection.
ON INTERRUPT GOTO ISR ' Interrupt service routine
TMR0 = spacing
OUT_PIN = 0
INTCON = %10100000 ' Enable TMR0 overflow interrupt 
'This is the interrupt service routine, ISR. The program jumps here whenever TMR0 overflow occurs
DISABLE 'Disable interrupts
ISR: 'Entry point of the ISR
OUT_PIN = 1
TMR0 = spacing
INTCON.2 = 0 ' Reset timer interrupt flag 
RESUME ' Resume main program
end

How can you RESUME if you didn't get there with an interrupt in the first place?
What happens to a program if you RETURN without a GOSUB? Or in this case, RETFIE without an INTERRUPT?
Now re-read post #7 and you'll see why I posted what I did...

[Archangel]

edit: never mind

[divaker]

Am preparing a soft copy of the schematic and also a writeup of what is what in the program?

Meanwhile I found that the chip actually resets everytime while executing the interrupt routine.
Goes to beginning of code and starts executing again.

WDT is OFF and I am not sure why this happening.
Could there be some other reason?

But the code works alright in the MPLAB SIM!!

Divaker

[skimask]

Who cares if it works in the MPLAB SIM or any other SIM.
If a plane test flies well in the simulator, but crashes every time they try to test fly it in real life, which method of testing are you going to believe?

Open up your datasheets, or do a Google search whatever for STACK UNDERFLOW or STACK OVERFLOW.
You explained your problem in your last post, and it almost completely verified what I told you 2 or 3 posts ago.

Meanwhile I found that the chip actually resets everytime while executing the interrupt routine.
Goes to beginning of code and starts executing again.
WDT is OFF and I am not sure why this happening.

Again, how can you RETURN from somewhere you didn't GOSUB to?
Same thing applies with an INTERRUPT. You can't RETFIE (RESUME) without an interrupt. Break out the datasheets and look up RETFIE, then break out your PBP manual and look up RESUME. An INTERRUPT is basically nothing more than a hardware generated CALL (not a GOTO because a CALL remembers where it came from). If you GOTO into your interrupt routine and expect it to come back where it came from, it's probably going to 'come back' to $0000, the RESET vector, whatever you want to call it. But actually, it's not going to do any of that, because you're going to have a STACK UNDERFLOW. You can't pull less than what's not there.
I'm guessing you probably haven't tried rewriting your code yet?
If you would've, you might avoid this problem altogether...

[divaker]

Dear Skimask and Joe,

Thanks guys for your kind suggestions for correcting the prob.
The whole prob was due to the relay that I had connected to the output.
It was the a typical case of not remembering to add a simple flyback diode. The relay was responsible for the prob.
As soon as I corrected it, everything worked like plum.
Thanks once 'gain.

Divaker