-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
AP_HAL: clean up UART driver storage/access and legacy ordering #25589
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
It's progress (removing uartX
as members is good), but there's obviously still more to do here.
Next step would probably be to push that mapping back down into each of the HALs, so the HALs can push the devices into here in a 1-1 order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to get rid of the old mapping completely, just needs some work in HAL_SITL, HAL_Linux etc
4f3ef57
to
cac5009
Compare
I looked into this but the old mapping still is user-visible as command line options with those. Is it finally time for those options to be removed? That could break people's scripts. |
@tridge how do you feel about merging this now and then do the AP_HAL changes in a follow-up PR? Just thinking of scope creep and helping devs cut their teeth on this smaller change. |
8948024
to
c82077e
Compare
I spent some cathartic time with Ctrl+F and I think I've managed to eliminate virtually every trace of the old mapping. A couple things remain which might break users if removed. It shouldn't be much effort to remove them for good if desired. |
@tpwrules wow, this is great! I've been putting this off for ages, and you did it exactly the way I wanted it done. I think you deserve for medal for taking this on. |
Thank you very much for the kind words. Glad to be able to help. I did test one serial port with a serial GPS on my own CubeOrange to make sure that ordering did not change. SITL should be covered by the CI. I did also launch and fly around a bit a SITL system on my computer using MAVProxy and |
Warnings have been added as discussed on the devcall. Should be ready to merge once you are happy with ChibiOS testing. |
@@ -669,7 +669,6 @@ def start_antenna_tracker(opts): | |||
def start_CAN_Periph(opts, frame_info): | |||
"""Compile and run the sitl_periph""" | |||
|
|||
global can_uarta |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the only place that name is referenced in the whole source code. I figured it was unused, so I just removed it.
Avoids UB-inducing assumption that UART drivers are consecutive in the serial() function.
Saves a bit of flash and execution time.
Saves a bit more flash.
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.
Fourth serial port (SERIAL2) added purely for consistency.
Leave the legacy command line arguments to avoid breaking users.
Legacy command line arguments are kept to avoid breaking users. The vestigial `_tcp_client_addr` variable is removed. Serial port status messages are updated to a slightly different format to clarify the numbering scheme being used and prompt any external consumers to update.
Also delete some unused variables and update the completions.
d1807a1
to
037e00c
Compare
Final rebase, mostly to clean up some super minor things and make CI green. |
@tpwrules I tested all uarts on cubeorange with no issues |
Eliminates UB and saves 108 bytes on CubeOrangePlus. See commits for details.
No functional change. I did test this on a real board and confirm using a GPS that the port ordering is the same.
Remaining shadows of the legacy ordering: