Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Foxyloxy has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
slabity[m] has joined #rust-embedded
<slabity[m]>
I'm trying to find some examples of the embedded-hal crates running on an RP2040, but I can only find guides on using it with STM32 type boards. Anyone know of where I can find that information?
pflanze has quit [Read error: Connection reset by peer]
pflanze has joined #rust-embedded
<ithinuel[m]>
<slabity[m]> "I'm trying to find some examples..." <- There are several examples available in these repos:
<ithinuel[m]>
ithinuel[m]: If you have any question, you can ask on #rp-rs:matrix.org 🙂
<slabity[m]>
<ithinuel[m]> "If you have any question, you..." <- I guess I'm a bit confused where the divide between the `embedded-hal` crate and `rp-hal` comes into play. I guess I'll ask any questions in that room.
<AugustoRoman[m]>
AugustoRoman[m]: I know that the hub75 lifetime should exceed the callback lifetime. I'm not sure
<AugustoRoman[m]>
if the lifetime of display will outlast the callback? Is there a real problem
<AugustoRoman[m]>
here or is there some annotation I need to add?
<AugustoRoman[m]>
* I know that the hub75 lifetime should exceed the callback lifetime. I'm not sure if the lifetime of display will outlast the callback? Is there a real problem here or is there some annotation I need to add?
<AugustoRoman[m]>
* 👋 I'm new to rust and struggling with lifetime woes for embedded dev. I have a triple-buffered frame buffer and trying to DMA the contents of one of the buffers to the display. I think I have everything else working for the writing of the buffers, but doing the DMA transfer is an async operation and the view callback I wrote doesn't play nicely with the static Hub75 display driver.
<AugustoRoman[m]>
More details in the thread.
<AugustoRoman[m]>
* I know that the hub75 lifetime should exceed the callback lifetime. I'm not sure if the lifetime of display will outlast the callback? Is there a real problem here or is there some annotation I need to add?
<barafael[m]>
I have a simple no_std library which defines some protocol types. It is marked: #![cfg_attr(not(test), no_std)]. I can't seem to figure out how to derive schemars::JsonSchema for my types (this macro requires std). I have tried cfg_attr, optional deps, etc.
AtleoS has joined #rust-embedded
AtleoS has quit [Quit: AtleoS]
<enaut[m]>
barafael: I guess you have to manually implement the trait?
almindor[m] has joined #rust-embedded
<almindor[m]>
how is hw CS supposed to be implemented with embedded-hal 1.0 SpiBus/SpiDevice and embedded_hal_bus ? (in the HAL level) Can I use embedded_hal_bus or do I need to implement my own?
<almindor[m]>
and as a side note: if SPI HW is controlling the delays, how should I approach the spi::Operation::DelayNs ? Just as a no-op"
<almindor[m]>
s//`/, s//`/, s/"/?/
IlPalazzo-ojiisa has quit [Quit: Leaving.]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
<almindor[m]> "how is hw CS supposed to be..." <- either don't use it: provide SpiBus (no CS), end users use GPIO pins for CS. if you must use it, e.g. linux spidev, only provide SpiDevice with managed CS
<adamgreig[m]>
<almindor[m]> "and as a side note: if SPI HW is..." <- the DelayNs is generally outside the HW delay, e.g. you should ideally sequence the specified delay in the transaction in between hardware operations
<dirbaio[m]>
because you can't put blocking and async things on the same shared bus
<barafael[m]>
I see now!
<dirbaio[m]>
the HAL struct can impl both, becuase you're not sharing it
<dirbaio[m]>
when you share it you have to pick
<barafael[m]>
dirbaio[m]: is that necessarily so? That is unexpected
<dirbaio[m]>
well
<dirbaio[m]>
generally async requires more resources (in this case, a DMA channel)
exark has joined #rust-embedded
<dirbaio[m]>
so the Async in generics indicates "this i2c supports async because it's been given the extra resources on new() "
<dirbaio[m]>
but it can also do blocking just fine
<barafael[m]>
aha. So if I use it in a context that just requires blocking it'll just fallback on that trait implementation
<dirbaio[m]>
yea
<dirbaio[m]>
it implements both the blocking traits (from both eh0.2 and eh1.0) and the async traits (from eha1.0) at the same time
<dirbaio[m]>
it's sometimes useful if you want to mix blocking and async code
<dirbaio[m]>
just not with sharing behind a mutex
<dirbaio[m]>
because on nostd you can't really do a mutex that is lockable both blockingly and asyncly at the same time
<dirbaio[m]>
(on std you can, because you have "real" threads)
<barafael[m]>
thanks for your help :) blocking it is :)
<barafael[m]>
awesome job dirbaio keeping on top of all this!
<barafael[m]>
ironically, in my application, there are different operation modes. One uses the i2c1 bus for one peripheral and the other for a different one. So not really sharing going on strictly speaking. I had the bus in an Option and simply used it, putting it back into the option after that.
<barafael[m]>
Now with the bus sharing there is less unwrapping and as_muting and it's a little more future-proof
<almindor[m]>
adamgreig: thanks, one last thing on the SPI side. The `read` trait in `SpiBus/Device` mentions sending a "default" byte during the read. Am I to understand that it's essentially a `transfer` with a filler write buffer?
<adamgreig[m]>
Yea, spi always has to be sending something so it's just up to the hal what to send during reads
<almindor[m]>
and that byte value is just "whatever"
<almindor[m]>
seems a bit odd, what's the use of this method then? to save a few bytes vs transfer?
<dirbaio[m]>
usually 0x00
<dirbaio[m]>
the advantage of read() is if you only want to read, you don't have to allocate a separate buffer for the dummy write
<almindor[m]>
right, so a few bytes :D ok
<dirbaio[m]>
nor bus bandwidth for the written data because you don't have to send it to the peripheral (though this is very rarely a concern. maybe with DMA if your SPI is superfast)
<dirbaio[m]>
yeah a few bytes if the transfer is just a few bytes :)
<almindor[m]>
ok, and for normal read/write, should the SPI block until the full buffer is read, or just until no more data is available?
<dirbaio[m]>
full buffer always
<almindor[m]>
busy-loop-wait?
<dirbaio[m]>
SPI has no concept of "no more data available", it's always the master that decides how many bytes are transferred, by choosing how many SCLK cycles it does. the peripheral can't force the master to wait, or otherwise "not send" a byte
<dirbaio[m]>
transferring N bytes always takes n*8/freq time
<dirbaio[m]>
* SPI has no concept of "no more data available", it's always the master that decides how many bytes are transferred, by choosing how many SCLK cycles it does. the slave device can't force the master to wait, or otherwise "not send" a byte
<almindor[m]>
ok, I think https://github.com/riscv-rust/e310x-hal/pull/58 should be ok now, not sure if anyone else has e310x (e.g. hifive1) but I'd be nice if I could get some other eyes on this
<almindor[m]>
needs to still be tested, especially the delay stuff, I don't think the ns granularity will work
Guest15 has joined #rust-embedded
Guest15 has left #rust-embedded [#rust-embedded]
sajattack[m]1 has quit [Quit: Idle timeout reached: 172800s]