> -----Original Message----- > From: Christopher Gibson > > 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. > > 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. > > Saying that (A) and (B) are the same negates the timing requirements > that (A) may have that are unimportant in (B). In an ideal world I do believe that the standard defined the CTS signal to provide this timing info (from modems). So, CTS should always be used as a output flow control. But in the real world I agree that usually the RS485 does not provide such signaling. > > 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. > > As far as IOCTL names go I dislike the CRTSTOGGLE, toggling > the RTS line > is an incorrect description of function. It is incorrect only if you introduce the timings. Please note that Windows has RTS_TOGGLE, no extra timings, and nobody seems to complain. Wait wait... I am not saying that you are wrong. Last year I had to write a (non unix) driver to handle these kinks of timings. But the case is not usual. > 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). > > >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. There would be 2 implementations of this ioctl. One for the zero-timing case which can be handled by some chips (Ox16C950), and one for the some-timing or old-uart case. > > I'm rather excited by the idea that a standard interface for RTS > direction control is going to be introduced. > > -- > Christopher Gibson <chris@xxxxxxxxxxxxxxxx> > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-serial" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
