'IOError: [Errno 5] Input/output error' while using SMBus for analog reading through RPi

Question

I have been looking for the answer for the error mentioned in the title but for the first time i haavent got an answer yet. We ll im trying to make my Raspberry pi read analog data but when i run the code in terminal window it gives me 'IOError: [Errno 5] Input/output error'.

The code im using to read analog data is shown below. Im using PCF8591 ADC converter.

from smbus import SMBus

bus = SMBus(0)

print "read a/d press ctrl + c to stop"

bus.write_byte(0x48, 0)
lastval = -1

while True:
  reada = bus.read_byte(0x48)
  if(abs(lastval-reada) > 2):
    print(reada)
    lastval=reada

I understand it might be because of the version changed in raspberry pi and i should change SMBus(0) to SMBus(1). For this i checked my RPi version which is not the revised one. But still I tried to run the program by changing the SMBus number, still no luck with it.

The error I get is shown below:

Traceback (most recent call last):
  File "analogread.py", line 7, in <module>
    bus.write_byte(0x48, 0)
IOError: [Errno 5] Input/output error

Any help is appreciated. This is the basic block in my bigger project which im trying to execute. So, the fas thinster i get thing working the better i can build my application. Thank you

Answer 1

These errors might be beyond programmer's control, caused by a random, yet usual, event.

One approach would be to try a couple of times before following with the error:

def try_io(call, tries=10):
    assert tries > 0
    error = None
    result = None

    while tries:
        try:
            result = call()
        except IOError as e:
            error = e
            tries -= 1
        else:
            break

    if not tries:
        raise error

    return result

try_io(lambda: bus.write_byte(0x48, 0))

Answer 2

The cause to this might be that you're pushing out the read/write calls faster than your hardware can accept them. So add small delays between read/write operations:

from time import sleep
from smbus import SMBus

bus = SMBus(0)

bus.write_byte(0x48, 0)
sleep(0.2)  # Wait for device to actually settle down
lastval = -1

while True:
  reada = bus.read_byte(0x48)
  if(abs(lastval-reada) > 2):
    print(reada)
    lastval=reada
  sleep(0.2) # This might be not needed.

Another possibility is that device is not actually present in this address. So if the timeouts don't help, try out i2c-tools (should be available via package management, unless you're using a custom software distribution) to check whether the device is actually available (sometimes it could be a wiring issue like forgotten GND):

i2cdetect -y [bus number]

Why i2c? Because SMBus is basically a modification of i2c bus with more strictly defined voltage levels and timings.

Answer 3

The cause to this might be that you're working remotely (SSH). After you disconnect the remote session, your program is still working and could try to print or interact to console, which is not available any more. This is what happened to me.

Answer 4

I experienced this problem when driving a 7-segment serial display over I2C with a model b+ rpi. I corrected the problem by adjusting the baud rate to match the device setting (9600). I believe the default is 100000.

To change the baud rate, I added the following line to /etc/modprobe.d/i2c.conf:

options i2c_bcm2708 baudrate=9600

After reboot, I verified the setting had taken effect with:

prompt$ sudo cat /sys/module/i2c_bcm2708/parameters/baudrate
9600

Since then, I've had no problems with intermittent I/O errors.

Answer 5

I had a similar problem in reading large volume csv file remotely (from the server) where I was connecting to workstation remotely and I was trying to read large size csv file from the Server. I copied the files to workstation that consequently 'IOError: [Errno 5] Input/output error' was resolved. I had a MemoryError after it that I resolved it by chunk reading and then converting to dataframe by pd.concat.

The code is as follows:

chunk=pd.read_csv(CSV_File_Loc,chunksize=1000000,low_memory=False)

DF_CSV=pd.concat(chunk)

Answer 6

I had the same problem in a RasPi -> ATMEGA communication and I resolve it on the slave. This error message occurs if your slave doesn't respond.

I tried the following code on RasPi, with an I2C slave connected on the I2C bus and configured with the 0x8 address :

from smbus import SMBus

I2C_Bus = SMBus(1)

SLAVE_ADD = 0x8

I2C_Bus.write_byte(SLAVE_ADD, 0xAA)

Providing the I2C slave is well configured to acknowledge, it should work!

Answer 7

In my case there was print statement that was causing this issue, I just removed that print statement and now that issue has been resolved for me.

Answer 8

The issue is old, but according to me very actual!

The solution(for RPi 3B+) is to set ALT0 mode for the GPIO at pin 3 & 5 (physical). This can be done with the gpio command line tool:

gpio mode 8 alt0
gpio mode 9 alt0

8 and 9 as these are the numberings used by wiringpi for physical pin 3 & 5. And this is exactly the issue... it uses wiringpi.
http://wiringpi.com/wiringpi-deprecated/

In my python code I could create a system call to those 2 commands (for me it works!)

However I would like a solution which does not use deprecated libs or tools.

Anyone?

Answer 9

While this thread is old, I want to share my resuly hoping someone else might be helped as all posts I came across did not mention this potential fix.

I was encountering a similar issue, but with different hardware (MCP23017 and an LCD).

After chasing the problem for some time, I found the problem was not software, but rather hardware. Specifically the pull up resistors on the SCL and SDA lines.

The RPI (3 in my case) has 1.8k resistors and my LCD had some pull up resistors installed as well (~2.2k). Running the LCD never had a problem, but the MCP23017 would randomly disappear from the bus and reappear when running a scan by issuing command "i2cdetect -y 1".

Removing the extra pull up resistors on the LCD fixed the problem and all works perfectly now.

Answer 10

I know this topic is quite old but the same error occured with I2C and PCA9685 when I put values that were not in range. The way I figured it out was just simply disabling and enabling I2C:

1. sudo raspi-config
2. '5. Interfacing options'
3. 'P5 I2C'
4. 'No'
5. 'OK'
6. sudo reboot now
7. sudo raspi-config
8. '5. Interfacing options'
9. 'P5 I2C'
10. 'Yes'
11. 'OK'
12. sudo reboot now

After that, sudo i2cdetect -y 1 detects my I2C PWM module back again.