embedded-hal
embedded-hal copied to clipboard
Datetime traits
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.
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.
That's awesome; had no idea. Your crate is in line with what I was proposing.
I'm currently implementing the trait for the ds323x
driver. Stay tuned.
Think I should PR linux-embedded-hal
with an impl using Chrono?
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.
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?
-
1: Switched to your new
ds323x
crate and theRtcc
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 fromChrono::Utc
, andset
usesprocess::Command
to set sys time; need to think on sys clock vs hw clock; latter is probably the answer). Given thatlinux-embedded-hal
implsembedded-hal
traits only, I agree it doesn't make sense whileRtcc
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.
@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?