01:01 <PhilMarkgraf[m]> <dirbaio[m]> "```rust..." <- What are the implications of make_static? I'm guessing you can only make ONE i2cBus2, if you use this approach. (Which is fine in my usage.)

03:43 <dirbaio[m]> <PhilMarkgraf[m]> "What are the implications of..." <- exactly that, yes

03:44 <dirbaio[m]> dirbaio[m]: first time you run the `make_static!()` it'll convert to `&'static Whatever`, second time it'll panic

04:43 <ducks2788[m]> Hi. `control` is defined like so... How can I make it static?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NhEYssoEzJTmrezagvVyaqkv>)

04:57 <ducks2788[m]> I want to use control as argument for a spawned task, but the compiler says it does not live long enough. I also tried to make a closure, that uses control, and give the closure to my task. But that also does not work...

05:19 <dirbaio[m]> you need to make_static! the state

05:19 <dirbaio[m]> then you can pass `Control<'static>` to the spawned task

05:31 <ducks2788[m]> But this doesn't work, if I try to spawn multiple tasks in a loop, because control is moved into make_static! and can be used only once?

05:42 <ducks2788[m]> If I leave control as it is, Rust says it cannot borrow control as mutable more than once a time... Btw: Is Rust insane or crazy? 😂

06:17 <dirbaio[m]> Ah, you didn't say you wanted to use Control from multiple tasks at the same time :) 

06:17 <dirbaio[m]> You have to wrap it in a mutex for that 

06:34 <ducks2788[m]> Which Mutex should I use embassy_sync::{sync, blocking_sync}} and how should I use it. Can you give an example, please?

06:36 <ducks2788[m]> * Which Mutex should I use embassy_sync::{mutex, blocking_sync}::Mutex and how should I use it. Can you give an example, please?

06:41 <ducks2788[m]> * Which Mutex should I use embassy_sync::{mutex, blocking_mutex}::Mutex and how should I use it. Can you give an example, please?

07:06 <ducks2788[m]> Yeah, I have it! It compiles! 😂 Thank you! 👍️

16:57 <StephenD[m]> I noticed that when the stm32 is put in DFU it activates a ton of busses - USART, SPI, I2C, etc. I'm worried it may activate a pin as an output that I also happen to be driving, damaging the pin. Should I just be putting small resistors on these pins, or is there a better way? I guess I could either avoid the pins that the DFU uses (it's document) but I'm curious if there's a way to tell the chip to only activate USB when in DFU

16:57 <StephenD[m]> mode. I didn't see anything in the docs

16:57 <StephenD[m]> I also realize this may be a teeny bit off topic for this room, sorry 😅

16:59 <adamgreig[m]> It always activates all those interfaces, though I thought it had all of them in a receive only mode until it received a message on it

17:09 <StephenD[m]> Hmm, it isn't obvious to me whether or not it puts the respective GPIO into output mode immediately

17:31 <JamesMunns[m]> There's a specific DFU app note, but I seem to recall it always cycles through listening on all of the interfaces

17:32 <JamesMunns[m]> AN2606, looks like

17:33 <JamesMunns[m]> It does rx-only I think, but some pins will be pulled up

17:36 <JamesMunns[m]> Stephen D as far as I can tell, as long as you are okay with some pins being pulled high, you should be fine. Definitely look for your specific chip tho

17:37 <JamesMunns[m]> For example in STM32F405, it pulls USART1, USART3, and CAN2 pins high, but all as inputs initially it seems

17:40 <StephenD[m]> <JamesMunns[m]> "AN2606, looks like" <- Yeah that's the one I'm looking at

17:40 <StephenD[m]> JamesMunns[m]: Okay thanks. That should be fine then

17:40 <StephenD[m]> I was mainly just worried about damage

17:40 <JamesMunns[m]> Be careful not to put any "turn on the big heater" switches on those pins :D

17:42 <StephenD[m]> Ah true