Hi Jan-Erik

Well there are other ISRs one is a timer that reads switch closure to detect
button presses......................... low priority
There is another ISR a timer that sets the sample rates of a couple of
channels on the AD converter..........low priority
And yet another ISR that reads the AD converters after the sample[s] are
done......................... low priority.  

(I did get in trouble with the AD converter.
There is a function where I use yet another channel of the AD converter in
polled mode.  If I disabled interrupts of the AD converter without clearing
the ADON bit first to switch to polled mode bad things happened. If I turned
the AD converter off by clearing the ADON bit, then disable AD interrupts,
then set the ADON bit, did the polled measurement and then when finished
clear the ADON bit,  re-enabled the AD interrupt and then set the ADON bit
life was good. This problem is eerily similar in that bad things happen
everywhere in my code and there is nothing specific except everything is
strange everywhere) 

So I would like to make the GPS receiver serial port a high priority because
it ultimately controls the most critical aspect of my device.

I don't want to take a chance that a button or something else got in the way
of the basic function of my device so I want the gps receiver to take
priority.

But even with that ISR circus going on all as a low priority I reckon one
level ISRs should be able to get it done but it makes my head hurt trying to
figure/sort it all out.
I am sure that if my commands or at least the GPS info makes it to the
buffers okay then the rest can wait.



Look at the code I posted.

I'm not doing anything except clearing a over run error or reading the char
if there is no error.

If I'm in that ISR and I don't clear the overrun bit if it is set.
(I can add the push to the buffer and the data look good in the buffer at a
low priority of course)
The show is over even though chars keep hitting the port the interrupts
stop.
I believe that the reason I'm there is a char was received.
Or said another way there is no overrun error interrupt flag.
The bigger question is why does the char received interrupt stop if there is
an overrun?

I'm not that sure that an overrun is really physically occurring (I do
believe the bit is set because clearing it makes things work) but I can't
think of a way to prove it.

Thanks again


 


 

 
 
 
 
Phillip
Things should be as simple as possible but no simpler
 
 
 
Phillip Coiner
CTO, GPS Source, Inc.
 
 
Your source for quality GNSS Networking Solutions and Design Services, Now!

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Jan-Erik Soderholm
Sent: Tuesday, September 19, 2006 11:06 AM
To: piclist@mit.edu
Subject: RE: RE: RE: FW: [PIC] Trouble getting my ISR high

Neil Baylis wrote :

> The two interrupts would be:
> 
> 1, an interrupt for receiving a character.
> 2, an overrun interrupt.

What is an "overrun interrupt" ?
I don't think that the overrun condition as such
generates any interrupt. does it ? It just sets the
OERR bit, AFAIK.

Phillip, are you checking/testing the OERR bit ?
If not, can you be sure that what you see realy is
an "overrun" ?

Phillip wrote :

> Yes you are correct I could just run everything at the
> same priority. But I should be able to put either one of
> my serial port ISRs as a high priority.

Yes, if your compiler correctly handles the differences
between high and low prio interrupt. Different save/restore
of context and so on. Sometimes there are limitations
on what you can and what you can't do in an interrupt.
There is also a risk that one by mistake uses the same
temp-varaible in both interrupt levels.

But my point was that for these two interrupt sources
(at the current baud rates) the added complexity of double
interrupt priorities isn't realy needed.


Jan-Erik.



-- 
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