02:12 <corecode[m]> mqtt seems the wrong vehicle to me

02:13 <corecode[m]> to push the ota binary, i mean

02:45 <bibble235[m]> Great!

07:08 <jannic[m]> <ithinuel> "rp2040-hal implements RTIC’s..." <- BTW, it only does this for RTIC v1. Do you have an idea how to also support v2?

07:08 <jannic[m]> Either having dependencies on multiple versions of RTIC or having separate feature flags for the two versions would be somewhat ugly. But just dropping support for RTICv1 also seems wrong, as afaik v1 is still widely used.

08:42 <Ralph[m]> <adamgreig[m]> "yea, @rust-embedded/hal I think?..." <- FYI: as the teams in the rust-embedded org are private it's not possible to ping the team (at least for non-members)

08:50 <badrb[m]> <corecode[m]> "mqtt seems the wrong vehicle..." <- Why?

08:50 <badrb[m]> The intention is to push sliced indexed chunks of a bin, each one checksummed, at the rhythm of the end device.

08:51 <badrb[m]> s/push/publish/

09:21 <michaeldesilva[m> Hi any ideas why my Jlink mini has trouble connecting sometimes?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LHuubMaIFedVaIDHoXMmSbqZ>)

09:22 <lulf[m]> badrb: I used hawkBit a little in the past, though that's http. For Drogue IoT I wrote https://github.com/drogue-iot/drogue-ajour which works on top of mqtt, http, lorawan and coap transport (yay layers on layers). Probably plain TCP or HTTP is just as good compared to MQTT. But for coap and lorawan having the 'message based' dfu protocol was nice as you could do the updates over a long period of time.

09:29 <badrb[m]> <lulf[m]> "badrb: I used hawkBit a little..." <- This look good!

09:29 <badrb[m]> How tightly coupled to Drogue IoT Cloud is it?

10:31 <Ralph[m]> a few weeks ago i already asked this here but never got a definitive answer, so here's another attempt: what is the recommended way for drivers to propagate e-h errors to their consumers? should they bubble up each individual error type or should they just wrap it up in a generic "hardware said no" error as the... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BBGTENIJVnnwDnZSfhXwFdjW>)

10:56 <lulf[m]> <badrb[m]> "This look good!..." <- > <@badrb:matrix.org> This look good!

10:56 <lulf[m]> > How tightly coupled to Drogue IoT Cloud is it?

10:56 <lulf[m]> It relies on mqtt and the event format in drogue cloud(cloudevents.io). There is also embedded-update crate for the device side that generalises the update mechanism with "pluggable" transports to drogue cloud (drogue device has http and lorawan)

12:03 <AdamHott[m]> Can anyone recommend an affordable stm32 board that has Wifi capabilities?

12:03 <AdamHott[m]> I want to test with embassy.

12:41 <ilpalazzo-ojiis4> OK, first things first, what constitutes “affordable”? Could you give, like, three prices for “Below price 1 I'd jump for joy, price 2 appears good, price 3 is the absolute hard upper limit”?

12:42 <lulf[m]> Adam Hott: I've used this devkit in the past https://www.st.com/en/evaluation-tools/b-l475e-iot01a.html - not much value for money compared to rpi pico IMHO though....

12:42 <lulf[m]> * rpi pico w IMHO though....

12:49 <AdamHott[m]> I had some trouble connecting my probe to a rpi pico w board to test, so I'm looking at alternative boards to test.

12:51 <AdamHott[m]> yeah this one is pretty pricey

12:53 <dirbaio[m]> wifi on these is AT-command based, so it doesn't work with embassy-net

12:54 <dirbaio[m]> you can still use it through embedded-nal-async with https://github.com/drogue-iot/es-wifi-driver

12:56 <lulf[m]> Maybe get another pico and use as probe :D In general I would recommend embassy-net over the at-command drivers

12:57 <dirbaio[m]> does it have to be stm32? if not, then an esp32c3 devkit is probably your best bet, using esp-wifi and esp-hal

