and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
And fix some IO bugs:
- PX4IO_P_STATUS_FLAGS_RAW_PWM was never cleared. This meant that after a
'pwm test' command, normal mixing was not possible anymore.
Fixed by remembering when we are in test mode and not sending
PX4IO_PAGE_CONTROLS during that time. PX4IO_P_STATUS_FLAGS_RAW_PWM is
cleared when PX4IO_PAGE_CONTROLS are received.
- when entering test mode w/o specifying all channels, the other channels
were not set at all, which means they could still be set to values from
a previous test call.
This is fixed by setting all channels to disarmed when entering/leaving
test mode.
The documentation of the thrust model parameter `THR_MDL_FAC` did not
mention both thrust and "PWM" being relative values. Also the use of the
term PWM could be misleading, since the model is applicable to CAN ESCs
as well.
This commit rephrases the user documentation string and a few source
code comments, but no logic changes are made.
ClosesPX4/Firmware#13105
system_state.fmu_data_received_time can be set from an IRQ handler, thus
we need to ensure every read access to it in mixer_tick is atomic.
So we read it once and copy it into a local variable.
The controls_tick() rate exceeds the rate at which RC receivers
provide digital rssi. As such, most ticks set PX4IO_P_RAW_RC_NRSSI
to 0.
This change promotes the controls_tick() local variable 'rssi' to
static storage so that it doesn't have to be updated every tick to
keep the correct value in PX4IO_P_RAW_RC_NRSSI.
On SPM4649T receivers with firmware versions at least 1.1RC9, the
serial data will contain an rssi value in dbm, as outlined in the
Remote Receiver Interfacing document section 8.3.1.
If the value received is greater than or equal to zero, the receiver
does not support rssi data, and the incoming value will be ignored.
However, if the value is negative, we can use the rssi value.
When we have a valid rssi, it gets mapped to a percentage from 0 to
100 as expected by mavlink. This mapping is constructed as a
logarithmic function over Spektrum's published minimum and maximum
rssi values, -92dBm to -42dBm as 0 to 100:
100 Log10[1 + (x - min) * (9 / (max - min))]
This change updates all calls to the dsm input rountes to return
the rssi value.
Note that one place this doesn't work with the px4io enabled.
There is a comment left in the absence of analog rssi that:
"we do not actually get digital RSSI regs[PX4IO_P_RAW_RC_NRSSI]".
This restriction has been left in place, as removing it exposes a
problem where the frequency of the control tick is greater than
that of valid dsm frames so the rssi isn't valid every cycle.
Daniel Agar