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
sroemer has quit [Ping timeout: 272 seconds]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
jistr_ has quit [Ping timeout: 244 seconds]
jistr has joined #rust-embedded
Noah[m] has joined #rust-embedded
<Noah[m]> I probably should have paid attention on the last few meetings but is there any plans to update embedded-hal in cortex-m?
_whitelogger has joined #rust-embedded
<DavidBrown[m]> Yes, but then the API becomes pretty much unusable.
<DavidBrown[m]> The goal is to keep it safe, but also make the interface usable.
crabbedhaloablut has quit [Quit: bye]
crabbedhaloablut has joined #rust-embedded
pcs38 has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> Just wanted to ping https://github.com/rust-embedded/wg/pull/818 again. I think there’s consensus but we’re stuck on procedure.
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok> What's a good way to prevent the M4 core from running when using a dual core bootloader running from M7 ?
<AlexandrosLiarok> (stm32h745)
<AlexandrosLiarok> Because the m7 core will be overwriting the m4 flash region.
<thejpster[m]> That should be explained in the chips data sheet
<AlexandrosLiarok> I guess I can keep the M4 option byte to off and enable on bootloader jump.
<AlexandrosLiarok> * and enable the SYSCFG boot bit on bootloader
<RobinMueller[m]> Hey, does anyone know an elegant way to initialize very large arrays? I have to define a L1 table with 4096 u32 entries, but all the values are known at compile time. This was solved with assembler... (full message at <https://catircservices.org/_irc/v1/media/download/AU976XQteaWqBBOX1hmmBgwI9HnOYtIOuyR23646WGVdokCiE24mhr7fJfltwDHCKTbXyOK7AVG02sGcJ3VNXU-_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9KY3BjTGV1RGtIWXdLc3VOZ2ZSVURpaW4>)
<RobinMueller[m]> Ah, the code is not public yet..
rmsyn[m] has joined #rust-embedded
<rmsyn[m]> <RobinMueller[m]> "Hey, does anyone know an elegant..." <- there's a couple ways to achieve what you're trying to do.... (full message at <https://catircservices.org/_irc/v1/media/download/AdmmeQR5cehVVrKgL3OjBBp93IPDPhynIM4ZP0n4MYJ20hinuzpw0DokHBjl5V3OUHFvGLCvxISHWMHyuf2gDBa_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9URkhQaFJJZURTaVVpTGNzbllJRmVyU3I>)
<rmsyn[m]> s/`/`./, s/for//, s/you.//
<thejpster[m]> I’d make a static slice of slices and flatten the iterator to set them all at run time
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<rmsyn[m]> right, but they were asking about how to achieve a compile-time solution ...
<thejpster[m]> Compile time what though? You can’t get data into the MMU at compile time.
<thejpster[m]> And it’s unlikely that MMU set up is performance critical.
<thejpster[m]> So to me it’s just a question of “code size” vs “data size”.
<rmsyn[m]> alright, yeah I guess that's answering a different question of "why do you want a compile-time solution".
jasperw has joined #rust-embedded
jasperw has quit [Client Quit]
<rmsyn[m]> I think the general case is still interesting, though. like there are entire crates dedicated to how to const-initialize an array programmatically using macros that take function arguments for how to initialize the elements
<thejpster[m]> Yeah but we have const blocks now so initialising a bunch of slices is now fairly easy
<rmsyn[m]> sure, I guess you also move the initiializer into a `const fn do_init<const N: usize>(..args) -> [T; N]` type function
jasperw has joined #rust-embedded
pcs38 has quit [Quit: leaving]
jasperw has quit [Changing host]
jasperw has joined #rust-embedded
jasperw has quit [Quit: Byeeeeeeeeeeeeeeee!]
jasperw has joined #rust-embedded
jasperw has quit [Changing host]
jasperw has joined #rust-embedded
<DavidBrown[m]> Pre-const block, there war a few crates that tried to help with array initialization, but I haven't seen anything that takes advantage of const.
<RobinMueller[m]> TO be honest, I am almost done with the compile time solution, it's not too bad with a bit of auto-generation, RUst makes things like this easy. I'm off by a few bytes apparently, but hey, the process probably caught a bug. The question whether the performance is worth it is interesting. Initializing 16 kB is not much for a powerful processor like Cortex-A, but I was thinking that a low level boot routine should be as fast as
<RobinMueller[m]> possible. It also allows me to stay closer to the vendor bootflow, which I would prefer, I am sure that they encountered a lot of issues and optimized a lot already, and reduces the chance that I have to debug evil errors. Considering the probem that it is not possible to get data into the MMU at compile time: My understanding from the XIlinx boot files is that they pass the MMU table pointer into a CP15 register. They don't
<RobinMueller[m]> have to call any function anymore from what I can see (https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexa9/gcc/translation_table.S)
<RobinMueller[m]> s/The question whether the performance is worth it is interesting.//, s/translation_table/translation\_table/
<RobinMueller[m]> * TO be honest, I am almost done with the compile time solution, it's not too bad with a bit of auto-generation, RUst makes things like this easy. I'm off by a few bytes apparently, but hey, the process probably caught a bug. Initializing 16 kB is not much for a powerful processor like Cortex-A, but I was thinking that a low level boot routine should be as fast as possible, and there is plenty of RAM for the statically
<RobinMueller[m]> a CP15 register. They don't have to call any function anymore from what I can see (https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexa9/gcc/translation\_table.S)
<RobinMueller[m]> compiled .data section for that system. It also allows me to stay closer to the vendor bootflow, which I would prefer, I am sure that they encountered a lot of issues and optimized a lot already, and reduces the chance that I have to debug evil errors. Considering the probem that it is not possible to get data into the MMU at compile time: My understanding from the XIlinx boot files is that they pass the MMU table pointer into
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
<RobinMueller[m]> * TO be honest, I am almost done with the compile time solution, it's not too bad with a bit of auto-generation, RUst makes things like this easy. I'm off by a few bytes apparently, but hey, the process probably caught a bug. Initializing 16 kB is not much for a powerful processor like Cortex-A, but I was thinking that a low level boot routine should be as fast as possible, and there is plenty of RAM for the statically
<RobinMueller[m]> compiled .data section for that system. It also allows me to stay closer to the vendor bootflow, which I would prefer, I am sure that they encountered a lot of issues and optimized a lot already, and it reduces the chance that I have to debug evil errors. Considering the probem that it is not possible to get data into the MMU at compile time: My understanding from the XIlinx boot files is that they pass the MMU table pointer
<RobinMueller[m]> into a CP15 register. They don't have to call any function anymore from what I can see (https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/standalone/src/arm/cortexa9/gcc/translation\_table.S)
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has joined #rust-embedded
<TomB[m]> <RobinMueller[m]> "TO be honest, I am almost done..." <- We did something similar for imxrt-rs to setup the boot config (the boot rom looks for a block of configuration) by using a build.rs helper and packaging it as a crate
<TomB[m]> it'd be a neat idea to create a mmu static crate of sorts
<TomB[m]> * of sorts that would let you generate translation tables at compile time
<TomB[m]> zephyr has a python script for this sort of thing https://github.com/zephyrproject-rtos/zephyr/blob/main/arch/x86/gen_mmu.py but does it through elf manipulations, which could be another option I guess... inspect the elf and set aside some space for the table? I'm actually somewhat interested to see how you solve this, I haven't dealt with MMU much before, still learning every day :-)
<TomB[m]> * zephyr has a python script for this sort of thing for x86 which is likely more complicated https://github.com/zephyrproject-rtos/zephyr/blob/main/arch/x86/gen\_mmu.py but does it through elf manipulations, which could be another option I guess... inspect the elf and set aside some space for the table? I'm actually somewhat interested to see how you solve this, I haven't dealt with MMU much before, still learning every day :-)
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
<RobinMueller[m]> I will move the code to a public crate so I you can inspect the source code. It is nothing too fancy, just generated a separate rs file with the instantiation of the table. I really liked that I could import my own library in the generator to import constants like the number of segments
<thejpster[m]> Oh right of course, it’s an MMU. The translation tables need to be in RAM so the OS can update them with new mappings, but the hardware needs to talk the tables too. I’ve been doing too much MPU programming, which involves feeding the table into the CPU one word at a time via magic registers.
<thejpster[m]> Are you updating your tables at run time or are they fixed?
<thejpster[m]> s/talk/walk/, s///
<thejpster[m]> I resurrected the arm-dcc crate: https://github.com/rust-embedded/arm-dcc/pull/10. So much faster than semihosting.
pcs38 has joined #rust-embedded
barafael[m] has joined #rust-embedded
<barafael[m]> maybe I'm veering a bit far into what's possible here. I saw this axum + tokio on esp32 example. It worked nicely!... (full message at <https://catircservices.org/_irc/v1/media/download/AUjzZz6AtyjNByHeUjXMfVHMauCm97Uf20EBDSlMeyGWt5kvOTrgT9lLnuI0qkkZ3U20TsJ9RwpbmQ3yvlMjrRO_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9Pclpmd0dzc0lCbEVNSkxNZ3JaZGlaQmE>)
<barafael[m]> i am using the aws-lc-rs feature of async-nats, because that will avoid having to compile ring (i hope).
<barafael[m]> s/i/when/, s/hope/trying to compile ring, there are a bunch of more problems, that's why/
hpux735[m] has joined #rust-embedded
<hpux735[m]> Hi all! 👋 I'm new here. I've been working on a project using embassy on the ESP32s3. Over all, it has been excellent. I have a quick question for the hive mind:
<hpux735[m]> I'm trying to use embedded-hal-bus to share an i2c device with two peripherals. It seems to me that embedded-hal-bus doesn't implement the async version of i2c (ideal in working with embassy, so I can use the embassy spawner and not put blocking calls in an async context). For now, I'm using blocking i2c and delay, but it would be really nice to use async. I'd be happy to do some work here if it's a "we just haven't gotten
<hpux735[m]> there" situation
danielb[m] has joined #rust-embedded
<danielb[m]> Try looking into embassy-embedded-hal
<hpux735[m]> Yah, I looked around a bunch. I hadn't found an implementation of a bus. Do you know for sure if it's in there?
<hpux735[m]> wow, I'm a dumbass. Look again, and it's right there!
<hpux735[m]> Thanks danielb !
realroot[m]1 has joined #rust-embedded
<realroot[m]1> lulf to sync the time do I need to use https://github.com/NordicSemiconductor/pc-nrfconnect-launcher?tab=readme-ov-file ?
pcs38 has quit [Ping timeout: 252 seconds]
limpkin has quit [Ping timeout: 252 seconds]
pcs38 has joined #rust-embedded
limpkin has joined #rust-embedded
pcs38 has quit [Quit: leaving]