06:42 <re_irc> < (@anand21:matrix.org)> Hi All,

06:42 <re_irc> Is there any way to getting ownership of a only 1 peripheral from HAL,

06:42 <re_irc> Rather than getting the whole Peripherals?

06:42 <re_irc> I don't want to use global statics.

09:28 <re_irc> < (@ryan-summers:matrix.org)> You can just move it out of the peripheral atruct the HAL gives you. No need to do anything else with the other stuff if you don't need it

09:28 <re_irc> < (@ryan-summers:matrix.org)> * struct

09:28 <re_irc> < (@ryan-summers:matrix.org)> Note that this may be confusing if you're used to c/c++, but rust ownership means you can destructive objects into multiple parts :)

09:29 <re_irc> < (@ryan-summers:matrix.org)> * destructure

09:30 <re_irc> < (@anand21:matrix.org)> No The problem is, I need 1 peripheral at the staring of the code. And another peripheral at some other point, in other file.

09:33 <re_irc> < (@ryan-summers:matrix.org)> You're going to have to post some kind of example, I'm not following what you mean

09:34 <re_irc> < (@ryan-summers:matrix.org)> * Can you post some kind of example?

09:36 <re_irc> < (@anand21:matrix.org)> Ok This is the main.rs

09:36 <re_irc> fn main() -> ! {

09:36 <re_irc> let dp= nrf9160_pac::Peripherals::take().unwrap();

09:36 <re_irc> defmt::println!("Hi from Secure world");

09:36 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/P2fmyg0a2r2Zg4KDT49HMGzNZoUdWiP0 (16 lines)

09:39 <re_irc> < (@anand21:matrix.org)> Then in some other file under the same crate I again want to use the NVMC peripheral.

09:39 <re_irc> Now if try to get the

09:39 <re_irc> nvmc: Peripherals::take().unwrap().NVMC_S;

09:39 <re_irc> Here I get None. As i have already taken the peripherals previously

09:42 <re_irc> < (@ryan-summers:matrix.org)> Why not pass NVMC_S to the other file instead?

09:43 <re_irc> < (@ryan-summers:matrix.org)> If it's in another thread, I think you have to use some global object with access control

09:43 <re_irc> < (@anand21:matrix.org)> Yes that can be done. But I wanted to explore other options available.

09:44 <re_irc> < (@anand21:matrix.org)> I guess I have to use Global statics only. Right?

09:45 <re_irc> < (@ryan-summers:matrix.org)> The rust ownership RAIA would break if the peripherals could be "take()"n more than once, as that would imply that two drivers/owners could have simultaneous control over the same peripheral, which is fundamentally unsound

09:46 <re_irc> < (@ryan-summers:matrix.org)> So without directly passing or moving the object into some owned location that's accessible, it will be dropped and not recoverable (might be an unsafe method to instantiate it from a ptr as well)

09:48 <re_irc> < (@anand21:matrix.org)> Ok thank you for the suggestion.

09:48 <re_irc> I will explore the global static thing. And lazy initialisation of it later point of time.

09:48 <re_irc> < (@ryan-summers:matrix.org)> Also worth noting that's from the PAC and not the HAL. Might make it easier to conjure up the object from a pointer

09:50 <re_irc> < (@ryan-summers:matrix.org)> Eh, that just gets you the "RegisterBlock" instead of the peripheral itself unfortunately

10:04 <re_irc> < (@marmrt:matrix.org)> "steal()" the peripherals. What could go wrong?

10:05 <re_irc> < (@anand21:matrix.org)> I tried "steal()" It is unsafe version of "take()"

10:07 <re_irc> < (@marmrt:matrix.org)> Yes, and if you do "steal()" instead of the second "take()" you will get a second copy of the peripheral struct.

10:09 <re_irc> < (@marmrt:matrix.org)> To be clear, I think you should listen to Ryan, not me. Figure out the legal way to get the behaviour you want

10:13 <re_irc> < (@ryan-summers:matrix.org)> Unsafe stuff is fine, you just need to thoroughly document why it's explicitly okay. And also recognize you are paying in technical debt. You may introduce a subtle bug in the future and waste hours on it

10:13 <re_irc> < (@ryan-summers:matrix.org)> Technically speaking though, using "steal()" as you propose is completely sound in this case. It's just quite easy to make it not sound in the future

10:14 <re_irc> < (@anand21:matrix.org)> I agree to this as we are using rust just to make the use of tightly coupled type systems.

20:39 <wes_> hello everyone. brand new here

20:40 <wes_> can i ask questions about specific code snippets here?

20:46 <wes_> well, here goes anyways...

20:46 <wes_> i'm working with an RP2040 pico

20:46 <wes_> i've pulled some sample code from the rp-hal repo

20:47 <wes_> for some reason, because of `to_Hz()` i cannot get this to compile

20:47 <wes_> `let mut delay = cortex_m::delay::Delay::new(core.SYST, clocks.system_clock.freq().to_Hz());`

20:51 <re_irc> < (@k900:0upti.me)> My guess would be lower case "to_hz"

20:52 <re_irc> < (@xiretza:xiretza.xyz)> wes_: what's the error?

20:57 <wes_> method not found in `embedded_time::rate::units::Hertz`

20:58 <wes_> no dice on lowercase'ing it. the code (and `use` calls) come directly from an example. which works (compiles, flashes, LEDs blink) in the example project

20:58 <wes_> i'm coming from C, and i'm not at all comfy using Rust documentation. yet

20:59 <re_irc> < (@xiretza:xiretza.xyz)> probably different versions of dependencies then, compare the Cargo.toml files

20:59 <wes_> ah! good call

21:03 <wes_> amazing! that's all it was. 0.4.0 -> 0.5.0 and boom. all good. thank you

21:03 <wes_> is there a way to tell Cargo to use the most up-to-date versions of dependencies?

21:06 <re_irc> < (@grantm11235:matrix.org)> Generally, you don't want cargo to update from 0.4.0 to 0.5.0 automatically without telling you

21:06 <wes_> sure. makes sense.

21:08 <re_irc> < (@grantm11235:matrix.org)> If you are adding a new dependency, you can use "cargo add the-name-of-the-new-dep" from cargo-edit (https://crates.io/crates/cargo-edit)

21:09 <re_irc> < (@grantm11235:matrix.org)> Which will automatically add that dependency to your "Cargo.toml", using the latest version

21:09 <wes_> that's perfect. exactly what i want

21:09 <wes_> thanks

21:09 <re_irc> < (@jannic:matrix.org)> cargo-edit also has a subcommand "cargo upgrade": https://github.com/killercup/cargo-edit#cargo-upgrade

21:25 <wes_> thanks for all the advice. my project is now up-to-date

21:26 <Socke> which crate would you recommend for doing small http requests on esp32? I'm especially concerned about memory and flash footprint

21:46 <re_irc> < (@yatekii:matrix.org)> Hey folks, can anyone tell me how I can lock a STM32F4 core easily? I wanna test if probe-rs can detect locked state ^^cc maybe?

21:47 <re_irc> < (@adamgreig:matrix.org)> locked as in no debug access due to protection, or as in sleep mode, or something else?

21:47 <re_irc> < (@yatekii:matrix.org)> Socke: always smoltcp :) but I wonder why you are concerned about the footprint on an esp32 which has an abundance of resources compared to every other MCU :P

21:47 <re_irc> < (@yatekii:matrix.org)> : as in no debug access :)

