kentborg[m] has quit [Quit: Idle timeout reached: 172800s]
hpux735[m] has joined #rust-embedded
<hpux735[m]>
This feels like a stupid question, but if you’re using a StaticCell that contains a Mutex shouldn’t you be able to clone it somehow? Is the only way to share it really an Arc? If it’s an Arc, it really wouldn’t need to be a StaticCell, I’d think.
<JamesMunns[m]>
Usually you make a static, then pass around the `&'static Mutex<...>`
<hpux735[m]>
Yah, that makes total sense to me, but the compiler is saying that I can’t borrow it more than once at a time.
<hpux735[m]>
Ooooh, I bet the problem is that I shouldn’t be borrowing it mutably.
<hpux735[m]>
Nah, that doesn’t help.
<hpux735[m]>
Ok, yah... Over thinking it. Lose the StaticCell and it works fine.
sigmaris_ has joined #rust-embedded
sigmaris has quit [Read error: Connection reset by peer]
<thejpster[m]>
hey HAL team, should the critical-section crate be using fences to ensure a happens-after relationship when taking the mutex and happens-before when releasing it?
<thejpster[m]>
there's only one mention of fences and that says that anyone creating a CriticalSection token should use SeqCst fences before and after. But then doesn't do those fences when creating the token for you? Maybe I'm missing something.
<adamgreig[m]>
where do you mean exactly?
<adamgreig[m]>
the borrow() method is the only shared reference access to the mutex in critical-section and it requires a CriticalSection token that you can only get if you're within a critical section, and whatever implements getting into and out of a critical section is responsible for any required fences
<RobinMueller[m]>
thejpster: I am trying to use derive-mmio to implement a GPIO. I have a large gap between some registers here. Can I just fill this with a u32 array?
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Yeah. Give it a name starting with an underscore
<thejpster[m]>
<adamgreig[m]> "the borrow() method is the..." <- The cortex-m-single-core code doesn’t seem to have any fences in it
<thejpster[m]>
I wondered if the cs library should do the fences rather than assuming the impls will get it right
<adamgreig[m]>
<thejpster[m]> "The cortex-m-single-core code..." <- it looks like it does? where don't you see them?
<adamgreig[m]>
it calls interrupt::disable or interrupt::enable (or primask::write_raw on master), all of which ultimately contain SeqCst compiler fences
<RobinMueller[m]>
thejpster: Is it possible to nest peripheral group blocks? For example, I have a set of 8 registers for bank 0, then the same for bank 1 etc..
<dirbaio[m]>
The impl might use something other than fences as long as it establishes a happens-before relationship. For example atomics or std mutex.
<dirbaio[m]>
If the CS crate itself added fences they'd be redundant
<dirbaio[m]>
* If the CS crate itself had fences, they'd be redundant with these impls
<thejpster[m]>
RobinMueller[m]: Not currently
<adamgreig[m]>
so long as the atomics actually provide the total ordering of all memory accesses around acquire/release calls and don't only provide ordering over other atomic access, anyway :P
<adamgreig[m]>
s/total//
<thejpster[m]>
<adamgreig[m]> "it calls interrupt::disable or..." <- Oh, that’s my mistake. They’re hidden in the function that I thought was just a thin wrapper over the cpsie instruction
<adamgreig[m]>
even the thinnest of wrappers over cpsie would need a fence, so it's there
<thejpster[m]>
I should add the fence to my wrapper then
<adamgreig[m]>
so at least it's a bit more obvious what's going on
<thejpster[m]>
Is a compiler fence enough out do you need a data memory barrier?
<dirbaio[m]>
Disabling interrupts is a core-local thing so Compiler fence is enough
<dirbaio[m]>
For multicore cs impls you probably need something stronger
<thejpster[m]>
I suppose if you’ve asserted there’s only one core then yeah, out of order writes aren’t an issue as they appear in-order to the core executing them
<adamgreig[m]>
CPSID is self-synchronising and doesn't need ISB, CPSIE technically doesn't guarantee interrupts will be enabled by the next instruction without a subsequent ISB but that doesn't cause us any safety issues
<thejpster[m]>
Do you know if that’s M profile specifically or AArch32 in general?
<adamgreig[m]>
(arm also guarantee that a cpsie/cpsid pair will always permit interrupt execution between the two instructions, so don't need isb there either)
<adamgreig[m]>
this documentation is M profile specific
<RobinMueller[m]>
thejpster: OKay.. Thinking a lot into the future here probably, i'll focus on making it work first.. but in principle, could the macro be adapted so that for inner(annotated?) fields which are also derive MMIO, an API is generated to retrieve the inner field, which in turn has generated API because the block was defined separately?
<thejpster[m]>
In theory a MmioT type could have methods to return an MmioS type where S is some subset of the registers in T.
<thejpster[m]>
You need to ensure people don’t call the method twice though, and get two handles to subset S.
<RobinMueller[m]>
or mark it unsafe and transfer the responsibility 😄
<DavidBrown[m]>
Yesterday, I tried running the cortex-m executor-thread on Zephyr, and, well, for the simple case of a single Zephyr thread, it works just fine. It wasn't too difficult to make a timer driver either. I'd like to also make an executor that uses Zephyr threads, so one could be run on each of multiple Zephyr threads. As far as I can tell, I can do this by not enabling either executor-thread or executor-interrupt, which will leave
<DavidBrown[m]>
__pender undefined, and I can define that myself using zephyr's k_thread_resume. The top-level executor I would just define myself, and when it is idle, it can call k_thread_suspend.
<DavidBrown[m]>
I guess I shouldn't have been too surprised that embassy-sync just worked.
<thejpster[m]>
Would you like to compile the Arm Automotive Solutions Software Reference Stack? You'll want a Thelio Astra - the System 76 workstation with 64 or 128 Neoverse N1 cores.
<thejpster[m]>
I'm doing it on an M1 Pro MacBook Pro and it's been at it three hours. It still hasn't finished compiling clang and rustc. Which it does from source.
<mkj[m]>
Yocto!
<DavidBrown[m]>
DavidBrown[m]: Hmm, just realized I "missed", and this probably makes more sense on the Embassy channel.
<mkj[m]>
DavidBrown[m]: is that running unprivileged tasks? do you have to worry about critical-section, or there isn't any concurrency in a thread/task anyway? (thinking of https://github.com/rust-embedded/cortex-m/issues/233)
<mkj[m]>
* isn't any <del>concurrency, * concurrency</del>, * preemption in a
<DavidBrown[m]>
mkj[m]: Things _should_ be working, as my support for Zephyr provides a critical section implementation that uses Zephyr's mechanisms. Higher priority threads will preempt, but the critical section should prevent that.
<DavidBrown[m]>
On the other hand, we just had to disable riscv32 smp targets in CI because we're seeing deadlocks, and incorrect behavior, which is suggesting that I'm not getting critical section and/or atomics correct on these targets.
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]>
<thejpster[m]> "Would you like to compile the..." <- > <@thejpster:matrix.org> Would you like to compile the Arm Automotive Solutions Software Reference Stack? You'll want a Thelio Astra - the System 76 workstation with 64 or 128... (full message at
<thejpster[m]>
petekubiak: looks great, thanks for publishing!
<thejpster[m]>
If I don't use a metadata function, does the relevant metadata get removed from the build? I'm worried about compile_time from a reproduceable build standpoint.
<thejpster[m]>
I'm also awarding you a golf clap for the name. Bravo.
marmrt[m] has joined #rust-embedded
<marmrt[m]>
Both of those names have excellent names
<petekubiak[m]>
<thejpster[m]> "petekubiak: looks great, thanks..." <- So long as the `include_metadata!()` macro is called somewhere in your source, the metadata will appear in the binary, regardless of whether it is referenced anywhere else in the code.
<petekubiak[m]>
* So long as the include_metadata!() macro is called somewhere in your source then the metadata will appear in the binary, regardless of whether it is referenced anywhere else in the code.
realroot[m]1 has quit [Quit: Idle timeout reached: 172800s]
<petekubiak[m]>
So to clarify, include_metadata!() is the thing which actually causes the metadata to be embedded. The other macros in the generated metadata module are just for easy access to the data. The metadata will be included regardless of whether they're used or not
<petekubiak[m]>
<thejpster[m]> "I'm also awarding you a golf..." <- As much as I'd love to take the credit for this, I must admit it was actually ChatGPT that came up with the name 😅
<petekubiak[m]>
Naming stuff is hard...
danielb[m] has joined #rust-embedded
<danielb[m]>
If only we could make probe-rs autodetect the metadata 👀
<adamgreig[m]>
that would be pretty neat
<adamgreig[m]>
I wonder if probe-rs run could even generate and append the metadata
<adamgreig[m]>
well, I suppose probe-rs run doesn't need to know, it's literally just built it anyway :P
<diondokter[m]>
The --preverify flag already helps a ton!
<danielb[m]>
We could have some magic header, a postcard schema and the metadata in the flash somewhere
<danielb[m]>
probe-rs explain-yourself
<petekubiak[m]>
Yeah one of the features I want to add is the ability to configure the metadata's contents and structure through a config file. The other feature is a tool to extract the metadata from a passed binary. The metadata has a header and footer to help the tool identify it, I was planning to make these configurable too. I hadn't thought of embedding the schema itself into the binary, that's a cool idea!
<DavidBrown[m]>
Things look on track for the upcoming Zephyr 4.1 release to include fairly decent Rust support. The support itself is implemented in (this repo)[https://github.com/zephyrproject-rtos/zephyr-lang-rust]. There is still a lot of work to do, but there is also a pretty good core in place.
<DavidBrown[m]>
The main challenge is that this crates don't work outside of the context of a Zephyr build, and therefore don't end up being part of crates.io, and aren't something searches will find. This is a consequence of the Zephyr build system needing to be in control of everything, and it runs cargo build on the Rust application after generating a bunch of files that the various creates use (bindgen, and other things).
<DavidBrown[m]>
I do provide a sample-cargo-config.toml that can be symlinked into the apps .cargo/config.toml so that cargo check and rust-analyzer all work, though.
<adamgreig[m]>
you could have a sort of storefront crate on crates.io to help people find you maybe?
<DavidBrown[m]>
I wonder if publishing some aspect of it on crates.io would help, although I think builds would have to download it, or the crate would look unused.
<DavidBrown[m]>
Sounds good. Just waiting for the PR to make it through their process that adds it to the main Zephyr docs.
<DavidBrown[m]>
So the question about the zephyr section in arewertosyet, should we add a new section? This is quite separate from Tyler Whall's work.
<adamgreig[m]>
probably makes sense, but it's newam's project
newam[m] has joined #rust-embedded
<newam[m]>
<DavidBrown[m]> "So the question about the zephyr..." <- Yeah I'm happy to accept PRs that expand on specific RTOS' in detail.
<thejpster[m]>
<danielb[m]> "We could have some magic header,..." <- picotool for the RP2040 / RP2350 does exactly this. I'd be minded to no re-invent the wheel.
<thejpster[m]>
s/no/not/
<thejpster[m]>
well, it's not postcard. But the mechanism for storing arbitrary metadata in a binary in a way that it can be discovered by analysing either the ELF or the raw binary already exists, and it's quite portable.
<danielb[m]>
Good to know
<danielb[m]>
If you could link some references for me, that would be appreciated
<thejpster[m]>
by relying on "magic numbers that exist somewhere near the start of the binary" it still works, even if you only have access to a programmed MCU over the debug interface, or if you have a UF2 file or raw binary file. Anything that relies on magic named symbols wouldn't work for these use cases.
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
<danielb[m]>
I can see probe-rs implementing this
<thejpster[m]>
I checked my crate and I did have all the right fences already
StasZin4 has joined #rust-embedded
StasZin4 has quit [Remote host closed the connection]
rafael[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
chrysn[m] has quit [Quit: Bridge terminating on SIGTERM]
ryan-summers[m] has quit [Quit: Bridge terminating on SIGTERM]
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
RobinMueller[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
bartmassey[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
i509vcb[m] has quit [Quit: Bridge terminating on SIGTERM]
berkus[m] has quit [Quit: Bridge terminating on SIGTERM]
SirWoodyHackswel has quit [Quit: Bridge terminating on SIGTERM]
ManuelHatzl[m] has quit [Quit: Bridge terminating on SIGTERM]
petekubiak[m] has quit [Quit: Bridge terminating on SIGTERM]
FreeKill[m] has quit [Quit: Bridge terminating on SIGTERM]
mkj[m] has quit [Quit: Bridge terminating on SIGTERM]
MrPashaPG[m] has quit [Quit: Bridge terminating on SIGTERM]
rmsyn[m] has quit [Quit: Bridge terminating on SIGTERM]
hpux735[m] has quit [Quit: Bridge terminating on SIGTERM]
jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
danielb[m] has quit [Quit: Bridge terminating on SIGTERM]
Andy[m] has quit [Quit: Bridge terminating on SIGTERM]
bitts[m] has quit [Quit: Bridge terminating on SIGTERM]
newam[m] has quit [Quit: Bridge terminating on SIGTERM]
ruabmbua[m] has quit [Quit: Bridge terminating on SIGTERM]
therealprof[m] has quit [Quit: Bridge terminating on SIGTERM]
marmrt[m] has quit [Quit: Bridge terminating on SIGTERM]
DominicFischer[m has quit [Quit: Bridge terminating on SIGTERM]
JulianDickert[m] has quit [Quit: Bridge terminating on SIGTERM]
DavidBrown[m] has quit [Quit: Bridge terminating on SIGTERM]
Mathias[m] has quit [Quit: Bridge terminating on SIGTERM]