Re: serial ports: how do I know data has been sent?

"Simon Elliott" <Simon at ctsn.co.uk> writes:
> A couple of examples from real life, where luckily I was using DOS and
> could therefore do whatever I wanted with the serial ports:
>
> 1/ Controlling a network of pressure transducers which used RS485, from
> a PC serial port via a RS232-485 converter which IIRC used RTS to grab
> the bus. It was fairly important to drop RTS _after_ the last character
> had been sent, but not too long after.

That's a line discipline. Having an RTS envelope on the data (and
presumably listening to CTS in response to RTS) is a well-known
standard RS-232 behavior. It's _not_ the default way that modems are
typically used -- which is more of an industry standard than an actual
standard -- but it's defined by the written standards themselves.

It should be selectable and, in my opinion, implemented as a part of
the system itself. In other words, likely in the kernel, and
certainly not part of an application program. It's an architectural
issue.

> 2/ Controlling a data collection device which continously transmitted
> garbage till it had been sent a "wake up" command.

I think the best you can do is send the special command, drain, then
flush pending input. Even then, it's possible that you could get
confused by timing elements that don't work out well.

Assuming that the "good" data has some pattern to it, you might be
able to repeat that command (or some "no-op" type command) until
you're in sync. That should cover most of the important cases of
confusion. If it has no usable pattern, then I think you may be sunk.

A separate but related issue here is what to do if the data you
receive some time *after* that "wake up" sequence are garbled.
Hardware isn't perfect, and errors do happen. You need a scheme that
will allow you to detect this problem and recover from it. I suspect
it's likely that this scheme, if it's robust at all, would cover for
the start-up confusion problem as well.

(This sounds a bit like a typical mouse or keyboard. They can be hard
to deal with at times.)

--
James Carlson, KISS Network <james.d.carlson@xxxxxxx>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
.

Relevant Pages

  • Re: Typography
    ... Sounds more to me as if there wasn't a straightforward LaTeX ... which editor to use. ... There never would have been one standard - obviously. ... old command line stuff had had its day. ...
    (uk.comp.sys.mac)
  • Re: Is Python really a scripting language?
    ... It's easy to run other programs, and easy to send command line ... """ errors to standard error, output to standard out, objects ... error_stuff is the string returned from standard error. ... circumstance where privilege escalation techniques are ...
    (comp.lang.python)
  • Re: Running Standalone Lisp Programs
    ... >>A standard should provide a universal API for aspects common ... >>command line arguments were rare among systems. ... > People have already explained the reason; apparently you just don't get it. ... logic as "operating systems exist which have no support for the command ...
    (comp.lang.lisp)
  • Re: Hiding process arguments from ps -ef
    ... > temporary file that X will read and erase) but if there is a standard way ... I don't know whether or not there is a Solaris specific ... command line someone may run psand view the original command line. ... redesign the information passing mechanism so that sensitive information ...
    (comp.unix.programmer)
  • Re: command line arguments best practices
    ... > I am familiar with how to create a string, set it equal to Command$, and ... > Once the delimiter is determined, what is the best way to parse Command$? ... This standard is characterized by allowing single and multiple character ...
    (microsoft.public.vb.general.discussion)