Phillip wrote:
> The only difference between my ISR and a standard one that just pushes
> every received char to a buffer is a test to see which buffer I push to.
> If it is a CMD char I push a byte to the command buffer if I have
> received a special character and I have set a flag I push the single
> char to a string buffer.

And why does this processing need to be done in the interrupt routine?  Why
can't you get the same effect with less complexity by pusing onto a single
FIFO in the interrupt routine, then letting the foreground code parse the
whole data stream?  This seems like an arbitrary and unoptimal division of
labor between the ISR and the foreground routine.  What are you getting in
return for the extra cycles and complexity in the interrupt routine and the
second FIFO?  I get the impression you latched onto an architecture for no
other reason than that is what popped into your head, and haven't gone back
and really thought about it since then.

Given that your problems seem to be related to the interrupt handler and
some related misconceptions about how the hardware works, you should be
aiming for the simplest minimal ISR that gets the job done.

> Things should be as simple as possible but no simpler

Right.  But this is also a content-free useless statement because the issue
is about the judgement when something is as simple as possible, not the
desire to make it so.  Do you really think anyone goes around saying "this
way would be the simplest, but I'm going to do it this other way because I
prefer a little more complicated"?  You might as well have a signature line
that says "Don't make mistakes".

> Phillip Coiner
> CTO, GPS Source, Inc.

I happen to be investigating different offerings for a GPS solution, so I
was curious and looked up the name of your company on the web.  I guess I
had just tuned out your signature before that because none of it triggered
any subliminal keyword recognition.  Frankly what I've seen here is a bit
troubling in regards to GPS Source.  Why is the CTO doing low level PIC
work?  A CTO is supposed to be the company technical guru, visionary,
evangelist, and possibly chief architect.  If it's a small company and he
also has to do product development, that's understandable.  But if he's the
best guru they got and he has serious misconceptions about interrupts in
general and specifically about PICs despite clear documentation, and his
software architecting is questionable, what does that say about the other
engineers?

My advice is to loose the tag line when asking basic questions.


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