[ECOS] Change system tick during runtime

[ECOS] Change system tick during runtime

[Daniel Lidsten]

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.

Regards, Daniel Lidsten

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

Re: [ECOS] Change system tick during runtime

[Slawek]

Hi,

undef CYGNUM_HAL_RTC_DENOMINATOR
and define it as a variable (in any of the global .h files).
The compiler shoud do the rest.

-- 
Slawek Piotrowski

----- Original Message ----- 
From: "Daniel Lidsten" <Daniel.Lidsten@combitechsystems.com>
To: "eCos Discussion" <ecos-discuss@sources.redhat.com>
Sent: Wednesday, October 01, 2003 2:55 PM
Subject: [ECOS] Change system tick during runtime


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.

Regards, Daniel Lidsten

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




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

Re: [ECOS] Change system tick during runtime

[Gary Thomas]

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

[ECOS] Changing CPU clock frequency on the fly

[Gratian Crisan]

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

Re: [ECOS] Changing CPU clock frequency on the fly

[Bart Veer]

>>>>> "Nelu" == Gratian Crisan <nelu@iv.ro> writes:

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

This sort of thing is possible, see
http://www.hpl.hp.com/techreports/2003/HPL-2003-81.html
Most of eCos does not care whether the processor is running at 1MHz or
1GHz, as long as there are enough cpu cycles to meet the application's
requirements. However you do have to be careful about a few things.

First, you have to check all the hardware being used to see how they
might be affected. You have already identified the flash and the
serial ports, there may be other devices as well. This sort of thing
depends entirely on the hardware and what bits of it are actually used
by your application.

Second, clock interrupts should happen at a constant rate (typically a
100 Hz) irrespective of the cpu frequency. These clock interrupts are
what tell eCos how much time has elapsed, so they are used for e.g.
TCP/IP timeouts. You will want to look at the HAL_CLOCK_INITIALIZE(),
HAL_CLOCK_READ() and especially HAL_CLOCK_RESET() macros appropriate
for your platform, and how these are used by the kernel's clock.cxx
module. At a guess, inside HAL_CLOCK_RESET() you'll want to scale the
period argument to compensate for a reduced cpu frequency.

Note that I think Gary's message was referring to changing the clock
interrupt frequency rather than the cpu frequency. I agree with him
that this is a bad idea, eCos is not designed to cope with that sort
of thing.

Third, you may want to be careful about exactly when you change the
cpu frequency. If you drop from 68MHz to say 10MHz halfway between
clock interrupts and don't adjust the interrupt clock, you are
introducing drift. Either manipulate the hardware timer that generates
clock interrupts at the same time as you change the cpu frequency, or
look at changing the cpu frequency in e.g. a kernel alarm function
which will be called shortly after a clock interrupt and do another
RESET() in there.

Finally there may be code which "knows" about the cpu speed,
especially inside device drivers. For example if the driver must wait
n microseconds between touching two hardware registers, that will
usually be implemented by either a spinning loop or an invocation of
HAL_DELAY_US(). For such small delays you cannot use higher-level
functionality like kernel alarms. Usually it will not matter much if
the cpu is running slower than expected, you are just giving the
hardware some extra time to settle down. However some drivers may be
more sensitive to exact timing. I suggest looking through the various
drivers used for your platform, there may be some obvious code that
will need tweaking.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts
`

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

Re: [ECOS] Change system tick during runtime

[Nick Garnett]

"Daniel Lidsten" <Daniel.Lidsten@combitechsystems.com> writes:

> In my system i want to run a thread at regular intervals since it is a
> control thread. It can be every 1ms but also every 50ms. Since i have to
> run the thread faster then i can setup an alarm in the default
> configuration where 10ms is the tick rate then i thought that perhaps i
> could let the system generate ticks more often. This is why i altered
> the tick generator.

To do this you would still only need to run the system clock at
1000Hz, not the 10000Hz you mentioned before. 1000Hz should be
doable on all but the slowest targets. You need to change the period
and denominator in the HAL to do this. On some targets the period is
calculated from the denominator, so you only need change the one
value. I added a new section to the HAL documentation a few weeks ago
describing how to do this.

To make the thread run at different rates at different times you
should then just change the trigger/interval times of the alarm, not
the frequency of the interrupts.

All time in eCos is based on the clock interrupt frequency, so
changing it would upset other alarms, network timeouts and the
system's notion of the passage of real time. It is not a good idea to
do this.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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

RE: [ECOS] Change system tick during runtime

[Gary Thomas]

On Wed, 2003-10-01 at 07:15, Daniel Lidsten wrote:
> > > 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*.
> 
> In my system i want to run a thread at regular intervals since it is a
> control thread. It can be every 1ms but also every 50ms. Since i have to
> run the thread faster then i can setup an alarm in the default
> configuration where 10ms is the tick rate then i thought that perhaps i
> could let the system generate ticks more often. This is why i altered
> the tick generator.
> 
> In your probosed solution then i should setup a HW timer to generate an
> interrupt every time i want to run the thread and then let the interrupt
> DSR post a semaphore or some other trigger mechanism. Did i understand
> it right? Is this the best way to accomplish the thread trigger?
> 

Yes, this is the idea.  It could be a periodic interrupt+thread, or if
your period varies, just have the control thread set it up and wait for
the appropriate time to elapse, then have the interrupt (DSR) wake up
the control thread.  This would be much better than trying to have the
whole system clock running at the higher frequency.

-- 
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

RE: [ECOS] Change system tick during runtime

[Daniel Lidsten]

> > 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*.

In my system i want to run a thread at regular intervals since it is a
control thread. It can be every 1ms but also every 50ms. Since i have to
run the thread faster then i can setup an alarm in the default
configuration where 10ms is the tick rate then i thought that perhaps i
could let the system generate ticks more often. This is why i altered
the tick generator.

In your probosed solution then i should setup a HW timer to generate an
interrupt every time i want to run the thread and then let the interrupt
DSR post a semaphore or some other trigger mechanism. Did i understand
it right? Is this the best way to accomplish the thread trigger?

Regards, Daniel Lidsten

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