[Vm-dev] RE: Serial ports on Linux

Schwab,Wilhelm K bschwab at anest.ufl.edu
Thu Sep 2 00:05:20 UTC 2010

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.


From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab at anest.ufl.edu]
Sent: Wednesday, September 01, 2010 3:36 PM
To: vm-dev at lists.squeakfoundation.org; squeak-dev at lists.squeakfoundation.org; Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Serial ports on Linux


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.


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,

Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr

More information about the Vm-dev mailing list