this replaces the two booleans used to mediate TX and RX buffer
protection with mutexes.
The booleans were a hangover from the very early HAL_ChibiOS code, and
can lead to a deadlock. The sequence is as follows:
- a very high CAN bus bandwidth usage, triggered by MissionPlanner
requesting CAN_FORWARD on a CAN serial port. That causes a
"infinite" number of CAN_FRAME messages which saturates the bus,
and leads to the DroneCAN thread looping with no pause
- a serial port configured as GPS type AUTO, auto-probing for a GPS
that isn't there. This calls begin() periodically
- the UART TX thread assocated with that UART not making progress as
the TX thread priority is below the DroneCAN thread priority
- this causes the begin() in main thread waiting for _in_tx_timer to
loop forever, which triggers a watchdog
Add code to reflect USB ACM parity setting to the passthrough port alongside existing support for ACM baud rate changes. Some use cases for serial passthrough require specific parity settings.
For example, even parity is used and required by the USART protocol used in the STM32 system bootloader. This enhancement allows the use of standard flash programming tools such as STM32CubeProgrammer to flash connected STM based peripherals such as Receivers and Telemetry radios via serial passthrough. Some examples of such peripherals include the FrSky R9 receivers as well as various other STM based LoRa modules used by the mLRS project.
SERIAL_ORDER has been around for a few years now and UART_ORDER is
rejected by the hwdef script, so support for UART_ORDER and associated
processing in the hwdef script is removed, along with the order
conversion script.
Added support for stm32l4+ processor
- Added scripts for hwdef generation
- Tested in custom hardware prototype (stm32l4r5vit6)
- Tested all peripherals and auto pilot modes.
hwdef for DevEBoxH7v2
pin definitions for STM32H750
add QSPI to DevEBox bootloader
add external flash to DevEBox
rename EXTERNAL_PROG_FLASH_MB to EXT_FLASH_SIZE_MB
Add support for EXT_FLASH_RESERVE_START_KB and EXT_FLASH_RESERVE_END_KB
Disable HAL_ENABLE_SAVE_PERSISTENT_PARAMS when there is no bootloader flash available
relax storage health status with SD card backend
don't check SD card health unless USE_POSIX
binary sections rearranged on external ram
manage RAMFUNC through ldscript and optimize function placement in external flash
inline timer functions
optimize placement of ChibiOS and functions in ITCM and AXI RAM
fix chibios features on bootloader build with external flash
change H750 memory layout
increase line storage for SD card based parameters
comment external flash linker script
move vtables into DTCM
update ram map for H757
enable crashdump support with external flash
correct bootloader pins and generator on SPRacingH7/DevEBoxH7v2
setup external flash reserve regions
allow different RAM_MAP for external flash on H750 and H757
this fixes an issue reported on MatekH743, but also applies to other
boards. When not using DMA if there have been bytes written before the
auto flow control detection was enabled then these must be cleared
from _total_written so the flow control detection can work correctly
this changes the heuristics for UART TX DMA allocation to greatly
reduce the chances of DMA contention causing long delays on other
devices
This fixes issues with FETTec driver output and gimbal status messages
as reported by Amilcar and OlliW. The problem is particularly bad when
no GPS is connected to GPS1 on fmuv3 and derived boards (such as
CubeBlack)
key changes:
- remember the contention_counter across begin() calls, as the GPS
calls begin with new baudrates regularly
- added a is_shared() API to Shared_DMA, allowing the UART driver to
avoid TX DMA on shared streams when at low baudrates.
this fixes a problem with the automatic DMA disable on DMA contention
in UARTs. This fixes issue #14581
the problem was that while tx_dma_enabled was correctly set to false,
it would keep looping inside write_pending_bytes_DMA() if the data
arrived in the write buffer at a faster rate than it could be sent
out, which did happen with a mavlink stream rate of 4Hz. This means it
kept using DMA even with tx_dma_enabled set to false. The result was
that the automatic flow control code never got a chance to run and we
didn't switch back to non-DMA for these low baudrate contended UARTs
