Hello,
I dare to post my questions here while there is no newest anounced groups (at least my news reader
tells me so). Maybe it’s not appropriate place, then I will crosspost Here we go:
Q1:
When parameters of TTY device is changing, for example, baud rate or bits
number in character, by stty utility or programmaticly by tcsetattr(),
tto() function get called in this order:
- tto(TTYDEV*, TTO_STTY, 0);
- tto(TTYDEV*, TTO_CTRL, );
- tto(TTYDEV*, TTO_CTRL, );
Is this expected behaviour? Refering to common sense I think it should be:
- tto(TTYDEV*, TTO_CTRL, ); //inform remote terminal we’re buzy
- tto(TTYDEV*, TTO_STTY, 0); //change settings
- tto(TTYDEV*, TTO_CTRL, ); //inform remote terminal we’re ready
Note: digging thru code (unfortunatelly the source of library is only in QNX 6.1 NC ddk, so I don’t
have the latest one) I can’t yet explain why tto() function gets called in that order, but debugging
my driver which my implementation of tto() I clearly see that order.
Q2:
Under current behaviour there is quite regular pause between steps 2) and 3).
If it is even possible somehow to change the order it won’t make much sense for devc-ser8250 driver
until there is “turn on DTR, RTS” line in ser_stty() function. In oder words, as soon as
tto(TTYDEV*, TTO_STTY, 0) is called, the DTR line is setted, so, precise timeout by timer and step
3) won’t have any effect. Might be this is answer to Q1? But I still think that order is wrong.
Q3:
When file (/dev/serX) get closed (I guess by the last client who opened it), library makes pair of
calls disjoint in time by pause
tto(TTYDEV*, TTO_CTRL, );
tto(TTYDEV*, TTO_CTRL, );
So, question is why we need it? I can easily imagine situation when application opens serial port,
then writes some data and finally (immidiately) closes the port (without tcdrain(), of course) - I
suppose DTR signal will be turned off while the data will be coming out. Sometimes it can be cause a
truncated data stream.
Thanks in advance,
Eduard.