tcdrain / TCSBRK / wait_until_sent delay

tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

Hello,

I wonder if anyone can help me with this as a problem?  I'm trying to send 
commands to a device along a two wire RS485 connection.  I'm using an RS232 
to RS485 converter that changes the buffer direction based on RTS.  With that 
in mind I therefore do things like (error detection left out for brevity)

bit = TIOCM_RTS;
ioctl( fd, TIOCMBIS, &bit );
write( fd, "\xaa", 1 );
tcdrain();
ioctl( fd, TIOCMBIC, &bit );

This triggers the other end to send a response that I read back with 
select/read.  However, what I am reading has the front few bytes corrupted.  
Sticking a scope on the TXD and RTS lines of the serial port shows that

      ______________________________________
RTS __|                                    |_____
       _____ ___ ___ ___
TXD ___|   |_| |_| |_| |_________________________
        S 1 0 1 0 1 0 1 0 s
                           <-----delay---->

There is a small delay between RTS going high and the data starting - no 
problem there, however, when the transmission finishes there is a 2 byte 
delay before RTS goes low.  The device I'm talking to has (apparently) a 
response time of 200us; I'm seeing a delay before restoration of RTS of 2ms. 
write() returns immediately - the delay is coming from tcdrain() - but I 
cannot see from where.

With a bit of digging I've found that tcdrain() simply calls ioctl(TCSBRK,1) 
which I guess ends up in

linux/driver/char/tty_io.c:         tty_ioctl() which calls
linux/driver/char/tty_ioctl.c:      tty_wait_until_sent() which calls
linux/driver/serial/serial_core.c:  uart_wait_until_sent()

uart_wait_until_sent() then sits and waits for /at most/ two characters worth 
of timeout for

linux/driver/serial/8250.c: serial8250_tx_empty()

to tell it that it can return.  It appears (in my very newbie eyes) that 
uart_wait_until_sent() checks for tx_empty() every 1/5th of a byte, I would 
think that would be more than enough.  It takes negligible time for 
serial8250_tx_empty() to call serial_in() to read the UART status register.  
I imagine that the msleep_interruptible() call is well tested in Linux.

My question then is where is the time going?  It seems suspicious that 
uart_wait_until_sent() has an overall timeout of two character times - 
exactly the excess I'm seeing.  Am I right to be suspicious?  Have I 
understood any of this?  Is it unreasonable to expect Linux to do a 200us 
turnaround?



Andy
-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcdrain / TCSBRK / wait_until_sent delay

[rich+ml]

On Thu, 5 May 2005, Andy Parkins wrote:

> Is it unreasonable to expect Linux to do a 200us turnaround?

Assuming you have 2.6 kernel? HZ=1000 and you'll only get 1mS resolution

== Rich

Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Thursday 2005 May 05 18:51, rich+ml@lclogic.com wrote:

> > Is it unreasonable to expect Linux to do a 200us turnaround?
>
> Assuming you have 2.6 kernel? HZ=1000 and you'll only get 1mS resolution

Thanks for your response.  You'll have to forgive me, I'm only vaguely 
familiar with the kernel internals.  I thought that because all of the work 
is being done in the kernel that the HZ value wouldn't have an effect?  In 
serial_core.c: uart_wait_until_sent() the character timeout is defined as

char_time = (port->timeout - HZ/50) / port->fifosize;
char_time = char_time / 5;

From this I guess that port->timeout is the estimated time for the whole 
transmit buffer, which is then divided by port->fifosize to make this a per 
character time which is then divided by five to ensure that the check for 
tx_empty() is done five times per character (the comments say this is to 
satisfy NIST-PCTS, whatever that is).  I'm not sure what the HZ/50 is for.

These times will all be significantly smaller than 1ms; if the value of HZ 
where going to affect this then why has the author bothered to calculate 
these times at all?  1ms would drown these other timeouts out.

Apologies if these are all stupid questions; as I say, I don't really know 
what I'm talking about. 


Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcdrain / TCSBRK / wait_until_sent delay

[rich+ml]

On Fri, 6 May 2005, Andy Parkins wrote:

> I'm not sure what the HZ/50 is for.
Undoes some fudge factor added on when first calculated.

> These times will all be significantly smaller than 1ms; if the value of HZ
> where going to affect this then why has the author bothered to calculate
> these times at all? 1ms would drown these other timeouts out.
It only kicks in for sub-1200 baud.

In any case linux is not an RTOS, it does not guarantee maximum latency,
so no matter what you are going to be intermittent at best.

