[ECOS] Changing CPU clock frequency on the fly

[Gratian Crisan <nelu at iv dot ro>]

Hi,

we are running eCos on a custom board based on AT91FR40162 ARM cpu from Atmel. 
(we use eCos target: eb40a). 
	I am trying to do dynamic frequency management, mainly for power management 
reasons. The board has a programable oscillator with an output frequency 
ranging from 1KHz to 68MHz. 
	Browsing trough eCos mailing lists I've stumbled upon an email in which Gary 
Thomas wrote that eCos isn't set up for this and it may not be a good idea.
My question is: what are the main reasons why this may not be a good idea?
What needs to be changed in order to implement dynamic frequency management in 
eCos. So far I've dug up the following things that need recalculation/setup:
- flash wait states (EBI wait states);
- recalculate main heartbeat CYGNUM_HAL_RTC_PERIOD to keep it at 100Hz;
- setup the serials to account for CPU clock frequency change;

Any suggestions?

Nelu

On Wednesday 01 October 2003 01:03 pm, Gary Thomas wrote:
> On Wed, 2003-10-01 at 06:55, Daniel Lidsten wrote:
> > Hi,
> >
> > Is there any way of changing the system tick during runtime? I have made
> > a quick test by letting an application provided variable be used when
> > setting the decrementer in the HAL_CLOCK_*-functions. This will make the
> > system generate tick more or less often depending on the value set.
> > However, the drawback is that the system expects that we have a
> > heartbeat of 100Hz and that will differ when changing the decrementer.
> > Is there any way to get around this? Is there any way to change the
> > CYGNUM_HAL_RTC_DENOMINATOR during runtime so that the change will affect
> > every file that use it? I want to be able to have 10000 ticks per second
> > but then i also need to let the system know that we have 10000 ticks per
> > seconds so that not all timeouts and stuff gets all confused.
>
> Are you sure that you want the system clock to run at this high of
> a frequency?  That means that every 100us you are going to execute
> the clock handler, which oft times ends up running the scheduler, etc.
> Unless you're on a blazingly fast platform, this seems like too much
> overhead.
>
> If you just want higher granularity timers or interrupts, how about
> using a second timer for this purpose?
>
> As for changing the clock frequency on the fly, I don't think eCos
> is set up for this, nor (IMO) is it a good idea.
>
> Maybe if you explain a little more the *why*, we can give you some
> ideas on the *how*.
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss