About using internal oscillator for soft serial comm?

[octal]

Hi,
I plan to use a 18F1320 with its Internal oscillator at 8Mhz (or 16F648A at 4Mhz) in a circuit 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 SUSART routines 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
_________________
http://www.pocketmt.com the GLCD Font Creator home

[Ttelmah]

The 1320, is fine, either with soft serial, or hardware, using the internal clock. provided your temperature range is 'reasonable' (office temperatures say). The allowable total timing error for RS232, depends on your word length etc., but is typically something in the order of 4%. If you assume the other end has 'good' timings, within perhaps 1%, then you can have up to perhaps 3% maximum error at the PIC. The internal oscillator on the 1320, manages a guaranteed +/-1% accuracy at 25C, degrading to +/-5% over the 'commercial' temperature range (-10 to +85C). I have tested a few of these oscillators, and have yet to find one that exceeds +/-2.5%, over the range 0C, to 50C, and so would consider this to be a happy range to use. If the part has to go into something experiencing a wider range than this, then problems become increasingly likely.

Best Wishes

[SherpaDoug]

Also look at the voltage range. I think the internal oscillators are good at 5V, but the spec is quite wide at 3.3V or less (maybe the opposite).

If you can individually adjust the speed you can use 9792 baud or 9408 baud (9600 +/- 2%), the software UART wont care.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[libor]

FYI: The 1320 has an enhanced hw USART (EUSART). It has a self-calibrating baudrate measuring function. All you have to do is turn this function on, and send a 0x55 (0101010101) to it. It will precisely calculate the proper baudrate counting register (BRG) value matching the sending device's baudrate independently of the actual oscillator clockrate in your device. You can store this calibrated value in EEPROM for having a individually tuned device afterwards, or even repeatedly recalibrate it during normal operation (or only when your device fails to communicate because of a possible baudrate mismatch)
There are many options, you might want implement this feature somehow in your product.

BTW: Why don't you want to use the hw USART ? This will result a much simpler code.

[octal]

[ckielstra]

[octal]

Hi,
yes I agree with you answer ckielska, my anwser was a bit ambiguous. In fact I offer to the user the choice between using inverted or true mode by pulling one pin High/Low. So Hardware UART can not be used If it was to be interfaced only with users programmed mcu's, things would be easier, but it's intended to be smart enough to accomodate any soft config. Some users asked for that because they use, with their compilers, libraries (without source codes) that let them use only true mode, so no way to make it work with my module. It's to avoid such problems that I want to give the possibility to define signals inversion mode using a special pin.

Regards
Octal
_________________
http://www.pocketmt.com the GLCD Font Creator home

[inservi]

Hello,

For TTL level inverting, a simple MOSFET transistor and probably one resistor is need. So with only two MOSFET , (one for TX and one for RX) you can give to user both inverted and not inverted at the same time (with two connector).
dro.
_________________
in médio virtus