Pregunta:
¿Cómo configurar un bus I2C que permanece válido si un esclavo se apaga o falla?
Jolas Marginópolis
2016-12-05 09:04:45 UTC
view on stackexchange narkive permalink

He configurado un bus I2C entre 3 Arduino (Master, Slave1 y Slave2) conectando los 3 pines A4 juntos, los 3 pines A5 juntos y un pin GND de cada Arduino a una línea de tierra común. Los 3 Arduinos están siendo alimentados actualmente por fuentes de alimentación USB independientes, pero tengo la intención de alimentarlos a todos desde una única fuente de alimentación usando sus pines Vin.

Los esclavos usan la biblioteca Wire: Slave1 está en la dirección 0x07 y Slave2 en 0x08. El maestro usa la biblioteca I2C de Wayne Truchsess, porque esta biblioteca tiene funcionalidad de tiempo de espera. El maestro interroga al esclavo1 y 100 ms después, interroga al esclavo2. Si alguno de los esclavos no está disponible, el maestro debería leer el otro esclavo (por eso el maestro no funciona con la biblioteca Wire).

Sin embargo, aunque el maestro no se bloquea, puede No leo un esclavo si el otro se apaga pero se deja conectado. Si corto la alimentación de Slave1, Master no puede leer datos de Slave2 hasta que desconecte físicamente Slave1. Si desconecto Slave1, Master puede volver a leer inmediatamente desde Slave2. El escaneo I2C sugiere que todo el bus se vuelve inválido cuando un esclavo se apaga (¿SCL y / o SDA están bajos?).

Por lo que he estado leyendo, esto no es un problema de software sino un problema de circuitos electrónicos : corriente de fuga relacionada con Slave1 y Slave2 que tienen algunos diodos, algo que tal vez podría resolverse con algunos transistores o N-FET que actuarían como válvulas de retención? Por favor avise.

P.D .: Tengo muy poca experiencia en electrónica y el inglés no es mi primer idioma.

Cuatro respuestas:
Nick Gammon
2016-12-05 12:33:17 UTC
view on stackexchange narkive permalink

Los 3 Arduino actualmente están siendo alimentados por fuentes de alimentación USB independientes, pero tengo la intención de alimentarlos a todos desde una única fuente de alimentación usando sus pines Vin.

Creo su problema aquí es que si apaga un Arduino, en realidad no se apaga, porque obtendrá "energía parasitaria" de la línea I2C, particularmente de las resistencias pull-up que deberían estar allí. Los diodos de protección (internos al procesador) permitirán que la energía fluya desde los pines A4 y A5 al pin Vcc del chip, que luego se encenderá, probablemente en algún tipo de estado indeterminado.

Dado que De todos modos, está planeando alimentarlos con el mismo suministro, su problema simplemente desaparecerá cuando lo haga. No se recomienda conectar un dispositivo con entradas activas a un circuito (es decir, un voltaje presente) cuando el dispositivo en sí no está encendido. Las excepciones serían los dispositivos que están diseñados específicamente para manejar eso, por ejemplo, impresoras producidas comercialmente a través de su entrada USB.

Estoy alimentando a los esclavos para simular fallas. Un esclavo puede fallar incluso si el resto del sistema sigue funcionando.
Ese no es un buen modelo de falla * recuperable *, ya que impone una falla eléctrica irrecuperable. Mantener un esclavo en reinicio, especialmente si puede activarlo a mitad de la transferencia, podría serlo. O coloque las simulaciones de fallas en el firmware de los esclavos.
De hecho, pero dado que los esclavos son módulos de sensores que se pueden restablecer en segundos y medir datos para I + D, pensé que podría tratar todas las fallas como irrecuperables. Si reinicio los sensores, no pierden la calibración, y pensé más tarde que podría agregar relés para el reinicio automático. ¿Es una mala idea?
Mikael Patel
2016-12-05 19:51:40 UTC
view on stackexchange narkive permalink

Por lo que he estado leyendo, esto no es un problema de software sino un problema de circuitos electrónicos: una fuga de corriente relacionada con Slave1 y Slave2 que tienen algunos diodos, algo que quizás podría resolverse con algunos transistores o N-FET que actuaría como válvulas de retención? Por favor avise.

Una buena solución a este problema es utilizar el aislamiento de bus I2C con búferes de bus de 2 cables intercambiables en caliente TI TCA4311A alt. Dispositivos analógicos ADUM1250.

Consulte el Foro de la comunidad electrónica de EEVblog para obtener más detalles y discusión.

¡Salud!

Ese fue el foro donde vi el problema de los "diodos". Traté de dibujar un esquema de cómo entendí que las cosas deberían estar conectadas, pero no sé qué conectar al VCC del chip de intercambio en caliente. A4 y A5 son los pines I2C de arduinos y D6 sería un pin que podría usar para impulsar el intercambio en caliente. ¿Podrías echar un vistazo? http://www.schematics.com/project/test-44785/
Consulte la fig. 11, pág. 13, para el cableado correcto del hot-spot; http://www.ti.com/lit/ds/symlink/tca4311a.pdf
¡Gracias! Que tiene sentido. Dos preguntas más: 1) ¿Qué es BD_SEL? 2) ¿Puede el VCC del backplane ser simplemente una salida regulada de 5V del Master Arduino?
Ah, otra pregunta: en el dibujo, hay una rama llamada "Activar / desactivar tarjeta". Ese es un pin en el arduino esclavo que siempre se establecería en ALTO por el firmware del esclavo para que una falla deshabilitara automáticamente ese esclavo, ¿verdad?
El ADUM1250 podría ser más fácil de entender y usar. Consulte la Nota de aplicación; http://www.analog.com/media/en/technical-documentation/application-notes/AN_913.pdf. Esto es muy sencillo.
st2000
2016-12-05 10:30:43 UTC
view on stackexchange narkive permalink

Un bus I2C debe usar líneas de drenaje abiertas o controladores de colector abierto Y debe haber solo 1 (una) resistencia de extracción para cada uno de los 2 cables I2C. De esta manera, si un esclavo falla, no afectará al bus I2C.

Un Arduino no tiene realmente un pin de colector abierto. En cambio, la gente ha sido inteligente y ha configurado el pin conectado a una línea I2C baja bajando el bus I2C o como una entrada que permite que el bus I2C flote alto a través de la resistencia pull up. De esta manera, múltiples dispositivos I2C (Arduino o no) pueden compartir el bus.

Sin embargo, si apaga un Arduino, ya no podrá operar de esta manera. De hecho, probablemente aparecerá como una carga o una ruta a tierra y afectará el funcionamiento normal del bus I2C.

Al final, I2C está diseñado para chips (generalmente) en la misma placa para que puedan hablar unos con otros. Se deduciría que todos están apagados por el mismo suministro. Es un escenario poco probable que falle la energía para un solo dispositivo en la placa.

Alternativas:

Hay protocolos diseñados para ir entre dispositivos (como en ubicaciones separadas y alimentadas por separado) . RS485 es uno de esos protocolos y existe desde hace años. Una búsqueda rápida muestra tanto sheilds hechos específicamente para Arduinos como también tutoriales que usan interfaces RS485 genéricas.

Gracias por la respuesta. Como dije, carezco de los antecedentes necesarios, por lo que tendré que hacer más preguntas estúpidas: "para manejar un transistor de configuración de colector abierto" -> ¿qué significa eso? Un transistor tiene 3 terminales, ¿verdad? ¿Qué va a dónde? ¿Sería 1 transistor por cada esclavo como intermedio entre el esclavo y qué cable I2C? ¿Algún transistor haría el truco?
Creo que sería difícil diseñar un búfer I2C que no inhibiera el bus si perdiera energía. Traté de describir uno en la respuesta. Pero sin experiencia eléctrica, creo que sería difícil. Además, es un escenario poco probable dado que se espera que los dispositivos I2C estén ubicados en la misma placa. Así que ofrecí RS485 como alternativa en la respuesta.
RS485 es un buen consejo y descubrí que el chip MAX485 se vende en mi país. "transmitir en un pin y recibir en otro" -> así que si solo tengo 2 esclavos y muchos pines sin usar en el maestro, ¿la biblioteca SoftwareSerial sería una solución simple, en lugar de intentar usar I2C? Por ejemplo, ¿usar D7 y D8 como RX y TX para Slave1 y D5 / D6 para Slave2?
** Esta teoría es simplemente incorrecta. ** Parece estar basada en conjeturas que no fueron verificadas pero que fácilmente podrían haberlo hecho, y como resultado, solo confunde a los lectores sin ayudar. Por favor borrar.
Convenido. Estaba agregando texto basado en los comentarios dejados por el O.P. Parece estar feliz. Aunque no votó ni aceptó mi respuesta. Lo editaré a una respuesta normal de intercambio de pila.
No pude votar porque no tenía suficientes puntos. Ha votado a favor ahora
Apreciado. (Con suficientes puntos, puede ver el conteo progresivo / regresivo individual). Es un problema difícil. Pero, de nuevo, I2C suele ser un bus que está en la misma placa que todas las partes. Simplemente no está configurado para (por sí mismo) manejar una parte que se corta la energía.
Christopher Couch
2017-09-28 08:40:50 UTC
view on stackexchange narkive permalink

Mikael tiene la respuesta correcta arriba.

Tuve este mismo problema cuando usé dos Megas comunicándose a través de I2C, junto con otros elementos que se ejecutan en el bus I2C. Necesitaba que el sistema continuara funcionando si uno de los Mega fallaba debido a una pérdida de energía. El otro Mega debería detectarlo y ejecutar algunos comandos de aborto para mi misión.

Inicialmente conecté los Megas al mismo bus I2C, como lo haría con cualquier otro dispositivo. Cuando desconectaba un Mega, el otro se congelaba la próxima vez que intentaba direccionar otro dispositivo en el bus.

La solución fue usar un búfer I2C intercambiable en caliente. Usé este, y todo funcionó inmediatamente sin problemas después de conectarlo: http://www.mouser.com/search/ProductDetail.aspx?r=595-TCA4311ADR

Para integrar el paquete SOIC-8 en una placa DIP estándar para Arduinos, utilicé un adaptador de Adafruit.

Saludos y buena suerte

Chris

Alto Vídeo 360 de Altitude Photography Platform desde una plataforma estabilizada por chorro en el borde del espacio http://hialtphoto.blogspot.com

Facebook @hialtphoto



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...