profile
viewpoint
Peter Taylor PTaylor-us @FluenTech Colorado, USA

FluenTech/embedded-time 43

Time(ing) library (Instant/Duration/Clock/Timer/Period/Frequency) for bare-metal embedded systems

PTaylor-us/tlsf 16

A Two Level Segregated Fit (TLSF) allocator optimized for memory-constrained systems

FluenTech/cortex-m 1

Low level access to Cortex-M processors

FluenTech/cortex-m-rtic 1

Real Time For the Masses (RTFM) framework for ARM Cortex-M microcontrollers

FluenTech/tlsf 1

A Two Level Segregated Fit (TLSF) allocator optimized for memory-constrained systems

PTaylor-us/boost-cmake 0

Easy Boost integration in CMake projects

PTaylor-us/CppCoreGuidelines 0

The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++

PTaylor-us/crect 0

A C++, compile-time, reactive RTOS for the Stack Resource Policy based Real-Time For the Masses kernel

PTaylor-us/criterion-history 0

Generate plot of historical criterion test results

issue commentFluenTech/embedded-time

Add implementation for embedded_hal::blocking::delay::Delay trait

Yes, DelayMs and DelayUs.

I thought that Timer is for constant duration...

Piroro-hs

comment created time in 2 days

issue commentFluenTech/embedded-time

Code bloat due to use of `unwrap` in library

@PTaylor-us On the "noisy" part, simply create a macro to reduce it.

korken89

comment created time in 2 days

issue commentFluenTech/embedded-time

Code bloat due to use of `unwrap` in library

Hi, here are the most prominent ones that popped up when adding embedded-time to our project and replacing all time usage with it:

0.0%   1.5%    874B                 std core::fmt::Formatter::pad
0.0%   1.0%    604B                 std core::fmt::num::<impl core::fmt::Debug for u64>::fmt
0.0%   0.8%    484B                 std core::fmt::write

I am not 100% sure if the first line is attributed to embedded-time though, as it's errors should not need padding. But I am not sure.

korken89

comment created time in 2 days

issue commentFluenTech/embedded-time

How do I declare a Timer field in a struct?

@PTaylor-us I think so. My main goal right now would be to declare a Periodic and Running timer as field/variable, and periodically check it, so exposing both type parameters as public would make it possible.

Maldus512

comment created time in 2 days

issue commentFluenTech/embedded-time

Code bloat due to use of `unwrap` in library

Not yet sure, as I converted my entire codebase to embedded time before realising, but I can run a cargo bloat and see what was added.

korken89

comment created time in 3 days

issue commentFluenTech/embedded-time

Code bloat due to use of `unwrap` in library

Are there numbers on how much bloat this causes?

korken89

comment created time in 4 days

issue openedFluenTech/embedded-time

Add implementation for embedded_hal::blocking::delay::Delay trait

How about adding Clock::delay(&self) -> impl Delay function (maybe behind feature gate)? I will make a PR if you like.

created time in 7 days

issue openedFluenTech/embedded-time

Fixed-point Duration with Clock::SCALING_FACTOR

It's convenient to have fixed-point Durations whose time unit is same as Clock's.

It could be useful for use-case like below.

// assume clock rate is multiple of 3
// this periodic timer runs at exactly 3Hz
let timer = clock.new_timer(3_u32.Hz().to_duration::<ClockDuration<Clock>>().unwrap()).into_periodic();
// while this is not
let timer = clock.new_timer(3_u32.Hz().to_duration::<Milliseconds>().unwrap()).into_periodic();

I will make a PR if you like.

created time in 7 days

issue commentFluenTech/embedded-time

Upgrade core::time::Duration conversions

+1. We are in the process of updating atsamd-rs HAL to use embedded-time (https://github.com/atsamd-rs/atsamd/issues/333), but running into issues as converting to a Hertz (as a lot of methods consume an Into<Hertz>) only works for the u64 version, or using TryFrom.

On our side, we never expect anything in the Ghz, so this ends up being unwieldy.

@PTaylor-us, would you accept a PR to either:

  • Implement From for the Hertz<u32> variants, with panic/unsoundness if greater than 4.1GHz
  • Implement the From as above but using a feature flag thats off by default?
PTaylor-us

comment created time in 8 days

issue commentFluenTech/embedded-time

Comparing durations -- operations not symmetric

PR with fix is up

korken89

comment created time in 8 days

issue openedFluenTech/embedded-time

Codebloat due to use of unwrap in library

Hi, I did some code bloat tests and as I suspected the use of unwrap() in the library does pull in unnecessary formatting machinery. I can fix it but I want to check first, all val.unwrap() would be replaced with:

if let Some(v) = val { // Or `Ok(v)` as needed
    v
} else {
    panic!("Operation X failed.")
}

Should I fix a PR with this?

created time in 8 days

PR opened FluenTech/embedded-time

Fixed symmetric duration/instant math

Fixed #82

+58 -0

0 comment

2 changed files

pr created time in 8 days

issue commentFluenTech/embedded-time

Comparing durations -- operations not symmetric

I'll also have a look at it, seems like it should be straight forward for me to expand this.

korken89

comment created time in 8 days

issue commentFluenTech/embedded-time

Comparing durations

More experimentation, it seems that the functionality is here, just asymmetrically implemented?

I found that the following works:

now > last_now + 3.seconds() // OK

However none of the following works:

now >  3.seconds() + last_now // FAIL 1
now - last_now >  3.seconds() // FAIL 2
now - 3.seconds() > last_now  // FAIL 3

All which are just symmetric transforms of

korken89

comment created time in 9 days

issue commentFluenTech/embedded-time

Comparing durations

Now after experimenting I am still not able to compare durations, but I found other "paper cuts" that I think is good feed back for the future development of this library. It's a great start, however I think the ease-of-use can have some improvements. :)

I'd expect to have 2 extension traits on top of Clock:

  1. InfiniteClock, which is a trait that for all intensive purposes are infinite (like extending a timer to 64 bits which makes them overflow in like 400 years). Here I'd expect a nicer duration calculation interface, or simple Sub to work with panicing semantics on top of the checked_duration_since.
  2. InfallibleClock, which would add a now API that is infallible.

These would combine into the following maximum ease of use API, which if misused would panic on first use:

if my_clock.now() - last_time > 3.seconds() {
    // ...
}

Ping me if you want to have some discussion! :)

