serial module

[Ron Eggler]

Hoi,

I'm trying to connect to a serial port and always get the error
"serial.serialutil.SerialException: Port is already open." whcih is untrue.
I have no serial port open yet, my code looks like this:
#!/usr/bin/python
import time
import serial

# configure the serial connections (the parameters differs on the device
# you are connecting to)
ser = serial.Serial(
port='/dev/ttyUSB0',
baudrate=19200,
parity=serial.PARITY_ODD,
stopbits=serial.STOPBITS_TWO,
bytesize=serial.SEVENBITS
)

ser.open()

Why do I get this error?

Thank you,
Ron

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[Paul Simon]

Sounds like you may be using this on a Windows machine. <If> the code is
functional, it is best practice to close the port first before openiing it.
If due to an error, usually not syntax, the port will stay stuck open until
the program is closed and reopened. I have used the Python serial port
(serial.py?) with good results.

Paul Simon

"Ron Eggler" <ronDOT...@tscheemail.com> wrote in message
news:jp6gcj$1rij$1...@adenine.netfront.net...

[Albert van der Horst]

In article <jp6gcj$1rij$1...@adenine.netfront.net>,

Ron Eggler <ronDOT...@tscheemail.com> wrote:
>Hoi,
>
>I'm trying to connect to a serial port and always get the error
>"serial.serialutil.SerialException: Port is already open." whcih is untrue.
>I have no serial port open yet, my code looks like this:
>#!/usr/bin/python
>import time
>import serial
>
># configure the serial connections (the parameters differs on the device
># you are connecting to)
>ser = serial.Serial(
> port='/dev/ttyUSB0',
> baudrate=19200,
> parity=serial.PARITY_ODD,
> stopbits=serial.STOPBITS_TWO,
> bytesize=serial.SEVENBITS
>)
>
>ser.open()
>
>Why do I get this error?

You realize that these parameters relate to RS232 ports?
It is anybody's guess what they do in USB. The best answers is probably
that it depends on the whim of whoever implements the usb device.

Certainly this stuff is system dependant, so please start with stating
which version kernel etc. of Linux you run, and the output of
lsusb --verbose.

>
>Thank you,
>Ron

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Grant Edwards]

On 2012-05-22, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:

>># configure the serial connections (the parameters differs on the device
>># you are connecting to)
>>ser = serial.Serial(
>> port='/dev/ttyUSB0',
>> baudrate=19200,
>> parity=serial.PARITY_ODD,
>> stopbits=serial.STOPBITS_TWO,
>> bytesize=serial.SEVENBITS
>>)
>>
>>ser.open()
>>
>>Why do I get this error?
>
> You realize that these parameters relate to RS232 ports?

/dev/ttyUSB0 is a serial port. In all likelyhood an RS-232 port, but
it could be RS-485 or RS-422 or some other physical layer. In anycase
it works just like a "normal" serial port such as /dev/ttyS0.

> It is anybody's guess what they do in USB.

They do exactly what they're supposed to regardless of what sort of
bus is used to connect the CPU and the UART (ISA, PCI, PCI-express,
USB, Ethernet, etc.).

> The best answers is probably that it depends on the whim of whoever
> implements the usb device.

It does not depend on anybody's whim. The meaning of those parameters
is well-defined.

> Certainly this stuff is system dependant,

No, it isn't.

> so please start with stating which version kernel etc. of Linux you
> run, and the output of lsusb --verbose.

There's very probably no need for that.

The drivers for the various USB-attached serial ports all work pretty
much exactly like the normal ISA/PCI-attached drivers. The main
things you'll notice are differences in buffer/fifo sizes and the
timing of things like commands to set/clear modem control lines.

--
Grant Edwards grant.b.edwards Yow! I didn't order any
at WOO-WOO ... Maybe a YUBBA
gmail.com ... But no WOO-WOO!

[Grant Edwards]

On 2012-05-18, Ron Eggler <ronDOT...@tscheemail.com> wrote:

> I'm trying to connect to a serial port and always get the error

> "serial.serialutil.SerialException: Port is already open." which is
> untrue.

It is true.

