Control de flujo de hardware (CTS/RTS)

Mi MCU no puede activarse a partir de los datos de UART, por lo que quería activarlo desde la línea RTS, pero tengo problemas para entender el concepto.

Cuando estoy enviando datos desde mi MCU al periférico, veo que el periférico establece su línea en ALTO cuando su búfer está lleno. Y tan pronto como pongo mi línea en ALTA, el periférico deja de enviarme ningún dato.

Esto permite la comunicación full-duplex, pero esperaba que el periférico me notificara antes de enviar cualquier dato, configurando su propia línea en ALTO. Esto no permite la comunicación dúplex completo, pero este periférico no admite TX/RX simultáneos de todos modos, por lo que no sería un problema.

Entonces, ¿hay dos modos de control de flujo CTS/RTS? ¿Y tengo mala suerte de que el periférico admita el modo incorrecto? ¿Alguien tiene alguna otra sugerencia sobre cómo puedo activar mi MCU antes de que ingresen los datos de UART?

¿Está seguro de que no puede despertar el mico usando una interrupción de borde en el pin RX (busque en la sección GPIO de las referencias, no en la sección UART). O tal vez también pueda ejecutar la señal RX en una entrada de interrupción de repuesto.
@ChrisStratton El tiempo de activación de la MCU es de alrededor de 65 microsegundos, y la velocidad en baudios es de 115200, por lo que espero perder los primeros caracteres con su método.
¿Puede preceder sus datos con un montón de nulos y definir el protocolo para ignorar cualquiera que pase? ¿O tiene un comando de atención reenviable y la respuesta que busca, antes de comenzar con los datos reales? O blip explícitamente la línea RTS, manipulándola como GPIO (o ioctl o lo que sea) si es necesario, luego espere un poco antes de enviar datos.
@ChrisStratton El problema es activar mi MCU a partir de los datos recibidos por un periférico de terceros (un módulo bluetooth). No puedo controlar su comportamiento ni modificar su firmware.
¿El módulo blueooth origina los datos, o simplemente hace algo como convertir datos seriales bluetooth a datos seriales? Si es lo último, puede solucionarlo agregando el tiempo de activación en el protocolo enviado desde el otro extremo del enlace bluetooth.
@ChrisStratton Si fuera solo un puente en serie, entonces su solución funcionaría, pero desafortunadamente es un módulo Bluetooth 4.0 (Baja energía), que no tiene perfil SSP, por lo que envío comandos API a través de UART y obtengo 'eventos' de su API , pero no puedo influir directamente en el formato del paquete.
¿Tu uart es compatible con dma? Si lo hace, puede ser una solución, ya que utilizará FIFO internamente para almacenar en búfer. ¿Cuál es tu CPU? Publique un enlace a la hoja de datos para que podamos proporcionar una mejor respuesta.
¿Puede usar un evento completo como despertador y luego seguirlo con eventos que logren algo? ¿O seguir reintentando un ciclo de encuesta/respuesta (de eventos en cada dirección) hasta obtener una respuesta y luego continuar desde allí?
Si se envían uno o dos caracteres FF antes que los datos reales, es probable que la CPU los pase por alto a menos que estuviera despierto cuando se envió, pero el segundo carácter no comenzaría hasta 86us después del primero, y el tercer carácter no empezaría hasta 86us después de eso.

Respuestas (2)

Lo que quieres es poder usar otras líneas de control (DTR/DSR). Es Data Set Ready / Data Terminal Ready, y resolvería su problema si su periférico (o el módulo BT utilizado) admitiera dicho comportamiento.

¿Eres capaz de agregar algo de HW a tu lado? ¿Tal vez podría implementar una línea de retraso simple registrando los datos entrantes a través de algunos registros de desplazamiento y activando su MCU en los datos entrantes para que (con suerte) esté listo para recibirlos?

La forma más fácil de hacer esto es usar una interrupción activada por flanco descendente y conectar la entrada en serie en paralelo con la entrada de interrupción.

Si tiene el control del protocolo, simplemente haga que cada paquete comience con un byte "FF", que será alto excepto el bit de inicio, que será bajo. Básicamente, esto solo generará un pulso bajo en el cable, lo que puede darle suficiente tiempo para despertarse y recibir los datos del paquete real.

Vale la pena señalar que una buena ventaja de los bytes "FF" es que, si bien es posible que un byte FF no se reciba correctamente después de un byte con un error de trama, el byte después del FF siempre se recibirá correctamente. Según el diseño de la UART, algunos valores de bytes FE, FC, F8, F0, E0, C0 y 80 también pueden usarse para este propósito. Tenga en cuenta que si está utilizando un protocolo de 9 bits, se debe configurar el MSB del byte de "sincronización".
Control de flujo de hardware (CTS/RTS)
RespuestasAquíPolítica de privacidad1y, 0v