2009-12-31 14 views
5

Para un proyecto en el que estoy trabajando tengo que hablar con un chip multifunción a través de I2C. Puedo hacer esto desde el espacio de usuario de Linux a través de la interfaz I2C/dev/i2c-1.¿Está forzando la comunicación I2C a ser segura?

Sin embargo, parece que un controlador está hablando con el mismo chip al mismo tiempo. Esto hace que mis accesos I2C_SLAVE fallen con An errno-value de EBUSY. Bueno, puedo anular esto a través del ioctl I2C_SLAVE_FORCE. Lo intenté, y funciona. Mis comandos alcanzan el chip.

Pregunta: ¿Es seguro hacer esto? Sé con seguridad que ningún kernel-driver accede a los rangos de direcciones que escribo. Sin embargo, no estoy seguro de si la comunicación I2C obligando de esa manera puede confundir un estado-máquina interna más o menos. (No estoy que en I2C, sólo lo utilizan ...)

Como referencia, el hardware hechos:

 
OS:   Linux 
Architecture: TI OMAP3 3530 
I2C-Chip:  TWL4030 (does power, audio, usb and lots of other things..) 
+0

¿Intentó hacer esta pregunta en http://chiphacker.com? Es un sitio similar a SO, pero para electrónica (aunque no tan activo como SO). – Wim

Respuesta

6

que no saben que chip en particular, pero a menudo tiene comandos que requieren una secuencia de operaciones de escritura, primero en una dirección para establecer un cierto modo, a continuación, leer o escribir otra dirección - donde la función de la segunda dirección cambia según lo que escribió en la primera. Entonces, si el conductor se encuentra en medio de una de esas operaciones, y usted lo interrumpe (o viceversa), tiene una condición de carrera que será difícil de depurar. Para una solución confiable, es mejor comunicarse a través del controlador del chip ...

+0

¿Cómo lidiamos con este problema si estamos escribiendo un controlador de chip? Según entiendo, estoy usando I2C_SLAVE y I2C_SLAVE_FORCE en el código de mi chip. Entonces, ¿es recomendable usar I2C_SLAVE_FORCE en el código de controlador del chip? –

2

Estoy de acuerdo con @Wim. Pero me gustaría añadir que esto definitivamente puede causar problemas irreversibles, o destrucción, dependiendo del dispositivo.

Conozco un giroscopio (L3GD20) que requiere que no escriba en ciertas ubicaciones. La forma en que se configura el chip, estas ubicaciones contienen configuraciones del fabricante que determinan cómo funciona y funciona el dispositivo.

Esto puede parecer un problema fácil de evitar, pero si piensa en cómo funciona I2C, todos los bytes se pasan de a uno por vez. Si interrumpe en el medio de la transmisión de otro byte, los resultados no solo pueden ser verdaderamente impredecibles, sino que también pueden aumentar exponencialmente el riesgo de daño permanente. Esto, por supuesto, depende totalmente del chip sobre cómo manejar el problema.

Dado que los microcontroladores tienden a funcionar a velocidades mucho más rápidas que las velocidades permitidas en I2C, y dado que las velocidades del mismo son dinámicas en función de la velocidad con la que procesan la información, la mejor opción es insertar pausas o bucles entre transmisiones que esperan que las cosas terminen. Si es necesario, incluso puede insertar un tiempo de espera. Si estas pausas no funcionan, algo está mal con la implementación.

Cuestiones relacionadas