* Updated and expanded batt_smbus to work with bq40z50-R2. Expanded battery_status.msg. Fixed mavlink_messages.cpp temperature, added commented out expanded battery_status.msg parameters for future mavlink expansion.
* Changed errx to PX4_ERR
* Added PX4_ERR returns
- this makes sure that all motors are idling in mc mode. having this too
low can lead to a motor stopping in flight which is critical for
attitude control
- experienced loss of attitude control in RTL during descent prior to this
change
Signed-off-by: Roman <bapstroman@gmail.com>
If the GPS driver was used on another port (e.g. TELEM2), it would get
stuck in a `write` call and not return anymore. Disabling flow control
fixes that.
CPU usage is unchanged.
- move to ModuleBase
- strip down to PWM 8 and 16 modes only
- remove all dead code
- implement missing pwm ioctls (current value, rates, etc)
- default rate 50Hz -> 400Hz
When the timer callback is called at a higher rate than the logger can
execute the main loop (which is never the case under normal conditions),
the semaphore counter will increase unbounded, and eventually lead to
an assertion failure in NuttX.
The maximum semaphore counter is 0x7FFF, and when the logger runs at
default rate (3.5ms), the logger task must be blocked for 0x7FFF*3.5/1000
= 114 seconds continuously for an overflow to happen.
I see 2 cases where that could happen:
- the logger execution blocks somehow, or busy-loops in an inner loop
- a higher-prio task runs busy and hogs the CPU over a long period of time
On the Intel Aero and probably also other specific platforms
the first measured voltage values despite connected battery are unuasable.
The solution here is to start filtering and determining warning
only after a measurement above 2.1V was received.
This prevents the autopilot from sending an invalid unix timestamp.
Usually, if no time is set yet by a GPS, the date is somehow set
to 2000-01-01, therefore we can ignore anything earlier than 2001.