ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
fabic has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
<re_irc> <judithbnks> I'll help 10 people on how to earn $20,000 within 72 hours but you will pay me 10% of your profit when you receive it.
<re_irc> Note: only interested people should apply, drop a message let's get started
<Darius> definitely not a scam (tm)
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
fabic has quit [Ping timeout: 240 seconds]
cr1901_ is now known as cr1901
nort has quit [Ping timeout: 246 seconds]
emerent has quit [Ping timeout: 246 seconds]
limpkin_ has quit [Ping timeout: 246 seconds]
Ekho has quit [Ping timeout: 246 seconds]
Ekho- has joined #rust-embedded
emerent has joined #rust-embedded
limpkin has joined #rust-embedded
Ekho- is now known as Ekho
fabic has joined #rust-embedded
aspe has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
aspe has quit [Quit: aspe]
cyrozap-ZNC has quit [Quit: Client quit]
cyrozap has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
<re_irc> static MQTT_CLIENT_ID: &str = "rogue0";
<re_irc> <andres> Rust built in "concat!" doest not support such thing:
<re_irc> fn send() {
<re_irc> mqtt.send(concat!(MQTT_CLIENT_ID), "/my/topic", b"hello mqtt");
<re_irc> <andres> * "/my/topic"),
fabic has joined #rust-embedded
<re_irc> <mabez> andres: Will MQTT_CLIENT_ID be a fixed value?
<re_irc> <andres> I wanna change it during development that is why it would good if I can concat like this.
explore has joined #rust-embedded
<re_irc> <andres> conscat seems to be doing it:
<re_irc> <andres> * constcat
<re_irc> <andres> I wanna change it during development that is why it would be good if I can concat like this.
<re_irc> <mabez> A small hack I've used is to not declare it as "const" or "static", but to tuck it inside a macro
<re_irc> <mabez> e.g
<re_irc> <mabez> macro_rules! mqtt_client_id {
<re_irc> () => {
<re_irc> "rogue0"
<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 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 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> <James Munns> serde json core, probably
genpaku has quit [Ping timeout: 276 seconds]
<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 (, 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> <diondokter> Huh, I did not know that!
<re_irc> <James Munns> I'm trying to find where the docs say "double panics abort"
<re_irc> <James Munns> (in the rust docs, not necessarily embedded)
<re_irc> <James Munns> I know ferrous' teaching guide stated this, I'm trying to find where that is defined (RFC, reference, etc.)
<re_irc> <diondokter> So background for the people here:
<re_irc> I encountered a recursive panic loop and James and I both were under the impression that that should not be possible
<re_irc> <James Munns> I'll open a Rust issue
<re_irc> <ryan-summers> That's, uh, not great
<re_irc> <ryan-summers> 😅
<re_irc> <dirbaio> that's not fixable without overhead..
<re_irc> <diondokter> Yeah, I do think it actually aborts on double panic on pc's
<re_irc> <James Munns> Yeah, I'd say it happens in unwind mode
<re_irc> <James Munns> but I didn't realize it was specific to the unwind handler
<re_irc> <James Munns> I mean, an atomic bool check on panic isn't THAT much overhead
<re_irc> <James Munns> I know it's not perfect (on non-CAS targets), but like... it's going down anyway
<re_irc> <dirbaio> plus you can still have recursive hardfaults
<re_irc> <dirbaio> so adding that check doesn't fix anything
<re_irc> <diondokter> At least you can reboot instead of getting a stackoverflow
<re_irc> <diondokter> Now our devices were bricked
<re_irc> <diondokter> (in the test)
<re_irc> <dirbaio> wouldn't the watchdog reset anyway?
<re_irc> <diondokter> (We also have a watchdog running, so not really bricked)
<re_irc> <dirbaio> I just elevate all panics to hardfaults (panic handler is just "asm!("UDF")"
<re_irc> <dirbaio> then log and whatever on hardfault
fabic has quit [Ping timeout: 276 seconds]
<re_irc> <dirbaio> (which you should STILL do anyway, because you can have issues that go straight to hardfault, not through the panic handler)
<re_irc> <James Munns> Yeah, not arguing with your approach.
<re_irc> <diondokter> In our app it's the other way around. The hardfault panics. That way we can keep the panic info
<re_irc> <diondokter> But maybe that's a bad idea?
<re_irc> <James Munns> I'm not arguing "the current approach is wrong", just "the current approach is confusing"
<re_irc> <dirbaio> and then if your hardfault handler hardfaults, the core enters "lockup" instead of stackoverflowing
<re_irc> <dirbaio> and then the watchdog reboots it
<re_irc> <diondokter> Hmmmm that's true
<re_irc> <dirbaio> the hardware checks it for you, no AtomicBool check needed
<re_irc> <James Munns> Opened an issue for clarification:
<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> diondokter: hardfault handler logs stuff
<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> I've never seen it happen
<re_irc> <James Munns> dirbaio I mentioned the immediately abort behavior in the issue:
<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> <Lachlan> Have any of you used rustBoot?
<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> <Lachlan> Thank you! That’s very helpful
Shell has quit [Quit: ZNC 1.8.2 -]
Shell has joined #rust-embedded
<re_irc> <ryan-summers> +1 on James' advice, and I'm listening as well ;) I have a feeling there
<re_irc> <ryan-summers> there's a lot of other consultants here as well
explore has joined #rust-embedded
<re_irc> <thejpster> :waves:
nort has joined #rust-embedded
<re_irc> <dirbaio> what's the best practice when impling traits for Vec/Box?
<re_irc> <dirbaio> I want to impl "Write" for "Vec<u8>" in embedded-io
<re_irc> <dirbaio> add an "alloc" cargo feature, impl it for "alloc::vec::Vec"?
<re_irc> <dirbaio> or add an "std" cargo feature, impl it for "std::vec::Vec"?
<re_irc> <dirbaio> probably the 1st? so you can still use it in no-std?
<re_irc> <dirbaio> and in that case, should the "std" cargo feature force-enable the "alloc" feature?
<re_irc> <dirbaio> is there some weird edge case where referring to "Vec" from "alloc" is bad if you do have "std"?
<re_irc> <dirbaio> for example "managed" does this
<re_irc> <dirbaio> is that required? or can you simply always use "alloc"? 🤔
<re_irc> <James Munns> I think you can probably use just alloc?
<re_irc> <James Munns> the alloc crate is always (???) enabled on std, and std is just a re-export
<re_irc> <James Munns> If you find the contrary tho, lemme know. I'll probably fix that in postcard (it has both std and alloc features)
<re_irc> <dirbaio> in postcard you always use it from "alloc"?
<re_irc> <James Munns> I have both std and alloc vec impls
<re_irc> <James Munns> but returning "alloc::vec::Vec" to a std user should be fine, since it's the same type
<re_irc> <James Munns> so, my vote is "just add an alloc feature, maybe alias std to that because expectations"
<re_irc> <James Munns> but also "that's not what I've done in the past, but for no good reason"
<re_irc> <dirbaio> well I still have the "std" feature for other stuff
<re_irc> <dirbaio> so it'd be "make "std" autoenable "alloc""
<re_irc> <James Munns> I think I probably added a stdvec impl first, then added an alloc one later when someone requested it
<re_irc> <dirbaio> so if you enable "std" you still get the impl on "alloc::Vec" but that should still work because it's the same time
<re_irc> <dirbaio> * type
<re_irc> <James Munns> yup, I'm 99.9% sure that's correct
<re_irc> <dirbaio> cool, will try
<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> figured it out
<re_irc> <dirbaio> "dyn MyTrait" impls "MyTrait" automatically, but "&mut dyn MyTrait" doesn't
<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
<re_irc> <dirbaio> oh nice! :D
dc740 has quit [Remote host closed the connection]