Actualmente estoy enfrentando el siguiente problema: hay un sistema, que consiste en un dispositivo maestro y una cantidad de dispositivos esclavos (todos esos dispositivos tienen MCU pequeñas). Se comunican con algún protocolo personalizado basado en cable serie (se parece bastante a Modbus). Todos los dispositivos esclavos deben tener identificaciones únicas dentro de un bus, por lo que el dispositivo maestro puede abordar cada uno de esos esclavos. Actualmente me veo obligado a codificar esos ID en cada dispositivo esclavo. Mi objetivo es actualizar todos esos dispositivos con el mismo firmware, por lo que no se deben usar ID codificadas para que esto sea posible. Estoy pensando en un dispositivo maestro, que es capaz de asignar direcciones únicas a todos esos dispositivos, pero no puedo averiguar cómo hacerlo. ¿Alguien me puede dar alguna idea o concepto sobre cómo extender mi protocolo de comunicación para que esto sea posible? Tal vez alguien me puede dar un ejemplo?
Detección de dispositivos en un bus simple
4 respuestas
Para hacer este tipo de direccionamiento dinámico en un bus común, en última instancia, debe tener una de estas dos cosas:
- un espacio de direcciones muy pequeño para que pueda realizar una búsqueda bruta de manera eficiente
- algún tipo de sistema de detección / gestión de colisiones
Si no tiene ninguna de estas dos cosas, necesitará las direcciones de código en los dispositivos maestro y esclavo.
El motivo de esto es que si tiene un espacio de direcciones (de tamaño N) que es demasiado grande para buscar de manera eficiente al revisar cada dirección N, entonces cualquier algoritmo de búsqueda optimizado que pueda encontrar la dirección en menos de N pasos debe Incluye la posibilidad de que más de un esclavo transmita una respuesta al mismo tiempo. Si la capa física no puede manejar esta situación, lamentablemente no tendrá suerte. Si la capa física puede detectar colisiones, hay muchas opciones, como tener un retardo aleatorio de reintento cuando se produce una colisión (Ethernet), o usar algo como el bus CAN donde las colisiones se manejan de manera cooperativa.
Si, en lugar de un bus real, tenía un arreglo en cadena, entonces el maestro podría hablar con el esclavo, asignarle una dirección y luego enviarle un comando para habilitar el puerto de salida al próximo esclavo. Repita hasta que todos los esclavos tengan direcciones. Esto es básicamente cómo funciona la enumeración USB con concentradores apilados.
Además, ¿qué tipo de arreglo de hardware está utilizando? ¿La placa de esclavos está conectada a un backplane? Si es así, puede agregar pines adicionales en el conector con diferentes disposiciones de pines conectados a tierra en cada ranura para que actúen como una identificación, leída por GPIO en el esclavo, para generar la dirección del esclavo.
Diseñé un sistema para esto hace varios años.
Funcionó como el esquema de abajo. Se estableció un anillo de comunicación común.
Cada esclavo tiene un circuito de interruptor lógico que inicialmente, o al reiniciar el sistema, bloquea el anillo.
Al iniciar, el dispositivo maestro, en la parte superior, envía un comando "Who_Is_There".
Estructura de comando [CODE◆◆(ID1,ID1 )◆◆END◆
Debido a que los interruptores están abiertos inicialmente, solo el primer esclavo recibió ese comando.
El esclavo copia el paquete de comando y agrega el ID de su tipo de función a la lista y luego envía el comando. El esclavo recuerda el índice de la ubicación que agregó su id de tipo como su dirección de anillo. Una vez enviado, el esclavo cierra su interruptor de anillo. Luego ignora cualquier otro comando "Who_Is_There" hasta el próximo reinicio.
El siguiente esclavo en secuencia hace lo mismo ... y en la cadena.
Finalmente, el maestro recibe el comando nuevamente con una lista de tipos de dispositivos en el orden en que fueron encontrados en el anillo, de modo que conoce el ID de cada esclavo.
Después de eso, el maestro solo dirige los paquetes al esclavo apropiado. Dado que todos los interruptores están cerrados en ese punto. Todos escuchan el comando, pero solo el que responde responde.
Además: en mi aplicación particular, el sistema estaba basado en plano posterior, donde los tableros pueden o no estar completos para una configuración de producto particular. Como tal, los elementos de conmutación se diseñaron en el plano posterior, por lo que la ranura se omitió si el dispositivo no se completó.
En realidad, una alternativa es pasar cada comando a través de cada micro, sin embargo eso introduce una latencia significativa y un poco de sobrecarga a cada micro.
Si no tiene una ID fija y no puede cambiar el hardware para interrumpir las conexiones, entonces necesitará un generador de números aleatorios.
El sistema a continuación puede hacer lo que desees si tienes una manera de generar un número aleatorio en cada micro independientemente uno del otro.
Sin embargo, la generación de la parte del número aleatorio es casi tan difícil como encontrar la parte de su ID si los micros no están conectados a algún tipo de señal analógica que pueda usar para generar su generador de números aleatorios.
Lea otras preguntas en las etiquetas serial protocol serial-bus