Have you tried hardware flow control, "stty crtscts < /dev/ttyX"?.  With
CTS strapped high, RTS should follow THRE||TE.

== Rich

Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Friday 06 May 2005 20:14, rich+ml@lclogic.com wrote:

Thanks for your response.

> It only kicks in for sub-1200 baud.

Oh dear.

> In any case linux is not an RTOS, it does not guarantee maximum latency,
> so no matter what you are going to be intermittent at best.

I appreciate that, I was disappointed because I know that some other people 
are doing this on Windows and I assumed Linux would be able to kick a**.  
Considering the magic that Linux can do elsewhere, it didn't seem 
unreasonable to expect 9600 half duplex.  :-(

> Have you tried hardware flow control, "stty crtscts < /dev/ttyX"?.  With
> CTS strapped high, RTS should follow THRE||TE.

That's an interesting idea - CTS is currently set by the RS485 converter to 
indicate when it has successfully turned the buffer around.  So it goes, RTS 
set high, wait for CTS, send...  Is what you're suggesting that I cut this 
wire and hold CTS high externally?

Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcdrain / TCSBRK / wait_until_sent delay

[Gerald Emig]

On Fri, 6 May 2005 12:14:51 -0700 (PDT)
rich+ml@lclogic.com wrote:

> On Fri, 6 May 2005, Andy Parkins wrote:
> 
> > I'm not sure what the HZ/50 is for.
> Undoes some fudge factor added on when first calculated.
> 
> > These times will all be significantly smaller than 1ms; if the value
> > of HZ where going to affect this then why has the author bothered to
> > calculate these times at all? 1ms would drown these other timeouts
> > out.
> It only kicks in for sub-1200 baud.
> 
> In any case linux is not an RTOS, it does not guarantee maximum
> latency, so no matter what you are going to be intermittent at best.


That is the key: because switching the handshake lines is commonly done
by software, it usually can not be reliable if you need a correct
switching of RTS.
You should instead purchase a dedicated RS485 board that does the
switching by hardhare.


> 
> Have you tried hardware flow control, "stty crtscts < /dev/ttyX"?. 
> With CTS strapped high, RTS should follow THRE||TE.

Probably with a delay depending on the current system load, I suppose !




Gerald

Re: tcdrain / TCSBRK / wait_until_sent delay

[rich+ml]

> > Have you tried hardware flow control, "stty crtscts < /dev/ttyX"?.  With
> > CTS strapped high, RTS should follow THRE||TE.
>
> That's an interesting idea - CTS is currently set by the RS485 converter to
> indicate when it has successfully turned the buffer around.  So it goes, RTS
> set high, wait for CTS, send...  Is what you're suggesting that I cut this
> wire and hold CTS high externally?

Oh no, in that case you don't need to do anything. The transaction you
described is exactly what happens automatically when crtscts is enabled.

However if your uart doesn't actually support AFE then it will be done
by the driver and have the timing characteristics you see already.

Hook up your scope, "stty crtscts < /dev/ttyX; echo test > /dev/ttyX" and
see what happens.

== Rich

Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Saturday 2005 May 07 19:09, rich+ml@lclogic.com wrote:
> > > Have you tried hardware flow control, "stty crtscts < /dev/ttyX"?. 
> > > With CTS strapped high, RTS should follow THRE||TE.
> >
> > That's an interesting idea - CTS is currently set by the RS485 converter
> > to indicate when it has successfully turned the buffer around.  So it
> > goes, RTS set high, wait for CTS, send...  Is what you're suggesting that
> > I cut this wire and hold CTS high externally?
>
> Oh no, in that case you don't need to do anything. The transaction you
> described is exactly what happens automatically when crtscts is enabled.
>
> However if your uart doesn't actually support AFE then it will be done
> by the driver and have the timing characteristics you see already.
>
> Hook up your scope, "stty crtscts < /dev/ttyX; echo test > /dev/ttyX" and
> see what happens.

Are you sure that RTSCTS flow control is what you think it is?  These days RTS 
means "request to send to me" rather than "I request to send"; that allows 
RTS and CTS to be crossed over in null modem cables - and puts the flow 
control in the receiver directly.

Of course in my case the RS485 converter is abusing the RTS line for its own 
purposes, which is why I set -CRTSCTS.

Regardless of all that, I tried it anyway with no joy :-)

I'm coming to accept that what I'm after isn't possible.  How likely is it 
that I could patch the serial_core kernel driver to do the RTS control for 
me?  Am I going to end up in the same situation?


Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: tcdrain / TCSBRK / wait_until_sent delay

