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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 |
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |