El microcontrolador escribe datos adicionales en escrituras de alta frecuencia

Estoy usando C-Control Pro 128 que contiene un procesador atmega. Conecté la interfaz rs232 con mi PC y leí los datos entrantes, ejecutando el siguiente programa en el controlador:

void main(void) {
  Serial_Init(0, SR_8BIT | SR_1STOP | SR_EVEN_PAR, SR_BD9600);
  Serial_Write(0, 1);
  Serial_Write(0, 2);
}

Esperaba que el controlador generara los bytes 1 y 2 . En cambio, recibo lo siguiente:

1
2
119
119

Si escribo, por ejemplo, ocho bytes en lugar de dos, 119 se agrega ocho veces a los datos reales. Si escribo solo un byte, solo se transmite el byte, por lo que todo funciona correctamente.

El número 119 es independiente del valor de los bytes y de la tasa de baudios.

Si agrego una instrucción de suspensión entre los comandos de escritura (alrededor de 50 ms), el problema no ocurre.

¿Alguien ha tenido un problema similar o alguna idea de dónde podría estar ubicado el problema?

Cuando escribes 8 bytes, ¿esos 8 bytes llegan correctamente a la PC, luego recibes 8x 119?
Sí, primero todo el bloque correcto, luego el 8x119.
¿Tienes un analizador lógico o un osciloscopio?
Ok, miraré el gráfico del osciloscopio.
Simplemente envíe un byte, preferiblemente algo con un patrón distintivo, como la letra K
¡Gracias por su ayuda, esto resolvió mi problema! El osciloscopio mostró los datos exactamente como se esperaba, por lo que usé un programa de terminal diferente, que no muestra los bytes adicionales. El problema debe estar en el programa terminal que usé primero. Un poco extraño, porque nunca descubrí ningún problema con eso, hasta ahora. De todos modos, no queda ningún problema. Si quieres que acepte tu respuesta, simplemente publica el último comentario como respuesta :)
FYI: háganos saber sus configuraciones anteriores, creo que ha activado el modo XON OFF. Donde envía los caracteres de control a través del canal de datos.
No, Xon Xoff no estaba habilitado, ni siquiera hace ninguna diferencia en la primera terminal. Usé 9600 baudios, 8 bits de datos, 1 bit de parada e incluso paridad, que también es la configuración en el código.

Respuestas (1)

La forma de diagnosticar este tipo de problemas es reducirlos a la mitad. ¿De quién es la culpa? ¿El C-Control o el PC? Si podemos mirar los datos reales enviados por el cable, podemos decir dónde se encuentra la falla.

Comience enviando un carácter simple y fácilmente identificable, una y otra vez. Me gusta usar el que se usa como ejemplo en la página RS232 de Wikipedia porque puede ver fácilmente cómo se supone que debe verse la forma de onda.

K RS232

Ahora necesitarás un osciloscopio. Si no puede pagar uno, le recomiendo el analizador Saleae Logic . No es tan caro y le ahorrará literalmente días de su vida. Mire la forma de onda en el bus y verifique que coincida con la forma de onda que espera. Verifique si hay caracteres maliciosos transmitidos después.

Suponiendo que todo se vea bien, entonces el problema está en algún lugar de la PC. Si aparecen los 119 caracteres falsos, entonces sabe que el problema está en el C-Control

El microcontrolador escribe datos adicionales en escrituras de alta frecuencia
RespuestasAquíPolítica de privacidad1y, 0v