[TW#28238] Missing APIs to drop messages in tx/rx queues in CAN driver without re-configure or restart

[keelung-yang]

In some application scope, we need drop messages in tx/rx queues, such as in in ISO 14229-1, some request messages should be sent to functional ECUs before enter programming session. Since we don't care responses from functional ECUs including self, we need to drop them.

I know I can reveive and drop them manually, but it's better to add can_drop_tx_queue()/can_drop_rx_queue() APIs to driver.

In our application, all messages in red should be dropped before send 10 02 request. And this is just one example. So it's better if droping APIs added into driver.

[jcsbanks]

Software filtering based on CAN ID (because of shortage of hardware filters on SJA1000) could be a useful addition, but conditional filtering like this I put in higher layers and send only the data to the highest layer for which an ISO 15765 conversation is setup.

[keelung-yang]

@jcsbanks It's not about filtering, but drop messages after filtering.

Now just one question: How to clean CAN tx/rx queue?

[jcsbanks]

I have a task that processes the Rx queue which copes with a full CAN bus during testing or flashing ECUs, with no hardware filtering. Sorry I thought of it as ISO 15765 conversation filtering in a higher level than the driver. It seems like you want to peek the queues directly. My ISO 15765/14229 payloads end up pointed to by another queue as the variable length of header bytes including for extended addressing made it pointless to try to preserve the raw CAN queue, but can imagine other use cases and will watch with interest.

[Dazza0]

Clearing the queue entirely will risk clearing messages of other IDs as well. To clear messages of a particular ID within a queue will require going through the whole queue item by item which is no different in terms of efficiency when compared to dropping those messages manually.

I think a run-time reconfigurable software filter would be more appropriate. A software filter would ideally be implemented in the CAN driver's ISR, and will prevent unwanted messages from being put into the queue to begin with.

Referring to the screenshot above, a software filter could first be configured to reject messages of ID 0x7EB, then after sending the request of ID 0x7E3 , the software filter will be reconfigured at run time to being accepting messages of ID 0x7EB.

[keelung-yang]

@jcsbanks I've implemented ISO 15765 on ESP32, as a tester.

@Dazza0 It's not about application scope but driver's APIs design. I checked this with several colleagues who developed applications on several MCUs with CAN controller, most of MCU SDK supply such APIs to clean tx/rx quene.