Caracteres ASCII diferentes en RS 232

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

Si está obteniendo resultados diferentes entre la simulación y la vida real, es probable que haya configurado las cosas incorrectamente. Verifique sus velocidades en baudios, los bits de parada / paridad, el protocolo de enlace, y también que el programa del terminal realmente está configurado en ASCII (es decir, no se muestra en hex / 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 y en el primer bucle. Use una variable separada para leer si yu no quiere que esto suceda (o reinicie a y dentro del bucle 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();
}

Primero que nada, ese código me parece que emite 1 'y', y luego se lee, obteniendo lo que no sé y obteniendo lo que lee. ¿ReadUSART bloquea a la espera de un personaje?

Segundo, ¿estás seguro de tus 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 este tipo de comportamiento.

El carácter extraño es Ç . Es el código C7 (11000111) en ISO 8851-1. El código para y es 79 (01111001). Si agregamos 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 y se convierte en Ç .

Un bistream correcto de back to back yyyy se ve así:

0011110011001111001100111100110011110011...

¡Ahora tienes que entender que en RS-232 puede haber un problema de sincronización! La única información de encuadre es el bit de inicio 0 y el bit 1 de parada. 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 transmiten una variedad de caracteres, es de esperar que se bloquee en el encuadre correcto con el tiempo. Si hay una pausa en la transmisión, por supuesto, eso también ayuda.

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

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

Entonces, suponiendo que un receptor correcto y un enlace confiable (a excepción de que falte el bit de inicio), un flujo de y podría ser mal interpretado como un flujo de g . No necesitas hardware defectuoso para obtener este error.

Ahora g tiene el código 67, que no es C7, pero tal vez algún otro problema pueda explicar eso, y también el hecho de que obtuviste el carácter C7 de manera constante.

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