Humm, you didn't say what PIC you are using, (maybe earlier in the
thread that I missed?) but...

if it is 18F series, you could have a high-priority interrupt handle
character receive and save to a buffer (circular or not).  Other
processing happens in the regular low-priority timer interrupts.

I have this issue in a design that receives packets of data via RF while
playing mp3s from flash.  The character receive to a buffer happens in
high-priority, and when there are a few that code triggers a
low-priority "timer0" interrupt by setting the interrupt bit (the timer
doesn't actually run), and when it exits the mp3 playback does a
low-priority interrupt to process the data and analyze the packet.  The
reason for the tomfoolery is that the packet processing time could be
longer than the time it takes to receive a character, and I wanted some
control over when packets are handled vs. mp3 playing - if the mp3 chip
needs more data, maybe send it some bytes before doing the packet
processing, but never drop characters in.  Mostly coded, am getting the
high vs. low priority code in place now.  The "software interrupt" by
faking timer0 overflow definitely does work.

J



Jan-Erik Soderholm wrote:
> Edward Cooper wrote :
>
>
>>I have some code which handles...
>
>
> Could you define "handles" ?
>
>
>>...a string from the serial port in the ISR (using USART receive
>>interrupt), effectively hanging the processor for a short time.
>
>
> Define "short time" !
>
>
>>During this period I will have multiple TMR0's occurring
>>of with I can't miss one because its using them to rack up a timer (in
>>milliseconds) for a time critical process.
>
>
> Aha ! So "short" above is > 1ms, right ? But 1ms whould be plenty
> of time to save the character from the USART.
>
>
>>Now I'm not entirely clear if another interrupt can occur while one is
>>in process?
>>I'm thinking it can't because it would just mess up the
>>PUSH and POP process, or would it!?
>
>
> The specific interrupt *flag* can be set, but the interrupt jump
> will not occure before you leave the current ISR.
>
>
>>Basically the TMR0 process is very short,
>
>
> And the you must make the USART ISR shorter then the intervall
> between two TMR0 interrupts. This should be no probalem at all.
> You have plenty of instructions in 1 ms  to save in incomming
> character !
>
>
>>I just need it to occur while the processor is still dealing...
>
>
> Define "dealing" !
>
>
>>with the serial receive.
>>
>>I think I should really look into handling this serial receive outside
>>of the interrupt?
>
>
> You should/could save the incomming character in an UART ISR, but
> do whatever has to be done about it, in the main loop. Just set a flag
> in the UART ISR saying "there is a new character received !", and let
> the main loop check this flag.
>
> Jan-Erik.
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
>
>


--
"There are 10 kinds of people in the world; those who understand binary
and those who don't."

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.