Actualmente estoy trabajando en un proyecto en el que usamos TIVA C TM4C123G y actualmente me estoy inspirando en el launchpad como diseño de referencia. Tengo varios periféricos UART para conectar al chip principal usando UART, sin embargo, en los pines del chip RTS y CTS solo están marcados en el UART1. ¿Cómo se supone que debo lidiar con esto?
Depende de qué tipo de "control de flujo" usen "varios periféricos UART" (no identificados). También depende de si necesita comunicación simultánea con sus periféricos, y si necesitan poder "interrumpir" el controlador de forma asíncrona, o si serán sondeados y solo "hablar cuando se le habla". Todos estos son parte del diseño general del sistema, que es un problema mayor que el problema restringido que usted preguntó.
Es posible que solo puedas ignorar estas señales. CTS (Clear To Send) y RT (Request To Send) proporcionan un mecanismo de intercambio para que cada dispositivo pueda decirle al otro cuando esté listo para recibir datos.
Sin embargo, muchos Uarts no implementan esto y suponen que el otro extremo puede tomar datos en cualquier momento o usar otro método como XON / XOFF
El protocolo de intercambio de hardware con RTS / CTS no se usa con mucha frecuencia en equipos modernos, pero tendrá que consultar el manual, algunos dispositivos aún lo requieren.
El soporte de hardware para RTS / CTS puede ser ventajoso y, a veces, necesario, dependiendo de la cantidad de "aviso anticipado" que un dispositivo pueda dar cuando necesite que un dispositivo de transmisión se detenga. Si un dispositivo receptor no tiene soporte de hardware para liberar RTS automáticamente, deberá poder asegurarse de que siempre puede atender cualquier carácter entrante antes de que el búfer de hardware pueda desbordarse. Si un dispositivo no tiene soporte de hardware para retener CTS, entonces tendrá que evitar que el UART tenga más caracteres de los que el receptor podría manejar después de liberar RTS.
Si tanto el transmisor como el receptor incluyen soporte de hardware para RTS / CTS, podrán comunicarse de manera confiable incluso si el receptor tiene solo un búfer de un solo carácter y el software del receptor a veces puede tardar un tiempo en responder a los datos entrantes (si el el receptor dejaría caer los datos al recibir el segundo byte completo, tendría que liberar RTS mientras recibe el primero, lo que degradaría el rendimiento; si no eliminara los datos a menos que / hasta que llegue el bit de inicio de un tercer byte, Podría dejar RTS afirmado hasta que esté recibiendo el segundo). Si el receptor carece de soporte de RTS de hardware, no será posible una comunicación confiable a menos que el búfer del receptor pueda contener todo lo que pueda llegar mientras no pueda responder a los datos entrantes (por ejemplo, porque está demasiado ocupado con interrupciones de mayor prioridad). Si el receptor tiene soporte de hardware pero el remitente no, la comunicación confiable será posible, pero solo si el software del remitente se mueve a sí mismo, por lo que nunca le da al UART más datos de los que se pueden transmitir con seguridad.
En chips con funcionalidad similar a PLD en algunos de los pines, puede ser posible falsificar el soporte RTS en bruto en chips que no tienen soporte de hardware real programando una salida para que se active automáticamente cada vez que el pin de recepción en serie sea bajo. Eso tendría el efecto de hacer que el receptor comience a informarse de que no está listo cada vez que comienza una transmisión. Una vez que el software recibe un byte, podrá volver a enviar el CTS para que el remitente sepa que puede transmitir otro byte. El rendimiento con tal enfoque probablemente sería malo, pero si un dispositivo que no tiene soporte de RTS de hardware ni la capacidad de garantizar buenos tiempos de respuesta de interrupción necesita recibir datos de un dispositivo que detiene los datos inmediatamente cuando se libera su CTS (el RTS del receptor) , tal enfoque podría permitir una operación confiable.
Otro enfoque que a veces puede ser útil en los casos en que un dispositivo responderá y no responderá a intervalos predecibles (por ejemplo, porque realiza periódicamente alguna tarea que requiere 100% de CPU, sin interrupción, por milisegundos a la vez) es para que un dispositivo libere RTS cada vez que esté a punto de entrar en un estado que no responde, independientemente de si su búfer de recepción estaría listo para aceptar algunos datos. El mayor problema con este enfoque es que si un dispositivo solo está listo para recibir datos durante ciertos momentos y otro solo verifica si está listo para recibir datos en ciertos momentos, no se enviarán datos a menos que esos tiempos coincidan.
Personalmente, considero que el soporte de RTS / CTS por hardware es una característica valiosa, pero muchos fabricantes de chips no lo parecen. Afortunadamente, los chips FTDI de USB a serie responden muy bien a esas señales (otras también pueden hacerlo, pero no las he probado), lo que hace posible que un dispositivo sin soporte de hardware RTS / CTS solicite un byte a la vez. afirmar RTS brevemente (no estoy seguro de cuál sería el ancho mínimo) siempre que el software del receptor compruebe si hay un byte entrante y lo libere poco después. Esto funcionará de manera confiable siempre que RTS nunca se afirme accidentalmente por más de un intervalo de caracteres a la vez.
RTS y CTS no son necesarios. RX y TX son suficientes si haces todo el control de flujo en el software.
Por ejemplo: se puede usar RTS si tiene un transceptor RS-485 (que solo puede transmitir o recibir a la vez) para deshabilitar automáticamente el receptor y habilitar el transmisor cuando desea enviar algo.
Si su MCU no tiene RTS de hardware, también podría hacer lo mismo con un GPIO y un código.
RTS y CTS solo le permiten tener el control de flujo ... quizás esté usando un chip FTDI que traduce los flujos de USB a UART ... Aquí hay 4 métodos de control de flujo que se pueden programar para el dispositivo FT232BM.
Ninguna: esto puede provocar la pérdida de datos a altas velocidades
Apretón de manos RTS / CTS - 2 cables. El dispositivo transmitirá si CTS está activo y descartará RTS si no puede recibir más.
Apretón de manos DTR / DSR - 2 cables. El dispositivo transmitirá si el DSR está activo y soltará el DTR si no puede recibir más.
XON / XOFF: el control de flujo se realiza enviando o recibiendo caracteres especiales. Uno es XOn (transmitir encendido) el otro es XOff (transmitir apagado).
Según el requisito que pueda seleccionar ... hay un comando en la línea de terminal que podemos usar para configurar o restablecer el control de flujo. Use este enlace para obtener más detalles.
stty --file / dev / ttyUSB0 -crtscts para deshabilitar el control de flujo de hardware
stty --file / dev / ttyUSB0 crtscts para habilitar el control de flujo de hardware.
stty -F / dev / ttyUSB0 -crtscts ixon ixoff para deshabilitar el software hon flow habilitado xon y xoff.
Lea otras preguntas en las etiquetas uart