21:48 <re_irc> < (@yatekii:matrix.org)> maybe there is a utility that does this off the bat or a register I can write with probe-rs without much fiddling

21:48 <re_irc> < (@adamgreig:matrix.org)> if you lock it to disable debug access, you can't re-enable debug access

21:49 <re_irc> < (@yatekii:matrix.org)> : oh wat

21:49 <re_irc> < (@yatekii:matrix.org)> you cannot reenable it by erasing?

21:49 <re_irc> < (@adamgreig:matrix.org)> how would you erase it without debug access?

21:50 <re_irc> < (@yatekii:matrix.org)> on nRF devices ther is a second custom AP that can unlock it :)

21:52 <re_irc> < (@adamgreig:matrix.org)> on stm32 flash readout protection, there's level 0, 1, or 2; level 0 is normal, 1 is can't read flash while debug is connected or booted from ram, and you can revert to level 0 which mass erases the flash, level 2 disables the debug interface such that you can no longer lower the protection level

21:54 <Socke> yatekii: but smoltcp has no http support? I thought it's a tcp stack. using esp-idf for this btw

21:55 <re_irc> < (@yatekii:matrix.org)> Socke: ah sorry, consider me stupid :/

21:55 <Socke> :D

21:55 <re_irc> < (@yatekii:matrix.org)> : hmm ok I am not sure what I would want XD

22:05 <Socke> just coding the parsing myself in this case

22:07 <re_irc> < (@mabez:matrix.org)> Socke: If you're using esp-idf, can't use you use the idf http client/server?

22:08 <Socke> oh it has one?

22:10 <Socke> hmm looks like there's only an httpd, but no httpc. but I found EspSntp, this will come in handy later :)

22:10 <Socke> https://esp-rs.github.io/esp-idf-svc/esp_idf_svc/index.html

22:11 <re_irc> < (@mabez:matrix.org)> Socke: There is a client here (and a new server): https://github.com/esp-rs/esp-idf-svc/blob/master/src/http/client.rs

22:12 <re_irc> < (@mabez:matrix.org)> Its behind an experimental feature flag which is why it doesn't show up on the docs I think

22:12 <Socke> NICE!

22:12 <Socke> damnit last hour of coding wasted :D

22:12 <re_irc> < (@mabez:matrix.org)> The plan is to remove the current httpd interface and replace with both of these :)

22:13 <re_irc> < (@mabez:matrix.org)> Socke: Sorry!! I'll PR the docs change now :)

22:13 <Socke> np, but thanks for the hint :)