09:00 <re_irc> <@paologentili:matrix.org> hi, is there any way to define two memory.x files and pick one using --feature?

09:02 <re_irc> <@diondokter:matrix.org> : Yes, kinda. You need to put it in your build.rs then

09:21 <re_irc> <@sjm42:matrix.org> https://github.com/sjm42/cortex-m-test2 <-- there is an example

09:22 <re_irc> <@sjm42:matrix.org> https://github.com/sjm42/cortex-m-test2/blob/master/build

09:26 <re_irc> <@thejpster:matrix.org> : I do this on the Neotron os. I have a binary for each linker configuration and switch the linker script based on the binary name in build.rs.

09:26 <re_irc> <@thejpster:matrix.org> https://github.com/neotron-compute/neotron-os

09:35 <re_irc> <@paologentili:matrix.org> thanks guys, I ended up with something similar to what suggested. I'm matching against the build profile actually.

11:10 <re_irc> <@firefrommoonlight:matrix.org> Nice! I'm also going to start using something like this

11:25 <re_irc> <@firefrommoonlight:matrix.org> *It works!

11:26 <re_irc> <@firefrommoonlight:matrix.org> Can probe-rs's "runner" flag in "config.toml" be feature-gated in a similar way?

11:26 <re_irc> <@diondokter:matrix.org> : Only on target triple level I think

11:28 <re_irc> <@diondokter:matrix.org> But, it seems you can provide the chip argument by setting an env variable as well: https://github.com/knurling-rs/probe-run/blob/main/src/cli.rs#L27

11:28 <re_irc> <@firefrommoonlight:matrix.org> Oh nice!

11:29 <re_irc> <@diondokter:matrix.org> You should be able to set that variable in the build.rs

11:29 <re_irc> <@firefrommoonlight:matrix.org> That makes sesnse in context

11:29 <re_irc> <@firefrommoonlight:matrix.org> Hopefully this works:

11:29 <re_irc> [target.'cfg(all(target_arch = "arm", target_os = "none", feature = "h72"))']

11:29 <re_irc> runner = "probe-run --chip STM32H743VIHx" # to list chips, run `probe-run --list-chips.`

11:29 <re_irc> [target.'cfg(all(target_arch = "arm", target_os = "none", feature = "g42"))']

11:29 <re_irc> runner = "probe-run --chip STM32G473CEUx"

11:29 <re_irc> <@firefrommoonlight:matrix.org> Hopefully this works:

11:29 <re_irc> runner = "probe-run --chip STM32H743VIHx" # to list chips, run `probe-run --list-chips.`

11:29 <re_irc> [target.'cfg(all(target_arch = "arm", target_os = "none", feature = "h7"))']

11:29 <re_irc> runner = "probe-run --chip STM32G473CEUx"

11:29 <re_irc> [target.'cfg(all(target_arch = "arm", target_os = "none", feature = "g4"))']

12:23 <re_irc> <@roy.buitenhuis-tnl:matrix.org> I have a project that has svd2rust as build dependency. Now I am trying to add log (0.4.17) to my project as a dependency, but it won't compile as svd2rust uses the std flag on log. I have no clue why this is an issue, aren't build dependencies build totally separate from your embedded application's binary?

12:23 <re_irc> When I rename build.rs to build.rs.bak and comment out svd2rust under build dependencies, it compiles log without issues for no_std.

12:23 <re_irc> What am I missing here?

12:26 <re_irc> <@roy.buitenhuis-tnl:matrix.org> Actually trying to add gdbstub, which in turn adds log (0.4.17). But both give the same issue.

12:39 <re_irc> <@roy.buitenhuis-tnl:matrix.org> Apparently, I was using the old feature resolver because I was on edition 2018 still. 😅

13:02 <re_irc> <@dirbaio:matrix.org> : omg, does this work? 👀

13:31 <re_irc> <@mciantyre:matrix.org> : I've tried this in the past but had luck. See https://doc.rust-lang.org/cargo/reference/config.html#target

13:31 <re_irc> > Do not try to match on debug_assertions or Cargo features like feature="foo".

13:31 <re_irc> <@mciantyre:matrix.org> +never

13:32 <re_irc> <@dirbaio:matrix.org> :(

13:32 <re_irc> <@dirbaio:matrix.org> was too good to be true

13:33 <re_irc> <@halfbit:matrix.org> it worked for me when I tried it with the imxrt1060evk I have

13:34 <re_irc> <@halfbit:matrix.org> ohhh feature matching the runner, nvm

13:34 <re_irc> <@halfbit:matrix.org> I misread :-D

13:35 <re_irc> <@halfbit:matrix.org> don't features set some env vars though? maybe a little probe-run wrapper?

13:37 <re_irc> <@halfbit:matrix.org> CARGO_CFG_TARGET_FEATURE seems to be the thing, I guess it'd require a little wrapper though to sort out

13:37 <re_irc> <@sjm42:matrix.org> Never underestimate the power of a small shell script wrapper :p

14:04 <re_irc> <@dirbaio:matrix.org> TIL you can "break" out of a "{}" block:

14:04 <re_irc> break 'a 1234;

14:04 <re_irc> 5678

14:04 <re_irc> let foo = 'a: {

14:04 <re_irc> };

14:04 <re_irc> assert_eq!(foo, 1234);

14:06 <re_irc> <@ryan-summers:matrix.org> Why did I never know that. That's so useful

14:07 <re_irc> let res = match op {

14:07 <re_irc> Operation::Read(buf) => self.bus.read(buf).await,

14:07 <re_irc> let op_res = 'ops: {

14:07 <re_irc> for op in operations {

14:07 <re_irc> <@dirbaio:matrix.org> sort of useful to emulate "try" on stable:

14:07 <re_irc> Operation::Transfer(read, write) => self.bus.transfer(read, write).await,

14:07 <re_irc> Operation::Write(buf) => self.bus.write(buf).await,

14:07 <re_irc> Operation::TransferInPlace(buf) => self.bus.transfer_in_place(buf).await,

14:07 <re_irc> };

14:07 <re_irc> if let Err(e) = res {

14:07 <re_irc> break 'ops Err(e);

14:07 <re_irc> }

14:07 <re_irc> }

14:07 <re_irc> Ok(())

14:07 <re_irc> };

14:17 <re_irc> <@therealprof:matrix.org> Hah, I did actually know but couldn't think of any clever use.

14:19 <re_irc> <@dirbaio:matrix.org> would be cool to be able to break values out of non-infinite loops too...]

14:20 <re_irc> <@dirbaio:matrix.org> * too...\

14:20 <re_irc> <@dirbaio:matrix.org> * too...

14:20 <re_irc> <@therealprof:matrix.org> Hm, wasn't there a way to desugar a for loop into a while loop?

14:20 <re_irc> <@dirbaio:matrix.org> you can't break values out of "while"s either

14:21 <re_irc> <@dirbaio:matrix.org> I guess the trouble is: what value would be returned if no break runs

14:21 <re_irc> <@dirbaio:matrix.org> for/else? :D

14:21 <re_irc> <@dirbaio:matrix.org> let op_res = for op in operations {

14:21 <re_irc> Operation::Read(buf) => self.bus.read(buf).await,

14:21 <re_irc> Operation::Transfer(read, write) => self.bus.transfer(read, write).await,

14:21 <re_irc> let res = match op {

14:21 <re_irc> Operation::Write(buf) => self.bus.write(buf).await,

14:21 <re_irc> Operation::TransferInPlace(buf) => self.bus.transfer_in_place(buf).await,

14:21 <re_irc> };

14:21 <re_irc> if let Err(e) = res {

14:21 <re_irc> break Err(e);

14:21 <re_irc> }

14:21 <re_irc> } else {

14:21 <re_irc> Ok(())

14:21 <re_irc> };

15:33 <re_irc> <@therealprof:matrix.org> : https://doc.rust-lang.org/reference/expressions/loop-expr.html claims otherwise.

15:35 <re_irc> <@therealprof:matrix.org> And by "while" loop I of course meant "loop" loop. 😉

15:36 <re_irc> <@dirbaio:matrix.org> by while loop I meant while loop

15:36 <re_irc> <@dirbaio:matrix.org> 😅

15:43 <re_irc> <@firefrommoonlight:matrix.org> : Will keep you posted!

16:54 <re_irc> <@paologentili:matrix.org> Hi (again). My project works _perfectly_ fine but now I'm trying to make it work with our bootloader. I changed the flash origin and I enabled cortex-m-rt set-vec feature. As a result I have something that is partially working: I can receive commands over usart (hence interrupts are working), I can run logic but I'm not able to write data anymore. The buffer content is fine but on the other end I only receive one 0x00...

16:54 <re_irc> ... byte. The bootloader works fine with the previous version (non rust) of the fw. Any suggestions on how to debug this problem?

21:00 <cr1901> jamesmunns: Thought I'd give an update on postcard-infomem. I ran into a nasty bug on msp430. After several days, I found a (the?) problem: https://github.com/rust-lang/rust/issues/107612#issuecomment-1472377638

21:00 <cr1901> So, Idk I guess I'll write docs and file an actual bug report? Siiiiiiiiiigh

21:02 <cr1901> How is this relevant to you? Well... https://github.com/jamesmunns/postcard/blob/main/src/de/deserializer.rs#L77 This line is the one that gets miscompiled somehow on msp430. Linked issue is just my minimal repro.

21:05 <re_irc> <@jamesmunns:beeper.com> Oof :(

22:56 <re_irc> <@firefrommoonlight:matrix.org> : It does, in fact, _not_ work

22:56 <re_irc> <@firefrommoonlight:matrix.org> Ah well

22:57 <re_irc> <@firefrommoonlight:matrix.org> Open to ideas

22:57 <re_irc> <@firefrommoonlight:matrix.org> Also for RTIC interrupt names

22:57 <re_irc> <@firefrommoonlight:matrix.org> My process is clunky re commenting and uncommenting these things when changing hardware. The memory.x thing helps though!