rust-embedded/embedded-hal

Datetime traits

David-OConnor opened this issue · 8 comments

David-OConnor commented

What are your thoughts on Datetime, Time, Date etc traits? They seem like a good fit because they're not available natively on no_std, are a common feature. It would be nice to be able to write general functions using these traits, instead of platform-specific ones.

Ie, make it so you don't have to hard-code functions to accept chrono::Datetime (eg a computer) or ds323x::DateTime (eg ds3231).

This feels higher-level than existing traits, but I'd argue it fits well with the concept of code portability across devices, which is a big (the main?) draw of this project. I we can currently write device-agnostic code using InputPin, but not dates/times/datetimes.

If y'all like it, I'll draft a PR.

eldruin commented

The types from chrono can be used in no_std as well. I use them in the rtcc crate where I define a trait for RTC devices. I implemented this in the mcp794xx driver but did not implement this yet in the ds323x or ds1307 drivers.

David-OConnor commented

That's awesome; had no idea. Your crate is in line with what I was proposing.

eldruin commented

I'm currently implementing the trait for the ds323x driver. Stay tuned.

  • 👍1
David-OConnor commented

Think I should PR linux-embedded-hal with an impl using Chrono?

  • 👍1
David-OConnor commented

Btw, looking fwd to your Rtcc impl on ds32x; I'm writing code now using ds323x's syntax. The obvious appeal of the Rtcc syntax is ability to switch devices without changing the code too much.

  • 👍1
eldruin commented

Ok, I just published version 0.3 of the ds323x driver crate which implements the Rtcc trait.
Yes, the ability to switch between implementations without changes to the code that just uses the traits is the main benefit from defining and implementing common traits. You can easily switch between using a DS3231, MCP79401 or any other RTC device supported by the drivers, for example.

I am unsure whether chrono-based methods for linux-embedded-hal would make sense. It would definitely make sense if we would add Rtcc-like traits to embedded-hal. Otherwise, if you are in a system running Linux, you can already use chrono and std methods anyway, I would say.

Whether Rtcc-like traits in embedded-hal would make sense, I do not know. RTCs are present in many systems but I would be a bit wary of adding the dependency on chrono to embedded-hal.
Maybe somebody else has an opinion here?

David-OConnor commented

  • 1: Switched to your new ds323x crate and the Rtcc trait - awesome! This is seriously good stuff, and is what I was looking for with this issue.

  • 2: I've written most of the linux-embedded-hal thing (get pulls things from Chrono::Utc, and set uses process::Command to set sys time; need to think on sys clock vs hw clock; latter is probably the answer). Given that linux-embedded-hal impls embedded-hal traits only, I agree it doesn't make sense while Rtcc is standalone. I don't know if the best course of action is to publish what I have as a sep crate, or what. linux-embedded-hal-extras ?

Thoughts on getting Rtcc merged into embedded-hal? Contingent on both you and the embedded hal guys agreeing it's the way to go. I do, as I think Rtc is as worth being hardware agnostic as InputPin. Here's an example of when it comes in handy: You're using chrono or std methods to get and set time. You realize that your SBC doesn't actually have a RTC, and switch to a separate hardware clock. You have to rewrite large chunks of code since they have diff APIs... I personally will use Rtcc for all my embedded projects in the future.

  • 👍1
eldruin commented

@David-OConnor I'm glad to hear that.
In the mean time I have updated my other RTC driver ds1307 to use the Rtcc trait as well.
If you want to publish an implementation of the Rtcc trait for linux that would be great, although I would rather not include embedded-hal in the name at this point.
Do you have a repository, branch or just a gist where I could have a look?