Tengo varias placas que se comunican entre sí con Rs485. Tienen ATMega
microcontroladores de serie como atmega168p
o atmega8
. Cada tablero es libre de enviar datos en cualquier momento y tengo una limitación que me lleva a No puedo usar Modbus . El número de tableros puede variar de 5 a 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 hasta que el bus esté libre y luego enviar sus propios datos?
¿Existe un indicador o registro especial que pueda cambiarlo automática o manualmente y permitir que la otra placa detecte que la línea está ocupada ?
Bienvenido al mayor desafío con los sistemas de comunicaciones semidúplex.
RS-485 no es un protocolo, es un estándar que define las propiedades eléctricas de un enlace diferencial semidúplex(*). No hay nada en la especificación sobre cómo se enviarán los datos a través de ese enlace o, de hecho, cómo se usa el enlace.
Como tales, los transceptores RS-485 no tienen una señal/indicador/lo que sea automático de "línea ocupada", ni los microcontroladores que tienen controladores RS-485 incorporados, ni los que usan un núcleo UART conectado a un transceptor externo.
Toda la implementación del control de flujo y el control de dirección se deja en manos del protocolo que utilice. Existen varios protocolos bien conocidos que utilizan controladores RS-485, como Modbus. También puede implementar cualquier protocolo que se le ocurra.
Para ayudarlo, estas son algunas ideas para los protocolos:
Tienes un protocolo de tipo maestro-esclavo. En este hay un nodo maestro que coordina el bus y nodos esclavos, cada uno de los cuales tiene 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 se direcciona a un esclavo, puede responder a cualquier comando de alguna manera predefinida, por ejemplo, un paquete de respuesta de longitud fija.
En este caso, evita problemas de que varios dispositivos quieran hablar al mismo tiempo porque el maestro está allí para coordinar todo.
Podría usar alguna forma de programación en la que cada dispositivo en el bus tenga una ranura fija en la que enviar datos a cualquier otro dispositivo. Una vez que se agote su espacio, debe dejar de enviar y permitir que el siguiente dispositivo hable.
La programación podría ser realizada por los propios dispositivos sin coordinación externa. El primer dispositivo habla y luego envía un mensaje diciendo que está listo. El siguiente dispositivo (p. ej., el que tenga el siguiente ID más alto) sabrá entonces que puede funcionar. En caso de que un dispositivo no responda, podría tener un tiempo de espera en el que cada dispositivo subsiguiente en el programa podría decir: bueno, no he tenido noticias del dispositivo anterior a mí durante un tiempo, por lo que debe ser mi turno.
(*) Creo que también define una versión full-duplex usando dos enlaces diferenciales.
atmega8
microcontrolador, creo que conduce a la inestabilidad en el dispositivo actuaciónEs muy similar a la comunicación por radio de los militares o la policía. Se requiere un protocolo. 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:
Y así. Puede ser muy interesante de implementar. ¡Buena suerte!
Aquí hay un par de posibilidades para resolver su dilema.
¿Cómo puede una placa encontrar 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 manera confiable. normalmente confía en un controlador o árbitro para ver si una línea está ocupada o no. Uno simple sería un pin OD tirando de una línea indicadora hacia abajo antes de la transmisión y soltándola después. Al leer esa línea, un transmisor puede determinar si el autobús está disponible o no.
un sistema menos confiable pero más simple es integrar el voltaje del bus (a través de la red ar/c, por ejemplo).
y si detecta que el bus está ocupado, esperar hasta que el bus esté libre y luego enviar sus propios datos?
el enfoque general es esperar un período de tiempo aleatorio y volver a intentarlo.
Resuelvo este problema con mis diseños de esta manera:
en lugar de usar 2 pines para comm, uso 3 pines. En distancias cortas funciona. El tercer pin es el indicador de línea ocupada. Este pin se levanta del lado maestro. Cuando alguien (MCU o lo que sea) quiere hablar:
Esta es una implementación de la respuesta de Gregory Kornblum.
Puede usar la pila de protocolos BACnet de código abierto para la comunicación del microcontrolador en RS485 si no desea usar modbus. Esencialmente, solo pasa un token que le dice a cada dispositivo cuándo puede enviar, de manera similar a la topología de token-ring y Ethernet. Aquí hay un par de enlaces para empezar:
http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/
Tanto el control de flujo de software como el de hardware necesitan software para realizar la tarea de negociación. Esto hace que el término control de flujo de software sea algo engañoso. Lo que significa es que con el control de flujo de hardware, hay líneas adicionales presentes en el cable de comunicación que señalan las condiciones de negociación. Con el control de flujo de software, que también se conoce con el nombre de control de flujo XON-XOFF, los bytes se envían al remitente utilizando las líneas de comunicación estándar.
El uso de control de flujo de hardware implica que debe haber más líneas entre el remitente y el receptor, lo que lleva a un cable más grueso y costoso. Por tanto, el software de control de flujo es una buena alternativa si no se necesita para obtener el máximo rendimiento en las comunicaciones. El control de flujo de software utiliza el canal de datos entre los dos dispositivos, lo que reduce el ancho de banda. Sin embargo, la reducción del ancho de banda en la mayoría de los casos no es tan sorprendente que sea una razón para no usarlo.
Se han predefinido dos bytes en el juego de caracteres ASCII para usar con el control de flujo de software. Estos bytes se denominan XOFF y XON porque pueden detener y reiniciar la transmisión. El valor de byte de XOFF es 19, se puede simular presionando Ctrl-S en el teclado. XON tiene asignado el valor 17 que es equivalente a Ctrl-Q.
Usar el control de flujo de software es fácil. Si se debe posponer el envío de caracteres, se envía el carácter XOFF en la línea, para reiniciar la comunicación nuevamente se utiliza XON. Enviar el carácter XOFF solo detiene la comunicación en la dirección del dispositivo que emitió el XOFF.
Este método tiene algunas desventajas. Uno ya se discutió: el uso de bytes en el canal de comunicación requiere algo de ancho de banda. Otra razón es más grave.
El protocolo de enlace se usa principalmente para evitar una saturación del búfer del receptor, el búfer en la memoria que se usa para almacenar los bytes recibidos recientemente. Si se produce un desbordamiento, esto afecta la forma en que se manejan los nuevos caracteres en el canal de comunicación. En el peor de los casos, cuando el software está mal diseñado, estos caracteres se tiran sin revisarlos. Si dicho carácter es XOFF o XON, el flujo de comunicación puede verse gravemente dañado. El remitente proporcionará continuamente nueva información si se pierde el XOFF, o nunca enviará nueva información si no se recibió XON.
Esto también se aplica a las líneas de comunicación donde la calidad de la señal es mala. ¿Qué sucede si el mensaje XOFF o XON no se recibe con claridad debido al ruido en la línea? También es necesario tener especial precaución de que la información enviada no contenga los caracteres XON o XOFF como bytes de información.
Por lo tanto, la comunicación en serie que utiliza el control de flujo de software solo es aceptable cuando las velocidades de comunicación no son demasiado altas y la probabilidad de que se produzcan desbordamientos de búfer o daños en los datos es mínima.
Para alta velocidad como la detección de portadora CSMA de ethernet , acceso múltiple, detección/evitación de colisión, con temporizadores de retroceso aleatorio, se ha analizado el rendimiento de probabilidad estocástica para la optimización.
Me gusta el enfoque de 3 pines, pero si 2 maestros bajan la tercera línea al mismo tiempo (lo que tiene una probabilidad baja pero no es imposible con una gran cantidad de mensajes), no verán que se está produciendo una colisión. Tal vez podamos bajar la línea a través de una resistencia y probar el nivel de la señal: por ejemplo: VCC/2 => 1 maestro quiere hablar, VCC/4: 2 maestros quieren hablar... Tan pronto como 2 o más maestros se detectan durante una comunicación, el envío del mensaje se considera fallido y se realiza un reintento después de un tiempo aleatorio. El inconveniente de este enfoque es que necesita 2 pines en el microcontrolador: uno para bajar la línea y otro para muestrear el nivel analógico de la línea.
Lundin
Jeroen3
hoshang shapar