RE: Confirming hardware Tx in socketCAN

Bram,

 

Thank you – I had seen mention of loopback, and perhaps that is a way – to wait until I see my specific message transmitted on the CAN bus.  But with further digging - specifically on the socketCAN developers list:  http://socket-can.996257.n3.nabble.com/   I noted a lot of posts back in 2008-2010 timeframe addressing what seemed to consider out-of-order messages as a bug.  My impression from those posting is that socketCAN is designed to always keep order of packets.  As I cannot find anything on that in the API documents (specifically can.txt) I have a query to that list asking for confirmation.  It seems that list’s traffic has slowed down these past years, but if I get any insight will reply back here.

 

Does this match up with your experience?   Or, are you thinking the real solution is to monitor the loop-back and confirm transmission.  And hum… w/o digging into each hardware driver, is there a way to tell if the driver supports actually hardware based loopback, or if it only came back via emulation?   

 

-al-

 

 

Viking Star

45' Monk Sr. / McQueen

mvVikingStar.blogspot.com

 

From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Monday, March 13, 2017 4:14 AM
To: [email protected]
Subject: Re: [CANLIST] 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-