ChibiOS support - part 6 #7851
Merged
ChibiOS support - part 6 #7851
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tridge
force-pushed
the
pr-chibios
branch
2 times, most recently
from
e3d011a
to
9873972
Compare
|
Isn't set_system_clock() done in #7716 ? I see an ifdef for Chibios there |
tridge
force-pushed
the
pr-chibios
branch
2 times, most recently
from
3581c8d
to
e95d36e
Compare
tridge
force-pushed
the
pr-chibios
branch
5 times, most recently
from
6f4b204
to
e34428d
Compare
and add DMA channels for TIMx_UP ready for DMAR based DShot support
no longer needed as this is automatic now
this allows for some groups using dshot and some not
this allows for some groups using dshot and some not
this allows for some groups using dshot and some not
try to prevent long delays on other users of a DMA channel
we need to pulldown to prevent delays in uart sends
use DMAR burst DMA to minimise number of DMA channels needed thanks to betaflight for the great reference implementation!
used to gain exclusive access to a UART. This is needed for the BLHeli MSP protocol to prevent protocol corruption due to console writes
this gains exclusive access to the UART while MSP protocol is active to prevent protocol corruption due to other drivers writing to hal.console
this was causing transfer errors on the primary IMU of a PH2.1 when fast sampling was enabled
this fixes an issue with blhelisuite init when min is not 1000
this fixes a SPI bandwidth issue on PH2.1 with 3 IMUs active
allow debug on any MAVLink port also fixed handling of passthru for oneshot125
this gives best compatibility with BLHeliSuite
this adds back in the priority boost system for the main thread when waiting for a IMU sample. This significantly improves scheduling performance on very busy boards like a PH2.1
this separates oneshot and oneshot125 at the HAL layer, allowing the HAL to properly handle the high timing resolution of oneshot125 (needed to use 125ns time steps, to get the full 1000 throttle steps)
handle it in the HAL backends, to allow for correct resolution
this sets up oneshot125 with the full 1000 steps of throttle resolution, using a 8MHz clock. This matches the behaviour of modern ESCs that measure PWM values with high accuracy
this ensures PWM output gets out as fast as possible
this maximises reliability for serial IO to ESCs, increasing flashing reliability
this maps to the right bits for each MCU type
we need at least one build without FATFS support, as it changes the build quite a lot
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is for continuing work on the ChibiOS port.
There are quite a few key features still needed:
This PR now includes BLHeli-passthru support for configuring and flashing ESCs on USB using BLHeliSuite. To enable, set SERVO_BLH_AUTO=1