korken89

comment created time in 9 days

issue openedFluenTech/embedded-time

Comparing durations

Hi!

I have been trying to port to this library but I seem to get into some unergonomic issues that I feel like should be straight forward. I think I am doing something wrong, and what I am doing is eg:

let last_now = some_clock.try_now().unwrap();
// Some time passes...
let now = some_clock.try_now().unwrap();

if matches!(now.checked_duration_since(&last_now), Some(d) if d > Seconds(5)) {
    // Do something...
}

I have issues with finding a way to get these kinds of conversions to pass. How would one do this?

created time in 13 days

issue commentFluenTech/embedded-time

Breaks docs.rs build

Thank you, and no need to apologize!

ctron

comment created time in 18 days

issue commentFluenTech/embedded-time

Separation of features into separate crates

If the timer functionality is separated from the Clock trait, we're left with:

let timer = Timer::new(my_clock, 2.seconds()).start();

Definitely not nearly as pretty. Any suggestions?

Add an extension trait to timer (pseudo-code, not compiled or tested):

pub trait ClockExt { // alternative name: `NewTimer`
    fn new_timer(duration) -> Timer { ... }
}

impl<T> ClockExt for T where T: Clock {}

That would require the user to import ClockExt to use that method, but that can be eased by creating a prelude module and telling users to always use timer::prelude::*.

PTaylor-us

comment created time in 19 days

issue commentFluenTech/embedded-time

Breaks docs.rs build

@PTaylor-us Would you consider releasing a new version some time soon? I have some new libraries that have no working documentation on docs.rs, and other crates that I couldn't release right now if I wanted (as to not break the documentation).

This also causes failure on my CI builds for the nightly channel, and I assume it's going to work its way up to the beta and stable channels soon.

Thank you for your work on this library! I think it's great and fills an important need.

ctron

comment created time in 19 days

pull request commentrust-embedded/embedded-hal

Embedded-hal 1.0.0-alpha.4 release

r? @ryankurte

(rust_highfive has picked a reviewer for you, use r? to override)

eldruin

comment created time in 21 days

PR opened rust-embedded/embedded-hal

Reviewers
Embedded-hal 1.0.0-alpha.4 release

Once we have a new alpha release we can move forward with merging https://github.com/rust-embedded/linux-embedded-hal/pull/44

+6 -2

0 comment

3 changed files

pr created time in 21 days

pull request commentrust-embedded/embedded-hal

[0.2.x] Use nb version 0.1.3 for compatibility with nb 1.0

Indeed. Should be fixed now.

eldruin

comment created time in 21 days

pull request commentrust-embedded/cortex-m

Import panic-itm

r? @therealprof

(rust_highfive has picked a reviewer for you, use r? to override)

jonas-schievink

comment created time in 22 days

PR opened rust-embedded/cortex-m

Import panic-itm
+198 -22

0 comment

8 changed files

pr created time in 22 days

pull request commentrust-embedded/cortex-m

Prepare for v0.7.0

v0.7.0 is released :tada:

adamgreig

comment created time in 22 days

created tagrust-embedded/cortex-m

tagv0.7.0

Low level access to Cortex-M processors

created time in 22 days

issue openedrust-embedded/cortex-m

Ship a 1.0 release

Part of https://github.com/rust-embedded/wg/issues/383

Blockers:

  • [ ] rust-embedded/cortex-m-semihosting#49 – interrupt::free is not enough to access static mut safely

created time in 22 days

issue commentrust-embedded/cortex-m

Pull out reusable semihosting code into its own crate

The issue referenced is actually: https://github.com/rust-embedded/cortex-m-semihosting/issues/49 Problems of moving repos, I guess.

japaric

comment created time in 22 days

delete branch rust-embedded/cortex-m

delete branch : v0.7.0

delete time in 22 days

PR merged rust-embedded/cortex-m

Prepare for v0.7.0 S-waiting-on-review T-cortex-m

I think I got everything in the changelog updates but please point out anything I missed. Anything else missing before we're ready for 0.7.0?

Note that my plan is to now release cortex-m-semihosting 0.3.6 (with support for cortex-m >0.5&&<0.8) and 0.4.2 (cortex-m ^0.7, with our recent breaking changes) after cortex-m 0.7 is out.

+35 -6

10 comments

3 changed files

adamgreig

pr closed time in 22 days

more