[ECOS] Additional Clock on AEB

[ECOS] Additional Clock on AEB

[k e]

> 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. 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?
> Here's the modified protion of the example
> program....
> 
> 
> /* alarm_prog() is a thread which sets up an alarm
> which is then
>    handled by test_alarm_func() */
> static void alarm_prog(cyg_addrword_t data)
> {
> 
>   cyg_clock clock1;              // the additional
> clock
>   cyg_resolution_t res_clock1;   // the resolution
> for the additional clock
>   cyg_handle_t hclock1;          // handle to the
> additional clock 
>   cyg_handle_t test_counterH, system_clockH,
> test_alarmH;
>   cyg_tick_count_t ticks;
>   cyg_alarm test_alarm;
>   unsigned how_many_alarms = 0, prev_alarms = 0,
> tmp_how_many;
> 
> 
>  // this creates the additional clock with 20ms
> freq.
>   res_clock1.dividend=20000000;
>   res_clock1.divisor=1;
>   cyg_clock_create(res_clock1, &hclock1, &clock1);
> 
>   cyg_clock_to_counter(hclock1, &test_counterH);  //
> point the counter to the new clock
>   cyg_alarm_create(test_counterH, test_alarm_func,
>                    (cyg_addrword_t)
> &how_many_alarms,
>                    &test_alarmH, &test_alarm);
>   //have it fire ever .4 sec, right???
>   cyg_alarm_initialize(test_alarmH,
> cyg_counter_current_value(test_counterH)+20, 20); 
> 
>   /* get in a loop in which we read the current time
> and
>      print it out, just to have something scrolling
> by */
>   for (;;) {
>     ticks = cyg_current_time();
>     printf("Time is %llu\n\r", ticks);
>     printf("Clock counter is
> %lld\n\r",cyg_counter_current_value(test_counterH));
>  // for debugging
>     /* note that we must lock access to
> how_many_alarms, since the
>        alarm handler might change it.  this involves
> using the
>        annoying temporary variable tmp_how_many so
> that I can keep the
>        critical region short */
>     cyg_scheduler_lock();
>     tmp_how_many = how_many_alarms;
>     cyg_scheduler_unlock();
>     if (prev_alarms != tmp_how_many) {
>       printf("  ---> alarm calls so far: %u\n\r",
> tmp_how_many);
>       prev_alarms = tmp_how_many;
>     }
>     cyg_thread_delay(30);
>   }
> }
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: [ECOS] Additional Clock on AEB

[Hugo Tyson]

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.