<ian_rees[m]>
I need to manage a few settings (and logging would be nice) on a firmware that will be able to provide WiFi but sometimes without an Internet connection. Wondering if there's a go-to crate for providing a REST API over HTTP(S) for this sort of thing?
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<thejpster[m]>
Do you want to write the server side or the client side?
Foxyloxy has quit [Read error: Connection reset by peer]
chrysn[m] has joined #rust-embedded
<chrysn[m]>
On the use of defmt in library crates: A library crate can use defmt in two ways building on each other -- it can impl defmt::Format on its types (no harm done, no code emitted), and it can actually use it (as in debug!, but also panic! etc).
<chrysn[m]>
Should those be distinguished in its features?
<chrysn[m]>
I think so, because other crates might just want to promise that their items are Format, but to do that they'll need the trait impls but not necessarily the macros-using-it.
<dirbaio[m]>
if the user wants defmt::Format impls it's because they're using defmt
<dirbaio[m]>
in which case it's fine to use debug! etc
<chrysn[m]>
it's not that simple if the user is a library
<dirbaio[m]>
and if the user doesn't want to see debug messages from the lib, they can filter them out with DEFMT_LOG which makes them compile to nothing.
<chrysn[m]>
if my lib depends on some other lib that has (and maybe uses) defmt, i can just depend on defmt and derive it without too much cfg-attr.
<chrysn[m]>
not quite: this means that all the libs that depend on it transitively have to pass through a defmt feature even to get the defmt-impl.
<chrysn[m]>
and having the defmt-impl available is practical not just for emitting defmt, but also to test that it can be emitted, and to reduce the cfg-attr stacking.
<chrysn[m]>
in particular, if my library has generic types, making any requirement that T: Format is extemely cumbersome in an ifdef'd situation.
<chrysn[m]>
especially now that defmt is 1.0 and there's an increased willingness to depend on it, providing defmt without feature gating is a practical thing applications can do (and they can even debug/trace without any penalty b/c those are off by default anyway and only enabled when someone does the rest of the setup).
<chrysn[m]>
but that only works if the transitive dependencies do not switch on their defmt::panic! macros as soon as defmt is selected.
<chrysn[m]>
almost, I'd say:
<chrysn[m]>
option Cprime: lib has one feature:
<chrysn[m]>
* lib ALWAYS provides defm::Format impls, and emits debug!/trace!, no Cargo features needed
<chrysn[m]>
* defmt: makes the lib use panic! and assert_eq! from defmt
<chrysn[m]>
* option Cprime: lib has one feature:
<chrysn[m]>
- lib ALWAYS provides `defmt::Format` impls, and emits `debug!`/`trace!`, no Cargo features needed
<chrysn[m]>
- `defmt`: makes the lib use `panic!` and `assert_eq!` from defmt
<dirbaio[m]>
hmmm
<chrysn[m]>
(and good to have you in chat: it's embassy-net where I've discovered this)
<dirbaio[m]>
I don't think that works
<dirbaio[m]>
#[derive(defmt::Format)] and defmt::write!() still emit stuff in the .defmt section, which blows up when building for std targets, especially windows/macos/ios
<dirbaio[m]>
so even option C would break
<dirbaio[m]>
Cprime would break more
<chrysn[m]>
I'll give that a try. It has worked for me so far on Ariel OS, which is no-std but whose linker script doesn't have a defmt section unless we go full defmt, and I've built some Cprime style applications for non-defmt output already.
<dirbaio[m]>
have you tried building for macos/ios/windows?
<chrysn[m]>
I will, and come back here.
<dirbaio[m]>
I know for a fact it makes the macos/ios linker explode
<dirbaio[m]>
windows not sure
<dirbaio[m]>
linux seems to ignore it just fine, but I'm not sure how strongly is it guaranteed
<chrysn[m]>
(I think it works b/c debug! and trace! are dead code unless explicitly enabled -- sure, if you set DEFMT_LOG=trace at build time, boom, but I'd argue that might be OK.)
<dirbaio[m]>
#[derive(defmt::Format)] isn't conditional on DEFMT_LOG
<chrysn[m]>
No, but unless it is top-level written it's dead code.
<chrysn[m]>
I'll try once I'm back!
<dirbaio[m]>
you're relying on rustc to optimize it all out before it reaches the linker, i don't think that's guaranteed
<dirbaio[m]>
a lot of dead code removal is done by the linker
<dirbaio[m]>
:(
<dngrs[m]>
<dirbaio[m]> "#[derive(defmt::Format)] and..." <- does it? I remember specifically adding macOS support for defmt linker sections
<dirbaio[m]>
hmm maybe it's more recent than me seeing it blow up
<dngrs[m]>
it's entirely possible my fix is inadequate
<dngrs[m]>
I only tested on macOS
<dirbaio[m]>
where you build a rust staticlib and then tell xcode to link it with the rest of the project
<dngrs[m]>
according to https://doc.rust-lang.org/reference/conditional-compilation.html ios is a separate target_os so that'd definitely be (part of) the reason. I'd guess the fix would be rather trivial (just add ios to the conditional) but can't guarantee it. If you can send me a project exhibiting the behavior I can give fixing it a try
<dngrs[m]>
(and if it works maybe it's better to check for target_vendor = "apple")
<dirbaio[m]>
I don't have it anymore, it was just that defmt was accidentally used in the ios build, I didn't actually want it
<dngrs[m]>
ok. If you run into it again, my offer will still stand :)
Foxyloxy has joined #rust-embedded
ivche has quit [Read error: Connection reset by peer]
<dirbaio[m]>
It's not rustc who's swallowing output here
<jason-kairos[m]>
After some tests I realize now that even armed with the potentially correct knowledge of debug flags, that certain aspects of a complicated third party build system doesn't play nice with the notion of inserting debug flags/env vars.
<jason-kairos[m]>
In this scenario I going to have to look at/fix things three errors at time. However, now that I know about the RUSTC_* flags, maybe I might be able to avoid it in the future.
<RobinMueller[m]>
cr1901: I have a low-level question about the MSP430. What is the easiest way to identify an interrupt vector inside a default handler? Is it even possible to identify the vector? I want to identify which interrupt was unhandled for debugging purposes
jackwilsdon[m] has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
ManuelHatzl[m] has quit [Quit: Idle timeout reached: 172800s]
Koen[m] has quit [Quit: Idle timeout reached: 172800s]
ragarnoy[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio- has quit [Ping timeout: 252 seconds]
pcs38 has quit [Quit: leaving]
Lumpio- has joined #rust-embedded
<cr1901>
RobinMueller[m]: Good question... I think how I did this was to make each handler a different function that funnels into a shared #[inline(never)] function, and then look at address on the stack