12:57 <dirbaio[m]> if it *has* to be stm32, then you can wire up the esp32c3 to the stm32 board via spi to use as a dumb wifi adapter with [esp-hosted](https://github.com/embassy-rs/embassy/tree/main/embassy-net-esp-hosted)

13:00 <AdamHott[m]> It doesn't have to be stm32, I'm just looking for an affordable alternative board to test

13:01 <AdamHott[m]> I also have a raspberry pi probe, wondering if I can use that as a probe on an alternative board or if I need to look at another probe

13:06 <dirbaio[m]> raspberry pi probe should work on stm32's too

13:06 <dirbaio[m]> many stm32 boards have a bulit-in stlink though

13:06 <dirbaio[m]> * most stm32 boards from ST have a bulit-in stlink though

13:09 <AdamHott[m]> would the raspberry pi probe work on the esp32c3?

13:11 <mabez[m]> AdamHott[m]: No, but the esp32c3 has its own JTAG probe built into the USB interface and it's well supported by probe-rs - if you're thinking of picking one up I'd recommend the [esp-rust-board](https://github.com/esp-rs/esp-rust-board)

13:13 <vollbrecht[m]> you can directly hook gpio 18/19 of that chip into your PC and have a jtag/usb-cdc connection without any 3rd party chip whatsoever

13:15 <AdamHott[m]> mabez[m]: that's the one from Mouser Electronics that's linked in the repo, right?

13:16 <mabez[m]> AdamHott[m]: Correct, it should also be available on Digikey if you prefer :)

13:17 <danielb[m]> Fair warning, probe-rs has some issues with the c3, though, for some users

13:20 <AdamHott[m]> danielb[m]: problems connecting?

13:21 <AdamHott[m]> <vollbrecht[m]> "you can directly hook gpio 18/19..." <- would that involve splicing a cable?

13:51 <firefrommoonligh> <danielb[m]> "Fair warning, probe-rs has..." <- FYSA I wasn't able to get it working, but I didn't try too hard

13:52 <danielb[m]> Sorry, what's fysa? 🙈

13:53 <firefrommoonligh> for your situational awareness

13:57 <vollbrecht[m]> <AdamHott[m]> "would that involve splicing a..." <- depending on the board, this two gpio pins are directly connected to the usb-header without any chips in between. The rust board does exactly that. But if you for example just get the naked esp32c3 module you could just use it with something like [this](https://images.app.goo.gl/D6jz5effkEex8MVQ9) connecting the usb+ / - to those pins directly.

13:59 <vollbrecht[m]> though to be safe i still would put minimal usb protection in series here with some special clamping diodes.

14:00 <vollbrecht[m]> but its just info, this is all not needed for the mention rust dev board

14:00 <vollbrecht[m]> * its just general info, this

15:14 <Ralph[m]> <Ralph[m]> "a few weeks ago i already..." <- > <@rursprung:matrix.org> a few weeks ago i already asked this here but never got a definitive answer, so here's another attempt: what is the recommended way for drivers to propagate e-h errors to their consumers? should they bubble up each individual error type or should... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HredomMimyhUaYqUewaererE>)

15:15 <corecode[m]> oh i managed to build a docker container for embedded arm work: https://hub.docker.com/r/bitsandelectrons/rust-embedded-arm

15:56 <pauldotsh[m]> How good is rust support on esp32 and on arduino uno?

16:02 <Ralph[m]> <pauldotsh[m]> "How good is rust support on esp3..." <- for arduino you currently need to use nightly rust, see: https://github.com/Rahix/avr-hal/issues/471

16:02 <Ralph[m]> no experience with esp32 from my side, but there's this: https://github.com/esp-rs

16:26 <JamesMunns[m]> My $0.02, doing Rust on AVR is a fairly advanced thing, the compiler sometimes doesn't work reliably, and requires some setup. it's way more bleeding edge than Cortex-M.

16:28 <vollbrecht[m]> pauldotsh: look at the https://esp-rs.github.io/book/ for infos around rust on esp's

16:28 <vollbrecht[m]> and feel free to ask around in https://matrix.to/#/#esp-rs:matrix.org

18:15 <vollbrecht[m]> C strings alla `c"my null terminated c string"` are stabilized for the upcoming rust 1.77. So no CStr::from_bytes_with_nul() anymore. Here are the [docs](https://doc.rust-lang.org/nightly/edition-guide/rust-2021/c-string-literals.html) 🎉

18:29 <JamesMunns[m]> oh that's cool!