11:31 <thejpster[m]> Ugh. https://github.com/rust-lang/rust/issues/118337

11:32 <thejpster[m]> There was quite a lot of wrong in there. Have done my best to address it. I hope in future they can just call in the experts who use these chips day in and day out.

11:33 <thejpster[m]> Pinging adamgreig and therealprof as our esteemed leaders.

13:15 <jessebraham[m]> Has there been any discussion regarding moving `defmt` to another organization like `rust-embedded`? I understand people are busy and empathize with that, but it would be nice to see some more activity there. For instance, there's an open PR I've been waiting on which has been open for ~3 weeks and has not even received an initial review yet, seems that allowing others to get involved would be a simple solutionf or this.

13:21 <burrbull[m]> <jessebraham[m]> "Has there been any discussion..." <- to `libs` team maybe.

13:21 <burrbull[m]> + `fugit`

13:21 <burrbull[m]> + more maintainers for libs team.

13:21 <andresovela[m]> I suggested this a few weeks ago

13:22 <adamgreig[m]> Yea, it was briefly discussed https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$uzQoU4-SyA35RhPBzCHBAUm3rs3Lf_gmwyF9aFJAGEc?via=matrix.org

13:22 <adamgreig[m]> (scroll down a bit too)

13:23 <adamgreig[m]> But basically it's owned and run by knurling so they're the people to talk to before anything in the wg

13:24 <jessebraham[m]> Okay, thanks for the link

13:55 <Bergmann[m]> Is there a way to specify where i want to start reading data in embedded_hal_async::i2c? I2c::read only takes address of the device and fills slice with data from the beginning of device memory addresses. Same thing with I2c::write. Can read or write single byte for example 0x1E without reading those 30 past bytes?

13:57 <andresovela[m]> Usually you just write 0x1E to the device you want to read from and then start reading

14:30 <Bergmann[m]> kinda strange, but it works

14:30 <Bergmann[m]> thanks

15:00 <andresovela[m]> That’s a general I2C thing, not an Embassy API thing, just FYI

15:05 <JonathanDickinso> Bergmann: unless you're integrating with an existing device, I2C is designed to work like remote memory-mapped registers. You want to `write_read(addr, register_num, &mut value)` to get values and `write(addr, &[register_num, data...])`. Trying to use it as a serial bus is fraught with peril (I've tried). If you want a serial bus then look at CAN instead.

15:18 <thejpster[m]> <jessebraham[m]> "Has there been any discussion..." <- I’m sorry we’re not going as quickly as people want right now. As a reminder, the Knurling project accepts sponsorship via Open Collective and GitHub IIRC. We don’t get a huge amount and it limits the hours we can fund staff to work on it. If you’re happy to donate money or time, please feel free to reach out.

15:18 <thejpster[m]> I’m not sure “just give it to the REDWG” is a solution in the general case to “I had to wait a few weeks for someone to look at my PR”, especially as they get zero sponsorship money and are in theory even less sustainable. And especially when it it’s commercial companies asking who can just pay to get work done.

15:19 <jessebraham[m]> No apology needed, I understand. I guess that was a poor example, I just know I am not the only person who wishes to see more progress there. It's an incredibly useful set of libraries, and I just want to see them flourish.

15:20 <jessebraham[m]> I guess I could have said less, really was just interested if there were any plans for changing how things work in the future.

15:24 <thejpster[m]> The team will be happy to receive any suggestions. Personally I think adding people from outside Ferrous could be possible.

15:25 <thejpster[m]> But that’s not my call to make.

15:25 <jessebraham[m]> Fair enough, thanks for giving some additional context.

16:03 <firefrommoonligh> My 2c is Demt works excellent as is, and I can seem it being a solid foundation even with no changes

16:03 <firefrommoonligh> So, thx for it

16:03 <firefrommoonligh> My experience would be worse without it

16:04 <firefrommoonligh> *Eh I guess something like the builtin println's float etc formatting would be nice, but that's minor

16:04 <firefrommoonligh> * * I guess something like the builtin println's float etc formatting and var-name-in-brackets would be nice, but that's minor

16:08 <firefrommoonligh> * * I guess something like the builtin println's float etc formatting and var-name-in-braces would be nice, but that's minor

16:08 <firefrommoonligh> s/Demt/Defmt/

16:10 <firefrommoonligh> As always re OSS in particular, if there is a blocker, you can fork. This produces fragmentation if the fork is public and/or published, so that's a tradeoff.

16:11 <firefrommoonligh> It's like, these guys have already been bros for publishing it OSS. Likewise, you have been too for making a PR and fixing or adding something. So, everyone is happy and helping

16:11 <firefrommoonligh> Don't feel like the merge to master is required

16:11 <firefrommoonligh> Use your PR fork

16:33 <dav1d> Is there a mqtt client for embassy?

16:52 <firefrommoonligh> I think Dirbaio mentioned one a few weeks ago. FYSA I am building a greenfield project at work using Rust with MQTT, but it's a PC software, so using Paho. Paho is great BC it's an official port and has an API similar to the C++ and Python ones, but won't work nostd

16:52 <firefrommoonligh> Also, it's super weird programming for job. Can get used to it .

17:59 <lulf[m]> There is https://crates.io/crates/rust-mqtt and https://crates.io/crates/minimq

18:10 <lulf[m]> * dav1d: There is

18:12 <dav1d> lulf[m], nice thanks, the first one actually is using the embedded-io-async traits!

18:16 <jessebraham[m]> dav1d: Some of my colleagues have used this and recommended it

18:16 <dav1d> cool thanks! I was wondering if I event want to use/test mqtt but this looks simple enough

18:21 <lulf[m]> You need to use the git dependency for now, the latest release is missing fixes to work with latest embassy. I have ownership of the crate now so only myself to blame for that lazyness 😀

18:21 <lulf[m]> s/lazyness/laziness/

18:24 <dav1d> that's fine, thanks for the headsup

21:17 <zaven[m]> yo, somewhat new to rust and the f103 hal, it's unclear to me how to use the ADC from the example and reading adc.rs. i see that in read_temperature we make use of read_aux, but read_aux being private how am I meant to call it for convert other channels on the ADC ?

21:52 <zaven[m]> s/read_temperature/read\_temperature/, s/read_aux/read\_aux/, s/read_aux/convert/

22:09 <zaven[m]> ok looks like the answer is probably

22:09 <zaven[m]> `let res: Result<u16, nb::Error<()>> = adc.read(&mut self.pins.channel1);`

22:10 <zaven[m]> the example given in the hal is thus not very useful, since it only shows how to read the aux channels (on chip temp sensor). shall I submit a PR with an update to this example, showing the above line as the way to read any analog pin?

22:17 <M9names[m]> If you could update the example to do both (read the aux channel and a pin) that would be great

22:26 <zaven[m]> sure no problem, that makes sense