[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: