ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
whitequark[cis] has joined #rust-embedded
<whitequark[cis]> I have a simplified SD host controller spec dating 2018
<dngrsspookyvisio> hmmm
<dngrsspookyvisio> so essentially one could just write a fast driver based on the Linux sources?
<dngrsspookyvisio> (I suppose that would gpl-infect it)
kenny has quit [Quit: WeeChat 4.1.2]
kenny has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 246 seconds]
notgull has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<Ralph[m]> 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]> <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. 😞
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
<AdamHott[m]> Would this be a good board to build a complex robot with, that has quite a few sensors, servos, motors, etc? https://www.digikey.pt/en/products/detail/arduino/ABX00042/11657626
<K900> > Arduino
<K900> Probably OK if you have enough I/O, but likely overpriced
<K900> > $99.90
<K900> wew
<danielb[m]> > Suggested programming environment: ... Javascript ...
<K900> I'm pretty sure ST's own H7 evaluation board is like $69.90
<AdamHott[m]> I was looking for SMT32's that had Wifi and a good amount of connectors
<AdamHott[m]> Any recommendations?
<K900> And specifically STM32?
<AdamHott[m]> It would be a big help
<AdamHott[m]> I wanted to try STM32 because of the embedded group here's focus on that chipset
<K900> I'd probably look at ESP32 stuff if you want wi-fi
<K900> Or Pico W
<AdamHott[m]> ok cool, and the Rust embedded hals and pacs, etc (Sorry I'm still green) work with those boards?
<K900> Or some "real computer" class Linux board
<K900> There are embedded-hal implementations for both esp32 and rp2040, but esp32 also has its own weird RTOS thing that you can use
<AdamHott[m]> Do you by chance have a link to that weird RTOS thing?
<danielb[m]> what's weird about freertos?
<danielb[m]> AdamHott[m]: look for esp-idf-svc
<K900> danielb[m]: The fact that espressif rewrote like two thirds of it
<K900> Mostly
<AdamHott[m]> Looks like this one would be supported by Rust embedded-hal? https://mauser.pt/catalog/product_info.php?products_id=095-0597
<K900> Yes
<AdamHott[m]> Ok cool, the low cost is appealing
<AdamHott[m]> Thanks K900
<Lumpio-> rp2040 is a pretty neat chip
<Lumpio-> Is the pico's wifi module supported by Rust yet?
crabbedhaloablut has quit []
<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] has joined #rust-embedded
<sourcebox[m]> I would like to check if I can use D-Cache on the Cortex-M7. What do I use for the CPUID argument? https://docs.rs/cortex-m/latest/cortex_m/peripheral/struct.SCB.html#method.enable_dcache
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]> You should receive a https://docs.rs/cortex-m/latest/cortex_m/peripheral/struct.CPUID.html when you get the core peripherals
<JamesMunns[m]> From https://docs.rs/cortex-m/latest/cortex_m/peripheral/struct.Peripherals.html#method.take, tho embassy or rtic may take this automatically already
<sourcebox[m]> Ah ok. Will have a look later.
<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.
kenny has quit [Quit: WeeChat 4.1.2]
Guest7282 has joined #rust-embedded
WSalmon has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
WSalmon has joined #rust-embedded
jsolano has quit [Remote host closed the connection]
jsolano has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
kenny has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
crabbedhaloablut has quit []