Endian-ness Undocumented

This is a request for a documentation improvement:

The ARM processor can be configured for Big-Endian or Little-Endian memory addressing - therefore it is important to know which option is required for use with Open-AT.

I searched all the Wavecom Open-AT documents, and found no mention of this.

The GCC manual, Using the GNU Compiler Collection (GCC), states that -mlittle-endian is the default “for all standard configurations” - so we just have to hope that Wavecom’s is a “standard configuration”

Searching all the .mak files finds only NG_LITTLE_ENDIAN as a preprocessor option - but no specific compiler option.

Thus we guess that Open-AT is Little-Endian - but these things should be specified; we shouldn’t have to guess! :angry:

This issue remains unresolved:

wavecom.com/modules/movie/sc … .php?t=905

Does anybody know anything new about this topic?

My guess seems to have served me well! 8)

I am pretty sure the Q2686/87 and Q26 Extreme I am using have little-endian. I think Wavecom can not explicit documentation for bi-endian architecture, such as ARM core based Wavecom wireless module. As far as I know the Intel x86 family, including AMD, and Digital Equipment Corporation architectures (PDP-11, VAX, Alpha) are representatives of Little-Endian, while the Sun SPARC, IBM 360/370, and Motorola 68000 and 88000 architectures are Big-Endians. Still, other architectures such as ARM core, PowerPC, MIPS, and Intel’s 64 IA-64 are Bi-Endian, i.e. they are capable of operating in either Big-Endian or Little-Endian mode.

Big-Endian means that the most significant byte of any multibyte data field is stored at the lowest memory address, which is also the address of the larger field.

Little-Endian means that the least significant byte of any multibyte data field is stored at the lowest memory address, which is also the address of the larger field.

Suppose we start with an unsigned 2 byte (16 bit) long number 43707 in Big-Endian. If we look at the hexadecimal version of 43707 in memory, it’s 0xAABB. So what is Little-Endian, then? Well, a Little-Endian version of the above 0xAABB looks like 0xBBAA in memory.

You can use the following function to see if your code is running on a Little- or Big-Endian system:

#define BIG_ENDIAN 0
#define LITTLE_ENDIAN 1

int TestByteOrder()
{
short word = 0x0001;
char *byte = (char *) &word;
return(byte[0] ? LITTLE_ENDIAN : BIG_ENDIAN);
}

or

bool IsBigEndian()
{
short word = 0x0001;
if((*(char *)& word) != 0x01)
return true;
else
return false;
}

If you are using C++ STL, you can write general function that can deal with any atomic data type (e.g. int, float, double, etc.) with automatic size detection:

#include //required for std::swap
#define AtomicSwap(x) ByteSwap((unsigned char *) &x,sizeof(x))
void ByteSwap(unsigned char * b, int n)
{
int i = 0, j = n-1;
while (i<j) {
std::swap(b[i], b[j]);
i++, j–;
}
}

For example, the next code snippet shows how to convert a data array of doubles from one format (e.g. Big-Endian) to the other (e.g. Little-Endian):

double* dArray; //array in big-endian format
int n; //Number of elements

for (int i = 0; i <n; i++)
AtomicSwap(dArray[i]);

M2M Studio is one of the best embedded I have seen so far. Its GCC compiler not only supports C++ and STL, but also TR1 shared pointer pretty well.

Hope this may clarify Wavecom module endianness mystery.

Nonsense! Of course they can - and, indeed, must!

They must know how they use it!

Another example: Undocumented: Audio PCM Sample Format