[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implem
Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations
Mon, 03 Dec 2012 10:47:58 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
Thank you for the extensive reply.
The newly installed glibc and avr-gcc are 1.7.1 and 4.7.2 respectively,
the old tarball versions were 1.6.1 and 4.2.2.
My evidence is clear, the data sent from the node compiled with the old
compiler is received correctly (messages are only 8 bytes long, easy to
dump) with the exception that the order of fields is inversed wrt to
what is generated when I compile the sending node with the new version
of the compiler - all is consistent. (For now, I cannot go back to the
old compiler and double check by recompiling with it.)
Further evidence is (a) that once the sending node is re-compiled with
the new compiler, the received data has the fields in the "correct"
order, and (b) that the communication between nodes worked perfectly
until I recompiled (only) the receiving node with the up-to-date compiler.
Would be interesting to re-install the old compiler and compare, as you
suggest, the listing of the code it generates with the new code, but I
dont have the time at present.
My question was not on potential shakyness of my facts, but on a
strategy how to deal with these facts.
Your mention of endianness reminded me of what I had learned about IP
and made me consider a close-to-perfect solution, splitting the question
(1) within each node, use whatever packing order the compiler deems OK,
and access fields with all the comfort offered by C;
(2) before sending, and after receiving, program the mapping between the
bit-fields locally used and the byte array that is sent/received:
explicitely control the packing order (shifting, masking) that is used
on the bus. In fact, that is very much how IP deals with endianness,
mapping from and to network byte order - I will now have my own "bus
bit-field order". (-
This is easy to implement (one single send/receive procedure in each
node - the frequency of data transmission is low and the overhead can be
I learned a lesson: this an issue to be aware of when such a network is
And, sorry, this has shifted from a gcc question to something that is
better discussed on the AVR chat list.