0

I am currently using the PIC24 with UART and am able to receive (Rx) and transmit (Tx) characters. The problem arises when trying to receive a continuous stream of characters, where there is no delay between start and stop bits.

The UART is setup with; 7 data bits, 1 parity bit and 1 stop bit at 1200baud

When displaying the received characters on a terminal it shows that only certain characters will print correctly. I do not believe this to be a baud rate error as I am able to receive and print characters correctly when small delay between start and stop bits i.e holding down a key on a keyboard.

To read two characters that were sent continuously I am doing as follows.

char buf[512];

while (U2STAbits.URXDA == 0); //wait while Rx buffer is full 
buf[0] = U2RXREG;

while (U2STAbits.URXDA == 0); //wait while Rx buffer is full 
buf[1] = U2RXREG;


while (U2STAbits.UTXBF); //wait while Tx Bit not free
U2TXREG = buf[0];

while (U2STAbits.UTXBF); //wait while Tx Bit not free
U2TXREG = buf[1];
41 72 6c
  • 1,600
  • 5
  • 19
  • 30
DARTH
  • 1
  • 1
  • Ensure that all flags are cleared before starting the transmission. Also, does the comment "wait while Rx buffer is full" make sense to you? – Lundin Sep 10 '19 at 09:19
  • 1
    In your code while waiting for TX to complete the RX buffer could overflow... Maybe you want check conditions together and act on both, or use some synchronization between transmit and receive. – Frankie_C Sep 10 '19 at 09:25
  • Could you elaborate more on "only certain characters", please? Which combinations did you try, and which characters are printed wrong, and what is printed instead? – the busybee Sep 10 '19 at 09:39
  • Is your UART fullduplex or halfduplex? – Mike Sep 10 '19 at 10:15
  • @Mike : Yea it is fullduplex UART – DARTH Sep 10 '19 at 18:34
  • @Lundin: Ive already tried that, also you're right, a better alternative would be "wait for Rx buffer to fill". – DARTH Sep 10 '19 at 18:36
  • @the busybee: Yeah, so characters such as 'A', 'f', and '?' will be fine and characters such as 'a', 'b', '1' will not. Ive looked at the ASCII table and found no correlation to the error. Maybe you can see one though? – DARTH Sep 10 '19 at 18:39
  • *"there is no delay between start and stop bits"* -- That's a requirement of asynchronous character framing. You probably mean no delay between a stop bit and the (next) start bit, otherwise known as a delay between frames. When there is no delay between frames, the UART can get confused and incorrectly start reading the frame on a *false* start bit. Check for framing and/or parity errors in the status register to identify this condition. Does your receive code ever check for errors? – sawdust Sep 10 '19 at 23:18
  • *"a better alternative would be 'wait for Rx buffer to fill'"* -- No, that's still inaccurate. The datasheet I'm looking at states that there is a four-character receive buffer. But your line of code will only wait until "one or more characters are available" (and then retrieves only one character). IOW this UART has a receive FIFO, and you don't show any code that handles it properly. – sawdust Sep 10 '19 at 23:37

1 Answers1

1

There might be other problems which we can't see since you just gave us only a small portion of your code.

Anyway, with the additional information in your comment, it's a mismatch in the parity:

Characters received fine:

char  code  binary    # of 1-bits
'A'   0x41  01000001  2 = even
'f'   0x66  01100110  4 = even
'?'   0x3f  00111111  6 = even

Characters not received:

char  code  binary    # of 1-bits
'a'   0x61  01100001  3 = odd
'b'   0x62  01100010  3 = odd
'1'   0x31  00110001  3 = odd

Please, the next time, instead of putting additional information in a comment, edit your question. That way all visitors have all the bits together without having to wade through all the comments.

the busybee
  • 10,755
  • 3
  • 13
  • 30