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
cr1901 has quit [Quit: Leaving]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
cr1901 has joined #rust-embedded
dreamcat4 has quit [Quit: Connection closed for inactivity]
emerent has quit [Ping timeout: 256 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
juliand[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
lockna[m] has quit [Quit: Idle timeout reached: 172800s]
jake_001[m] has quit [Quit: Idle timeout reached: 172800s]
<SergioGasquez[m]> <JorgeDOrtizFuent> "I have had to use `networksetup..." <- Just opened a PR with the feedback from yesterday: https://github.com/esp-rs/book/pull/132. Any input is welcome!
t-moe[m] has quit [Quit: Idle timeout reached: 172800s]
WikeChao[m] has joined #rust-embedded
<WikeChao[m]> How can we properly use naked functions nowadays?
<JamesMunns[m]> <WikeChao[m]> "How can we properly use naked..." <- I haven't actually seen one in use, tho phil opp's blog os talks a little bit about using one for exception handlers: https://os.phil-opp.com/better-exception-messages/#naked-functions
<JamesMunns[m]> not sure how you're trying to use them.
<diondokter[m]> Ah man, I want naked functions to be stabilized. In some niche cases they are really nice!
<diondokter[m]> When I was working with trustzone I needed them. Instead I had to write the functions fully in global asm. Naked fn + local asm would've been much nicer
<JamesMunns[m]> I thought they were? maybe not tho
<JamesMunns[m]> Ah, blocked on https://github.com/rust-lang/rust/issues/90957 I guess
<dirbaio[m]> you can use global_asm! instead, which is stable
<diondokter[m]> Yeah, it's one of those things that's been open for years. Original RFC is from summer 2015 :P
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<M9names[m]> for anyone who wasn't around at that time: https://blog.rust-lang.org/2015/05/15/Rust-1.0.html
<dirbaio[m]> maybe this is worth doing an rc3? https://github.com/rust-embedded/embedded-hal/pull/547
<diondokter[m]> <dirbaio[m]> "maybe this is worth doing an rc3..." <- Is there any additional change yet for an RC3?
<diondokter[m]> If not, then IMO the change is too small to bother
<dirbaio[m]> that's the only one yeah. there's only small docs fixes
<dirbaio[m]> * docs fixes other than that
<dirbaio[m]> yea I agree it's small
<dirbaio[m]> but perhaps it has some unintended consequence we're not aware of now? dunno
<dirbaio[m]> a RC would allow scream-testing it
<dirbaio[m]> to mitigate risk a bit more?
<dirbaio[m]> imo it'd have to be a quite big consequence though for us to revert to `&self`
<dirbaio[m]> s/a/something/, s/consequence though//, s/`/`, though/
<diondokter[m]> Well, it'd only be in an RC for 14 days. Only pretty dedicated up-to-date people would see it, so...
<diondokter[m]> RC doesn't hurt (much) though
<dirbaio[m]> there's 14 days more to go until release
<JamesMunns[m]> https://grep.app/search?q=InputPin&filter[lang][0]=Rust
<JamesMunns[m]> Ah that's not a full list
<JamesMunns[m]> Tho it does only show up 267 times, a lot of which are embassy and esp-rs
<JamesMunns[m]> Almost every case I can see it is used with something else that requires &mut
<diondokter[m]> I think if anybody is gonna complain, it's gonna be HAL users, not HAL makers
<dirbaio[m]> driver writers
<dirbaio[m]> HALs can still provide &self, so users directly using a HAL can still have it
<diondokter[m]> dirbaio[m]: Ah yeah, I mean those as HAL users as well
<diondokter[m]> * I mean I count those as
<dirbaio[m]> actually hals could provide `&self` for all gpio? Output too
<dirbaio[m]> if the GPIO is atomic reg writes
<dirbaio[m]> I wonder if there's some downside to that
<diondokter[m]> Question is whether they should :)
<dirbaio[m]> if you think of a pin as kind of an AtomicBool, why not?
<dirbaio[m]> dunno!
<dirbaio[m]> mabez eldruin therealprof ryankurte if you're around 🙏
<diondokter[m]> Maybe a model where pins cannot be shared is better?
<diondokter[m]> OTOH, if you don't want to share a pin, then don't.
<diondokter[m]> I guess it's not the same as a pin implementing clone
<diondokter[m]> Maybe I want to be able to give a reference to a pin where the recipient can only read the state and not change it?
<dirbaio[m]> grr ci was red, fixed now
<dirbaio[m]> diondokter[m]: if it's an Input then the recipient can already only read
<dirbaio[m]> or you mean read the StatefulOutputPin state, but not change it? that seems very niche? 🤔
<JamesMunns[m]> &mut allows a swap, I guess
<JamesMunns[m]> if the type is the same
<diondokter[m]> It really depends on the hardware and how the HAL tries to model it
<diondokter[m]> I guess it's niche yeah...
Noah[m]1 has quit [Quit: Idle timeout reached: 172800s]
<jessebraham[m]> FYI we're not going to be able to get a release out implementing this version for `esp-hal`. We just published new HALs and I'm not going to cut a new release this close to the end of the year just for this. So, hope it works, good luck 😀
<jessebraham[m]> > mabez eldruin therealprof ryankurte if you're around 🙏
<dirbaio[m]> that's understandable, no worries
<jessebraham[m]> * FYI we're not going to be able to get a release out implementing this version for `esp-hal`. We just published new HALs and I'm not going to cut a new release this close to the end of the year just for this. So, hope it works out, good luck 😀
<dirbaio[m]> would still be helpful if you could change rc2->rc3 and do a CI run to see if something breaks, even if you don't release
<dirbaio[m]> if you want I can do it
<jessebraham[m]> Sure, we can update in `main`
<jessebraham[m]> <dirbaio[m]> "if you want I can do it" <- I don't mind doing the update, should be pretty straight-forward. Thanks though!
<dirbaio[m]> plus it's not wasted effort because you'll need it for the final 1.0.0 update :D
<dirbaio[m]> * 1.0.0 update anyway :D
<dirbaio[m]> 📣 embedded-hal 1.0.0-rc.3 released
danielb[m] has joined #rust-embedded
<danielb[m]> dirbaio[m]: So there wont be an rc.4?
<dirbaio[m]> hopefully not 😰
<danielb[m]> 🤭
<dirbaio[m]> 😬
<dirbaio[m]> haha I already found one issue trying to update embassy
<dirbaio[m]> works with `&self`, fails with `&mut self`
<dirbaio[m]> because Rust gives preference to the trait method because it's the only one that matches `&mut self`
<diondokter[m]> Ah
<diondokter[m]> That's annoying
<dirbaio[m]> apparently Rust gives more priority to "has the same kind of self param" over "inherent method and not trait method"
<dirbaio[m]> which makes no sense at all
mabez[m] has joined #rust-embedded
<mabez[m]> I guess the fix is just `(&*self).is_high()` in the trait impl?
<dirbaio[m]> yea
<mabez[m]> Not so bad imo
<dirbaio[m]> or fully-qualify it: Input::is_high(self)
<dirbaio[m]> ironically, changing StatefulOutputPin to require `&mut self` fixes that one 🤣
<dirbaio[m]> I even proposed it in that issue
<dirbaio[m]> the issue affects user code too, though
<diondokter[m]> Only when the trait is used
<dirbaio[m]> not sure how bad it is though, it only happens if you import the trait yes
<dirbaio[m]> which you probably wouldn't if you're using the hal-specific methods
<dirbaio[m]> it does work if you have it on a `&mut SomeStruct` though https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0412eeff38573b82754c65e707357a8e
<dirbaio[m]> autoref/autoderef rules are super whacky lol
<JamesMunns[m]> diondokter[m]: yes, tho the trait is always in scope in the impl of a trait
<dirbaio[m]> perhaps this weirdness is enough reason for HALs to not provide `&self` inherent methods?
<dirbaio[m]> maybe I can try it in embassy and see if someone screams
<diondokter[m]> I don't think I've ever shared a pin between two pieces of code, so I don't think we'd lose much
<dirbaio[m]> lol but 0.2 still requires `&self`, if I make the inherent one `&mut self` I can't call it from the 0.2 impl 😬
<diondokter[m]> is_high and is_high_non_mut
<dirbaio[m]> I guess yea
<dirbaio[m]> why is this so hard lol
<dirbaio[m]> drop support for 0.2? 🤣🙈
eyduhshethey[m] has joined #rust-embedded
<eyduhshethey[m]> especially when high
<JamesMunns[m]> I mean you could still do the qualified call, or yeah do the reborrow
<JamesMunns[m]> it'll all flatten to the same
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<dirbaio[m]> doesn't look too bad https://github.com/embassy-rs/embassy/pull/2287
<dirbaio[m]> I ended up going with "don't provide inherent `&self` methods"
<dirbaio[m]> no changes in user code required, other than adding muts
<diondokter[m]> Cool!
ChristianHeussy[ has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
Farooq has joined #rust-embedded
<Farooq> How good it is? rate it please
xiretza[cis] has joined #rust-embedded
<xiretza[cis]> not that it's really related to rust, but you need more heat
<JamesMunns[m]> More specifically, you probably need to heat the pads more. You usually want to heat the copper of the pad, then touch the pin, so that the solder flows on the pad, and then wicks up the pin
<JamesMunns[m]> usually, when I solder a through hole pad, I do these, about half a second or a second apart:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/sJwNsxXNKhyKEOkjHANKhCoU>)
<JamesMunns[m]> This guide from NASA (pdf): https://workmanship.nasa.gov/lib/insp/2%20books/links/sections/files/601.pdf has very good visual examples of what they all should look like
<diondokter[m]> This is also a helpful image:
<JamesMunns[m]> oh that's a good one
<adamgreig[m]> https://mightyohm.com/files/soldercomic/FullSolderComic_EN.pdf is nice too, and available in a bunch of languages now
<JamesMunns[m]> <Farooq> "How good it is? rate it please" <- Also I didn't notice initially, but it looks like one of the pins of the thing in background has ripped off the pad
<JamesMunns[m]> (unfortunately easy to do on cheap protoboards, where the holes are not plated)
<vollbrecht[m]> today you often dont have leaded solder anymore, unleaded solder looks a bit different and handles a bit different, you also keep that in mind
<vollbrecht[m]> * different, you should also keep
<xiretza[cis]> vollbrecht[m]: yeah, don't expect it to be shiny once cooled
<JamesMunns[m]> JamesMunns[m]: Honestly, a fun project is to use kicad to design protoboards in a shape and layout you like, since they are cheap as hell to make through JLC, and you can get quality plated through holes
<JamesMunns[m]> And you can do fun things, like add LEGO mounting holes: https://github.com/jamesmunns/brick-mount
<vollbrecht[m]> :D that looks funny. Btw is there a specification of the heat resistance of LEGO blocks?
<JamesMunns[m]> They probably state whatever plastic they use, I wouldn't solder ON it tho
<JamesMunns[m]> Looks like ABS, vaguely
<vollbrecht[m]> baseplate is "HIPS" from the document. Though yeah your contact points with the pcb are normal blocks
<JamesMunns[m]> It was a while ago, but 20x of those big ones in the back were 11.73 EUR, and 60 of the smaller proto ones for 11.56 EUR (plus shipping and import)
<JamesMunns[m]> So, more expensive than the aliexpress proto boards, but cheaper than the fancy adafruit protoboards, it took me a year or two to go through all of those :D
barnabyw[m] has joined #rust-embedded
<barnabyw[m]> ooh lego mounted PCBs are a really nice idea. I recently started using gridfinity baseplates and custom parts as a platform for prototypes but for some stuff lego would work really well too
Guest7282 has joined #rust-embedded
<jessebraham[m]> > you can play with it when you aren't building Serious Things
<jessebraham[m]> Very important, IMO
<JamesMunns[m]> If nothing else, it has had a fun side effect of setting a standard for my board designs: I design almost everything in multiples of 8mm now, just in case I want to put lego mounting rails on any of the edges :D
lulf[m] has joined #rust-embedded
<lulf[m]> <JamesMunns[m]> "I chose lego because:..." <- > <@jamesmunns:beeper.com> I chose lego because:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tetpikagHhsIMrZGdIsqMccM>)
<lulf[m]> Thanks for sharing the footprints!
kpcyrd[m] has quit [Quit: Idle timeout reached: 172800s]
<newam[m]> it's been a while since I have touched `async`. Searching isn't much help here, are these warnings at all relevant for embedded?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uPFGhmBJirhFtgnxzXynKvJh>)
<newam[m]> Oh, nevermind, found the list of auto traits here: https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits
<newam[m]> The first page of results all talk about the nightly auto trait feature :|
<adamgreig[m]> they added the lint when they stabilised AFIT, but basically just allow it for embedded stuff
<adamgreig[m]> we do in embedded-hal-async for instance
<newam[m]> Oooo that's the kind of detailed information I was looking for, thanks!
d3zd3z[m] has quit [Quit: Idle timeout reached: 172800s]
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
<therealprof[m]> <xiretza[cis]> "yeah, don't expect it to be..." <- Depends on the solder and the handling. PbSn can also get dull and modern Pb-free solders can also do shiny...
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 256 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
Jonathan[m]1 has joined #rust-embedded
<Jonathan[m]1> How do you use floating point on embedded?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PLfrjuSHStVnmWTbptNhXqgB>)
<firefrommoonligh> Does using num_traits' Float trait work?
<firefrommoonligh> num_traits is useful for this stuff in general, but I don't remember if it has floor
<JamesMunns[m]> hoooopefully fixed in the next stable, if the PR gets merged.
<Jonathan[m]1> Thanks! libm seems to have the functions I need
<Jonathan[m]1> So we that PR I'll be able to use the code above as standard rust? That will be nice indeed
<JamesMunns[m]> Jonathan[m]1: I think so!
<firefrommoonligh> Yea would be great
<firefrommoonligh> num_traits (Which I think can be configured to use libm or micromath) is in p much all my firmwares
<firefrommoonligh> It's not a big deal, but not having to add it to cargo.toml and every file that uses math methods would be an improvement
crabbedhaloablut has quit []
StephenD[m] has quit [Quit: Idle timeout reached: 172800s]