Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: serial port (was Re: metex)

From: holger:rebol at: 13-Apr-2002 6:08

On Sat, Apr 13, 2002 at 02:46:24PM +0200, Piotr Gapinski wrote:
> From: "Adrian" <[a--none--email--it]> > > It worked fine for me with > > mm: open/direct serial://port2/1200/8/none/1 > > are you sure 7 and 2 is correct for your port ? > > > > The problem is that rebol does not support serial dsr-dtr handshake > and thus (at this moment) 'wait function support only changes > on rts and cts pins (data flow handshake).
No. Wait returns if incoming data is available. This has nothing to do with flow control. Flow control is handled transparently by the hardware or operating system, and has no impact on application software. The standard flow control mechanisms are RTS/CTS and Xon/Xoff, both done at the OS level. DTS/DTR is an obsolete, non-standard way of performing flow control, that most operating systems and devices no longer support (except for Macintosh, where it is often used instead of RTS/CTS, for legacy reasons, thus requiring different devices or different cables). With current systems DTS/DTR is only used to indicate whether a device is connected and turned on, not to indicate flow control. That is why most devices these days automatically set DTS/DTR within the driver or OS, without allowing applications to change the state of the line afterwards. If you have an old device (or a Mac device connected to a non-Mac) that requires DTS/DTR flow control then the best solution is to wire a cable in such a way that DTS/DTR gets cross-connected to RTS/CTS, and then use RTS/CTS flow control. Btw, with only 1200 bps, why do you bother with flow control at all ? Pretty much all computers these days have large inbound buffers (16 kB or more), so with 1200 bps there is absolutely no need for inbound flow control. In the outbound direction you may want to use a 10ms delay between characters instead of flow control, especially when only sending little information. From my experience with modems this is actually more reliable for command mode-type devices than flow control, and it also nicely solves the problem of 1 vs 2 stop bits. -- Holger Kruse [kruse--nordicglobal--com]