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
this gains about 20k of RAM, and has almost no impact on log download
speed at 921600 on a F427. The improved threading means we can afford
to have smaller buffers
refactor rcout into separate thread and process all dshot requests there
move uart DMA completion to event model
process dshot locks in strick reverse order when unlocking
convert Shared_DMA to use mutexes
move UART transmit to a thread-per-uart
do blocking UART DMA transactions
do blocking dshot DMA transactions
trim stack sizes
cancel dma transactions on dshot when timeout occurs
support contention stats on blocking locking
move thread supression into chibios_hwdef.py
invalidate DMA bounce buffer correctly
separate UART initialisation into two halves
cleanup UART transaction timeouts
add @SYS/uarts.txt
move half-duplex handling to TX thread
correct thread statistics after use of ExpandingString
set unbuffered TX thread priority owner + 1
correctly unlock serial_led_send()
don't share IMU RX on KakuteF7Mini
observe dshot pulse time more accurately.
set TRBUFF bit for UART DMA transfers
deal with UART DMA timeouts correctly
don't deadlock on reverse ordered DMA locks
change PORT_INT_REQUIRED_STACK to 128
When hw flow control is enabled check the CTS pin before we grab the
DMA channel to prevent a long timeout trying to send to a blocked port
from holding a DMA channel against another device
this fixes issue #16587
when a peripheral is made available via BRD_ALT_CONFIG we need to
remap the existing ioline_t in the UART and I2C drivers to use the new
pin.
This fixes an issue with half-duplex, inverted, swapped UART pins for
protocols like FPort and FPort2
this fixes an issue seen on one board which caused a watchdog on high
uart DMA load. We have reproduced the issue on another board by
forcing a very high DMA transfer rate on the same DMA channel while
also requesting very high transfer rates on the UART. The likely race
is in the DMA transmit timeout code, and the simplest fix is to lock
out interrupts during the DMA setup to ensure the tx timeout cannot
trigger during the setup
Andrew Tridgell
bugobliterator
tsubashmail@gmail.com
Peter Barker
James O'Shannessy
Andy Piper
murata
Stephen Dade
Iampete1