> 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, t=
hen
> pass around buffers of data.  However, eventually, somewhere, the bytes i=
n the
> buffer will get processed one by one.
> =


But there are a lot of protocols which requires that you have the whole fra=
me =

before you can do anything with the data. Everywhere you need to do a check=
sum =

or CRC for example. Before you know that the checksum/crc is Ok you can't d=
o =

anything than to put it in a buffer. Many times you also have to reply to a =

message/frame and you don't know what to reply before the you have the =

requesting frame.

The checksumming and CRCing can easily be done on the fly by the ISR one by=
te =

at a time though.

> 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 a=
nd
> 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, f=
or
> example, because that would be many more cycles/byte and probably limit t=
he 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

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

buffer. You don't need to pass anything around since it's location is alway=
s =

known. Just set a flag to inform that the buffer needs to be =

handled/interpreted on a higher level.

> 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 c=
ases
> 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 buffe=
r the
> few bytes as it needs to when it needs to.

But then you need the buffer anyway... =


/Ruben=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Ruben J=F6nsson
AB Liros Electronic
Box 9124, 200 39 Malm=F6, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
ruben@pp.sbbs.se
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

-- =

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