Oscillator question (LP-Mode)

[MJU20]

In the datasheet for the 16F1827 ( http://ww1.microchip.com/downloads/en/d ... 41391d.pdf ) as from page 299, I see tables with different BAUD rates with different Xtal's. "BAUD RATES FOR ASYNCHRONOUS MODES"

I want to use a PIC that consumes as less power as possible, and then I see the 32khz XTAL configuration (LP mode) as the most power efficient..

My question is if the 32khz crystal can generate a decent 9600baud signal and a 1-wire signal for a DS18B20?
Maybe I need to make a leap to a 1Mhz, or even 4Mhz crystal but in these modes the chip consumes more energy.
How does Flowcode handle the baudrates?

Do they really mean a 32Khz or a 32.786kHz (Page 55 5.2.1.5 TIMER1 Oscillator), elsewhere in the datasheet them keep on calling it a 32Khz Xtal

And, how can I set the project options to 32khz?

[BenR]

Hello,

The baud rate calculation on an 8-bit PIC looks like this.

BAUDTICKS = (((ClockFrequencyHz / BAUD) - 2) / 4)

For a clock of 32.768KHz or 0.032678 in the project options you can't really get 9600 baud.

32.768KHz = 0 = NO
1MHz = 25 = YES 2.1% bit error
4MHz = 103 = YES 0.6% bit error

For 1-wire I've just been playing with it and for an 8-bit PIC you really need at least 20MHz for it to work reliably.

There is an I2C OneWire master device I am looking at supporting and so this might be an option for slower devices.

Instead of running so slowly, what about running fast and then powering down and sleeping for a bit? Then either using a timer or an edge driven interrupt to wake back up again.

Some devices also feature an internal oscillator that you can switch to fast and slow as required so you could keep awake and just speed up to do the comms and then speed down to power save. The IntOsc component should help with showing what settings are available on your device and the C code to call to acheive the speed.

[MJU20]

Thank you BenR,

My goal is to get a certain low power PIC sample a temperature, compare it with other measurements, and if the difference is a certain value, send it via UART to an other device.
Then the PIC must go to sleep for a while and with the internal watchdog timer wake up and perform the action above.

I've tested the sleep/wake up feature and this works fine. The time the PIC sleeps isn't critical (max time was something like 2 minutes).

My idea was to use as less power when the PIC is awake by reducing the oscillator speed.
But the way you put it, as soon as the actions are done, the faster the PIC can go back to sleep, is logical.

I've never used the high/low speed oscillator settings in a project.
I've made an example Flowchart with the OSC settings but I don't know if this will work.
When reducing the speed I get the message that the chosen speed doesn't reflect the speed in the project settings.

Could you please review the attached file and look if I get the picture?
If this would work?

The file isn't somewhere near what I want to make, but is just an example for what I understand it must do to change the speed.

Thanks again

TestOscillator.fcfx

(8.51 KiB) Downloaded 120 times

[BenR]

Hello,

That looks pretty good yes. The only problem I see is this.

When at full speed 32MHz timings and things will be correct as that's the speed that Flowcode knows about.

When you slow down to 31KHz delays will become much longer then they should be because the device is now running much slower than it was before.

So your delay of 100s would actually take (32000000 / 31000) or about 1032 * longer.

So if you want a delay of 100s at the slow speed then instead use a delay of 97ms.

[MJU20]

Hello,
That looks pretty good yes. The only problem I see is this.
Snip..

Thanks BenR
So when I tell the oscillator that (for non time critical time features), he can slow down, he will, and reduce it's power?
What if I slow it down and put it asleep. Will the watchdog timer increase it's time also?

I want to combine these settings to reduce power during comparison of temp-readings and decide to wake up a tranceiver and send the new data.
But is this good practice? Because at higher speeds the calculation will be done much faster and the PIC can go to sleep much faster.

Will this really have an noticeable effect on the power consumption?
The way I see it, the moment the clockspeed must be high enough is when the 1-wire is sampled and the data send.
The calculation is between them and maybe the reduction of the clockspeed isn't worth the while (power consumingly speaking)?

Maybe these seem strange questions but I want to test for the first time in my life a project that needs to run as long as possible on a single battery.
Nano-power if possible

[chipfryer27]

Hi MJU

As per my reply to your v8 post, the PIC automatically switches to it's 31KHz Osc when you issue a sleep command (used by WDT) so your ratio of sleep / awake could negate any concerns of power consumption running at a higher speed when awake.

Just for the sake of argument a clock running at 32,000,000Hz is a thousand times faster than one running at 32,000Hz.

Regards

[MJU20]

Hi MJU

As per my reply to your v8 post, the PIC automatically switches to it's 31KHz Osc when you issue a sleep command (used by WDT) so your ratio of sleep / awake could negate any concerns of power consumption running at a higher speed when awake.

Just for the sake of argument a clock running at 32,000,000Hz is a thousand times faster than one running at 32,000Hz.

Regards

Thanks Chipfryer,
The fact that in sleep mode the power consumption is much lower is indeed caused by lower clock frequencies.
But my question, after the answers from BenR is if changing the clock frequency during periods that the comms aren't active (1-wire or RS232), changes much for power consumption.

So let's say I need the 1-wire component to sample something. The osc. speed needs to be fast enough to get communication working.
After this sample, the sampled value needs to be calculated and compared.
During this phase, is it necessary to lower the clockspeed to save power?
If the compared value is known, possibly the RS232 needs to be activated and the PIC needs to power a tranceiver.
So if this tranceiver is needed the clockspeed must meet it's lowest value to guaranty the BAUD rate needed.

So lower the clockspeed is only necessary during comparison and calculation which takes only a small amount of time.
Maybe this is not really the way to save power?

[chipfryer27]

Hi

Personally I don't know the actual power difference between running at say 32MHz vs 8 (or such like). Sounds like a good experiment though to obtain empirical. Can't imagine it being too drastic over a few instructions though.

As you will only be running slow for a calculation or two, i don't think it would be worth the bother. By the time you slow down and do a calculation, the faster clock would already be wearing its pyjamas

Regards

[BenR]

If your using a one wire temperature sensor then at the maximum sensitivity of 12-bit it can take up to 800ms for a temperature conversion.

So you could do something like this.

Start
Go to high speed
Initialise 1-wire temperature conversion
Go to low speed
Wait 800ms
Go To High Speed
Collect temperature reading
Perform other communications
Go to low speed
Wait for a predetermined duration
goto start

This way you are at high power mode when needed but at a low power state during the inactive waiting times.

If you sampled say once per minute and you can reduce the high power time to say 0.5 seconds then your battery should last up to 120 times longer.

[chipfryer27]

Hi Ben

Good point, I'd forgotten about the one-wire aspect

Regards