RockBoynton[m] has quit [Quit: Idle timeout reached: 172800s]
swork[m] has quit [Quit: Idle timeout reached: 172800s]
jistr has quit [Quit: quit]
jistr has joined #rust-embedded
gregormoritz[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
<zaven[m]>
<M9names[m]> "also: you could help prepare a..." <- Ok yeah I found that, the main branch is working but there's no release.. What should I do to help prepare a release? Contact the maintainers, or is there a standard process I can read up on?
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
duderonomy has joined #rust-embedded
korken89[m] has joined #rust-embedded
<korken89[m]>
Has anyone tried to impl a trait which has a const generic in an impl block? I'm trying to glue together an external lib, where a GPIO trait is parameterized over a const generic - but I can't add the const generic when I... (full message at
<FrreJacques[m]>
I have some questions about idiomatic rust. I started to read the API standards again and already found that I should remove the get_ in methods. But I also stumbled over error handling.
<FrreJacques[m]>
Should one use .unwrap() or? In a lib? I used that on checking whether the inputs are high or low. I also didn't really saw how the code should handle an Err here without panicking.
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
rainingmessages has quit [Client Quit]
rainingmessages has joined #rust-embedded
<M9names[m]>
It's usually bad form to panic in a library, you should return an Err to your user - preferably one that gives them enough information to decide what to do with it.
<M9names[m]>
That way the user of the library can then decide the best course of action, whether it's retrying, rebooting, or simply panicking
Kaspar[m] has quit [Quit: Idle timeout reached: 172800s]
<Dlaw[m]>
Dlaw[m]: If the compiler allowed me to `impl <P: ExternalGpio<N>, const N: u8> Output<P> {}` then I would end up with two (possibly conflicting) implementations of `Output` for `u32`.
<Dlaw[m]>
Dlaw[m]: Not knowing anything about the external library, I wonder if `N` should be an associated constant rather than a const generic.
<Dlaw[m]>
* If the compiler allowed `impl <P: ExternalGpio<N>, const N: u8> Output<P> {}`, then you would get two conflicting implementations of `Output<u32>`.
<korken89[m]>
Dlaw[m]: Thanks for the clarification! I came to the same conclusion. I too think the const generic should be an associated constant, but I don't control that library. I'm going to poke it though :)
<Dlaw[m]>
* If the compiler allowed `impl<P: ExternalGpio<N>, const N: u8> Output<P> {}`, then you would get two conflicting implementations of `Output<u32>`.
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
<cgc17[m]>
i checked a couple of board support crates, but didn't see anything pre-made for it. it basically lets you set a channel and then send/receive to other microbits on the same channel.
<cgc17[m]>
i am also happy to implement it if it doesn't exist, so any (simple, ideally) example of how to work with the radio at all using the PAC may be helpful. at this point i don't even know where to start w/ it.
<drahnr[m]>
EDIT: bah, it works if I downgrade embassy-nrf to 0.2.0 and embassy-executor to 0.6.0, using nrf-softdevice at 0.1.0
<drahnr[m]>
It's unfortunate rust doesn't have a good mechanism for detecting the source of conflicting symbols at linktime.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
you have something pulling the old nrf52832-pac
<dirbaio[m]>
instead of downgrading, you can use cargo tree to find out what it is and update that to use nrf-pac
<drahnr[m]>
Aware, but that package was at it's latest published version 🫠
<dirbaio[m]>
which one it is?
<dirbaio[m]>
* which one is it?
<drahnr[m]>
I am amidst debugging, so will get back to that :)
Lumpio- has quit [Ping timeout: 265 seconds]
Lumpio- has joined #rust-embedded
almindor[m] has joined #rust-embedded
<almindor[m]>
is it possible to get an SPI instance with esp-hal such that it's both sync AND async? (e.g. implements both traits)
danielb[m] has joined #rust-embedded
<danielb[m]>
Async should implement the blocking things, did we miss that?
<almindor[m]>
so I have a use case where a bit of hybrid approach is wanted, basically the "init" sections always use delays anyhow so I'd like to "re-use" the code and just do them sync, but actual data transfers should be async
<almindor[m]>
it works on the trait logic level, but looking at how hals implement async it seems it's fully mutually exclusive
<almindor[m]>
I'm trying to make mipidsi async support such that [models like this one](https://github.com/almindor/mipidsi/blob/master/mipidsi/src/models/st7789.rs#L21-L54) can be just re-used even in an async context since the init code basically never needs to run "during hot times" (e.g. when blocking the executor would be a major issue). I've managed to do it with the new display interface definition and a bit of smart wrapper + a buffer
<almindor[m]>
for async flushing, but now I realize that while I can use things like `hal::SpiDevice + hal-async::SpiDevice` it doesn't seem that the hal implementations actually allow this :(
<danielb[m]>
why not?
<danielb[m]>
if the traits are implemented, and you can formulate your solution with them, but the hals don't do what you want, it might be a bug in the hal
<almindor[m]>
because the hals seem to make it exclusive
<almindor[m]>
you either create an Spi (sync) instance or get the async version out of it with something like spi.with_async()
<almindor[m]>
but they seem to be taken as two separate and mutually exclusive entities
<danielb[m]>
Ill have to double check this tomorrow
<almindor[m]>
oh hmm you might be right, it seems it should be generic over M (mode)
<almindor[m]>
so technically the .with_async() instance of Spi should have both traits
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<almindor[m]>
I'm getting embedded-hal version conflicts though, which somehow point to embassy-time crate but I can't see why o.O
<almindor[m]>
AFAIK both my lib and embassy-time use e-h and e-h-async 1.0
<dirbaio[m]>
the real issue is `GpioPin<6>: embedded_hal::digital::OutputPin` doesn't hold
<dirbaio[m]>
and then it "helpfully" points out there's two versions of e-h around and points at embassy-time as the source (because embassy-time implements both v0.2 and v1.0, that's expected)
<almindor[m]>
is it jus tmissing into_output kind of thing?
<dirbaio[m]>
but I don't think that's the issue? like, `GpioPin<6>` doesn't implement 0.2 OutputPin either, does it?
<dirbaio[m]>
so the fact that there's two e-h versions is completely irrelevant here lol