Hello.
I am writing an app that needs to control the
serial xmit in real-time. What I need is a notification
that the TTY output queue fillup (returned by TIOCOUTQ
ioctl) have dropped below the specified value.
I haven't found anything that can help implementing
this. If I can't get an async notification, the sync
notification will do too, like, for instance, the tcdrain()
call, but with the argument to specify the needed fillup,
below which the function will return.
If there is nothing like this, then even the notification
on every transmitted char will do.
But I've found nothing of the above. :(
Any suggestions how the real-time control can be
implemented?
(please CC me the replies)
> I am writing an app that needs to control the
> serial xmit in real-time. What I need is a notification
> that the TTY output queue fillup (returned by TIOCOUTQ
> ioctl) have dropped below the specified value.
Not a supported feature basically.
> I haven't found anything that can help implementing
> this. If I can't get an async notification, the sync
> notification will do too, like, for instance, the tcdrain()
> call, but with the argument to specify the needed fillup,
> below which the function will return.
> If there is nothing like this, then even the notification
> on every transmitted char will do.
> But I've found nothing of the above. :(
>
> Any suggestions how the real-time control can be
> implemented?
Bascially even on the hardware that knows with this degree of granularity
we don't propogate the information back in the manner you want.
I'm not sure its a total loss however. Currently all the code basically
does stuff in the tx path or tx irq handler along the line of
if (bytes_left < constant)
write_wakeup
and I suspect if you made that adjustable and turned off the fifo and any
other funnies you'd at least make it work for a sufficiently rigged demo.
We could in theory put it in the tty_port in future too if its general
purpose useful.
Alan
Hi Alan, thanks, clear enough now. :)
10.08.2012 23:33, Alan Cox wrote:
> if (bytes_left < constant)
> write_wakeup
>
>
> and I suspect if you made that adjustable and turned off the fifo and any
> other funnies you'd at least make it work for a sufficiently rigged demo.
You suggest to turn off the fifo, sounds worrysome,
does this mean that tcdrain() and TIOCOUTQ do not
account the fifo too?
If they do quite fine with the fifo, then maybe the new
function will do too? Its basically a tcdrain(), just with
the controllable watermark I guess.
> If they do quite fine with the fifo, then maybe the new
> function will do too? Its basically a tcdrain(), just with
> the controllable watermark I guess.
I guess providing you account the fifo, and any hardware flow control it
would work.