AP_SerialManager: RegisteredPort, add bytes_per_second/baudrate methods, proper flow control for MAVLink via DroneCAN #28315
+2
−0
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.
The RegisteredPort class in AP_SerialManager derives from the "naked" AP_HAL::UARTDriver class, and therefore provides its bw_in_bytes_per_second() method. This method however returns a default bytes/seconds of 5760 (https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL/UARTDriver.h#L151-L153).
The registered port is used by e.g. the DroneCAN serial class, in order to do e.g. MAVlink via DroneCAN tunneling. The MAVLink flow control of the parameter stream and mavftp however relies on the value returned by bw_in_bytes_per_second() (https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/GCS_Param.cpp#L56, https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/GCS_FTP.cpp#L500). Therefore, currently it only works properly if the default of 5760 is in fact appropriate. There is no means to change this.
This PR adds the missing bw_in_bytes_per_second() method to the RegisteredPort class (and in addition also adds the get_baudrate() method, to be consistent).
This has the effect that the setting in the parameter CAN_D1_UC_Sx_BD results in respective return values for bw_in_bytes_per_second(), so that the parameter/mavftp flow control has an idea.
OT note:
The whole baudrate thing is actually pretty wild. Each AP_HAL::UARTDriver has it's own baudrate field, when there is a state.baud in the serial manager class, and in addition the DroneCAN serial class also maintains it's own baudrate field. I think what actually should be done is that the generic AP_HAL::UARTDriver class gets a baudrate field (pretty much like it also has a parity field https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL/UARTDriver.h#L222). This would allow defining proper default methods for bw_in_bytes_per_second() and get_baudrate(), and the higher classes would not have to always do the same thing over and over again. Also the baudrate mapping could be moved to the generic begin() and similar methods, so that its baudrate field would always hold the correct value. I think this would simplify the code in sevral places a good bit (maybe also saving flash). Unfortunately I don't have the oversight to know if such a change would not have side effects, hence I here propse the simple "work around".
Tested on the bench using a MatekH743 flight controller with Plane firmware, and a Matek DroneCAN-ized mLRS receiver.