'IOError: [Errno 5] Errore input/output' durante l'utilizzo di SMBus per lettura analogica tramite RPi

Question

Ho cercato la risposta per l'errore menzionato nel titolo ma per la prima volta ho ancora una risposta. Stiamo cercando di far leggere al mio Raspberry i dati analogici, ma quando eseguo il codice nella finestra del terminale mi dà 'IOError: [Errno 5] Input/output error'.

Il codice im che utilizza per leggere i dati analogici è mostrato di seguito. Sto usando il convertitore ADC PCF8591.

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 

Capisco che potrebbe essere a causa della versione modificata in Raspberry Pi e dovrei cambiare SMBus (0) per SMBus (1). Per questo ho controllato la mia versione RPi che non è quella revisionata. Ma ancora ho provato a eseguire il programma cambiando il numero SMBus, ancora senza fortuna con esso.

L'errore che ottengo è il seguente:

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

Ogni aiuto è apprezzato. Questo è il blocco di base nel mio progetto più grande che sto cercando di eseguire. Quindi, la cosa migliore è che la cosa funzioni meglio posso costruire la mia applicazione. Grazie

Answer 1

Questi errori potrebbe essere fuori del controllo del programmatore, causata da una a caso, ma al solito, eventi.

Un approccio potrebbe essere quello di provare un paio di volte prima di seguire con l'errore:

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

La causa di questo potrebbe essere che si sta spingendo le read/write chiamate più velocemente di quanto l'hardware li può accettare. Quindi aggiungere piccole ritardi tra le operazioni di lettura/scrittura:

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. 

Un'altra possibilità è che il dispositivo non è in realtà presente in questo indirizzo. Quindi, se i timeout non aiutano, prova i2c-tools (dovrebbe essere disponibile tramite la gestione dei pacchetti, a meno che tu non stia utilizzando una distribuzione software personalizzata) per verificare se il dispositivo è effettivamente disponibile (a volte potrebbe essere un problema di cablaggio come dimenticato GND):

i2cdetect -y [bus number] 

Perché i2c? Perché SMBus è fondamentalmente una modifica del bus i2c con livelli di tensione e tempi più definiti.

Answer 3

Ho avuto lo stesso problema in una comunicazione RasPi -> ATMEGA e lo risolvo sullo slave. Questo messaggio di errore si verifica se lo slave non risponde.

Ho provato il seguente codice Raspi, con uno slave I2C collegato sul bus I2C e configurato con l'indirizzo 0x8:

da smbus importazione SMBus

I2C_Bus = SMBus (1)

SLAVE_ADD = 0x8

I2C_Bus.write_byte (SLAVE_ADD, 0xAA)

Fornendo lo slave I2C è ben configurato per acknowled ge, dovrebbe funzionare!

Answer 4

La causa potrebbe essere che si sta lavorando in remoto (SSH). Dopo aver disconnesso la sessione remota, il programma è ancora funzionante e potrebbe provare a stampare o interagire con la console, che non è più disponibile. Questo è quello che mi è successo.

Answer 5

Mentre questo thread è vecchio, voglio condividere la mia speranza speranzosa che qualcun altro possa essere aiutato visto che tutti i post che ho trovato non menzionano questa potenziale soluzione.

Si è verificato un problema simile, ma con hardware diverso (MCP23017 e un LCD).

Dopo aver inseguito il problema per un po 'di tempo, ho scoperto che il problema non era il software, ma piuttosto l'hardware. Specificamente i resistori di pull up sulle linee SCL e SDA.

L'RPI (3 nel mio caso) ha resistenze 1,8k e il mio LCD ha anche installato alcuni resistori di pull up (~ 2.2k). L'esecuzione dello schermo LCD non ha mai avuto un problema, ma l'MCP23017 scomparirebbe in modo casuale dal bus e riapparirebbe durante l'esecuzione di una scansione inviando il comando "i2cdetect -y 1".

La rimozione delle resistenze di pull up aggiuntive sul display LCD ha risolto il problema e tutto funziona perfettamente ora.

Answer 6

Ho riscontrato questo problema durante la guida di un 7-segment serial display su I2C con un modello b + rpi. Ho corretto il problema regolando la velocità di trasmissione in modo che corrispondesse all'impostazione del dispositivo (9600). Credo che il valore predefinito è 100000.

Per cambiare la velocità di trasmissione, ho aggiunto la seguente riga alla /etc/modprobe.d/i2c.conf:

options i2c_bcm2708 baudrate=9600 

Dopo il riavvio, ho verificato l'impostazione aveva preso effetto con:

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

da allora, ho avuto problemi con errori di I/O intermittenti.

Answer 7

So che questo argomento è piuttosto vecchio ma lo stesso errore si è verificato con I2C e PCA9685 quando ho inserito valori che non erano nel raggio d'azione. Il modo in cui ho pensato che fuori era semplicemente disattivazione e attivazione I2C:

1. sudo raspi-config
2. '5. Interfacciamento opzioni
3. 'P5 I2C'
4. 'Non ci sono'
5. 'OK'
6. sudo reboot now
7. sudo raspi-config
8. '5. Interfacciamento opzioni
9. 'P5 I2C'
10. 'Sì'
11. 'OK'
12. sudo reboot now

Dopo di che, sudo i2cdetect -y 1 rileva il mio modulo I2C PWM di nuovo.