¿Es realista un "tiempo de espera" de 0.2 ms para la comunicación UART?

0

En la mayoría de los ejemplos (de Arduino / STM32 / lo que sea) veo tiempos de espera de 10 a 100 ms para diferentes tipos de comunicación.

Sin embargo, me pregunto cuánta "sobrecarga" hay. Suponiendo que quiero enviar 8 bytes (incluidos los bits de detención + sobrecarga, a través de RS485, 2.5 mbps) y obtener una respuesta (digamos también 8 bytes). Esto tomaría: 64 bits / 2500000 bits / s = 32 us.

Ahora debe haber algún procesamiento (manejo de interrupciones) desde ambos lados (envío + recepción). Estoy usando HAL, que quizás tenga un poco más de sobrecarga, así que tomemos unas 10.000 instrucciones enormes. En una CPU de 72 MHz esto tomaría 10,000 / 72,000,000 = 138 us.

Esto suma menos de 200 juntos ... ¿Echo de menos algo?

(tenga en cuenta que tengo la intención de usar interrupciones, y probablemente DMA más tarde, ya que probablemente tendrá menos gastos generales).

EDIT

  • Comunicación de un STM32F103C8T6 a otro STM32F103C8T6
  • Ambos se ejecutan a 72 MHz
  • RS-485 a través de UART, 2.5 mbps
  • No hay otras interrupciones de mayor prioridad (que pueden bloquear UART)
  • Requisito: no es difícil, pero preferiblemente múltiples mensajes dentro de 1 ms.
pregunta Michel Keijzers

2 respuestas

3

La respuesta es, desafortunadamente, "depende".

¿Con qué estás hablando? ¿Qué tipo de procesamiento tienen que hacer los nodos antes de que puedan responder? ¿Cuánto tiempo tarda la señal en pasar por el cable y ser recibida (esto solo es importante para los enlaces RS485 REALMENTE largos)? ¿Cuáles son los límites (habilitación y cambio del controlador) en sus controladores RS485?

Los tiempos de espera son siempre una buena idea: aseguran que, sin importar lo que ocurra en el cable, su dispositivo responderá de manera predecible y controlada. Significa que su protocolo será más robusto y una falla de comunicación no acabará con el enlace. Sin embargo, 200us parece realmente apretado y tengo que preguntar por qué querría hacer cumplir un tiempo de espera tan rápido. 2.5mpbs es bastante rápido, pero está hablando de RS485 y también necesita administrar la DE y la temporización entre cuadros: ¿ha pensado en estos elementos porque tienen un impacto directo en las capacidades del enlace? y en última instancia, su valor de tiempo de espera.

Si está utilizando UART con el controlador de hardware habilitado, esto es un bono, especialmente a velocidades de datos tan altas; de lo contrario, estará girando esperando que el registro de cambio de transmisión esté vacío (¡NO el registro de espera!) o incurriendo en un procesamiento de interrupción adicional para apagar el controlador cuando se haya puesto el último bit en el cable. Algunos controladores también requieren un poco más de tiempo antes de ser deshabilitados, lo que puede agregar más tiempo a la ecuación.

¿Qué disposiciones tiene el protocolo que está utilizando para la integridad de los datos? ¿Tiene que calcular los CRC o imponer la integridad real de los parámetros? Estos también consumirán tiempo de recepción y procesamiento de paquetes, especialmente si no tiene asistencia de hardware. ¿El protocolo permite la fragmentación de paquetes o la transmisión y recepción fuera de orden? ¿Qué pasa en el caso de una colisión? No ha proporcionado suficiente información y sospecho que, según el estilo de su pregunta, no le ha dado a estas cosas importantes el pensamiento que requieren para que podamos responder su pregunta correctamente.

Tómate un tiempo y piensa en el problema. 2.5mbps en un sistema con un reloj de 72MHz no tiene mucho tiempo para gastar en estas cosas, especialmente si está realizando otro procesamiento de datos además de ejecutar el enlace de comunicación. El poder de procesamiento involucrado no es mucho, pero parece que estás atando intencionalmente una mano detrás de tu propia espalda y te estás planteando un problema mucho más difícil sin una buena razón.

Y, por último, si al final del día quieres hacerlo ... ¿por qué no elegir un número para el tiempo de espera y experimentar? Cargue los sistemas, dese el enlace físico más largo, hágalo de mierda, agregue algo de ruido e incertidumbre, aumente la temperatura y vea dónde comienza a romperse el sistema. En realidad, idealmente estarías haciendo esto de todos modos.

    
respondido por el akohlsmith
3
  

Esto totaliza menos de 200 juntos ... ¿Echo de menos algo?

En caso de que la otra parte sea una PC: sincronización USB. Por lo general, esto se programa en marcos USB completos (para velocidad máxima) y puede agregar hasta 1,5 ms de latencia. Incluso es posible una mayor latencia cuando la PC está "cargada".

En caso de que la otra parte sea otra µC, sus 200 µs parecen ser un tiempo de espera útil.

    
respondido por el Turbo J

Lea otras preguntas en las etiquetas