11:37 <re_irc> < (@thebutlah:matrix.org)> Is there a good way to access a static that is "!Sync" if I know that I am on a single core system? _must_ I use a critical section every time or is it sound to just use "unsafe" here?

12:24 <re_irc> < (@thebutlah:matrix.org)> I used "StaticCell", solved it for me :)

12:24 <re_irc> < (@thebutlah:matrix.org)> +I needed the "'static" lifetime not not a global scope, so that did the job

12:45 <re_irc> < (@adamgreig:matrix.org)> You need a critical section because otherwise different interrupts and the main thread could race each other for access, but if StaticCell works for what you need that's ok too

21:48 <re_irc> <rutherther> Hi, I have been thinking about writing a _driver_ for i/o expander working over i2c

21:48 <re_irc> I checked out some libraries that work with i2c and all in all of them the i2c interface was passed in ::new, for example in this library https://github.com/JohnDoneth/hd44780-driver

21:48 <re_irc> I find that strange, I am new to Rust, so I may be just missing something, but that moves the i2c, doesn't it? and you cannot use it for anything else then...

21:48 <re_irc> am I interpreting it correctly? What would the alternative to this be so more devices on the bus may be used? The only solution that came to my mind was borrowing &mut i2c only in methods that need it without moving it.

21:57 <re_irc> < (@9names:matrix.org)> This is what shared-bus is for.

21:57 <re_irc> https://crates.io/crates/shared-bus

21:58 <re_irc> < (@freckly-sunbeam:matrix.org)> (x-posted from #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org) ) Hi all 👋 I'm running into an issue with my highly cobbled-together attempts to drive the display on a Lilygo T-Display microcontroller, which has an ST7789V display unit. I'm using esp-idf-hal, display-interface, embedded-graphics, display-interface-spi, and mipidsi. I'm not quite sure if I'm using the APIs or pins...

21:58 <re_irc> ... correctly, and I'm a bit confused about the runtime panic I'm getting.

21:58 <re_irc> here is the code that I'm running, and this is the panic message that's popping up after the code starts. Could anyone lend a hand on this? Am I misunderstanding the pin configuration or using the wrong libraries here?

22:00 <re_irc> < (@freckly-sunbeam:matrix.org)> +(https://github.com/lily-mara/ttgo-tdisplay-rs/blob/main/src/main.rs)

22:01 <re_irc> < (@freckly-sunbeam:matrix.org)> (x-posted from #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org) ) Hi all 👋 I'm running into an issue with my highly cobbled-together attempts to drive the display on a Lilygo T-Display microcontroller, which has an ST7789V display unit. I'm using esp-idf-hal, display-interface, embedded-graphics, display-interface-spi, and mipidsi. I'm not quite sure if I'm using the APIs or pins...

22:01 <re_irc> here (https://github.com/lily-mara/ttgo-tdisplay-rs/blob/main/src/main.rs) is the code that I'm running, and this (https://gist.github.com/lily-mara/4ad10b61d411efdbede1104ac94a328b) is the panic message that's popping up after the code starts. Could anyone lend a hand on this? Am I misunderstanding the pin configuration or using the wrong libraries here?

22:01 <re_irc> ... correctly, and I'm a bit confused about the runtime panic I'm getting.

22:01 <re_irc> edit: links didn't copy

22:05 <re_irc> <Rutherther> : okay, thanks.

22:14 <re_irc> <Diaeresis> From the pure rust perspective note how "I2C" is declared: "impl<I2C: i2c::Write>". So you need any type that you can get exclusive access to and that provides an implementation of "i2c::Write". That allows taking a handle (that is itself exclusive) to something you don't necessarily have exclusive access to, with safety ensured by locks and similar.

22:21 <re_irc> <Rutherther> Diaeresis: right, I have not thought of that, thanks for the explanation