<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
<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]>
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]>
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
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?
<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!