You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a call tcflush() in termios Unix interface that is quite useful when used in TCIFLUSH queue selector. It allows us to efficiently clear OS input buffer from possible garbage data appeared during RS232 line idle. it is quite common when the peripheral RS232 device works in transaction mode, i.e. it is listening for host requests and responding on each request, not initiating transfer on its own. In this case calling tcflush() before writing the request at host side is a good practice.
The text was updated successfully, but these errors were encountered:
After taking a look at both tcflush and PurgeComm, it looks like it's plausible to encapsulate them both inside a SerialPort::purge(&mut self, queue: Queue) method. Queue could be an enum that selects between the input queue, the output queue, or both:
enumQueue{Input,Output,Both,}
Then it gets implemented with a single call to tcflush or PurgeComm as appropriate.
Does this look like a reasonable API? I would also find this useful for one of my projects.
There is a call
tcflush()
in termios Unix interface that is quite useful when used inTCIFLUSH
queue selector. It allows us to efficiently clear OS input buffer from possible garbage data appeared during RS232 line idle. it is quite common when the peripheral RS232 device works in transaction mode, i.e. it is listening for host requests and responding on each request, not initiating transfer on its own. In this case callingtcflush()
before writing the request at host side is a good practice.The text was updated successfully, but these errors were encountered: