This is a global state object which we really want to get rid of - but
while we have it it does contain some useful state.
pbarker@bluebottle:~/rc/ardupilot(pr/du32-change)$ ./Tools/scripts/du32_change.py ~/rc/log32.bin
1648874490: Creating connection
Original armed_with_airmode_switch: 0
Original auto_armed: 0
Original compass_mot: 0
Original gps_glitching: 0
Original in_arming_delay: 1
Original initialised: 1
Original initialised_params: 1
Original land_complete: 1
Original land_complete_maybe: 1
Original land_repo_active: 0
Original logging_started: 1
Original motor_interlock_switch: 0
Original motor_test: 0
Original new_radio_frame: 1
Original pre_arm_check: 1
Original pre_arm_rc_check: 1
Original prec_land_active: 0
Original rc_receiver_present: 1
Original system_time_set_unused: 0
Original throttle_zero: 1
Original unused1: 0
Original unused2: 0
Original unused3: 0
Original unused_was_simple_mode bit1: 0
Original unused_was_simple_mode bit2: 0
Original usb_connected_unused: 0
Original using_interlock: 0
2022-04-01 08:19:27.03: -in_arming_delay
2022-04-01 08:19:31.04: +auto_armed -throttle_zero
2022-04-01 08:19:38.04: -land_complete -land_complete_maybe
2022-04-01 08:20:34.29: +throttle_zero
2022-04-01 08:20:35.29: -auto_armed +land_complete +land_complete_maybe
pbarker@bluebottle:~/rc/ardupilot(pr/du32-change)$
this fixes the flash re-init problem when flash storage fills on
H7. It was caused by rejecting writes where one or more of the 32 byte
chunks was not all 0xff but was equal to the current data. That
happens when writing to the sector header in AP_FlashStorage
it also moves the interrupt disable inside the loop to allow for
other interrupts to run between blocks
this halves the number of flash writes needed, and makes flash storage
twice as space efficient on H7
On H7 we need to write 32 bytes at a time to flash, which corresponds
to 30 bytes of data in AP_FlashStorage. By using a 16 byte storage
line we don't waste as much space
we have now shown that interrupts being enabled during flash
operations can cause the infamous "68ms" bug, or watchdog when using a
32 bit timer on boards using flash for storage
The issue is quite repeatable with a load of a very large waypoint
file (over 500 waypoints) using "wp ftpload" in MAVProxy. This puts a
huge load on flash storage.
Our current working theory is that while doing flash writes for
storage on dual-bank we block access to only one bank, so if another
thread uses a timeout function with a short timeout while the flash
write is happening and chVTDoTickI calls code which crosses the flash
bank boundary then it can cause chVTDoTickI to violate the assumption
that no more than CH_CFG_ST_DELTA ticks pass while it is calculating
the value to set in the system timer. In that case we get a delay of a
full timer wrap, which is 68ms on boards with 16 bit timer and 70
minutes on boards with 32 bit timer
this prevents bad calculated timeouts in DShot. The timeout would
sometimes come out as 0xFFFFFFFF, which led to an assert and could
block the thread
This fix is meant to be minimilistic to allow it to be merged easily
into 4.2. A better fix would fix all the uint32_t wrap handling in
DShot
sometimes it really does matter that we use constrain_uint32() instead
of constrain_int32(). For example, if we have a value like 0xFFFFFFFF
then the result will be very different
we should use unsigned constrain when dealing with unsigned values
Modification of CarbonixL496 to add more features.
Features:
To use internal clock of MCU, Oscillator value is set to 0.
LED pin changed from PA13 to PA15
Enabled JTAG
Add interface to GPS and ADSB.
In the case that you have INS_USE indicating IMUs should be used, but
EK3_IMU_MASK leaving some IMUs unused, we subtract the bias from the
wrong INS data
when rudder disarm is disabled we should allow full yaw control
regardless of throttle level. We should also only disable left yaw
when throttle is at zero, as right yaw does not indicate pilot may be
trying to disarm
set_speed_max updates position controller limits and triggers recalculation of scurves
local _desired_speed member is no longer required because max speed is held in position controller
Peter Barker
Andrew Tridgell
Henry Wurzburg
Lokesh Ramina
Nicholas Kruzan
Mirko Denecke
Randy Mackay