Refactor flush_tx_queue for VectorBus #1636
Merged
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.
In
VectorBus
class, there's an implementation offlush_tx_buffer
relying onxlCanFlushTransmitQueue
function of the XL driver. However, this function is a no-op for devices other than XL family, which are discontinued. This means that the library does not support flushing the TX buffer for any Vector devices currently available on the market.(https://cdn.vector.com/cms/content/products/XL_Driver_Library/Docs/XL_Driver_Library_Manual_EN.pdf)
My implementation of flush_tx_buffer consists of “sending” a dummy message with overrun/highprio flag set. The Vector interface will flush the TX queue after receiving a request to send this message.
Tested on VN5610A, for both FD and non-FD bus. I think it's a good idea to check this on other Vector devices, especially on XL family, to make sure that the implementation works for them all. In our use case, the flush is called after
XL_ERR_QUEUE_IS_FULL
is raised (e.g. when sending a ton of messages on a dead bus). In previous implementation, any next send request will raise this error if the bus is still dead, because the flush was a no-op. In my implementation, next send requests will not raise an error (until it fills up again).