<re_irc>
<mabez> You can use the macro version in concat
<re_irc>
<mabez> I'm sure there is a better way to do this, but this is the solution I found a couple of years ago
<re_irc>
<mabez> In your example "concat!(mqtt_client_id!(), "/my/topic")" now works
<re_irc>
<strawman> Hi All, I'm hitting a strange problem with cargo-binutils. On an interactive session on my linux workstation, I can build a binary (for thumbv7em-none-eabihf, set in .cargo/config) and check it with, e.g. "cargo size --release". However, in gitlab CI when I try to run the same command on a similarly configured linux environment, building the ELF binary seems to work fine but the binutils-specific stuff seems to find...
<re_irc>
... the ELF binary but interprets as empty. E.g. "cargo size --release" shows sizes of all sections 0. Any suggestions what to look for? I've already trying ensuring that the target is correctly set (which it is already in .cargo/config but also when "overriding" it by specifying this directly on the command line with --target.
<re_irc>
<adamgreig> is it possible your CI environment doesn't have the linker script set, e.g. because it's in your .cargo/config.toml file and that's not present/used?
<re_irc>
<adamgreig> or perhaps CI is setting a RUSTFLAGS environment variable that's overriding .cargo/config.toml?
cr1901_ has joined #rust-embedded
<re_irc>
<adamgreig> you can specify the linker script using your build.rs now, instead of .cargo/config, with "println!("cargo:rustc-link-args=-Tlink.x");", so maybe try that instead?
<re_irc>
<strawman> Ahh, I am setting RUSTFLAGS in CI (to error on compiler warnings). I will not do that and see if it that solves things. I will launch a new CI build now.
<re_irc>
<adamgreig> yea, that will override the rustflags setting you may have in .cargo/config that sets "-C link-arg=-Tlink.x"
<re_irc>
<adamgreig> I recommend putting the linker script in build.rs instead, then
cr1901 has quit [Ping timeout: 240 seconds]
<re_irc>
<strawman> wonderful, that hint fixed things. So much.
<re_irc>
<strawman> * Thanks so
cr1901_ has quit [Ping timeout: 240 seconds]
<re_irc>
<andres> What is preferred crate on embedded for json serde?
<re_irc>
<korken89> I know the quartic firmware uses JSON somewhere in there
<re_irc>
<korken89> Maybe have a look in there
<re_irc>
<korken89> I remember the quartic firmware uses JSON somewhere in there
dc740 has joined #rust-embedded
rektide has quit [Remote host closed the connection]
genpaku has joined #rust-embedded
rektide has joined #rust-embedded
<re_irc>
<ryan-summers> Quartiq definitely uses lots of JSON. We use it _primarily_ for miniconf (https://docs.rs/miniconf/latest/miniconf/), which we use as a run-time settings configuration tool
<re_irc>
<ryan-summers> * It's used
<re_irc>
<ryan-summers> * is used
<re_irc>
<korken89> ryan-summers: Quick question, do you have a workaround for shipping f32s with "serde_json_core"?
<re_irc>
<korken89> * "f32"s
<re_irc>
<korken89> Or is the answer "don't"?
<re_irc>
<ryan-summers> You could probably feature-block it?
<re_irc>
<ryan-summers> We use f32's just fine
<re_irc>
<ryan-summers> The parsing support is pretty good - I think it got fixed a while back to be more robust
<re_irc>
<korken89> Ah, I though't "serde_json_core" used "ufmt"
<re_irc>
<korken89> * thought
<re_irc>
<ryan-summers> No, it implements all custom parsing FWIW
<re_irc>
<korken89> Ahh cool!
<re_irc>
<ryan-summers> I think there's only a few types it doesn't support like some of Rust's more exotic types
<re_irc>
<korken89> Awesome, thanks!
rektide has quit [Ping timeout: 272 seconds]
rektide has joined #rust-embedded
<re_irc>
<James Munns> A long time ago it wasn't as complete (or it was, but the lib hadn't released, which is why I made the temporary "core-serde-json" fork), but I think it has caught up in recent years.
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<James Munns> CC diondokter - TIL that in "panic = "abort"", double-panics recurse, NOT abort:
<re_irc>
<dirbaio> also, some chips reset on lockup, instead of hardfaulting
<re_irc>
<dirbaio> * halting
<re_irc>
<dirbaio> the nRF does
<re_irc>
<dirbaio> and you can check if the reset was due to lockup in POWER.RESETREAS, so you can log "OMG something is VERY broken" after reset
cr1901 has joined #rust-embedded
<re_irc>
<James Munns> (btw this is why I wrote panic-persist - it's very likely something/everything is terribly wrong on panic, and it's better to store the message and handle at the next "sanity" point after reboot, than at the dangerous panic point)
<re_irc>
<dirbaio> elevating panics to hardfaults has more advantages btw
<re_irc>
<diondokter> But how do you then log the panic if you immediately do a UDF in the panic handler?
<re_irc>
<dirbaio> for example, interrupts can't preempt your panic handler
<re_irc>
<James Munns> I know dirbaio does something similar by having a semi-non-vol log buffer that can be checked after soft reboot
<re_irc>
<dirbaio> I _don't_ log Rust's panic message in production, because it causes "fmt" bloat
<re_irc>
<diondokter> But you don't have access to the panic info in the hardfault handler
<re_irc>
<diondokter> Ah ok
<re_irc>
<dirbaio> I use defmt::panic everywhere I can
<re_irc>
<dirbaio> and for the rest of panics, I get just the PC value
<re_irc>
<diondokter> We've got enough space for the fmt bloat so far, so we've been lazy
<re_irc>
<thalesfragoso> dirbaio: Can defmt::panic panic ?
<re_irc>
<diondokter> Does a small panic handler get inlined? Otherwise the PC would just point to the panic handler...
<re_irc>
<James Munns> defmt::panic is user defined, so yes
<re_irc>
<thalesfragoso> I mean, it sure panics, what I meant is can the log on defmt panic ?
<re_irc>
<James Munns> by default (in the template) it just udfs
<re_irc>
<thalesfragoso> Hmm, but it wouldn't double panic anyways
<re_irc>
<dirbaio> diondokter: it doesn't, but if you build with "build-std-features=panic_immediate_abort" then the panic itself compiles to a "udf" so you get the PC of the panic
<re_irc>
<diondokter> Ah ok, neat!
<re_irc>
<dirbaio> for development I do have a Cargo feature that logs Rust's panic message then "udf"s
<re_irc>
<dirbaio> that would stack-overflow if the panic handler panics before the "udf", yes
<re_irc>
<dirbaio> I didn't think about that until today 🤣
<re_irc>
<dirbaio> this alone is a GIANT reason to elevate all panics to hardfault though
<re_irc>
<diondokter> Yeah, I think I will change our setup
<re_irc>
<James Munns> it's probably reasonable to disable interrupts on panic entry
<re_irc>
<James Munns> but
<re_irc>
<dirbaio> otherwise you can end up with crazy brokenness
<re_irc>
<James Munns> non maskable exceptions DGAF
<re_irc>
<dirbaio> like, multiple instances of the panic handler running, one in main and one in irq
<re_irc>
<James Munns> but yeah
<re_irc>
<James Munns> UDF/hardfault is a big powerful hammer
<re_irc>
<James Munns> CC adamgreig, probably good to take a peek at this issue in the next meeting. I have a feeling we should probably update some docs based on the reply, if it's not "oh shit we didn't mean that" (which it probably won't be).
<re_irc>
<James Munns> I haven't, but seen it around, and I know nihal.pasham (the author) hangs around here :D
<re_irc>
<Lachlan> Okay cool. I’m mostly curious if it’s been tested on production hardware yet.
<re_irc>
<dirbaio> embassy-boot is used in production by my company
<re_irc>
<dirbaio> +if you're looking for a production-ready BL,
<re_irc>
<Lachlan> Im looking for a bootloader that doesn’t require that the mcu be reset to switch to new firmware
<re_irc>
<diondokter> That's gonna be difficult because you can't realistically keep your old stack around after upgrading
<re_irc>
<James Munns> I mean
<re_irc>
<James Munns> you can either:
<re_irc>
- Just treat the used stack as "dead forever", or
<re_irc>
- Write some asm that resets the stack and jumps, using only register values
<re_irc>
<diondokter> If you want to prevent getting the peripherals reset, then you could reset the stack and then jump to the bootloader instead of resetting
<re_irc>
<James Munns> Lachlan: Any reason why you have this preference?
<re_irc>
<Lachlan> I can’t get into too much detail, but the mcu controls the power-state of a larger application computer through a gpio. I’ve been told that the mcu should be able to update without that gpio pulling down and resetting the application computer
<re_irc>
<James Munns> whew.
<re_irc>
<James Munns> SR latch/GPIO expander out of the question? :D
<re_irc>
<Lachlan> Hardware changes aren’t possible at this point
<re_irc>
<James Munns> evergreen comment
<re_irc>
<Lachlan> My first thought was a cap sized to hold it up long enough, but no
<re_irc>
<Lachlan> Indeed haha
<re_irc>
<diondokter> Which MCU are you using? Some manufacturers have a pin retention bit you can turn on. Though I have only seen that on an Atmel chip
<re_irc>
<James Munns> But yeah, your problem here is a bit larger: you need the bootloader to control that peripheral basically
<re_irc>
<James Munns> (like, the application can never be trusted to initialize that peripheral on boot, basically.
<re_irc>
<Lachlan> That’s true
<re_irc>
<Lachlan> It’s an stm32 part
<re_irc>
<James Munns> or, needs to get a flag from the bootloader saying whether to "initialize", or "just create without init, trust config"
<re_irc>
<diondokter> Hmmm yeah, I don't think that's available then
<re_irc>
<James Munns> reset to boot is really just a shortcut for bootloader devs, it reduces the room for inconsistent behaviors
<re_irc>
<James Munns> but yeah, it'd probably be possible to lightly tweak to avoid that.
<re_irc>
<James Munns> Then either:
<re_irc>
- always set up the gpio(s) (and all the dependant parts, like clocks!) in the bootloader, OR
<re_irc>
- Have the bootloader pass a "clean boot" flag, init when false, skip when true.
<re_irc>
<Lachlan> Yeah, definitely seems possible
<re_irc>
<Lachlan> I’m going to attempt to push back against the requirement first
<re_irc>
<James Munns> Protip for that: I find the "yes, but" method works really well, instead of "no we can't do that, it's too hard", go with "yes, we can do that, but it will take X weeks of effort. If we change the requirements to Y, no effort is required".
<re_irc>
<James Munns> basically: go in with negotiation, and if it costs X weeks of your time, vs N weeks of their time (to work around, limit features), you can make a more informed decision as a team whether X or N is more possible/important.
<re_irc>
<James Munns> (this is a consulting trick. the answer is never no, but sometimes the 'yes but' price is too much to bear)
<re_irc>
<James Munns> I'll build whatever folks want however they want it built, but I'm gunna charge what I charge, and they can listen to me or not, that's their decision :)
<re_irc>
<James Munns> Sometimes it is worth it to do the dumb cursed thing, because that's a better option than the sum total cost of all the workarounds/rescoping.
<re_irc>
<James Munns> (but having a mutual understanding of the cost makes that process much less contention. And "time" is directly related to "cost", even in free/non-billed projects)
<re_irc>
<James Munns> okay, enough consulting tips for an embedded channel :D
<re_irc>
<James Munns> (but having a mutual understanding of the cost makes that process much less contentious. And "time" is directly related to "cost", even in free/non-billed projects)
<re_irc>
<James Munns> (if you find it's not, please tell me :D)
<re_irc>
<James Munns> (I've already been wrong about one Rust thing today)
<re_irc>
<dirbaio> one does not simply finish learning rust
<re_irc>
<James Munns> Now I just need a database of the 100s of people I've trained to date, so I can email them every time I go "well actually, today I learned..."
<re_irc>
<adamgreig> email them "your training is now out of date, to sign up to a new training with a 10% discount..."
<re_irc>
<James Munns> I'll just keep a running errata doc published somewhere and link to it nowhere
<re_irc>
<dirbaio> "rust 2021 is now out, all your knowledge is now deprecated"
<re_irc>
<adamgreig> idk why managed does that thing, I'm sure I've seen other crates just directly use alloc's vec for this purpose
<re_irc>
<James Munns> if someone says "but james said!", I can be like "ohhhhh, look, we already published that errata in 2021, what can you do"
<re_irc>
<dirbaio> _actually_, this IS true for C++ 💩
<re_irc>
<James Munns> thats the opposite
<re_irc>
<James Munns> it's deprecated, but WILL BE VALID CURSED KNOWLEDGE FOREVER
<re_irc>
<adamgreig> like a fine wine, if you wait long enough it will be very valuable expensive knowledge
<re_irc>
<dirbaio> everything you do in C++, there's the C way, the C++98 way, the C++11 way, the C++17 way....
<re_irc>
<adamgreig> the "C" way :P
<re_irc>
<dirbaio> oh, and the "with exceptions" way and the "-fno-exceptions" way
<re_irc>
<d3zd3z> Looks like Zephyr doesn't actually build with clang/llvm. So, I guess I get to continue with the hacky workarounds to combine gcc and clang generated code.
<re_irc>
<dirbaio> why is it that you sometimes have to "impl MyTrait for &mut dyn MyTrait"?? Shouldn't that be automatic?
<re_irc>
<dirbaio> so you can pass a "dyn MyTrait" to somewhere that expects a "MyTrait"
<re_irc>
<dirbaio> so the right thing to do is "impl<T: ?Sized + MyTrait> MyTrait for &mut T" I guess, so that covers "&mut dyn" but also other "&mut"s