<M9names[m]>
<DavidHowells[m]> "Is anyone using svdtools and..." <- If you could share a link to the SVD and the name of thing you expect to be expanded, that would allow someone to give a concrete example
Amanieu has quit [Ping timeout: 265 seconds]
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #rust-embedded
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
anton_star has joined #rust-embedded
anton_star has quit [Changing host]
anton_star has joined #rust-embedded
konkers[m]1 has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m]1 has quit [Quit: Idle timeout reached: 172800s]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
anton_star has quit [Quit: Client closed]
mrkajetanp has joined #rust-embedded
VaradShinde[m] has quit [Quit: Idle timeout reached: 172800s]
anton_star has joined #rust-embedded
<thejpster[m]1>
If anyone is going to RustConf, don't forget to sort your visa or eTA. And ignore all the sponsored Google results - they're all scams.
anton_star has quit [Changing host]
anton_star has joined #rust-embedded
<AlexandrosLiarok>
flip-link seems to not take REGION_ALIAS into account
<JamesMunns[m]>
Reminder to everyone to take the survey if you haven't, and to keep sharing it! We're at 1120 responses so far, and 1400 would match the number of people who said they target bare metal systems in the 2023 general Rust survey!
<AlexandrosLiarok>
(also needs -SIZEOF(..) for all custom sections in RAM`
<AlexandrosLiarok>
s/-/-`/, s//`/, s/`/\`)/
<AlexandrosLiarok>
s/-/-`/, s//`/, s/`/)/
<ryan-summers[m]>
I suppose it should, the downside being here that you have a fixed stack size as opposed to a stack filling the unused RAM
LucasChiesa[m] has joined #rust-embedded
<LucasChiesa[m]>
Hi! I was looking embedded-hal for a 'pin' trait (something like the i2c or spi traits), but I didn't find one. Am I missing something, or there is no defined 'hal agnostic trait' for GPIOs?
<AlexandrosLiarok>
It is not fixed since it depends on the .bss and .data sections
<LucasChiesa[m]>
ryan-summers[m]: Yes, don't know how I missed it. Thanks!
<ryan-summers[m]>
AlexandrosLiarok: Something is nudging the back of my brain about this, but I don't know exactly what. There's got to be a reason why flip-link went for the (much more complicated) double-linking process
<ryan-summers[m]>
I think it has to do with how the linker calculates BSS and region sizes. I think there might be an issue with your implementation because the linker does a single pass on calculating the section sizes?
<AlexandrosLiarok>
It works on my project. I have also used the SIZEOF(section) trick to align sections to their size before.
mrkajetanp has quit [Ping timeout: 248 seconds]
<ryan-summers[m]>
I wonder if this would make a reasonable addition to the cortex-m linker files
<AlexandrosLiarok>
Would be tricky with custom sections.
<ryan-summers[m]>
I don't think cortex-m-rt really supports them anyways. If you have custom sections you have to rewrite things a bit
<AlexandrosLiarok>
users would always need to override the _stack_start
<AlexandrosLiarok>
if put in RAM
<AlexandrosLiarok>
which may be an okay compromise, it should just be well documented. Would probably break a ton of stuff if added directly though but could work fine behind a feature flag.
<AlexandrosLiarok>
I just want to ensure that it works in general, I should probably make an issue on the flip-link repo.
<ryan-summers[m]>
Yeah I think if you have any custom `INSERT AFTER <data segment>` your script wouldn't work
<ryan-summers[m]>
Since that would then cause the effective BSS size to be bigger than SIZEOF(.bss)
<ryan-summers[m]>
Might be able to calculate that using the _ebss variable though
<AlexandrosLiarok>
yea custom sections can easily break this
mrkajetanp has joined #rust-embedded
AtleoS has quit [Ping timeout: 252 seconds]
AtleoS has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]1>
<ryan-summers[m]> "I don't think cortex-m-rt really..." <- rp-rs injects custom sections in memory.x and it works fine
<thejpster[m]1>
You can try sending an issue to flip-link that says “you can replace your tool with a custom linker script that has a bunch of edge cases and issues” but I don’t know what you want them to do about it. Flip Link exists and will continue to exist, and you don’t have to use it if you don’t want to.
<AlexandrosLiarok>
just to be clear, flip-link also has a ton of edge cases and issues
<AlexandrosLiarok>
I actually had to do this because I couldn't get it to work with my custrom sections and alias regions
<AlexandrosLiarok>
s/custrom/custom/
<AlexandrosLiarok>
because it does linker script parsing and is only aware of a limited number of sections
<thejpster[m]1>
fair
<thejpster[m]1>
if you have suggestions for improvements, by all means. But what I read (and maybe I misunderstood) was that you wanted to ask flip-link if your custom linker script was going to work as an alternative to flip-link, and I don't think they (and my they I mean me and Johann) are going to be able to answer that.
<AlexandrosLiarok>
thejpster[m]1: Just to be clear, I am very grateful for `flip-link`. Just wanted to ask about the different design tradeoffs and why you went with the linker wrapper instead of the linker script approach.
<thejpster[m]1>
I'm pretty sure Jonas wrote it and he's not at Ferrous any more. I can ask Jorge but I expect the answer is "because we couldn't find a well to tell the linker to do it".
<thejpster[m]1>
s/well/way/
<thejpster[m]1>
but it's a fair question
<AlexandrosLiarok>
I am not sure if it works in general as well, it relies on SIZEOF of next sections working properly which I only experimentally verified these days and would not be aware of it if I didn't play around with trying to align sections to their own size for MPU usage.
<ryan-summers[m]>
Yeah I was surprised when I noticed the README didn't outline that. I think I read about it in one of Jorge's blogs years ago? Don't know though
<AlexandrosLiarok>
fair enough.
<ryan-summers[m]>
tl;dr here is there's likely room for improvement, but it's been hard as of yet to make things generic enough for all use cases. Even cortex-m and cortex-m-rt suffer from this a little bit
<JamesMunns[m]>
<thejpster[m]1> "I'm pretty sure Jonas wrote it..." <- I'm pretty sure Jorge wrote it, or at least was the one that proposed the functionality
<JamesMunns[m]>
JamesMunns[m]: as far as I'm aware there were some more serious issues with both GCC and LLD linkers (we have found a lot of inconsistencies and outright bugs), it's possible things have improved over the past 3-4 years tho.
<AlexandrosLiarok>
I can imagine the linker script SIZEOF stuff not working between versions / linkers.
<DavidHowells[m]>
For subsequent processing of that svd file, I need to expand that register block into multiple register definitions without the indexing, i.e. individual KEY registers. svdtools looks like it might well do this, but I cannot figure out what needs to go in the patch file: https://github.com/rust-embedded/svdtools
<thejpster[m]1>
but mainly we're trying to go from KEY0, KEY1, ..., KEYN to KEY[x] and it sounds like you want to go the other way around
<thejpster[m]1>
TIL dep-info-basedir = ".", which allows me to import cargo's .d files into my Makefile and have them actually work.
<thejpster[m]1>
(I'm replacing a build.sh with a Makefile because I was tired of it continually relinking my OS when I haven't changed anything)
<DavidHowells[m]>
Yes, I sort of want the reverse of cluster (I guess).
<DavidHowells[m]>
I think it would be handled by _expand_array. But I cannot figure out the syntax needed in the patch file and have tried various guesses. I would think it was:
<DavidHowells[m]>
* I think it would be handled by _expand_array. But I cannot figure out the syntax needed in the patch file and have tried various guesses. I would think it was: AES: _expand_array: KEY[%s] (something unknown!)
<jannic[m]>
<ryan-summers[m]> "I suppose it should, the..." <- BTW, I think having a fixed stack size can be an advantage. Sure, you need to do some estimation / measurement beforehand, to select the correct value. And if you don't want to adapt it every time you change something in your software, you'll obviously end up with a smaller stack size than theoretically possible. But then, if you have some unexpected growth in your bss / data
<jannic[m]>
section, you'll be notified at link time instead of getting stack overflows at runtime.
<ryan-summers[m]>
Yeah it's common to instead set a minimum stack size requirement in the link, but still place it such that overallocation doesn't necessarily cause faults/corruption
<ryan-summers[m]>
But a robust stack analysis can be really hard. If you have any possible cycles in the call graph, it quickly becomes really hard to reason about. Also, worst case analysis can often not be representative of what the app might see during real usage
<jannic[m]>
Definitely! I don't doubt the concept of reversing the memory layout. I just think it's sometimes better to do it by manually changing the linker script instead of just using flip-link. Of course, the latter is still a handy tool!
<jannic[m]>
Perhaps having an option like min-stack-size for flip-link would get you best of both worlds? Max stack available, and if it gets smaller than expected, it'll fail at build time?
<jannic[m]>
(I only had a quick look at flip-link to check if such a thing already exists and didn't find anything. Sorry if I missed it.)
burrbull[m] has joined #rust-embedded
<burrbull[m]>
<DavidHowells[m]> "I think it would be handled by..." <- try to escape brackets like `KEY\[%s\]`
<burrbull[m]>
* try to escape brackets with backslash
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
mrkajetanp has joined #rust-embedded
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #rust-embedded
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
I'm writing rust wrappers around Zephyr's channel primitives. I have a `Box<Message<T>>` that I use `Box::leak()` to get into a `&mut Message<T>`. Some casts, and I can give this to the zephyr function which is expecting a `*mut c_void`. When I later get the `*mut c_void` back, I can cast that to a `*mut Message<T>`, but trying to cast this to a `&mut Message<T>` gives me an error about a non-primitive cast. Do I need to use
<d3zd3z[m]>
transmute for this?
<JamesMunns[m]>
<d3zd3z[m]> "I'm writing rust wrappers around..." <- What does `.as_mut().unwrap()` say?
<dirbaio[m]>
`&mut *your,_ptr`
<dirbaio[m]>
* `&mut *your_ptr`
<dirbaio[m]>
It's not a cast op, it's a dereference op
<JamesMunns[m]>
ahhh that's right. I use `NonNull<T>` whenever I can over raw pointers in most cases
<JamesMunns[m]>
that makes it clear when you have something that is non-nullable.
<JamesMunns[m]>
(where you would have .as_mut() without unwrap)
<d3zd3z[m]>
Thanks, I don't know why I forget `&mut *ptr`.
Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 246 seconds]
<DavidHowells[m]>
<thejpster[m]1> "a github search throws up https:..." <- The do, but I just can't find a good example of how to use _expand_array!
<DavidHowells[m]>
<burrbull[m]> "try to escape brackets like `KEY..." <- Thanks. Tried that to no avail :-(