Open kentindell opened 1 year ago
For the MCP25xxFD this is a bit tricky: the drivers pick up the frame transmit events to mark them off from the internal buffer structures, but when the controller gives up on re-transmitting a frame that event doesn't show up as a transmit event.
Instead of a transmit event, there's a "I gave up" interrupt. This doesn't say which frames were given up on. Unfortunately, reading out which buffers are empty and matching this up isn't so easy: by the time the interrupt is handled, another frame might have been sent (CAN frames can be sent in as little at 47 microseconds). Resolving this race is not straightforward.
One possible way to resolve this is when TXQ is not full, and TXQUA points to a buffer that the drivers have marked as a frame to send, then the buffer slot must be empty, and if the frame did not appear in the transmit event queue then the frame must have been aborted at some point. The drivers must record the TXQUA value for each frame queued so that this can be matched up, and there are races to deal with where the transmit queue must be processed before any decision is made on whether a frame was aborted.
There is also the issue of reporting the space left in the queue: the driver has no idea how much space there is left because it cannot see which frames were abandoned after an error. So get_send_space() will be pessimistic. Send space of 0 can be tested by asking the controller if the buffer is empty or not (there is just a 1-bit flag).
The MCP25xxFD has support for disabling error retransmission. Add to the API the option to select this.