[Tosoni]

> I appreciate that, I was disappointed because I know
> that some other people are doing this on Windows and
> I assumed Linux would be able to kick a**.
> Considering the magic that Linux can do elsewhere, it
> didn't seem unreasonable to expect 9600 half duplex.  :-(

Hi,

I have the same problem and here is where I am:

- Windows can handle this because it has a RTS mode ioctl called
"RTS_TOGGLE" which sounds perfectly OK for your use (and mine).

- Historically UNIX did not implement such ioctl, and so did (not) LINUX.

- I suggested last year to create such ioctl in LINUX.

- Mr Russell King answered me that the good way to do this is to handle it
in the user space application, which is obviously flawed and results in the
delays you see because of user-space time-sharing granularity.

- Then Mr Russel King suggested to redesign a complete "line discipline"
just to handle the missing RTS feature. I must note that such "line
discipline" would duplicate completely the existing default line discipline
except for the RTS_TOGGLE ioctl.

- So I implemented the RTS_TOGGLE for myself in the serial driver, but my
(small, non-intrusive) patch would not be accepted in the standard serial
driver.

Well, if you use the Oxford 16C95x chip, I can provide you with a patched
driver for kernel 2.6.10. Or I can sell you my own RS485 card with drivers
(we are manufacturers - www.acksys.fr)

I wish linux people would accept to add such ioctl in the standard serial
API. Even if it is not immediately implemented in the serial drivers, it
would give a standard path for anyone wishing to implement it. I am sure
many people miss it in a time where LINUX is used more and more in
industrial appliance.

Jean-Pierre Tosoni
ACKSYS

Re: tcdrain / TCSBRK / wait_until_sent delay

[Russell King]

On Mon, May 09, 2005 at 10:16:03AM +0200, Tosoni wrote:
> - Then Mr Russel King suggested to redesign a complete "line discipline"

Please do me the reasonable curtesy of spelling my name correctly.

> just to handle the missing RTS feature. I must note that such "line
> discipline" would duplicate completely the existing default line discipline
> except for the RTS_TOGGLE ioctl.

Interestingly, I've reviewed our discussions back in December, and
they aren't exactly how you recollect them to be.  I gave you the
historical position, and suggested both a possible way forward and
someone else for you to talk to about this.

It also appears that you continued to press for _your_ original
implementation, justifying it against the historical position (both
of which I'd already suggested weren't suitable.)

Maybe I didn't explain clearly enough why your implementation wasn't
suitable.  Adding an IOCTL for RS485 RTS style vs conventional RTS
style causes problems.  Consider what happens when:

1. we get a third (and there are more than two) flow control styles.
2. the port is closed and something else opens it which wants standard
   flow control. (or even an overlapping open/close.)

I have also suggested to a third party about adding a feature by which
the flow control method could be changed between several different
settings, preferably via the existing control implmentation - termios.
This should resolve both of the above.

Unfortunately, that also went by un-noticed and as such hasn't progressed.

Therefore, there has been no progress on different flow control styles.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: tcdrain / TCSBRK / wait_until_sent delay

[Christer Weinigel]

Andy Parkins <andyparkins@gmail.com> writes:

> I wonder if anyone can help me with this as a problem?  I'm trying to send 
> commands to a device along a two wire RS485 connection.  I'm using an RS232 
> to RS485 converter that changes the buffer direction based on RTS.  With that 
> in mind I therefore do things like (error detection left out for brevity)
> 
>       ______________________________________
> RTS __|                                    |_____
>        _____ ___ ___ ___
> TXD ___|   |_| |_| |_| |_________________________
>         S 1 0 1 0 1 0 1 0 s
>                            <-----delay---->
> 
> There is a small delay between RTS going high and the data starting - no 
> problem there, however, when the transmission finishes there is a 2 byte 
> delay before RTS goes low.  The device I'm talking to has (apparently) a 
> response time of 200us; I'm seeing a delay before restoration of RTS of 2ms. 
> write() returns immediately - the delay is coming from tcdrain() - but I 
> cannot see from where.

As others have told you, the granularity of HZ in the stock Linux
kernel isn't good enough to give you a 200us RTS shutoff.  What you
should be able to do is something like this:

    usigned int lsr;

    bit = TIOCM_RTS;
    ioctl( fd, TIOCMBIS, &bit );

    do {
        ioctl(fd, TIOCSERGETLSR, &lsr);
    } while (lsr & TIOCSER_TEMT);

    ioctl( fd, TIOCMBIC, &bit );

