Diferentes caracteres ASCII en RS 232

No, dado que es un estándar de codificación, si se establece en ASCII, los valores hexadecimales en su mayoría deben interpretarse de la misma manera en cualquier máquina. Los caracteres imprimibles AZ, az y numéricos deberían ser confiables, pero como Chris señala en los comentarios, puede haber diferencias con otros códigos y el conjunto extendido.

Si obtiene resultados diferentes entre la simulación y la vida real, es probable que haya configurado las cosas incorrectamente. Verifique sus tasas de baudios, bits de parada/paridad, protocolo de enlace y también que el programa de terminal esté realmente configurado en ASCII (es decir, no se muestra en hexadecimal/octal/binario)

Como referencia, aquí hay una tabla ASCII .

EDITAR: ahora que ha agregado el código, veo otro problema. Establece la variable r = 'y', pero luego lee el UART y almacena el resultado en esta variable, sobrescribiéndola. Esto significa que el código solo enviará un correo electrónico yen el primer bucle. Use una variable separada para leer si no quiere que esto suceda (o reinicie dentro ydel ciclo cada vez)

Algo como esto:

void main(void)
{
    unsigned char r;
    unsigned char t;

    TRISB=0;
    // configure USART
    OpenUSART( USART_TX_INT_OFF  &
         USART_RX_INT_OFF  &
         USART_ASYNCH_MODE &
         USART_EIGHT_BIT   &
         USART_CONT_RX     &
         USART_BRGH_HIGH,
         5 );
    t='y';
    while(1)
    {
        putcUSART(t);      // Changed variable to t to avoid overwriting on read    
        while (BusyUSART());            
        r=ReadUSART();         // Read into r
        PORTB=r;
    }
    CloseUSART();
}

En primer lugar, ese código me parece que emite 1 'y', y luego se lee, obtiene no sé qué y genera lo que lee. ¿ReadUSART bloquea la espera de un carácter?

En segundo lugar, ¿está seguro de sus cálculos de velocidad en baudios? No conozco la plataforma, por lo que no puedo verificarlo, pero si su terminal serial está mal configurado en el mundo real, eso podría causar fácilmente este tipo de comportamiento.

El personaje extraño esÇ . Es el código C7 (11000111) en ISO 8851-1. El código para yes 79 (01111001). Si agregamos los bits de inicio y parada, obtenemos 0110001111 y 0011110011. Y, por supuesto, el nivel de inactividad en RS232 corresponde a 1.

Puede ver que hay similitudes en el nivel binario, por lo que si de alguna manera la recepción de los bits de inicio y parada no es confiable o lo que sea, podría explicar cómo se yconvierte en Ç.

Un bistream correcto de espalda con espalda yyyyse parece a:

0011110011001111001100111100110011110011...

¡Ahora debe comprender que en RS-232 puede haber un problema de sincronización! La única información de trama es el bit de inicio 0 y el bit de parada 1. Si el bit de inicio no se recibe correctamente y hay una transmisión continua consecutiva, la única forma en que el receptor puede detectar que está en error es si recibe un 0 en un punto donde se espera el bit de parada. Si se transmite una variedad de caracteres, es de esperar que finalmente se fije en el encuadre correcto. Si hay una pausa en la transmisión, por supuesto, eso también ayuda.

En una secuencia repetitiva de 10 bits, cualquier 0 que esté precedido por un 1 podría ser el bit de inicio. Entonces, en una secuencia repetitiva de y, asumiendo 8 bits, sin paridad y 1 bit de parada, hay dos posibles inicios de trama:

0011110011001111001100111100110011110011...
      ^--------^ 'g'
          ^--------^ 's'     

Entonces, suponiendo un receptor correcto y un enlace confiable (excepto por la falta del bit de inicio), una secuencia de ypodría malinterpretarse como una secuencia de g. No necesitas un hardware malo para conseguir este error.

Ahora gtiene el código 67, que no es C7, pero algún otro problema tal vez pueda explicar ese, y también el hecho de que estaba obteniendo constantemente el carácter C7.

Tengo mi problema resuelto, supongo. Hubo un problema con la placa de desarrollo y cuando cambié la placa, obtuve los datos sin fallas. Gracias a todos.