Shift time into RSR (PIC UART)

[qtommer]

hello, sorry i've been posting avidly on the forum but I'm at a stage (in playing with PICs) where I've done my homework and now want a verification from you experts on what I have learnt

Assuming a PIC 876A UART with a baud rate set to 9600. The baud clock has 9600 clock periods per second where each clock period is the time taken to sample 1 bit. (on the receiver)

Assuming a byte comes in at the receiver, how long is the processing time for a byte to be shifted into the Receive Shift Register (RSR) and then transferred to the RCREG?

Assuming 8-N-1, 10 bits are expected to be received (1 start, 8 bits, 1stop) per byte reception , if the baud clock is 9600, time for 1 bit to be shifted would be 1/9600 which is close to 104us. Hence, 10 bits would be 1041us. Is this the time required to shift a byte into the RSR?

I ask this because I want to see how much processing time I can squeeze in to do other processing in my code before going back to receiving another byte (assuming a back to back reception of bytes)

thank you all!

 

[Gayan Soyza]

You are correct that is 104uS X 10 = 1040uS.

I'm doing UART reception in the interrupt.When the PIC received a byte it will generate an interrupt & goes to ISR.I read the RCREG & save them in temp registers & returning from the ISR.Likewise you can read a string of characters.

 

[qtommer]

hi thank you for your reply!

I'm doing it in the non interrupt way cuz my program is sorta dedicated to the receive line but I get you loud and clear.=)

will the transfer from RSR to RCREG take additional cycle time?if so how much??

 

[Jon Wilder]

Assuming a PIC 876A UART with a baud rate set to 9600. The baud clock has 9600 clock periods per second where each clock period is the time taken to sample 1 bit. (on the receiver)

Actually, the "baud clock" runs at either 16x or 64x the serial bit shift rate, depending on whether bit TXSTA,BRGH is set or cleared. When cleared, it runs at 16x and the receive line is sampled on the 7th, 8th, and 9th rising edges of the baud clock. When set, the sampling is done on the 3 clock edges preceding the second rising edge after the first falling edge of a x4 clock. The RX pin is sampled 3 times. It then uses a majority detect circuit and takes the "best 2 out of 3 samples" to determine the state of the received bit whether it be a 0 or a 1.

For reduced error percentage for 9600bps with a 4MHz external clock, it's best to set bit TXSTA,BRGH to run the baud clock in high speed mode. This will drop your error percentage from 7% down to 0.15%.

Assuming a byte comes in at the receiver, how long is the processing time for a byte to be shifted into the Receive Shift Register (RSR) and then transferred to the RCREG?

Since the data sheet doesn't provide this information I think it's safe to assume that data is transferred from the RSR to the receive buffer register in one baud clock cycle upon sampling of the stop bit.

Assuming 8-N-1, 10 bits are expected to be received (1 start, 8 bits, 1stop) per byte reception , if the baud clock is 9600, time for 1 bit to be shifted would be 1/9600 which is close to 104us. Hence, 10 bits would be 1041us. Is this the time required to shift a byte into the RSR?

Yes

I ask this because I want to see how much processing time I can squeeze in to do other processing in my code before going back to receiving another byte (assuming a back to back reception of bytes)

Assuming an external clock frequency (Fosc) of 4MHz (Fins = 1MHz), the PIC will perform 1 instruction per microsecond (1ins/us). If your shift time = 1041uS, this means the PIC can execute 1041 instructions per received byte.

 

[qtommer]

thank you jon for the wonderful breakdown

seeing that the RCREG is a 2 deep FIFO, does this mean that actually we are allowed to actually wait 1041us X2 before an overflow happens?

 

[Jon Wilder]

thank you jon for the wonderful breakdown

seeing that the RCREG is a 2 deep FIFO, does this mean that actually we are allowed to actually wait 1041us X2 before an overflow happens?

Actually you can wait x3 before the overflow happens. The OERR flag doesn't get set until the rising edge of the 3rd byte's stop bit shifts into the RSR (it is the rising edge of the stop bit that triggers the RSR to shift into the buffer). If the receive buffer has not been read prior to the stop bit of the 3rd byte being shifted in, then the overrun error gets set.

 

[qtommer]

YEAH you're right! i just used my debugger and found out that we are given a 3057us leeway before having to retrieve another byte...
thanks alot jon! you're da man!

 

[Mosaic]

For accurate comms perhaps you could look at an 18.432Mhz crystal.

 

[Jon Wilder]

Glad I don't have to worry about any of that. Ahh...the beauty of running bit divisible bit shift rates.