> I have no serial port open yet, my code looks like this:
> #!/usr/bin/python
> import time
> import serial
>
> # configure the serial connections (the parameters differs on the device
> # you are connecting to)
> ser = serial.Serial(
> port='/dev/ttyUSB0',
> baudrate=19200,
> parity=serial.PARITY_ODD,
> stopbits=serial.STOPBITS_TWO,
> bytesize=serial.SEVENBITS
> )

The call above opened the port.

Please see the pySerial documentation:

http://pyserial.sourceforge.net/shortintro.html#opening-serial-ports

Particularly the first example:

Open port 0 at "9600,8,N,1" no timeout:

>>> import serial
>>> ser = serial.Serial(0) # open first serial port
>>> print ser.portstr # check which port was really used
>>> ser.write("hello") # write a string
>>> ser.close() # close port


And here to try to open and already-opened port:

> ser.open()
>
> Why do I get this error?

Becaue the port is already opened. :)

--
Grant Edwards grant.b.edwards Yow! Sign my PETITION.
at
gmail.com

[Grant Edwards]

On 2012-05-19, Paul Simon <psi...@sonic.net> wrote:
> "Ron Eggler" <ronDOT...@tscheemail.com> wrote:

>> [...] my code looks like this:

>> #!/usr/bin/python
[...]
>> port='/dev/ttyUSB0',

> Sounds like you may be using this on a Windows machine.

I don't think so. :)

--
Grant Edwards grant.b.edwards Yow! Hello? Enema Bondage?
at I'm calling because I want
gmail.com to be happy, I guess ...

[Ron Eggler]

Grant Edwards wrote:

> On 2012-05-19, Paul Simon <psi...@sonic.net> wrote:
>> "Ron Eggler" <ronDOT...@tscheemail.com> wrote:
>
>>> [...] my code looks like this:
>
>>> #!/usr/bin/python
> [...]
>>> port='/dev/ttyUSB0',
>
>> Sounds like you may be using this on a Windows machine.
>
> I don't think so. :)

Nope it's Linmux but nevermind. I'm writing a C app instead. That's more in
my line of fire too... :)

Thanks,

[John Nagle]

On 5/22/2012 8:42 AM, Grant Edwards wrote:
> On 2012-05-22, Albert van der Horst<alb...@spenarnc.xs4all.nl> wrote:

>> It is anybody's guess what they do in USB.
>
> They do exactly what they're supposed to regardless of what sort of
> bus is used to connect the CPU and the UART (ISA, PCI, PCI-express,
> USB, Ethernet, etc.).

