The reason of defining BMI160_MAX_FIFO_SAMPLES as 8 can be found on the
following histogram of the number of samples in the FIFO on each read while
performing the accelerometer calibration process:
Samples Count Freq Acc. Freq
------------------------------
1 3842 0.1201 0.120111
2 13172 0.4118 0.531904
3 9065 0.2834 0.815300
4 2710 0.0847 0.900022
5 2231 0.0697 0.969769
6 816 0.0255 0.995279
7 137 0.0043 0.999562
8 13 0.0004 0.999969
13 1 0.0000 1.000000
Using factory method maked it easier to grasp the lifetime of all object
that get created and destroyed. Instead of spanning this thoughout whole
source file we have it nicely encapsulated in this a little horrendeous
_parseDevicePath that is of course to improve more.
Otherwise we're going to leak memory without any need.
Before this fix we've created ConsoleDevice 4 times in case -A switch hadn't been supplied,
but we hadn't ever deleted those. Now there's no memory leak here.
Minor changes to follow coding style and improve readability:
- sort headers
- move struct definition to compilation unit rather than header
- Add braces to if, for, etc
- Initialize device on hw_init() method, allowing it not to be
present
- Add missing lock
- Add packed attribute to structs
- Move defines to source file
- Add missing semaphore take on bus
- Initialize device on init function rather than constructor: the
constructor may run before I2CDeviceManager is initialized since our
AP_Notify objects are static so it can't be used.
In _start_conversion(), the check for return code of _dev->transfer() was
inverted. The structure also needs to be PACKED, otherwise there will be
a hole in the middle. Fix these issues and use be16_t where it makes
sense.
In read() we need to check for the second byte of config register, so
either make it an array of uint8_t or convert from big endian to host
endianness. It's simpler to leave it as it was, accessing just the
first byte. Also the conversion value is in be16 type an needs to be
converted to host endiannes, not the opposite.
Fix bus number: all boards that use it expect it to be on bus 1, not 0.
this allows for external modules to be called at defined hook
locations in ArduPilot. The initial example is a module that consumes
the AHRS state, but this can be generalised to a wide variety of hooks