<therealprof[m]>
<Ralph[m]> "this is probably of interest..." <- > <@rursprung:matrix.org> this is probably of interest to a lot of embedded developers? i came across it by pure chance. maybe some of you want to join?
<therealprof[m]>
Some years ago I'd been very interested (and tried to push things a bit when it was on no-ones radar really), now I just don't have the time to. :(
<therealprof[m]>
* Some years ago I'd been very interested (and tried to push things a bit when it was on no-ones radar really), now I just don't have the time to. 😞
<dngrsspookyvisio>
<AdamHott[m]> "I wanted to try STM32 because of..." <- You can also use an Espressif board as a wifi "coprocessor" in an STM32 project
<dngrsspookyvisio>
But that definitely makes things more complicated
crabbedhaloablut has joined #rust-embedded
Farooq has joined #rust-embedded
<Farooq>
If you want to use ESP, why not make the ESP the main processor?
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
emmanuelsearch[m has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
<dngrsspookyvisio>
If you need more oomph
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
AdamHott[m] has quit [Quit: Bridge terminating on SIGTERM]
MarkSzente[m] has quit [Quit: Bridge terminating on SIGTERM]
StephenD[m] has quit [Quit: Bridge terminating on SIGTERM]
jessebraham[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
therealprof[m] has quit [Quit: Bridge terminating on SIGTERM]
lulf[m] has quit [Quit: Bridge terminating on SIGTERM]
K900 has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
vollbrecht[m] has quit [Quit: Bridge terminating on SIGTERM]
marmrt[m] has quit [Quit: Bridge terminating on SIGTERM]
spinfast[m] has quit [Quit: Bridge terminating on SIGTERM]
danielb[m] has quit [Quit: Bridge terminating on SIGTERM]
Lumpio[m] has quit [Quit: Bridge terminating on SIGTERM]
hampycalc[m] has quit [Quit: Bridge terminating on SIGTERM]
FlixtheNewbie[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
IsaBang[m] has quit [Quit: Bridge terminating on SIGTERM]
chxry[m] has quit [Quit: Bridge terminating on SIGTERM]
sourcebox[m] has quit [Quit: Bridge terminating on SIGTERM]
Farooq has quit [Quit: Bridge terminating on SIGTERM]
JarrodHamilton[m has quit [Quit: Bridge terminating on SIGTERM]
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
mabez[m] has quit [Quit: Bridge terminating on SIGTERM]
jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
newam[m] has quit [Quit: Bridge terminating on SIGTERM]
dngrsspookyvisio has quit [Quit: Bridge terminating on SIGTERM]
Ralph[m] has quit [Quit: Bridge terminating on SIGTERM]
elpiel[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
if you've already written the entire firmware for another mcu, and you're doing a new product variant with wifi and don't want to port
<sourcebox[m]>
In my current test scenario, using D-Cache makes not really a difference in terms of performance. So maybe it's not worth the hassle of doing the cache maintainance.
Guest7282 has left #rust-embedded [Error from remote client]
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
<sourcebox[m]> "In my current test scenario..." <- We use the I-Cache for stabilizer and it only impacted us for the initial first loop of execution. After that, the cache does a really good job of making things "just work faster" because of the algorithms they use for automated cache maintenance
<ryan-summers[m]>
The only time you need to worry about that is i.e. you have real-time performance requirements that require it to be in cache. In our case, we ended up putting the respective functions into the ITCM to avoid cache and reduce execution cycles anyways
<sourcebox[m]>
Yes, with I-Cache you can address the slow flash speed.
<ryan-summers[m]>
Sorry, coming from reading a single message, so if the context is totally gone, my bad
<ryan-summers[m]>
My main point is that the cache automatically does a pretty good job on figuring out what needs to be cached
<ryan-summers[m]>
But yeah, the value can be limited
<sourcebox[m]>
I was wondering if D-Cache can improve things, but that will probably only happen if you use slower RAM sections (e.g. for DMA). But then you have to clean/invalidate the cache every time you read or write from/to DMA.
<ryan-summers[m]>
D-cache would only really make a difference if you're doing a lot of data storage and rmw of lots of memory. However, by definition this usually isn't the case for embedded because of the limited RAM anyways
<ryan-summers[m]>
Most of our RAM requirements go to the stack, which isn't really cacheable
<ryan-summers[m]>
But it could be useful for i.e. if you had a stack and a huge RAM section dedicated to something like an MP4 stream
<sourcebox[m]>
The cache issue is more relevant for Cortex-A when dealing with DDR.