Guest2495 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
causal has quit [Quit: WeeChat 3.6]
neceve_ has joined #rust-embedded
<re_irc>
<James Munns> nihal.pasham: Do you need it to be human readable? If so, there is also serde-json-core, which will get you JSON, if not, postcard might be good.
<re_irc>
<James Munns> Not sure if I've seen any no-std ini or toml parsers, but it should be possible with Serde.
<re_irc>
<nihal.pasham> Thanks for the tip. "json-core" looks interesting (might come handy for a future proj).
<re_irc>
my conf file is a simple ". txt" file. As it's a relatively small file, I went with rolling my own nom based parser.
VShell has joined #rust-embedded
VShell has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
<firefrommoonlight> Hi. I've heard Debug impls on structs and enums isn't ideal for embedded/no_std. Is this true?
<re_irc>
<firefrommoonlight> Is there a way to mitigate this in a library that's capable of no_std, and not? (Eg use Debug when on std, and not have it on no_std if it causes problems? Maybe just printing using the debug tag is where the problem arises? Thank you
<re_irc>
<adamgreig> there's no cost if you don't use the Debug impl
<re_irc>
<adamgreig> it's just that formatting machinery in general is expensive
<re_irc>
<adamgreig> defmt is a common alternative
<re_irc>
<dirbaio> if you do have "std", I can't think of any reason you'd want to _not_ use critlcal-section's "std" implementation..
<re_irc>
<dirbaio> but on the other hand it feels weird
<re_irc>
<adamgreig> I guess it depends on the library
<re_irc>
<adamgreig> just because it has a std feature doesn't mean it should enable c-s/std I don't think
<re_irc>
<adamgreig> but in that particular case maybe it makes sense? hard to imagine there wanting any other c-s impl
<re_irc>
<dirbaio> hmm
<re_irc>
<dirbaio> what example of lib with an "std" feature you _wouldn't_ make it enable "c-s/std"?
<re_irc>
<dirbaio> or, what's an example of a project you'd build for a target with "std" but still want a custom c-s impl?
<re_irc>
<dirbaio> btw, why feature-gate "critical-section" in PACs?
<re_irc>
<dirbaio> there's no downside to always having it enabled
<re_irc>
<dirbaio> "to avoid more deps" -> the c-s crate is tiny
<re_irc>
"to avoid failing the build if the user hasn't imported a c-s impl" -> it only fails to link if the user actually uses "Peripherals::take".
<re_irc>
<dirbaio> not that I care much, I'm personally not using PAC owned singletons anymore 😅
<re_irc>
<adamgreig> for platforms that don't have any c-s impl I think
<re_irc>
<adamgreig> bit annoying to have a function that the user can't call or they'll get a linker error
<re_irc>
<adamgreig> hmm
<re_irc>
<adamgreig> but it's a feature in the generated crate, not a command line flag for svd2rust
<re_irc>
<adamgreig> that does seem kind of unnecessary I guess
<re_irc>
<adamgreig> maybe we should have called it take-api or something :P
<re_irc>
<adamgreig> dirbaio: some random component driver or whatever?
<re_irc>
<dirbaio> yeah... but if the user enables the "std" feature they do have "std", so why wouldn't they want "cs/std"?
<re_irc>
<dirbaio> and isn't the goal to have c-s impls for all platforms?
<re_irc>
<adamgreig> dirbaio: hmm yea, I guess I can't imagine why a user on std would want any alternative impl of c-s
<re_irc>
<adamgreig> maaaaybe if they wanted to use parking lot's mutexes or something weird?
<re_irc>
<dirbaio> recent std's Mutex is as fast as parking_lot's
<re_irc>
<adamgreig> and yea, it is, but we're still waiting on msp430 and riscv, and don't control mips_mcu (though it seems like it will also soon get it)
<re_irc>
<adamgreig> I have to admit it seems more like something that could be an option to svd2rust, not an actual feature flag in the emitted PAC
<re_irc>
<adamgreig> wellllllll. I guess. I dunno.
<re_irc>
<dirbaio> there's avr too :P
<re_irc>
<adamgreig> in stm32ral I have a feature flag to _disable_ the singleton API
<re_irc>
<adamgreig> in general this might be a nice opportunity to softly discourage the use of the singleton api :p
<re_irc>
<adamgreig> probably not the best way to go about it though
<re_irc>
<dirbaio> uh
<re_irc>
<dirbaio> feels weird to still have the objects you can "own" if using them as signletons is discouraged
<re_irc>
<adamgreig> in that the pointer API just unsafely returns something you "own"?
<re_irc>
<dirbaio> yeh
<re_irc>
<dirbaio> * yeah
<re_irc>
<dirbaio> unsafe to obtain, safe to use, and not Copy/Clone
<re_irc>
<dirbaio> vs chiptool is safe to obtain, unsafe to use, and Copy/Clone
<re_irc>
<dirbaio> chiptool's are just raw pointer wrappers
<re_irc>
<dirbaio> you can even construct one from an arbitrary raw pointer safely
<re_irc>
<adamgreig> why not when it's safe to use I guess
<re_irc>
<adamgreig> * unsafe
<re_irc>
<adamgreig> hmm yea, so maybe for next svd2rust we should just have the c-s thing always enabled and not behind a feature gate or runtime flag, and anyway hopefully all supported arches will have a c-s impl available before that release (but even if not, it's only a problem when people using those arches generate a new pac with the new svd2rust)
<re_irc>
<dirbaio> and only if the user actually tries to _use_ "take" :)
<re_irc>
<adamgreig> well yea but they presumably would like to be able to :P
<re_irc>
<dirbaio> yeah, I mean it's not like it automatically fails the build by just _being there_, you have to _call_ it to get the "undefined reference" error.
<re_irc>
<adamgreig> in terms of finding the issue/being surprised, that might be worse
<re_irc>
<dirbaio> you still get the linker error if you've enabled the "critical-section" cargo feature in the pac but still don't supply an impl
<re_irc>
<dirbaio> the cargo feature doesn't protect from the linker fail :S
<re_irc>
<adamgreig> but only if you call take()?
<re_irc>
<dirbaio> yeah
<re_irc>
<GrantM11235> I would be more suprised if _enabling_ a feature works but _using_ it breaks everything
<re_irc>
<adamgreig> which is what we have now
<re_irc>
<dirbaio> I wonder if we can rename the "extern fn"s to something like "you forgot to supply a cs impl, see <link>"
<re_irc>
<dirbaio> so the user sees "undefined reference to "you forgot to supply a cs impl, see <link>"" 🤣
<re_irc>
<adamgreig> cortex-m-rt did this in the days before cargo had "links"
<re_irc>
<adamgreig> "#[export_name="error: cortex-m-rt appears more than once in the dependency graph"] pub static __ONCE__: () = ();"