Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datetime traits #207

Open
David-OConnor opened this issue May 1, 2020 · 8 comments
Open

Datetime traits #207

David-OConnor opened this issue May 1, 2020 · 8 comments

Comments

@David-OConnor
Copy link

David-OConnor commented May 1, 2020

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
Copy link
Member

eldruin commented May 1, 2020

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
Copy link
Author

David-OConnor commented May 1, 2020

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

@eldruin
Copy link
Member

eldruin commented May 1, 2020

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

@David-OConnor
Copy link
Author

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

@David-OConnor
Copy link
Author

David-OConnor commented May 2, 2020

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.

@eldruin
Copy link
Member

eldruin commented May 2, 2020

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
Copy link
Author

David-OConnor commented May 2, 2020

  • 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.

@eldruin
Copy link
Member

eldruin commented May 22, 2020

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants