Olin Lathrop wrote:
>> Say you allocate a static buffer to hold data that you receive over
>> UART.
>
> That sounds like big system thinking.

You say it like it's a bad thing. :)


> Most of the time you don't need to
> store a buffer full of input data to process it.

You never work on projects where data comes in while the processor is busy 
doing something else?


> Eventually deep down
> somewhere it will likely be processed a byte at a time.  You might as well
> design your system to process the incoming data as a byte stream in the
> first place.

That's small project thinking! ;) You

While it's true that you can process data "on the fly", I don't like the 
coupling it creates. I like it when the responsibilities of each module are 
clearly defined. Processing data is not the comm module's responsibility, 
its job is to assemble a packet and pass it onto the next level.


> Occasionally you may need to process a chunk of bytes together, like when
> converting them from ASCII to integer, but that is still smaller than a
> whole line or record or something.  Such small temporary buffers can often
> be allocated by adding them to the stack since their use is local to the
> current routine.

Oh, c'mon Olin. Don't tell me you've never looked at Microchip's USB or TCP 
stacks.

Bottom line, what you say makes sense for projects with severe memory 
constraints. Once you stop counting bytes, dynamic memory allocation becomes 
just another (very powerful) tool in a programmer's toolbox.

Vitaliy 

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