-
Notifications
You must be signed in to change notification settings - Fork 16.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HAL_ChibiOS: add fair scheduling for UARTs #14604
Conversation
Looks good to me. |
So I think this patch is reasonable, but it doesn't solve the problem it was intended to. So probably a merge but no backport. |
If the DMA is busy when there are bytes to send or receive, the CPU should do it. |
e51b0b8
to
5a8c7d3
Compare
for recv that can't happen as we don't have receive DMA. For send I agree that it would be nice to switch to interrupt driven when busy |
5a8c7d3
to
b68d9ad
Compare
b68d9ad
to
3fe14ad
Compare
rebased |
@tridge I did some testing on a MatekF405-Wing using UART5 (RX5/TX5) and UART1 (RX1/TX1), I'm logging CRSF telemetry rates every 5 seconds, should be around 150Hz It looks like the patch does not improve UART5 peformance. Note: CRSF protocol is hardcoded @416666 baud
UART5 with this patch:
UART5 without this patch:
UART1 with this patch
UART1 without this patch
|
is there any reason this wasnt merged? |
How does this relate to #15984 ? |
@amilcarlucas this should be fixed by #15984 as I believe we will then rely on the thread scheduling algorithm which tries to be fair. |
This issue seems to be related to this, #16587 |
switch to interrupt driven when in high contention
3fe14ad
to
ee5135c
Compare
rebased, now includes only the dma disable change |
if two UARTs have DMA contention then we can get 2nd UART always
failing to send as as always do sends in the same order per 1kHz
loop. This ensures we give equal priority to all UARTs
see issue #14581