Converting struct in to array changing byte order

[Nusa]

Intel didn't reinvent endianness...they were microprocessor pioneers, just like the other early developers, and that's simply the choice they made. Others made different choices and things developed in parallel. Intel's dominence in the PC platform came much later.

Nor are big and little the only results of history...there are also mixed-endian implementations, the most prominent of which is probably PDP-11 (0x12345678 stores as 0x34127856). Realize nothing was set in stone back then...not even the size of a byte. My first programs were for the CDC cyber series with 60 bit words, 12 bit bytes, and 6 bit characters.

[Bruce Abbott]

we cannot say either big or small endian is right or wrong, its inherent in the design of the hardware... btw, in avr chip there is register setting to store 10/16bits adc value as right or left aligned in adc register, setting this appropriately, and you dont have to change your code a thing. i'm not sure about pic18...

8 bit PICs are strictly 8 bit. All instructions work on single Bytes only, so you can choose whichever endian you like. When I started using PICs I chose big-endian because that is what I was most familiar with (on 68000). However XC8 uses little-endian exclusively, so in this case the compiler has made the choice for you.

If you code properly it's not a problem. But if you do stuff like this:-

Code: [Select]

UART_Write_Packet((uint8_t *)&packet,sizeof(Packet_t));
then you shouldn't be surprised when it doesn't turn out quite like you expected...
 

[Ian.M]

Strictly speaking, the 8 bit PIC hardware has a (mild) bias towards little-endian because there are various peripheral register pairs in little-endian order that are best treated as single 16 bit entities.

[Bruce Abbott]

there are various peripheral register pairs in little-endian order that are best treated as single 16 bit entities.

Some may be, but others need to be treated as separate 'High' and 'Low' registers. For example in the PIC12F675 ADRESH is at 0x1E and ADRESL is at 0x9E - the same address but different banks. TMR1 is little-endian, but Microchip recommends reading and writing to TMR1H and TMR1L separately - in big-endian order.

[Mechatrommer]

there are various peripheral register pairs in little-endian order that are best treated as single 16 bit entities.

Some may be, but others need to be treated as separate 'High' and 'Low' registers. For example in the PIC12F675 ADRESH is at 0x1E and ADRESL is at 0x9E - the same address but different banks. TMR1 is little-endian, but Microchip recommends reading and writing to TMR1H and TMR1L separately - in big-endian order.

there is no atomic opcode in 8bit mcu for reading/writing /updating 16bit value (even if one thinks it is when coding in c) , and certain read/write order is needed due to how the 16bit 8bit register pair is non atomicness updated, not due to endianness. Avr may have different read order vs pic even if they have same memory layout... it could be, it could be not. afaik.

[Ian.M]

Yes.  some registers e.g the TMR0H/L pair are latched, and you must either explicitly access them 8 bits at a time as per datasheet, or use the compiler's access macros for that register pair which are guaranteed to perform the reads or writes in the correct order.  If the compiler's access order is ever changed, the compiler team will update the macros to match. 

[sangar]

Hi,

XC8 compiler manual says that it does not support for big endian format.Please refer the attached image.


Well.What I understood is that it's always best to correct the endianess at Our application in the PC. At PC side, I am going to use labview. I will do this correction there itself and get back to you.





Thanks,
Sangar

[NorthGuy]

Well.What I understood is that it's always best to correct the endianess at Our application in the PC. At PC side, I am going to use labview. I will do this correction there itself and get back to you.

Of course, doing things on PC is always better - much more computing power.

However, you get two bytes from the sensor. It doesn't really make any difference in what order you save them. Why not to save them in little-endian order right away and avoid the problem altogether?

[Bruce Abbott]

At PC side, I am going to use labview.

Finally we get to find out what your 'problem' is! PC's generally use little-endian. Labview is an exception.

Writing Binary Files with LabVIEW That Can Be Read by Other Applications

The problem is that LabVIEW uses Big Endian format for its binary numbers, while most Windows programs use Little Endian format. LabVIEW uses Big Endian, because that is what the MacOS uses, and LabVIEW was created first for the Macintosh...

In LabVIEW 8.0 and later, the Write Binary File VI and Read from Binary File VI have an input to specify the byte order.

