- unfortunately we can't depend on the system field due to potential
external binding and non-genuine Spektrum equipment
- reject any DSM frame with duplicate channels
- add 16 channel mask
- tighten valid PWM range 990-2010us (±100% travel is 1102-1898µs)
- update RCTest rejected frame count
- always check system field for validity
- reject any data outside of "servo position" valid range from Spektrum specification
- properly support XPlus channels (12+)
- debug message if channel count changes
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)
Fixes these invalid format strings:
- A `%d` for a pointer (replaced it by `%p`)
- A 0x%08x (and a 0x%0x8!) for a pointer (replaced by %p)
- 2 cases of `%d` for a `ssize_t` (replaced it by `%zi`)
- 1 case of a %u for an `int` (replaced by %i)
- 3 cases of %d for a `long` (replaced by %ld)
- 19 cases of `%d`, `%i`, `%u` or `%lu` for a `size_t` (replaced it by `%zu`)
- An unused formatting argument (removed it)
- A missing `%d` (added it)
- A missing `%s` (added it)
- 2 cases of `%llu` for a `uint64_t` (replaced it by `"%" PRIu64`)
- 6 cases of giving a string directly as format string (replaced it by `("%s", string)`)
- 2 cases of %*-s, which should probably have been %-*s.
(Looks like NuttX accepts (the invalid) %*-s, but other platforms don't.)
- A %04x for a `uint32_t` (replaced by "%04" PRIx32)
- Telemetry is only enabled on omnibus, since on Pixhawk it seems we cannot
write to the RC UART due to how the board is wired
- For the Telemetry the UART needs to be opened RW
Rather than initializing the rssi percentage lookup table at runtime
on the heap, we would like it to be stored in flash.
This change pre-computes the rssi lookup table.
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.
Most of the incompatitbilities are luckily similar to the darwin build.
- New target OS __PX4_CYGWIN added because in other build environments on Windows defines will very likely be completely different
- added all necessary exeptions to the defines
- disabled priorities completely because on Windows they are defined 1-32 and with all the arbitrary +40 -40 priority settings there were a lot of problems
not only did some threads/"virtual tasks" not start because of out of bound priorities but also the resulting scheduling was totally random and inadequate
with default priorities it ran toally fine during my first tests, should be rethought when windows is used onboard in the future
* For some reason cppcheck complains with `fp != nullptr` but accepts truthiness
of handle by itself.
* Note that the expressions are equivalent according to the C++ standard ("A
prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member
type can be converted to a prvalue of type bool. A zero value, null pointer
value, or null member pointer value is converted to false; any other value is
converted to true. A prvalue of type std::nullptr_t can be converted to a
prvalue of type bool; the resulting value is false.")
