<re_irc>
<gpanders> what is the recommended way to get access to Peripherals from an ISR?
<re_irc>
<adamgreig> there's a few options, ranging from "unsafe { pac::TIM2::PTR }" to storing it in a "static mut Mutex<Rc<Option<Peripheral>>>", or using a framework like RTIC that provides a safe interface, or using a smaller library for it like cmim
<re_irc>
<adamgreig> there's a few options, ranging from "unsafe { pac::TIM2::PTR }" to storing it in a "static mut Mutex<RefCell<Option<Peripheral>>>", or using a framework like RTIC that provides a safe interface, or using a smaller library for it like cmim
<re_irc>
<adamgreig> https://crates.io/crates/cmim is cmim, though I think it's relatively rarely used but might suit you
<re_irc>
<adamgreig> https://rtic.rs/ is RTIC is a heavier-weight solution to this problem if you're on cortex-m, but it solves a lot of issues very nicely and gives you a good framework for sharing data and peripherals between interrupts
<re_irc>
<adamgreig> if you're "sure" it won't race with another interrupt, consider just using "unsafe" to grab it, but that only gives you a RegisterBlock: fine to access registers directly yourself, but annoying to provide to a HAL
<cr1901>
Does Per Lindgren still idle here (on the Matrix side of things)?
<re_irc>
<adamgreig> yep
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<cr1901>
Just curious... we talked a while back about how maybe to add RTIC to msp430, but seeing as msp430 doesn't have something that "looks like" an NVIC, it hasn't been my priority.
slugbyte has joined #rust-embedded
slugbyte has quit [Quit: WeeChat 3.4]
slugbyte has joined #rust-embedded
slugbyte has quit [Client Quit]
slugbyte has joined #rust-embedded
sknebel has joined #rust-embedded
limpkin has joined #rust-embedded
<limpkin>
hello everyone!
<limpkin>
i've been banging my head for 3 hours on some trivial stm32 HAL related stuff and was wondering if I could ask a question here
mattgirv has joined #rust-embedded
<re_irc>
<henrik_alser> limpkin: Sure! There's also the https://matrix.to/#/#stm32-rs:matrix.org room for your info :)
<re_irc>
<luojia65> I have an unreleased risc-v chip that has a core of RV32E base extension, but Rust's RISC-V support only contains RV32I and RV64I. What should I do to support writing embedded Rust code on this chip?
<re_irc>
<K900> Does LLVM have an RV32E target?
<re_irc>
<K900> If it does, adding it to rustc should be pretty easy
<re_irc>
<luojia65> Yes, LLVM has that target
<re_irc>
<K900> Then you can probably just write a new target spec
<re_irc>
<K900> Well
<re_irc>
<K900> Probably copy the RV32I one and edit it a bit
<Amanieu>
You can enable the +e target feature on LLVM to tell it to generate RV32-E code.
<re_irc>
<Amanieu d'Antras> luojia65: You can enable the +e target feature on LLVM to tell it to generate RV32-E code.
<re_irc>
<Amanieu d'Antras> Use "rustc --print target-spec-json -Z unstable-options --target riscv32i-unknown-none-elf" to generate a JSON target file, add ""features": "+e"", and then use rustc --target rv32e.json
<re_irc>
<adamgreig> can you just "RUSTFLAGS="-C taregt-feature=+e"" with the normal riscv32i-unknown-none-elf target?
<re_irc>
<adamgreig> * target-feature=+e""
<re_irc>
<Amanieu d'Antras> Yea, that would work too.
<re_irc>
<adamgreig> though if I try that I get:
<re_irc>
LLVM ERROR: Codegen not yet implemented for RV32E
<re_irc>
error: build failed
<re_irc>
<Amanieu d'Antras> Oh I guess it's not supported by LLVM yet then.
<re_irc>
<Amanieu d'Antras> if (Subtarget.isRV32E())
<re_irc>
report_fatal_error("Codegen not yet implemented for RV32E");
<re_irc>
<adamgreig> that's the latest version of cortex-m, which uses "Interrupt", which the PAC should implement
<re_irc>
<adamgreig> you might need to "cargo update" to be sure you're on cortex-m 0.7
<re_irc>
<adamgreig> well, you might need to update your Cargo.toml too I guess
<limpkin>
ok, need to check that
<re_irc>
<adamgreig> by the way, you might find using RTT via the rtt-target and panic-rtt-target crates is more convenient, it's a _lot_ quicker at getting data back to your computer
<limpkin>
thanks :)
<limpkin>
it compiles! thanks a lot
<re_irc>
<adamgreig> np, glad it's working!
<limpkin>
thanks again for the help
<re_irc>
<dirbaio> is there any reason "heapless::Vec<T, N>" is not Copy even if "T: Copy"?
<re_irc>
<dirbaio> it seems to me like it could be Copy
<re_irc>
<dirbaio> and it'd be handy if it was, for example Cell::get() needs it
<limpkin>
may I ask a quick code check on rust? https://pastebin.com/fS4FZLwj In short for a complex solution I want to split functionalities in multiple mods
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
Guest2 has joined #rust-embedded
cr1901_ is now known as cr1901
lambda has quit [Quit: WeeChat 3.4]
<re_irc>
<omar_u8> Hello, question on the pac::Peripherals::take() method. I’m curious to the underlying workings and efficiency as comments mention something to the effect that it takes all peripherals. Does that mean that it would be more efficient to apply the take method only the peripherals that are being used in the code, or it doesn’t matter?
<re_irc>
<dirbaio> peripheral singletons are zero-sized types
<re_irc>
<dirbaio> the Peripherals struct containing them all is also zero-sized
<re_irc>
<dirbaio> so it doesn't "exist" in runtime, it's zero bytes
<re_irc>
<dirbaio> "Peripherals::take()" sets a single global "bool" flag to indicate they've been taken, then returns the struct
<re_irc>
<dirbaio> if take() was per-peripheral, it'd need one global "bool" flag per peripheral, it'd be _less_ efficient
MatrixTravelerbo has quit [K-Lined]
<re_irc>
<omar_u8> Awesome, thanks!
<re_irc>
<thejpster> Also worth making the observation that Rust allows you to 'move' fields out of a struct, leaving the struct only partially complete. This means you can do, say, "let uart = p.UART", and any other attempt to use "p.UART" will fail. Sadly. any attempt to move "p" itself will also fail, so we tend to just do this in the "main()" function of the program, and then never touch "p" again.
neceve has joined #rust-embedded
<re_irc>
<thejpster> dirbaio: wouldn't that make it unmovable?
<re_irc>
call_function_that_consumes_a_vec(h);
<re_irc>
h.foo(); // ta-da, it's stilll here!
<re_irc>
let h = heapless::Vec::new();
<re_irc>
<dirbaio> what's the issue? Copy types can be copied _and_ moved, compiler decides which happens
<re_irc>
<dirbaio> both "move" and "copy" are memcpys, it shouldn't affect perf
<re_irc>
<thejpster> How does the compiler decide when a "Copy" type gets moved instead of copied?
<re_irc>
<thejpster> It's not that it affects performance, it that it affects whether the data remains where it was or not.
<re_irc>
<dirbaio> it's only a semantic distinctin, in the final binary they're both memcpy
<re_irc>
<dirbaio> moving does leave the old copy behind, it's just that the compiler knows not to use it (ie not call Drop on it)
<re_irc>
<dirbaio> * (for example
<re_irc>
<thejpster> Right, but people use Rust ownership rules to indicate things like "I have permission to do this". SIlently making objects "Copy" seems like it would mess that up.
<re_irc>
<thejpster> Well, not silently - it'll be in the docs. But _unexpectedly_
<re_irc>
<dirbaio> why is that unexpected?
<re_irc>
<dirbaio> "[u8; 1024]" is Copy, "Vec<u8, 1024>" could be as well
<re_irc>
<thejpster> Because it's conceptually a "Vec". "Vec" doesn't become "Copy" just because I put integers in it.
<re_irc>
The executor is constant-time so it should add no/little jitter, just a bit of latency
<re_irc>
<dirbaio> you can also mix: run an embassy executor inside rtic's idle task, or you can also use good old cortex-m-rt "#[interrupt]" handlers with embassy
smach has quit [Read error: Connection reset by peer]