RS232 problems using software UART

[mewanchyna]

I'm trying to establish a serial tranmission using a PIC 16F676 which has no hardware UART. I'm using the internal oscillator at 4MHz. Of course I also am using a Max232 IC as the interface between the serial port and PIC. I've tried various baud rates but still get nothing more than garbage. It looks like a timing issue. I've scaled the text down to one letter for easier debugging. My next plan is to use an external clock. Anyone have any ideas?

[#include <16F676.h>
#device adc=8
#FUSES NOWDT, INTRC, NOPROTECT, BROWNOUT, MCLR, NOCPD, NOPUT
#use delay(clock=4000000,RESTART_WDT)
#use rs232(baud=110,parity=N,xmit=PIN_C3,bits=8,force_sw,restart_wdt)

void main() {

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_comparator(NC_NC);
setup_vref(FALSE);
while(1){
delay_ms(800);
printf("H\r\n");
}

}
][/code]

[PCM programmer]

The internal oscillator could be poorly calibrated. The frequency might
be incorrect by a sufficient amount to cause framing errors in the PC's
UART.

[mewanchyna]

My external oscillator test will verify the clock error. I'm surprised that after trying several devices that are supposed to have an internal clock accuracy of 1% has such poor timing. Also note that I've used a low Baud rate which should be less critical than higher rates. The testing will continue!

[Ttelmah]

Actually, the baud rate, will not affect the basic criticality of timings. The accuracy required, depends on the total 'length' of a character, and the sampling strategy being used. For a typical hardware PC UART, the bits are sampled at 40%, 50%, and 62% of the expected bit time. Now if you have a character that has one start bit, 8 data bits, and a parity bit, then the parity bit starts 9 clock times after the edge of the start bit, and the 40% point, will be 9.4 clock times from the edge of the start, and the 62%point, will be at 9.62 clock times from the edge of the start. These will be mis-sampled, if (in the first case), the _relative_ clocks between the two devices is fast by 9.4/9, and in the second case, if the clock is slow by 9/9.62. These give a allowable margin of typically 1.044 (4.4%) in the worst case. The actual baud rate, does not enter this equation anywhere....
Now it is important to be aware, that unless a UART is running off a clock that is exactly divisible by the required rate, there will be an error in the division (a typical PC, may on some rates be over 1.5% in error, both as a result of the division factors used, and internal errors in the crystal - stupidly, if you have 'spread spectrum' enabled in the BIOS of many PC's, it is designed to slightly shift the processor clocks to reduce peaks in the noise spectrum produced by the units, and allow EMC tests to be passed, and on some units, it shifts the UART clock as well, resulting in random fluctuations in the measured baud rates, of about another percent!). If you combine this with a baud rate that is already slightly out, because of the division factors chosen, the total error rises again. I have seen PC's producing well over 2% timing errors in some cases...
Now on your PIC, the qoted accuracy for the internal RC oscillator, is +/- 2%, if you are using 5v (the 1% figure is only achieved if using 3.5v operation). If you are running down at 2.5v, the quoted accuracy falls to +/-5%. Assuming you are on 5v, then it doesn't take much error at the other end, for the total error to be getting outside the allowable range...

Best Wishes