<re_irc>
<@adamgreig:matrix.org> f32::from_bits() is probably best and avoids a division
<re_irc>
<@adamgreig:matrix.org> Invert the msbit and leave at the top, put 127 in the next 8 bits, shift the rest of the input right by 9 bits, something like that?
<re_irc>
<@whitequark:matrix.org> you would think so
<re_irc>
<@whitequark:matrix.org> but now you have to handle subnormals
<re_irc>
<@whitequark:matrix.org> well, not subnormals
<re_irc>
<@whitequark:matrix.org> your mantissa doesn't start with an implicit 1 in this case, which means that to adapt it to f32 format, you need to shift it and increase the exponent
<re_irc>
<@whitequark:matrix.org> which is to say, normalize
<re_irc>
<@whitequark:matrix.org> but now you have to ~~handle subnormals~~ normalize
<re_irc>
<@whitequark:matrix.org> (you can guess why i had the playrust link at a moment's notice :)
<re_irc>
<@adamgreig:matrix.org> Ah indeed, I guess you've thought about this before :p still it seems better than the cast, division z subtraction?
<re_irc>
<@adamgreig:matrix.org> * division,
<re_irc>
<@adamgreig:matrix.org> Maybe not actually
<re_irc>
<@whitequark:matrix.org> multiply by reciprocal
<re_irc>
<@jamesmunns:beeper.com> I _think_ mara had a post a while back that was something like this, where she tried progressively more cursed things, until she found that "as" ended up being the fastest and sanest
<re_irc>
<@jamesmunns:beeper.com> Ah, that was just for general int to float conversion, not necessarily in the normalized fractional range: https://blog.m-ou.se/floats/
<re_irc>
<@whitequark:matrix.org> : the reciprocal of 2^31 is an exact number, 0x1.p-31, which means that instead of what looks like a division, you really have a subtraction
<re_irc>
<@adamgreig:matrix.org> Yea, neat
<re_irc>
<@whitequark:matrix.org> the mantissa is 0 and the exponent is 2^-31, so it's just a subtraction of exponent
<re_irc>
<@whitequark:matrix.org> which means that u32 as f32 does the normalization for you
<re_irc>
<@adamgreig:matrix.org> Makes sense since it's basically doing what you'd do manually, yep
<re_irc>
<@adamgreig:matrix.org> Even moreso when you want the output to be -1 to 1 as in this case
<re_irc>
<@dngrs:matrix.org> ok, so ... convert "as f32" and then normalize?
<re_irc>
<@dngrs:matrix.org> +using
<re_irc>
<@jamesmunns:beeper.com> Trust Whitequark and Adam more than me (I'm not sure if there was a concrete suggestion), but tbh what you're doing is probably fine, and probably will end up being optimal enough
<re_irc>
<@jamesmunns:beeper.com> * Catherine
gajwani_ has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<@whitequark:matrix.org> dngrs: yep
<re_irc>
<@dngrs:matrix.org> : awesome, thx!
gajwani_ has quit [Ping timeout: 260 seconds]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
gajwani_ has joined #rust-embedded
gajwani_ has quit [Ping timeout: 260 seconds]
dc740 has joined #rust-embedded
m5zs7k has quit [Ping timeout: 265 seconds]
m5zs7k has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
<@juliand:fehler-in-der-matrix.de> Hey,
<re_irc>
From what I see in existing drivers, nb is widely used, but my understanding is that the future is going to be async. (Please correct me if that's wrong.)
<re_irc>
I would like to ask for your recommendations regarding new (non-blocking) drivers using embedded-hal.
<re_irc>
So for example for a driver that relies on bit-banging, I would need to block on a timer between setting the pin high and low.
<re_irc>
How would a proper non-blocking implementation currently look like? Is async/await mature enough?
<re_irc>
If not, would it still be a good idea to go for async/await in order to make the driver future-proof?
<re_irc>
If so, are there any examples/guidelines for this?
dc740 has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> Yeah IMO the future for non-blocking is definitely async. It's very usable right now, but still does have some rough edges and requires nightly (for normal use. It is possible to use stable, but I don't recommend going that way).
<re_irc>
As for the bit-bang, you'd need an async timer to wait on.
<re_irc>
Only question then is if that gives you enough 'realtime' guarantees. Async is cooperative so even if the timer goes off, your bitbang code may not continue in time
<re_irc>
<@thejpster:matrix.org> I took a wander around a Rust group on Linked In. This may have been an error.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Sounds good, thanks for your input. Are you aware of any driver that already uses async?
<re_irc>
As for the bit-bang: That is certainly true, however I feel like bit-banging in any non-blocking manner is going to be somewhat unreliable. For my use-case, the tolerances are pretty high, so it should work just fine.
<re_irc>
<@diondokter:matrix.org> : An async driver usually isn't very special. The major difference is that you need to use the async hal and need to put async and await in the code.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Makes sense. And to provide a blocking interface, I would usually make a second crate? Or is it better implement it as crate features?
<re_irc>
<@diondokter:matrix.org> : Well, that's a good question that I don't have an answer for. Still figuring that out myself
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Let me know if you figure it out ;) For now, I will have a look at the existing drivers and try to figure out a way for myself.
<re_irc>
Thanks for the help!
dc740 has quit [Remote host closed the connection]
bpye has quit [Ping timeout: 256 seconds]
bpye has joined #rust-embedded
bpye has quit [Ping timeout: 248 seconds]
bpye has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
WSalmon_ has quit [Ping timeout: 246 seconds]
WSalmon_ has joined #rust-embedded
gajwani_ has joined #rust-embedded
gajwani_ has quit [Remote host closed the connection]
<re_irc>
<@vollbrecht:matrix.org> : with the latest rust nightly compiler i cant build embedded-io v0.3.1 anymore it because it complanse that impl tait's are unstable but not marked as create attritbutes.
<re_irc>
<@vollbrecht:matrix.org> * ibecause
<re_irc>
<@vollbrecht:matrix.org> is that expected ?
<re_irc>
<@dirbaio:matrix.org> they added a new feature explicitfor "impl Trait in associated type position"
<re_irc>
<@dirbaio:matrix.org> * explicitly for
<re_irc>
<@dirbaio:matrix.org> I recommend you switch to embedded-io 0.4 which uses real async fn in traits, not "impl Future"
<re_irc>
<@vollbrecht:matrix.org> yeah i thought i will get that answer 😅
<re_irc>
<@dirbaio:matrix.org> if you want to get 0.3 updated please send a PR against the v0.3.x branch and I'll release it
<re_irc>
<@dirbaio:matrix.org> but i'm not sure if the breakage affects only the crate defining the trait only, or all crates with impls
<re_irc>
<@vollbrecht:matrix.org> nah its fine will have a look
<re_irc>
<@vollbrecht:matrix.org> i think we only get it into esp-idf-svc via embassy-sync but have to double check here
<re_irc>
<@dirbaio:matrix.org> oh oops
<re_irc>
<@dirbaio:matrix.org> let me release a new embassy-sync then. I didn't realize the released version still depended on 0.3
<re_irc>
<@dirbaio:matrix.org> unfortunately it'll have to be embassy-sync 0.2