00:54 <re_irc> < (@adamgreig:matrix.org)> has the room icon disappeared for anyone else 🤔

00:56 <re_irc> < (@jessebraham:matrix.org)> I still see it

06:22 <re_irc> < (@yuhanliin:matrix.org)> cr1901: I've been trying to update my MSP430 HAL to the latest ecosystem crates and I've been running into some link errors when building the examples. I used the "-lmul_32" link flag, because my chip uses a 32-bit multiplier. However, I've been getting the following linker error:

06:22 <re_irc> = note: /home/yuhan/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/8.3.1/430/libmul_f5.a(lib2hw_mul_f5.o): In function '__muldi3':

06:22 <re_irc> (.text.__muldi3+0x0): multiple definition of '__muldi3'

06:22 <re_irc> /home/yuhan/projects/rust/embedded/msp430fr2x5x-hal/target/msp430-none-elf/debug/deps/libcompiler_builtins-b8a7118326f0a1f6.rlib(compiler_builtins-b8a7118326f0a1f6.compiler_builtins.03021f45-cgu.0.rcgu.o):compiler_builtins.03021f45-cgu.0:(.text.__muldi3+0x0): first defined here

06:22 <re_irc> In addition, I also get "undefined reference to 'abort'". This error seems to originate from PAC reads/writes.

06:27 <cr1901> undefined reference to abort can be solved by adding your own abort function for debug mode: https://github.com/rust-embedded/msp430-quickstart/blob/master/src/main.rs#L26-L32

06:28 <cr1901> I've never used an msp430 w/ the hardware multiplier... interesting there's a conflict when anything besides -lmul_none is supplied

06:29 <cr1901> yuhanliin: I'm about to call it quits for the night. Lemme know if you figure anything else out re: the multiplier. I'm not sure what's wrong

06:33 <re_irc> < (@yuhanliin:matrix.org)> I added "-Wl,--allow-duplicate-definition" to sidestep the multiplier error. IDK if that's a good idea though.

13:12 <re_irc> < (@diondokter:matrix.org)> Hey so, there is an existing device driver out there I want to use. But I'm writing async code and the driver is blocking.

13:12 <re_irc> How do I proceed? (Because every path has different pros and cons)

13:12 <re_irc> 2. Add a separate async module to the current driver and make a PR. This will duplicate >50% of code!

13:12 <re_irc> 1. Fork and create a new repo "drivername-async" and just make the entire driver async

13:12 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/3aious9HEVHRRNmF4JfAWueJHnhR8yMX (10 lines)

13:13 <re_irc> < (@diondokter:matrix.org)> Hey so, there is an existing device driver out there I want to use. But I'm writing async code and the driver is blocking.

13:13 <re_irc> How do I proceed? (Because every path has different pros and cons)

13:13 <re_irc> 1. Fork and create a new repo "drivername-async" and just make the entire driver async

13:13 <re_irc> 2. Add a separate async module to the current driver and make a PR. This will duplicate >50% of code!

13:13 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/ErXogEYtMXltsfBuQ7cLBYBdDjYjRdU4 (14 lines)

13:15 <re_irc> < (@diondokter:matrix.org)> Hmmm, there is a library already for the last one: https://github.com/fMeow/maybe-async-rs

13:16 <re_irc> < (@dirbaio:matrix.org)> "maybe-async" is cursed

13:16 <re_irc> < (@diondokter:matrix.org)> Ah good to know haha

13:17 <re_irc> < (@xiretza:xiretza.xyz)> : all the best things are

13:17 <re_irc> < (@dirbaio:matrix.org)> I mean yes, it does work

13:17 <re_irc> < (@dirbaio:matrix.org)> but you have to "stick" to the lowest common denominator of both blocking+async

13:18 <re_irc> < (@dirbaio:matrix.org)> you lose the best of async: you can't use "with_timeout", join/select, or multiple tasks to coordinate stuff

13:18 <re_irc> < (@diondokter:matrix.org)> Basically it's just that there's a read_register and a write_register function. Those must be made async and anything that uses it must become async

13:18 <re_irc> < (@dirbaio:matrix.org)> and you still have to deal with the bad parts of async, like cancelation

13:19 <re_irc> < (@dirbaio:matrix.org)> user might call one of your functions inside "with_timeout", canceling it halfway and leaving the device in an inconsistent state, etc

13:19 <re_irc> < (@diondokter:matrix.org)> True

13:20 <re_irc> < (@diondokter:matrix.org)> Hmmm, yeah so that would require a critical section between every read and write in a modify at least

13:21 <re_irc> < (@dirbaio:matrix.org)> critical sections can't prevent async cancelation

13:21 <re_irc> < (@dirbaio:matrix.org)> they prevent concurrency, but you can already forbid that by exclusively owning the spi/i2c device

13:22 <re_irc> < (@diondokter:matrix.org)> Ah yes I see

13:22 <re_irc> < (@dirbaio:matrix.org)> also you might want to have a different public API for blocking vs async...

13:23 <re_irc> < (@dirbaio:matrix.org)> for xample, for devices using pin interrupts. in async you can just "wait for high", in blocking you want the user to do it by using irqs manually and call a callback..

13:23 <re_irc> < (@diondokter:matrix.org)> Ok so, there will be code duplication. So no option 3

13:24 <re_irc> < (@diondokter:matrix.org)> What then? Option 1 or 2?

13:24 <re_irc> < (@dirbaio:matrix.org)> it might work for a simple device that's just "read reg, write reg" and has no pin irqs nor concurrency

13:25 <re_irc> < (@dirbaio:matrix.org)> but you can't just slap maybe-async on any driver and have it magically support blocking+async

13:25 <re_irc> < (@diondokter:matrix.org)> Well, it has some simple irq stuff. It's an accelerometer

