0
\$\begingroup\$

I am using PIC18F46K80, at a baud rate of 115200, a Stop Bit of 1 and no parity. I am sending data from a C# application(Baud Rate 115200, Stop Bit-1 and No Parity) to the PIC. After send some bytes of data, I get an over-run error in the PIC. I have inserted delays before receiving the data in the PIC. 

T_UINT8 UARTReceive(T_UINT8 *t_ret)
{
    *t_ret = 0;
    T_UINT8 temp;

    while(!PIR1bits.RC1IF)
    {
        /* Wait till the data is received   */
            if((RCSTA1bits.FERR) || (RCSTA1bits.OERR) )
            {
                temp=RCREG1;
                temp=RCREG1;
                temp=RCREG1;
                temp=RCREG1;
                temp=RCREG1;
                // EUSART1 error - restart
                RCSTA1bits.CREN = 0;
                asm("NOP");
                RCSTA1bits.CREN = 1;              
                *t_ret = 1;
                return 0;
            }
    }

    if(RCSTA1bits.OERR==1)
    {
        k=30;
    }

    /* Return the received data  */
    Delay100TCYX(0);
    asm("NOP");
    asm("NOP");

    return RCREG1;
}

Even after inserting large delay, I am getting an over-run error, on maintaining the same baud rate in C# application . How do I avoid over-run errors while receiving data in my PIC?

\$\endgroup\$
2
  • 3
    \$\begingroup\$ While it's probably not the best way to avoid overruns wouldn't you want the delay when sending in the C# application? By adding a delay on the PIC side it'll make things worse because it'll be longer before it's ready to receive the next character. \$\endgroup\$
    – PeterJ
    Commented Jul 26, 2015 at 8:37
  • \$\begingroup\$ On this micro for this speed you will have better luck processing on the fly. Best way to do it is to configure an interrupt on serial rx, then code a parser as a state machine, then call the second from the first, or even place the parser inside the ISR - as long as it returns quickly enough all should be good. \$\endgroup\$
    – Oleg Mazurov
    Commented Jul 27, 2015 at 0:15

1 Answer 1

Reset to default
5
\$\begingroup\$

You are getting overruns, which means the PIC isn't grabbing data out of the receive buffer fast enough. So adding even more delay makes absolutely no sense. Stop and actually think about what is going on.

Test with the PIC emptying RCREG as quickly as it can when RCIF indicates it has data. If the PIC is doing nothing else, it should be easily able to keep up at 115.2 kBaud.

You may have a baud rate mismatch. Test this by sending some characters and looking at their timing carefully on the scope. Then also verify the PC is sending characters at the same baud rate.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Id just add(for those who may not know) that PIC18F fifos are quite small so any needed accumulation of data (ex the get a full packet of data) should be done in a user's software buffer. \$\endgroup\$
    – Mathieu L.
    Commented Jul 26, 2015 at 12:40
  • 1
    \$\begingroup\$ @MathieuL: Agreed. On small systems like this you want to handle individual bytes at a time, not try to buffer whole packets or something. In the end some code somewhere it going to handle the bytes individually anyway, you might as well design the system that way too. It actually makes things easier in most cases. Also, I usually use the UART interrupts to implement larger software FIFOs for sending and receiving, especially on a PIC 18 and above. \$\endgroup\$
    – Olin Lathrop
    Commented Jul 26, 2015 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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