If a device is registered as /dev/ttyUSBnn, one would hope that
the Linux USB insertion event handler, which assigns that name,
determined that the device was a serial port emulator. Unfortunately,
the USB standard device classes
(http://www.usb.org/developers/defined_class) don't have "serial port
emulator" as a standardized device. So there's more variation in this
area than in keyboards, mice, or storage devices.

>
>> The best answers is probably that it depends on the whim of whoever
>> implements the usb device.
>
> It does not depend on anybody's whim. The meaning of those parameters
> is well-defined.
>
>> Certainly this stuff is system dependant,
>
> No, it isn't.

It is, a little. There's a problem with the way Linux does
serial ports. The only speeds allowed are the ones nailed into the
kernel as named constants. This is a holdover from UNIX, which is a
holdover from DEC PDP-11 serial hardware circa mid 1970s, which had
14 standard baud rates encoded in 4 bits. Really.

In the Windows world, the actual baud rate is passed to the
driver. Serial ports on the original IBM PC were loaded with
a clock rate, so DOS worked that way.

This only matters if you need non-standard baud rates. I've
had to deal with that twice, for a SICK LMS LIDAR, (1,000,000 baud)
and 1930s Teletype machines (45.45 baud).

If you need non-standard speeds, see this:

http://www.aetherltd.com/connectingusb.html

If 19,200 baud is enough for you, don't worry about it.

John Nagle

[Paul Rubin]

John Nagle <na...@animats.com> writes:
> If a device is registered as /dev/ttyUSBnn, one would hope that
> the Linux USB insertion event handler, which assigns that name,
> determined that the device was a serial port emulator. Unfortunately,
> the USB standard device classes
> (http://www.usb.org/developers/defined_class) don't have "serial port
> emulator" as a standardized device. So there's more variation in this
> area than in keyboards, mice, or storage devices.

Hmm, I've been using USB-to-serial adapters and so far they've worked
just fine. I plug the USB end of adapter into a Ubuntu box, see
/dev/ttyUSB* appear, plug the serial end into the external serial
device, and just use pyserial like with an actual serial port. I didn't
realize there were issues with this.

[John Nagle]

There are. See "http://wiki.debian.org/usbserial". Because there's
no standard USB class for such devices, the specific vendor ID/product
ID pair has to be known to the OS. In Linux, there's a file of these,
but not all USB to serial adapters are in it. In Windows, there
tends to be a vendor-provided driver for each brand of USB to
serial converter. This all would have been much simpler if the USB
Consortium had defined a USB class for these devices, as they did
for keyboards, mice, etc.

However, this is not the original poster's problem.

John Nagle

[Grant Edwards]

On 2012-05-22, John Nagle <na...@animats.com> wrote:
> On 5/22/2012 8:42 AM, Grant Edwards wrote:
>> On 2012-05-22, Albert van der Horst<alb...@spenarnc.xs4all.nl> wrote:
>
>>> It is anybody's guess what they do in USB.
>>
>> They do exactly what they're supposed to regardless of what sort of
>> bus is used to connect the CPU and the UART (ISA, PCI, PCI-express,
>> USB, Ethernet, etc.).
>
> If a device is registered as /dev/ttyUSBnn, one would hope that the
> Linux USB insertion event handler, which assigns that name,
> determined that the device was a serial port emulator.

The fact that it shows up as /dev/tty<something> means that the driver
registered the port as a tty (serial) device.

> Unfortunately, the USB standard device classes
> (http://www.usb.org/developers/defined_class) don't have "serial port
> emulator" as a standardized device. So there's more variation in
> this area than in keyboards, mice, or storage devices.

I've used a log of USB connected serial devices, and they all worked
fine. Some show up as /dev/ttyUSBn and some as /dev/ttyACMn, but the
standard tty APIs all worked fine. What sorts of vartiations have you
seen?

>>> The best answers is probably that it depends on the whim of whoever
>>> implements the usb device.
>>
>> It does not depend on anybody's whim. The meaning of those
>> parameters is well-defined.
>>
>>> Certainly this stuff is system dependant,
>>
>> No, it isn't.
>
> It is, a little. There's a problem with the way Linux does serial
> ports. The only speeds allowed are the ones nailed into the kernel
> as named constants.

That hasn't been true for years. The termios2 structure allows
arbitrary baud rates. I don't know if all low-level serial drivers
support that API, but I believe all the in-kernel ones do (and I know
the out-of-kernel one's I maintain do).

The UART hardware may have limits in the buad-clock divider chains
that limit the number of baud rates that can be generated, but that's
a different problem.

> In the Windows world, the actual baud rate is passed to the driver.

That's also how it works with a modern Linux serial driver. You
use "struct termios2" instead of "struct termios" TCGETS2 et al
instead of TCGETS et al.

Here's source code for a command-line utility to set a Linux serial
port to an arbitrary baud rate:

http://www.panix.com/~grante/files/arbitrary-baud.c

That said, the POSIX APIs in the libc implementations I know about
(glibc, uClibc) unfortunately haven't caught up yet. :)

> Serial ports on the original IBM PC were loaded with a clock rate, so
> DOS worked that way.
>
> This only matters if you need non-standard baud rates. I've had to
> deal with that twice, for a SICK LMS LIDAR, (1,000,000 baud) and
> 1930s Teletype machines (45.45 baud).

We run our Sick LMS units at 500,000 baud, and bog-standard Linux
kernels support that just fine.

--
Grant Edwards grant.b.edwards Yow! I'm having a BIG BANG
at THEORY!!
gmail.com

[Grant Edwards]

I've used probably a dozen different ones. I've read about some
people having odd problems with them, but I've never seen any of the
those problems. They've all "just worked" for me.

--
Grant Edwards grant.b.edwards Yow! He is the MELBA-BEING
at ... the ANGEL CAKE
gmail.com ... XEROX him ... XEROX
him --