13:25 <re_irc> < (@dirbaio:matrix.org)> : or just support async :D

13:25 <re_irc> < (@dirbaio:matrix.org)> +only

13:25 <re_irc> < (@diondokter:matrix.org)> I'm not the author of the crate :)

13:26 <re_irc> < (@diondokter:matrix.org)> So you're saying to just make a new crate?

13:26 <re_irc> < (@dirbaio:matrix.org)> ah.. then I dunno, ask the author

13:26 <re_irc> < (@dirbaio:matrix.org)> supporting only async is not that bad

13:27 <re_irc> < (@dirbaio:matrix.org)> if the user's HAL doesn't support async, they can use an adapter like BlockingAsync to 'convert" from blocking i2c/spi to async i2c/spi emedded-hal

13:27 <re_irc> < (@dirbaio:matrix.org)> and if the user doesn't have an executor they can use "block_on()" to call into the driver

13:27 <re_irc> < (@diondokter:matrix.org)> Well yeah, but that'd be a very annoying change for existing users

13:27 <re_irc> < (@dirbaio:matrix.org)> the only downside is code size

13:27 <re_irc> < (@dirbaio:matrix.org)> but yeah if the existing driver is already blocking it'll be a tough sell to the maintainer D:

13:28 <re_irc> < (@diondokter:matrix.org)> It is

13:30 <re_irc> < (@mabez:matrix.org)> : You can add a blocking module that keeps the blocking interface but under the hood will use "block_on()"

13:30 <re_irc> < (@diondokter:matrix.org)> That's also true

13:30 <re_irc> < (@mabez:matrix.org)> I suggested this approach for the fatfs library: https://github.com/rafalh/rust-fatfs/issues/71 but the maintainer doesn't seems interested... dont blame him tbh!

13:31 <re_irc> < (@mabez:matrix.org)> Keywork generics would be nice :)

13:31 <re_irc> < (@mabez:matrix.org)> * Keyword

13:31 <re_irc> < (@diondokter:matrix.org)> But then the user must also provide an async I2C implementation which their current HAL probably doesn't have

13:31 <re_irc> < (@dirbaio:matrix.org)> keyword generics will run into the same problems as maybe-async

13:32 <re_irc> < (@dirbaio:matrix.org)> you can't abstract over blocking+async, they're just too different

14:31 <re_irc> < (@eldruin:matrix.org)> PSA: embedded-hal-async 0.1.0-alpha.3 (https://crates.io/crates/embedded-hal-async/0.1.0-alpha.3) is out! thanks goes to and 🎉

20:05 <cr1901> >you can't abstract over blocking+async, they're just too different <-- I don't have an opinion either way, but the ppl who are working on keyword generics explicitly don't think this is true and in the cases where it is, they will provide "some sort of" escape hatch

20:06 <cr1901> It's in the proposal for keyword generics, which I am too lazy to look up rn :P

20:24 <re_irc> < (@dirbaio:matrix.org)> cr1901: keyword generics can work to avoid duplication like "get/get_mut", "map/map_async" etc

20:24 <re_irc> < (@dirbaio:matrix.org)> like, "map" taking a blocking closure, "map_async" taking an async closure

20:24 <re_irc> < (@dirbaio:matrix.org)> so you do a generic "map" instead that can take both kinds of closures, and is async itself if the closure is

20:25 <re_irc> < (@dirbaio:matrix.org)> I see the value in that

20:25 <re_irc> < (@dirbaio:matrix.org)> but not for a whole driver...

20:26 <cr1901> I would have to see the whole proposal to determine for myself whether it's feasible to write a single HAL driver for blocking, async, and maybe even nonblocking

20:27 <re_irc> < (@dirbaio:matrix.org)> single HAL yes, embassy kinda does that

20:27 <re_irc> < (@dirbaio:matrix.org)> you can share quite a bit of code between async+blocking, like "setup transfer" and "cleanup transfer"

20:28 <re_irc> < (@dirbaio:matrix.org)> while "wait for transfer done" is different

20:29 <re_irc> < (@dirbaio:matrix.org)> and it becomes quite annoying for more complex periphs where you do lots of "wait for" (looking at you stm32 i2c >_>)

20:29 <re_irc> < (@dirbaio:matrix.org)> so it's more like "2 HALs in one" sometimes :D

21:06 <re_irc> < (@simon:delire.party)> anyone doing RISC-V things, have you tried doing lock-step simulation with Spike? I’m running into this: https://github.com/riscv-software-src/riscv-isa-sim/issues/1134

21:29 <re_irc> < (@oop584:matrix.org)> I'm not in RTL, but my company is the one that wrote Hammer (https://github.com/rivosinc/hammer), so we just use that. Is there a reason you want to use a subprocess as opposed to something like that?

21:54 <re_irc> < (@simon:delire.party)> I just didn’t know something like that existed, thanks!

21:54 <re_irc> < (@simon:delire.party)> (and making it in C++ didn’t sound fun)

21:59 <re_irc> < (@simon:delire.party)> though I might still need so more glue code to use that one from rust

22:08 <re_irc> < (@simon:delire.party)> using a subprocess means I don’t need to make Cargo link to C++ code and mess with bindgen

22:22 <re_irc> < (@oop584:matrix.org)> : Ah, it was linked in the most recent comment of the PR you mentioned so I figured you were referring to that.

22:33 <re_irc> < (@simon:delire.party)> ah indeed, I only read the start of that thread

22:34 <re_irc> < (@simon:delire.party)> with https://github.com/SpinalHDL/NaxRiscv/blob/703bb86106d0db87b9844d28eded3b3608e59a58/src/test/cpp/naxriscv/src/main.cpp#L1399 and such