John W. Temples, III wrote:

> On Sat, 4 Oct 2003, Lucian wrote:
>
> > I do not use interrupts anymore, because I already have a timer
> > interrupt activated, and i think it is interferring.
>
>Interrupts don't "interfere" with each other.

Well, it depends on how you look at it and how you have written
your ISR (and how you define "to interfere" :-) ).

Lets say you have to interrupt sources "A" and "B",
two "enable flags" "AE" and "BE", and two "interrupt flags"
"AF" and "BF".

Now, lets say that both A and B are handled by the ISR. You
probably start your ISR with a "dispatcher" that checks the AF
and BF flags and jumps to the correct code. Perhaps first
checking AF and then BF.

Now, you want to "stop" the interrupt handler for A so you clear
the AE flag. All seems to be well, the event A will not trigg
the interrupt handler. But, the AF flag will still be set whenever
the event A happens.

Later on the event B sets BF and triggs the interrupt. Now, since
the AF flag is now set, the ISR "dispatch" code will see this and
call the A interrupt handler.

This is of course "cured" by checking both the "F" and "E" flags
in the ISR dispatcher, but I'm sure many has been trapped by
this, I have at least... :-)

The other cause of "interferance" I can think of, is if one
ISR handler just takes to much time so the other event is missed.

So, to me, it's clear that interrupts can "interfere".

My current desig with a 12F629 @ 4Mhz has three interrupt sources
running at the same time, GIPO-on-change, GP2-int, and tmr0
overflow. Two of them at about 100Hz and the third in bursts
at about 1 Khz. Works great. The ISR just make a few checks and then
sets some flags that are checked in the main loop. All real
processing is done as code dispatched from the main loop. I'm using
assembler so I have full control...


> > I would like to know if there can be a problem if there are
> > activated the timer interrupts and the usart module interrupts
>
> Not from the PIC, if that's what you mean.

It depends on what the timer interrupt does. If it take to long time,
the USART might overrun. I'd call that to "interfere".

> > and if I can still check RCIF to see if there is something to receive, or how
> could i figure it out.
>
> You only need to check RCIF in your interrupt handler.

Yes, but if the RC-interrupt is disabled by clearing RCIE, you
have to check the RCIF flag regulary in your main code. One have
to decide...

> It sounds like you have too much going on your code that you don't
> understand; I would suggest taking the advice others here have given
> and step back to a simpler example.  An polled serial echo is very
> trivial to implement, and you can verify it by typing into your PC
> communications program; this also verifies your serial hardware and
> your UART settings.  Then you can move to an interrupt-driven serial
> echo, then on to a buffered, interrupt-driven serial scheme.

Amen to that !

Jan-Erik.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads