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
jcroisant has joined #rust-embedded
SunClonus has quit [Quit: Leaving]
pflanze has quit [Read error: Connection reset by peer]
pflanze has joined #rust-embedded
inara has quit [Quit: Leaving]
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
inara has joined #rust-embedded
linfax has joined #rust-embedded
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<michaeldesilva[m> How can I get my probe-rs config to run cargo build --release as pre launch task?
<M9names[m]> add probe-rs run as a runner. run cargo run --release instead
<michaeldesilva[m> M9names[m]: I have `runner = "probe-rs run --chip STM32H747XIHx"` but that doesn't build the release
<M9names[m]> cargo run --release does that
<JamesMunns[m]> the runner just takes the binary built by cargo - so it works with both debug and release mode
<michaeldesilva[m> `runner = "cargo run --release && probe-rs run --chip STM32H747XIHx"` like that?
<JamesMunns[m]> nope
<M9names[m]> please look at the code i linked to
<michaeldesilva[m> M9names[m]: I already have that same config though? hmm
<JamesMunns[m]> do you want cargo run to build the release binary and not the debug binary?
<JamesMunns[m]> like, you want to avoid typing --release?
<michaeldesilva[m> JamesMunns[m]: well, the issue is the debug output is like 500K vs the 38K of release and I was/am still use dfu-util, but this is SLOW as molasses. But let me re-clarify, if I just stick to the default runner config, change something in my code, click on debug - it'll run probe-rs (and it says it is flashing the device) but my RTT logs show the **previous** data.
<michaeldesilva[m> I noticed I had to manually do another cargo build (irrespective of debug/or release) and then the next run of probe-rs (through VSCode) would work.
<JamesMunns[m]> I don't know about vscode, but the way `runner` works is:
<JamesMunns[m]> * it does `cargo build`
<JamesMunns[m]> * it passes the path to the executable to the command you specify
<JamesMunns[m]> like, it will never skip the cargo build step, which is why you don't need to specify it.
<JamesMunns[m]> but I'm confused, you said:
<JamesMunns[m]> "I still use dfu-util", but you are trying to use `probe-rs cli` which is like... the opposite of that?
<JamesMunns[m]> if you are using a vscode plugin, THAT doesn't use the runner config afaik - that's only if you type cargo run --release at the command line
<michaeldesilva[m> JamesMunns[m]: > <@jamesmunns:beeper.com> but I'm confused, you said:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tWxatWIHTwITnAYUItLLyCJf>)
<michaeldesilva[m> BUT fyi cargo run does everything I need
<JamesMunns[m]> yes
<JamesMunns[m]> cargo run will build the debug build, and flash it with your runner, cargo run --release will build the release build, and flash it with your runner.
<michaeldesilva[m> JamesMunns[m]: yeah that's just fine.
<michaeldesilva[m> michaeldesilva[m: The issue is this VScode setup (as per the probe-rs config) https://github.com/bsodmike/arduino-giga-r1-wifi-stm32h747xi-async-quickstart/blob/master/.vscode/launch.json
<michaeldesilva[m> I think I need to configure the preLaunchTask and get that to do a cargo build
<M9names[m]> have you tried putting cargo build --release in that spot?
<michaeldesilva[m> * I think I need to configure the preLaunchTask and get that to do a cargo build (and or pass --release)`
<M9names[m]> okay. i've finally caught up to where you started, where you said "prelaunch task" without specifying you wanted to know how to get vscode to do that.
<M9names[m]> a little context goes a long way
<michaeldesilva[m> ok it took a few more steps - I need to configure custom tasks
<M9names[m]> the other option is to make your debug builds optimised like release builds, since they're largely useless otherwise anyway.
<michaeldesilva[m> michaeldesilva[m: It needs... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bZcQeZooERNttSCstBBlLrXm>)
<michaeldesilva[m> michaeldesilva[m: and `"preLaunchTask": "rust: cargo run (debug)",`
<michaeldesilva[m> M9names[m]: > <@9names:matrix.org> the other option is to make your debug builds optimised like release builds, since they're largely useless otherwise anyway.
<michaeldesilva[m> ah. You'll laugh but I've been using this script I wrote 👀 https://github.com/bsodmike/arduino-giga-r1-wifi-stm32h747xi-async-quickstart/blob/master/upload.sh
<michaeldesilva[m> I've been taking the Arduino IDE process apart and arrived at that :D
<michaeldesilva[m> s/:D/😂/
<michaeldesilva[m> michaeldesilva[m: Hmm this has an issue though
<michaeldesilva[m> michaeldesilva[m: `cargo run` causes probe-rs to attach to the RTT output
<JamesMunns[m]> yeah if your other stuff already invokes probe-rs, then you don't want run, you want build
<JamesMunns[m]> also note that you SPECIFICALLY are using the release path here: https://github.com/bsodmike/arduino-giga-r1-wifi-stm32h747xi-async-quickstart/blob/master/.vscode/launch.json#L20
<JamesMunns[m]> so you'll need to use cargo build --release not cargo build
<michaeldesilva[m> no wonder!!!
<michaeldesilva[m> thanks
<michaeldesilva[m> JamesMunns[m]: Great catch, solved now!! I can throw away my bash script 😍
<michaeldesilva[m> <michaeldesilva[m> "`cargo run` causes probe-rs to..." <- Ok this is solved now, this is the working VSCode config https://github.com/bsodmike/arduino-giga-r1-wifi-stm32h747xi-async-quickstart/commit/fdafc00501cb91b37e38ba462ebc301d76db932b
nukka has joined #rust-embedded
sigmaris has quit [Quit: ZNC - https://znc.in]
sigmaris has joined #rust-embedded
nukka has quit [Ping timeout: 252 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
Henk[m] has joined #rust-embedded
<Henk[m]> <adamgreig[m]> "I've made this room actually, so..." <- I'm interested!
<Henk[m]> > <@adamgreig:matrix.org> I've made this room actually, so please shout or message me if you're interested in attending
<Henk[m]> * I'm interested! Can you invite me?
korken89[m] has joined #rust-embedded
<korken89[m]> Alright generic gurus assemble! I'm trying to write an algorithm generic over atomic width. More or less, I want to build a `BitChannel` where the atomic holds flags from `bitflags` crate. The thing is, below is my try to make an atomic that is generic over width - i.e. place stuff in memory and dance it like it was an atomic. Is there any... (full message at
<diondokter[m]> So basically the num crate, but for atomics?
<korken89[m]> Yeah
<diondokter[m]> You're creating your own trait, so you could implement it on the atomic types directly
<diondokter[m]> Why the unsafecell business?
<diondokter[m]> Ah I see
<korken89[m]> I could, but how would one make the genericlly sized atomic then?
<korken89[m]> I use unsafecell to get the right size, and then cast to atomic to get right operations in a sense
<diondokter[m]> Ok, so now you have an e.g. AtomicStorage<u16>
<korken89[m]> Correct!
<korken89[m]> I have 2 tests that will generate `AtomicStorage<{u8, u16}>` as follows:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/jJEzXDXmfzVKBLuJDrmYppzr>)
<korken89[m]> Also, I have checked the asm, and it generates the correct asm - but the methods feels icky
<diondokter[m]> Ok, so what if something like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bDvoZeObhwfyVJtfGjHJvnRn>)
<diondokter[m]> Ok, let me open the playground. Typing in here sucks :P
<korken89[m]> :D
<korken89[m]> Can one import a crate in playground? I generally use CompilerExplorer but get stuck when I need to import a crate
<diondokter[m]> Only like the top 100 popular or so
<korken89[m]> Auw
<diondokter[m]> I think there should be a way to connect it to the flags trait
<korken89[m]> Checking!
<korken89[m]> Ahh, neat - I'll try to adapt it to Flags!
<korken89[m]> Give me a sec
<diondokter[m]> So the advantage is that we simply encode which atomic type corresponds to which integer so we're able to use the correct atomic type. That way we don't have to do any unsafe spooky stuff
<korken89[m]> Yeah, quite nice! Lets see if I run into problems trying to make it connect :D
IlPalazzo-ojiisa has quit [Ping timeout: 264 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
<korken89[m]> Hmm, I'm getting stuck on converting between flags and this atomic type
<diondokter[m]> The Bits type on the flags are integers right?
<korken89[m]> The trait is implemented for integers
<diondokter[m]> So then you should be able to put extra bounds in places
<diondokter[m]> `where F::Bits: AtomicType`
<korken89[m]> But I can get the following to work
<korken89[m]> So to convert EMPTY to whats inside the atomic
<diondokter[m]> I didn't know you could convert integers like that
<diondokter[m]> Can you share the full thing you have now?
<korken89[m]> Absolutely!
<JamesMunns[m]> I feel like as-casting like that is going to hide errors, like if one is u8 and one is u16
<korken89[m]> It won't build though as bitflags is not there
<diondokter[m]> Maybe what could be done is something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bgIUNgNEDGtAtcmEfHQmwJQA>)
<korken89[m]> Hmm
<JamesMunns[m]> maybe zooming out: whatcha actually trying to do here? There's a lot of generics going on here and there might be a simpler way :D
<korken89[m]> I think my original approach was quite simple but required unsafe xD
<korken89[m]> <korken89[m]> "Alright generic gurus assemble..." <- > <@korken89:matrix.org> Alright generic gurus assemble! I'm trying to write an algorithm generic over atomic width. More or less, I want to build a `BitChannel` where the atomic holds flags from `bitflags` crate. The thing is, below is my try to make an atomic... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZBQJwFmfglEdCNzHEwVjmNyd>)
<diondokter[m]> Basically, store flags in a container where you can manipulate them atomically
<korken89[m]> Yeah, I know the inner type of bitflags is {u8, u16, ...}, so I just want them to be atgomic
<korken89[m]> * Yeah, I know the inner type of bitflags is {u8, u16, ...}, so I just want them to be atomic
<korken89[m]> So I needed a variable width atomic based on what underlying storage bitflags used for the type
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<JamesMunns[m]> I think the issue is getting Rust to realize that AtomicType::Target is what you pass to AtomicType's methods
<JamesMunns[m]> and since `AtomicType` doesn't define the methods there's no way to constrain the blanket impl so that `<T as Flags>::Bits` is the same type as `AtomicType::Target` and also the right type for the atomic methods?
<JamesMunns[m]> like, you could trait out all the atomic methods you care about to constrain that, but this seems... not what you want?
<korken89[m]> In my test I only did one, but I only need fetch_and and fetch_or for the datastructure
<korken89[m]> The thing is I can'
<korken89[m]> * I can't see why the same trick I used does now work on diondokter traits
<korken89[m]> I have to experiment a bit
<korken89[m]> * I can't see why the same trick I used does not work on diondokter traits
<JamesMunns[m]> can you just have some like `where Flags::Bits: Into<AtomicType::Target>` or something? like don't the bits impl into?
<JamesMunns[m]> then you do something like... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NrRPRnSvVgUPliMOXDucoKgp>)
<JamesMunns[m]> idk
<korken89[m]> Hmm, I'll give that a try as well!
<dirbaio[m]> you can remove the PhantomData even
<korken89[m]> Oh
<korken89[m]> Ah so the trick is to take in the atomic as an argument and not by self
<korken89[m]> Damn, getting so close xD Now I just want to get the new to be a const fn but this seems to be hard
<diondokter[m]> korken89[m]: I don't think that's gonna be possible because const doesn't exist for traits
<korken89[m]> As long as you base it on From I guess it won't happen
<korken89[m]> Yeahg
<korken89[m]> * Yeah
<diondokter[m]> I guess... You could have a const value on the traits though
<korken89[m]> Ah!
<diondokter[m]> * because const fn doesn't exist
<dirbaio[m]> add const ATOMIC_ZERO: Self::Atomic; yep
<JamesMunns[m]> you could probably just use the ::EMPTY assoc value
<korken89[m]> JamesMunns[m]: I tried this, but it needs converting
<JamesMunns[m]> ahhh right you lose the into, got it
<korken89[m]> Testing the trait const now
<korken89[m]> I was too slow :D
<korken89[m]> Yeeeee! No unsafe!
<korken89[m]> Very nice, thank you all for the assistance! Finally I can do watch dog handling generically with event flags in async, bye bye MPSCs feeding a task :D
Charles[m]1 has quit [Quit: Idle timeout reached: 172800s]
SunClonus has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
juliand[m] has joined #rust-embedded
linfax has quit [Ping timeout: 264 seconds]
SunClonusX has joined #rust-embedded
SunClonus has quit [Ping timeout: 256 seconds]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
posborne[m] has quit [Quit: Idle timeout reached: 172800s]
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
geky[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
spinfast[m] has quit [Quit: Idle timeout reached: 172800s]
SunClonusX has quit [Quit: Leaving]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]