Tasa de bits de la comunicación uart

Tengo una configuración que se comunica entre PC (Windows) y Atmega2560 usando UART. En el lado de la PC estoy usando Pyserial. Desde la PC estoy enviando un párrafo de texto byte a byte a Atmega2560. La configuración de UART es: velocidad de 2400 baudios; datos de 8 bits; 1 bit de parada; Sin paridad; El código de Pyserial es el siguiente:

string = "some sample text" strobe = serial.Serial('com3',baudrate = 2400) for x in string: strobe.write(x) sleep(0.001)

Usé un osciloscopio para verificar la señal UART en el pin RX de la MCU y observé que había una brecha de 15 ms entre dos marcos de datos. Mis preguntas son:

  1. ¿Las tramas de datos en UART se transmiten sucesivamente, es decir, después de un bit de parada, comienza el bit de inicio de la siguiente trama?
  2. Si la respuesta a la pregunta anterior es afirmativa, ¿la velocidad de transmisión de datos es la misma que la velocidad en baudios?
  3. En la transmisión de datos (de PC a MCU), sin el retraso de 1 ms, los datos se corrompen. ¿Por qué sucede esto? ¿Cómo puedo transmitir con éxito sin ningún retraso?

También estoy enviando datos de MCU a PC. Cuando probé el pin TX de la MCU usando el osciloscopio, hubo un retraso insignificante entre los cuadros de datos. Creo que esto se debe a que estoy usando interrupciones para transmitir en la MCU.

Estoy agregando el código Atmega2560 aquí:

volatile uint16_t address; volatile char incoming; uint8_t in_buffer[2000]; void eeprom_write(uint16_t add,uint8_t val){ while(((EECR)&(0x02)) != 0);//EEPE bit cli(); EEAR = add; EEDR = val; EECR |= 0x04;//EEMPE EECR |= 0x02;//EEPE sei(); } ISR(USART0_RX_vect){ incoming = UDR0; in_buffer[address]=incoming; address++; } int main(void){ /*initialization of uart*/ address = 0; incoming = 1; while(incoming!='#'){} for(uint16_t i = 0 ;i<address;i++) eeprom_write(i,in_buffer[i]); }

La terminación de los datos se indica con '#'.

Las PC con Windows y Python no son muy eficientes en el tiempo, ese retraso podría ser simplemente una sobrecarga del sistema operativo o del idioma. Pero, ¿por qué estás agregando un retraso de 1 ms?
Sin agregar 1 ms de retraso, los datos se corrompen cuando los recibe la MCU.
Eso suena como (1) un problema de codificación en la MCU o (2) una MCU MUY lenta. Casi siempre uso 115 kbps sin problemas. ~400µs entre bits, >3.5ms entre bytes es una velocidad glacial.
Ese retraso es tolerable. Pero, ¿cómo puedo monitorear la velocidad de datos en vivo en el lado de la PC?
¿Usar una aplicación de terminal serie? ¿Conectar Tx a Rx para poder ver todas las transmisiones? ¿Conseguir un autobús pirata? ¿Usar un analizador lógico barato? ¿El osciloscopio? Sin más información sobre qué es exactamente lo que quiere "monitorear" es difícil saber cuál es la herramienta adecuada.
@shubhamsharma: hola, su comentario dice " cómo puedo monitorear la velocidad de datos en vivo en el lado de la PC ". ¿ Qué quiere decir con " tasa de datos en vivo "? ¿Quiere decir que tiene que encontrar una tasa de datos desconocida? Pero no, no puedes decir eso, ya que ya nos dijiste que son 2400 bps. Entonces, ¿tal vez quiere decir que necesita monitorear los datos en vivo ? Pero no, no puedes decir eso, porque sigue diciendo tarifa de datos . Entonces , edite su pregunta para aclarar y agregar más detalles. Gracias.
@SamGibson De la velocidad en baudios, entiendo que es la velocidad a la que la MCU/PC muestrea la señal UART para convertir los datos en serie en un byte. Como he visto que hay una brecha de 15 ms entre dos tramas de datos sucesivas, creo que la tasa de bits real diferiría de la tasa de baudios. Aunque, cuando la MCU está transmitiendo, hay una brecha insignificante entre dos tramas de datos sucesivas, en este caso, creo que puedo decir que la tasa de bits es igual a la tasa de baudios. Corríjame si tengo una comprensión incorrecta de la velocidad en baudios.
Voto para cerrar esta pregunta como fuera de tema porque es un problema XY. El error real es uno de software en el código MCU, que impide que los datos se acepten sin demora, y la solución es encontrar y corregir eso, no tratar de hacer que un sistema operativo de escritorio se comporte como un sistema duro en tiempo real.
UART no utiliza marcos.
¿Por qué necesita monitorear la "tasa de datos en vivo" sea lo que sea? Creo que si modifica su pregunta para explicar más cosas, tal vez alguien pueda ayudarlo. Parece que puede monitorear fácilmente la cantidad de bytes enviados o recibidos en tiempo real desde cualquier extremo. Así que no puedo imaginar lo que estás tratando de hacer o por qué necesitas hacerlo.
@ChrisStratton He agregado el código MCU.

Respuestas (1)

2400 baudios son 240 caracteres (octetos) por segundo a 10 bits por cuadro (que es el estándar "8N1"). Dormir durante 1 milisegundo no afectará mucho el espaciado, ciertamente no de una manera predecible, porque cada carácter tarda 4 ms en enviarse.

Podría ser que el sueño de Python no pueda hacer sueños tan cortos como 1 ms,

aún así, si desea monitorear los datos, necesita un osciloscopio (o conecte la línea de datos a través de una resistencia a la entrada de una tarjeta de sonido, haga una grabación y visualícela en un editor de archivos de sonido; el voltaje probablemente fluctúe un poco pero usted debería ver claramente los bordes de cada bit.)

¿Podría haber algo que mantenga ocupado su microcontrolador de tal manera que no pueda manejar 240 caracteres por segundo?

No es que Python no pueda dormir durante un corto período de tiempo, es que el sistema operativo del host normalmente no respetará retrasos tan cortos: obtendrá su retraso, pero no volverá a ejecutarse hasta que el programador se comunique con usted. . Y luego, por lo general, también hay que agregar latencia USB.