PIC16LF1823 - minimum component Question

[Docara]

Hi

Working on my first big boys PIC project and the BOM ogres are playing with my nuts, so I need to massively cut down on components.

If I use the 16LF1823's internal oscillator, in the real world, is it reliable for comms up to (hopefully) 1M when there are 30 slave devices on the bus (RS485, master is crystal controlled)

Thanks

[NorthGuy]

Should be Ok, but probably not over full temperature/voltage range. Look for internal oscillator characteristics in the datasheet. You need 2% accuracy or better.

[fmkit]

 14% accuracy  clock for UART ok.

[Docara]

Thank you both

[woofy]

Even with a xtal on the master, I would advise caution. With 30 RS485 nodes, this sounds like an industrial application where the nodes may be subject to wide temperature variations.
I would ignore the datasheet headline 1% typical, page 355 (rev E) indicates 5% over temperature/voltage. That places the final sample point perilously close the boundery of another bit.

If this is going to be deployed in human comfort temperatures, then you may be OK.
On the other hand if this is an industrial product, bite the bullet and use a xtal.

[Ian.M]

Yes.  Assuming 8N1 framing, the middle of the stop bit is 9.5 bit times after the leading edge of the start bit.  That means it *will* fail if the baud rate mismatch exceeds 5.263%.  If you are using 9 bit  framing (e.g addressable UART modes), the mismatch limit is 4.762%. Pushing too close to the limits is asking for trouble as you need margin for shifted timing due to threshold variations with respect to risetime, master clock error (e.g typical crystal with untrimmed load capacitance +/-100PPM = +/- 0.01%) and sampling point quantization to core instruction cycle, adding +/- 1 Tcy jitter.

[Docara]

Thank you Ian.M and Woofy for a thorough explanation guys that really is appreciated.

The application is a low budget lighting system I have to do for a narrow boat, the run is approx. 20m straight (under the roof). I have assumed a worse case working temperature of 30deg though probably closer to 25deg when the lights are to be used. The working voltage is 12Vdc

I made a decision over 2 years ago for 'something' which is know biting me very hard, and which I have to pay personally to resolve. Damn LV volt drops and 20mm conduit!!!

I'm presuming by dropping the speed down will resolve the close margin if there is a problem?

Thanks again chaps

[Ian.M]

Reducing the baud rate helps at the edges because the risetime is a smaller percentage of the bit time, but if its so close that the risetime is affecting it you are probably in deep doo-doo anyway as changes in the dielectric constant of the cable insulation e.g. due to moisture adsorption could have sufficient effect on the capacitance per unit length to push you over the edge!

Also there's the issue that if your clock error exceeds half the max baud rate mismatch, slave to slave comms will be unreliable as slaves with clock errors at the opposite ends of their tolerance bands will have excessive baud rate mismatch. That wouldn't be an issue except for the risk of corruption of the next byte after one received with a framing error due to mis-synchronisation, so you need to make sure the receiver code discards the whole packet, until the line has been idle for at least one byte time to avoid the risk of the corruption being mistaken for the start of a packet from the master.

It may be worth looking at ceramic resonators to reduce your BOM cost.  Many are available with integrated caps so one part instead of three, and holding 0.1% clock frequency tolerance shouldn't be a problem.

A low hardware cost approach might be to auto-baud off the master bit timing on each powerup, at a relatively low baud rate (to get the fine resolution) then adjust each slave OSCTUNE accordingly to bring the baud rate divisor in the SPBRG SFR pair back to nominal.

See datasheet sections: 26.3.1 Auto-Baud Detect, and 26.2 Clock Accuracy with Asynchronous Operation.

[NorthGuy]

14% accuracy  clock for UART ok.

Why 14?

The typical uart transmission takes 10 bites - start (0), 8 bits of data, and stop(1), each of which takes 1 baud.

Not counting the stop bit, the worst byte is the last data byte which is transmitted between 8.0 and 9.0 baud distance from the beginning of the byte. The best way is to sample it in the middle 8.5 baud from the beginning.

If you're by 14% earlier, you'll be sampling at 8.5 - 14% = 7.31 bauds from the beginning, which is the previous byte. If you are 14% late, you'll be sampling at 8.5 + 14% = 9.69, which is the stop bit.

The maximum you can wonder away is 0.5 baud - this will keep you between 8.0 and 9.0. Thus you need 0.5/8.5 = 5.8% accuracy.

If you want to avoid frame errors, you need to sample stp bit correctly too - from 9.0 to 10.0 baud. Ths you need 0.5/9.5 = 5.2%.

Since both the receiver and transmitter may have errors, each of them is entitled only to half of the error. This guarantees the combined error to be satisfactory. Thus, the maximum error is 2.6% for each side.

Then there are transitions between bytes and jitter, which is not important at 9600 baud, but the faster you go, the more important it becomes. Say, if the rise/fall time is 50 ns, then at 5M baud, your target sampling interval for the stop byte is not from 1.8 to 2.0 us, but rather from 1.85 to 1.95 us. This doubles the clock accuracy requirement.

[Docara]

I have been looking at the OSCTUNE function and auto baud rate in the datasheet.

The datasheet states that the internal oscillator is factory calibrated to 1% @16MHz, later on it states 2% then, like you stated, 5% very confusing!!.

Thank you for you guidance, based on your replies, I have decided to utilise the internal HFINTOSC BUT will incorporate the provision to include a resonator on the PCB just in case. I reckon that because I am so close I should be able to use Auto Baud & OSCTUNE functionality I should be able to maintain a level of accuracy to receive 3 possible 4 frames of data at very sporadic intervals.

My logic is that by using the internal oscillator I have programmable control over the base clock frequency for course control and the ability to trim the baud rate via OSCTUNE.  I can implement either/both the calibration during the 'proper' transfer of data or more than likely I will carry out a periodic calibration check when the system is first tuned on and then running, I might even use the on die temp sensor to invoke a calibration cycle.

Thanks again

[fmkit]

I was wrong about UART clock