On Sun, 4 Jul 2010, William "Chops" Westfield wrote:

> 
> 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.)

I don't like putting this much protocol dpendent code in the ISR as it 
leads to many complications. What happens if the data length arrives 
corrupted, what happens if there is a break in transmision - do you 
implement timeouts, do you send a NAK, what happens if the CRC is wrong, 
what happens if you see the start of the next packet before the end of the 
current one, what about different packet formats.

How do you debug all this (as it's going on in an ISR) and push errors 
through it to ensure you've caught all those gotchas in the "protocol".

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

And a very good way of having a surplus of actual computing power is not 
to waste time in an ISR.

If you really want to reduce the load by not having the background task 
waking up very frequently and processing each byte as it gets put into 
your fifo, you need a little more intelligence in your RTOS. You put your 
packet processing task to sleep for a long time (say a data transmition 
timeout period). You implement a high water mark on your fifo (say 50%) 
and when the ISR detects that it has gone past this mark it wakes up the 
packet processing task. If the fifo never gets to this mark (because the 
transmiter has stopped sending) then the task gets woken up anyway because 
of the timeout. The high water mark can even be made variable such that 
the packet processing task always gets woken up when the first few bytes 
of a packet arrive. It then determins what type of packet it is receiving 
and sets the high water mark accordingly.

With an intelligent RTOS tasks don't need to wake up very often to check 
the environment, they can be woken up by an ISR (or other task) and while 
the tasks are asleep they consume NO CPU time. A good RTOS will not try to 
resume each task that is sleeping. It will maintain a ready to run list 
and simply cycle through the list (in priority order).

Some multitasking executives simply provide a "yield" facility. It is then 
the responsibility of each task to keep putting itself back to sleep if it 
is woken and has nothing to do. Processing a data packet this way will 
waste CPU time and I can see the rational behind Bill and Isaacs 
suggestion. But if the RTOS does provide a proper suspend and resume 
facility then your overheads will drop dramitically and you software will 
be greatly simplified.

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