The RPM telemetry data structure can get updated by another thread at
any time. This can cause (now - last_update_us) to be negative, which
looks like the data is nearly UINT32_MAX microseconds stale. To fix
this, we copy the last_update_us value before we get the current time
so it's guaranteed to be positive.
We also minimize the number of places we explicitly check the timestamp
and rely on the `data_valid` where possible to minimize the performance
impact of this change.
the autopilot can instantly reset this back to 0 after we set it, so we never receive the set value:
2025-01-30T06:49:04.2029371Z AT-0931.7: COMPASS_LEARN want=3.000000 autopilot=0.0 (attempt=3/10)
2025-01-30T06:49:04.2029876Z AT-0931.7: Sending set (COMPASS_LEARN) to (3.000000) (old=0.000000)
2025-01-30T06:49:04.2030299Z AT-0931.7: AP: CompassLearn: Initialised
2025-01-30T06:49:04.2030653Z AT-0931.7: AP: CompassLearn: Finished
2025-01-30T06:49:04.2031166Z AT-0931.7: Received wanted PARAM_VALUE COMPASS_LEARN=0.000000
2025-01-30T06:49:04.2031653Z AT-0931.7: Received wanted PARAM_VALUE COMPASS_LEARN=3.000000
2025-01-30T06:49:04.2032117Z AT-0931.7: Received wanted PARAM_VALUE COMPASS_LEARN=0.000000
2025-01-30T06:49:04.2032732Z AT-0931.7: COMPASS_LEARN want=3.000000 autopilot=0.0 (attempt=4/10)
Co-authored-by: Bob Long <robertlong13@gmail.com>
Co-authored-by: Michelle Rossouw <michelleros128@gmail.com>
another one of our "do nasty thing to autopilot" commands, useful for testing what ground control stations do when the autopilot is in this state
this allows for hwdef entries like this:
PB1 GPIO_CAN1_TERM OUTPUT PUSHPULL SPEED_LOW LOW
PB3 GPIO_CAN1_TERM_LED OUTPUT PUSHPULL SPEED_LOW LOW
PB0 GPIO_CAN1_TERM_SWITCH INPUT FLOAT
that specifies a termination pin controllable by either a parameter or
a hardware switch, with an LED to indicate if termination is active
... if the driver ever asked for prom0 then we would do Very Bad Things here.
File: build/sitl/../../libraries/SITL/SIM_Temperature_TSYS01.cpp
Warning: line 38, column 13
Assigned value is garbage or undefined
Lua opens scripts to load them into memory, then the logger opens them
after to stream them into the dataflash log. When loading multiple large
Lua scripts from ROMFS, decompression takes a significant amount of
time. This creates the opportunity for the Lua interpreter and logging
threads to both be inside `AP_Filesystem_ROMFS::open()` decompressing a
file.
If this happens, the function can return the same `fd` for two different
calls as the `fd` is chosen before decompression starts, but only marked
as being used after that finishes. The read pointers then stomp on each
other, so Lua loads garbled scripts (usually resulting in a syntax
error) and the logger dumps garbled data.
Fix the issue by locking before searching for a free record (or marking
a record as free). Apply the same fix to directories as well. This
doesn't protect against using the same `fd`/`dirp` from multiple
threads, but that behavior is to be discouraged anyway and is not the
root cause here.
the third argument is space remaining in buffer, not size of buffer...
../../libraries/AP_AIS/AP_AIS.cpp:183:71: warning: Potential buffer overflow. Replace with 'sizeof(multi) - strlen(multi) - 1' or use a safer 'strlcat' API [unix.cstring.BadSizeArg]
strncat(multi,_AIVDM_buffer[msg_parts[i]].payload,sizeof(multi));
^~~~~~~~~~~~~
../../libraries/AP_AIS/AP_AIS.cpp:185:49: warning: Potential buffer overflow. Replace with 'sizeof(multi) - strlen(multi) - 1' or use a safer 'strlcat' API [unix.cstring.BadSizeArg]
strncat(multi,_incoming.payload,sizeof(multi));
these would be leaked if the "new" call for the ModeGuidedCustom object failed.
Since resgister_custom_mode may be called multiple times we could leak memory continuously
