devc-ser8250 and io-char library questions

bridged with qdn.public.ddk

devc-ser8250 and io-char library questions

Postby ed1k » Sat Dec 13, 2003 2:16 am

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:

1) tto(TTYDEV*, TTO_STTY, 0);
2) tto(TTYDEV*, TTO_CTRL, <arg1 to clear DTR>);
3) tto(TTYDEV*, TTO_CTRL, <arg1 to set DTR>);

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

1) tto(TTYDEV*, TTO_CTRL, <arg1 to clear DTR>); //inform remote terminal we're buzy
2) tto(TTYDEV*, TTO_STTY, 0); //change settings
3) tto(TTYDEV*, TTO_CTRL, <arg1 to set DTR>); //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, <clear DTR>);
tto(TTYDEV*, TTO_CTRL, <set DTR>);
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.
ed1k
 

Re: devc-ser8250 and io-char library questions

Postby ed1k » Sat Jan 10, 2004 3:03 am

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 :) 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, <arg1 to clear DTR>);
3) tto(TTYDEV*, TTO_CTRL, <arg1 to set DTR>);

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

1) tto(TTYDEV*, TTO_CTRL, <arg1 to clear DTR>); //inform remote terminal we're buzy
2) tto(TTYDEV*, TTO_STTY, 0); //change settings
3) tto(TTYDEV*, TTO_CTRL, <arg1 to set DTR>); //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, <clear DTR>);
tto(TTYDEV*, TTO_CTRL, <set DTR>);
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.
ed1k
 


Return to qdn.public.ddk

Who is online

Users browsing this forum: No registered users and 1 guest

cron