Serial ports on Linux

I have been able to do serial I/O on Windows, but not Linux.  Running in a terminal to capture output yields "Error while saving old state" while trying to open just about any number or name I can think of (including 0 and /dev/ttyS0), but the open method gives no indication that there is a problem; it returns a perfectly valid looking serial port with the #port set to whatever it was given.

Subsequent reads fail, and are probably a bit more honest about what is happening: "Error while reading: serial port is not open."  I am not sure whether that is always the case, but it certainly is on this machine when I try /dev/ttyUSB0, which does not exist here.

Any ideas?

Bill

On Tue, 31 Aug 2010 23:57:39 -0400, "Schwab,Wilhelm K"
<[hidden email]> wrote:

>I have been able to do serial I/O on Windows, but not Linux.  Running in a terminal to capture output yields "Error while saving old state" while trying to open just about any number or name I can think of (including 0 and /dev/ttyS0), but the open method gives no indication that there is a problem; it returns a perfectly valid looking serial port with the #port set to whatever it was given.
>
>Subsequent reads fail, and are probably a bit more honest about what is happening: "Error while reading: serial port is not open."  I am not sure whether that is always the case, but it certainly is on this machine when I try /dev/ttyUSB0, which does not exist here.

If you're trying to use a USB->Serial port, what I normally do is
create a symbolic link to /dev/ttyUSB0 from /dev/ttyS4, and open the
port as port #4.

ln -s /dev/ttyUSB0 /dev/ttyS4

In terms of errors, though, the new SerialPort >> #openPort: in 4.1 is
really borked - it returns no indication that the open succeeded or
failed.

The old one, in 3.8, was much better.

Later,
Jon

Markus,

If you have some experience with serial I/O on Linux, I would appreciate your giving it a quick shakedown; if it is just plain broken or is still known to work, it would be nice to confirm either way.  I would like to use the binary distribution, but it does not report enough of what it is trying to do (so no clues when things fail) and I end up hacking to add tracing with possible installation troubles as a result.

That said, this time around, I find myself in serialPortOpenByName() and puzzled by the failure being allegedly detected by:

    /* save the old state */
    if (tcgetattr(sp->spDescriptor, &sp->spTermios))

My question: is there old state to save on the first pass?  errno is not helpful; it is set to 5 aka I/O error :(   I find myself wondering whether this should be conditional on the internal state of the descriptor, and the failure to open simply being that it gives up too easily?  Then again, it could be detecting a true error condition and preventing certain disaster in the lines that would follow.

Any ideas?  I can't get /dev/ttyS0 to open by name or number.  'COM1' worked nicely on Windows.

Bill



Markus Lampert markuslampert at yahoo.com
Wed Sep 1 15:28:38 UTC 2010

Hi Bill,

haven't used the serial interface with the new VMs (yet), but previously under
Linux I had to use the vm option '-notimer'. I did not find any negative side
effects with that option.

Hope this helps,
Markus

Hi, 

I *think* I have been able to successfully open '/dev/ttyS0' by name.  I started on my laptop, which does not have a serial port, so I tried the USB-serial box knowing there could be problems.  Then I worked for a while at home, "knowing" that this machine has a serial port (apparently not!).  Having realized the latter trap, I fired up a PC/104 machine that is currently in my care; it has two serial ports, and I can open and read nothing from them.

I still think the Linux vm is too stingy with diagnostic information, but the named ports hopefully indeed work.  It will take a little doing to get a computer with serial ports in the same place as the device with which I need to communicate, and/or to write some code for the PC/104 machine to talk to itself using the two ports and a cable.  The latter is not entirely trivial, mostly because I want to do it using streams.

The state of the USB-serial box is unclear.  The problems might simply be in the way I created the nodes for its ports - more on that after some technical support.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Wednesday, September 01, 2010 3:36 PM
To: [hidden email]; [hidden email]; [hidden email]
Subject: Re: [Pharo-project] Serial ports on Linux

Markus,

If you have some experience with serial I/O on Linux, I would appreciate your giving it a quick shakedown; if it is just plain broken or is still known to work, it would be nice to confirm either way.  I would like to use the binary distribution, but it does not report enough of what it is trying to do (so no clues when things fail) and I end up hacking to add tracing with possible installation troubles as a result.

That said, this time around, I find myself in serialPortOpenByName() and puzzled by the failure being allegedly detected by:

    /* save the old state */
    if (tcgetattr(sp->spDescriptor, &sp->spTermios))

My question: is there old state to save on the first pass?  errno is not helpful; it is set to 5 aka I/O error :(   I find myself wondering whether this should be conditional on the internal state of the descriptor, and the failure to open simply being that it gives up too easily?  Then again, it could be detecting a true error condition and preventing certain disaster in the lines that would follow.

Any ideas?  I can't get /dev/ttyS0 to open by name or number.  'COM1' worked nicely on Windows.

Bill



Markus Lampert markuslampert at yahoo.com
Wed Sep 1 15:28:38 UTC 2010

Hi Bill,

haven't used the serial interface with the new VMs (yet), but previously under
Linux I had to use the vm option '-notimer'. I did not find any negative side
effects with that option.

Hope this helps,
Markus



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi,

I have it happily running on my Powerbook under MacOSX. Do you have a  
Monticello Repository to integrate the changes easily? Then there is  
also the question of the external dependency (pyserial, avr-gcc, avr-
libc, avr-binutils and avrdude) and the startscripts for the  
environment.

Right now the LED is blinking.

Cheers,
Torsten


Am 02.09.2010 um 01:20 schrieb Ricardo Moran: