On Jul 4, 2010, at 1:23 AM, solarwind wrote:

> In this way, the ISR stays relatively free most of the time. It only
> executes some short code when a byte is received. So, even if the
> processing of the message data takes a long time (for whatever
> reason), the ISR is free to continue pushing data into the buffer.
> Meanwhile, the processing thread runs "in the background" to handle
> the received data.

Your ideas are fine and relatively standard for device drivers on  
pretty much any class of processor.  You can end up saving significant  
amounts of CPU time overall by adding a little bit more intelligence  
to the ISR; detecting end-of-packet before waking up the "processing  
thread", for example.   You use more cycles in the ISR, but the data  
is already in registers and such, and the processing wakes up a lot  
less.  (and one learns to appreciate protocol definitions that make it  
easy to do significant portions of processing in the ISR.  Terminating  
byte values avoided in the packet itself: good; byte count at start of  
packet: less good.)

It'll depend somewhat on what else is going on...  Multitasking  
kernels are fundamentally dependent on having a surplus of actual  
computing power...

BillW

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist