00:06 <M0e4ef622[m]> <KevinPFleming[m]> "OK, thanks for the tips, I think..." <- I've toyed with the idea of having one `memory.toml` and then the have the application/bootloader build.rs generate the memory.x from that.

00:08 <KevinPFleming[m]> M0e4ef622[m]: Interesting idea... that's more capable but requires more copy-paste code in the build script.

01:01 <KevinPFleming[m]> I've got a branch using the far crate working with my idea... I'll get it posted for comments tomorrow.

06:58 <Ralph[m]> <ivmarkov[m]> "Can't imagine not having select..." <- can you elaborate on this? i'm only aware of `select!` (both with embassy and tokio)

07:00 <Ralph[m]> <Noah[m]> "is there an easy way to get a..." <- simple: throw it into the recycling bin and get something else which exposes debug pins 😉

07:00 <Ralph[m]> (i have one of those POS on my desk and am forced to interact with it. i think board designers not exposing debug pins or offering a built-in debugger via USB should be publicly shamed and never allowed to make a board ever again 🤬)

07:06 <M9names[m]> I think teensy is just fine for what it's intended for (a high-performance Arduino).

07:06 <M9names[m]> If you are trying to use it for something else, that's kinda on you

07:06 <ivmarkov[m]> <Ralph[m]> "can you elaborate on this? i'm..." <- `embassy_futures` does not have a `select!` macro. It has a bunch of `select` functions, as in `select`, `select3`, `select4`, `select_array` and so on. While they are a bit more restrictive, the are overall also simpler to use. And don't require futures to be fused.

07:08 <ivmarkov[m]> race from futures_lite seems to be similar to embassy_futures::select

07:08 <ivmarkov[m]> * race and or from futures_lite seems to be similar to embassy_futures::select

