No sé por qué quieres algo más conveniente. Pero sería posible probar varios otros arreglos.
Algunas ideas iniciales sobre las dificultades son que tus dispositivos estarán (1) a distintas distancias unos de otros, y (2) funcionando con relojes completamente asíncronos. Su línea de reloj se recibirá (debido a la demora de la señal, el retraso de hardware micro, y debido a sus propios retrasos de software) en diferentes momentos por los diferentes dispositivos. Así que necesitas asegurarte de que los tiempos de configuración de los datos son lo suficientemente largos como para garantizar que están presentes y son sólidos en el momento en que cada dispositivo reconoce el flanco de reloj (suponiendo que planeas utilizar un flanco para activar el muestreo de datos). También puedes necesitar alguna forma de resincronizar todos tus dispositivos en caso de que uno de ellos (o más) se "pierda" o se inicie incorrectamente pensando que está en medio de una comunicación de tu maestro. Es posible que quieras tener un diseño de señal de "inicio" muy claro. (Para esto, podrías buscar en protocolos existentes, como los destinados a comunicarse con EEPROMs seriales o I2C).
Un enfoque comúnmente utilizado -- he visto esto en productos comerciales -- es atar cada uno de sus dispositivos "en serie" (TX de un dispositivo atado al RX del siguiente, ese TX luego conectado con el RX del dispositivo aún más próximo, etc.) con señalización de hardware RS-232 y utilizando el puerto serie asíncrono habitual del micro. Cada dispositivo es entonces responsable de reconocer y pasar cualquier comunicación que no esté destinada a él. Aquí puede haber retrasos, pero con su comportamiento de "encender luces" no creo que esto importe mucho. Otro problema es que están en serie, así que si algún cable se desconecta o hace un cortocircuito entonces tienes todo el sistema caído.
Otra opción sería que buscaras el uso de drenaje abierto en una "línea de partido" compartida (o, como he utilizado antes, dos líneas de partido de drenaje abierto compartidas - una para iniciar el arbitraje y otra para resolver la propiedad) utilizadas para resolver la propiedad del único par de líneas del puerto serie. En la forma en que lo he hecho antes, requería cuatro cables para cualquier número de dispositivos. El par del puerto serie se mantenía en alta impedancia en todo momento cuando no estaba en uso (otros esquemas que puedo imaginar pueden funcionar aquí, también.) El otro par era compartido por todos, pero las salidas eran operadas en drenaje abierto con un pull-up externo cada una. Una de ellas se utilizaba para iniciar un diálogo de arbitraje para la propiedad (que llamé subvención línea) del par de puertos serie. Cualquier dispositivo podría intentar bajar la línea de concesión de arbitraje en cualquier momento si lee que la línea de concesión de arbitraje no está ya bajada. Cualquier otro dispositivo, al ver que la línea de concesión de arbitraje ya está bajada, NO intentará participar en el arbitraje por sí mismo, sino que esperará a ver si la línea de concesión de arbitraje vuelve a estar inactiva en algún momento en el futuro. Hasta entonces, todos los dispositivos que esperan obtener la propiedad simplemente esperan.
Ahora es posible que dos o tres dispositivos observen que la línea de concesión de arbitraje no está bajada, decidan bajarla, y luego observen que la bajaron con éxito (mirando) y por lo tanto crean que han ganado la propiedad del puerto serie. Esto sería mala . Por lo tanto, la segunda línea (que llamé el arbitraje id ) se utiliza para desplazar en serie un patrón binario que representa su propio código de identificación personal en binario. Al maestro se le asignaría "0000" (o cualquier número de bits que quieras asignar a cada dispositivo). Los dispositivos envían en serie cada bit a la línea de ID de arbitraje (mientras todos mantienen la línea de concesión de arbitraje bajada, ya que aún no se ha resuelto quién es el dueño de las cosas), de uno en uno. A continuación, leen el bit para ver si coincide con el suyo. Si no lo hace (y eso significa que intentaron serializar un "1" de drenaje abierto cuando alguien más intentó aplicar un "0" de drenaje abierto), liberaron su retención en la línea de concesión de arbitraje y salieron de todas las líneas de partido. Perdieron el arbitraje y ahora deben esperar hasta que la línea de arbitraje se libere de nuevo.
En poco tiempo, y ciertamente en el momento en que todos los bits de identificación son desplazados, alguien es el ganador. A continuación, se aferran a la línea de concesión hasta que terminen con la línea del puerto serie. Ya que ganan, configuran su par de puertos serie (usé bit-banging para esto) donde configuran el TX como una salida y el RX como una entrada. Todos los demás dispositivos invierten ese orden y escuchan.
La temporización que tenía que utilizar en cada procesador tenía que tener en cuenta los retrasos relativos para llegar a cada dispositivo, además de los retrasos que implica que el software observe las condiciones de la línea y/o establezca las condiciones de la línea. Así que si se utiliza un bucle de sondeo, por ejemplo, hay que tener en cuenta el tiempo necesario para dar una vuelta completa al bucle en cada dispositivo y el hecho de que los diferentes procesadores pueden estar en diferentes lugares en sus propios bucles y en diferentes relojes. El cálculo del periodo de tiempo no es difícil de hacer. Pero es necesario para que no haya confusión.
(Mi situación era un conjunto de dispositivos que se probaban después de ser fabricados y antes de la calificación completa para su envío. Habría un número arbitrario de dispositivos colocados en una mesa y vinculados a un controlador maestro que se utilizaría para someter a los esclavos a una serie de pruebas durante un período de 24 horas. Y no podíamos considerar la posibilidad de añadir circuitos integrados de señalización RS-485 a placas que normalmente no llevaban esas piezas, así que simplemente utilizábamos pines de E/S directos. Así que no era lo mismo que estás considerando).
El hardware de señalización que utilices tendría que ser el adecuado para unas líneas tan largas. Puede utilizar un par trenzado, como en el caso de cat-5, cat-6, etc., y controladores diferenciales. O puede utilizar el estilo RS-232 de un solo extremo.
O simplemente evite todo lo que acabo de mencionar y considere la posibilidad de utilizar las técnicas RS-485 y los protocolos asociados a ellas para las comunicaciones multipunto.
