On Wednesday 06 August 2008, Christopher Gibson wrote: > Been a few years since I ran into this issue, but are faced with it > again. Last time the timing wasn't to critical and I managed to use > user space control of the RTS line to achieve RS485 buffer direction > control. In this case I had control of the response time of the slave > processor, so got away with it. This time I haven't got that much > control over the timing of the slave units, and a bit more load on the > Linux system, and a user space solution is just not cutting it. Have > hacked up a kernel to give me the RTS control I need, but started > working on a more generic (and less CPU wasting) solution. It was part > of this work that lead me to this mail group, as I was looking for > conventions on how to enable RTS direction control. It would seem, > looking through this mail list that any convention is yet to be defined > for Linux. That's right. Hopefully we should achieve a consensus on the API soon. > On Tue, 2008-08-05 at 14:55 +0200, Tosoni wrote: > > > -----Original Message----- > > > From: Laurent Pinchart > > (...) > > > > > We already have 3 distinct modes for RTS/CTS (see my mail > > > from today 11:23:36 in this thread). If we add DSR/DTR > > > hardware support we can easily get 5 or 6 modes. We will run > > > out of bits in c_cflags. > > > > > The three modes which you identify are > > (A) bus direction > > (B) send data request (well... RTS=Request To Send :-)) which should be > > acknowledged by CTS > > (C) input flow control > > but, the RTS is widely used for (A)=bus direction BECAUSE it is the same > > behaviour than (B)=request to send... because RTS was initially made to > > set the "bus direction" in the attached modem. > > So the three modes are really 2. > (--->8---) > > The only case above that is actually RS232 is (B), the rest are just > asynchronous serial communications. (C) has actually been standardized in TIA-232-E (formerly RS-232-E). See http://en.wikipedia.org/wiki/RS-232 > Saying that (A) and (B) are the same negates the timing requirements > that (A) may have that are unimportant in (B). > > In some situations you can get case (A) from a type (B) implementation > by tying RTS and CTS together, but for other UARTS, this just doesn't > work. You can end up losing characters that are in the tx shift > register and end of FIFO, or in the other timing extreme, losing the > response from a RS485 slave unit. > > I would say that it's important to make the RS485 RTS direction control > mode distinct from the RTS/CTS RS232 hand shaking mode. I would foresee > that it may be necessary to allow setup of different timing modes, to > allow for example chewing up CPU resources for the sake of fast > direction turn around when using ill conceived UARTS. (Maybe an ill > conceived UART is just an ART;) Also if this is to also be useful for > radio communications then it may be necessary to provide a mechanism > where lead in and lead out times can be specified for the control. This is getting more complex than I would have thought, although your point is quite valid :-/ I don't think we should implement any hardware handshake mode in software thought. Drivers should export the capabilities of the hardware. If an UART doesn't support mode (A) it's quite pointless to try to emulate it in the driver. Timing requirements will be violated at some point, users will complain, and developers will point out that the software implementation didn't come with any guarantee. Everybody will be disappointed in the end. Is there any UART that supports lead in/lead out timing configuration in hardware ? > As far as IOCTL names go I dislike the CRTSTOGGLE, toggling the RTS line > is an incorrect description of function. I prefer CARTS as it is not an > incorrect description of function. CARTS - auto request to send is > rather ambiguous though. If I was to suggest a name it would be RTSADC > - request to send auto direction control (maybe with a preceding C if it > went into termios cflags). Let's first decide where it should go, then we'll try to find appropriate names. The number of free bits in c_cflags is quite limited, so I think a new ioctl is probably required with a new data structure to pass additional data such as timing information in addition to the handshaking mode. > From what I can gather through the man pages it seems inappropriate to > add this to termios cflag, though the CRTSCTS flag does set a precedent. > I'm an advocate of the idea of introducing a new IOCTL for setting up > non standard hand-shaking settings. I would suggest that things that > should be considered in the interface are settings for lead-in and > lead-out timing on the direction line (for the use of radio modems for > example) and means to specify if it's appropriate to have the CPU spin > on the shift register empty flag on the last byte of a block, if RTS > timing really is that critical. I don't think we want to introduce software emulation, but feel free to prove me wrong. > I'm rather excited by the idea that a standard interface for RTS > direction control is going to be introduced. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75
Attachment:
signature.asc
Description: This is a digitally signed message part.