07:26 <Ralph[m]> ah, i used tokio so much lately that i forgot about the difference in embassy 😅 (haven't used async on embedded that much yet - at least not in cases where i needed select)

09:50 <Ralph[m]> i'm in need of some suggestions for an `std` async problem (using `tokio`):... (full message at <https://catircservices.org/_irc/v1/media/download/AfHYumfC3H4cpzBs7dqd4CnQGoW_j5zvcmnEL0ZS6ZqrL62H_hMSeS-luM0UM-z_N24VKtBB2HB6PzpST59z5FO_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9wb1NWd05tSmdZSkhzQ1lNeU9pRGRPbnU>)

10:02 <Ralph[m]> hm, maybe i could spawn a new thread just to launch the external process from there and then await it there? that feels like complete overkill, though...

10:02 <Ralph[m]> but then i could also skip the `Option`s and instead check `JoinHandle::is_finished` in `Drop` (not sure if i'm allowed to `await` a `JoinHandle` which already finished? IIRC it wasn't allowed to `await` an already finished `Future` a second time in async rust?)

10:55 <KevinPFleming[m]> Draft PR for cortex-m-rt to allow custom memory region names: https://github.com/rust-embedded/cortex-m/pull/601

10:55 <KevinPFleming[m]> Lots of CI failures, but they don't seem to be related to the PR contents.

11:04 <dngrs[m]> <Ralph[m]> "i'm in need of some suggestions..." <- > <@rursprung:matrix.org> i'm in need of some suggestions for an `std` async problem (using `tokio`):... (full message at <https://catircservices.org/_irc/v1/media/download/AeVVxzSh04tY74b0gE0nIeAkXqSL8UZM56xiOb7GRfbpiolSg6YmPKbhtUaIbTY2aXc3cqd5LNst8PozXkneTpa_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9Jc1RNUUpoUWZyUHlNZWhnUm9kcUpVY1k>)

11:49 <jf-uu[m]> Is there a crypto library I can use in an no_std / no alloc environment to do mTLS for MQTT? (connecting to AWS MQTT). I found https://docs.rs/embedded-tls/latest/embedded_tls/ but it sounds like it doesn't support server certificate validation.

11:50 <dngrs[m]> yeah, long standing issue: https://github.com/drogue-iot/embedded-tls/issues/13

11:50 <jf-uu[m]> Aye saw that - there is a PR open to switch from webpki to RustCrypto but it's in early days by the looks of it.

11:51 <jf-uu[m]> * to RustCrypto for server certificate validation but it's

11:52 <dngrs[m]> for me personally reserving a bit of ram for having an allocator isn't a deal breaker; that said I don't know of a no_std + alloc solution either 😬

11:52 <jf-uu[m]> What options are there if I do have an allocator?

11:53 <dngrs[m]> it's just my take on the issue discussion

11:53 <dngrs[m]> * on the linked issue discussion

11:55 <jf-uu[m]> It sounds like rustls might support no_std now actually, I'll give that a go with an allocator I guess.

11:55 <lulf[m]> With alloc there is the webpki support that you can enable via the 'webpki' feature, that enables a verifier that you can use https://github.com/drogue-iot/embedded-tls/blob/main/src/webpki.rs#L101

11:56 <jf-uu[m]> Ah I didn't realise webpki worked with no_std+alloc, thought it required std. I'll give that a go first, cheers

11:56 <dngrs[m]> oh, I had missed that as well

12:05 <vollbrecht[m]> a alternative, ( maybe not as nice as a pure rust tls version) may be to use mbedtls. ( This can be run on no_std but needs a allocator)... (full message at <https://catircservices.org/_irc/v1/media/download/AR-P5pKJAJQYmQmLzEI8AOITXfauecIdRSrsrDQA2lg6A2F3qwZmjUFy8ZiIEOTHMhpc__AuzLzFMHzCcQRryMW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9iQldwbGx4TG1uSk9id3h2Q3pFdHdZdUU>)

12:08 <vollbrecht[m]> if you for example use something like [edge-net](https://github.com/ivmarkov/edge-net) you can use this as your tls provider

12:40 <Ralph[m]> <dngrs[m]> "> <@rursprung:matrix.org> i'm in..." <- i've managed to avoid discord for now... 🙈

12:41 <Ralph[m]> <Ralph[m]> "hm, maybe i could spawn a new..." <- i think i now have the solution: i now indeed spawn a new thread to launch - and await - the child process as well. and i'm using _two separate_ [`TaskTracker`](https://docs.rs/tokio-util/latest/tokio_util/task/task_tracker/struct.TaskTracker.html)s which offer `wait(&self)` which i can use. this, combined with a cancellation token (to kill the threads - i use another `select!` in

12:41 <Ralph[m]> there) seems to work fine!

12:55 <dngrs[m]> <Ralph[m]> "i've managed to avoid discord..." <- Maybe they have a bridge, I don't know

18:24 <jbeaurivage[m]> I'm not sure if it's a regression or not, but trying to upgrade from `svd2rust` 0.33 to 0.36, some register groups which were previously represented as an array are now explicitly listed.... (full message at <https://catircservices.org/_irc/v1/media/download/AcEvDOvxp1CRrGHTSOl2IjYLIEiZcBRcMYSl25GbcvzPyO1xE5DUzpEEME5z6sFpC3DGh09BW-PAFpryhoYoCW6_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9pQkJKY0F6cHpEWXBCbGFoRUp1RWVPeEk>)

18:24 <jbeaurivage[m]> * I'm not sure if it's a regression or not, but trying to upgrade from svd2rust 0.33 to 0.36, some register groups which were previously represented as an array are now explicitly listed.... (full message at <https://catircservices.org/_irc/v1/media/download/Abclxy3EqdFojVdJxjmQN_xroU_Vx5j5Om2GZ-wGLkiF6VmZofokbQPV_b-zhICuGp2hrEk0QEb1P_C8YJYbsJy_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy94UUlKbXpQVktDdWhVcFBZS1dBZHpYTVA>)