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 use named serial ports on Linux all the time and I didn't have any problem. I think the latest release has the serial plugin fix but I can't confirm because I usually use my own vm (which the vm guys gladly helped me compile :) ). If it's of any help to you, you can download it from here: http://tecnodacta.com.ar/gira/Arduino.10 (linux only).ziphttp://tecnodacta.com.ar/gira/Arduino.10%20(linux%20only).zip and test it.
Best regards Richo
On Wed, Sep 1, 2010 at 4:36 PM, Schwab,Wilhelm K bschwab@anest.ufl.eduwrote:
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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Wednesday, September 01, 2010 3:36 PM To: vm-dev@lists.squeakfoundation.org; squeak-dev@lists.squeakfoundation.org; Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
vm-dev@lists.squeakfoundation.org
-
Ricardo Moran -
Schwab,Wilhelm K