Pyserial - 'device reports readiness to read but returned no data '

[windy54]

I am developing a python script to connect to a jevois camera on the serial interface, still using python2.

Every so often I get the error below

Code: Select all

Traceback (most recent call last):
  File "keyColour.py", line 109, in <module>
    selectBlue()
  File "keyColour.py", line 86, in selectBlue
    send_command('setpar hrange {0}...{1}'.format(95, 110)) 
  File "keyColour.py", line 32, in send_command
    out += ser.read(1)
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 490, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

Here is the function that generated the error, program is based on one from the jevois website,

Code: Select all

# Send a command to JeVois and show response
def send_command(cmd):
    print "HOST>> " + cmd
    ser.write(cmd + '\n')
    out = ''
    time.sleep(0.1)
    while ser.inWaiting() > 0:
        out += ser.read(1)
    if out != '':
        print "JEVOIS>> " + out, # the final comma suppresses extra newline, since JeVois already sends one

I have done some searching on the web and it can be caused by the serial console process if not disabled, I have disabled it. The post recommended using
ps -ef | grep tty to see what was running.

I get the following output,

Code: Select all

ps -ef | grep tty
root       298     1  0 17:02 tty1     00:00:00 /bin/login -f
root       315   297  7 17:02 tty7     00:00:05 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
pi         405   298  1 17:02 tty1     00:00:01 -bash
pi         686   675  0 17:03 pts/0    00:00:00 grep --color=auto tty

My program is using serdev = '/dev/serial0' # serial device of JeVois

As no process is associated with serial0 am I correct in believing that the problem is not due to "multiple access on port" and it is something else?

Has anyone got a suggestion as to what to try next?

thanks

Steve

[MrYsLab]

Some questions?

How do you instantiate the serial port exactly (options of baudrate, etc.)?

What value does

Code: Select all

ser.write(cmd + '\n')

return?

If you increase your sleep value, does that help?

[hippy]

As no process is associated with serial0 am I correct in believing that the problem is not due to "multiple access on port" and it is something else?

Hard to say as I wouldn't have thought a grep on "tty" would necessarily reveal anything using "serial0". And I believe it is also possible that something could be using "serial0" but be referring it using some other name.

[Paul Hutch]

"'device reports readiness to read but returned no data ' serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)"

The part of the error message I made bold tells me this is an error that covers many types of common real world problems with asynch serial communication (e.g. disconnected wires, data corruption due to noise, temporarily non-responsive serial device, intermittent wires, and more).

If you can't track down exactly what is triggering the error, then trapping the error, closing and re-opening the port, and re-initializing the device may keep things running.

[hippy]

The part of the error message I made bold tells me this is an error that covers many types of common real world problems with asynch serial communication (e.g. disconnected wires, data corruption due to noise, temporarily non-responsive serial device, intermittent wires, and more).

Having looked at the serialposix.py module source; it looks to be something like that.

The weird thing is why this would happen with a hard-wired on-chip peripheral ?

That would be more understandable with a USB serial cable which could get disconnected between checking if there's anything to read and then not being able to read it.

I don't think putting any amount of traps around the code is going to solve whatever the underlying issue is, at best would only avoid a program halt when the error occurs.

[bensimmo]

I'm just checking
In raspi-config /raspberry configuration or otherwise
You have enabled the serial port
and disabled the console.

https://www.raspberrypi.org/documentati ... on/uart.md

[windy54]

Thanks for replies, yes I have enabled serial port and disabled console.

I will see what I can do trap the error and restart the script, at the moment it seems to lock up.

Steve

[Paul Hutch]

Having looked at the serialposix.py module source; it looks to be something like that.

The weird thing is why this would happen with a hard-wired on-chip peripheral ?

That would be more understandable with a USB serial cable which could get disconnected between checking if there's anything to read and then not being able to read it.

I don't think putting any amount of traps around the code is going to solve whatever the underlying issue is, at best would only avoid a program halt when the error occurs.

TTL level signals really are an abuse of asynch serial communications. With 3.3V/0V level TTL signals running on wires (TTL is only designed for PCB tracks) it's virtually guaranteed to lead to all sorts of weird errors. When TIA-232 or other properly designed signal levels are used, problems like this are rare. TIA-232, I2C, USB,and many other transmission schemes are designed to avoid the problems that arise from sending out an asynch serial TTL signal on wires.

The last two posts in the following forum thread link show simple traps for a similar error in an application that can just keep running after that error.
viewtopic.php?t=201976#p1256252