This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: changing the length of a tick


>>>>> "Tom" == Tom Coremans <tom.coremans@acunia.com> writes:

    Tom> Jonathan Larmour wrote:
    <snip>
    >> The configured resolution has to reflect what the clock
    >> actually does. In this case there is nothing that actually
    >> tells the clock hardware to do anything other than 100 ticks
    >> per second (10000000 ns/tick). It's just that now eCos will
    >> *think* when it got a tick that is 20 ticks per second.
    >> 
    >> Look at how the kernel uses the HAL to configure the real
    >> hardware and do the same thing.

    Tom> I have changed the resolution of the real time clock in the
    Tom> configtool under an option concerning the hal and now it
    Tom> works fine and the tests run correct.

    Tom> Is there a way to do this in the code of your application
    Tom> program?

This depends on the hardware and the HAL implementation. With some
hardware you may be able to invoke HAL_CLOCK_INITIALIZE() while the
application is running to change the behaviour of the system's
real-time clock. It is that HAL macro which is called during system
initialization to get the clock running at the desired frequency. You
would need to combine this with a call to cyg_clock_set_resolution()
to keep things consistent.

However there may be code in various places, for example the C
library, which assumes that the frequency of the real-time clock does
not change after initialization. I have not checked this.

    Tom> And what do you accomplish by the fact that ecos *thinks* it
    Tom> got 20 ticks a second?

The thing to remember here is that eCos does not restrict you to just
one clock. In typical configurations there will be a default real-time
clock provided by the system, ticking at a fixed rate determined by
configuration options, and used to control e.g. timeslicing. If the
target hardware supports more than one physical clock then application
code can instantiate additional clock objects, and you would be
responsible for implementing appropriate interrupt handlers and
generating counter ticks from the DSR. You can then attach alarms to
these additional clocks, as desired. If application code wants to
change the frequencies for these additional clocks then that is fine,
cyg_clock_set_resolution() just provides a way of keeping everything
consistent.

Bart

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]