RE: Confirming hardware Tx in socketCAN

I think this is a good forum for this question.  It has applications for a
protocol like MilCAN for example.
 
In MilCAN there's a rule that the messages should be sent as One Shot.  No
retries since a runaway retry could step on top of place where the SYNC FLAG
message must appear.
 
For processors that don't have that ability the application needs to be able
to verify that the message was properly sent before the next SYNC FLAG
message and if not needs to be cancelled.
 
Therefore the ability to verify the status of a message (or cancel it)  is
fairly important.  I'd certainly like to know how this would be done.
Thanks
John Dammeyer
 
 
 
From: [email protected] [mailto:[email protected]] On Behalf
Of Al Thomason
Sent: March-09-17 9:27 AM
To: [email protected]
Subject: [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-