00:48 <GuineaWheek[m]> what i've found is that it's often good to have escape hatches even in the high-level drivers

00:48 <GuineaWheek[m]> sometimes you can't always imagine what a user is going to do with your driver and suddenly you run into issues

00:48 <GuineaWheek[m]> often my first response is to end up vendoring the crate

00:59 <dirbaio[m]> This is why I said "for concrete use cases"

01:00 <dirbaio[m]> If that concrete use case doesn't match what you as a user want to do you shouldn't use that driver, just use the low level drivers

01:05 <dirbaio[m]> If the high level driver has "escape hatches" that let you modify internals with the pac directly or whatever, if creates two problems:

01:05 <dirbaio[m]> 1. You can't make effective use of it without reading the driver source code. You have to see how the driver works internally and what registers it sets and when so you know what to override

01:05 <dirbaio[m]> 2. Now making any change to the drivers internals is potentially a breaking change, there's no way to predict what interactions it could have with everyone's low level overrides

06:43 <PicklePoacher[m]> Hello there! I am new here. :)

08:59 <dngrs[m]> STM32 has this too, they call it DMA continuous conversion mode

11:52 <EthanGardner[m]> Does probe_rs have a way of flashing over a generic uart similar to st-flash: https://github.com/stlink-org/stlink

11:55 <JamesMunns[m]> No, probe-rs generally only works over debuggers, not with bootloaders (like the serial DFU one)

11:58 <EthanGardner[m]> Happen to know any crates that do have it implemented

11:58 <JamesMunns[m]> Not off the top of my head, maybe someone else does.

12:00 <diondokter[m]> I created one that worked with STM and RP. But proprietary for a customer.

12:00 <diondokter[m]> But the company stopped... I can ask someone who worked there about the IP.

12:00 <diondokter[m]> Maybe I can open source it with permissions

12:00 <EthanGardner[m]> That would be lovely lol

12:00 <diondokter[m]> Though it wasn't uart, but usb

12:03 <dirbaio[m]> There's the USB dfu class. Embassy-usb has an impl for the firmware side, and I believe I've seen a rust impl of the host side somewhere as well

12:04 <diondokter[m]> Funny thing is that RP does something custom for its usb flashing. But it's so much better than the usb-dfu standard to work with :P

12:05 <dirbaio[m]> Yeah! Less customizable tho, for example there's no way to make it check the fw has some header or sig to check it's actually intended for this hardware and not just any random uf2

12:06 <dirbaio[m]> (rp235x maybe with secure boot can do it?)

12:06 <dirbaio[m]> And no way to change vid/pid/name

12:10 <JamesMunns[m]> the rp2350 does let you program otp for white labeling

12:10 <JamesMunns[m]> Check out "USB White-Labelling" in the rp2350 docs (section 5.7)

12:11 <dirbaio[m]> fancy!

13:08 <Ralph[m]> is there a reason why embedded-hal v1 has a set_state for GPIOs to use PinState but no state to get it? that could be added in a non-breaking way based on is_high and is_low, right? or can there be an InputPin which is neither high nor low? (for a digital pin i don't expect a tri-state behaviour?)

13:16 <marmrt[m]> you have StatefulOutputPin as a separate trait for pins which can read their output states

13:27 <Ralph[m]> i have an input pin in my case. i'm just designing an API where i get a `PinState` and have to check `is_low` / `is_high` to check if it's the desired state - if i'd have a `state` in e-h (which would do that... (full message at <https://catircservices.org/_irc/v1/media/download/AR8O4UMftlDIyRxO0A-J3tdEfUyysTJkZySuKndWA8vVagf8UMtsZ7QjuJNjVi-UtZ2vwnQyCq5U-PteWsYomZi_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy90ZnN6QmN4YlBGbXBxRkdqdnp0WElLd3Y>)

14:51 <Ralph[m]> how can i use `embedded-hal-bus` to use an (async) I2C bus for two devices where i have both in a `postcard-rpc` `Context` (i.e. a static `struct`)?... (full message at <https://catircservices.org/_irc/v1/media/download/AZ7KYrnp1DPjpL0KXdHGt6nDNsq3lRya3YMkgKCNYkp6cS4-N6g-ClE97VlJJU68hq6g2N9yhfh9X24OsjsXY2y_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9rcnBMTUFqSWZuQXVibXlLZXVYRkJweWE>)

14:54 <dirbaio[m]> put the `RefCell<I2c<'static...>>` in a StaticCell

14:54 <dirbaio[m]> so you get a `&'static RefCell<I2c<...>>`

14:54 <dirbaio[m]> then construct as many I2cRefCellDevices you need from that

14:55 <dirbaio[m]> * in a [StaticCell, * StaticCell](https://docs.rs/static_cell/latest/static_cell/struct.StaticCell.html)

14:57 <dirbaio[m]> the issue is you need the RefCell to live forever, but you cannot put it in Context together with the I2cRefCellDevice because that would make it self-referential. StaticCell allows you to statically allocate it somewhere else, solving the problem.

19:15 <Ralph[m]> thanks! that feels weird - is there any case where `RefCellDevice` can be used on its own then? i guess in almost all cases you need to pass it to other places where you then run into these lifetime issues? is this something which could/should be added to the examples in `embedded-hal-bus`? (which IMHO feels rather short on examples)

19:15 <Ralph[m]> using one of the other `*Device` impls from e-h-b doesn't improve the situation, right?

21:45 <zeenix[m]> Could heapless admins please add https://github.com/sosthene-nitrokey maintainer rights? They have contributed significantly to the crate, have been reviewing PRs and even helping with releases.

21:46 <zeenix[m]> s/add/give/

21:47 <zeenix[m]> Otherwise, it'll remain almost unmaintained

21:49 <zeenix[m]> adamgreig: dirbaio: ^

21:50 <zeenix[m]> Of course it could also be someone else that you trust more and think they'll be able to help with the maintenance

23:29 <adamgreig[m]> <zeenix[m]> Could heapless admins please add https://github.com/sosthene-nitrokey maintainer rights? They have contributed significantly to the crate, have been reviewing PRs and even helping with releases.

23:29 <adamgreig[m]> If they're interested the usual process would be to volunteer to join the libs team to help maintain it

23:49 <zeenix[m]> Sosthène Guédon: ^