Cómo encontrar la línea UART libre para enviar datos

Question

Tengo varias placas que se comunican entre sí con Rs485. Tienen ATMega microcontroladores de la serie como atmega168p o atmega8 . Cada tabla es libre de enviar datos en cualquier momento y tengo la limitación que lleva a No puedo usar Modbus . El número de tablas puede oscilar entre 5 y 10.

Mi problema es: Cómo puede una placa encontrar si la línea UART está libre para enviar datos, y si detecta que el bus está ocupado, esperar a que el autobús esté libre y luego enviar los datos propios?

¿Existe un indicador o registro especial que pueda cambiarlo automática o manualmente y que permita a la otra placa encontrarlo? La línea está ocupada ?

Answer 1

Bienvenido al mayor reto de los sistemas de comunicación semidúplex.

RS-485 no es un protocolo, es una norma que define las propiedades eléctricas de un enlace diferencial semidúplex(*). No hay nada en la especificación sobre cómo se deben enviar los datos a través de ese enlace, o de hecho cómo se utiliza el enlace.

Los transceptores RS-485 no tienen una señal/bandera/lo que sea de "línea ocupada" automática, ni tampoco los microcontroladores que tienen controladores RS-485 incorporados, ni los que utilizan un núcleo UART conectado a un transceptor externo.

Toda la implementación del control de flujo y del control de dirección se deja al protocolo que se utilice. Existen varios protocolos muy conocidos que utilizan controladores RS-485, como el Modbus. También puedes implementar cualquier protocolo que se te ocurra.

Para ayudarte, estas son un par de ideas de protocolos:

1. Tienes un protocolo de tipo maestro-esclavo. En éste hay un nodo maestro que coordina el bus, y nodos esclavos que tienen cada uno un identificador único.

   Los nodos esclavos no pueden enviar ningún dato hasta que el nodo maestro envíe específicamente comandos dirigidos a ellos. Una vez que un esclavo está dirigido, puede responder a cualquier comando de una manera predefinida, por ejemplo, un paquete de respuesta de longitud fija.

   En este caso se evitan los problemas de que varios dispositivos quieran hablar al mismo tiempo porque el maestro está ahí para coordinarlo todo.

2. Se podría utilizar alguna forma de programación por la que cada dispositivo del bus tenga un slot fijo en el que enviar datos a cualquier otro dispositivo. Una vez que su ranura se agota, debe dejar de enviar y permitir que el siguiente dispositivo hable.

   La programación podría ser realizada por los propios dispositivos sin necesidad de coordinación externa. El primer dispositivo habla y envía un mensaje diciendo que ha terminado. El siguiente dispositivo (por ejemplo, el de mayor ID) sabría entonces que puede ir. En caso de que un dispositivo no responda, se podría tener un tiempo de espera por el que cada dispositivo posterior en el programa podría decir: bueno, no he oído nada del dispositivo anterior a mí durante un tiempo, así que debe ser mi turno.

---

(*) Creo que también define una versión full-duplex utilizando dos enlaces diferenciales.

Answer 2

Es muy similar a la comunicación por radio de los militares o la policía. Se requiere un protocolo. El maestro-esclavo es fácil y bueno para la mayoría de los casos. Pero otra opción es hacerlo como lo hacen los humanos:

1. Escucha.
2. Si alguien habla, espera.
3. Si crees que nadie habla, puedes hablar tú.
4. Espera la confirmación.
5. Si no se recibe confirmación, vuelva a hablar.
6. Si quieres emitir, pide a todas las emisoras que confirmen la escucha.
7. Si quieres hablar con alguien que no puede oírte, pregunta si hay otra persona que pueda transmitirte.

Y así sucesivamente. Puede ser muy interesante ponerlo en práctica. Buena suerte.

Answer 3

Aquí tienes un par de posibilidades para resolver tu dilema.

1. Implementar un sistema de paso de fichas. Cuando un dispositivo tiene el token, se le permite transmitir durante un periodo de tiempo limitado. A continuación, pasa el testigo al siguiente dispositivo. Hay que tomar medidas para los nodos perdidos que no pueden recibir y pasar el testigo.
2. Mira la línea de recepción. Si está ocupada, genera un retardo aleatorio y vuelve a intentarlo. El retardo aleatorio ayuda a garantizar que ningún nodo pueda monopolizar las ventanas de transmisión. Todavía pueden producirse colisiones, pero una función de suma de comprobación puede determinar si el paquete recibido está intacto. Si no está intacto, el receptor puede solicitar una retransmisión.

Answer 4

Cómo puede una placa saber si la línea UART está libre para enviar datos,

la respuesta general es que sin algún tipo de protocolo, no puede hacerlo de forma fiable. normalmente se depende de un controlador o árbitro para ver si una línea está ocupada o no. Una forma sencilla sería que un pin OD bajara una línea indicadora antes de la transmisión y la liberara después. Leyendo esa línea un transmisor puede determinar si el bus está disponible o no.

un sistema menos fiable pero más sencillo es integrar la tensión del bus (a través de una red r/c, por ejemplo).

¿y si detecta que el bus está ocupado, espera hasta que el bus esté libre y entonces envía sus propios datos?

el enfoque general es esperar un periodo de tiempo aleatorio y volver a intentarlo.

Answer 5

Yo resuelvo este problema con mis diseños de esta manera:

en lugar de usar 2 pines para la comunicación, uso 3 pines. En distancias cortas funciona. El tercer pin es el indicador de línea ocupada. Este pin se tira hacia arriba desde el lado del maestro. Cuando alguien (MCU o lo que sea) quiere hablar:

• comprueba el estado de este pin (INPUT).
• si el pin es ALTO entonces hace que el pin sea bajo (OUTPUT)
• y charlas.
• Cuando el mensaje se transfiere libera el pin (INPUT) (alta impedancia) entonces el pin se pone en alto.
• Si el pin está bajo, entonces espera un tiempo y vuelve a comprobar el ciclo del pin.

Esta es una implementación de la respuesta de Gregory Kornblum.