10:13 <ainedixon[m]> 👋 hi

10:14 <ainedixon[m]> I have to find how to parse arguments to an attribute macro

10:14 <ainedixon[m]> Forexample #[module("users")]

10:14 <ainedixon[m]> How can I obtain arg "users"?

10:15 <ainedixon[m]> s/to/failed/, s/find/tofind/

10:18 <xiretza[cis]> it's the first argument to your proc macro

10:21 <ainedixon[m]> Yeah, but I mean, how do I parse it... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/iaNZRWGnlYuXLkElaAmRHxxR>)

10:28 <xiretza[cis]> ah you're asking about syn, honestly I might just skip it and look at the TokenStream directly for something this trivial

13:08 <pronvis> Hey guys, could you help me with some weird thing inside stm32_hal. To change pin type (input / output) you need to have some weird `cr: &mut <Self as HL>::Cr` which is not used inside actually, so it is just a "own marker" or smth like that

13:09 <pronvis> I have struct that speak with UART on half-duplex (using only one pin) - so I need to be able to change pin type

13:09 <pronvis> So, my struct need to have `cr: <Pin<PIN_C, PIN_N, Dynamic> as HL>::Cr,`

13:09 <pronvis> which is working fine

13:10 <pronvis> but now I found that I need several of those structures

13:10 <pronvis> so, several structures need to own `cr: <Pin<PIN_C, PIN_N, Dynamic> as HL>::Cr` which is impossible

13:10 <pronvis> what interior mutability pattern should I use here?

13:11 <pronvis> I dont want to use Mutex, cause it will use CriticalSection, which I dont actually need - because `&mut cr` is not used actually

13:13 <pronvis> here is the function from stm32f1xx_hal that using `cr`:

13:13 <pronvis> ```rust

13:13 <pronvis> fn mode<MODE: PinMode>(&mut self, cr: &mut <Self as HL>::Cr) {

13:13 <pronvis> // Input<PullUp> or Input<PullDown> mode

13:13 <pronvis> if let Some(pull) = MODE::PULL {

13:13 <pronvis> let gpio = unsafe { &(*Gpio::<P>::ptr()) };

13:13 <pronvis> if pull {

13:13 <pronvis> gpio.bsrr.write(|w| unsafe { w.bits(1 << N) });

13:13 <pronvis> } else {

13:13 <pronvis> gpio.bsrr.write(|w| unsafe { w.bits(1 << (16 + N)) });

13:13 <pronvis> }

13:13 <pronvis> }

13:13 <pronvis> let bits = (MODE::CNF << 2) | MODE::MODE;

13:13 <pronvis> self.cr_modify(cr, |r_bits| {

13:13 <pronvis> ```rust

13:13 <pronvis> #[inline(always)]

13:13 <pronvis> fn cr_modify(&mut self, _cr: &mut <Self as HL>::Cr, f: impl FnOnce(u32) -> u32) {

13:13 <pronvis> let gpio = unsafe { &(*Gpio::<P>::ptr()) };

13:13 <pronvis> match N {

13:13 <pronvis> 0..=7 => {

13:13 <pronvis> gpio.crl.modify(|r, w| unsafe { w.bits(f(r.bits())) });

13:13 <pronvis> }

13:13 <pronvis> 8..=15 => {

13:13 <pronvis> gpio.crh.modify(|r, w| unsafe { w.bits(f(r.bits())) });

13:13 <pronvis> }

13:13 <pronvis> _ => unreachable!(),

13:13 <pronvis> }

13:13 <pronvis> }

13:35 <JamesMunns[m]> The reason that thing exists is that swapping the config registers for a port/pin is not necessarily atomic, depending on the config changes you are making

13:37 <pronvis> Ok, but what workaround should I implement here?

13:37 <JamesMunns[m]> it's hard to read your code, matrix split each line into a message for me, but you do probably want a critical section while modifying the configuration registers, as you could potentially corrupt it if you were to change them concurrently (two cores, or one in an interrupt, etc).

13:38 <JamesMunns[m]> I'm not sure if `embassy_stm32` handles this any better, but yeah, it's likely that the current stm32f1xx_hal doesn't handle this well. Particulary, peripherals with a lot of "type states" make it very hard to do dynamic changes like that.

13:39 <pronvis> https://github.com/pronvis/drawer-robot/blob/master/crates/robot-core/src/my_tmc2209/communicator.rs#L51 here is how my Struct looks like now

13:40 <pronvis> but, I need to have several of those

13:40 <pronvis> so I cant own `cr: <Pin<PIN_C, PIN_N, Dynamic> as HL>::Cr,`

13:41 <JamesMunns[m]> yeah, I'm saying: you probably can't do that using stm32f1xx-hal.

13:41 <pronvis> O_o

13:41 <JamesMunns[m]> you could write your own unsafe GPIO drivers, use a critical section while making port changes, and do the port changes yourself using unsafe PAC operations.

13:42 <pronvis> omg, such a pain

14:07 <pronvis> Maybe I can just wrap `cr: <Pin<PIN_C, PIN_N, Dynamic> as HL>::Cr` into some wrapper that implements interior mutability? On std I could do it with `Box<RefCell<Cr>>`, is there something similar in no_std?

14:12 <dirbaio[m]> https://docs.embassy.dev/embassy-stm32/git/stm32h747xi-cm7/gpio/struct.Flex.html

14:13 <dirbaio[m]> No `&mut Cr` :P

14:14 <pronvis> hmm, never use embassy_stm32 previously - is it possible to use it together with stm32f1xx_hal? Cause I dont want to rewrite my entire code

15:10 <firefrommoonligh> I use an agnostic Pin that doesn't have ownership of hardware, and/or free-standing functions to set state and clear interrupts

15:11 <firefrommoonligh> Doesn't help you here directly, but it's a pattern I like

15:12 <firefrommoonligh> s/like/use that avoids this trouble./

15:28 <pronvis> @firefrommoonligh do you have some open sourced projects where you used that pattern?

21:45 <firefrommoonligh> No

23:05 <firefrommoonligh> If your case is let several structs use a pin as you said, you would just clone the pin, or use the freestanding fn without ownership, eg:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/CaUkFeACsCIDzERkYQZBAfos>)