[alm]

That applies to writing binary files. Does it also apply to sending/receiving binary data over RS-232?

[cv007]

Wouldn't it be fun if serial ports were bit-endian to whatever each hardware maker decided to use? (add one more parameter I guess- 8 N 1 L)

It appears the OP is sending one 'packet' of the packet_t struct, but how would the pc side know where each 'packet' starts/stops? If the pc side is simply looking for x bytes or x amount of time between 'packets', then it could get 'out of sync' in any number of ways.

I would guess that the next step after the trivial problem of byte order is taken care of, is a 'frame' to enclose the 'packet' so the pc side can tell where each value belongs.

[Bruce Abbott]

That applies to writing binary files. Does it also apply to sending/receiving binary data over RS-232?

Obviously, because when data is sent or received via RS232 the order of individual Bytes in it doesn't change (or at least they better not!). In this case the data being sent is a block of memory. This can be received by Labview as a binary 'string', then converted to big-endian numbers using the 'Unflatten' function.   

how would the pc side know where each 'packet' starts/stops? If the pc side is simply looking for x bytes or x amount of time between 'packets', then it could get 'out of sync' in any number of ways.

That's another problem to solve. Labview has a timeout function, so just having a large enough gap between transmissions might be enough.
 

[John Coloccia]

Oh, WOW, a little-endian 68K?!! I love it!! So much more elegant and sensible.

more elegant? more sensible? more-UAT-W-h-a-t?

In addition to little endian historically being more efficient to implement in hardware (especially math), big endian has a crazy pathology that the same variable, cast to different widths (i.e. 32 bits vs 16 bits) has a different pointer address. Totally crazy that to know where something starts, you need to know how big it is. The only advantage to big endian I can think of is that it's potentially more human readable. I say potentially because after a little while, you just read it as naturally as anything else.

And this is coming from someone that's spent most of his embedded development on big endian machines. The real question in my head is why big endian ever existed in the first place, not the other way around.

[Bruce Abbott]

big endian has a crazy pathology that the same variable, cast to different widths (i.e. 32 bits vs 16 bits) has a different pointer address.

Only if the pointer points to the first byte in the word rather than the last. But it's really not a big deal. Adding an offset to the address is a trivial detail that is taken care of by the compiler. 

Apart from debugging or doing crazy stuff with pointers, the programmer should not care about (or rely on) the internal representation of numbers.

Totally crazy that to know where something starts, you need to know how big it is.

Totally crazy that know how big a number is, you need to know how 'big' it is.

The only advantage to big endian I can think of is that it's potentially more human readable. I say potentially because after a little while, you just read it as naturally as anything else.

.esle gnihtyna sa yllarutan sa ti daer tsuj uoy ,elihw elttil a retfa esuaceb yllaitnetop yas I .elbadaer namuh erom yllaitnetop s'ti taht si fo kniht nac I naidne gib ot egatnavda ylno ehT

[John Coloccia]

Only if the pointer points to the first byte in the word rather than the last.

A pointer pointing at anything but the lowest addressable byte would be even weirder.

[Bruce Abbott]

A pointer pointing at anything but the lowest addressable byte would be even weirder.

The point is you shouldn't make any assumptions about how the individual Bits of a variable are stored in memory.

Here's the allocation in memory of Words and Bytes for the TMS9995 (used in the Texas Instruments TI-99/4A home computer). Notice something weird?
     

[Nusa]

A pointer pointing at anything but the lowest addressable byte would be even weirder.

The point is you shouldn't make any assumptions about how the individual Bits of a variable are stored in memory.

Here's the allocation in memory of Words and Bytes for the TMS9995 (used in the Texas Instruments TI-99/4A home computer). Notice something weird?
   

16-bit processor, big endian, 16-bit word-aligned memory on an 8-bit memory bus. Sounds typical for what it is, not weird. Modern processors may align on 32-bit or 64-bit boundaries for some data types.

But his point is that block transfers of memory should not be considered compatible between unknown machines, even if the endianess is known to be the same. Compilers will pad structure definitions as required to maintain the alignment the processor requires.

[nfmax]

Ah yes, the numbering of the individual bits is back to front in TI devices. Brings back memories!