pbsds35 has quit [Read error: Connection reset by peer]
pbsds356 is now known as pbsds35
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<i509vcb[m]>
James Munns: for questions relating to postcard just head to the onevariable matrix or dm you? Or is there somewhere else?
<i509vcb[m]>
(Not looking for consulting unfortunately, I am a poor Uni student. Mainly some question around highly dynamic endpoint lists)
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Here or there works! OV room is sort of for all of postcard/postcard-rpc/Poststation. I don't charge for chatting in public, only for private advice or when folks want a guaranteed response time :D
m5zs7k has quit [Ping timeout: 244 seconds]
m5zs7k has joined #rust-embedded
gaivs[m] has joined #rust-embedded
<gaivs[m]>
Do anyone know if it is possible to read and write u16's directly to SPIs on the raspberry pi? I have a sensor I wanted to write a small driver for, where I know that the data I read is u16's, and I'd love to be able to allocate and read out a buffer of data as [u16; 1000], rather than first reading out a [u8, 2000] and manually convert this to the correct buffer
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
Presumably there is transmute as an option here if you don't mind being undafe
<davidmpye[m]>
Unsafe. Probably not a bad use for it here?
M9names[m] has joined #rust-embedded
<M9names[m]>
There's also align_to()/align_to_mut(), don't need any unsafe if you use those instead of transmute, just need to ensure your buffer has room with alignment losses if you start with the smaller element size
<M9names[m]>
But they weren't asking for conversion options.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
M9names[m]: but align_to is also unsafe, right?
<JamesMunns[m]>
yeah, but harder to misuse
<adamgreig[m]>
sure, but still need unsafe
<M9names[m]>
Ah, must have misremembered. Sorry
<adamgreig[m]>
if you start with u16 then transmuting to u8 to give the hal would always be fine, but if the hal returns an odd-length slice or something I guess you might need to be careful on the way back
<JamesMunns[m]>
It'd be neat if there was an integer-specific safe version of align_to. I wonder if zerocopy has something like that
<M9names[m]>
I don't know if we can answer "does raspberry pi support other transfer sizes" without looking at a datasheet, which means we'd need to know which pi, which hal, etc.
das-Klebeband[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
<ninjasource[m]>
Hi guys, I've got a puzzling problem with a touchscreen driver I wrote when operating over DMA. The following line of deserialization code: x: u16::from_le_bytes([buf[1], buf[2]]), gets compiled to the following Arm instruction on an STM32H7S7L8: ldrhhi.wr3, [r1, #1]. I intended for this to be two separate byte load operations but instead the compiler has generated a half-word load operation. The issue is that if the
ninjasource[m] has joined #rust-embedded
<ninjasource[m]>
address of buf[1] is not correctly aligned the processor crashes. I assume this has something to do with DMA. Fixing the problem involves aligning the buffer to 1 byte before the 4-byte alignment boundary which is a nasty requirement to pass on to users.
<ninjasource[m]>
* Hi guys, I've got a puzzling problem with a touchscreen driver I wrote when operating over DMA. The following line of deserialization code: x: u16::from_le_bytes([buf[1], buf[2]]), gets compiled to the following Arm instruction on an STM32H7S7L8: ldrhhi.wr3, [r1, #1]. I intended for this to be two separate byte load operations but instead the compiler has generated a half-word load operation. The issue is that if the
<ninjasource[m]>
address of buf[1] is not correctly aligned the processor crashes. I assume this has something to do with DMA. Fixing the problem involves aligning the buffer to 1 byte before the 4-byte alignment boundary which is a nasty requirement to pass on to users. Any ideas about how to force two 1-byte loads instead?
<dirbaio[m]>
> if the address of buf[1] is not correctly aligned the processor crashes
<dirbaio[m]>
cortex-m7 supports unaligned accesses. they're slower but they work
<dirbaio[m]>
how do you know it's crashing due to alignment?
<ninjasource[m]>
I don't, someone raised it as an issue and they fixed the problem by messing with the alignment of the buffer passed into the decoder and the problem went away.
<ninjasource[m]>
* went away. So it's an assumption.
<dirbaio[m]>
hmm it might be somehting else then
<dirbaio[m]>
maybe there's UB somewhere and moving the buffer makes it work by chance
SirWoodyHackswel has joined #rust-embedded
<SirWoodyHackswel>
.oO( I hate it when my compiler switches alignment... to Chaotic Neutral )
<ninjasource[m]>
DCACHE is involved too :(
<dirbaio[m]>
is this using embassy?
<ninjasource[m]>
Yes it is
<ninjasource[m]>
And coms over I2C
<dirbaio[m]>
DCACHE support for DMA is an unsolved problem currently :(
<dirbaio[m]>
if you enable dcache you have to either
<dirbaio[m]>
- flush before dma writes, or invalidate after dma reads, and ensure the buffer is aligned to cache line size because you can't flush/invalidate half a cache line
<dirbaio[m]>
- place the buffer in uncached memory
<dirbaio[m]>
the embassy-stm32 hal won't do this for you currently :(
<ninjasource[m]>
Easier to place it in uncached memory rather. I will give that a go.
<dirbaio[m]>
it's especially painful with drivers written on top of embedded-hal because it's the driver who allocates the buffers, and it has no idea the underlying impl has these crazy requirements
<dirbaio[m]>
so I'm not sure what's the best solution
<dirbaio[m]>
maybe make the HAL copy through temp buffers, like nrf52 does for the "can't DMA from flash" bullshit :(
<ninjasource[m]>
I specifically changed my driver to accept an input buffer for that reason
<dirbaio[m]>
yeah...
<dirbaio[m]>
we can't expect every driver to do that tho
<dirbaio[m]>
the bug is within embassy-stm32, technically the embedded-hal impls don't comply with the contract
<dirbaio[m]>
because the embedded-hal contract implies the impl has to be able to accept any buffer. it has no special reqiurements at all
<dirbaio[m]>
* special reqiurements for the buffers at all
<ninjasource[m]>
I see, interesting.
<dirbaio[m]>
i'm surprised this causes a crash instead of just garbage data
<dirbaio[m]>
* garbage data though
<ninjasource[m]>
I've been having an issue with async i2c on an stm32u5 where it works for a bit then begins to return a Timeout error. I haven't quite figured out if it is the same issue but it happens with DCACHE off too.
<ninjasource[m]>
This is a different chip of course so the problems may well be unrelated.