Feeding the wclock in Céu 3.x

[Matthias T.]

Hi Francisco,

I recently tried to bind Céu's wclock to the system clock of my microcontroller. I do not want to implement the naive approach that feeds the wclock on every tick, e.g. each millisecond, by using

ceu_input(CEU_INPUT__WCLOCK, &dt);

Instead, I would like Céu to let me know when the next wclock tick is actually required. In the old version 1.x of Céu this has been done through a global variable assignment, I think it was something like WCLOCK_NEXT. The latter has been updated by Céu with the next point in time to wake up. Now, in Céu 3.x, there is an additional callback CEU_CALLBACK_WCLOCK_DT introduced which I guess is used for this purpose. However, so far I did not understand how to use it correctly.

Could you point to a basic example which illustrates the concept? What exactly do I have to return in ceu_callback_ret.num? Is it the elapsed system time since the last callback invocation? How does Céu gets triggered once the required delta time has been elapsed?

Thanks so much in advance!

Regards,

Matthias

[Francisco Sant'anna]

On Sun, Aug 5, 2018 at 12:51 PM, Matthias T. <matthia...@gmail.com> wrote:

Hi Francisco,

I recently tried to bind Céu's wclock to the system clock of my microcontroller. I do not want to implement the naive approach that feeds the wclock on every tick, e.g. each millisecond, by using

ceu_input(CEU_INPUT__WCLOCK, &dt);

Instead, I would like Céu to let me know when the next wclock tick is actually required. In the old version 1.x of Céu this has been done through a global variable assignment, I think it was something like WCLOCK_NEXT. The latter has been updated by Céu with the next point in time to wake up. Now, in Céu 3.x, there is an additional callback CEU_CALLBACK_WCLOCK_DT introduced which I guess is used for this purpose.

Yes.

 

However, so far I did not understand how to use it correctly.

Could you point to a basic example which illustrates the concept? What exactly do I have to return in ceu_callback_ret.num? Is it the elapsed system time since the last callback invocation?

Yes, since the last invocation for CEU_CALLBACK_WCLOCK_DT.
 

How does Céu gets triggered once the required delta time has been elapsed?

You need to generate any input:

https://github.com/ceu-lang/ceu/blob/v0.30/src/c/ceu.c#L912

Whenever your system calls `ceu_input`, Céu will automatically generate an a WCLOCK input as well (before your event).

So, your system needs to know DT even when generating another input.

When you just want to generate a WCLOCK (e.g., your timer expired), you have to call `ceu_input` passing `CEU_INPUT__NONE`.

You still need some way to know how much time your system needs to sleep before it has to awake Céu.

In this case, you'll need to handle another callback: `CEU_CALLBACK_WCLOCK_MIN`:

https://github.com/ceu-lang/ceu-libuv/blob/v0.30/include/uv/uv.ceu#L82

This callback carries the minimum time for the next "await <time>" in your program.

This allows you to set a timer in your system that will eventually generate a `ceu_input(CEU_INPUT__NONE)`, which will awake Céu and make it ask you for DT.

Let me know if this explanation is enough.

(We are changing the details again in the next version, but the concept will remain.)

Francisco

[Matthias T.]

I got it running, thanks!

So as I understood, Céu basically is triggered

• implicitly (any event occurred and the internal wclock is updated in this context – the time information is kind of piggy-backed in this case)
  
• explicitly (no event occurred but Céu needs to awake since e.g. an await XXms statement needs to return – a "wall clock event" so to speak)
  

to query the delta time from the environment.

Regards,

Matthias

[Francisco Sant'anna]

Yes, exactly.

The implicit trigger is a design decision that we want to enforce and avoid depending on the environment implementation: It should be impossible to have events A and B in sequence occurring at the same physical time.