This will busy wait until the transmitter is empty.  It's wasteful,
but it'll probably work.  Remember to add error checking to the above
code, and you may want to run it with a realtime priority when you've
seen that it works.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: tcdrain / TCSBRK / wait_until_sent delay

[Christer Weinigel]

Christer Weinigel <christer@weinigel.se> writes:

>     do {
>         ioctl(fd, TIOCSERGETLSR, &lsr);
>     } while (lsr & TIOCSER_TEMT);

Should be !(lsr & TIOCSER_TEMT), since the bit set means that the
transmitter is empty.

Note to self.  _Always_ check posted code one extra time.  :-/

  /Christer
 
-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

RE: tcdrain / TCSBRK / wait_until_sent delay

[Tosoni]

Hello Russell,

First I apologize for not spelling your name correcty. Also, I wrote the
previous mail of memory of our discussion because my mail archives were
since destroyed in some part.

Still it is true that I pushed my suggestion, since it works so perfectly
well in Windows. (for your records I wrote serial drivers in Unix far before
Windows was born, so don't call me a Windows enthusiast please).

> 1. we get a third (and there are more than two) flow control styles.
> 2. the port is closed and something else opens it which wants standard
>    flow control. (or even an overlapping open/close.)

I did not understand well your motivations before. I'm not sure I get all
the implications you suggest. But did you consider theses points:

a) The change we are seeking is not a new flow control at all, in the
   sense that it has absolutely no concern with buffer-full events.
b) The change we are seeking is *exclusive* with other uses of RTS
   (that is how it is done in Windows)
c) With RS485 we are talking about, e.g., a computer installed in a
   factory and connected to an automaton. There is no purpose for someone
   to reopen the port for another kind of use (I know this argument is weak)
d) We could define (since the functionality is not yet defined) that in
   the last close the standard RTS behaviour is reinstated. But still,
   there are differences between some UNIXes and LINUX regarding what state
   is kept between close and open.

Finally, I agree that the best would be to add this feature in termios -
well, it is exactly what I am seeking: to define a application API which
would be recognized as a standard. I am tired of reimplementing my own way
in each release of Linux. I am tired of seeing the same need implemented by
different people with diverging ioctls over and over.

When I talked to Allan Cox as you suggested, there was no answer from him.
Maybe too busy?

Jean-Pierre Tosoni

Re: tcdrain / TCSBRK / wait_until_sent delay

[Russell King]

On Mon, May 09, 2005 at 12:03:32PM +0200, Tosoni wrote:
> I did not understand well your motivations before. I'm not sure I get all
> the implications you suggest. But did you consider theses points:
> 
> b) The change we are seeking is *exclusive* with other uses of RTS
>    (that is how it is done in Windows)

There are many different styles of use of RTS.  The conventional one
and your one are only two.  There are more than two, and all of them
are exclusive.  I don't see why you made the above comment, since we
obviously agree.

> c) With RS485 we are talking about, e.g., a computer installed in a
>    factory and connected to an automaton. There is no purpose for someone
>    to reopen the port for another kind of use (I know this argument is weak)

Consider a brail device which requires non-standard RTS behaviour,
which may be replaced by a modem.

> d) We could define (since the functionality is not yet defined) that in
>    the last close the standard RTS behaviour is reinstated. But still,
>    there are differences between some UNIXes and LINUX regarding what state
>    is kept between close and open.

As I tried to point out (and you missed) there is no clear point at which
the port is closed.  Consider the following scenario:

	1. program A has the port open.
	2. program B tries to open the port, but blocks in the open,
	   waiting for program A to free up the port.
	3. program A closes the port.
	4. program B finally returns from the open call.

Compare this with:

	1. program A (eg, terminal program) has the port open.
	2. program B (eg, file upload utility) opens the port and
	   sends its data.
	3. program B closes the port.

With the second scenario, it's clear that step 3 shouldn't reset the
behaviour.  However, what about the first scenario?

> When I talked to Allan Cox as you suggested, there was no answer from him.
> Maybe too busy?

I can't talk for Alan.  However, Alan has taken on the task of looking
after the tty layer, and so Alan needs to comment.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Monday 2005 May 09 10:22, Christer Weinigel wrote:
> Christer Weinigel <christer@weinigel.se> writes:
> >     do {
> >         ioctl(fd, TIOCSERGETLSR, &lsr);
> >     } while (lsr & TIOCSER_TEMT);
>
> Should be !(lsr & TIOCSER_TEMT), since the bit set means that the
> transmitter is empty.
>
> Note to self.  _Always_ check posted code one extra time.  :-/

