Re: revl + timer

Brunet Yorick <[email protected]>
Newsgroups dev.linux.lists.xenomai
Message-ID <[email protected]>
On 8/19/26 19:45, Philippe Gerum wrote:
> Brunet Yorick <[email protected]> writes:
> 
>> Hello,
>>
>> I originally posted this question in the matrix channel but got no answer. I try with the mailing list.
>>
> 
> The matrix channel is dead, at least nobody is monitoring it anymore due
> to lack of sustained interest from users, and lack of time on my end
> too. This is the reason why the matrix URL was dropped from the website
> information a year ago or so. I may have to close the channel and lose
> the messages posted there. This mailing list is indeed the right place
> to inquire about xenomai stuff.
> 
>> I have been using `libevl` for some time. I am now testing `revl` as I want to move forward Rust.
>>
>> As a first step before going on the embedded board, I'm using "qemu virt64".
>>
>> First, I noticed that https://gitlab.com/Xenomai/xenomai4/revl/-/blob/master/Cargo.toml?ref\_type=heads doesn't refer a valid `evl-sys` as it points to the main branch and not a tag. I had to clone `revl v0.6.2` and change manually Cargo.toml to
>>
>> ```
>> -evl-sys = { version = "0.32", git = "https://gitlab.com/Xenomai/xenomai4/evl-sys" }
>> +evl-sys = { tag = "v0.36.1", git = "https://gitlab.com/Xenomai/xenomai4/evl-sys" }
>> ```
>> (or v0.32.1)
>>
> 
> I'm not sure to understand the issue. Cargo should pick v0.32.1 since it
> tries to upgrade automatically as long as it finds a newer compatible
> version, e.g.:
> 
> $ cargo build
>     Compiling autocfg v1.1.0
>     Compiling proc-macro2 v1.0.89
>     Compiling unicode-ident v1.0.1
>     Compiling memchr v2.5.0
>     Compiling glob v0.3.0
>     Compiling cfg-if v1.0.0
>     ...
>     Compiling evl-sys v0.32.0 (https://gitlab.com/Xenomai/xenomai4/evl-sys#381404f7)
> 
> Which is evl-sys v0.32.1, as it should be:
> 
> $ git log -1 381404f7
> commit 381404f7ab5a38744b6a771f60a4620b865d208d (tag: v0.32.1)
> ...
> 
> This said, I agree that using tags would be clearer and follow the
> recommendation from the Cargo docs.
> 
> NOTE: in the version/tag information v0.x.y for evl-sys, 'x' refers to
> the libevl API number this FFI is compatible with, and 'y' is a patch
> level fixing minor issue(s) in this context.
> 

That's strange. I get the following behaviour:

```
revl = {
	git = "https://gitlab.com/Xenomai/xenomai4/revl", tag = v0.6.2" }
```

in Cargo.toml gives as a result

$ cargo clean
[...]
$ cargo build
     Updating git repository `https://gitlab.com/Xenomai/xenomai4/revl`
     Updating git repository `https://gitlab.com/Xenomai/xenomai4/evl-sys`
error: failed to select a version for the requirement `evl-sys = "^0.32"`
candidate versions found which didn't match: 0.36.1
location searched: Git repository 
https://gitlab.com/Xenomai/xenomai4/evl-sys
required by package `revl v0.6.2 
(https://gitlab.com/Xenomai/xenomai4/revl?tag=v0.6.2#1d771341)`
     ... which satisfies git dependency `revl` of package 
`evl-periodic_task-rs v0.1.0 
(/home/.../evl-rt/linux/usr/evl_periodic_task_rs)`

>> Then I tried to use the timer with
>>
>> ```
>> let timer = timer::Timer::new(clock::STEADY_CLOCK).expect("[ERROR] timer create failed\n");
>> let now = clock::STEADY_CLOCK.now();
>> let period = Nanoseconds(1_000_000_000_u64);
>> let first_expiry = now + period;
>> timer.arm_periodic(first_expiry, period).expect("[ERROR] timer arm failed\n");
>> loop {
>>      match timer.wait() {
>>          [...]
>>      }
>> }
>> ```
>>
> 
> Which error is this, precisely? e.g. using .unwrap() on the result
> instead of expect() would give better details.
> 
>> or
>>
>> ```
>> let timeout = clock::STEADY_CLOCK.now() + Seconds(1_u32);
>> assert!(clock::STEADY_CLOCK.sleep_until(timeout).is_ok());
>> ```
>>
>> Both cases fail, either on the `timer.wait()` or `sleep_until()`.
>>
>> My system is composed of:
>> - uboot
>> - buildroot (I included the libevl r59, revl v0.6.2, and evl-sys v0.36.1 packages but I'm not sure that it was necessary)
>> - linux-evl v6.18.29-evl2-rebase
>>
>> rustc 1.97.1 (8bab26f4f 2026-07-14)
>>
>> The Cargo.toml of my project is:
>> ```
>> [package]
>> name = "evl-periodic_task-rs"
>> version = "0.1.0"
>> edition = "2024"
>>
>> [dependencies]
>> revl = { path = "../../../../revl" } <--- points to v0.6.2 with changes presented above
>> libc = "0.2.189"
>> embedded-time = "0.12.1"
>> ```
>>
>> Do you have any idea on the issue ?
> 
> 1. revl::init() was not called prior to issuing any of those requests. I
> would suspect ErrorKind::Other to be returned by Timer::arm_timer().
> 
> 2. Thread::attach was not called prior to attempting to sleep in oob
> mode on the steady clock. In such an event, receiving
> ErrorKind::PermissionDenied would make sense.
> 
>> How can I retrieve more logs from EVL?
>>
> 
> There isn't, this is a system call (low-level) interface, so no cosy
> application-level message logging in such layer.


I did not write the full main.rs in my previous message.
Here it is. I changed .except() to .unwrap().

```
use embedded_time::duration::{Nanoseconds, Seconds};
use embedded_time::fixed_point::FixedPoint;
use revl::sched::SchedAttrs;
use revl::{clock, evl_eprintln, evl_println, thread, timer};
use std::process;

fn main() {
     println!(
         "{} v{}\n",
         env!("CARGO_PKG_NAME"),
         env!("CARGO_PKG_VERSION")
     );

     // Pin to CPU 1 which is dedicated to RT
     unsafe {
         let mut cpuset: libc::cpu_set_t = std::mem::zeroed();
         libc::CPU_ZERO(&mut cpuset);
         libc::CPU_SET(1, &mut cpuset);
         if libc::sched_setaffinity(libc::getpid(), 
size_of::<libc::cpu_set_t>(), &cpuset) != 0 {
             eprintln!(
                 "[ERROR] Set affinity failed: {}\n",
                 std::io::Error::last_os_error()
             );
         }
     }

     // Initialize EVL
     revl::init().unwrap();

     // Attach the current thread to EVL core, undergoing SCHED_FIFO at 
priority 8
     thread::Builder::new()
         .name(&format!("Periodic EVL thread {}", std::process::id()))
         .sched(SchedAttrs::FIFO(8.into()))
         .public()
         .attach()
         .unwrap();
     evl_println!("EVL thread attached\n");

     // Create a timer based on the monotonic clock
     let timer = timer::Timer::new(clock::STEADY_CLOCK).unwrap();
     evl_println!("Timer created\n");

     // Set up a 1 Hz periodic timer
     let now = clock::STEADY_CLOCK.now();
     let period = Nanoseconds(1_000_000_000_u64);
     let first_expiry = now + period;

     timer.arm_periodic(first_expiry, period).unwrap();
     evl_println!("Timer armed\n");

     // Loop waiting for timer events
     loop {
         // Wait for the next tick to be notified
         match timer.wait() {
             Ok(result) => {
                 // Read the current time via EVL clock
                 let now = revl::clock::STEADY_CLOCK.now();
                 let dur = now.duration_since_epoch();
                 let secs = Seconds::<u64>::try_from(dur).unwrap();
                 let nsecs = (Nanoseconds::<u64>::try_from(dur).unwrap() 
% secs).integer();
                 evl_println!("{}.{:09} - TICKED\n", secs.integer(), nsecs);
                 // Overrun warning if any
                 if let Some(overruns) = result {
                     evl_println!("Late wakeup of {} ticks\n", overruns);
                 }
             }
             Err(e) => {
                 evl_eprintln!("[ERROR] timer wait failed: {} ({:?})\n", 
e, e.kind());
                 process::exit(1);
             }
         }
     }
}
```

 From revl doc, I suppose that revl::init() is correctly called.
I'm not sure about Thread::attach() though.
The doc gives this way of doing but I have the impression to create a 
new thread and attaching it but not attaching the current "main" thread.
I haven't found how to attach the latter though.

Concerning the error, even with unwrap, only the following text is 
printed. The error seems to be empty.
And neither "Timer created" nor "Timer armed" are displayed (may still 
be in print buffer).

```
evl-periodic_task-rs v0.1.5

EVL thread attached
[ERROR] timer wait failed:
```

Thanks for you help.
Yorick
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.