The method was not using the instance parameter. Instead it always use
primary barometer. Bug was not detected because method
get_last_update() is used where instance is _primary.
Detected with warnings, warnings are useful :-)
this is needed to enable probing for a MS5611 on external I2C bus. The
MS5611 looks the same as a MS5525 airspeed sensor, so we can't just
auto-probe. Users will need to enable external barometers
the datasheet says that if you get back zero in an ADC read that the
next value can be corrupt. I have seen this happen on the FMUv1,
leading to bad altitude readings
RC_Channel: To nullptr from NULL.
AC_Fence: To nullptr from NULL.
AC_Avoidance: To nullptr from NULL.
AC_PrecLand: To nullptr from NULL.
DataFlash: To nullptr from NULL.
SITL: To nullptr from NULL.
GCS_MAVLink: To nullptr from NULL.
DataFlash: To nullptr from NULL.
AP_Compass: To nullptr from NULL.
Global: To nullptr from NULL.
Global: To nullptr from NULL.
We currently check examples are buildable with waf which doesn't need
the libraries to be specified in a make.inc file. Having the makefiles
there is misleading since people try to build and realize the build is
broken.
- reorder and document members.
- remove tentative of vertical alignement
- like was done for accumulated values, move the calibration
values to a struct
This converts MS56XX to use the thread started by SPI/I2C instead of
using the timer thread. This also fixes a possible starvation of the
main thread:
1) INS driver registers itself to be sampled on timer thread
2) MS56XX registers itself to be sampled on timer thread
3) Main thread waits for a sample from INS with
ins.wait_for_sample()
4) timer thread is waiting on update from MS56XX and consequently
the main thread is waiting on an I2C/SPI transfer
Besides this starvation there's another one due to reuse of the timer
lock in order to pump values from the timer thread to the main thread. A
call to the update() method when we have a sample available would need
to wait on any other driver holding the timer lock.
Now there's a lock just to pass the new values from the bus thread to
the main thread with a very tiny critical region, not waiting on any
bus transfers and/or syscalls.
Instead of a couple seconds, make it about 15sec. This makes TECS happy by not glitching the height demand as much. When applied too fast the TECS height demand causes a large single oscillation as it chases the filter lag.