Re: String Manipulation and a Need for RS-232
>>>>> Martin McCormick <martin@x.it.okstate.edu> writes:
[…]
> I also got that working such that it could read the response and
> break out all the CSV variables in to separate strings. In other
> words, it does work and with gdb, one can trouble-shoot it fairly
> easily.
[…]
> In the standard set of tools that are free and found on most Unix
> systems, which language such as perl, python, etc can handle rS-232
> gracefully and do strings without having to reen vent the wheel?
[…]
> If I can do all of this within one language, including the RS-232
> coms, that will be great.
In Unix-like systems, including GNU/Linux, there isn't really
any difference between using a regular file, pipe, virtual
terminal, or a serial port. Most of the time, one just does it,
and it works.
E. g., if I'd have to read a line from COM1, I could do it
easily in, say, Bash:
$ read x < /dev/ttyS0
$ printf %s\\n "$x"
Hello, world!
$
(Assuming there's some device attached that sends “Hello,
world!” just at the right moment.)
There're a few things that may require explicit attention.
First of all, I'm almost certain that it will be necessary to
set the serial port to a particular mode (like: bit rate,
bitness, parity.) I guess that many languages have support for
it (including a wrapper for the ioctl(2) system call, which, I
guess, you're familiar with.)
However, it's not /necessary/ to set the serial port's mode in
your own program. Instead, you may set it with stty(1), once,
and then just run the program. It's almost exactly what happens
if you'll use a “classic” serial terminal, or a modem and a
machine running a terminal emulator.
Second, the device may be using a newline sequence different to
that of the system, and it may be a bit tricky to set up the
language chosen to interpret it properly.
Also, it will really be nice to implement serial device locking
(I'm familiar with the UUCP locking scheme, but I vaguely recall
that it was to be deprecated; hopefully no misunderstanding on
my part.) That way, only one of the programs trying to
simultaneously use the port will succeed, while the others will
fail with a nice error message.
That being said, my personal preference for that kind of task
would be Perl. I guess that the points above could be resolved
by searching the CPAN archives [1].
[1] http://search.cpan.org/
PS. I'm still interested in serial ports, partly due to having a live
UUCP link, and partly due to having some interest in embedded
systems' development, so I guess I'd be able to answer a few
more questions on them in this list (though it's a bit OT.)
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)
Reply to: