2007/9/14, Jan Kiszka <[EMAIL PROTECTED]>: > > > > For some kind of "realtime" serial communication ones > > may need something like "synchronous" write, meaning > > driver write call should block or timeout if underlying HW is not > > able to send the provided data. > > Yes, I agree, I just don't want to change the semantic of rtserial's > write service. Besides likely breaking existing apps, I don't see the > need for the change in the _common_ case. Most scenarios I saw so far > either used the real-time UART port just for reading (+ some > initialisation maybe) or they synchronised on the transmission by > waiting on a reply from the devices. The case that you just write was > yet not required, but it is a valid one. For that case, a patter of > "write to port" + "wait on TXDONE event" would be appropriate IMO.
May be you may mimic the POSIX termios API (cf man termios(3)) which would be "write to fd" then "tcdrain" it. This is just the same behavior you described with a known API. May be such API (tcdrain) only deserve to be in userland or the serial device profile may be updated to include feature inspired from termios. May be another RTSER_RTIOC_DRAIN which may be the same as RTSER_RTIOC_WAIT_EVENT on TXDONE. Talking about this I don't really know who (driver, kernel, libc) is doing what (write,ioctl, ...) when I use the termios API on a "classical" linux serial device. However I thought termios might be inspiring for RTDM serial device profile. -- Erk _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
