Does endian-ness matter? How to make robust?

[Georacer]

This is extracted from comments in the code.

[hunt0r]

Since we read the file as a series of 8-bit bytes with the fread() command, endian-ness is not an issue at that point. The issue would arise inside storeData() inside LogMsgGroup.m

At present, our code (MATLAB's default) assumes little-endian, and this must be agreeing with all the logs we've tested. If no processor ever saves a log big-endian, I think this is a non-issue.

This is best illustrated with an example:
typecast([uint8(1) uint8(0)],'uint16') = 1. (the byte-sequence 0x01, 0x00 is equal to value 1)
typecast([uint8(0) uint8(1)],'uint16') = 256. (the byte-sequence 0x00, 0x01 is equal to value 256)

I guess we'll leave this issue open until either we discover that all logs will be little-endian, or we support big-endianness. (Note: the MATLAB function swapbytes() would be useful, in this case)

[Georacer]

Thanks for the explanation!
So this is a matter of compatibility between the system which reads the data (our PC) and the system which which writes it (uControllers, Linux boxes, anything that runs ArduPilot).

So far we have tested Pixhawk logs and the autotest logs, which I assume are the Linux build. So we have covered two big systems.

I think the ArduPilot developers won't let a rogue system mess their stuff, so I guess we're covered on this one.