I2C Central Error Handling

Navega tus respuestas
1

Espero obtener más opiniones para complementar mi propia opinión.

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

Mi sistema puede ser entendido por la siguiente foto.

MisistemaestácompuestosoloporArduinoUNOycadaunodeellostienesuspropiosprocesosinternos,sinembargo,quieroquesenotifiquenadvertenciasyerroresaunerrorcentralquemanejaUNOcomomuestraeldiagramaadjunto.Los"trabajadores" de la ONU tienen sus propios procesos y continuarán con sus negocios individuales siempre que la "All Good Flag" sea Alta (un ALTO GPIO leído en el lado de los "Trabajadores").

Si la UNO Central detecta un error catastrófico, apagará todo el sistema tirando de "All Good Flag" Low.

Estoy anticipando que las líneas I2C se mantendrán decentemente silenciosas. 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é tabla envió el error y decide qué hacer con dicho error.

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

Nota: Todos los Uno están a 2 pies uno del otro.

Cualquier orientación es muy apreciada.

Gracias a todos por adelantado, Carlo

    
pregunta Carlo

2 respuestas

1

Al usar UNOs tienes la capacidad de control directo. Con I2C necesitas un maestro y un grupo de esclavos (ya lo sabes).

Un buen lugar para comenzar es hacer que el maestro pregunte periódicamente a los esclavos por un informe de error. Si un esclavo envía un error o si 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 escuchar a 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 quedarse despierto, entonces hay redundancia. De esta manera, si el maestro falla, los esclavos se apagarán automáticamente. Esto es difícil de configurar porque configurar el enlace y mantenerlo estable puede ser problemático.

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

    
respondido por el vini_i
1

Un puro I 2 El bus C no tiene líneas adicionales de alerta e interrupción. En dicho bus, el esclavo I 2 C no puede iniciar transacciones y el maestro del bus I 2 no puede ser un oyente puro. Sin embargo, el maestro del bus puede encuestar a los esclavos para el indicador de error. Además, parece que estás planeando tener una línea de alerta fuera de I 2 C.
(Algunos temas relacionados: this y esto .)

Si bien puede hacer que el I 2 C funcione con conexiones de 2 pies, un bus con varias conexiones de 2 pies puede llegar a ser demasiado grande para el I 2 C, y te será difícil hacer que funcione de manera confiable. Un tipo de sistema de control distribuido que usted describe se hace a menudo con CAN. Fue diseñado para funcionar a través de cables largos y es de igual a igual, por lo que cualquier nodo puede iniciar transacciones. (Al mismo tiempo, no estoy seguro de si desea abrir la CAN de gusanos, porque la CAN es más compleja que I 2 C. Por otra parte, si no observa la CAN, puede terminar como este tipo con un overgrown I 2 C bus .)

    
respondido por el Nick Alexeev

Lea otras preguntas en las etiquetas

¿La configuración en el archivo startup.s se genera utilizando KEIL IDE y pone el Fcpu a 60 MHz directamente? linterna DIY - enchufe USB [cerrado]