cr1901 has quit [Read error: Connection reset by peer]
cr1901_ is now known as cr1901
<re_irc>
<firefrommoonlight> Has anyone done SPI DMA reads before? Running into a struggle over what sequence to command the reads, writes, CS high/low etc
<re_irc>
<firefrommoonlight> Complicated by the fact I'm transferring data from multiple registers
<re_irc>
<firefrommoonlight> Current approach:
<re_irc>
- Command DMA write with the 12 (byte-long) regs to read from as the buffer.
<re_irc>
- CS low
<re_irc>
- On Rx Xfer complete, set CS high, and process the data
<re_irc>
- On Tx Xfer complete, command DMA read, with the 12-byte buffer I want the data to go to
cr1901 has quit [Quit: Leaving]
<re_irc>
<firefrommoonlight> Currently getting some, but not all data. Have reviewed the RM on SPI DMA, and am still confused. It also includes a lot of info on disabling the DMA and SPI etc at various points, but again... pretty confused about how this works
<re_irc>
<dirbaio> you have to start dma rx+tx at the same time
cr1901 has joined #rust-embedded
<re_irc>
<firefrommoonlight> Oh...
<re_irc>
<dirbaio> you want to do what embedded-hal calls an spi "transfer" right?
<re_irc>
<dirbaio> rx+tx 12 bytes at the same time
<re_irc>
<dirbaio> not tx 12 bytes, then rx 12 bytes?
<re_irc>
<firefrommoonlight> I will try that
<re_irc>
<firefrommoonlight> It's just a read. The Tx is just part of it
<re_irc>
<dirbaio> also there's a trap
<re_irc>
<firefrommoonlight> (That was one bit I did get cleanly from the RM; you need both transfers to read)
<re_irc>
<dirbaio> you have to
<re_irc>
- start RX, TX DMAs
<re_irc>
- set TXDMAEN=1
<re_irc>
- set SPE=1
<re_irc>
- set RXDMAEN=1
<re_irc>
<dirbaio> if you don't do it in that exact order, it doesn't work 🤷🤣
<re_irc>
<firefrommoonlight> Well... You already partly solved it
<re_irc>
<firefrommoonlight> Getting what looks like good data (It fills the buf) by getting rid of the TC ISR, and doing read/write together. It's only triggering one though, not each time, so I'll try switching the order around
<re_irc>
<firefrommoonlight> My API is _not_ set up for that, since I have separate "read_dma", and "write_dma" fns
<re_irc>
<dirbaio> which chip?
<re_irc>
<firefrommoonlight> I think I need to modify the "read_dma" to do both commands, do do the things in the order you specified
<re_irc>
<firefrommoonlight> G4
<re_irc>
<firefrommoonlight> *You probably fully solved it, but I haven't done the reordering yet
<re_irc>
<firefrommoonlight> STM32G4
<re_irc>
<dirbaio> well this thing would be "transfer_dma"
<re_irc>
<dirbaio> which is "read and write concurrently"
<re_irc>
<firefrommoonlight> Yea, good point. The non-DMA API is more like that
<re_irc>
<dirbaio> you might also want to only read
<re_irc>
<firefrommoonlight> I'll cross-ref the embassy link
<re_irc>
<firefrommoonlight> Well, this is _only reading_ in this case, right?
<re_irc>
<firefrommoonlight> You just have to _write_ the addresses you're reading from
<re_irc>
<dirbaio> from the high-level "register access" point of view you're reading
<re_irc>
<dirbaio> from the low-level "spi" point of view you're writing+reading
<re_irc>
<dirbaio> to me an "spi read" is _only_ reading, like, no data on MOSI at all
<re_irc>
<firefrommoonlight> Good point. Are there practical uses for that?
<re_irc>
<dirbaio> maybe if you're reading something big, like a 1500 byte network packet
<re_irc>
<dirbaio> you can write 1 byte for "gimme the packet", then read 1500 bytes
<re_irc>
<dirbaio> vs with "transfer" you'd need a 1501-byte tx buffer and a 1501-byte rx buffer
<re_irc>
<firefrommoonlight> Oh good point
<re_irc>
<firefrommoonlight> This might actually apply here... ie I might be able to write 1 reg byte, and have it auto-incr
<re_irc>
<firefrommoonlight> Since the regs are sequential
<re_irc>
<firefrommoonlight> Ok, going to make a new "transfer_dma" method instead, as you imply
<re_irc>
<firefrommoonlight> Instead of replacing "read_dma"
<re_irc>
<firefrommoonlight> like your "transfer_inner"
ymwm has quit [Ping timeout: 250 seconds]
<re_irc>
<firefrommoonlight> I'm also going to throw these in the TC ISR:
<re_irc>
Disable DMA streams for Tx and Rx in the DMA registers, if the streams are used.
<re_irc>
> To close communication it is mandatory to follow these steps in order:
<re_irc>
<firefrommoonlight> *Might make a helper fn in the API; not sure yet
<re_irc>
<firefrommoonlight> *Nvm, have a helper, just forgot about it
ymwm has joined #rust-embedded
<re_irc>
<firefrommoonlight> Completedly fixed - thank you very much!
nort has joined #rust-embedded
nort has quit [Changing host]
ymwm_ has joined #rust-embedded
ymwm has quit [Read error: Connection reset by peer]
ymwm_ has quit [Remote host closed the connection]
<re_irc>
<eldruin> PSA: "embedded-hal" "v1.0.0-alpha.8" is out, including a complete rework of the SPI traits. Please have a try at adapting your HALs (See PR #351 (https://github.com/rust-embedded/embedded-hal/pull/351) for motivation/guidance) and let us know if you run into problems.
<re_irc>
- when I compute a hash of large file (like 30MB) on a raspberry pi 4, it takes way too long. (i.e. I'm expecting a 30MB file to be hashed in 3 seconds but it takes about 36-40 seconds)
<re_irc>
- my bare-metal bootloader's results are way off when compared with "OpenSSL and the sha2 crate" running a standard linux OS on a raspberry pi 4 i.e. the hashing-speed for openssl is 121 MiB/s and sha2 is 82 MiB/s, which roughly translates to less than 3 seconds for a 30MB file.
<re_irc>
- My suspicion is its some kind of hardware misconfiguration issue but I cant seem to figure it out.
<re_irc>
I'm hoping folks here who have more experience with a "rpi" can offer some insight into what's probably missing/wrong.
<re_irc>
- when I compute the hash of a large file (like 30MB) on a raspberry pi 4, it takes way too long. (i.e. I'm expecting a 30MB file to be hashed in 3 seconds but it takes about 36-40 seconds)
<re_irc>
- my bare-metal bootloader's results are way off when compared with "OpenSSL and the sha2 crate" running on a standard linux OS + raspberry pi 4 i.e. the hashing-speed for openssl is 121 MiB/s and sha2 is 82 MiB/s, which roughly translates to less than 3 seconds for a 30MB file.
<re_irc>
- My suspicion is its some kind of hardware misconfiguration issue but I cant seem to figure it out.
<re_irc>
I'm hoping folks here who have more experience with a "rpi" can offer some insight into what's probably missing/wrong.
<Lumpio->
I wonder what the best way of implementing millis() would be on Cortex-M, I'm thinking of using SysTick set to maximum reload value and incrementing a counter in an interrupt handler
<Lumpio->
But how would I read both the counter and the atomic correctly
<Lumpio->
Read in a busy loop checking that I have the ticks decreasing and the overflow counter stay the same?
<re_irc>
<9names (@9names:matrix.org)> you don't have to do the loop method, you can do
<re_irc>
return (hi_second, 0)
<re_irc>
if hi_first != hi_second {
<re_irc>
since anytime where you overflow the upper 32bits the lower 32bits are going to be very close to zero
<re_irc>
}
<re_irc>
<9names (@9names:matrix.org)> unless... you interrupt or sleep for a long time, i guess. well, there are always exceptions :S i don't really deal with long sleep times very often
<Lumpio->
That Monotonic style thing might be hard to adapt to something using SysTick and not RTIC
<Lumpio->
AFAIK you can't even read the overflow flag without clearing it
<Lumpio->
fwiw I don't even have other interrupts besides the SysTick one so long sleeping interrupts aren't going to be a thing, but I was just wondering if this is a generally working solution
creich has joined #rust-embedded
creich has quit [Remote host closed the connection]
<re_irc>
<adamgreig> Have systick interrupt every 1ms to increment a shared u64 inside a critical section
<re_irc>
<adamgreig> Then no systick overflow to worry about and can't have a torn read
creich has joined #rust-embedded
<re_irc>
<adamgreig> (ie you never read systick counter, just the u64)
<Lumpio->
That would be the safest way yes
<Lumpio->
But so many interrupts!
<re_irc>
<9names (@9names:matrix.org)> oof critical section, i'd rather do three reads than disable all interrupts for this
<re_irc>
<adamgreig> It's gonna be a real short CS to write one u64
<re_irc>
<adamgreig> Could also just make systick interrupt higher priority than anything that reads it I guess
<Lumpio->
Yes I don't think really tiny critical sections like that should be a problem for most applications
<re_irc>
<adamgreig> Or sure, two u32 and all readers do 3 reads works too
<re_irc>
<adamgreig> Hm
<Lumpio->
This is surprisingly intricate heh
<Lumpio->
I wish we could just have a u64 hardware timer
<re_irc>
<adamgreig> Yea, I guess readers would also need a critical section with a single u64 so probably two u32 is better
<re_irc>
<9names (@9names:matrix.org)> probably still need the CS on overflow though :/
creich has quit [Client Quit]
creich has joined #rust-embedded
creich has quit [Remote host closed the connection]
<Lumpio->
tbh the busy loop will loop *very* rarely so I'm not worried about having to loop, and a few reads are cheap
<Lumpio->
...but can it return an incorrect result?
<re_irc>
<9names (@9names:matrix.org)> Lumpio-: one of the things I think riscv got right: you always have a 64bit cycle counter per HART
creich has joined #rust-embedded
<Darius>
I thought 99% of modernish ARM cores had a counter in the debug section you could do
<Lumpio->
But is it 64 bit
<Darius>
ah hmm, might not be..
<Darius>
rollover time is pretty long though
<Lumpio->
Is there a rollover interrupt though
<Lumpio->
Plus 32 bits rolls over pretty fast if you're going at say 100MHz
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<Darius>
every 42 seconds seem pretty infrequent to me..
ymwm has joined #rust-embedded
<re_irc>
<halfbit> that's quite frequent if you want to sit idle on a battery for a very long time
<re_irc>
<dirbaio> if you want low-power you wouldn't use a Mhz-range clock, you'd use 32khz for example, as just having it running uses quite a bit of power
<re_irc>
<dirbaio> * a mhz clockrunning
<re_irc>
<dirbaio> * clock running
<re_irc>
<halfbit> that's true
ymwm has quit [Ping timeout: 250 seconds]
ymwm has joined #rust-embedded
ymwm has quit [Ping timeout: 250 seconds]
<re_irc>
<newam> Is there no way to mark a doctest as "should_panic" for "const" panic?
<re_irc>
<riskable> What's the practical difference between doing something like "SOME_NUMBER.try_into().unwrap()" and "SOME_NUMBER as usize"?
<re_irc>
<newam> "as" (in that context) will truncate. "try_into" will check and make sure that "SOME_NUMBER" can fit into "usize". If "usize" and "SOME_NUMBER" are the same size then it doesn't matter
<re_irc>
<newam> *then it doesn't matter if you don't care about writing portable code that is
<re_irc>
<riskable> Is one faster/more efficient than the other in any way? Like, will I save a byte in my firmware if I use "as"?
<re_irc>
<newam> if they are the same size then the compiler should optimize away the "unwrap" and they both become zero cost
<re_irc>
<newam> if they are not the same size then "as" will be faster & more space efficient