From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <2ade719a-84c7-c53d-9895-a5e6eea354a3@siemens.com> In-Reply-To: <2ade719a-84c7-c53d-9895-a5e6eea354a3@siemens.com> From: C Smith Date: Sat, 20 Apr 2019 21:33:47 -0700 Message-ID: Subject: Re: rt_dev_send() stalls periodic task Content-Type: text/plain; charset="UTF-8" List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Sumitabh Ghosh via Xenomai Per your suggestion, I added code to call this ioctl, right after the rt_dev_write() : rt_dev_ioctl(fd_tty[1], RTSER_RTIOC_GET_STATUS, &serial_status); I let the transmit stall again, then attached with a gdb, which allows me to step forward to the ioctl: serial_status.line_status was 96 decimal, or 0110 0000 binary which means both transmit holding and transmit shift registers were empty, thus nothing was queued up in the UART for transmission. The return value of rt_dev_write() was only 8, after a 72 byte packet was submitted to rt_dev_write(). So your theory that the TX interrupt got lost seems correct. First, why does rt_dev_write() wait until all bytes are transmitted ? Shouldn't it be effectively "non blocking" ? Second, how might l generate another UART TX interrupt to keep the transmission going? Can we modify the serial driver at a low level to check the LSR vs the bytes in the buffer, and force transmission until the buffer is empty? thanks, -C Smith