Re: Confirming hardware Tx in socketCAN

Unless you have disabled it explicitly, CAN messages that are sent via a socket are "looped back" via the hardware driver to other open sockets so other clients are aware of the message you have sent. 
By setting the raw socket option CAN_RAW_RECV_OWN_MSGS a socket will also receive the messages that have been sent through it. This looped back message can be used to validate whether a message was indeed sent by the controller. 

However: there is an important caveat -- the hardware driver needs to support looping back sent messages otherwise SocketCAN will happily emulate it in software and every message will appear to have been sent regardless if it ever got on the wire or not! 

I'm not aware of a better implementation with SocketCAN. 





cheers, 

Bram 

Van: "Al Thomason" <[email protected]> 
Aan: [email protected] 
Verzonden: Donderdag 9 maart 2017 18:27:26 
Onderwerp: [CANLIST] Confirming hardware Tx in socketCAN 



I am not sure if this is the best forum to ask socketCAN questions on, if there is a better place - suggestions appreciated. 



I am porting an existing program from a micro-controller to be usable in Linux. I am using socketCAN for the Tx and Rx capabilities and all is working well using non-blocking RAW writes (letting the socket queue do its job). However, one of the needs of the existing program is to assure a given packet has been sent out via the hardware. It uses this to coordinate in-order transmission of multi-packet messages. Is there a way to poll a CAN socket to determine if indeed a message has been sent, or if the entire queue is empty? All references I have found to date cover file or perhaps TCP access – and changing (even temporarily) to blocking writes risks wedging the application. 



Right now I am using an ugly sleep() for 3mS after transmitting ‘need to confirm’ packets, with the idea being to raise the likelihood a given packet was indeed sent (if it can be at all). However, clearly some other non-delay approach would be preferred. Any other ideas? 



Thank you in advance for any suggestions. 



-al-