- checking of space in send_to_active_channels was incorrect - did not
take into account locked status of the channel
- corrected return value on comm_get_txspace - took a uint32_t, cast it
to int16_t, checked it for zero, then cast it to uint16_t on return.
That's just... odd.
this allows a channel to be marked "private". A private channel gets
heartbeats, but doesn't get forwarded packets or broadcast messages
This is used by solo gimbal driver
GCS_MAVLink: remove comm_receive_ch
This is a lot of sanity checking in a static function which has been
called from a place where things are guaranteed
GCS_MAVLink: remove unused comm_is_idle
GCS_MAVLink: remove unused comm_send_ch
GCS_MAVLink: remove unused hal reference
GCS_MAVLink: remove unused #includes
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.
warning: comparison of constant 4 with expression of type 'mavlink_channel_t' is always false [-Wtautological-constant-out-of-range-compare]
if (chan >= MAVLINK_COMM_NUM_BUFFERS) {
~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~
Most of AP_Progmem is already gone so we can stop including it in most
of the places. The only places that need it are the ones using
pgm_read_*() APIs.
In some cases the header needed to be added in the .cpp since it was
removed from the .h to reduce scope. In those cases the headers were
also reordered.
Now variables don't have to be declared with PROGMEM anymore, so remove
them. This was automated with:
git grep -l -z PROGMEM | xargs -0 sed -i 's/ PROGMEM / /g'
git grep -l -z PROGMEM | xargs -0 sed -i 's/PROGMEM//g'
The 2 commands were done so we don't leave behind spurious spaces.
AVR-specific places were not changed.
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.
Peter Barker
Andrew Tridgell
Michael du Breuil
Rajat Singhal
Lucas De Marchi
floaledm
murata
Mathieu OTHACEHE
Francisco Ferreira
Gustavo Jose de Sousa
Randy Mackay
Andrew Tridgell
Pat Hickey