Hace poco pedí dos dongles Bluetooth para mis Arduinos para que puedan comunicarse a largo plazo. Los dongles que ordené tienen el pin con la etiqueta CTS-I y el pin con la etiqueta RTS-0. Hice un poco de googlear y descubrí que tienen algo que ver con el "control de flujo", ¿qué es eso?
Tengo a los Arduinos comunicándose correctamente sin estos pines en uso. ¿Para qué están destinados estos dos pines? ¿Debo usarlos? ¿Cómo puedo usarlos?
El control de flujo es un término general para un medio por el cual una entidad que quiere enviar información a otra puede evitar enviarla más rápido de lo que el receptor puede aceptar. Una de las formas más tempranas de control de flujo que todavía existe en el uso común comúnmente se llama xon / xoff; se usó en la comunicación entre teletipos, en situaciones en las que un teletipo estaba usando su lector de cinta de papel para enviar datos a otro teletipo. Aunque una impresora de teletipo generalmente podría mantenerse al día con un lector de cinta de papel (ambos operados a diez caracteres / segundo), eso dependería de cosas como un suministro adecuado de papel. Un operador que notó que era necesario reemplazar el papel en un teletipo que estaba recibiendo una transmisión podía escribir Control-S para enviar un carácter XOFF, que pediría al lector de cinta de papel en el otro extremo que se detuviera. Una vez que se reemplazó el papel, el operador podría escribir Control-Q para reiniciar el lector de cinta de papel. Esos caracteres todavía se utilizan hasta el día de hoy, aunque el extremo remoto de la conexión generalmente será una computadora en lugar de un lector de cinta.
El protocolo RTS / CTS es un método de intercambio de información que utiliza un cable en cada dirección para permitir que cada dispositivo indique al otro si está o no listo para recibir datos en un momento dado. Un dispositivo envía en RTS y escucha en CTS; el otro hace lo contrario. Un dispositivo debe bajar su cable de salida de protocolo de enlace cuando está listo para recibir datos, y alto cuando no lo está. Un dispositivo que desea enviar datos no debe comenzar a enviar bytes mientras el cable de entrada de intercambio sea bajo; Si ve que el cable del protocolo de enlace pasa a nivel alto, debería terminar de transmitir el byte actual y luego esperar a que el cable del protocolo de enlace se agote antes de seguir transmitiendo.
Tenga en cuenta que, aunque lo ideal es que los dispositivos nunca envíen más de un byte después de que su entrada de intercambio sea alta (si la línea se pone alta al comenzar a transmitir un carácter, deben permitir que ese carácter se transmita por completo), muchos puertos serie de PC No cumpla con esto, incluso cuando está habilitada la comunicación. Los puertos en serie permiten que el software detecte el estado del cable entrante de intercambio y espera que el software decida cuándo se deben poner en cola los datos para la transmisión. Desafortunadamente, la única forma de lograr un buen rendimiento con un puerto en serie es poner en cola los datos para su transmisión un poco antes de que realmente se envíen, y muchos puertos en serie para PC siempre transmitirán los datos en cola tan rápido como puedan sin importarlos. Para los cables de apretón de manos. En consecuencia, no es infrecuente que los puertos serie de PC envíen una docena de caracteres, incluso después de que se les haya pedido que esperen.
RTS = Solicitud de envío. El dispositivo de envío le indica al otro extremo que se prepare para recibir y que configure su línea CTS cuando esté listo.
CTS = Borrar para enviar. El extremo receptor está listo ("todo despejado") y le dice al otro extremo que comience a enviar los caracteres.
Hace mucho tiempo, las conexiones semidúplex eran comunes. Estas fueron conexiones unidireccionales y estas señales se utilizaron para "cambiar la línea", por lo que no intentó enviar cuando se le estaba enviando algo.
El "handshaking" de hardware, usado incorrectamente, era un problema clásico de "la computadora se atasca", y era tan problemático que la mayoría de los implementadores simplemente dejaron de intentar usar este método de handshake. Es por eso que tuviste éxito.
Si los caracteres continúan siendo enviados después de que el extremo lejano diga que se detenga, esto puede deberse a la "FIFO" (Primero en entrar, primero en salir) en el dispositivo. Esto puede almacenar (almacenar en búfer) varios caracteres para enviar, por lo que la computadora no tiene que detenerse y verificar después de cada carácter. Pero, como se dijo, a veces es difícil hacer que se detenga. De ahí la creación de buffers de recepción ...
Lea otras preguntas en las etiquetas flow-control
Información de sentido común y desarrollo estructural ¿Pensamientos avanzados del juego? Swing todavía confirma? Whew. Espero que haya valido la pena. El cGame que tengo es básicamente 3D. Mi capa de terreno es geometría vertical, pero el parque temático es realmente similar. Por supuesto, como descubrí por mi amigo del campamento de verano D&D 2013, pequeñas cajas, racimos de huevos e iluminación interactiva del patio de recreo son (al menos en parte) el resultado de los niños inteligentes de TDK (¿sabías... Lees verder