<re_irc>
<riskable> What am I supposed to use for "defmt" and "critical-section" with "rp2040-hal"? If I use "cortex-m = { version = "0.7", features = ["critical-section-single-core"] }" I get errors about "RawRestoreStateInner" trying compile "critical-section". If I get rid of that cortex-m feature flag I get linker errors like this: "rust-lld: error: undefined symbol: _critical_section_1_0_acquire" which suggests I need to "pick an...
<re_irc>
... implementation". How do I do that?
<re_irc>
<riskable> I'm using _both_ cores on my RP2040
<re_irc>
<riskable> Ahh, I figured it out: Had to add ""critical-section-impl"" to the "features" of "rp2040-hal" in my "Cargo.toml" (which isn't documented yet I don't think)
<re_irc>
< (@ithinuel:matrix.org)> Indeed, this feature is enabled by the BSPs but is off by default.
<re_irc>
< (@ithinuel:matrix.org)> * default on the hal
<re_irc>
< (@jamesmunns:beeper.com)> lmao I love it
<cr1901>
Am seeking sincere suggestions to make this look less awful
<re_irc>
< (@jamesmunns:beeper.com)> you can also "assert!(infomem.len() <= full_array.len);", asserts in const context will just fail the build
<cr1901>
I'm trying to get rid of the need to supply the full array size since it can be inferred by the assignment to VERSION
<re_irc>
< (@jamesmunns:beeper.com)> oh! If you also use the experimental postcard MAX_SIZE feature (you might need to impl some traits yourself :/), you can use that as the array size lol
<re_irc>
< (@jamesmunns:beeper.com)> cr1901: I have something amazing for you.
<cr1901>
That works, and I can turn it into a macro
<re_irc>
< (@chrysn:matrix.org)> It's kind of cool it works, but also makes the inability to just say "const EXAMPLE: [u8; _] = include_bytes!(...);" feel quite arbitrary.
<re_irc>
< (@jamesmunns:beeper.com)> btw c1901, I might be wrong, but I don't think "#[used]" always does what you want (ensure sections always make it to the binary). I think it's supposed to, but I've had troubles when I don't ALSO have a "KEEP" directive in the linkerscript
<re_irc>
< (@jamesmunns:beeper.com)> could be remembering wrong tho
<cr1901>
Correct, I got hit by that today
<re_irc>
< (@jamesmunns:beeper.com)> IF you want to get way more cursed, or ever want to to see what data is actually in that var (instead of just dumping it to a host or something), you might be interested in databake
<re_irc>
< (@jamesmunns:beeper.com)> which (iirc?) basically uses proc macros to build the struct at compile time, so you can get a reference at runtime, and don't have to pay the deser/validation size/cpu usage cost.
<cr1901>
I have no idea what the hell that crate is trying to do
<re_irc>
< (@jamesmunns:beeper.com)> uhhh, it's basically a serializer that spits out rust code
<re_irc>
< (@jamesmunns:beeper.com)> you would want this if you are "rendering" your data at build-rs or proc macro time, and wanted to "just have all the data as static/const vals"
<re_irc>
< (@jamesmunns:beeper.com)> icu4x uses it to convert big old tables of data into autogenerated .rs files, instead of include_bytes + postcard-deserializing at runtim
<cr1901>
So it's the fancy version of "using println to generate Rust code"
<re_irc>
< (@jamesmunns:beeper.com)> icu4x uses it to convert big old tables of data into autogenerated .rs files, instead of include_bytes + postcard-deserializing at runtime
<cr1901>
There's a few bugs, but I now have a mechanism to store binary/env info into info mem using build.rs and a small macro
<cr1901>
(The last 64 bytes are calibration data/TI stuff
<cr1901>
And yes, #[used] needs to be combined with a linker section marked as keep... so the top level memory.x will need to be modified for any project you use this crate in
<cr1901>
(Honestly, once I deploy insns for using this crate, I'd appreciate ppl testing w/ other microcontrollers. I'm guessing most of them have an .info/.config section in flash
IlPalazzo-ojiisa has quit [Ping timeout: 248 seconds]
<re_irc>
< (@jamesmunns:beeper.com)> love it :D
<re_irc>
< (@jamesmunns:beeper.com)> Gentle reminder, today's Rust release, v1.67.0, is likely to alter struct ordering for repr(Rust) types! If you have unsafe code that starts acting funny after updating, you _probably_ are missing a "repr(C)" somewhere!