ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
xnor has quit [Ping timeout: 246 seconds]
genpaku has quit [Ping timeout: 250 seconds]
genpaku has joined #rust-embedded
bjc has quit [Ping timeout: 248 seconds]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
rektide has quit [Ping timeout: 268 seconds]
rardiol has quit [Ping timeout: 246 seconds]
lehmrob has joined #rust-embedded
Shell- is now known as Shell
lehmrob has quit [Ping timeout: 246 seconds]
mightypork has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
<re_irc> <@eldruin:matrix.org> I have seen the shared bus impl PRs as well and have added them to the 1.0.0 milestone but I have not reviewed them in detail since they are waiting on other PRs. I have at least commented on every other PR I think.
<re_irc> <@jannic:matrix.org> If I have a delay implementation that can work with a shared reference, what's the best (most useful) way to implement the eh-1.0 trait?
<re_irc> e.g. I have:
<re_irc> impl MyDelay {
<re_irc> fn delay_us(&self, us: u32) -> Result<(), Self::Error> {...}
<re_irc> let my_delay = MyDelay::new(...);
<re_irc> So application code could do this:
<re_irc> let driver1 = Driver1::new(&my_delay, ...);
<re_irc> let driver2 = Driver2::new(&my_delay, ...);
<re_irc> But the e-h trait "DelayUs" takes "&mut self". So if the drivers are not tightly coupled with "MyDelay", but are implemented in terms of "embedded_hal::delay::DelayUs", this won't work.
<re_irc> Is there some way to use the trait and still use the same delay object for two drivers?
<re_irc> <@ryan-summers:matrix.org> : I think the general approach is "impl embedded_hal::delay::DelayUs for &mut MyDelay"
<re_irc> <@ryan-summers:matrix.org> * &MyDelay"
<re_irc> <@ryan-summers:matrix.org> So you impl the trait for the reference as opposed to the object itself
<re_irc> <@jannic:matrix.org> Ok, so in the end one actually calls some function "delay_us(&mut &MyDelay, ...)", internally. But that signature is not actually visible so it doesn't hurt usability.
<re_irc> <@ryan-summers:matrix.org> Correct
<re_irc> <@jannic:matrix.org> Thanks, I'll try that :-)
<re_irc> <@ryan-summers:matrix.org> You actually will see this method in some HALs for the delays for this exact reason
<re_irc> <@ryan-summers:matrix.org> Can't recall which off the top of my head though
<re_irc> <@jannic:matrix.org> Actually I already tried this approach a few days ago and now I think it was already correct back then:
<re_irc> #[cfg(feature = "eh1_0_alpha")]
<re_irc> impl eh1_0_alpha::delay::DelayUs for &Timer {
<re_irc> let end = self.get_counter().ticks().wrapping_add(us.into());
<re_irc> fn delay_us(&mut self, us: u32) {
<re_irc> loop {
<re_irc> let ts = self.get_counter().ticks();
<re_irc> if ts >= end {
<re_irc> return;
<re_irc> }
<re_irc> }
<re_irc> }
<re_irc> }
<re_irc> But then I tried this and it failed:
<re_irc> let timer = rp2040_hal::Timer::new(pac.TIMER, &mut pac.RESETS);
<re_irc> timer.delay_ms(500);
<re_irc> But the only thing wrong was that I didn't take the reference, and rust doesn't do it automatically. So this works:
<re_irc> let timer = rp2040_hal::Timer::new(pac.TIMER, &mut pac.RESETS);
<re_irc> let mut delay = &timer;
<re_irc> delay.delay_ms(500);
<re_irc> Anyways, good to know that this is the canonical approach and that I'm not doing something stupid / over-complicated.
<re_irc> <@ryan-summers:matrix.org> A common approach is to "impl DelayUs for MyDelay" and "impl DelayUs for &MyDelay" to avoid that strangeness
<re_irc> <@ryan-summers:matrix.org> It's redundant, but it works to avoid the strange "let mut delay = &timer"
<re_irc> <@jannic:matrix.org> With a version 1.0.0 around the corner (maybe...): Wouldn't it be useful to cut a (hopefully) final alpha.10 first? alpha.9 is already half a year old and there were some breaking changes. It would be nice if we had some implementations ready right from the start.
<re_irc> <@jannic:matrix.org> (I'm talking about embedded-hal, of course)
rardiol has joined #rust-embedded
bjc has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
lehmrob has joined #rust-embedded
xnor has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
rardiol has joined #rust-embedded
<re_irc> <@almindor:matrix.org> if so we def. want https://github.com/rust-embedded/embedded-hal/pull/443 decided for the next alpha
<re_irc> <@firefrommoonlight:matrix.org> Hi! With SVD2Rust like "stm32-rs", is there a way to only build the target you want, with "make svd2rust"? Thanks!
<re_irc> <@adamgreig:matrix.org> Set the CRATES environment variable, like CRATES=stm32h5 make svd2rust
<re_irc> <@firefrommoonlight:matrix.org> Thx!
<re_irc> <@firefrommoonlight:matrix.org> Works great!
<re_irc> <@2:0x2c.org> oh i had hopes to use "embedded_time", but its "Instant" is generic over a "Clock", which makes all my code generic if I don't want to be tied to a specific clock
<re_irc> <@2:0x2c.org> even the "time" crate doesn't supply "Instant" with "#![no_std]"
<re_irc> <@2:0x2c.org> what am i missing?
<re_irc> <@rmja:matrix.org> Use embassy-time, it is the far easiest one to use.
<re_irc> <@adamgreig:matrix.org> Fugit might also be worth a look depending on what you want to do
<re_irc> <@2:0x2c.org> heh clearly there is a need for timekeeping in embedded, with all of these choices
<re_irc> <@2:0x2c.org> : looks like i have to carry around the NOM and DENOM parts there - doesn't look like i can easily use that in portable code
<re_irc> <@2:0x2c.org> maybe i should just define a "Millis(u32)" type
<re_irc> <@adamgreig:matrix.org> You don't have to - you can be concrete over a particular timebase and users just have to convert their instances into it
<re_irc> <@adamgreig:matrix.org> Check out the various type aliases like TimerInstantU32 or MicrosDurationU32 etc
<re_irc> <@adamgreig:matrix.org> (and that conversation is done efficiently and easily, at least)
<re_irc> <@adamgreig:matrix.org> In effect it's like saying you want to be told "the time in milliseconds using a u32" with the advantage that conversion to and from other timebases is done easily
<re_irc> <@adamgreig:matrix.org> : This is MillisDurationU32 in fugit, but you get all the helper methods and conversions
<re_irc> <@2:0x2c.org> well that's a duration, but i am interested in instants, i think
<re_irc> <@2:0x2c.org> i'm trying to determine how long a button has been pressed; seems like i need instants
<re_irc> <@adamgreig:matrix.org> You probably are interested in "duration since boot"?
<re_irc> <@adamgreig:matrix.org> I wouldn't be too worried about it
<re_irc> <@2:0x2c.org> duration since some other event
<re_irc> <@adamgreig:matrix.org> You could take a TimerInstantU32 but it's probably simpler to take a MillisDurationU32. Either way you're going to subtract two of them to get a new duration that you want to use
<re_irc> <@2:0x2c.org> hehe, semantic mixup
<re_irc> <@2:0x2c.org> so maybe i'll make a "Millis" type alias for "TimerInstantU32<1000>"
<re_irc> <@adamgreig:matrix.org> Sure. I think the duration types might be simpler for users who have a duration since boot or whatever though, dunno
<re_irc> <@2:0x2c.org> but what's an instant type good for then?
lehmrob has quit [Ping timeout: 248 seconds]
<re_irc> <@jannic:matrix.org> Isn't an "Instant" the same as "duration since boot"?
<re_irc> "rp2040_hal::timer::Timer::getCounter()" returns a "TimerInstantU64<1_000_000>", for example. The ticks counted by that are just milliseconds since boot.
<re_irc> <@diondokter:matrix.org> Instant and duration are analogous to a point and a vector.
<re_irc> An instant is a point in time while a duration is a span of time. There's different math involved even though the data is similar.
<re_irc> A negative duration makes sense, but a negative instant does not.
<re_irc> You can add two durations together, but adding two instants together does not make sense. That's like asking adding together the location of your phone and the location of your tv.
<re_irc> Hope this clears up the difference a bit.
<re_irc> But why be so pedantic? Correctness
<re_irc> <@firefrommoonlight:matrix.org> A negative instant could arise from a change of basis. HTH!
<re_irc> <@firefrommoonlight:matrix.org> Using your analogy, a duration might be more precisely described as the _length_ of that vector, found by taking the inner product of it with itself
<re_irc> <@firefrommoonlight:matrix.org> A negative instant could arise from a change of basis
<re_irc> <@firefrommoonlight:matrix.org> Things get messier if you're working with more than 1 time-dimension, of course. Perhaps we should get some PRs going for the more _general_ case
<re_irc> <@zaven:matrix.x24.tools> Hey how inappropriate would it be to post about a funded opening for a Master's degree here, on which rust will be used for embedded? Is there a better spot for that?
<re_irc> <@adamgreig:matrix.org> totally fine
<re_irc> <@adamgreig:matrix.org> in fact please do
<re_irc> <@jamesmunns:beeper.com> This is a good place! The general rules are "it must be relevant", and "don't do it too often (a couple times a month or so)
<re_irc> <@jamesmunns:beeper.com> also, feel free to tag "@rustembedded" on twitter too, if you'd like, same rules there :)
<re_irc> <@jamesmunns:beeper.com> This is a good place! The general rules are "it must be relevant", and "don't do it too often (a couple times a month or so)"
inara` has quit [Quit: Leaving]
inara has joined #rust-embedded
<re_irc> <@peter9477:matrix.org> : I think negative durations cause a panic right now... had one the other day I believe.
<re_irc> <@peter9477:matrix.org> (Or is that just in Embassy?)
<re_irc> <@dirbaio:matrix.org> both embassy and std duration are unsigned
<re_irc> <@dirbaio:matrix.org> embassy-time mirrors std exactly
<re_irc> <@peter9477:matrix.org> I would actually vote for changing that, though I assume it's a breaking change. Negative duration makes sense, or at least the concept of a negative delta between two instants in time makes sense, though "duration" may not be the right word for it.
<re_irc> <@peter9477:matrix.org> I had a timer, and was calculating the time remaining until it would fire, to use in a timeout. Once past the actual time, I got a panic because it was a negative time remaining. Easy enough to avoid the panic, but would have been simpler if I could just say calculate it, and then deal with positive/negative values appropriately.
<re_irc> <@peter9477:matrix.org> * timer (not a Timer, just a "future point in time"),
<re_irc> <@peter9477:matrix.org> Maybe a TimeDiff or something like that...
<re_irc> <@dirbaio:matrix.org> on embassy, or on std?
<re_irc> <@dirbaio:matrix.org> I'd rather embassy-time stay consistent with std
<re_irc> <@peter9477:matrix.org> I can cope with Duration as it is, and certainly not suggesting Embassy change to be different. I was just responding to the notion that a "negative Duration" is not an unreasonable concept, and aside from the possible "positive values only" connotation inherent in the name, it seems perhaps unnecessarily limiting to have it restricted to unsigned values.
<re_irc> <@firefrommoonlight:matrix.org> Perhaps we should add a complex duration as well, to cover the bases
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc> <@jamesmunns:beeper.com> "I would like to wait for 1.4 + 2.7j seconds", a statement dreamed of by the utterly deranged :D
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]