devc-ser8250 and io-char library questions

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 :slight_smile: 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:

  1. tto(TTYDEV*, TTO_STTY, 0);
  2. tto(TTYDEV*, TTO_CTRL, );
  3. tto(TTYDEV*, TTO_CTRL, );

Is this expected behaviour? Refering to common sense I think it should be:

  1. tto(TTYDEV*, TTO_CTRL, ); //inform remote terminal we’re buzy
  2. tto(TTYDEV*, TTO_STTY, 0); //change settings
  3. 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.

In article <MPG.1a444e8d744ff747989712@inn.qnx.com>, ed1k@humber.bay
says…

Hello,

ping

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 > :slight_smile: > 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:

  1. tto(TTYDEV*, TTO_STTY, 0);
  2. tto(TTYDEV*, TTO_CTRL, );
  3. tto(TTYDEV*, TTO_CTRL, );

Is this expected behaviour? Refering to common sense I think it should be:

  1. tto(TTYDEV*, TTO_CTRL, ); //inform remote terminal we’re buzy
  2. tto(TTYDEV*, TTO_STTY, 0); //change settings
  3. 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.