about using PIC internal oscillator for soft serial comm?

[octal]

Hi,
I plan to use a 18F1320 with its Internal oscillator at 8Mhz in a circuit (or 16F648A at 4Mhz) to control I/O (mainly an LCD and 3 or 4 buttons).
For this design I MUST use RS232 communications at 9600bps (I must avoid Crystal and I have no external clock source).

Do you think that Software USART routines (bitbanging) will be reliable at this rate? I know that temperature effects can alter PIC's internal oscillator precision, but what I want to know is : Does anyone used this solution in a real work and had problems? can you give your feedbacks please?

Regards
Octal

 

[Nigel Goodwin]

Hi,
I plan to use a 18F1320 with its Internal oscillator at 8Mhz in a circuit (or 16F648A at 4Mhz) to control I/O (mainly an LCD and 3 or 4 buttons).
For this design I MUST use RS232 communications at 9600bps (I must avoid Crystal and I have no external clock source).

Do you think that Software USART routines (bitbanging) will be reliable at this rate? I know that temperature effects can alter PIC's internal oscillator precision, but what I want to know is : Does anyone used this solution in a real work and had problems? can you give your feedbacks please?

You might try reading my PIC tutorials?, the internal oscillator is absolutely fine at 9600 baud, and even higher if required - but I generally use 9600 baud as it's usually plenty fast enough anyway. I've been using software UART routines for a LONG, LONG time, and never had a problem.

 

[Mike - K8LH]

Devices with the 1% tolerance factory calibrated INTOSC work fine. As you mentioned, the big qualifier is temperature.

 

[octal]

Thank you Nigel ...
I'm already using it without problem at 9600 (I'll not go beyond) and 2400. but my fear comes from the Microchip Data sheet. they says that the drift can be as 10% between -40 to +85°C ... and this tolerance rate I think is too high to be acceptable for 9600 bps.

I'll continue my tests.

regards
Octal

 

[Nigel Goodwin]

Thank you Nigel ...
I'm already using it without problem at 9600 (I'll not go beyond) and 2400. but my fear comes from the Microchip Data sheet. they says that the drift can be as 10% between -40 to +85°C ... and this tolerance rate I think is too high to be acceptable for 9600 bps.

I don't think 10% is likely to be a problem anyway? - bear in mind it's only got to remain within a whole bit space for 8 bits, then it re-syncronises.

 

[Tomble]

Hi, sorry for the momentary vague threadjacking, but I happened to be thinking about software UARTing myself today- just the receiving side though. I figure it's relevant enough here (sorry if not)

One of the things I couldn't quite fathom was how you're supposed to tell for sure which bits are the framing (start and stop) bits compared to data. IE, what happens if you start up listening in mid-transmission, or somehow get lost, how do you know where to resynchronise?

Having just read your tutorial on RS232 (really I'm more interested in midi but it's still async) I feel none the wiser on that Is it simply not possible without a long break in transmission?

 

[Nigel Goodwin]

Doesn't matter if it's a software or hardware UART, the only way it can syncronise is to correctly find a start bit when it's looking for it. So the only guaranteed way is to have a break longer than a complete word.

Like you say, MIDI is similar, and there's a LOT of PIC MIDI projects on the net.

 

[Leftyretro]

Hi, sorry for the momentary vague threadjacking, but I happened to be thinking about software UARTing myself today- just the receiving side though. I figure it's relevant enough here (sorry if not)

One of the things I couldn't quite fathom was how you're supposed to tell for sure which bits are the framing (start and stop) bits compared to data. IE, what happens if you start up listening in mid-transmission, or somehow get lost, how do you know where to resynchronise?

Having just read your tutorial on RS232 (really I'm more interested in midi but it's still async) I feel none the wiser on that Is it simply not possible without a long break in transmission?

Trying to first sync up in the middle of a continous stream of async serial data is not a easy task. One can end up processing a continous stream of grabbled data until there is a pause (stop state) of at least one full character time frame. Looking first for a stop state of long enough duration before triggering on a start bit is one way.

Lefty

 

[Tomble]

Fair enough, I guess that's the way to go then. Thanks guys
(/Tomble returns thread to its rightful owner )

 

[donniedj]

Why so many replies.

The answer to a general internal OSC for lowly 9600bps soft USUART is YES.

Now what truely matters is for the developer to test in developer's environment because variable voltages, temps, and error % will be the true determining answer to the question.

In short do it regardless of what we say.

 

[Sceadwian]

Using extra stop bits can help, most PC's will sync with an external clock if it's slightly off. Depends on the UART. Some do it every byte, some just do it after a small pause in the transmission. So you could probably send data at really high bit rates as long as you don't completly saturate the available bandwidth.