Swap the endianness of accelerometer values read from device

[hnez]

Hi,

when testing on an ADXL345 accelerometer, that shares a device-id with the ADXL343 and looks to be mostly register-compatible, the measurements returned by accel_norm() and accel_raw() do not look quite right.

The datasheet for both ADXL345 and ADXL343 states, that:

The output data is twos complement, with DATAx0 as the least significant byte and DATAx1 as the most significant byte

When treated as little endian i16 instead of as a big endian i16 the resulting accelerometer readings look more sensible.

Please note that I do not own an actual ADXL343 to test this patch on and that my assumtion that this patch should also work for that accelerometer is only based on the very similar datasheets.

[tarcieri]

Interesting! Let me test it out on my side but it looks like you are correct

[tarcieri]

I tried this out. Unfortunately I don't have SWD set up right now (I can look into reporting the data via USB instead), however outputting it directly to some NeoPixels it looks like noise, as opposed to gradiations (well, flickering gradiations) as I rotate the device with the existing implementation, so at the very least something else is wrong.

I went through the code to give myself a refresher (as it were, the comment for write_read_i16 quotes the same section of the manual you did, although the existing implementation does not appear to match the comment), and I think there's a little bit more going on here, namely the "Justify Bit":

Justify Bit
A setting of 1 in the justify bit selects left-justified (MSB) mode,
and a setting of 0 selects right-justified mode with sign extension.

The current implementation maps these onto different endianness interpretations depending on whether or not the justify bit is set. They take the form of I16x3 vs U16x3-based impls of RawAccelerometer, where the I16x3 version presently uses the big endian interpretation of the output, and U16x3 uses the little endian interpretation.

tl;dr: while I think you're right and this PR should be merged, there's more going on here, and this change alone breaks the driver.