CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Multiple clock sources and clock switching
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
blowtorch



Joined: 11 Jun 2013
Posts: 35
Location: Cape Town

View user's profile Send private message

Multiple clock sources and clock switching
PostPosted: Wed May 08, 2019 3:26 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed May 08, 2019 4:55 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed May 08, 2019 6:38 am     Reply with quote

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



Joined: 11 Jun 2013
Posts: 35
Location: Cape Town

View user's profile Send private message

PostPosted: Wed May 08, 2019 11:08 am     Reply with quote

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



Joined: 11 Jun 2013
Posts: 35
Location: Cape Town

View user's profile Send private message

Update
PostPosted: Tue May 14, 2019 9:02 am     Reply with quote

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!
Code:

// example of the display code & printf statements, taking 70ms at 4MHz...
#define MAX_ELEMENTS 250;
uint32 gbl_list[MAX_ELEMENTS];
uint8 ele_index;
uint32 timed_at = 123456;  // 123.456 seconds
uint32 time_duration = 100; //   0.100 seconds
gbl_list[0] = 0xF0F0F0F0";

printf(glcd_putc, "Event #%3u X=%lX\nTime  %7.3w\n", ele_index, gbl_list[ele_index], timed_at);
printf(glcd_putc, "Took %7.3w", time_duration);

This of course ties up the processor, in this case for an unacceptable amount of time. The speed of execution scales quite lineally with clock speed, at 16MHz it takes 16ms, at 32MHz 8 ms...

8ms is quite acceptable, but 70 odd ms is definitely not!

I will see if I can optimise the code, maybe split the display code into several separate activities. Otherwise I can go back to the original thought of using different clock speeds for different activities.


Last edited by blowtorch on Tue May 14, 2019 10:06 am; edited 1 time in total
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue May 14, 2019 9:28 am     Reply with quote

this....
Quote:
uint32 timed_at = 123.456; // 123.456 seconds

has me confused, though these dayze, everything seems to..

I'm thinking an unsigned integer should be 123 and not 123point456 (that's a floating point number).
It'd be interesting to see what the listing shows as to what is really stored.

Jay
blowtorch



Joined: 11 Jun 2013
Posts: 35
Location: Cape Town

View user's profile Send private message

PostPosted: Tue May 14, 2019 10:09 am     Reply with quote

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



Joined: 05 Apr 2011
Posts: 286

View user's profile Send private message

PostPosted: Tue May 14, 2019 10:19 am     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Tue May 14, 2019 11:26 am     Reply with quote

gaugeguy wrote:
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.


Unless printf is really that slow, wouldn't this be slowing, since it involves doing a bunch of mods and divisions?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue May 14, 2019 11:39 am     Reply with quote

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



Joined: 11 Jun 2013
Posts: 35
Location: Cape Town

View user's profile Send private message

PostPosted: Tue May 14, 2019 12:40 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue May 14, 2019 1:11 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue May 14, 2019 2:45 pm     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Tue May 14, 2019 2:53 pm     Reply with quote

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



Joined: 05 Apr 2011
Posts: 286

View user's profile Send private message

PostPosted: Tue May 14, 2019 3:11 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group