Lpc2000

At 06:34 PM 3/30/06 -0800, David Hawkins wrote:

>Here's a another couple of comments to provide you some context
>for this type of problem, i.e., of interpreting the contents
>of a binary data stream;
>
>"Machine independent binary formats"
>
>Not binary executable, just binary numeric representations.
>There's a few out there, but here's a couple;
>
>XDR - external data representation; used by SUNRPC.
>
>CDR - common data representation, used by CORBA
>
>XDR and CDR define a machine independent set of rules for
>data alignment, byte packing/padding, etc.

Another approach that makes a lot of sense its if this is going to/coming 
from a communications interface is to leave the structures alone (ie use 
the same declarations in both cases) and use a simple message cracking 
routine on input.  So rather than try to read an integer from an odd 
address use something like:

x = buf[i] + (buf[i+1] << CHAR_BIT);
sign_extend(x);

making sure buf is unsigned for what I hope are obvious reasons.  The sign 
extend is needed if the data coming from the channel is a 16 bit quantity 
and a is 32bits as would be the case if converting from an 8 bit processor 
to an ARM.  All the nastyness of dealing with sizes, signedness and 
endianness then ends up being confined to the one place as with the machine 
independent binary formats, it's just a little bit more explicit as suits 
the smaller micro.  It's no less efficient than forcing packed 
representations on the compiler at that point and the rest of the program 
can efficiently deal with the data in it's natural alignment.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/