[Top][All Lists]

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

Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implem

From: Juergen Harms
Subject: Re: [avr-gcc-list] Bit-field packing order changed between avrgcc implementations
Date: Mon, 03 Dec 2012 10:47:58 +0100
User-agent: 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 in two: (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 neglected).

I learned a lesson: this an issue to be aware of when such a network is designed.

And, sorry, this has shifted from a gcc question to something that is better discussed on the AVR chat list.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]