Ruben J=F6nsson wrote:
> As others have said you can handle the frame decoding in the ISR
> itself and only call the processing_thread when you have a complete
> frame in order to increase efficiency.

I keep hearing this concept, but step back a bit folks, this is a small
system.  On a large system it may make sense to put things into buffer, then
pass around buffers of data.  However, eventually, somewhere, the bytes in
the buffer will get processed one by one.

The only reason the buffer concept is more efficient on a large system is
because of the overhead of getting into and out of the operating system and
kernel priveledge level, so you wouldn't want to do this every byte.  You
wouldn't want to call Windows ReadFile for each byte from a TCP stream, for
example, because that would be many more cycles/byte and probably limit the
top speed you could receive.

However, on little systems with no OS this is the other way around.  The
layers are few and cheap, but memory is more of a premium, and it's
inefficient to "pass around" buffers.  Here is makes sense to have the
protocol stack (often just a single layer and a interrupt routine) handle a
byte at a time just like the application will eventually anyway.  If in rare
cases the application needs to deal with a group of bytes together (like
when converting a input ASCII number to binary for example), then it can
buffer the few bytes as it needs to when it needs to.

So on small systems, think byte at a time.  You may be surprised how much
simpler this makes both the low level input code and the app processing code
once you buy into this concept the whole way thru.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- =

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