Hurrah! What you suggest has given me exactly what I needed.  Thank you so 
much.



Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcdrain / TCSBRK / wait_until_sent delay

[Theodore Ts'o]

On Mon, May 09, 2005 at 11:13:38AM +0100, Russell King wrote:
> 
> There are many different styles of use of RTS.  The conventional one
> and your one are only two.  There are more than two, and all of them
> are exclusive.  I don't see why you made the above comment, since we
> obviously agree.
> 

It's worse than this.  Even with the ancient/historic RTS/CTS toggle
approach, I've heard all sorts of different timing constraints.  For
example, in some implementations the implementation must wait at
_least_ (or in other cases no more than) some time period before
toggling CTS.  The old RS-422 devices were so crufty that they all had
their own idiosyncratic requirements.

My suggestion would be to do this as a new line discpline, and have
the line displine act as a pass-through to the N_TTY line displine for
those things that it doesn't need to do differently.

						- Ted

Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Monday 2005 May 09 10:22, Christer Weinigel wrote:
> Christer Weinigel <christer@weinigel.se> writes:
> >     do {
> >         ioctl(fd, TIOCSERGETLSR, &lsr);
> >     } while (lsr & TIOCSER_TEMT);

In case you are interested, I found another problem (but this time a solution 
too); my code is now (edited for brevity):

	do {
		ioctl(fd, TIOCSERGETLSR, &i);
	} while( !i & TIOCSER_TEMT );
	tcdrain( fd );

The tcdrain() at the bottom returns fast (presumably because the transmit 
buffer is already empty) so the original problem is solved.  Without the 
tcdrain() the port is left in a strange state - at random, future writes are 
silently dropped.  The echo back when this happens is simply a NUL.  With the 
tcdrain() in place, that problem goes away as well.

Andy


-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: tcdrain / TCSBRK / wait_until_sent delay

[rich+ml]

> Christer Weinigel <christer@weinigel.se> writes:
>
> >     do {
> >         ioctl(fd, TIOCSERGETLSR, &lsr);
> >     } while (lsr & TIOCSER_TEMT);
>

Ah that'll usually work OK but try it after this:

 for (( x=0; x<100; x++ )); do tar -c / > /dev/null & done

Hopefully we're not talking about an RS-485 industrial pallet nailer :)

Re: tcdrain / TCSBRK / wait_until_sent delay

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

On Monday 2005 May 09 17:33, rich+ml@lclogic.com wrote:
> On Mon, 9 May 2005, Andy Parkins wrote:
> > Are you sure that RTSCTS flow control is what you think it is?  These
> > days RTS means "request to send to me" rather than "I request to send";
> > that allows RTS and CTS to be crossed over in null modem cables - and
> > puts the flow control in the receiver directly.
>
> Yep. RTS is an output from the PC, CTS is an input to the PC, weird
> cabling does not change this.

I wasn't suggesting otherwise; I think these days though, RTS doesn't mean 
that the PC is requesting to send it means the PC is open to receiving. 

http://www.pccompci.com/cable.html

Hence, when the RTS and CTS are crossed over in a null modem cable (which 
isn't by any means weird) RTS from device 1 lights up CTS in device 2 and 
vice versa -- exactly what would be required.  Although t

> > I'm coming to accept that what I'm after isn't possible.  How likely is
> > it that I could patch the serial_core kernel driver to do the RTS control
> > for me?  Am I going to end up in the same situation?
>
> I believe you will end up in the same situation.

As it happens, Christer Weinigel in another part of the thread suggested a 
solution that I've had great success with - so thankfully I don't have to go 
near the kernel :-)

> You might take a look at a usb-to-serial cable, kernel will 'mount' it as
> /dev/ttyUSB0 or something so the application doesn't have to know any
> better. However these cables contain PL2303 or similar uart which supports
> auto rts/cts if so enabled (the idea is to not push every control signal
> transient down the usb). Google for PL2303 spec, look for pl2303.c in the
> kernel.

That would be an excellent solution, and I still may look into that - the 
option of lots of serial ports via USB has a certain appeal.

Again, thanks for your help on this.  It's all been (and continues to be) very 
interesting.

Andy

-- 
Dr Andrew Parkins, M Eng (hons), AMIEE


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]