<re_irc> <@oddstr13:matrix.org> How would I go about reading the device ID / address etc?
<re_irc> <@richarddodd:matrix.org> Oddstr13: basically you use [Peripherals::take](https://docs.rs/nrf52840-hal/0.13.0/nrf52840_hal/pac/struct.Peripherals.html#method.take) and then it's at (if p is what's returned) `p.FICR.`..
<re_irc> <@firefrommoonlight:matrix.org> dp.FICR.DEVICEID[n].read().bits()
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> where n is 0 or 1
<re_irc> <@richarddodd:matrix.org> (in firefrommoonlight 's example `let dp = Peripherals::take()`
<re_irc> <@firefrommoonlight:matrix.org> I guess since the 2 indices are 2 halfs of a u64, you'd read both and | them together etc
<re_irc> <@firefrommoonlight:matrix.org> let MSB = dp.FICR.DEVICEID[0].read().bits();
<re_irc> <@firefrommoonlight:matrix.org> let id = MSB as u64 << 32 | LSB as u64
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> let LSB = dp.FICR.DEVICEID[n].read().bits();
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
tokomak has joined #rust-embedded
dcz has joined #rust-embedded
dcz_ has joined #rust-embedded
dcz has quit [Ping timeout: 252 seconds]
gsalazar_ has joined #rust-embedded
gsalazar_ is now known as gsalazar
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
gsalazar_ is now known as gsalazar
fabic has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
starblue has quit [Quit: WeeChat 3.0]
fabic has joined #rust-embedded
tokomak has quit [Read error: Connection reset by peer]
starblue has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
starblue has quit [Quit: WeeChat 3.0]
fabic has joined #rust-embedded
<re_irc> <@newam:matrix.org> Anyone know of an automated way to remove unused dependencies in `Cargo.toml`?
<re_irc> <@newam:matrix.org> Hm, seems the only option is that and `+nightly`, which works :D
<re_irc> <@newam:matrix.org> https://crates.io/crates/cargo-udeps
<re_irc> <@newam:matrix.org> so many unused dependencies after testing every MQTT crate in existance.
<re_irc> <@chrysn:privacytools.io> can that be determined easily at all, given that dependencies might be conditional on platforms etc?
<re_irc> <@newam:matrix.org> cargo udeps did a good job of working around my feature flags.
<re_irc> <@newam:matrix.org> I am guessing it does `--all-targets` and `--all-features` which would be problematic for a lot of embedded crates.
<re_irc> <@chrysn:privacytools.io> cool!
<re_irc> <@richarddodd:matrix.org> Question about embassy: the DMA code uses compiler fences. Do arm chips to out-of-order execution/do we need a full memory barrier?
<re_irc> <@dirbaio:matrix.org> afaik no cortex-m is out of order
<re_irc> <@dirbaio:matrix.org> so I *think* the last write to the dma buffer is guaranteed to be flushed before the write to the DMA peripheral telling it to start DMA
<re_irc> <@dirbaio:matrix.org> ...?
Amanieu has joined #rust-embedded
<re_irc> <@oddstr13:matrix.org> richarddodd firefrommoonlight oh, so that's where it's hiding? thanks!
<re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: Would it be worth adding a memory barrier? If there is no issue on ARM, would it get removed?
<re_irc> <@dirbaio:matrix.org> it might make things slower I think?
<re_irc> <@dirbaio:matrix.org> like, a full memory barrier waits until earlier writes are fully stored in the destination (not in store buffers)
<re_irc> <@dirbaio:matrix.org> and that's "stronger" than needed
<re_irc> <@dirbaio:matrix.org> like, it's OK for data writes and the reg write to be in filght simultaneously in store buffers
starblue has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> hm
<re_irc> <@dirbaio:matrix.org> you just need the guarantee that the data writes get flushed before the reg write
<re_irc> <@adamgreig:matrix.org> don't think that's right on m7 or with dcache?
<re_irc> <@adamgreig:matrix.org> I guess by the time the DMA register write is flushed out the store cache the preceding write to memory will be
<re_irc> <@richarddodd:matrix.org> This stuff is soo fiddly
<re_irc> <@adamgreig:matrix.org> so yea, nothing a memory barrier can help, just the cache control
<re_irc> <@dirbaio:matrix.org> yeah it's super scary
<re_irc> <@dirbaio:matrix.org> uh so with dcache the core writes through the dcache and dma reads NOT through the dcache?
<re_irc> <@adamgreig:matrix.org> yes
<re_irc> <@dirbaio:matrix.org> heh
<karlp> from other places, there's been a bunch of places where dsb's were required for m7...
<karlp> never been needed on m0(+)/m3
<re_irc> <@dirbaio:matrix.org> isn't dcache optional and rare?
<re_irc> <@adamgreig:matrix.org> it's on all the stm32f7 and stm32h7 for example
<re_irc> <@adamgreig:matrix.org> yea, karlp has reminded me of a bug i found in chibios back in 2017 where DSB is required for the ethernet DMA to work, https://sourceforge.net/p/chibios/bugs/815/
<re_irc> <@dirbaio:matrix.org> uuuuuh
<re_irc> <@dirbaio:matrix.org> I guess this needs some auditing in embassy then :)
<re_irc> <@dirbaio:matrix.org> does DSB flush the dcache?
<re_irc> <@adamgreig:matrix.org> no
<re_irc> <@adamgreig:matrix.org> that patch only helps with dcache disabled
<re_irc> <@adamgreig:matrix.org> with dcache enabled you need to do explicit cache management around DMA operations
<re_irc> <@adamgreig:matrix.org> and it's pointless
<re_irc> <@adamgreig:matrix.org> just disable dcache for regions where dma buffers are
<re_irc> <@adamgreig:matrix.org> (by explicit cache management I mean like the https://docs.rs/cortex-m/0.7.3/cortex_m/peripheral/struct.SCB.html#method.invalidate_dcache_by_slice
<re_irc> <@dirbaio:matrix.org> haha
<re_irc> <@dirbaio:matrix.org> when not using embedded-dma, dma buffers can be anywhere :P
<re_irc> <@dirbaio:matrix.org> embassy has impls for e-h traits that take a `&[u8]` then DMAs it
<re_irc> <@adamgreig:matrix.org> sure, they can be, but it's pointless to put them somewhere they get cached, only reduces performance unless you're doing very infrequent dma operations and then lots of cpu access to that same buffer
<re_irc> <@dirbaio:matrix.org> hal-independent drivers that just use the traits have no idea that DMA is being used
<re_irc> <@adamgreig:matrix.org> well, if you're definitely DMAing it and you don't know if the dcache is enabled for that memory, I guess you need to clean and/or invalidate around DMA ops
<re_irc> <@adamgreig:matrix.org> but it's a bunch of faffy overhead since it's done in a loop over each cache line
<re_irc> <@dirbaio:matrix.org> it's O(n)? oh no
<re_irc> <@adamgreig:matrix.org> uh, it's a bit trickier too, this is for the ethernet dma which is different in ways I don't remember right now to the MDMA/BDMA/etc etc
<re_irc> <@dirbaio:matrix.org> goddamnit :D
<re_irc> <@dirbaio:matrix.org> well at least for ETH the HAL driver does own the buffers
<re_irc> <@adamgreig:matrix.org> iirc you have to do the same dcache management for the normal DMA engines as well as eth dma though
<re_irc> <@adamgreig:matrix.org> basically if people enable dcache they should be careful about what goes in it
<re_irc> <@dirbaio:matrix.org> but for generic spi/i2c/uart DMA this is a problem if it needs dcache flushing :S
<re_irc> <@dirbaio:matrix.org> dcache is off by default? maybe that's why no problem has manifested?
<re_irc> <@adamgreig:matrix.org> yes, it's off by default
<re_irc> <@dirbaio:matrix.org> lol
<re_irc> <@adamgreig:matrix.org> and then you enable it globally, and if you want more fine-grained control, you set up the MPU to disable it per-region
<re_irc> <@adamgreig:matrix.org> where regions can be variable size and e.g. it's very common on stm32f7 to disable dcache on SRAM2 and SRAM3, use those for DMA buffers since then CPU access to SRAM1 won't contend the bus with DMA
<re_irc> <@adamgreig:matrix.org> and leave dcache enabled on SRAM1 and don't put DMA buffers there
<re_irc> <@adamgreig:matrix.org> kinda tricky to work out if a slice you're given is in a cached region or not though... but I guess it's not impossible
<re_irc> <@adamgreig:matrix.org> bit of a performance footgun though
<re_irc> <@dirbaio:matrix.org> yeah.. tricky!
<re_irc> <@adamgreig:matrix.org> it's a pain
<re_irc> <@adamgreig:matrix.org> maybe just try and get the right DSBs/DMBs in
<re_irc> <@adamgreig:matrix.org> at least then it works on cm7 with dcache off, and just leave a doc note that users are on their own if they enable dcache, lol
<re_irc> <@dirbaio:matrix.org> lol
<re_irc> <@adamgreig:matrix.org> the dsbs really are required for e.g. f7/h7 ethernet though
<re_irc> <@richarddodd:matrix.org> I think it's ok to say something like "if you use dcache, it's on you to make sure it can't contend with DMA" or even "if you use dcache with memory you also use for DMA, that's UB"
<karlp> even just thigns like turning on peripherals can need either dsb or nops to allow writes to propagate.
<karlp> it's kinda niche to hit it, but...
<re_irc> <@dirbaio:matrix.org> seems like fences on ETH are in
<re_irc> <@dirbaio:matrix.org> DMB instead of DSB thoguh..? is that an issue?
<re_irc> <@adamgreig:matrix.org> don't remember, feels like dmb should be enough
<re_irc> <@richarddodd:matrix.org> the one on SPI is a `compiler_fence` I think https://github.com/embassy-rs/embassy/blob/master/embassy-nrf/src/spim.rs#L246
<re_irc> <@richarddodd:matrix.org> The thing about embassy is you only have to get it right once, then it works for everyone.
<re_irc> <@dirbaio:matrix.org> I don't think nrf needs DMB/DSB?
<re_irc> <@dirbaio:matrix.org> it's an M4
<re_irc> <@richarddodd:matrix.org> OK cool
<re_irc> <@dirbaio:matrix.org> if it needs them then nrf-hal is also wrong lol
<re_irc> <@thalesfragoso:matrix.org> dirbaio:matrix.org: Writes to normal memory can be re-ordered/omitted on the store buffer (M7)
<re_irc> <@thalesfragoso:matrix.org> And I think it can be re-ordered even w.r.t writes to device memory
<karlp> richarddodd: you mean, "you only hve to get it right for everyone, and pay the price for everyone" ;)
<re_irc> <@thalesfragoso:matrix.org> Although writes to device memory will flush the store buffer, I didn't see anywhere saying that it couldn't be re-ordered just before the flush
<re_irc> <@thalesfragoso:matrix.org> So I use a DMB on DMA on embassy
<re_irc> <@adamgreig:matrix.org> richarddodd:matrix.org: this is the same as for any of the HALs or drivers in general really though, is embassy different?
<re_irc> <@dirbaio:matrix.org> once for all stm32s, at least 😜
<re_irc> <@thalesfragoso:matrix.org> The thing with the ethernet on the H7/F7 was that some of the "registers" for the DMA were in RAM, i.e. the descriptors
<re_irc> <@thalesfragoso:matrix.org> So you need to mark the descriptor as ready in the RAM before writing to the real registers for the DMA to poll the descriptors
<re_irc> <@thalesfragoso:matrix.org> Without dmb the write to the descriptor could be re-ordered to after the write to the dma register
<re_irc> <@thalesfragoso:matrix.org> Which would stall the DMA because it would see a non-ready descriptor
<re_irc> <@thalesfragoso:matrix.org> Which is way easier to noticed than if you write a bit to your buffer just before enable normal DMA (not ethernet)
<re_irc> <@thalesfragoso:matrix.org> I.e. even with normal DMA I think we need a DMB to ensure that all writes to the buffer are done before we enable the DMA
starblue has quit [Quit: WeeChat 3.0]
<re_irc> <@thalesfragoso:matrix.org> But it's hard to notice the problem because the write to the DMA register will probably cause a flush on the store buffer, so the write will probably happen before the DMA gets to the end of the buffer
<re_irc> <@richarddodd:matrix.org> adamgreig: Yes it is
<re_irc> <@thalesfragoso:matrix.org> And my opinion about the d-cache is to just document it, too much trouble to check it for everyone
<re_irc> <@adamgreig:matrix.org> "for power users only" :P
<re_irc> <@adamgreig:matrix.org> honestly just putting dma buffers in sram2 while stacks are in dtcm or sram1 probably gets you most of the benefit already
<re_irc> <@dirbaio:matrix.org> dcache enable bit is the "run fast and break things bit"
<re_irc> <@thalesfragoso:matrix.org> Btw, dirbaio what RAM were you using in the ethernet example ? Forgot to ask about that...
<re_irc> <@dirbaio:matrix.org> no idea, it's the example you wrote
<re_irc> <@dirbaio:matrix.org> I just fixed chip, pinout and phy addr
<re_irc> <@thalesfragoso:matrix.org> Hmm, I probably add a memory.x, not sure if it got removed with that feature to generate onr
fabic has quit [Ping timeout: 252 seconds]
dcz_ has quit [Ping timeout: 252 seconds]
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
<re_irc> <@firefrommoonlight:matrix.org> Noob audio / sampling question: Lets say you want to sample at a specific frequency (as alwaysish?), like 48Khz. Do you trigger the read this with a timer, or, with your audio peripheral set up correctly, using its FIFO-is-fiilled-to-appropriate-level interrupt?
<re_irc> <@firefrommoonlight:matrix.org> [This example from H7xxh-hal](https://github.com/stm32-rs/stm32h7xx-hal/blob/master/examples/sai-i2s-passthru.rs) and 2 others in its repo are the only I can find, and it uses the SAI FIFO interrupt. I'm wondering if this would drift over time if the SAI clock isn't exactly your sample freq etc
<re_irc> <@firefrommoonlight:matrix.org> I guess part of the reason the H7 has (optionally) fractional PLL config is letting you set very precise freqs, but that may be unrelated
<re_irc> <@firefrommoonlight:matrix.org> Or if the data signal gets interrupted etc, your sample freq wouldn't be true