It was noted that we did not increment the return value bufflen when
adding zero. This is an ambiguity in the function declaration; if we
are told to add a zero should the return value be like strnlen (does not
include terminating null character) or read (includes all bytes used in
return buffer).
This PR makes it a non-issue by ensuring string null termination in the
caller and removing the append_zero parameter.
this zeros-watchdog was caused by a SPI DMA error on STM32F405:
https://discuss.ardupilot.org/t/crash-with-4-2-0-beta-and-4-3-0-daily-bdshot/83297
we had incorrectly left these internal errors enabled when asserts
were not enabled. That led to a osalSysHalt()
without these we get an spi_fail internal error, caught by the
SPIDevice code
this fixes two issues:
The first issue that if we are missing a log file in the middle of the
list then it was not possible to download recent logs, as we get the
incorrect value for total number of logs. This happened for me with
107 logs, with log62 missing from the microSD. It would only show 45
available logs, so the most recent logs could not be downloaded.
The second issue is that get_num_logs() was very slow if there were a
lot of log files in a directory. This would cause EKF errors and ESC
resets. Using a opendir/readdir loop is much faster (approx 10x faster
in my testing with 107 logs on a MatekH743).
This addition allows for cheap testing of a STM32H755 (dual core). This borrows the setup file STM32H757xx.py, as there are almost no changes between the chips. CRSF in and out, gps, ICM20948, BMP388, settings saving to on board flash all working.
PWM(3) pin change
Changed PWM(3) pin to one exposed on connector
we have seen errors where the BMI088 gets out of sync, so that the 3
axes are rotated. The data is shifted by 4 bytes, so that X=Z, Y=X
and Z=Y
this changes the BMI088 to "stop on full" mode, which is what Bosch
use in their example drivers, and also catches FIFO overrun events and
triggers a full FIFO reset. This should fix the problem with the FIFO
sync
when nose-in or tail-in, if the aircraft has significant pitch
asymmetry in hover then we would spin around in no wind if we use
pitch as an input
this makes pitch input for nose-in and tail-in optional and off by
default to preserve existing behaviour
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
adding fmuv3 into the list of firmwares we might run on Solo was a late
addition to the recent PRs. It was forgotten that the inheritance would
cause a redefition failure
the key fix is the reset of the fd to -1. Without that fix we only
ever log @SYS/uarts.txt
The timing change is needed to get the files out in a reasonable
time. The function is actually getting called at 100Hz or less, not
1kHz (measured on MatekH743 copter at 400Hz). So we need to run it
faster to get the files logged in a reasonable time
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
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
param class conversion was unconditionally overwriting the parameter
from the old parameter. This meant if the user has set a value in an
old firmware they could not change it in a new firmware.
I hit this with ARSPD_TYPE. I had previously set this to 0 in a
previous use of the board, and found that it kept resetting to 0 on
the new firmware when I tried to enable airspeed
make sure debug will compile
take into account active channels when configuring bdshot
add channel mask debug output
correct set bdshot telemetry position at startup
make sure all channels in a bdshot group are pulled high to prevent spurious pulses
