RS485 sin control de flujo

RS485 es un bus multipunto, lo que significa que varios nodos están conectados al mismo bus y, en este caso, todos tienen el potencial de "hablar" al mismo tiempo. Para que un dispositivo tome el control del bus y sea capaz de hablar, el transceptor RS485 (en su caso, el MAX3160) debe tener habilitado su pin de habilitación de transmisión. Todos los otros dispositivos en el bus necesitan tenerlos desactivados. Si más de un dispositivo está habilitado para transmitir, los datos se pueden distorsionar porque un dispositivo podría estar tratando de conducir el bus en un estado y otro dispositivo tratando de conducir el autobús en un estado diferente.

Usted habilita el dispositivo para tomar el control del bus configurando el pin DE alto. Una vez que está alto, cualquier cosa en el pin DI se transmite al bus. Es importante tener en cuenta que todos los demás dispositivos en el bus deben tener sus pines DE bajos.

El otro pin de habilitación en el transceptor generalmente se llama el pin ~ RE. Tenga en cuenta que esto es bajo para que cualquier cosa en el bus se refleje en el pin de RO. Eso parece que es el R1OUT en su dispositivo Max.

La mayoría de las veces, ves los pines ~ RE y DE conectados entre sí y a un GPIO en el micro. Este GPIO determina si está escuchando lo que otros nodos en el bus están diciendo o hablando en el bus usted mismo.

Todo esto no debe confundirse con el control de flujo que se usa a menudo en dispositivos como módems que son relativamente estúpidos y tienen buffers de datos relativamente pequeños. Este es un método que dice que cada dispositivo está listo para enviar más datos o está listo para recibir datos. Esto se puede hacer en hardware con pines RTS / CTS y también se puede hacer en software con mensajes XON / OFF. Hay muchos buenos recursos en línea que lo explican muy bien y todavía me meto dentro y fuera de estos de vez en cuando porque puede ser confuso.

Probablemente vale la pena señalar que existen varios métodos para decidir quién puede hablar en el autobús en cualquier momento. Siempre debe haber un método para saber quién es el único maestro en cualquier momento del tiempo.

Entonces, para escuchar en el bus, asegúrese de que ~ RE (R1OUT) y DE estén bajos. Para transmitir al bus, DE debe ser alto. Si ~ RE es alto al mismo tiempo, no obtendrá lo que se está transmitiendo, envíelo de vuelta al pin Rx del UART en su micro.

¿Es posible enviar / recibir en RS485 sin control de flujo?

Sí, ya que no hay control de flujo en RS-485.

RS-485 es una señal única, implementada como un par diferencial. Eso le da una buena inmunidad al ruido y un rechazo del modo común, pero sigue siendo una sola señal. No hay provisión para el control de flujo.

Como todo lo que va más allá del simple envío de un solo carácter en RS-485, el resto depende de su implementación. Depende de usted decidir cuándo los nodos saben que tienen permiso para transmitir, cuánto pueden transmitir en cualquier momento, etc.

El mejor escenario para el control de flujo es asegurarse de que todos los receptores puedan tomar la velocidad de datos sostenida máxima de cualquier transmisor. Si ese no es el caso, entonces necesitas implementar la regulación de datos de alguna manera, pero eso está completamente fuera de la especificación RS-485.

En general, implementas la regulación de datos como parte del protocolo de nivel superior que se utiliza para decidir quién puede enviar. En general, el remitente solo puede enviar un paquete a la vez. Por lo general, estos tienen una longitud máxima, por lo que hay un máximo que un nodo puede enviar sin obtener más permisos, u otro intervalo de tiempo, o lo que sea. La implementación de la regulación de datos mediante el control de flujo de bajo nivel en un bus multipunto como el RS-485 no tiene mucho sentido.

Si todo esto suena demasiado complicado, eche un vistazo a CAN como alternativa a su red RS-485. CAN también utiliza una única señal implementada como un par diferencial, por lo que tiene una inmunidad y robustez similares al ruido. Sin embargo, CAN define varias capas por encima de la señalización de bajo nivel. Incluye paquetes completos, validación de paquetes, detección de colisiones y reintentos, y algunas otras mejoras.

Todas estas partes de CAN, que son estándar, permiten que se implementen en silicio comercial. Hay muchos microcontroladores por ahí que implementan CAN en hardware hasta el nivel de paquetes. El firmware envía y recibe paquetes completos, y el hardware se encarga del resto, incluida la generación y validación de la suma de comprobación CRC.

Si está diseñando un nuevo sistema hoy, RS-485 rara vez es una buena opción. Mira seriamente a CAN en su lugar.