05:33 <chrysn[m]> not strictly planned, but we should spool all desirable changes to assess whether the spool is heavy enough.

07:44 <mrpashapg[m]> I'm using an ESP32-C3 SuperMini with a single SPI interface. I have two peripheral modules with different clock requirements (10MHz vs 50MHz). While I understand maintaining a lower frequency would... (full message at <https://catircservices.org/_irc/v1/media/download/AXyVvCqgC4pYNwDFkRrjYwYBoMEsqkE7ACQe9Ko_YIN5cveYvWO_Kx2rlYlmptdv3GsakJWCFpWdgFbKOpsHHTa_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9BVkVxaFJaclNJZlZRdm5vb3lEWUxtckQ>)

07:46 <danielb[m]> use one of embassy-embedded-hal's https://docs.rs/embassy-embedded-hal/latest/embassy_embedded_hal/shared_bus/asynch/spi/struct.SpiDeviceWithConfig.html, that allows you to change configuration for the active device

07:46 <danielb[m]> s/one of//, s/embassy_embedded_hal/embassy\_embedded\_hal/, s/shared_bus/shared\_bus/

07:52 <mrpashapg[m]> danielb[m]: Oh, what a huge mistake I made - it was right in front of me and I didn't see it! 😅

07:52 <mrpashapg[m]> Thank you so much

09:00 <eddie1o[m]> Hi all, I really need your help in understanding of interrupts on esp32c6 using `esp-hal`. Here is an example I was looking at https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/gpio_interrupt.rs

09:00 <eddie1o[m]> My question is: when I have more than one button with `.listen(Event::RisingEdge)` how can I distinguish which one has been pressed? The example I linked only checks for `.is_interrupt_set()` which in my case will return true for both of my buttons. Or maybe is it better to spawn embassy tasks for each button and just `.wait_for_falling_edge()` in them?

09:01 <Ralph[m]> eddie1o[m]: as far as i understood the latter is the preferred method with `async`

09:14 <eddie1o[m]> Makes sense, thanks. It just felt a bit weird to spawn tasks for each end every button

10:06 <danielb[m]> <eddie1o[m]> Hi all, I really need your help in understanding of interrupts on esp32c6 using `esp-hal`. Here is an example I was looking at https://github.com/esp-rs/esp-hal/blob/main/examples/src/bin/gpio_interrupt.rs...

10:06 <danielb[m]> since there is a single interrupt handler, you'll need to go through your watched pins and read each one of them

10:07 <danielb[m]> * interrupt handler (because the hardware only gives us one), you'll

10:08 <danielb[m]> you can also select between your buttons in a single task, you don't need to spawn separate tasks for this

12:58 <eddie1o[m]> Okay, so the problem was that I thought that .is_interrupt_set() will return true for every pin I set .listen(Event::RisingEdge) to. But it returns true only for the interrupt source pin. Many thanks for all of you!

14:58 <zeenix[m]> dirbaio: Hi, not sure if this is what you suggested I do but here goes nothing: https://github.com/rust-embedded/wg/issues/857

18:57 <mrpashapg[m]> <diondokter[m]> Yeah, it's the same as the old one, but with better support for different memory sizes and series... (full message at <https://catircservices.org/_irc/v1/media/download/AV9UOErv6kZxwY4bEIn4dyMORai3_fnlQQ9yT3ItuAHFWschen10BS9qciZu9RdOM0s9Xwcntb-XrCaQ9wPSwty_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9kcFdwdm1mQkVCbGJaWUFoZE1jaGVYak0>)

19:00 <diondokter[m]> mrpashapg[m]: Yeah, that's handled in the w25 crate.

19:00 <diondokter[m]> I think the documentation of the embedded-storage will help you a lot: https://docs.rs/embedded-storage/latest/embedded_storage/nor_flash/index.html#traits

19:00 <diondokter[m]> These traits are implemented by the w25 driver. So you're getting what these traits give you

19:03 <diondokter[m]> Still, managing data on flash is still quite tricky. That's why Dirbaio and I both wrote a higher level crate to deal with it.... (full message at <https://catircservices.org/_irc/v1/media/download/AS7ECBYLv2iJfEh9_rbI1ai6K-ATf8tnOrV8nHL75CUSGjoPFp_gGskj_mcc1pWZVZCBb62aCJR8d4oPWhKbRgW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9lWmxRaU90cFBRR1V0cEpDTlNqdkpjR3o>)

19:03 <diondokter[m]> s/still//

19:07 <mrpashapg[m]> <diondokter[m]> Yeah, that's handled in the w25 crate....

19:07 <mrpashapg[m]> I'll definitely read into it. Previously I had used another library that depended on embedded-storage - it was a high-level library, and I assumed embedded-storage mandated that an entire sector must be securely prepared before writing, performing erase operations prior to writes. Because of this, I didn't delve deeper into embedded-storage and was looking for alternative approaches.

19:07 <mrpashapg[m]> Thanks for your explanation. And thank you for your work - now I don't need to implement low-level drivers in my project or handle these issues manually. I can focus on wear-leveling logic instead XD

19:19 <mrpashapg[m]> <diondokter[m]> Still, managing data on flash is still quite tricky. That's why Dirbaio and I both wrote a higher level crate to deal with it....... (full message at <https://catircservices.org/_irc/v1/media/download/ASqO6jSKKzhJMgD2Yw_QMZAhsJ2JIjZsWMvCo88V9Dc9R7FSHMmN00p4lyaPW857CgfcO93Y7i51aV-FYkmIAgK_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9vbWx2c2ppWnJ1WGdieVpsVHNWWVNqcW8>)

19:27 <mrpashapg[m]> Would you consider this a viable solution that could benefit others working with severely constrained memory (in the kilobyte range), providing them with the most optimized and efficient approach available?

19:29 <diondokter[m]> Sounds like it's got different tradeoffs compared to the existing crates. So yeah, maybe

19:32 <mrpashapg[m]> diondokter[m]: I really appreciate the time you've taken

21:22 <ghostie[m]> hello all. i'm new. does anyone know what i'm doing wrong here? i was using async-std and the change to smol is confusing me

21:28 <dirbaio[m]> use `MutexDevice`, not `Arc<AtomicDevice>`