<korken89[m]>
I have 2 async methods that are in a select! statement, but they need to share a resource (cryptographic accelerator). Is there something better to use than a "vanilla" async mutex when you know they are running at the same priority within the same async task?
<korken89[m]>
* I have 2 async methods that are in a select! statement, but they need to share a resource (cryptographic accelerator). Is there something better to use than a "vanilla" async mutex to share the resource when you know they are running at the same priority within the same async task?
<korken89[m]>
I'm almost thinking about just wrapping an RefCell a Future, but I think someone has probably a better idea :)
<korken89[m]>
* I'm almost thinking about just wrapping an RefCell in a Future, but I think someone has probably a better idea :)
M-[m] has quit [Quit: Idle timeout reached: 172800s]
K900 has quit [Quit: Idle timeout reached: 172800s]
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
<korken89[m]> "I'm almost thinking about just..." <- I guess that could panic if a borrow is held across an await?
<henrik_alser[m]>
But if not, it should be fine?
<henrik_alser[m]>
Otherwise, i can’t think of any other option than async Mutex
<henrik_alser[m]>
* be fine? But then a RefCell without Future would do?
<korken89[m]>
<henrik_alser[m]> "But if not, it should be fine?" <- I was thinking too return poll if the borrow failed, maybe simple enough
<korken89[m]>
* I was thinking about returning poll if the borrow failed, maybe simple enough
<henrik_alser[m]>
korken89[m]: Ahh with try_borrow?
<henrik_alser[m]>
That should work i guess
<korken89[m]>
Yeah, basically that
<korken89[m]>
I'll give it a try, worst case it'll explode in my face :D
Curid[m] has joined #rust-embedded
<Curid[m]>
Isn't that just a mutex with extra steps?
<korken89[m]>
Depends on what the mutex does under the hood
<Curid[m]>
<korken89[m]> "I'm almost thinking about just..." <- You could keep track of the other borrower and wake it up once the first borrow is dropped
<korken89[m]>
Curid[m]: Yeah I think handling the waker is required or one might not run the select statement again on release of the borrow :)
<Curid[m]>
It'll deadlock if you use it outside of a select though
jr-oss_ has quit [Read error: Connection reset by peer]
jr-oss has joined #rust-embedded
<korken89[m]>
<Curid[m]> "It'll deadlock if you use it..." <- As long as it's used within a task it should be fine. Making it !Sync will protect it from being shared
<korken89[m]>
Or did you think of another way it could deadlock?
<JamesMunns[m]>
Are you describing embassy_sync::Mutex with NoopRawMutex?
<JamesMunns[m]>
it's basically a refcell with wakers :D
<henrik_alser[m]>
Yeah that’s the one i was thinking about ^^
<JamesMunns[m]>
korken89 ^
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
<korken89[m]>
<JamesMunns[m]> "Are you describing embassy_sync..." <- This was exactly what I was looking for 🚀
<korken89[m]>
Thanks!
ilpalazzo-ojiis4 has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
jakzale has quit [Remote host closed the connection]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
jakzale has joined #rust-embedded
adamhott[m] has joined #rust-embedded
<adamhott[m]>
I'm trying to implement a driver for an led to use with a custom pcb via PI. I need to use Spi async so I found SpiBus from embedded-hal-async to be the option because I'm not implementing a CS pin (documentation points to SpiBus for that rather than SpiDevice). I also found an embedded-hal trait SpiDma which is also async. I'm wondering if a wrapper is necessary here because I'm getting a trait bound error that SpiDma is not
<adamhott[m]>
implemented in SpiBus.
<JamesMunns[m]>
I'm not sure what you mean by SpiDma?
<adamhott[m]>
It's one of the spi traits from embedded-hal
<JamesMunns[m]>
You could use SpiBus directly (e-hal or e-hal-async), as you don't need a CS pin, are you looking to drive something like WS2812 LEDs?
<JamesMunns[m]>
adamhott[m]: could you show me? I don't see it.
<JamesMunns[m]>
If you are only writing it for your project, you can use whatever interface you want? If you want to make it portable for other people, it sounds like basing it on SpiBus is the right idea.
<JamesMunns[m]>
You didn't answer what kind of LEDs they are, if the SmartLeds crate hasn't been updated, it might be worth doing that?
<adamhott[m]>
oh sorry, it's an hd108-2020
<adamhott[m]>
2 mm x 2mm
<adamhott[m]>
little dudes
<adamhott[m]>
I don't need to read back from them
<adamhott[m]>
I just need to write
<JamesMunns[m]>
Gotcha, looks straightforward! The fact they have clock and data is nice.
<JamesMunns[m]>
if this is esp32 specific (where they impl e-hal traits), it might be worth asking there.
<JamesMunns[m]>
Still unclear on the actual question you have, unless you were just sharing :)
<adamhott[m]>
the trait `embedded_hal_async::spi::SpiBus` is not implemented for `ExclusiveDevice<esp_hal::spi::master::Spi<'_, esp_hal::peripherals::SPI2, FullDuplexMode>, DummyPin, NoDelay>`
<adamhott[m]>
```the trait `embedded_hal_async::spi::SpiBus` is not implemented for `ExclusiveDevice<esp_hal::spi::master::Spi<'_, esp_hal::peripherals::SPI2, FullDuplexMode>, DummyPin, NoDelay>`
<JamesMunns[m]>
Exclusive device is usually a "SpiDevice" thing not "SpiBus"
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
ExclusiveDevice implements SpiDevice, not SpiBus
<adamhott[m]>
Gosh I think I'm looking at the wrong commit
<JamesMunns[m]>
does whatever you got that from have a different constructor? or are you doing an extra step to go from Bus to Device?
<adamhott[m]>
no extra step I don't think, just wrote a driver that implements SpiBus
<adamhott[m]>
I read that since I have no CS pin I should implement SpiBus
<dirbaio[m]>
the embedded-hal traits already have blanket impls for &mut, so this allows using both owned and borrowed spi
<adamhott[m]>
ah interesting
<dirbaio[m]>
while the previous code forces the user to use borrowed spi even if they don't want to
cr1901 has quit [Ping timeout: 264 seconds]
<henrik_alser[m]>
Also even if you don’t use the cs pin, it would be better to write the driver to support it and use a dummy ”cs pin” that doesnt do anything in your specific use of it, if you wanna publish it as a resusable driver
<henrik_alser[m]>
If the device has it i mean
<henrik_alser[m]>
But you just tied it low
<henrik_alser[m]>
But if the device itself doesnt have it, then SpiBus is the right trait
<henrik_alser[m]>
But just a general note :)
<henrik_alser[m]>
* Also even if you don’t use the cs pin, it would be better to write the driver to support it, by using SpiDevice, and use a dummy ”cs pin” that doesnt do anything in your specific use of it, if you wanna publish it as a resusable driver
<adamhott[m]>
thanks henrik, I did try to setup dummy pins, but got an error on that
<adamhott[m]>
but I'll take a closer look at that later
<dirbaio[m]>
The hd108 is one of these smartleds where you use spi to bitbang a non-spi protocol, right?
<dirbaio[m]>
In that case you don't want SpiDevice
<dirbaio[m]>
There's no cs pin
<adamhott[m]>
it's just a daisy chained spi led
<adamhott[m]>
I don't know what bitbang means
<adamhott[m]>
ha
<JamesMunns[m]>
<dirbaio[m]> "The hd108 is one of these..." <- it's a "normal spi" ish one, it has normal clock and data pins
<JamesMunns[m]>
it's not like WS2812
<dirbaio[m]>
but no CS pin
<JamesMunns[m]>
no CS pin
<JamesMunns[m]>
Agree that it should be SpiBus and not SpiDevice.
<henrik_alser[m]>
Ahh sorry, adamhott said the other day there was a cs pin but didnt use it, hence my suggestion
<henrik_alser[m]>
Wasnt familiar with the device in question :)
<adamhott[m]>
no worries, I struggle to explain the behavior since so many terms are new to me
mburton[m] has joined #rust-embedded
<mburton[m]>
LinuxI2CDevice
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
FrreJacques[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]>
Is there a way to find the memory map of my embedded rust program? I'm trying to identify what bit of code is generating a hardfault. My code has captured the PC of that hardfault...
<PhilMarkgraf[m]>
(I've done this too many times to count in C/C++... I am a little chagrined at not being able to figure it out in the Rust tooling.
<dirbaio[m]>
most tools for c/c++ work for rust too
<dirbaio[m]>
for example you can objdump -x the elf
<dirbaio[m]>
or use addr2line
AtleoS has quit [Ping timeout: 268 seconds]
<PhilMarkgraf[m]>
Thank you! (I think I've been using linker commands for proprietary compilers in my past efforts.)
<PhilMarkgraf[m]>
s///, s/Is this a "Greater Than" function?//
<dirbaio[m]>
do you have logs? or just a PC value?
<dirbaio[m]>
logs would tell you if it's a panic, and the panic message
<PhilMarkgraf[m]>
Just a PC value. In my release build, we had to shift to Panic="abort" for space reasons. This is not set for the dev profile... but I may be bouncing the panic to hardfault in my logging code. (I haven't tested with the debug profile in a long while.)
<PhilMarkgraf[m]>
Yep. The panic handler is currently cortex_m::asm::udf(); ... I'll swap this to something conditionally compiled, so I can catch the panic.
<PhilMarkgraf[m]>
* Yep. The panic handler is currently cortex_m::asm::udf(); ... I'll swap this to something conditionally compiled, so I can catch the panic when compiled for debug.
<PhilMarkgraf[m]>
This is taking a little bit... figuring out how to dump the panic when using defmt (in place of rprintln...)