Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #79967 > unrolled thread

pySerial works in miniterm but not in my app

Back to article view | Back to comp.lang.python

Contents

  pySerial works in miniterm but not in my app Dario <d.corti@gmail.com> - 2014-10-30 12:42 -0700
    Re: pySerial works in miniterm but not in my app Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-30 18:57 -0400
      Re: pySerial works in miniterm but not in my app Dario <d.corti@gmail.com> - 2014-10-31 01:21 -0700
        Re: pySerial works in miniterm but not in my app Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-31 14:00 -0400
          Re: pySerial works in miniterm but not in my app Dario <d.corti@gmail.com> - 2014-11-01 08:03 -0700
            Re: pySerial works in miniterm but not in my app Dario <d.corti@gmail.com> - 2014-11-01 08:30 -0700
              Re: pySerial works in miniterm but not in my app Dario <d.corti@gmail.com> - 2014-11-01 08:57 -0700

#79967 — pySerial works in miniterm but not in my app

Python 2.7.6 on Mint, pySerial 2.6

I'm trying to write a console app to control a certain device via a usb com port.

In miniterm (-p /dev/ttyUSB0 -e -b 19200), I can communicate correctly with this configuration:

--- Settings: /dev/ttyUSB0  19200,8,N,1
--- RTS: inactive  DTR: inactive  BREAK: inactive
--- CTS: inactive  DSR: inactive  RI: inactive  CD: inactive
--- software flow control: inactive
--- hardware flow control: inactive
--- data escaping: raw  linefeed: CR

sw o01 + <--- I send this
sw o01 + Command OK <--- device does what it should *and* I receive this


Now my code:

----
import serial

s = serial.serial_for_url(
	'/dev/ttyUSB0',
	19200,
	bytesize = 8,
	parity   = 'N',
	stopbits = 1,
	rtscts   = False,
	dsrdtr   = False,
	xonxoff  = False,
	timeout  = 1 # tried without
)
s.close() # tried without
s.open()
s.write('sw o01 +\r')
s.flush() # tried without
s.close() # tried with a sleep before close
----

With this I don't receive anything (tried with readline etc, omitted for readability), and the device doesn't react. Also, if I connect again with miniterm and issue the command, I first receive a "wrong command" message, as if some garbage was actually sent by my app, then it works again.

Isn't my config equivalent to the one in miniterm? Anything missing?

Thanks

[toc] | [next] | [standalone]

#79979

On Thu, 30 Oct 2014 12:42:20 -0700 (PDT), Dario <d.corti@gmail.com>
declaimed the following:

>
>sw o01 + <--- I send this

	How do you "send this"... 

>sw o01 + Command OK <--- device does what it should *and* I receive this

	Is that a new line, or somehow part of the same line?
>s.write('sw o01 +\r')

	What happens if you use \n... or \r\n ?
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#80000

Il giorno giovedì 30 ottobre 2014 23:57:40 UTC+1, Dennis Lee Bieber ha scritto:

> >sw o01 + <--- I send this

> How do you "send this"... 

I just type or paste it in miniterm and hit return. Miniterm sends the return as CR, but it also works with CRLF.

> >sw o01 + Command OK <--- device does what it should *and* I receive this

> Is that a new line, or somehow part of the same line?

