Thanks a lot, Jinx. I couldn't try this out yet...

However, I was trying to solve something else first with no success:o((

 The thing is as follows:


 ORG 0
>            CALL INIT
>            GOTO MAIN
>            ORG 4
>
               ...
               DECFSZ Counter
               GOTO   Loop
              ...

>            RETFIE

>            INIT
>            - initialisation...
>            RETURN
>
              MAIN
>                - Loop
>                          ...
                            GOTO Loop
              END

Something happens at the ISR and subrrutine called Loop has to be executed,
which is within MAIN. If this loop is entered, microcontroller never gets
out of this interrupt rutine. Am I right??

Then, I'm supposed to have this code completely changed or can I make some
amendments just in order to test if this work??

Bye!


On 9/1/07, Jinx <joecolquitt@clear.net.nz > wrote:
>
> > Is there any precaution that I have to have when I try to use Timer1
> > interrupt and USART receive interrupt in the same code?
>
> Hi Carol,
>
> Say for example TMR1 is 524ms and the baud rate is 9600. This is
> a bit time of 1000000/9600 = 104us, and there are 10 bits to receive
> for each byte (Start, Data, Stop) before the USART interrupt goes
> off, => 1.042ms between RCIF interrupts, which is a long time in
> which to process the last received byte. And also process TMR1
> interrupts that might happen during reception. Given the difference
> between their timing, only occassionally will they coincide, so it's
> quite manageable. But you do have to write the code to cope with
> the worst-case
>
> So at the start of your ISR you'd first test which interrupt flag has
> been set, ie the one that caused this interrupt. Clear that flag and
> do what's required. For TMR1 that might be incrementing a counter
> of setting a flag to be used outside of the ISR by the main code. For
> the USART it might be storing the data
>
> When RETFIE turns GIE back on, if the other interrupt source had
> its IF set (ie the timer had rolled over or another byte had been
> received during the ISR) then the ISR will be immediately re-entered,
> and you do the above paragraph
>
> The thing to remember is that an interrupt flag (IF) is retained in
> hardware, and you can respond to it as and when you like. If your
> s/w is busy processing one interrupt, you can delay processing
> the other one
>
> Your interrupt sources are fairly slow and you won't have any
> problem processing either. Howard mentioned that it's generally
> a good idea to keep the ISR short. Say your USART baud rate
> was a lot higher, perhaps 115kB. That's only 87us for a 10-bit
> frame, and you'd not want to spend anywhere that time in the
> ISR or interrupts will be missed
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist