Manejo central de errores I2C

Espero recibir más opiniones para complementar la mía.

Espero optimizar mi sistema para usar I2C para manejar todos mis informes de errores.

Mi sistema puede ser entendido por la siguiente foto.ingrese la descripción de la imagen aquí

Mi sistema se compone solo de Arduino UNO y cada uno de ellos tiene sus propios procesos internos, sin embargo, quiero que las advertencias y los errores se informen a un error central que maneja UNO como se muestra en el diagrama adjunto. Los UNO de "Trabajadores" tienen sus propios procesos y continuarán con sus negocios individuales siempre que la "Bandera de todo bien" sea alta (UN GPIO ALTO se lee en el lado de "Trabajadores").

Si Central UNO detecta un error catastrófico, cerraría todo el sistema bajando la "Bandera de todo bien".

Anticipo que las líneas I2C permanecerán decentemente tranquilas. Estoy buscando hacer uso del I2C en el lado de "Trabajadores" para que cada vez que haya un error en uno de los Procesos de "Trabajador", el "Trabajador" envíe el error a la Junta "Central" donde cataloga qué placa envió el error y decide qué hacer con dicho error.

Creo que para lograr esto de la mejor manera, haría que el "Controlador central de errores" sea el Maestro (Oyente) y los "Trabajadores" como Esclavos (remitentes), sin embargo, no estoy seguro de cómo implementar este tipo de sistema. .

Nota: Todos los Uno están a 2 pies de distancia entre sí.

Cualquier orientación es muy apreciada.

Gracias a todos de antemano, Carlos.

Respuestas (2)

Cuando usa UNO, tiene control directo. Con I2C necesitas un maestro y un montón de esclavos (esto ya lo sabes).

Un buen lugar para comenzar es hacer que el maestro solicite periódicamente a los esclavos un informe de error. Si un esclavo envía un error o un esclavo no responde, el maestro apaga el sistema.

Para un sistema aún más robusto (pero mucho más difícil de configurar) es que la conexión es bidireccional. El maestro debe saber de los esclavos sin errores, si no lo hace, apagará el sistema. El problema es que si el maestro falla, el sistema puede salirse de control. Si los esclavos también tienen que escuchar periódicamente al maestro para mantenerse despiertos, entonces hay redundancia. De esta forma, si el maestro falla, los esclavos se apagarán automáticamente. Esto es difícil de configurar porque configurar un enlace y mantenerlo estable puede ser problemático.

Mi sugerencia sería poner el sistema en modo de desactivación. Luego, cuando el enlace esté activo y estable, presione un botón en el maestro para habilitar el sistema.

Un bus I 2 C puro no tiene líneas adicionales de alerta e interrupción. En tal bus, el esclavo I 2 C no puede iniciar transacciones, y el bus maestro I 2 C no puede ser un oyente puro. Sin embargo, el bus maestro puede sondear a los esclavos en busca del indicador de error. Además, parece que está planeando tener una línea de alerta fuera del I 2 C. (Hilos algo relacionados: este y este ).

Si bien es posible que pueda hacer que el I 2 C funcione con conexiones de 2 pies, un autobús con múltiples conexiones de 2 pies puede terminar siendo demasiado grande para el I 2 C simple, y tendrá dificultades para que funcione de manera confiable. . Un tipo de sistema de control distribuido que está describiendo a menudo se realiza con CAN. Fue diseñado para funcionar a través de cables largos y es peer-to-peer, por lo que cualquier nodo puede iniciar transacciones. (Al mismo tiempo, no estoy seguro de si desea abrir el CAN de gusanos, porque CAN es más complejo que I 2 C. Por otra parte, si no investiga CAN, podría terminar como este tipo con un autobús I 2 C demasiado grande .)

Manejo central de errores I2C
RespuestasAquíPolítica de privacidad1y, 0v