1
\$\begingroup\$

I'm working on the UART communication of PIC18F4520. I have tried simulating the code on ISIS proteus and then also checked the real time result. One thing I am quite confused about is that the characters I get from the two i.e. simulation and the experiment are not the same. I have no confirmation of this but still wondering if it is possible that for every other machine, ASCII characters are interpreted differently. Is this possible..?

void main(void)
{
    unsigned char r;
    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 );
    r='y';
    while(1)
    {
        putcUSART(r);    
        while (BusyUSART());            
        r=ReadUSART();
        PORTB=r;
    }
    CloseUSART();
}

The output has been shown in this snapshot:

enter image description here

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Can you share your code and the results you got from the simulation and the experiment? Also, what software did you use in the experiment? \$\endgroup\$ – user17592 Apr 13 '13 at 10:36
  • \$\begingroup\$ following is my code. I am sending a 'y' continuously while expecting an input from PC. but what i get on the PC is this strange character repeating. \$\endgroup\$ – Umer Huzaifa Apr 13 '13 at 11:30
  • \$\begingroup\$ Code starts: #include <p18F4520.h> #include <usart.h> void main(void) { unsigned char r; 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 ); r='y'; l: while(1) { putcUSART(r); while (BusyUSART()); r=ReadUSART(); PORTB=r; } goto l; CloseUSART(); } Code Ends. \$\endgroup\$ – Umer Huzaifa Apr 13 '13 at 11:31
  • 1
    \$\begingroup\$ Yo, you can edit your question ;) please add the code to your question, prefixed with four spaces on each line so that it will get highlighted. \$\endgroup\$ – user17592 Apr 13 '13 at 11:31
  • 3
    \$\begingroup\$ Sure about all the & for OpenUSART? I usually use a | to or bits into a byte, but I am unfamiliar with PIC and this function call. \$\endgroup\$ – jippie Apr 13 '13 at 14:13
6
\$\begingroup\$

No, since it's an encoding standard, if set to ASCII the hex values should mostly be interpreted the same on any machine. The printable A-Z, a-z and numeric characters should be reliable, but as Chris notes in the comments there can be differences with other codes and the extended set.

If you are getting different results between simulation and real life, then it's likely you have set things up incorrectly. Check your baud rates, stop/parity bits, handshaking, and also that the terminal program is actually set to ASCII (i.e. not displaying in hex/octal/binary)

For reference here is an ASCII table.

EDIT - now you have added the code, I see another issue. You set the variable r = 'y', but then read the UART and store the result in this variable, overwriting it. This means the code will only send a y on the first loop. Use a separate variable to read into if yu don't want this to happen (or reset to y within the loop each time)

Something like this:

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();
}
\$\endgroup\$
3
  • \$\begingroup\$ Ok. Thanks for the reply. But do you think this is a mistake that can lead to these alien characters.? \$\endgroup\$ – Umer Huzaifa Apr 13 '13 at 18:09
  • 3
    \$\begingroup\$ This is not entirely accurate. The printable range of 7-bit ASCII may be standard, but the response to non-printable control codes below 32, and 8-bit codes with the MSB set is not entirely standard. And even in the printable range, there are possible terminal translations, and differing responses in the context of escape codes. \$\endgroup\$ – Chris Stratton Apr 15 '13 at 14:23
  • 1
    \$\begingroup\$ @Chris - good point, I'll adjust the wording a bit. \$\endgroup\$ – Oli Glaser Apr 15 '13 at 17:55
3
\$\begingroup\$

First off, that code looks to me like it puts out 1 'y', and then it reads, getting I-don't-know-what and outputting what it reads. Does ReadUSART block waiting for a character?

Second, are you certain of your baud rate calculations? I don't know the platform, so I can't check you, but if your serial terminal is set wrong in the real world, that could easily cause this kind of behavior.

\$\endgroup\$
1
1
\$\begingroup\$

The strange character is Ç. It is code C7 (11000111) in ISO 8851-1. The code for y is 79 (01111001). If we add start and stop bits we get 0110001111 and 0011110011. And of course the idle level in RS232 corresponds to 1.

You can see there are similarities at the binary level, so that if somehow the reception of start and stop bits is unreliable or whatever, it could explain how y turns to Ç.

A correct bistream of back to back yyyy looks like:

0011110011001111001100111100110011110011...

Now you have to understand that in RS-232 there can be a synchronization problem! The only framing information is the 0 start bit and the 1 stop bit. If the start bit is not received correctly, and there is back-to-back continuous transmission, the only way that the receiver can detect that it is in error is if it receives a 0 at a point where the stop bit is expected! If a variety of characters are transmitted, hopefully it will lock in on the correct framing eventually. If there is a pause in the transmission, of course, that helps too.

In repeating sequence of 10 bits, any 0 which is preceded by a 1 could be the start bit. So in a repeating sequence of y, assuming 8 bits, no parity and 1 stop bit, there are two possible frame starts:

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

So assuming a correct receiver and a reliable link (except for missing the start bit), a stream of y could be misinterpreted as a stream of g. You don't need bad hardware to get this screwup.

Now g has code 67, which isn't C7, but some other problem can perhaps explain that one, and also the fact that you were consistently getting the C7 character.

\$\endgroup\$
0
\$\begingroup\$

I have got my problem solved i guess. There was a problem with the development board and as i changed the board, i got the data without any glitches. Thank you everyone.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.