Der Can-Treiber nimmt alle auf dem Bus auftretende Telegramme entgegen und wertet diese per Software aus. Die Auswertung der eingetroffenen Daten geschieht im CAN-Receive-Interrupt. Das bedeutet somit, dass die Abarbeitung sehr schnell ausgeführt sein muß, um nicht zuviel Zeit im Interrupt zuu verbringen und so die restliche Firmware/Applikation zu blockieren. Die Hardwarefilterung der CAN-Hardware wird (derzeit) nicht genutzt. Die Filterung nach interessanten und nicht benötigten Botschaften geschieht dann später im Comm-Treiber.
Eintreffende CAN-Telegramme werden aus den Hardwareregistern ausgelesen und in eine allgemeine Datenstruktur umkopiert, die dann dem Comm-Treiber zur weiteren Verarbeitung übergeben wird. Allgemeine Datenstruktur bedeutet hier, dass es hier keine Can-typischen Besonderheiten mehr gibt. So wird bereits im Can-Treiber die Can-ID als solche aufgelöst und die Id-Daten in den Datenbereich eines „normalen“ Cah-Telegramms umgewandelt. Grund: Der Comm-Treiber soll sich nicht mehr um die Besonderheiten von darunterliegenden Schichten/Protokollen kümmern müssen.
Zu sendende CAN-Telegramm nimmt der Can-Treiber direkt als fertiges Can-Telegramm entgegen und reiht dieses in die Sendequeue ein (S12: 3stufig). Ist die Sendequeue aufnahmefähig, dann wird signalisiert, dass das Telegramm verarbeitet werden konnte, wenn nicht, so muss der Aufrufer seine Anfrage ggf. später erneut stellen. (CAN0_TX)
Der Sendequeue wird über einen Can-IRQ signalisiert, dass die nächsten Daten in die CAN-HW-Register kopiert werden können. (CAN0_TransmitInterrupt). So arbeitet sich die Sendequeue im Interruptbetrieb selbst ab – ganz ohne Eingriff einer zyklischen Funktion oder ähnlichem.
Der Can-Treiber selbst ist also nur eine sehr kurze/schlanke Instanz, die die Daten ungefiltert an die darüberliegende Schicht weiterleitet oder von dieser entgegennimmt.
(In diesem Abschnitt wurden folgende Komponenten angesprochen: drv_can)