This is the response from the device, saying that my command was ok, and it also does what it should (it's an hdmi 4-4 matrix, it switches the first output to the next input).

> >s.write('sw o01 +\r')

> What happens if you use \n... or \r\n ?

In my app, that doesn't make any difference, never works. In miniterm, only CR and CRLF work, LF alone does not.

This evening I'll try with com0com to see what is really sent...

-- 
Dario

[toc] | [prev] | [next] | [standalone]

#80045

On Fri, 31 Oct 2014 01:21:48 -0700 (PDT), Dario <d.corti@gmail.com>
declaimed the following:

>
>This is the response from the device, saying that my command was ok, and it also does what it should (it's an hdmi 4-4 matrix, it switches the first output to the next input).

	Didn't quite answer my question. If the comm line is using remote echo,
it could eat the transmitted line ending and append its response on the
same line. If it is running no echo, your line ending should have moved the
cursor back to the left and possibly down a line -- meaning the device sent
back your command string along with its response as a full line of text.

	Come to that, in the terminal window, after the OK, did it go to a new
line (is the device sending a line ending) or just stopping on that line.

	I don't know how much system buffering takes place, but if it is using
remote echo, you've got 19 characters coming back, where a 16550-class
serial port internally buffers up to 16 -- with no flow control and if the
OS is not buffering via an interrupt handler, you could be losing part of
the response.

	Based on the miniterm source, keyboard echo is turned off -- that means
any characters you see are being returned by the remote device. The default
is to send <CR><LF>. Miniterm runs the serial reader as a separate thread
looping over a serial read of 1 byte, the writer is also a thread doing a
getkey on the console, so it too is doing 1 byte at a time.

	So in effect, your line typed in miniterm is doing the sequence

<reader>						<writer>
wait/read 1 char				wait/read 1 key
								(key rcvd)
								send key to remote
(char rcvd)						wait/read 1 key
display char
wait/read 1 char				(key rcvd)
								send key to remote
(char rcvd)
...



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#80090

Il giorno venerdì 31 ottobre 2014 19:00:26 UTC+1, Dennis Lee Bieber ha scritto:

> Didn't quite answer my question. If the comm line is using remote 

I understand your point, I didn't mention but I also tried sending one char at a time and listening at the same time, nothing changed.

BUT.. plot twist: in Windows XP, the very same python code and usb adapter are working just right (python 2.7 and pySerial 2.7). Also with c#, no issues.

So one could blame the usb adapter or its drivers, but the fact is that minicom (not miniterm) always works, while miniterm only works if used after minicom, and only the first time.

I mean: I start minicom, it works. Close it (quit without reset), start miniterm, it works. Close miniterm, open it again, just garbage...

[toc] | [prev] | [next] | [standalone]

#80091

Il giorno sabato 1 novembre 2014 16:04:06 UTC+1, Dario ha scritto:

> BUT.. plot twist: in Windows XP, the very same python code and usb adapter are working just right (python 2.7 and pySerial 2.7). Also with c#, no issues.

I compared the behaviour of mono and python (2.7 and 3.3) on the same hw and os, I guess something is wrong with pySerial implementation...

Mono code on Mint:

----
SerialPort s = new SerialPort("/dev/ttyUSB0", 19200, Parity.None, 8, StopBits.One);
s.Open();

s.Write("sw o01 +\r");

while (true)
    Console.Write(Convert.ToChar(s.ReadByte()));
----

Device reacts correctly and I get back what I expect (the first line is because I sent the command via com port, the second is because I pushed a button on the device):

dario@ivymint ~ $ sudo ./Test1.exe 
sw o01 + Command OK
Button 1 pushed


Now equivalent Python 3.3 code on Mint:

---
import serial

s = serial.serial_for_url('/dev/ttyUSB0', 19200, bytesize = 8, parity = 'N', stopbits = 1)

s.close()
s.open()
s.write(bytearray('sw o01 +\r','ascii'))

while True:
	print(s.read())
---

In this case, I don't receive anything for my command, and when I press I receive garbage instead of "Button 1 pushed"

dario@ivymint ~ $ sudo python3 ./test2.py 
b'\xfc'
b'\x8f'
b'\r'
b'\x85'
b'1'
b'+'
b'\xfe'

[toc] | [prev] | [next] | [standalone]

#80092

Ehm sorry for the neverending spam, anyway I tried from my raspberry pi and it works there:

root@pi:/home/pi# python3 ./test.py 
b's'
b'w'
b' '
b'o'
b'0'
b'1'
b' '
b'+'
b' '
b'C'
b'o'
b'm'
b'm'
b'a'
b'n'
b'd'
b' '
b'O'
b'K'
b'\r'
b'\n'

Since I need it to work on the rpi and I was using Mint only for easiness, I'm ok with it :)

Thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web