<RobertJrdens[m]>
<RobertJrdens[m]> "https://github.com/dtolnay/..."; <- Just needs a derive macro for `defmt::Format` (re/ab)using the `thiserror` derive macro attributes similar to make this really cool.
<RobertJrdens[m]>
* macro attributes or similar, * similar syntax to make
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
<dirbaio[m]>
👀
jannic[m] has joined #rust-embedded
<jannic[m]>
Will there be a meeting today, or is everyone busy with Oxidize?
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
oh right
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
yep, just about to say!
<adamgreig[m]>
@room hi everyone, meeting time again! agenda is (going to be) https://hackmd.io/JOA43f0bTk6vZk5DNTUHPQ, please add anything you'd like to discuss and we'll start in a couple of minutes
pronvis has joined #rust-embedded
<adamgreig[m]>
OK, let's start and work out any other items as we go, my internet just swapped over to satellite backup so I'm running a 1s latency lol
<adamgreig[m]>
first up, welcome bartmassey and Henk to the wg and the resources team! I've been afk since last saturday but will get you officially added to the org today or tomorrow
<adamgreig[m]>
and, thanks to thejpster who is retiring from the wg and from being our rep on the leadership council
<adamgreig[m]>
I think that's all the announcements I had, does anyone have anything else?
Henk[m] has joined #rust-embedded
<Henk[m]>
👋 Thanks! Happy to be a part!
<adamgreig[m]>
I'll quickly cover the cortex-m-rt item as I don't think we need much discussion: it sounds like we just need to review the PR for the linker section and then merge and release 0.7.5 with the updated 0.7.5 macros crate
<adamgreig[m]>
I'll poke those PRs and if anyone else in cortex-m wants to have a look over then go ahead, otherwise we'll get those released and hopefully keep them released this time
<adamgreig[m]>
ok, then the main two items left to discuss are the timer/counter traits and the disco/book plans
<adamgreig[m]>
I understand bartmassey isn't here atm but Henk is, did you want to go over any updates since last week?
<adamgreig[m]>
if not we can save it for next week and keep up discussions on the RFC instead
VictorOsedahunsi has joined #rust-embedded
<VictorOsedahunsi>
Thanks for the good work you are doing on the embedded ecosystem adamgreig
pronvis has quit [Ping timeout: 268 seconds]
<Henk[m]>
I've been busy with other stuff in the last week, so there isn't much to add apart from the fact that I plan to start working on porting chapters from the STM32 disco book to microbit v2 next thursday
<Henk[m]>
Any suggestions as to whether I should work on a branch or on a fork of the repo?
<AdamHott[m]>
Do you have a time set aside for that next Thursday? I'd be happy to help.
<Henk[m]>
Seeing as the current RFC doesn't cover porting the chapters just yet
<adamgreig[m]>
Henk[m]: either is fine, typically team members often work on branches
<Henk[m]>
Cool
<Henk[m]>
adamhott[m]: Sure! I'll drop you a message
<adamgreig[m]>
great, thanks for the update
<adamgreig[m]>
so the final thing I had is the timer/counter traits, although it sounds like discussion has already been quite lively on those!
<adamgreig[m]>
procedurally, do you think you'd want a new embedded-timers or similar inside the e-h repo but as its own crate as the first step, then consider merging into e-h only after some time and experience?
<dirbaio[m]>
i'm not sure. ti feels like if we put it in embedded-timers with the intention of later merging, what will happen in practice is it'll stay there forever
<dirbaio[m]>
like it has happened with async
<dirbaio[m]>
and timer traits are very "foundational"
<dirbaio[m]>
if Delay is in the main e-h crate then Timer should be too
<dirbaio[m]>
perhaps we can name the crate something ugly like embedded-hal-timers-preview, to force ourselves to not let it stay
<adamgreig[m]>
yea, that's my general feeling. maybe an e-h 1.1-alpha release?
<adamgreig[m]>
hah, or that
<adamgreig[m]>
if it's in a -alpha it can always be totally deleted later
<dirbaio[m]>
I think e-h 1.1-alpha would be annoying because Cargo considers it incompatible with e-h 1.0?
<dirbaio[m]>
a hal implementing e-h 1.1-alpha wouldn't work with a driver using e-h 1.0
<dirbaio[m]>
or would it?
<adamgreig[m]>
huh, is that so? 1.1 should be compatible with 1.0 but yea not sure about -alpha
<dirbaio[m]>
so the hal would have to impl both e-h 1.1-alpha and e-h 1.0 ... for all traits 💀
<adamgreig[m]>
or rather 1.1 would get used throughout the tree for someone depending on "1.0" iirc
<dirbaio[m]>
1.0 -> 1.1 yes
<dirbaio[m]>
but 1.0 -> 1.1-alpha.0 not sure
pronvis has joined #rust-embedded
<jannic[m]>
Do we even need a name for now? From all the discussions we had back before e-h 1.0 about time related stuff, I guess it will take at least months until we get to the point that we'd want to release anything to crates.io. And as long as it's only in github repositories, we can rename stuff as often as we like.
<dirbaio[m]>
yeah, given the state of the rfc it's a bit early to start discussing this
<Henk[m]>
I'm taking off now, chat you next week! 👋
<adamgreig[m]>
👋
<adamgreig[m]>
so atm probably the next step would be to continue discussing the concerns on the RFC and/or update the proposal to something more like the simple traits discussed in chat?
AlexandervanSaas has joined #rust-embedded
<AlexandervanSaas>
dirbaio[m]: Cargo indeed considers all versions with a postfix not semver compatible.
<dirbaio[m]>
yep then I think we'll ahve to do somethign like embedded-hal-timers-preview then
pronvis has quit [Ping timeout: 260 seconds]
<dirbaio[m]>
adamgreig[m]: basically yep
<dirbaio[m]>
honestly imo the proposed trait in the RFC is overly complex
<adamgreig[m]>
or patch to git dependency until happy and put in e-h 1.1? a shame you can't easily do a 1.1 test release without patching all the things that were saying 1.0
<AlexandervanSaas>
AlexandervanSaas: Hmm actually this is not entirely correct but it won't update from 1.0 to 1.1-something.
<adamgreig[m]>
yea, it won't update to it
<adamgreig[m]>
but if you manually depend on 1.1-alpha, will it replace 1.0 everywhere in the tree?
<adamgreig[m]>
I was thinking about other use cases and things like smoltcp wanting to know the ms-since-boot came to mind
<adamgreig[m]>
of course in practice it can just be told the current timestamp at every call to poll so it's not a huge problem, and any similar driver could probably do the same
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
Also it would be nice if a monotonic clock could be derives from these new traits
<romancardenas[m]>
s/derives/derived/
<dirbaio[m]>
Timer would still work as a monotonic clock, you just have to use an impl that takes long enough to overflow
<dirbaio[m]>
except then you probably want u64 and not u32
BenPh[m] has joined #rust-embedded
<BenPh[m]>
I'm here.
<dirbaio[m]>
but forcing u64 on everyone is a bit .. uh
pronvis has quit [Ping timeout: 256 seconds]
<BenPh[m]>
dirbaio[m]: That's why I propose a generic `RawData` assosciated type. The output type can be what is most impl appropriate
<adamgreig[m]>
but it's not really about impl-appropriateness, it's just about how long a delay the user needs
<BenPh[m]>
I didn't have delays in mind when thinking about the RFC.
<adamgreig[m]>
if the driver only needs <1s then u32 is fine and good even at ns resolution
<adamgreig[m]>
ah sure, s/delay/measurement period
<adamgreig[m]>
I understand you were aiming to abstract the general concept of accessing a counter/timer, while the simpler proposal above really just targets drivers wanting to measure short elapsed times
<adamgreig[m]>
if we're happy saying those times are always <4s you could require "always u32 nanoseconds and must handle up to 4.3s" but it's not obviously long enough
<adamgreig[m]>
and if you're running on a 16-bit timer you would probably like to avoid requiring handling rollover
<BenPh[m]>
Part of the work I want to do, is to PoC drivers that need to handle rolovers.
<BenPh[m]>
The use case that spurred this RFC was wanting to write something portable, while also being able to track time.
<vollbrecht[m]>
if we are generic here we would have impls for all base types
<vollbrecht[m]>
s/have/need/
<BenPh[m]>
vollbrecht[m]: That's part of the RFC. If it's only u32 or u64, we can take it for granted that we get all the unsigned interfaces, such as Ord, Sub, Mul, etc.
<vollbrecht[m]>
yeah but if we go generic that introduces a lot of overhead here, just u64 is so much simpler
<BenPh[m]>
That wouldn't be appropriate for e-hal though, no? lot's of platforms prefer not to use u64, or straight up can't? Forcing the one u64 would destroy portability.
<BenPh[m]>
not to mention, there might be a desire to do a non-primitive, such as (u16, u32), where .0 counts rollovers, and .1 counts the ticks.
<BenPh[m]>
also, I don't understand how making RawData would add complexity.
<BenPh[m]>
* also, I don't understand how making RawData generic would add complexity.
<vollbrecht[m]>
the compexitiy is in the plumbing of things, user should have a good time here
<vollbrecht[m]>
not that its hard to understand whats going on
<JamesMunns[m]1>
BenPh[m]: I don't think that's necessary fact, given that embassy time does it across many platforms
<vollbrecht[m]>
what most rust users frustrate is mismatching of generics when a wants x and b wants y
<vollbrecht[m]>
* what most rust users frustrate is mismatching of generics when a wants x and b wants y
<JamesMunns[m]1>
vollbrecht[m]: Case in point: the old SPI word size of 8 vs 16 bit
<JamesMunns[m]1>
s/necessary/necessarily/
<BenPh[m]>
that would be a design choice of the implementation though, no? it would be a compromise between platform appropriate and plumbing ergonomics. Is it appropriate for e-hal to force the choice onto the implementor?
<adamgreig[m]>
it's not inconceivable to end up with just u64 if it ends up being much more ergonomic to use
<adamgreig[m]>
the new spi does still have a word size generic, just it can now default to u8, iirc
<BenPh[m]>
Documentation on the trait to encourage a particular impl to either use u64, or ensure it impls `Into<u64>`.
<adamgreig[m]>
but if it seems like the majority of use-cases are measuring times that fit in u32, it probably makes more sense to use u32 or to make it generic (maybe with a default u32...)
<adamgreig[m]>
yea, the problem we had before is that anything suitably generic or complicated to model lots of disparate uses ends up being bad for the same reasons
<jannic[m]>
It seems we are back at the point that there are too many trade-offs to consider so we don't find an API that's suitable for all use cases. Perhaps the RFC could contain a list of use cases, and then we could see if we could cover a significant majority of them with some trait, and only cover them?
<jannic[m]>
Because at the moment, for every suggestion, there is at least one counter-example where it wouldn't work. We can continue like that forever without finding a perfect solution.
<adamgreig[m]>
whereas we could save DelayNs in e-h 1.0 because it's such a simple and concrete use-case that's well met by the very simple design it got
<adamgreig[m]>
jannic[m]: > <@jannic:matrix.org> It seems we are back at the point that there are too many trade-offs to consider so we don't find an API that's suitable for all use cases. Perhaps the RFC could contain a list of use cases, and then we could see if we could cover a significant majority of them with some trait, and only cover them?
<adamgreig[m]>
> Because at the moment, for every suggestion, there is at least one counter-example where it wouldn't work. We can continue like that forever without finding a perfect solution.
<adamgreig[m]>
yea, I think the recent interest is maybe best captured by the simple proposal of just "measure short durations of time since start() was called, or error on overflow", and it's not fully satisfactory even so (perhaps one addition is the Overflow error could contain the minimum time that must have elapsed?)
<BenPh[m]>
adamgreig[m]: The proposal I have in mind addresses this. It's very simple and straight forward. reads a count of something, and also knows the scale of what each count is.
<BenPh[m]>
if there's an overflow, the implementor can define the way it's handled.
<BenPh[m]>
nothing complicated about it, and gives complete room for the implementor to handle cases such as rollover appropriately.
<firefrommoonligh>
I think some of the trouble you get into here is in firmware vs libraries (eg HAL or w/e manages the time source)
<BenPh[m]>
at least, that's the goal in mind
<firefrommoonligh>
Like, the overflow counter will probalby be incremented in the firmware via a timeout interrupt or w/e
<BenPh[m]>
exactly
<firefrommoonligh>
I do it (as we've discussed) with a public atomic in the lib's module. You could also do it on the timing struct, although that will require ownership semantics which may be overkill
<adamgreig[m]>
BenPh[m]: yea, I think the core of that is what's encouraged some interest, but your proposal on the RFC still has more complexity than https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$OD0bh5PT-eF-OI8dfVI7OoD4BxpmBRDY6SLRAVUj1pc for example, so the question is whether that complexity is warranted
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
BenPh[m]: as I said the other day, the goal is to enable writing drivers that are portable across HALs. If you leave it all up to the implementor, you can get slient misbehavior. e.g. if a driver is waiting for the timer to hit 10s, but the impl silently overflows at 5, so it keeps cycling 0..5.
<adamgreig[m]>
if the purpose is "measure elapsed time since start" then you never want it to roll over back to 0, right
<dirbaio[m]>
vs if you mandate overflow returns an Overflow error, such use in drivers is guaranteed to either behave correctly or error. No silent misbehavior. this is strictly better in my eyes.
<dirbaio[m]>
you keep dismissing concerns as "just implementation details, implementation can do wahtever, we don't want to constrain it"
<adamgreig[m]>
if the implementation can count rollovers to keep increasing the total duration, great, and if it can't, perhaps also fine so long as it can signal that it's reached its maximum
<dirbaio[m]>
but doing this severely limits the usefulness of the traits for writing drivers that are portable across HALs
<dirbaio[m]>
which is the original goal
<jannic[m]>
Even if the implementor could signal that overflow with an error, we could get into situations where drivers and implementations are compatible API-wise, but wouldn't work in practice, as the implementation always returned errors.
<BenPh[m]>
adamgreig[m]: yeah. A requirement of the trait design would include allowing the implementation to be able to address the "counter register rolledover" scenario.
<BenPh[m]>
dirbaio[m]: I mean, that's kinda the whole point.
<BenPh[m]>
...otherwise it's a trait that forces design decisions onto the implementor.
<dirbaio[m]>
????
<adamgreig[m]>
Ben Ph: to be clearer: right now the RFC proposal reads as too complicated for the people who decide if it gets accepted, so it won't get accepted without either changes to simplify it, or a more convincing explanation of why the complexity is essential
<vollbrecht[m]>
There is no up do date PR or RFC where we have a concrete Representation how it should look like or did i not find it?
<vollbrecht[m]>
* look like in terms of Code or did
<BenPh[m]>
case in point, I want to write 3d printer firmware. That needs to be able to get a reference in time. Right now, there is nothing available such that each of the MCU hals can say "have this implementation of clock-tick-count, and here are it's limitations etc."
Amit[m] has quit [Quit: Idle timeout reached: 172800s]
<BenPh[m]>
Think of it this way: without the trait, what would the solution be? if you choose an implementation that hase option B behavior, then that's what you would get.
<adamgreig[m]>
BenPh[m]: yea, this would be a really nice thing to have available, but if you want "time since boot, keeps going basically forever" that's a different problem (maybe with a different concrete solution) than "short time since timer was started", which has been the focus of more of the recent discussions
<adamgreig[m]>
we could have both as separate things
<dirbaio[m]>
BenPh[m]: you're not answering my question
<BenPh[m]>
> are you seriously saying we should do B instead of A?
<BenPh[m]>
Personally, if I needed something that needed to hit 10s, but never reached it, I would go for something different.
<adamgreig[m]>
the first might be better solved like critical-section: some single global counter into a u64 that gets "registered" once, akin to how embassy-time does it, while the second could be more like the simple Timer trait above
pronvis has joined #rust-embedded
<BenPh[m]>
it shouldn't be up to the trait to choose between A and B
<adamgreig[m]>
trying to make one generic design able to solve both problems puts us into a difficult position
<jannic[m]>
adamgreig[m]: That's a good point. And some 16bit MCU probably just wouldn't implement the "64bit microseconds since boot" trait, but still could provide meaningful measurements for shorter periods with the other trait.
<dirbaio[m]>
BenPh[m]: it IS up to the trait contract. the trait can either specify what happens on overflow (option A) or not specify it and leave it to the impementation (option B). Is there a third option i'm ,issing?
<dirbaio[m]>
s/,issing/missing/
<adamgreig[m]>
yea, having an assocated max wait seems nice, I had thought the overflow error could contain the max wait but it could probably just be associated on the type
<BenPh[m]>
the choices you're presenting are design choices. Unless e-hal is aiming to impose standards onto how things shall be implemented, the choice is inconsequential other than to raise the question of how not to impose inapropriate restrictions.
<dirbaio[m]>
> Unless e-hal is aiming to impose standards onto how things shall be implemented
<dirbaio[m]>
this is exactly embedded-hal's goal
<BenPh[m]>
really? that seems at odds with partability.
<dirbaio[m]>
impose standards on impls, so that you can write a driver using the traits and be sure it'll work everywhere
<dirbaio[m]>
you NEED standards to get portability of drivers
<BenPh[m]>
"tick counts shall be u64 only" is at odds with platforms that read tick counts as u32.
<dirbaio[m]>
no, these platforms can return tick_count as u64
<adamgreig[m]>
we learnt from e-h 0.2 that making traits too generic, or not imposing enough requirements on implementations, ended up with useless traits that were impossible to use in portable code
<BenPh[m]>
I don't see that as a desireable thing to compel a platform to do.
<BenPh[m]>
"fuck. I need to use u64?"
<adamgreig[m]>
so yes, the design intent with 1.0 is that the traits do impose enough of a requirement on the implementation that you can have meaningfully portable users
pronvis has quit [Ping timeout: 268 seconds]
<dirbaio[m]>
yaeh as Adam is saying we've been through this many times
<dirbaio[m]>
if you make a trait that leaves too many things to the implementation, it's impossible to use in drivers
<dirbaio[m]>
because drivers can't rely on anything
<adamgreig[m]>
of course it's nice when we can find solutions that are comfortable with a wide range of platforms and implementations, otherwise we'd have already just said "time is u128 picoseconds" and moved on, but the balance is going to be towards constraining implementations even in ways they'd rather not for their specific platform
<adamgreig[m]>
and in exchange we can have drivers that work across a wide range of platforms because they are provided the same common set of guarantees
<adamgreig[m]>
hah yea we could just use core Duration, that would be nice :P
<adamgreig[m]>
but that is seen as too constraining of the implementation, so there has to be a balance found somewhere
<dirbaio[m]>
core::duration is way too bloated
<adamgreig[m]>
hopefully, anyway! maybe it turns out we do just use core duration...
<BenPh[m]>
fugit is perhaps the closest to ideal.
<BenPh[m]>
would have to double check, but it doesn't give any binary bloat, it's all const, encapsulates a whole bunch of time expressions nicely. is compatable with just about any time representation you would want.
<dirbaio[m]>
.... and is very complex
<vollbrecht[m]>
the question is -> is it plumable ?
<adamgreig[m]>
yea, it's nice that fugit gives you convenient wrappers for things like "u32 microseconds", lets the users get durations out in whatever units they want, and is computationally pretty efficient and can store ticks or nanoseconds or whatever under the hood
<BenPh[m]>
...not really.
<BenPh[m]>
vollbrecht[m]: very
<adamgreig[m]>
but yes, it is much more complex than the very simple trait discussed previously, and for just "get short durations" it might not be worth it
<BenPh[m]>
dirbaio[m]: ...you really think so?
<dirbaio[m]>
yep
<BenPh[m]>
under the hood it's complex, but to use it, it's pretty straight forward. I would even say it simplifies things quite a lot if you are dealing with time.
<firefrommoonligh>
adamgreig[m]: I find that sort of thing useful when conforming to a spec that has timestamps. For example, DroneCAN, or maybe parsing things like GPS timestamps from the GPS chips.
<firefrommoonligh>
For internal use, I've been storing the Instants (like core::time::Instant) directly, then subtracting to get a Duration, then calling "as_millis()" or w/e to compare to a const that defines a threshold or w/e
<jannic[m]>
Under-the-hood complexity can show up in unreadable error messages or less then optimal code completion in editors. In that sense, it's a leaky abstraction.
<adamgreig[m]>
yea, it's nice that you can load up nanoseconds parsed from a gps message and quickly convert to ticks in your timer base or something
<firefrommoonligh>
So, I only want a free integer floating around if a wire format wants that
<firefrommoonligh>
Otherwise I want a more abstract struct
<BenPh[m]>
I could see it being complex from a perspective where you're okay with handwaving-away actual complexity, but time is a complex thing. if all you have is a u64 to count milliseconds or something, then it's simple at the surface, but then you have to do a whole bunch of complex stuff to get the job done.
<dirbaio[m]>
first of all, fugit is just instant/duration/rate types. it ahs no trait for "give me the current Instant"
<dirbaio[m]>
I don't know how that trait would look
<dirbaio[m]>
but it wouldnt' be trivial
<dirbaio[m]>
it'd have to deal with the NUM/DENOM fraction somehow
<dirbaio[m]>
who chooses it? the trait implementation? the caller?
<dirbaio[m]>
s/caller/driver/
<adamgreig[m]>
well, hm
<firefrommoonligh>
dirbaio[m]: Yea - this is the core of why what Ben is talkign about, and Fugit are only superficially related, if I understand him correctly.
<firefrommoonligh>
Ben's idea, and the work it inspired me to do on my own code bases over the past week, are IRT actually getting a relative timestamp.
<adamgreig[m]>
for the simple Timer trait, you could be using fugit to store the actual duration
<dirbaio[m]>
second, the NUM/DENOM generics would have to "propagate" through all the driver code, which is a bit of boilerplate
<adamgreig[m]>
and use fugit's conversions for the elasped_millis() etc
<adamgreig[m]>
you can still have that simple Timer trait and the underlying implementation uses fugit
<BenPh[m]>
yeah. I only brought up fugit because the discussion turned to "what type would a clock-count implement"?
<firefrommoonligh>
Btw, there is, of course, the option to use a hardware RTC, and convert its reg values to Chrono datetimes etc!
<adamgreig[m]>
it doesn't need to appear in the trait API
<BenPh[m]>
adamgreig[m]: yeah. hard-coding u64 or u32 rules out anyone ever being able to make a portable interface that uses something like fugit to improve ergonomics.
<adamgreig[m]>
I'm not sure returning a fugit type from the timer trait is better ergonomics than elasped_millis()->u32, though
<firefrommoonligh>
adamgreig[m]: Hah interesting. Also "inspired" but not aping std::time I guess?
<firefrommoonligh>
I was using "as_ms" etc, but recently changed to "as_millis" to match std::time
pronvis has joined #rust-embedded
<BenPh[m]>
adamgreig[m]: I strongly disagree with forcing a specific type.
<jannic[m]>
And it still doesn't cover handling of overflows.
<BenPh[m]>
that's intentional
<jannic[m]>
But makes it useless.
<BenPh[m]>
let me quickly put together an example where overflow is handled. gimme 5 mins or so...
<adamgreig[m]>
we're over time for the meeting and I have to run, thanks everyone! as usual feel free to continue...
<jannic[m]>
Just one quick question: I noticed that the rust-embedded github repos contain a lot of old issues. Many of them only had a few comments and didn't get new comments for months or years. I wonder if we should try to do some cleanup and perhaps close those which are mostly ideas or feature requests, without any sign of activity?
<jannic[m]>
Would that be a good agenda topic for one of the next meetings?
<adamgreig[m]>
Ben Ph: having all those unconstrained associated types will just not get accepted into e-h, we had that sort of thing and it just didn't work, so what people are saying is if you want something that makes its way into embedded-hal, it will have to be different somehow
<adamgreig[m]>
jannic: sounds good, we could try and work through a bunch in the meeting perhaps too
pronvis has quit [Ping timeout: 240 seconds]
<adamgreig[m]>
if they become constrained to be fugit types you at least have a sensible type, but then the argument is about having fugit in the e-h API
<dirbaio[m]>
Can you share working code of how the `wait_for_ready` function would look like with your trait instead?
<dirbaio[m]>
this is a good way to test how easy/complex it is to use in a real-world driver
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
^ just an FYI that this implementation on arm cortex will time travel on any clock besides the systick. Sorry to jump in
<FreeKill[m]>
(I am only seeing messages flash past)
<dirbaio[m]>
the trait you've posted above leaves so many things up to the implementation that I don't think it's possible to implement a wait_for_ready with it.
<BenPh[m]>
leave it with me, and I'll see what I come up with.
<dirbaio[m]>
keep in mind wait_for_ready should ideally be written so that it works with ANY TimeCount implementation.
<dirbaio[m]>
i.e. it must not do things like `where T: TimeCount<RawData=u32, TickMeausre=...>` because then it's ruling out implementations.
<BenPh[m]>
actually no, can tell you right now
<BenPh[m]>
let start_time = timer.try_now();
<BenPh[m]>
if timer.try_now().duration_since(start_time).as_secs() >= 1
<dirbaio[m]>
please provide a full playground example that can be compiled
<dirbaio[m]>
try_read() returns a Self::CountMeasure which has no trait bounds, so I can't see how can you call .duration_since() on it
<BenPh[m]>
sorry, I forgot that prototypes aren't allowed to be a tool to explore possibilities.
<dirbaio[m]>
is that sarcasm?
<BenPh[m]>
I'm happy to respond to comments, but right now, I feel like the sub-text is "dance, monkey!"
<dirbaio[m]>
look
<GrantM11235[m]>
I think it is reasonable for people to ask to see your proposal
<dirbaio[m]>
i've invested many hours in this chat, discussing this with you
pronvis has joined #rust-embedded
<vollbrecht[m]>
"actualy no, can tell you right now" -> please just take your time and we can have a look. This is not going anywhere
<vollbrecht[m]>
prepare a RFC with your proposal and we can discuss on code
<vollbrecht[m]>
till than i think there is not much left in the "pregame"
<dirbaio[m]>
i've spent a lot of time trying to explain to you the goals of embedded-hal
<BenPh[m]>
doesn't feel like it
<vollbrecht[m]>
guys maybe take a step back, think 10 min what you want to answer to that or leave it at that
<dirbaio[m]>
you're proposing a design that doesn't work with these goals
<dirbaio[m]>
i'm trying to explain to you why
<dirbaio[m]>
every time I pose you a question in prose, you either dismiss it or say "yes of course it works"
<dirbaio[m]>
so my goal with that playground example is to drive discussion forward by lowering to actual code
<dirbaio[m]>
because with actual code it becomes obvious whether something works or doesn't work
pronvis has quit [Ping timeout: 268 seconds]
<dirbaio[m]>
and there's no room for dismissing away questions, you can't dismiss away the typechecker
<BenPh[m]>
> i.e. it must not do things like where T: TimeCount<RawData=u32, TickMeausre=...> because then it's ruling out implementations.
<BenPh[m]>
that's not asking me to engage with a comment. that's asking a monkey to dance.
<dirbaio[m]>
i'm personally quite sure that the trait in your RFC doesn't allow implementing a wait_for_ready that's portable across all implementations
<dirbaio[m]>
and given the embedded-hal goals, the trait that we merge has to allow implementing a wait_for_ready
<dirbaio[m]>
ti's a pretty basic use case
<BenPh[m]>
if you set the goal poasts without leaving any room for finding nice solutions, then why even bother asking someone to spend the time to work on it?
<dirbaio[m]>
as a maintainer of embedded-hal yes, it's my job to set the goal posts
<dirbaio[m]>
and it's your job to show your proposed trait meets these goal posts
<dirbaio[m]>
and I think a "wait for a pin to go high with a 1s timeout" is a very reasonable, basic goal post
<dirbaio[m]>
I personally don't see how your trait as it is can meet that
<dirbaio[m]>
it's your job to show to me that i'm wrong, that it can
<dirbaio[m]>
or to propose a different trait that can
<dirbaio[m]>
I can assure you my intent is not to make you waste time with pointless errands
<dirbaio[m]>
I too want a timer trait in embedded-hal
<dirbaio[m]>
we all do
<vollbrecht[m]>
<BenPh[m]> "if you set the goal poasts..." <- you can do that all day long - but you have to see that it has no merit to discuss something that doesn't even exists. And from my perspective you suggest that you already have cocked something up. So how should scrutiny applied here? If you are not at that stage that is absolutely no problem! Just state it as such, and then when its finished we can go from there.
<vollbrecht[m]>
For the other case where you just want an "open" discussions because you are not actually wanting code but just want to through ideas back and forth, that is fine but should be Label as such and not be "i want exactly this" but actually i am only through around ideas. Its fine to do that here but we should distinguish clearly.
<dirbaio[m]>
i'm trying to drive discussion forward by proposing an objective test case that the trait has to pass
<dirbaio[m]>
we've spent a lot of time discussing the trait in "prose" (words, not code)
<BenPh[m]>
You know, I don't think i've gotten one encouraging comment, feedback, critique or engagement of any form. I don't have any desire to have my ego stroked, but for fucks sake, the moment I hear something along the lines of "okay, that looks interesting, but I'm concened about $USE_CASE", instead of "Well, I don't see how it could work, so here are all the reasons why I don't like it", then perhaps I wouldn't be pissed off.
<vollbrecht[m]>
s///, s/Label/labeld/
<dirbaio[m]>
the discussion has gone in circles a lot, mainly because many of the criteria are subjective
<dirbaio[m]>
so I was trying to move the discussion forward by shifting it to objective criteria
<dirbaio[m]>
"can you impl a wait_for_ready with it? yes/no" is an objective criteria
<BenPh[m]>
not once have I read something from you that doesn't ooze discouragement in its subtext.
<dirbaio[m]>
that's your interpretation of my words
<dirbaio[m]>
when I tell you something in your trait doesn't work, my intent is not to discourage you, my intent is to arrive at a trait that does work
<dirbaio[m]>
nothing more
pronvis has joined #rust-embedded
<BenPh[m]>
and yet, despite your best efforts...
<BenPh[m]>
I mean, if I felt like I wasn't talking to a brick wall, perhaps this would be different. I don't think there's been one thing I've brought up that you haven't just dismissed out of hand.
<dirbaio[m]>
I don't "dismiss things out of hand", I explain to you what the issue is and why it is incompatible with the goal of embedded-hal
<jannic[m]>
Ben, I don't think anyone here has bad intentions. But you keep repeating arguments that have been discussed again and again, long before you came up with your proposal. It's difficult to stay patient. If you like it or not, if you want to make progress, and you are not convinced by arguments like "we thought about this before, it didn't work out", it's your turn to show that your suggestions actually work.
<dirbaio[m]>
exactly this ^
<GrantM11235[m]>
Keep in mind that there have been other timer traits before yours. It may seem like some aspects of your proposal are being dismissed out of hand, but that is because we have already seen the problems that can occur (for example underconstrained types)
pronvis has quit [Ping timeout: 240 seconds]
<dirbaio[m]>
an associated type Duration is exactly what the e-h0.2 timer had, and exactly why it was removed
<dirbaio[m]>
there's reasons why it doesn't work well
<JamesMunns[m]1>
I feel like I have been very supportive to your efforts Ben, but I think that dirbaio's requests are very reasonable. He is raising the same concerns I raised with you privately and publicly.
<JamesMunns[m]1>
I think you should listen to jannic and others, and please take some time to step away and come back to this. I would like to see you succeed, but discussing this in detail, with examples and counterexamples, is what is necessary to come to an agreement here.
<JamesMunns[m]1>
I think now would be a good time for everyone to pause on this discussion to avoid it getting heated.
<jannic[m]>
In part, it's probably our fault that we didn't take notes during these past discussions, so we can't just point to some kind of FAQ now, listing all the proposals that were discussed and dismissed for one reason or another.
<dirbaio[m]>
many of these discusisons are in github issues
<JamesMunns[m]1>
jannic[m]: I think we could definitely do better in these regards. I have some notes I wrote for Ben that I can contribute.
<jannic[m]>
Sure. But quite difficult to find.
<JamesMunns[m]1>
dirbaio[m]: Let's get it somewhere easier to find and agree on.
<dirbaio[m]>
> When a trait has an unconstrained associated type, it is not possible to write generic code around it. Each side (implementer and user) need to specify which type the associated type will be. If the types match, the both parts can work together, however, this is not truly generic code.
<dirbaio[m]>
> For example, if somebody creates a device driver that receives a CountDown struct, it needs to specify what its Time type should be. If they choose a type coming from fugit, somebody else cannot use this driver if the HAL implementation for the MCU they are using only provides CountDown with Time types defined in embedded-time. It is also not possible for the user to implement CountDown for Time types defined by fugit in a
<dirbaio[m]>
straight-forward way due to the orphan rule.
<JamesMunns[m]1>
I think this is fair, let's pick this up another time, to discuss if we need to document this somewhere easier to link to, or if we need to be more vocal. I had forgotten this list existed in one place.
<dirbaio[m]>
that's the problem all proposals with associated type Duration; or similar run into
<dirbaio[m]>
and the problem I wanted to highlight with the wait_for_ready use case
<FreeKill[m]>
I'm not sure this counts as pausing discussion 😅
<dirbaio[m]>
it's not indeed 🤣
<dirbaio[m]>
just wanted to point out the issue IS documented
kevlan[m] has joined #rust-embedded
<kevlan[m]>
Must be time for everyone to go for a walk and touch some grass.
<jannic[m]>
Thank you, the pointer to that github issue was very interesting, I wasn't aware of that. It shows that the discussion is even much older than I remember.
<vollbrecht[m]>
🎶 Wintersun - Land of Snow and Sorrow 🎶
<danielb[m]>
vollbrecht[m]: thank you. while I'm not sure how this is connected to the room, I need more metal in my life :D
pronvis has joined #rust-embedded
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
Lumpio- has quit [Ping timeout: 268 seconds]
Lumpio- has joined #rust-embedded
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
pronvis has quit [Ping timeout: 264 seconds]
<firefrommoonligh>
I appreciate that Ben's proposal drove me to fix timestamp code across my embedded firmwares. But I don't know if it's in a way that's compatible with a general trait.