Hi Olin

I apologize for wasting your time or if I pissed you off it was certainly
not my intent.
 
I think what is going on here is that I'm using interrupt when I meant
interrupt flag bits...my mistake.
 If you had bothered to look at the code (not that I expect anyone to peruse
my code to debug it) you likely would have noticed it straight away that I
was referring to clearing the interrupt flag not an interrupt.
Once again my apologies for not stating the problem correctly and in more
than one spot.

The data sheet says that interrupt flag bits must be cleared in software to
avoid recursive interrupts. 
I still think that recursive interrupts was the root cause of my troubles
but I don't mind if someone helps me figure the real cause.

I still think there is a good case to be made to use HHL to develop code
recognizing that you are trading efficiency and code size for ease of
development.
To me it is about trade offs not that there is a perfect way to do
anything...there are certainly better ways to do things but when your
resources are limited you are forced to choose the lesser evil.
Only a bigger fool than myself would argue that you don't need fundamental
understanding of what's going on below to write stable efficient code.
I hope you et al can bear with me till that happens..............or not ..
it does help me to learn when I write down my questions even the stupid
poorly written ones.



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
Olin Lathrop
Sent: Wednesday, June 28, 2006 12:45 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] C18 resource remaining metric/test

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

No.  I don't do C ISRs, and as I said, I think they're silly.

Don't you need to mutter some magic incantation though to make the compiler
understand that this particular subroutine is meant to be a ISR?  (No, I
don't care about the answer, but it's something you might want to look
into.)

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

Then why are you asking me for help if you don't believe what I say anyway,
especially when it is something directly stated in the data sheet?

For the record, I said that the hardware disables interrupts on entry to the
ISR, not "during an ISR event", whatever that means.

> I think my problem was that my serial ISR was reading the char and
> clearing the interrupt before control was transferred again by the
> hardware...

But...  Oh never mind.  What's the point.

> at least most times as long as the characters arrived slowly
> enough when I started sending characters relentlessly eventually the
> ISR fell behind and before it could read the last char the hardware
> tried to transfer control to the ISR or some nonsense....as you can see
> I'm much clearer on what fixed it than what was going wrong....

No, you don't have a clue.  You accidentally found something that made the
symptom appear to go away.  Clearly you have very little understanding of
what is actually going on.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products
-- 
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