Hi Jan-Erick
Thanks I was writing a response to Olin.
So I just read your message.
This of course clears up a lot.
Once again I apologize for saying one thing when I meant another.
I certainly appreciate the everyone's help and don't intend to antagonize
anyone by wasting their time.


I used the high level interrupts for the serial ports and the low level
interrupts for button presses/ switch de-bouncing.
My reasoning was that I didn't want to be servicing a switch/button press
which compared to a serial character is very slow and could be preempted
without much effect and might make me miss a character if it were at the
same level of priority as a serial character.
So in my mind the switches/buttons that have a lower priority should be a
serviced with lower priority interrupt.
(Don't hesitate to correct me if you see a better way to structure things.
I have no problem with told I'm wrong as this is my natural state of being )

The reason for not having a key word is that this function is called by the
actual ISR.
I realize that it adds overhead to my code but I "think" am making a trade
off between modularity, ease of maintenance/modification and efficiency
/size/speed.
If I find things are going too slowly or using up too many resources I'll go
back and move stuff around that works slowly to eliminate the extra calls
and speed things up/ reduce stack size/ overhead etc.

Thanks again Jan-Erick............et al

 
 
 
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: Wednesday, June 28, 2006 1:17 PM
To: piclist@mit.edu
Subject: RE: [PIC] C18 resource remaining metric/test

Phillip wrote :

> I don't know about making sense but it does fix my problem.
> I have two ISR's in my program.

That are called from some common interrupt entry point ?
Or how are they entered ?

> One is a timer that expires so I can check/scan/de-bounce 
> button presses and the other receives characters on the
> first serial port.

The second is triggered by the USART interrupt, right ?

> Below is the code of my timer/button ISR routine below.
> Look at the first line.

OK :

>   PIR2bits.TMR3IF = 0;  //disable the timer3 interrupt 

The comment is wrong and shows a slight missunderstanding
of the way interrupts works. "clear TMR3 interupt flag" is right.
That does *NOT* "disable" anything.

> If I comment it out my program will no longer work.

Of course.

> If I halt the debugger whilst it is commented out it stops in 
> this routine that is being called over and over...

Of course.

>....because the hardware is transferring control to this routine?

> I do believe that it is doing a retfie (underneath) because I 
> don't enable PIR2bits.TMR3IF on exit and it works fine the next 
time.

Again shows a missunderstanding of how interrupts work.
the TMR3IF flag is set whenever the TMR3 overflows. Your
code should only clear it (in the ISR).

> So I don't believe you when you say that the hardware 
> disables interrupts during an ISR event...

They are.
*Read* the chapter on interrupts in the data sheet.

> ..now I may be mixing my chickens with my ducks
> because my button ISR is a low level ISR and the original 
> serial IRS was a high level...

Are you using high/low interrupt priority ? That makes things
a little more complex. Do you realy need that with only two
interrupt sources ?

> ...but disabling interrupts does fix them both.

But you aren't "disabling interrupts" !


> as you can see I'm much clearer 
> on what fixed it
> than what was going wrong....

No, you aren't.

> 
> void detect_button_push_ISR(void)

This can't be the main ISR. Doesn't that need some keyword
in the function header saying "this is an ISR" ?

Best Regards,
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