<M9names[m]>
are we reading the same post? "We are currently targeting Rust 1.74 for stabilization" sounds more like an aspirational goal than a delivery plan
<sourcebox[m]>
You're right in the sense that it's not really a plan, but I think if someone does this kind of post in this blog, then there's a good chance that it will be realized.
<sourcebox[m]>
To me it reads like: "We're trying to do it, but we can't promise"
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
s7rul[m] has quit [Quit: Idle timeout reached: 172800s]
SeanLyons[m] has quit [Quit: Idle timeout reached: 172800s]
yruama_lairba[m] has joined #rust-embedded
<yruama_lairba[m]>
Hi, is there a documentation somewhere about controlling memory cache from rust point of view ? is it chip speficific ? In particular id like to know how to disable cache for a pariticular variable or piece of memory
<yruama_lairba[m]>
*it's just for general information
<JamesMunns[m]>
Yeah, it's pretty chip specific
<JamesMunns[m]>
Especially on microcontrollers, not sure what kind of device (MCU, CPU) you are talking about.
<yruama_lairba[m]>
for the moment i only practiced embedded rust on stm32 MCU.
<JamesMunns[m]>
Then yeah, definitely check out the reference manual for the specific chip you are using, you'll likely need to explicitly set up instruction or data cache in the first place if your chip has it. The chip will then have some specific way of configuring, enable/disabling, or clearing certain lines (in addition to isb/dsb instructions)
<yruama_lairba[m]>
refernces manual of what ?
<JamesMunns[m]>
For the chip you are using
<JamesMunns[m]>
what chip are you using?
<K900>
What do you even mean by "memory cache"
<yruama_lairba[m]>
lol, none for the moment
<K900>
Do you mean CPU cache?
<K900>
You shouldn't ever have to disable that
<K900>
Unless there's a hardware bug
<JamesMunns[m]>
yruama_lairba[m]: Then yeah, I'm very confused at what you are trying to do!
<JamesMunns[m]>
I'd probably agree fully disabling it is decently rare, sometimes you don't set it up at all if you don't need the perf, and sometimes you need to explicitly clear or reset it in some way (like if you are mapping in external qspi flash or something).
<yruama_lairba[m]>
I'm just trying to get information about that, but i should asked this question only with a concrete need
<K900>
About what?
<K900>
CPU caches?
<yruama_lairba[m]>
K900 ⚡️: yes, some MCU have CPU like cache
<K900>
This is an implementation detail you should never have to worry about
<K900>
The cache should not affect the behavior of your program in any way
<JamesMunns[m]>
K900 ⚡️ I think you're being a little sharp/aggressive for someone who is interested in learning in a topic
<K900>
And if it does, you've found a hardware bug
<JamesMunns[m]>
K900: And I SUPER disagree with this in the general case, at least from a performance/latency/etc. perspective
<K900>
Well yes, I'm using "behavior" here to mean "observable side effects"
<K900>
It definitely affects performance
<K900>
But it should not affect what your program does
<JamesMunns[m]>
Yeah! So there's typically two kinds of cache RAM:
<JamesMunns[m]>
* Instruction Cache, for storing CPU instructions
<JamesMunns[m]>
* Data Cache, for storing data
<JamesMunns[m]>
For instruction cache, it's usually used to compensate that loading from flash memory is slower than the CPU's clock rate, or might work faster in "bursts" rather than random seeking like a jump instruction might cause
<JamesMunns[m]>
For data cache, it's usually used when you have external memory, like QSPI or external DRAM, that again is not as fast as the internal SRAM.
<yruama_lairba[m]>
there is also DMA to consider with cache
<JamesMunns[m]>
K900: Perf and latency are definitely observable side effects. You don't *usually* need to ever think about them, but learning how they work is a reasonable thing to ask (but I totally agree, it's usually when something is weird, or you are noticing nomdeterministc behavior because it SOMETIMES is fast enough but not always).
<JamesMunns[m]>
yruama_lairba[m]: yup! there's a lot of concepts to learn here, though it's *usually* less relevant on MCUs than desktop CPUs
<JamesMunns[m]>
most CPUs (except for fairly high end ones) only typically mess with instruction cache, to help with internal or external flash performance
<JamesMunns[m]>
s/ most/_most_/, s/CPUs/MCUs/
xiretza[cis] has joined #rust-embedded
<xiretza[cis]>
JamesMunns[m]: ehhh I disagree except for old or very low-spec modern MCUs
<JamesMunns[m]>
But there are totally high end stm32s like the H7 that have some internal SRAM regions with different perf
<K900>
DMA is usually cache coherent on modern stuff
<JamesMunns[m]>
xiretza[cis]: Is dcache typically common below say a Cortex-M7?
<JamesMunns[m]>
not saying it isn't, but I've typically only seen dcache on M7 and above where you're likely to have QSPI or other external SRAM or DRAM
<xiretza[cis]>
JamesMunns[m]: not sure, but M7 is pretty common nowadays I'd say
<JamesMunns[m]>
But I also know stm32 has stuff like ccram and other regions that I think have different perf numbers? where some SRAM has wait states like flash would?
<JamesMunns[m]>
xiretza[cis]: that's fair! I tend to do a lot of smaller stuff, I'd definitely expect H7s or stuff like imxrt chips to have dcache too
<JamesMunns[m]>
but I also see a lot of people working mostly on M0+/M3/M4 chips too :D
<JamesMunns[m]>
(so many M0+ chips)
<FreeKill[m]>
Fyi the cache on stm chips also has massive consequences. It's a transparent cache to the CPU but *not* to peripherals
<FreeKill[m]>
In the general case you cannot turn on the main cache and expect everything to work the same
<FreeKill[m]>
<K900> "DMA is usually cache coherent on..." <- This, for example, is not true
<FreeKill[m]>
On STM32
<FreeKill[m]>
s/main/dcache/, s/cache//
dalepsmith[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
Plus even the cortex-m caches (like th cm7 store buffer) can cause all sorts of subtle problems in various edge cases, like writing a 32 bit flag and then resetting the CPU but the store buffer didn't get flushed so the flag was never updated
<adamgreig[m]>
Definitely using the dcache on stm32 requires very careful thought and attention and cache management and probably setting up the mpu to disable caching some regions and so forth
<dngrsspookyvisio>
just checked because I was curious - STM32F4x1 (CM4) has icache and dcache
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
I don't think that's quite right technically speaking, it has some ccm and it has the ST ART but it doesn't have what Arm called icache or dcache as those are cm7 and up only
<adamgreig[m]>
(the ART is ST's flash cache that caches flash reads over both the i- and d-bus, but it's just for values read from flash to help mitigate the wait cycles needed at high CPU speeds)
<dngrsspookyvisio>
not confusing at all
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
<dngrsspookyvisio>
(blaming ST here, not you!)
<xiretza[cis]>
<adamgreig[m]> "Plus even the cortex-m caches (..." <- oh yeah, been there debugged that
crabbedhaloablut has quit []
Darius has quit [Ping timeout: 240 seconds]
Darius has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Guest7221 has left #rust-embedded [Error from remote client]