Regarding endianness determination, I built this simple program (thanks stackoverflow!)

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int is_big_endian(void)
{
    union {
        uint32_t i;
        char c[4];
    } bint = {0x01020304};

    return bint.c[0] == 1;
}

int isLittleEndian()
{
    short int number = 0x1;
    char *numPtr = (char*)&number;
    return (numPtr[0] == 1);
}
/*
 *
 */
int main(int argc, char** argv) {

    int result;
    result = is_big_endian();
    printf("First test, is Big Endian : %s\n",result ? "True" : "False");
    //printf("Raw result: %d\n",result);

    result = isLittleEndian();
    printf("Second test, is Little Endian : %s\n",result ? "True" : "False");
    //printf("Raw result: %d\n",result);
    return (EXIT_SUCCESS);
}

Both methods return little_endian on both my x86 and my ARM machines.
So endianness shouldn't be the problem.

I'm now recompiling roscpp with a few printfs where Cedric indicated to see what's happening, but only on the ARM.
On the x86 I have ROS installed from binaries and I'd rather not recompile everything there too.

Claudio


On 28/11/12 22:26, Brian Gerkey wrote:

I also suspect that it's an endian mismatch, which I mentioned in answer to this question at ROS Answers:
http://answers.ros.org/question/49136/arm-buffer-overrun-debug-help/

There I suggested changing the endianness of the embedded machine; I've never done it myself, but I think that ARM processors can usually be switched between big and little endian.  As Cedric has pointed out, making roscpp endian-aware would be better, but making all of your machine little-endian is a pragmatic workaround.

Btw, if your ARM is running big-endian, then that's almost certainly the problem.  You should run a sample program to determine that machine's endianness (look around for an example).

    brian.

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users