Re: [ECOS] Additional Clock on AEB

[Hugo Tyson <hmt at cygnus dot co dot uk>]

k e <ndgipper@yahoo.com> writes:
> Question about additional clock on AEB.

> I'm trying to create a second clock that will tick every 20ms.  I'd like
> this clock to attach to an alarm.  Below, I've modified the appropriate
> portion of the simple-alarm.c example program to have an alarm every .4
> sec.  I've also added a print to the loop that reports the current state
> of the alarm counter.

> The alarm counter that I think I've attached to the new clock is not
> clicking.  The reported value is always 0.

> Am I missing something about actually STARTING the new clock.  It seems
> like the clock never gets going.

This is kind of it; you have instantiated a clock and attached alarms to
it, all well and good, but you have not done anything to make your clock
actually be ticked.


I'll explain the class relationships a bit:

A counter is expected to be "ticked" [ie. counter->tick() called or void
cyg_counter_tick(cyg_handle_t counter); in the KAPI] by some external
means.  It is up to the user to provide this.  The "ticks" need not be
regular nor frequent - eg. a shaft-encoder interrupt could do this, or
simply a function call from some idle loop or server-loop.

A clock is simply a counter with an associated resolution that you can set
or get.  Nothing else is added.  Setting the resolution has no effect
whatsoever on how fast the clock ticks - if it ticks at all; the owner of
the clock must see to that.

Alarms are associated with counters or clocks; an alarm waits for a counter
(or clock) value to get to a certain point then it does something for you,
perhaps repeatedly - but only if the counter ticks.

Now, all this is pretty useless for doing anything with time.  So, there is
one special clock instantiated by the system, which is ticked by a periodic
interrupt, and whose resolution reflects how often that occurs.  That's the
system real time clock.  [Cyg_Clock::real_time_clock or cyg_handle_t
cyg_real_time_clock(void); in the KAPI]

Setting the resolution of the system real time clock will simply make the
resolution be wrong - the rate at which ticks occur will not change.  Put
another way, the resolution is for information only, it is NOT a control
input.

You can associate alarms with the real time clock and they will behave as
you expect, with centi-Second ticks (usually - but read the resolution and
do sums if you want really portable code.)

The reason it's arranged like this is: there could be hardware platforms
where there is no periodic interrupt, so we cannot support a real time
clock.  But we do want to make available all the facilities for counters
and clocks and alarms, so that a project based on that hardware can add
whatever means it likes to get a real time clock, such as a proper
progammable periodic external interrupt, or even just a dumb astable
attached to an interrupt line, or a polling call from time to time from the
application code.

That's why creating a clock does not automatically make it tick.


Solutions?  Three, of which the third is the realistic one:

1) Select a hardware interrupt source such as a counter/timer which is
   otherwise unused, program it to interrupt periodically, and write an ISR
   to reset the timer and acknowledge the interrupt and request the kernel
   to call the DSR.  Write a DSR which calls counter->tick() or in the KAPI
   cyg_counter_tick(cyg_handle_t counter).  That's what the kernel does for
   the system real time clock.

2) Attach a periodic repeating alarm every 2 ticks (2cS == 20mS) to the
   system real time clock, and have that alarm handler call
   cyg_counter_tick() on your counter.  This is ridiculously inefficient,
   but it's worth mentioning for illustration.

3) Do not bother creating your own clock, just create your alarm associated
   with the counter of the system real time clock, and live with the fact
   that ticks are 1cS not 2cS as you first wanted.

> Or if it does, the alarm counter isn't clicking.  OR is isn't something
> possibly as nasty as I can't have a clock that ticks FASTER than the
> system clock.... If so, that's ugly.  Isn't the AEB capable of having
> more than one clock going?

Not unless you write some code ;-)

But you can have lots and lots of one-shot and repeating alarms all at
different rates and times and so on, all driven by the system real time
clock, which is what I suspect you really want.

In other words, eCos supports mapping many different (repeating) events
onto one clock, working out which will be next, calling them in the right
order and so on, but it does not support mapping many different frequencies
of the underlying clock class onto one hardware counter/timer interrupt.

	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.