A baja velocidad en baudios, como 9600bps, no creo que el control de flujo de hardware CTS / RTS sea necesario. Creo que a tasas de baudios más altas, CTS / RTS será necesario. ¿Cuál es esta tasa de baudios? ¿Se puede seguir sin CTS / RTS a 115.2kbps?
No es la velocidad de datos lo que importa; usamos CTS / RTS (o XON / XOFF para el control de flujo de software) donde existe la posibilidad de un desbordamiento del receptor , aunque hay que admitir que es más probable que a velocidades de datos más altas.
Si un receptor no puede vaciar sus buffers lo suficientemente rápido, entonces debe desactivar el CTS (en respuesta a lo cual, el transmisor hará valer RTS si hay más datos para transmitir).
Tenga en cuenta que el transmisor puede experimentar una insuficiencia de datos en el búfer , en cuyo caso debe deshabilitar RTS (porque no hay datos válidos). enviar).
Por lo que se trata de la rapidez con la que se pueden mover los buffers, es más probable que sea un problema a velocidades de datos más altas, pero depende completamente de la implementación; no hay una sola velocidad.
El control de flujo de hardware permite que los equipos de comunicación se sincronicen entre sí. Permite que el equipo receptor indique que está listo para recibir los datos que se envían. Si se envían datos cuando el receptor no está 'escuchando', esto causará errores en los datos.
La velocidad de datos a la que se produce esto dependerá de una serie de otras cosas, incluido el tipo de dispositivo y el software en el dispositivo. Si está conectando dos PC a 115.2K, es probable que funcionen bien. Si son dos microcontroladores con otra carga de software, pueden no hacerlo.
Si especifica qué tipo de dispositivos están enviando y recibiendo, recibirá un mejor consejo.
Necesita algún tipo de control de flujo (ya sea ese hardware o XON / XOFF) cuando está transfiriendo datos a una velocidad superior a la que puede procesarlos. Es tan simple como eso.
El control de flujo se usa para un extremo para indicar al otro extremo "espere un momento, todavía estoy pensando". Por lo general, está ligado a un búfer que está casi lleno (conocido como "marca de límite superior").
La necesidad de control de flujo en una interfaz serial asíncrona depende completamente de las necesidades de la aplicación. A veces, una velocidad en baudios más lenta puede disminuir la velocidad de datos efectiva para aliviar la necesidad de control de flujo, pero eso depende de la aplicación.
Existen algunas técnicas que pueden permitir que una aplicación funcione a velocidades de transmisión más altas sin la necesidad de usar el protocolo de control de flujo. Uno de ellos es utilizar una técnica de envío y recepción de UART con interrupción y poner en cola el flujo de datos entre el código de la línea principal de la aplicación y las rutinas de interrupción a través de búferes FIFO circulares.
El uso de búferes FIFO se debe hacer en función de si el procesador de la aplicación puede manejar las interrupciones UART a la tasa de caracteres (es decir, baud_rate / bits_per_transmission_unit). Si no puede manejar esa tasa de interrupción más la pequeña sobrecarga impuesta por el manejo del búfer FIFO, entonces sería necesario reducir la velocidad en baudios lo suficiente para permitir que la tasa de interrupción funcione.
A veces, el procesador de su aplicación tendrá un UART que incluye un FIFO de hardware incorporado. Si estos se utilizan junto con un esquema de almacenamiento en búfer de FIFO con manejo de interrupciones, puede ser beneficioso para el diseño de rutina del servicio de interrupciones vaciar los FIFO de hardware de recepción o la transmisión de relleno. los FIFO de hardware completamente en el momento de la interrupción hacia / desde el software manejado por los buffers FIFO que normalmente serían de mayor tamaño. Configurado y codificado correctamente, esto puede reducir la tasa de interrupción neta que un procesador de aplicaciones debe manejar a cualquier velocidad de transmisión en particular.
Recuerdo que cuando solíamos usar terminales "tontas", usted teclea Ctrl + S (XOFF) para pausar la transmisión para que podamos leer la pantalla antes de que los datos se desplacen. Luego escribiríamos Ctrl + Q (XON) para reanudar la salida. La pantalla puede estar en pausa durante 10 minutos. No tenía nada que ver con la velocidad en baudios.
De manera similar, una impresora en serie que se quedó sin papel puede hacer valer el control de flujo del hardware para pausar la salida mientras se reemplaza el papel. De nuevo, no tendría nada que ver con la velocidad en baudios.
¿Se puede seguir sin CTS / RTS a 115.2kbps?
Por lo general, envío datos desde mi ATmega328P * a un monitor serie a 115200 baudios. Eso funciona bien.
* Arduino
¿Te importa que tus datos se caigan en el cubo de bits? Si es así, entonces use el control de flujo.
¿Tiene una paridad secundaria / ECC / control de flujo como TCP? Si es así, entonces estás cubierto. Sin embargo, al utilizar TCP / OSI como modelo, varias capas realizan la comprobación y el control de errores para garantizar la entrega de datos y para mantener los errores lo menos posible. Digamos que está ejecutando TCP / IP, sin control de flujo de hardware a 115.2kbps, su tasa efectiva debido a problemas de flujo de hardware podría ser terrible.
Hay muchas consideraciones.
No hay un número mágico para "cuándo necesito control de flujo de hardware", es una pregunta que se debe hacer y responder en el contexto de un sistema específico.
¿Se puede seguir sin CTS / RTS a 115.2kbps?
Muchos sistemas lo hacen, vea, por ejemplo, los puertos de la consola serie en casi todas las placas de Linux integradas.
Si el dispositivo de destino tiene un búfer de 16 bytes pero la interrupción rápida no está garantizada, RTS / CTS siempre se prefiere y también incluye bit de paridad impar para mayor confiabilidad. Sin todos los detalles, es difícil saber el umbral del desbordamiento del búfer de destino, por lo que se convierte en prueba y error.
Lea otras preguntas en las etiquetas uart flow-control