Ruben J=F6nsson wrote:
> But there are a lot of protocols which requires that you have the
> whole frame
> before you can do anything with the data.

We're talking about a protocol that we can develop to fit well with our
embedded system.

> Everywhere you need to do a
> checksum
> or CRC for example.

Sometimes you're stuck with that.  Even then though, you likely don't need
to buffer the whole packet, only the payload part.

> Before you know that the checksum/crc is Ok you
> can't do
> anything than to put it in a buffer.

Sometimes, sometimes not.  Sometimes you can process the data covered by the
checksum but not act on it until it is verified by the checksum.  Sometimes
that requires holding processed data which is a lot like writing it to a
buffer, but that processed data may be smaller than the raw data.  Or the
raw data may cause different branches to be taken in parsing logic rather
than being real data that must be saved until it's known to be OK to use.

I'm not saying this always works, but you see things differently when you at
least try to look at things a byte at a time instead of just knee jerk
putting it into a buffer.

> The checksumming and CRCing can easily be done on the fly by the ISR
> one byte at a time though.

Not necessarily so easily.  The ISR is very low level and it may be
inconvenient to pass it enough information from the higher levels so that it
knows the context of the data coming in to perform such processing.  The ISR
knowing too much about what is going on is a kludge alert red flag.
Sometimes you need to do that, but you'd better be real sure you have a good
reason.

> On a small system it is usually one single array of memory that acts
> as the buffer.

Sure, but note that then prevents overlapped processing of one buffer while
receiving the next.

Again, all I'm saying is step back and think about byte at a time.  It's not
always the right answer, but more often than it gets used I think.


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