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

Bienvenido al mayor desafío con los sistemas de comunicaciones half-duplex.

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 deben enviarse 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 de "línea está ocupada" / lo que sea, ni los microcontroladores que tienen controladores RS-485 integrados, ni los que usan un núcleo UART conectado a un transceptor externo.

Toda la implementación del control de flujo y control de dirección se deja a cualquier protocolo que use. Existen varios protocolos bien conocidos que utilizan controladores RS-485, como Modbus. También puede implementar cualquier protocolo que se le ocurra.

Para ayudarte, estas son algunas ideas para los protocolos:

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

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

   En este caso, evita los problemas de varios dispositivos que desean hablar al mismo tiempo porque el maestro está allí para coordinar todo.

2. Podría usar algún tipo de programación en la que cada dispositivo en el bus tenga una ranura fija para enviar datos a cualquier otro dispositivo. Una vez que su ranura se agote, 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 ya está hecho. El siguiente dispositivo (por ejemplo, el que tenga la siguiente ID más alta) sabría entonces que podría funcionar. En caso de que un dispositivo no responda, entonces podría tener algún tiempo de espera por el cual cada dispositivo subsiguiente en la programación podría decir: bueno, no he escuchado nada del dispositivo que tenía antes, por lo que debe ser mi turno. p>

(*) Creo que también define una versión de dúplex completo con dos enlaces diferenciales.

Es muy similar a la comunicación por radio de los militares o la policía. Se requiere un protocolo. El esclavo maestro 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.
4. Espere la confirmación.
5. Si no se recibe confirmación, hable nuevamente.
6. Si desea transmitir, pida a todas las estaciones que confirmen la escucha.
7. Si desea hablar con alguien que no puede escucharlo, pregunte si hay alguien más que pueda transmitir.

Y así sucesivamente. Puede ser muy interesante de implementar. ¡Buena suerte!

Aquí hay un par de posibilidades para resolver su dilema.

1. Implementar un sistema de paso de token. Cuando un dispositivo tiene el token, se le permite transmitir durante un período de tiempo limitado. Luego pasa el token al siguiente dispositivo. Se deben hacer provisiones para los nodos faltantes que no pueden recibir y pasar el token.
2. Mira la línea de recepción. Si está ocupado, genere un retraso aleatorio y vuelva a intentarlo. El retardo aleatorio ayuda a garantizar que ningún nodo pueda monopolizar las ventanas de transmisión. Las colisiones aún pueden ocurrir, pero una característica de suma de verificación puede determinar si el paquete recibido está intacto. Si no está intacto, el receptor puede solicitar una retransmisión.

  

¿Cómo puede encontrar una placa si la línea UART es libre de enviar datos,

la respuesta general es que sin algún tipo de protocolo, no puede hacerlo de manera confiable. Por lo general, depende de un controlador o árbitro para ver si una línea está ocupada o no. Una simple sería un pin OD que tira de una línea indicadora hacia abajo antes de la transmisión y la suelta después. Al leer esa línea, un transmisor puede determinar si el bus está disponible o no.

un sistema menos confiable pero más simple es integrar el voltaje del bus (por ejemplo, a través de una red r / c).

  

y si detecta que el bus está ocupado, espere hasta que el bus esté libre y luego envíe sus propios datos.

el enfoque general es esperar un período aleatorio de tiempo y volver a intentarlo.

Resuelvo este problema con mis diseños como este:

en lugar de usar 2 pines para comunicación, uso 3 pines. A 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:

• comprueba el estado de este pin (ENTRADA).
• si el pin es ALTO, entonces el pin baja (SALIDA)
• y habla.
• Cuando se transfiere el mensaje, se suelta el pin (INPUT) (alta impedancia) y el pin se pone alto.
• Si el pin está bajo, espera un tiempo y luego vuelve para verificar el ciclo del pin.

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

Puede usar la pila de protocolo BACnet de código abierto para la comunicación del microcontrolador en RS485 si no desea usar modbus. Básicamente, 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 comenzar:

enlace enlace

Control de flujo de software

Tanto el software como el control de flujo de hardware necesitan software para realizar la tarea de handshaking. Esto hace que el término control de flujo de software sea un tanto engañoso. Lo que se quiere decir es que con el control de flujo de hardware, hay líneas adicionales presentes en el cable de comunicación que indican las condiciones de comunicación. Con el control de flujo del software, que también se conoce con el nombre de control de flujo XON-XOFF, los bytes se envían al remitente mediante las líneas de comunicación estándar.

El uso del control de flujo de hardware implica que deben haber más líneas entre el remitente y el receptor, lo que lleva a un cable más grueso y más costoso. Por lo tanto, el control de flujo de software es una buena alternativa si no es necesario para obtener el máximo rendimiento en las comunicaciones. El control de flujo del software hace uso del canal de datos entre los dos dispositivos, lo que reduce el ancho de banda. La reducción del ancho de banda en la mayoría de los casos, sin embargo, no es tan sorprendente que sea una razón para no usarlo.

Dos bytes se han predefinido en el conjunto de caracteres ASCII para ser utilizados con el control de flujo de software. Estos bytes se denominan XOFF y XON, porque pueden detener y reiniciar la transmisión. El bytevalue de XOFF es 19, se puede simular presionando Ctrl-S en el teclado. XON tiene el valor 17 asignado, que es equivalente a Ctrl-Q.

Usar el control de flujo de software es fácil. Si el envío de caracteres se debe posponer, el carácter XOFF se envía en la línea, para reiniciar la comunicación nuevamente se usa XON. El envío del 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 fue discutido: el uso de bytes en el canal de comunicación ocupa algo de ancho de banda. Otra razón es más severa.

Handshaking se utiliza principalmente para evitar un exceso del búfer del receptor, el búfer en la memoria se usa para almacenar los bytes recibidos recientemente. Si se produce una saturación, esto afecta la forma en que se manejan los nuevos caracteres en el canal de comunicación. En el peor de los casos en que el software ha sido mal diseñado, estos personajes se tiran sin verificarlos. Si dicho carácter es XOFF o XON, el flujo de comunicación puede sufrir graves daños. El remitente proporcionará continuamente nueva información si se pierde el XOFF, o nunca enviará nueva información si no se recibió un XON.

Esto también es válido para 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 claramente debido al ruido en la línea? También es necesario tener precaución especial 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 mediante el control de flujo de software es solo aceptable cuando las velocidades de comunicación no son demasiado altas, y la probabilidad de que se produzcan excesos de búfer o daños en los datos es mínima.

CSMA de alta velocidad

Para alta velocidad como Ethernet CSMA sentido del operador, acceso múltiple, detección / evitación de colisiones, con temporizadores de retroceso aleatorios se han analizado para detectar la probabilidad estocástica de optimización.