<wassasin[m]>
For a project we filter it even on-device depending on a runtime config parameter
<wassasin[m]>
But that is not a standard probe-rs feature
<wassasin[m]>
s/probe-rs/defmt/
<thejpster[m]>
TIM6_DAC1_CH1_DMA_RMP - what is this chip even doing
<JamesMunns[m]>
big "it's free real estate" energy
<dirbaio[m]>
the "randomly shuffle a few things" bit
<dirbaio[m]>
ST loves those
<JamesMunns[m]>
Is that an M0/M0+ target @thejpster? I see those kinds of "merged" interrupts on M0/+ when they have more than the 32 usable interrupts and need to squish them together
<thejpster[m]>
Never used uom but as the author of Measurements, the whole point is that they are different types specifically to avoid people mixing them up.
<thejpster[m]>
Now Torque and Energy is a more interesting question (both are measured in Newtons x Metres).
<Koen[m]>
(IMHO) not including any quantity in the schema is how you crash your next mars climate orbiter
<wassasin[m]>
I have a function in ROM memory for which I have a fixed address written down in a datasheet, but no ELF file or similar. What would be the most beautiful and least undefined way to get this function callable in my Rust code? Currently I just transmute the address to a function pointer of the correct type with that address. Linkerscript?
<diondokter[m]>
wassasin[m]: I think it's fine what you're doing. Surely the RP impls do something similar
<BartvanMaris[m]>
I have an issue that i cant find much information about and i was wondering if anyone here can help me figure it out.
<BartvanMaris[m]>
I have made some firmware for an ATSAM3X8E. Generate the PAC using svd2rust. Built a little application on top. The code works when i compile it using rustc version 1.86. However now when upgrading to 1.87 and changing nothing in the code it no longer works. It still compiles and gives no warnings. When debugging using gdb it runs up to the #[entry] macro from the cortex-m-rt crate and then immediately goes into a HardFault.
<BartvanMaris[m]>
Did anyone else experience an issue like this when updating rust versions?
<JamesMunns[m]>
Can you share the code as a github repo? That's pretty unusual, the only things that cause that in my experience are stack overflows or if you were doing some kind of unsafe code that caused undefined behavior.
<JamesMunns[m]>
In embassy, we've seen at least one case where rust has gotten smarter about not aligning stack types when it's not required, which caused an issue with DMA code that expected stack buffers to be 2 or 4 byte aligned, but they are now only 1 byte aligned.
<JamesMunns[m]>
@Bart van Maris ^
<BartvanMaris[m]>
The repo is work related and private unfortunately.
<JamesMunns[m]>
Gotcha, are you doing any unsafe code in your drivers or application code?
<wassasin[m]>
I would start out testing a minimal blinky style application with the same compiler version, just to verify that your problem is not on that level
<JamesMunns[m]>
oh, and general "avoid stack overflow" guidance, check if you are ever passing or returning large structures by value, this can cause much more stack usage than you expect.
<BartvanMaris[m]>
Does the extra information gathered from using gdb help. I was able to get to the start of main. After which the hardfault was immediately triggered. So no additional data or structs where initialized at that time i'd assume.
<BartvanMaris[m]>
I already compile using release.
<BartvanMaris[m]>
Ill have a look at the memory layout. Thanks for the advice.
ello_ has quit [Read error: Connection reset by peer]
DavidBrown[m] has joined #rust-embedded
<DavidBrown[m]>
I'm now registered for RustConf, it'd be nice to meet anyone else that will be there in person.
ello_ has joined #rust-embedded
<Ralph[m]>
i guess "defmt" no longer just stands for "deferred formatting"... it's now also "differential evolution fuzzy multilevel thresholding (DEFMT)" 😅
<Ralph[m]>
it's from a student group which wrote the firmware for a robot in Rust in 2023 (using embassy) and their recommendation is to _not_ use Rust for student projects based on their experience. i hope that the experience has improved in the mean time and new student teams no longer arrive at the same conclusion.
jonored[m] has joined #rust-embedded
<jonored[m]>
<JamesMunns[m]> "oh, and general "avoid stack..." <- I've found that this annoyingly often includes "constructing a value". Had to do some wacky dances with async when I was doing very-memory-constrained stuff.
<RockBoynton[m]>
<jonored[m]> "I've found that this annoyingly..." <- What did you have to do? I'm constructing a large object on init right now that should be placed in a specific linker section (using a static mut MaybeUninit) that has more ram. I try to write that on init and send to an RTIC software task, but that only works when it's under some size threshold
<jonored[m]>
<RockBoynton[m]> "What did you have to do? I'm..." <- Probably not a helpful trick, sadly. Most of my stack usage consisted of the stack frame(s) for a poll() function for a single big compound Future (which was running in essentially a custom executor); the trick was to push a reference to a sub-future to a different top-level slot, return from the big poll(), have the outer process run _that_ future to completion, and then poll()
<jonored[m]>
into the top future again. Nothing really directly to do with the value construction except that the big locals on the stack, and bad interactions between inlining and the stack-slot coloring in llvm to let it reuse variables making my poll() functions have much larger stack frames than you might expect, but I got a win from knowing that everything in the stack frame was essentially a temporary so I could use a trampoline to reuse
<jonored[m]>
it without really losing anything.
<jonored[m]>
the problem with the stack-slot coloring optimization is that it can't cut up the space used by a large value to reuse it piecewise, so if you have a lot of different sizes of on-stack data it can leak space for the rest of the frame, and with aggressive inlining to let other optimizations happen that can get to being a problem.
sroemer has quit [Quit: WeeChat 4.5.2]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time! i've just enough bandwidth to host and hopefully getting more over the next few weeks... thanks James Munns for running the last couple! agenda for this week is https://github.com/rust-embedded/wg/discussions/848, please add anything you'd like to announce or discuss and we'll start in a few minutes
<adamgreig[m]>
I think the simplest answer is "we don't support that target and that's why it doesn't work", but it's frustrating because the only reason it doesn't work is due to copying some precompiled files that we don't even need any more
<adamgreig[m]>
I think the best solution is to make a new 0.7.x release of cortex-m which backports all the non-breaking changes from master, which includes removing the pre-built objects
<dirbaio[m]>
didn't we make inline-asm non-opt-in a loooooong while ago?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Is there a reason we don't support that target? Presumably it's popular enough?
<adamgreig[m]>
it's some tier-3 target for a particular rtos
<adamgreig[m]>
it probably didn't exist as a rust target when we did the cortex-m targets, I expect
<thejpster[m]>
Is removing the objects a non breaking change? Could someone be relying on them being the?
<bartmassey[m]>
Oh, it's the nuttx target. Didn't realize that was even a thing.
<adamgreig[m]>
they're strictly an implementation detail for the asm calls, so I don't expect it to break anything, but I suppose there's a chance someone has done something very weird to call them directly?
<adamgreig[m]>
it's not part of our api
<dirbaio[m]>
oh wow it's indeed not removedin 0.7.7
<adamgreig[m]>
dirbaio[m]: yes, I'm trying to dig this detail up but yea I think only on master perhaps
<dirbaio[m]>
I think defaulting to inline asm should be non-breaking (other than the MSRV bump of course)
<thejpster[m]>
You haven’t since a release in about 2 years IIRC
<dirbaio[m]>
> This crate is guaranteed to compile on stable Rust 1.38 and up.
<thejpster[m]>
I’m happy to report - Ferrocene can handle that ;)
<adamgreig[m]>
we can bump the msrv in a minor release
<i509vcb[m]>
> 2019
<bartmassey[m]>
This is an issue I wanted to talk about in general maybe. Today's was aarch64-cpu, which on crates.io exports an older version of tock-registers. There's a lot of crates in our ecosystem where top-of-tree is way behind published…
<adamgreig[m]>
we haven't had a release for a few reasons; it's such an ecosystem pain, doing the semver trick thing is pretty awful and there's not much appetite for doing it again, there's been a few breaking changes we want to roll out that would go into the next release but haven't happened yet
<adamgreig[m]>
I don't think any fundamental problems. we could do a new 0.7 with most of the changes relatively straightforwardly
<adamgreig[m]>
doing 0.8 is a bigger question about what changes we do and whether it should just be 1.0
<dirbaio[m]>
for commit in commits { if !commit.is_breaking() { commit.cherry_pick(); }}
<adamgreig[m]>
(some of those breaking changes to-do are around decoupling cortex-m in a way that lets people use multiple versions in one crate and thus stop future ecosystem pain)
<bartmassey[m]>
I think it should just be 1.0. What's the counterargument?
<adamgreig[m]>
right now you can't use 0.7 and a hypothetical 0.8 together, but PACs all use 0.7, so HALs use 0.7, so users can't upgrade to 0.8 themselves easily, basically
<therealprof[m]>
bartmassey[m]: 1.0 anxiety
<adamgreig[m]>
one of the design plans for 0.8 is to change this in a way that would let you have 0.7 and 0.8 and 1.0 etc in the same crate, which makes future releases much less painful too
<dirbaio[m]>
inline asm was stabilized in 1.59. February 2022. I think we can take the MSRV bump 🤣
<thejpster[m]>
Why can’t you mix cortex-m crates?
<adamgreig[m]>
I think it would probably be fine to call the next breaking release 1.0, but I think it's a better idea to get a new 0.7 out with most of those changes first as people can more immediately benefit
<dirbaio[m]>
thejpster[m]: owned singletons
<thejpster[m]>
Is it the critical section impl unmangled functions?
<thejpster[m]>
Oh
<adamgreig[m]>
thejpster: direct answer is "because they have an exported no-mangle static to prevent it" plus "cargo.toml links field is set"
<therealprof[m]>
dirbaio[m]: Ooh, edition 2021?
<adamgreig[m]>
but yea, the reason behind that is because of the owner peripheral singletons, the cortex-m crate is basically a PAC in disguise
<therealprof[m]>
Funny enough I tried to compile some super old code for ATSAMD21 MCUs and that exploded spectacularly in the most vibrant colours imaginable...
<i509vcb[m]>
Pure white because linker errors lol?
<therealprof[m]>
therealprof[m]: Main reason I couldn't get it to work in a pinch was a mess of different cortex-m version dependencies.
<thejpster[m]>
Ok so it sounds like we do a 0.7.8 to try and catch up, and we don’t consider the MSRV bump to be breaking.
<adamgreig[m]>
it's still going to be quite an old msrv I think
<thejpster[m]>
And we’re still punting on 0.8 / 1.0
<adamgreig[m]>
yea, that's pretty much the state of it
<thejpster[m]>
Cool
<bartmassey[m]>
Who's putting the bell on that cat?
<adamgreig[m]>
and I expect 0.7.8 to fix that particular issue 602 too
<whitequark[cis]>
meow?
<thejpster[m]>
Sheesh, if it’s like putting flea drops on my cat, hell no.
<adamgreig[m]>
I can't do it for at least a week or two I don't expect, but I could review a pr for it
<therealprof[m]>
bartmassey[m]: Interesting phrase. We have a kitten now, he sure would appreciate a bell. 😉
<bartmassey[m]>
Sorry, old proverb about how mice agreed that the cat needed a bell to warn them. But…
<bartmassey[m]>
Me? I do love typing. But I'll shut up now.
<adamgreig[m]>
looks like the first one about deleting some old/empty repos is sorted already
<therealprof[m]>
Maybe there's more?
jannic[m] has joined #rust-embedded
<jannic[m]>
Likely. The plan is that I look out for them while triaging tickets.
<adamgreig[m]>
we'll delete 'em as we find 'em I suppose
<jannic[m]>
That already involves randomly looking into various repos. Usually for large amounts of unhandled tickets, but it would be easy to also take a note if some repo looks completely unused.
<adamgreig[m]>
svd2rust takes references to bits of mmio memory but not to global storage I don't think, so the only UB worry was about dereferencing the references possibly causing side effects, which isn't a problem in current rust
<adamgreig[m]>
but the general concept of moving away from the memory-mapped-references-to-structs (and the singleton api entirely) remains; just I don't believe there's any immediate UB concern there
<JamesMunns[m]>
(UB is also sneaky, it's also very possible to CLEARLY be doing UB but not "observe" any problems, it just means that you are dancing in a zone that rustc/llvm can decide at any time now or in the future to wreck your day
<JamesMunns[m]>
mostly commenting on the "'actual' UB" phrasing, mostly.
<JamesMunns[m]>
* your day)
<adamgreig[m]>
right; as I understand it there simply isn't UB, but there was a concern around the references for a while
<JamesMunns[m]>
IIRC yes the biggest issue was the dereferencable attribute
<JamesMunns[m]>
(causing multiple reads, like you described)
<jannic[m]>
Which wouldn't be UB from rust's POV, but might severely confuse the hardware.
<JamesMunns[m]>
For those not familiar: some hardware has "side effectful reads": e.g. just reading the register might clear a flag or pop a byte out of a ring buffer
<dirbaio[m]>
adamgreig[m]: it is UB
<JamesMunns[m]>
so if the compiler does multiple reads, which it is allowed to do since the reference is dereferencable, you might lose some events that you don't expect
<dirbaio[m]>
today's rustc implementation doesn't exploit it, that's all
<adamgreig[m]>
rustc was specifically changed to ensure that this pattern wouldn't cause ub, and the problem came from llvm's semantics, so I'm not sure it's fair to say it's ub in rust
<adamgreig[m]>
anyway it's not an immediate problem
<adamgreig[m]>
and the change from our side is clear in terms of what to do, I think, just it needs to be done
<adamgreig[m]>
was there any particular conclusion on what to do about the landing page or showcase?
RyanStreur[m] has joined #rust-embedded
<RyanStreur[m]>
I don't believe there was. The landing page is currently under construction, and there is an open PR to replace the landing page with the showcase. It seems like the questions to answer are
<RyanStreur[m]>
1. What's the goal of the landing page?
<RyanStreur[m]>
2. Will the showcase accomplish that goal, or should there perhaps be a homepage for the Rust Embedded WG, and then the showcase could perhaps be a subdomain of or a set of routes on that website?
<adamgreig[m]>
I feel like in an ideal world we'd have a small landing page with some basic info and links to github/matrix/etc, and also the showcase
<adamgreig[m]>
it doesn't make sense to me for rust-embedded.org to immediately be the showcase, but i think the idea of the pr might be that that's still better than what we currently have as a front page
<adamgreig[m]>
ok, I think as a final issue before getting to the triage ones there's the new naked functions in rust 1.88, which probably make sense for things like pre_init rather than saying they have to be in assembly as external symbols?
<therealprof[m]>
Naked functions go great with assembly...
<jannic[m]>
Is it documented that calling a naked function is allowed before statics are initialized etc? (Life before main)
<jannic[m]>
I don't see why it shouldn't be, but I never saw that spelled out.
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
In theory, it produces just your assembly. You even have to include the return instruction
<adamgreig[m]>
yea, maybe something we can get clarified, but since the body is purely assembly I feel like there can't be any issues with access to uninitialised statics/memory
<dirbaio[m]>
yeah imo it's pretty clear it's not rust code
<adamgreig[m]>
ok, let's have a quick go through the triage issues in the last ten minutes or so
<adamgreig[m]>
looks like https://github.com/rust-embedded/cortex-m/pull/594 is either awaiting the author adding a qemu test or also more review from cortex-m members, I don't think any immediate action to take
<JamesMunns[m]>
(gotta run, have a great week all, thank you Adam!)
<jannic[m]>
I love my compose key — it's so useful to type strange unicode characters!
<bartmassey[m]>
It's waiting on the suggested change, I think.
<adamgreig[m]>
the change from TIM2 to TIMER2A is good, and explaining that the interrupt macro shouldn't be used directly is useful
<bartmassey[m]>
The spaces around the em dash. Could just take it without?
<jannic[m]>
Indeed, and the formatting suggestion is a small detail.
<adamgreig[m]>
given the suggestion doesn't change the other two instances of the same thing and it's been waiting since may I think we probably take it as it comes yea