[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Re: Porting to ARM

On Tue, 26 Sep 2000, Gordon McNutt wrote:
> > The swap is usually a single instruction, and an "unneeded" extra
> Just to clarify, what your're suggesting is this:
> 1. Use the packed attribute to solve alignment problems (ok, that seems to
> work).


> 2. Use ntohl & friends to solve the endian problems. So, for example:
>         foo = buf;
>         foo->u16field = 0xa5a5;
>         htons(foo->u16field)          /* add this line? */

Well really

foo->u16field = htons(0xa5a5);

If you look in a TCP/IP stack or anything that touches data that needs to
pass between platforms of different endianess, you'll see the above. 

And when you receive, you do 

	i = ntohs(foo->u16field);

(or whatever you want to do with the data)

This is portable and fine. But the key question is if Bluetooth is a
network-endian protocol! If it's not, you cannot use the standardized
htons/ntohs because they can only convert between the host format and the
network format (so it's either a swap or a no-op depending on the host
arch). Then you need something comparable that always converts to
little-endian order (network is big-endian) like the macros suggested in
this thread (and then you'd define these in a clever way perhaps with arch
dependant asm instructions).

> 3. For 12, 6 and other length bitfields use an endian-safe macro to do the
> shifting?

Well, what you really need is to look at the protocol header specification
and figure out what you want to do, and see if those macros can help
you. I'm not familiar with the bluetooth headers so I cannot say. In
TCP/IP, this situation seldomly occurs because they were smart enough to
not align the header bits in weird ways (it's mostly full 8/16/32 bit
fields, aligned correctly compared to the header start).