Re: rt_dev_send() stalls periodic task

[C Smith <csmithquestions@gmail.com>]

Thanks for your insight, Steve. I didn't realize rt_dev_write() doesnt
actually stall until it is called many times and the 4K TX buffer gets
full. (is that right Jan?)
It that is the case, sure I could find a way to check the TX buffer fill
level to prevent my app from stalling.

I rewrote the xeno_16550A driver RTSER_RTIOC_GET_STATUS ioctl to return to
userspace the contents of the IIR and the IER too.
I'm getting IIR = 0b 0001 0100, so the source of the latest interrupt is a
RX (not surprising, as I'm doing full duplex) and there is no THRE
interrupt pending.
So regardless of the ultimate cause, this state will never empty the TX
buffer.

I think my only choice is to try something I had to do once before on a
similarly misbehaving serial port: I'll rewrite the xeno_16550A interrupt
handlers to redundantly check for data pending in the TX buffer whenever
any interrupt like an RX interrupt happens. I do have bidirectional traffic
after all, so the driver will wake up frequently and keep the TX data
transmitting.

Interesting enough, the stall problem did not occur when I used the sample
serial code provided by xenomai: cross-link.c . I also rewrote cross-link.c
to send a 72 byte packet and receive on the same port (I installed a
physical loopback device on the serial port). No stalls for 12+ hours with
packets streaming at 100 Hz.
The only difference in the serial configuration between that cross-link.c
app and my app was :
struct rtser_config :
        .rx_timeout        = RTSER_DEF_TIMEOUT  // infinite ,  no stall for
many hours in cross-link.c
versus:
        .rx_timeout        = 500000   // 500us, stalls within an hour in my
app
I don't know why an RX setting affects TX behavior. I also can't use
RTSER_DEF_TIMEOUT in my application or it dies when it starts up - no clue
why.  But I did try setting
  .rx_timeout        = 5000000   // 5 ms. my app doesnt stall for several
hours
and though that did not cause the serial to stall in my app for several
hours of testing, it is just open-loop finger-crossing, and not a real
solution.
I need the TX interrupts to fire reliably. So I think I must rewrite that
interrupt handler, as above.

-C Smith