Re: Clear transmit buffer (of pending queued tx-messages)

[Wolfgang Grandegger <wg@grandegger.com>]

Am 23.06.2016 um 10:45 schrieb ajneu:
> Oliver Hartkopp <socketcan <at> hartkopp.net> writes:
>
>>
>> The question is whether blocking write (and probably write outdated
>> content) is what you want for CAN.
>
> Oliver Hartkopp posted that on a different thread...
> Subject: Re: want blocking writes, but eventually get: errno 105 (No buffer
> space available)
> Date: 2016-06-22 15:52:04 GMT (15 hours and 32 minutes ago)
>
> OK ->
>
> I've tried non-blocking.
> Unfortunately non-blocking will not tell you if messages are delivered or not.
>
> Example:
> If I send out 2 messages (non-blocking) with no participant on the bus,
> those messages will remain queued.

Yes, in software but also hardware queues.

> If 5 minutes later a participant joins the bus, he'll get those 2 very old
> messages: outdated content.

Yep.

> What are my options to solve this?

The only method I know to flush the queue is restarting the device 
(down->up).

> (Can I find out if a message has actually been sent out onto the bus?)

If you really need to known, you could check for the looped back message 
on the same socket enabling CAN_RAW_RECV_OWN_MSGS. But it will slow down 
the message transfers.

> (I'm currently thinking about checking the CAN-Bus status: If NOT
> error-active (and high tx count), I know that tx-messages will not get
> delivered.

Well, the errors could also be caused by other issues. You could check 
for no-ack bus error messages but not all CAN controllers support that 
feature.

> But if I had a few messages in the queue, I still cannot tell which ones got
> delivered. Hmmmm...

See above.

Wolfgang.