<cr1901>
Yuhan Lin: Gave my feedback... thanks for waiting!
<re_irc>
<chemicstry> aktaboot: It depends what you call low-level and cryptography. Do you have an embedded device in mind? Because this channel is mostly about microcontrollers. If that's the case then embedded rust book is a good start https://docs.rust-embedded.org/book/ If you are looking for material on low-level unsafe optimisation and simd stuff then you probably should ask elsewhere, see what chatrooms crates of your interest use
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<re_irc>
<eldruin> aktaboot: Welcome! Also, for a gentler introduction to embedded development with Rust we also have the discovery book: https://docs.rust-embedded.org/discovery/
<re_irc>
<MathiasKoch> Does anyone have the actual shopping list for the CO2 sensor knurling session? The one listed in the session book seems to refer to the newer 2021 Minesweeper session?
<re_irc>
<ryan-summers> eldruin: Is there any ETA on GAT stabilization? I'm definitely interested in leveraging async, but don't like forced use of nightly / unstable features
<re_irc>
<ryan-summers> I'd love to have a blend of RTIC + async :)
<re_irc>
<eldruin> I think GAT should be available quite soon ™️ but I have no ETA
<cr1901>
What is the #[proc_macro] attribute for here and why is that function body returning a TokenStream required?
<re_irc>
<jamwaffles> Hey all, would someone be able to explain the behaviour seen by @pdgilbert in this issue? https://github.com/jamwaffles/ssd1306/issues/165 I don't know how the "memory.x" machinery works
<re_irc>
<allexoll> jamwaffles: the STM-rs dinamically create/link the correct memory.x depending on the mcu/reference you're choosing in your toml. since the ssd1306 crate also includes one memory.x for the STM32F103C8T6, it gets included twice in the linking process by build.rs.
<re_irc>
Since ssd1306 is a driver crate and not a mcu hal crate, it shouldn't include a memory.x linker script.
<re_irc>
when @pdgilbert was using your crate with (i suppose) another mcu-hal crate with no mechanism for memory.x, it was relying on yours for it. which would also probably explain his runtime error if it was for another mcu with another memory map.
<re_irc>
<jamwaffles> Ah sweet, thank you for the explanation! Do you mind if I/you post it on the linked thread?
<re_irc>
<allexoll> sure go on!
<re_irc>
<allexoll> but that also mean that you might need to fix your crate/build.rs so it does not include this linker script (might break your example aswell, but there are other ways to have dev-depencencies)
<re_irc>
<barafael> is there an idiom to prevent debug builds, in cases where building with non-release creates a binary which is too large to fit in flash?
<re_irc>
<ryan-summers> #[cfg(debug_assertions)]
<re_irc>
compile_error!("This crate cannot be built in debug builds")
<re_irc>
<ryan-summers> Compile errors will occur before linking, so that will always error before the flash error hits
<re_irc>
<ryan-summers> But I'm not sure I'd pursue that avenue. Users can always optimize debug builds further to allow them to fit in flash
xnor has quit [Ping timeout: 268 seconds]
xnor has joined #rust-embedded
<re_irc>
<barafael> ok, I'd leave as is then
m5zs7k has quit [Ping timeout: 256 seconds]
m5zs7k has joined #rust-embedded
badboy_ has joined #rust-embedded
vancz_ has joined #rust-embedded
vancz has quit [*.net *.split]
limpkin has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
badboy has quit [*.net *.split]
sknebel has quit [*.net *.split]
Rahix has quit [*.net *.split]
richardeoin has quit [*.net *.split]
limpkin has joined #rust-embedded
Rahix has joined #rust-embedded
richardeoin has joined #rust-embedded
sknebel has joined #rust-embedded
Lumpio- has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
Darius_ has joined #rust-embedded
Darius has quit [Quit: Bye]
Darius_ is now known as Darius
Guest2 has joined #rust-embedded
<re_irc>
<d3zd3z> For those curious about code execution during flash operation. The NRF51 and NRF52 behave slightly differently. The NRF51 requires the code to manage separate banks of flash, and the code doing the flash programming has to be in the other bank from the bank being programmed.
<re_irc>
<d3zd3z> The NRF52 is pretty flexible, however the CPU is halted while the flash operation is happening.
<re_irc>
<dirbaio> nrf52 can do "partial erases" so you can have many short stalls instead of one long stall
<re_irc>
<d3zd3z> Possible general Rust question, but if I want to, say, work on a local git checkout of the nrf52 hal, I need to also clone all of my dependencies that depend on it, and add patch sections in those to refer to that dependency?
<re_irc>
<adamgreig> nope, just one patch in the binary crate will replace nrf52-hal for the whole build tree
<re_irc>
<adamgreig> using [patch.crates-io] nrf52-hal = { path = "../nrf52-hal" } in the binary's cargo.toml
<re_irc>
<d3zd3z> adamgreig: Thanks, that seems to work for the nrf52833-hal, when I try to use the local version of the microbit-v2 hal, I get a warning: warning: Patch "microbit-v2 v0.12.0 (/home/davidb/linaro/embed-rust/microbit/microbit-v2)" was not used in the crate graph.
<re_irc>
<adamgreig> perhaps the version doesn't match?
<re_irc>
<adamgreig> "cargo tree" is helpful to see what's coming in with what versions
<re_irc>
<d3zd3z> The versions appear to match. I ended up creating a workspace that just includes the things I'm working on. I had to move aside the microbit workspace Cargo.toml, since apparently workspaces can't be nested, but otherwise it seems to be working.
Guest2 has quit [Quit: Client closed]
Subaudible has joined #rust-embedded
<re_irc>
<wsalmon> i have a little program that uses a stm32f103 to read some data and the do some processing then write the results to serial over usb, turns out
<re_irc>
write!(
<re_irc>
"results C {:?} {:?} {:?} {:?} {:?} {:?}",
<re_irc>
<James Munns> "pretty-hal-machine" v0.0.2 just went out! More info here:
<re_irc>
<adamgreig> wsalmon: you could also do f32::to_bits() which gives you a u32 that you can print as e.g. hex, then on the computer parse the hex number back to a float with f32::from_bits (or equivalent), if you want something that's still plain text and so on
<re_irc>
<adamgreig> I've done that a bunch when I'm logging some state and don't want to pull in a float formatter and can always convert the hex back to a float
<re_irc>
<adamgreig> though defmt is probably a better global solution to the problem since then you don't pull in any formatting code for anything :P
<Lumpio->
Is defmt something you'd use for stuff besides debug logging?
<Lumpio->
Personally I like to stick to fixed point math and no floats whenever possible.