USART Bit Time Error

[JEC]

I've searched through a stack of datasheets, errata and app notes without any success.

Short version: When using a hardware serial port, is a 2.3% difference between actual and expected baud rates enough to render received data unreliable?

Longer version:

18F6310, 20 Mhz. 'Heartbeat' LED confirms that the chip is running at the proper speed.

The AUSART (port 2) is set up to receive.

Paper calculations and Mister-E's calculator tools show that there are two sets of register settings which result in a 0% baud rate error for the speed I'm receiving.

This makes me happy.

Expected bit time of incoming data is 3,125 uS. Actual bit time of incoming data - measured on the 'scope with 4 uS resolution - is 3,200 uS, or 2.34% too slow.

I'm occasionally seeing the OERR (overrun) bit set in the RCSTA2 register, even when polling RCIF2 in an exceedingly tight loop.

I can't really change the incoming data rate.

Is this difference enough to occasionally corrupt the data?

Thoughts?
Thanks in advance.

[skimask]

Looks like you're shooting for 312.5 baud, but getting 320 baud? Maybe? Sounds awful slow!
I know you said you read all of the errata and everything...There is a AUSART note in the errata sheets (DS80206F)...


12. Module: AUSART
The AUSART for PIC18F6310/6410/8310/8410 devices may not recognize a received Stop bit if the combined error rate is too high.
Work around
1. Increase the baud rate of the device by decrementing the SPBRGHx:SPBRGx register pair value by one. Verify that the new baud rate does not exceed the maximum combined error
rate of the application.
2. Configure the transmitter to send two Stop bits.
Date Codes that pertain to this issue:
All engineering and production devices.

Try it out...bump it up by one, down by one, whatever works...

[JEC]

10X that, actually. It's MIDI.

I saw that errata & tried bumping the register values (from 39 to 38 and 41, also from 9 to 10 and 8) but without much joy.

The other wrinkle is that even if I tune to 3,200 uS, I'm (maybe) in trouble if a properly timed datastream ever appears.

Hmmmm.

[Darrel Taylor]

Time to buy a new Scope.

The bit rate of 31,250 baud (midi) is 32us.
An entire byte would take 320us.

But the big question is, how are you interfacing with the 5ma current loop?
<br>

[JEC]

Time to buy a new Scope.

The bit rate of 31,250 baud (midi) is 32us.
An entire byte would take 320us.

But the big question is, how are you interfacing with the 5ma current loop?
<br>

Wahoo! My TDS210 is so black and white. Those new colour plasma scopes look fun...

You're right about the byte time. Somehow I messed up that calculation.

Receiving data through a 220W series resistor, a 6N137 and a flyback diode across pins 2 & 3 for protection. 1K pullup on the output, and the signal is nice and clean.

I did some further testing yesterday. Basically sat in a tight loop around RCIF2 and twiddled a pin when something come in and/or an error occurred.

Found that everything was working perfectly. FERR and OERR were never set and every byte I received came through properly.

Then, I re-added my TMR0 interrupt routine, using DT_INTS 18. It ticks every 60 uS and does about 4 uS of PBP work before returning. The routine works well when data is transmitted fairly slowly. It crashes and I start missing bytes when lots of data is sent in a chain.

I suspect that what I hadn't considered was the overhead of 70+ 'hidden' instructions on each side of the interrupt. Even at 20 MHz, it looks like the total interrupt time is about 34 uS.

It shouldn't make a difference, since my main loop is so short. But that's all I can think of right now.

Today I'm going to try using an .asm interrupt routine and see if the extra leanness makes any difference.

[Darrel Taylor]

Then, I re-added my TMR0 interrupt routine, using DT_INTS 18. It ticks every 60 uS and does about 4 uS of PBP work before returning.

A lot of times, the handlers don't use any "heavy duty" PBP commands. Often just counting, setting a flag or something similar. If it's only using 4us, this may be one of those times.

If none of the PBP system registers are used, you can just change the handlers TYPE to ASM, and leave it as PBP statements, instead of having to convert it to ASM. This eliminates that overhead, (which is pretty large).

I'd like to see the handlers to verify it though.
<br>

[JEC]

Thanks, DT, for the suggestions.

Update: I re-spun the code entirely. Got rid of the interrupts altogether and set up everything to poll the needed register flags.

UART2 works perfectly to capture the MIDI data - all of it - and the numbers generated by Mister-E's baud rate calculator are spot-on.

My main loop is massaging UART2's data and re-transmitting at a different baud rate through EAURT1.

Thanks to all for the input. At some point I may re-visit this program and try using interrupts...