fix: rtos-trace time missing #2541
Conversation
|
embassy-executor intentionally doesn't depend on Also can you add one line with the right features to |
|
That's what I was feeling. Move the GCDs to the embassy-time-driver, but didn't reexport it in the embassy-time crate. |
embassy-executor/src/raw/mod.rs
Outdated
| #[cfg(feature = "rtos-trace")] | ||
| impl rtos_trace::RtosTraceOSCallbacks for Executor { | ||
| fn task_list() { | ||
| // We don't know what tasks exist, so we can't send them. | ||
| } | ||
| #[cfg(feature = "integrated-timers")] | ||
| fn time() -> u64 { | ||
| Instant::now().as_micros() | ||
| const GCD_1M: u64 = gcd(embassy_time_driver::TICK_HZ, 1_000_000); | ||
| let us_per_tick = (1000 / GCD_1M) / (embassy_time_driver::TICK_HZ / GCD_1M); |
There was a problem hiding this comment.
1000 -> 1_000_000
also: the order of operations here will accumulate error if tick rate is not a clean divisor of 1e6. Note:
- embassy_time:
(ticks * (1000 / GCD_1K)) / (embassy_time_driver::TICK_HZ / GCD_1K); - this PR:
ticks * ((1000 / GCD_1K) / (embassy_time_driver::TICK_HZ / GCD_1K));
if you do the division first, it'll get rounded a bit, and that error will accumulate for every second passed. Or in extreme cases, if the tick rate is higher than 1MHz us_per_tick will be exactly 0. If you multiply first then divide, the rounding is just +/- 1us independently of the absolute value of the uptime.
There was a problem hiding this comment.
You're right, just fixed it.
Sorry about the back in forth in this PR., I'll take my time for the future ones
xgroleau
force-pushed
the
fix/executor-rtos-usage-time
branch
from
9c6322a to
d48620d
Compare
Could not compile when
rtos-tracewas enabled due to missing embassy_time feature. Note that I addedembassy-timefor thertos-tracefeatureWe could probably derive from
embassy-time-driver::now()if it's preferred and don't want to depend onembassy-time