Wow. This turned into another huge tutorial. Get set!

Using these debugging and tweaking techniques discussed in this tutorial, you should be able to implement a software UART of pretty much any rate. We have very successfully implemented 115200bps on the 16F819 because it has a higher 8MHz internal oscillator. With a 20MHz external crystal the timing becomes even easier!

We will be demonstrating a difficult setup of 57600bps using the internal 4MHz oscillator of the 16F628. It does work! It's just a painful journey...

Get to it!:

Page 1 : The basic RS232 timing layout and requirements
Page 2 : Setting up a project under MPLAB
Page 3 : About StopWatch and Debug functions
Page 4 : Using the StopWatch to tailor delays used in RS232 timing
Page 5 : Hardware connections and HyperTerminal setup

Ok, so we wrote the original "Serial Comm Tutorial" not really knowing what we were doing. That tutorial should still be read for reference! It has good information about the RS232 protocol and how to handle it.

We have since had a few projects pop up that required the 12F675, 12F629, 16F819, and 16F872. So what? Well, none of these PICs have an onboard hardware UART. And when we went to use our handy dandy software based serial routines, things started falling apart.

Mostly it was the soft_rs232_in() function - the function that the PIC uses to monitor input from the computer (rs232 in... get it?). Very handy if you want to send keyboard commands to the PIC and have the PIC respond to a 'z' or an arrow key.

We also upgraded to a purchased version of the CC5X PIC Compiler. Quite possibly the first software package we've ever paid for! The free version of the compiler does not have code optimizations. So when we went to compile our original code with the new optimized compiler, ALL the timing routines got thrown out the window.

There was also a project that required faster 57600 and 115200 bps communication. While the original guess and check method got us going using the 9600bps routines, it is really unlikely that we are going to find a magical number for our time delay 'for' loop with such tight delays for 115200bps.

So it's time to learn how to calculate delays required for timing specific applications and then learn how to correctly implement those time delays!

First, a review of what 9600bps means.

When you setup hyperterminal under Windows to accept 9600baud communication, that means that it will expect to see a bit every 104us (microseconds).

9600 bits per second = 9600 bits / seconds

Flip the fractions:

1 second / 9600 bits = 1.041666e-4s or 104.17us per bit

So you need to send the computer a bit every 104 microseconds. How about 57600bps?

1 second / 57600 bits = 17.361us per bit

So depending on your hardware, you will need to select the speed in which you communicate. It's probably best to start out getting 9600bps to work. Then go to 57600bps or higher.

Now let's take a look at the rs_out routine from the Serial Comm Tutorial:

Serial_Out = 1;
rs_wait();

for (j = 0 ; j < 8 ; j++)
{

Serial_Out = !send_me .0;
send_me = rr(send_me);
rs_wait();

}

Serial_Out = 0;
delay_us(100);

Everything is fine and dandy. send_me gets clocked out from least significant bit to most significant bit. But then there is this rs_wait function that forms . Previously we have you attempt to use a calibrate_step varible to attempt at guessing what the delay should be. While this worked for us, it's not very professional or even easy. A much more elegant solution is to use the StopWatch!