Multiple clock sources and clock switching

[blowtorch]

OK so I have some questions relating probably more to PIC architecture than coding specifically in CCS C so apologies in advance. I am a relative newbie and to date have always used the internal oscillator for projects, but I now have a requirement for more accurate timing for certain sections of the code, so a crystal is in order. PIC used is a PIC16LF18877, on the latest version of CCS as of writing, application is a battery powered device with 128x64 display. Voltage is stepped up from 2 x AA to 3V3 when awake.

All working beautifully, on the internal oscillator running at 16MHz. But I am not happy with the consumption, so I am now seeking methods to lower overall consumption. Gone through a lot of optimisation on the external parts of the circuitry...Now seeking ways of lowering the PIC itselfs consumption.

I have studied the datasheet, on switching clock sources, as well as the sections at the back where the specifications are detailed in terms of time to get PLL ready etc. Also spent considerable time reading the forum, on various posts relating to switching clock sources etc.
I am seduced by the promise of lowered power usage when using a 4MHz crystal in XT mode, max 600uA at 3V compared to 2.6mA when using HFINTOSC at 16MHz per the datasheet. What I am exploring, is to run on a 4MHz crystal in XT mode for certain portions of the code (low power and accurate timing), but when driving the display / navigating menus etc , I wish to increase the clock speed to have fast display refreshes.

So, my options appear to be running off the 4MHz crystal for the timing part, and then when writing to the display:
(1) switch the clock source to the internal oscillator at say 16MHz or 32MHz
(2) or keep the clock from the crystal but enable PLL to get a 16MHz clock

Which is better? The PLL lock time is specced at 200us, the oscillator start up period timer is 1024 TOSC. Switching clocks in my case is not super critical timewise, as when I need to switch, it’s basically because the user has pressed a button to enter the menu etc. I can see that if entering the critical timing mode, I should poll the Oscillator ready bit to ensure the clock has actually switched, although again this switch would be initiated in the human domain, not the mcu domain so should be fine timing wise.
I am ok with the compiler “#use delay” and the implications thereof in terms of delays, and the effects of switching clock speeds on timers etc. I _think_ I have all that covered.

What else am I missing? I read stuff in the datasheet such as “If the PLL fails to lock the FSCM will trigger...”. Terrifying! What would cause this?

Are there other gotchas I should be aware of?

[temtronic]

There's an early Microchip Application Note about PICs and clocks and batteries that you should find and read( has to be on their website). It should be a'must read'for all that use batteries. It's in a hardcopy book of apnotes ,here, somewhere....
From my aging memory... it may be better to run fast and get stuff done, than slow and save power.
From my real life with remote control systems.. use a bigger battery. Yes I know everyone wants itty bitty ultra small stuff BUT usually the next size battery gives 2X power,or more. Also batteries HATE being too hot and too cold. Most forget that and wonder why does it fail outside ,in winter, when it worked fine in the warm,cozy lab?
Also the TYPE of battery is important. Some are designed for high current-low time use, others.. low current 'forever'.

Jay

[Ttelmah]

Also, as a comment, even 4MHz, is faster than many displays. Most
are limited in their refresh rate by the LCD technology, so text displays
for example can't be updated faster than about four times a second and
still display reasonable values. Are you sure you really need to go faster
than the 4Mhz?.

[blowtorch]

All good points. I am using 2 x AA, thinking about moving to a single lithium cell. The 18650's are cheap but bulky, the flat cells are great but expensive...but that's another discussion!

Screen updates in terms of constant refresh is not an issue. But when going into the menu, the display is cleared, and a whole screen full of info is then presented. Lets say the users scrolls down and selects an option, then another new screen of info is presented. At 4MHz one can see the lag (It's not huge, but noticeable to my eye). I have already optimised my library for this display (it's based on the CCS GLCD library) . Anyway, at 16MHz the display update is to the eye instantaneous.

My one dev board I run without a crystal, and it's of course real easy to play around with different speeds using the internal oscillator. I have a wrapper for the menu which pushes the speed to 16MHz.

In actual, non-menu operation 4MHz is quite satisfactory.

[blowtorch]

OK after some more testing I am happy with menu operation at 4MHz, but not the main loop. During normal, main loop execution I need to react to various triggers, and display info on the screen. These triggers are spaced wide enough apart to manage, but other events need servicing, so I can't tie up the processor for too long in a display routine. Anyway, with respect to the display, it's printf that's the culprit. The following example 2 printf statements take around 70ms to execute at 4MHz. It's not the actual writing of data to the display, it's the formatting of the data!

[temtronic]

this....

[blowtorch]

Sorry Jay, to illustrate the point I created some dummy code just to show the printf statement. I edited the post to correct the declaration.

I use a 32 bit int, holding time in milliseconds. The printf with %7.3w then displays it correctly formatted.

[gaugeguy]

The printf can be split up so that each part takes much less than 8ms at 4MHz. The biggest savings would probably be doing your own BCD conversion function instead of having printf doing the interger to ASCII conversion.

[dluu13]

[Ttelmah]

The key point about working with BCD, is that you can just use the
nibbles, without any divisions - when using standard printing involves
loads of /10 divisions whch are slow. It does though mean you have to
code your own maths....

[blowtorch]

OK that gives me something else to consider. I assumed (!) that the printf function would have been coded so efficiently I would not be able to improve on it. Never actually looked at the code.

It would have been nice to store the numbers as BCD, then one could have a very fast display function, but it just about doubles the memory requirement.

Edit: or use packed BCD...

[Ttelmah]

Exactly.
Remember in particular that the PIC has a single cycle 'swap' instruction
that swaps the high and low nibbles of a byte. Makes getting at these
much more efficient.
Printf is coded efficiently, but /10 is not easy.

[temtronic]

hmm, wonder if /2,/2,/2,/2,/2 is faster than /10 ?
My PIC PC is 'down for service'....

[dluu13]

Sorry to hijack, but I must be missing something. Even if you were to make some BCD variables, wouldn't you still have to get them formatted to %u or %d to put it in the string?

Is it the %lw that is slowing everything down?

[gaugeguy]

BCD is much quicker to print in human readable form.
As an example decimal value 1234 is hex 0x04D2.
If you do a BCD conversion to this you get hex 0x1234. Each decimal digit is a 4 bit nibble. This can be printed using %x with printf or converted to characters by adding 0x30 to each nibble.
The BCD conversion can be done with repeated shift, compare, add so no division or multiplication needed.