Serial communications is a long and complicated subject, and you could write a book about just on it's own. Lot's of people successfully implement Serial comms and get away with it, and just because they never encounter any problems they become ‘instant experts’. And because they never had problems, it's always assumed neither should anyone else. This is not the case. There's lots of problems that can creep in and it’s more luck and good fortune if you never encounter any.

Here’s a small checklist…

1. Firstly a stable oscillator is a must. If you have 4MHz, and it's a Crystal or a Resonator (or other type of external oscillator - eg TTL oscillators - but NOT RC types) then that’s fine. If you rely on an internal oscillator or RC type oscillators, it’s unlikely you will get stable communications above 1200 baud. If you do, again it’s down to good fortune. Experimenting with a latest batch of 100 PIC16F628’s running on internal oscillator, about 80% managed 2400 baud, 17% managed only 1200 baud, and 3% only reliably managed 300 baud. You can see it’s a lottery so Serial Comms MUST have a good stable oscillator.

2. If you’re using a Xtal or Resonator, have you remembered the appropriate loading Capacitors? Some Resonators (especially the 3-pin ones) have them built-in and do not need any external Capacitors added.

3. Have you remembered to tell PBP what oscillator setting you’ve got? 4MHz is the default so no additional action needs to be taken if you have 4MHz.

4. Have you remembered to tell the PIC what oscillator it is to use. You might have a 4MHz Xtal or Resonator, but if the PIC is set to Internal Oscillator then it’s not going to make any difference. With a 4MHz Xtal or Resonator, your PIC should be set to XT-OSC.

5. When playing, always start at the lowest baudrate and work up. So if 1200 baud doesn’t work, drop to 600 or 300. If however you have a good Xtal or Resonator (or other external oscillator), and you cannot get at least say 4800 baud reliably (at 4MHz), then you have other problems that need investigating (for example see point 4).

6. If using HSERIN/HSEROUT remember you need to hardware INVERT your comms signal before it is sent to your PC. The use of a MAX232 or equivalent is the usual route although there are many other methods.

7. A lot of garbage can get pipelined in Serial Communications and a single bit misplaced can ruin your day. So to flush this out, always prefix your transmission packet with a number of NUL ($00) characters… this little loop is a good test sending to your PC…

Loop:
HSEROUT [REP $00\8,13,10,”The quick brown fox jumps over the lazy dog”,13,10]
Pause 1000
Goto Loop

8. If sending to a PC, always try to terminate your data packet with a CR/LF (13,10 in my above example). This terminates the Data Buffer String at the PC’s end and starts a new string with the next data packet. Lots of people try to send mountains of data to the PC and wonder why everything hangs after about 32K characters. It’s because Microsoft DOS/Microsoft Languages only allocate around 32K to the comms input buffer (certainly was the case with Microsoft Basic). When this buffer is full no more data will be accepted and everything hangs. Send periodic CR/LF’s to flush the buffer and ensure this never happens.

Hope these tips will be handy on the road to resolving your issue.

Melanie

Oh, as an afterthought, if your Hardware is good, and you still have problems, post your code (showing any and all defines) and we can all take a look at it...