system_source - This battery status is for the brick that is
supplying VDD_5V_IN
priority - Zero based, This battery status is for the brick
that is connected to the Power controller's
N-1 priority input. V1..VN. 0 would normally be
Brick1, 1 for Brick2 etc
Battery now assigns connected from the api in the
updateBatteryStatus, as well as system_source and priority
This PR is preliminary ground work for FMUv5.
PX4 does not use the NuttX adc driver. But used the same format
for the data returned by the nuttx ADC driver.
There was a fixme:in src/platforms/px4_adc.h "this needs to be
a px4_adc_msg_s type" With this PR the need for
src/platforms/px4_adc.h goes away as the driver drv_adc.h now
describes the px4_adc_msg_t.
Current driver was copy pasted from a MS5611 driver.
The existing driver takes data from Simulator, not from
an actual device.
Signed-off-by: Nicolae Rosia <nicolae.rosia@gmail.com>
Provides:
- thread-safety for module start/stop
- some shared code for module start/stop. Should also be less prone to
errors.
- constructor & destructors are called from within the new module thread
- can be used for work queue & thread modules
- strutured & formal way for module printf usage & module documentation
Limitation:
- supports only modules with one instance (eg. not mavlink)
- Fixed V712
- The compiler can optimize this code by creating an infinite loop, or simply deleting it.
- There is need to add a volatile qualifier to the '_ExitFlag' and 'sim_delay' variables.
param_t is only used as an offset and we have <1000 params, so an uint16_t
is enough.
This saves roughly 1KB of RAM. We only do that on NuttX because normal
integers have better performance in general.
Previously on amd64, this was even 64bits because it was an uintptr_t.
We need to protect access to the param_values array. This is dynamically
allocated and resized (utarray_reserve() calls realloc). If some thread
was iterating the array while another was resizing the array, the first one
would iterate on a freed array, thus accessing invalid memory.
On NuttX this could lead to hardfaults in rare conditions.
Unfortunately we need to initialize the semaphore on startup, by calling
sem_init(). This adds a param_init() method called by every board/config
that uses the params (at least I think I've found all of them)
David Sidrane