I have an application running baremetal which controls a peripheral via CAN. In its original form, my application hands messages to the CAN "driver", which is actually a buffering layer. Incoming messages are pulled out of the hardware buffer and either:
- pushed onto the queue by an interrupt handler, using a further CAN HAL.
- sent to an emergency secondary handler, which runs in the context of the ISR.
Now, I am required to replace the buffering layer and HAL with a SocketCAN-based driver for the peripheral.
--------------------- | ---------------------
| | | | |
| Peripheral driver | Emergency | | Peripheral driver |
| | ^ | | |
----------------^---- | | ----------------^----
|Queue | | | |Queue |
| |Dequeue | | | |Dequeue
-----v--------------- --------------------- | -----v---------------
| | | | | | |
| CAN driver (queues) <-------- ISR | | | SocketCAN |
| | | | | | |
--------------------- ----------^---------- | ---------------------
| Tx | |
| | |
-----v--------------- | |
| | | |
| CAN HAL | Rx | |
| |------------------- |
--------------------- |
In the original setup, handling CAN reception in the ISR means that the emergency messages are dealt with as soon as possible. My understanding of SocketCAN is that it (or the World of Sockets, which I am not familiar with) handles the queuing of incoming frames, which means that emergency messages will have to wait until the peripheral driver has pulled out of the queue everything that arrived before the emergency.
Surely there is a way to handle certain messages first. How would I do that?
CodePudding user response：
I'm not super familiar with socketcan but what you are asking is usually done through hardware filtering. However, socket-can doesn't support hardware CAN filters and, after reading some docs, I don't think you can get a filter identifier for a specific CAN message.
But you could theoretically open a second socket-can on the same device with a separate set of filters and treat these differently.
CodePudding user response：
The answer I think I was looking for is that you must set up a signal and signal handler, or a handler for SIGIO, for the socket.
The topology would then again look like the original (left-hand side of the diagram).