Re: What are you doing if the TX buffer overflows?

[Kurt Van Dijck <kurt.van.dijck@eia.be>]

On Mon, Sep 17, 2012 at 09:40:41PM +0200, Heinz-Jürgen Oertel wrote:
> 
[...]
> > 
> > > Or read out the occupied size of it
> > > to get the mumber of CAN frames waiting for transmission?
> > 
> > 
> > I'll take a look, if there's a programming interface to get this value.
> > Or is this request obsolete now after my answer above?
> 
> No. This is still of interest.
> Knowing if the transmit queue is mostly empty is a good thing.
> Otherwise the application is sending to fast,

I distinguish 2 use cases there:
1. repeating a limited set of identical frames endlessly (eg. grabbing a bootloader)
2. burst a lot of data on the bus.

Case 1 can be solved by setting CAN_RAW_RECV_OWN_MSGS. If you don't
see your transmitted frames, it makes no sense to repeat it, since
they're still queued.

Case 2 is solved by waiting a little while when you get ENOBUFS. This
way, you will not need to track the buffer's status.
Throttling messages based on buffer fill status is a bit difficult
in a multi-user environment. You may know the buffer max. size,
but not the number of applications using it.

Can your issue be categorized under one of these 2 cases?
If not, I'd like to learn the use case :-)

Kurt