115200 to 57600 conversion

[Barney]

I am using a 16F88 to buffer the 115200 baud output of a device. The PIC receives data at 115200 baud and then transmits it to a PC at 57600 baud. HW details: PIC running at 18.432Mhz, the 115200 is going into the hardware UART, and I am using a software UART at 57600 to send to the PC.

I am using INT_RDA to store the incoming bytes into a 64 byte circular buffer. There is a loop in main() that checks for new data in the buffer and transmits it if found at the slower rate.

Since the hardware UART has a 2 byte FIFO plus the RSR this gives almost 3 bytes of hardware buffering. I figured that would be enough to cover the slower xmit rate, but I knew the code would have to be very tight.

In my test case, I send 20 bytes with no delays and the PIC is dropping 3 bytes at 57600. So just for grins I raised the xmit rate and at 65000 baud no bytes were dropped. (I don't plan on using 65000 baud, just wanted to see how high I had to go to not drop bytes.)

I instrumented the interrupt handler and the fputc() command to toggle output pins and looked at the timing on a DSO. PIN_B4 for the fputc() shows a time of 213uS. Transmitting a byte at 57600 should take only 174 uS, so I am loosing 39 uS somewhere.

Questions:

1. Is 115200 to 57600 feasible? There seems to be more overhead than I expected. Would a hand written ASM output routine be efficient enough?

2. I can go to 20Mhz and gain another 8.5% of clock speed. Worthwhile? An extra 8.5% gain in clock speed dosen't seem enough.

3. I am using the 16F88 because I am familiar with it, but would consider going to a 40Mhz 18F if that would work.

[Mark]

[ckielstra]

Mark,
Can you explain why you are ignoring the incomming nulls? If the incomming data stream is binary, then I think it is incorrect to throw away incomming null data.

[bkamen]

[Mark]

[Barney]

1. The data comes in bursts so the 64 byte buffer should be long enough to handle the situation. I agree that the INT_RDA must be disabled while using a software UART to transmit so I am using the DISABLE_INT parameter in the #use rs232(). I also tried bracketing the fputc() with disable, enable interrupt commands and it worked about the same.

2. I am ignoring nulls because the cretin that designed the external device uses the TX pin for other things, like an index pulse. The index pulse causes the PIC UART to see <NULL> characters. The real data is ASCII text so throwing away the <NULL>s is OK.

3. I tried polling with kbhit() and it was even worse for dropping characters.

Using the bit_clear() function to implement the circular buffer is cute. Any idea on how much time it saves?

4. No handshaking available. The PIC has to be able to keep up with 115200 baud characters. Yeah the design bites, but that is what I have to deal with.

[Mark]

So you tried the code that I posted and it dropped more chars?

[Barney]

Yes I tried your code. It was very similar to a polling routine I had tried earlier and both were signifcantly worse than the interrupt version.

I think this mid-line CPU just doesn't have the horsepower to do the job reliably so I am moving up the food chain. I found some 18F6227 with dual EUSARTs that should give me a lot more head room.

I am not familiary with the 18F6XXX series, in particular the data addressing. How big a byte array will the CCS compiler support on this chip?

[newguy]

[Ttelmah]

The dual UART chip, will get rid of the problem, provided the data really can be shifted out in the time. However looking at it, I'd suspect you might actually get better results using the two UARTs the other way round!. This is the reverse to what seems 'good logic', since using the hardware to handle the faster rate makes good sense, but if you are running the 'polling' approach, using the software input for the higher rate, potentially allows the slower data to be sending while the faster data is being received. If you reversed the UARTS, and then used the polling code posted, but modified with:

[Barney]

Interesting out of the box thinking. While I am waiting for the 18F parts, I will give it a whirl and report on the results.

I also realized that the UART TX section is sitting idle. Right now, all of the communication is one way, so I could use the set_uart_speed to switch back and forth between the different receive and xmit rates. Any words of wisdom?

[Mark]

[Barney]

Right, bad idea. Back to the drawing board.

[Barney]

I tried a couple of other ideas and they didn't work. Sadly, I have to conclude that the 16F88 doesn't have the horsepower to do the job reliabily.

1. The 115200 software UART: Looking at the timing requirements, it should have worked, but didn't. I cut the polling loop to just the kbdhit() and fgetc() and toggled an output bit before and after the fgec(). I didn't even store the data or output it. The oscilloscope shows a lot of data is being missed. Don't know why.

2. External Interrupt: Since the software UART was missing bytes, I thought to use the EI to "kick start" it by triggering on a falling signal to detect the start bit. There is a 8.5 uSec delay between the falling signal and a bit toggle at the start of the interrupt handler. This means the interrupt handler misses the entire start bit at 115200 baud. I could maybe write a custom routine to pick up the 8 data bits, but that seems too hokey.

So now I am waiting for some 18FXXX parts with dual H/W UARTS & a PCH compiler. My new motto is "Do it in hardware".

Thanks for the suggestions.

[Barney]

The 18F6627 with the dual UARTS works like a champ. No more dropped characters. I set it up with a 2KB buffer and just for grins ran some tests to see how much buffer was required for various output bauds. These results depend on the burst timing characteristics of my incoming data (YMMV). When graphed it shows a pretty good quadratic curve. In each case a total of 519 bytes was received at 115KB. Since I can't figure out a way to do tables, the data is ordered pairs of:

Xmit Rate:Max #Chars Buffered

9600:245
14400:218
19200:190
28800:150
38400:127
57600:93
115200:2