jannic[m] has quit [Quit: Idle timeout reached: 172800s]
pkoevesdi[m] has joined #rust-embedded
<pkoevesdi[m]>
`embassy-executor`.)
<pkoevesdi[m]>
Hey. I'm trying to bring parts of my rust program into the external QSPI flash.
<pkoevesdi[m]>
To achieve this, I linked a custom `memory.x` with `"-C", "link-arg=-Tmemory.x"` inside my `config.toml`. But it seems, it gets pulled in twice, because for every entry in it, I get a "region '###' already defined" error from rust-lld, no matter how I name the region. I think, it's pulled by `cortex-m-rt-b26624eecb12fef9/out/link.x`, which has a "INCLUDE memory.x" in it. I can comment that out there and my crate compiles, but I
<pkoevesdi[m]>
don't think that's the intended way of giving a custom `memory.x`. If I leave out my `-Tmemory.x`, it also compiles, but where are the memory regions defined then? In the search paths for the rust-lld (to my knowledge PATH and -L paths), there's no "memory.x". So, what's the correct/recommended way of making `cargo build` use my crate's `memory.x`, but only once? (Still using `cortex-m-rt` of course, needed by
<pkoevesdi[m]>
I cannot leave out the -C", "link-arg=-Tlink.x" from my config.toml. Then it compiles, but cannot be flashed ("No loadable segments were found in the ELF file."), understandably.
<JamesMunns[m]>
cortex-m-rt's link.x already includes memory.x, so you just need to make sure that's in the linker include path
<JamesMunns[m]>
ah wait, that just includes the link.x, that's not a good example, hold on
<JamesMunns[m]>
IIRC, the root of the crate is already in the link path, so if you put your memory.x in the same folder as the Cargo.toml, you should be good to go
<JamesMunns[m]>
otherwise, you can add the path to the link path like the example I showed
<diondokter[m]>
Yeah, normally you don't specify anything about memory.x to the linker
<JamesMunns[m]>
you say it "just works", then that is it working correctly!
<JamesMunns[m]>
stating the link args in .cargo/config.toml is the older way of doing it, but it still totally works.
<pkoevesdi[m]>
Sorry, I have to correct myself: If I leave out my -Tmemory.x, it doesn't compile, because it doesn't find my memory.x. It compiles, if I put the feature "memory-x" into embassy-stm32 in Config.toml. But that memory.x doesn't contain some of the regions I need (OCTOSPI).
<JamesMunns[m]>
if THAT doesn't work, I can help debug more :)
<JamesMunns[m]>
if the memory.x is in a library crate, for example if you are making a custom BSP or something, then that lib needs to add the memory.x to the linker path. If that's the case, lemme know.
<pkoevesdi[m]>
Ok, thank You very much for You help. Just putting in a memory.x in my crate root I did before, and also removing the embassy memory.x feature. But obviously not in conjunction. :-) Thanks for pushing me in the right direction! Probably soon I'll ask here, how to bring parts of my program into that OCTOSPI region... :-)
<pkoevesdi[m]>
Ok, sooner than expected... how can I add up to the cortex-m-rt-b26624eecb12fef9/out/link.x? If I put a link.x in my crate root, it replaces (probaly gets pulled before) the one from coretex-m-rt.
<pkoevesdi[m]>
* Ok, sooner than expected... how can I add up to the cortex-m-rt-b26624eecb12fef9/out/link.x? If I put a link.x in my crate root, it replaces (probaly gets pulled before) the one from cortex-m-rt.
<JamesMunns[m]>
ah, do you want to replace link.x, or just memory.x? usually you don't modify link.x?
<JamesMunns[m]>
cortex-m-rt EXPECTS to provide the link.x, which INCLUDES your memory.x
<pkoevesdi[m]>
Well, I thought I must change both? memory.x to define my OCTOSPI region, and link.x to put something in there. For the latter, I didn't mean to replace the cortex-m-link.x, just do add something. But, let's start one step earlier: I have a OCTOSPI-memory region defined now. How can I bring "something" into it?
<JamesMunns[m]>
typically, you would define the OCTOSPI region as FLASH
<JamesMunns[m]>
if you want to XIP from octospi
<JamesMunns[m]>
but, you might need a bootloader to enable OCTOSPI on startup?
<pkoevesdi[m]>
Yes, that's what I want in the end.
<diondokter[m]>
Everything in memory.x *is* added to link.x
<diondokter[m]>
Link.x includes the memory.x which works like include in C (as in it just gets copied)
<JamesMunns[m]>
generally, cortex-m-rt is very simple, it expects only a single FLASH and a single RAM range, which it uses for .text, .data, and .bss
<pkoevesdi[m]>
The bootloader I'll take care of later, first I want to achieve being able to flash something into the external flash with probe-rs (I'll read out the external flash with another tool and see, what happened there) - so, a step-by-step-approach, hopefully ending up having understood all the mechanics. Ok, good, I'll try with naming my OCTOSPI-region as FLASH. Thank You!
<JamesMunns[m]>
I recommend doing 1, then 3, then 2, in terms of "how I would do this".
<pkoevesdi[m]>
Great, thanks. I had mostly something like the first option in my mind.
<pkoevesdi[m]>
But first, let me come to the point being able to flash by probe-rs. :-)
<JamesMunns[m]>
then some complications:
<JamesMunns[m]>
1. I'm not sure if the probe-rs flash algos are smart enough to set up octospi, so they can do the flashing. That might require a custom flash algorithm
<JamesMunns[m]>
2. if you go with option 1, you might need to be careful on some chips and HALs. For example, embassy-stm32 doesn't "like" when you set up RCC already before you call `embassy_stm32::init()` - it can cause weird crashes
<JamesMunns[m]>
for 1: you can ask in #probe-rs:matrix.org if anyone has tried this, if it doesn't Just Work.
<JamesMunns[m]>
for 2: I'm not sure how to handle this. might require patching your HAL
<FreeKill[m]>
(As a C-creature now actually getting to write some embedded implementation stuff in Rust, it's pretty dang sweet 🦀)
<JamesMunns[m]>
(at least the linker script and startup behavior)
<pkoevesdi[m]>
I already wrote a custom flash algorithm, which works with my own written wrapper, but not with target-gen test of probe-rs. In the probe-rs channel they told me, that target-gen test might be broken. So, now I try to test my or an exisiting flash algorithm with this approach here, by trying to flash something. Because that would have been the next step after target-gen testanyway.
omniscient_[m] has joined #rust-embedded
<omniscient_[m]>
Hi all. I'm new to Embedded Rust (about 1 week :P). I'm curious what RPC libraries or messaging everyone is using in embedded to communicate with a server. I'm looking at `postcard-rpc` but it doesn't seem to be too mature yet and is only (currently) wired up for serial/USB, not TCP. Other options that come back from a Google seem quite old and unmaintained (`urpc`, `rust-remote-hal`) . I'd like to maybe contribute to
<omniscient_[m]>
postcard-rpc but for the purposes of my current project something that I can get up and running with immediately would be good
<ryan-summers[m]>
https://github.com/diondokter/device-driver might be interesting to you :) In general, I tend to just keep simple registers as u8/u16 internally because I'm lazy and users very rarely need them outside of the driver. For the rare ones where they do, you can expose them
<ryan-summers[m]>
If you want a sample of my lazy style, I just finished cleaning up and publishing one for the Si1145 (ambient light sensor) that you can look at for inspiration/reference: https://github.com/ryan-summers/si1145
<ryan-summers[m]>
<omniscient_[m]> "Hi all. I'm new to Embedded Rust..." <- If you're looking for pub/sub models, like for IoT devices, I maintain an MQTT driver: https://crates.io/crates/minimq
<ryan-summers[m]>
It works really well for simple telemetry + command/control interfaces when you have a network of devices
pronvis has joined #rust-embedded
<juliand[m]>
<ryan-summers[m]> "If you want a sample of my..." <- That looks very clean (or lazy ;D), indeed, thanks! Having the registers as enum variants with a value associated would make more sense for my driver, as well. And since some registers have a HIGH and a LOW byte, its probably best to keep just the first address in the enum. Then I can have the knowledge about which registers need combining into one particular function. Instead of
<juliand[m]>
distributing it over multiple files and having read/set/clear etc.
<juliand[m]>
Thanks for the input!
<juliand[m]>
<ryan-summers[m]> "https://github.com/diondokter/..."; <- Great reminder, I've seen that a while ago but never got around to actually use it. And then forgot. I'll give that a shot.
<ryan-summers[m]>
I'm personally not a fan of custom DSL syntaxes because its another thing I have to keep in memory :/ Otherwise I like the idea. Just wish it could be more basic rust code
<ryan-summers[m]>
But that's more a gripe against Rust macros in general
<ryan-summers[m]>
<juliand[m]> "That looks very clean (or lazy..." <- > <@juliand:fehler-in-der-matrix.de> That looks very clean (or lazy ;D), indeed, thanks! Having the registers as enum variants with a value associated would make more sense for my driver, as well. And since some registers have a HIGH and a LOW byte, its... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xnGnfesDUpIhzPmFFewZJbwS>)
pronvis has quit [Ping timeout: 264 seconds]
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<juliand[m]>
<ryan-summers[m]> "I'm personally not a fan of..." <- Agreed, that easily makes it a lot more complicated and unless you have a ton of registers or different chip flavors (like stm32) it is a lot of overhead for little gain.
<ryan-summers[m]>
Does anyone know if you can use quote! for docstrings in generated code? I'm trying to past things but only getting the #ident literal
<ryan-summers[m]>
* Does anyone know how you can use quote! for docstrings in generated code? I'm trying to past things but only getting the #ident literal
<ryan-summers[m]>
Ah the trick is to use #[doc = ""]
Socke has quit [Ping timeout: 264 seconds]
AtleoS has quit [Ping timeout: 255 seconds]
AtleoS has joined #rust-embedded
Rustnoob[m] has quit [Quit: Idle timeout reached: 172800s]
Socke has joined #rust-embedded
<omniscient_[m]>
<ryan-summers[m]> "If you're looking for pub/sub..." <- thanks ill check it out ^_^
birdistheword99[ has quit [Quit: Idle timeout reached: 172800s]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
AtleoS has quit [Ping timeout: 268 seconds]
<JamesMunns[m]>
Hey adamgreig or other cortex-m people, do you think we could define a variable in the linker script, and reference it in `cortex-m-rt`, so if people are missing a "real" linker script, it becomes a louder link time error, and not a delayed "no loadable sections in the elf file" thing we see reported occasionally?
<JamesMunns[m]>
like, it feels like a waste to use a variable to force it, but I feel like we could extern define it in Rust (or asm?), and touch it at least once to make sure it doesn't go missing
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
oh yea, maybe so
<adamgreig[m]>
we've talked before about having something set up to help catch missing "-Tlink.x" stuff
ivmarkov[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
Klemens[m] has quit [Quit: Idle timeout reached: 172800s]
fooker has quit [Quit: WeeChat 4.1.1]
fooker has joined #rust-embedded
FrreJacques[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
but if I merge the others that build on mine i'd be effectively self-merging mine and I'd rather not to
<newam[m]>
Strange, that was also quick for me.
<newam[m]>
I'll review that now!
<dirbaio[m]>
nightly also takes ~9s
<dirbaio[m]>
s/9s/8s/
<dirbaio[m]>
newam[m]: how do you repro the slowness then?
<newam[m]>
it was slow for me with time cargo build -p cortex-m-rt --example data_overflow --target thumbv6m-none-eabi --features cortex-m/critical-section-single-core
<dirbaio[m]>
from the cmrt dir, or repo root?
<newam[m]>
cmrt dir
<dirbaio[m]>
yep it's slow with that command for me too
<dirbaio[m]>
weird!
<newam[m]>
that's good data though!
<dirbaio[m]>
2m40s on nightly
<newam[m]>
Yeah similar here, good to know it's reproducible, but only with cortex-m/critical-section-single-core. That's a good hint.
<dirbaio[m]>
why would that matter tho 🤯
<newam[m]>
<dirbaio[m]> "btw newam while you're here..." <- Approved! Thanks for all the work on heapless BTW! I haven't had time to keep up with PRs.
<dirbaio[m]>
don't thank me, I haven't kept up either 🙈
<dirbaio[m]>
i'm going to catch up tonight
<dirbaio[m]>
hopefully
<dirbaio[m]>
the *View types are super cool
<newam[m]>
Yeah, makes it a lot closer to actual vecs in terms of usability.
<dirbaio[m]>
we also have
<dirbaio[m]>
> warning: /home/dirbaio/cortex-m/panic-itm/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2021
<newam[m]>
Yeah, need to fix that, but I got nerd sniped trying to make CI go faster before other changes 😅
<dirbaio[m]>
bisecting rustc ... it's down to nigthlies from Feb, still slow
<dirbaio[m]>
now at Jun'23
<dirbaio[m]>
do we know if it was fast at some point, or has it always been slow?
<newam[m]>
so short version, I made it slow without really taking the time to understand why originally, and now I'm paying the price :D
<dirbaio[m]>
ah so it's slow because reading the entire array? reading only one byte isn't slow?
<newam[m]>
Yeah, I'm fixing it all now, if I increase the RODATA size to reflect the linker changes and case the pointer to a *const u8 so it only reads a single element then it's fast again.
<dirbaio[m]>
const split is nice on paper, but the example code with it is about as gnarly as the example without
Trurl_m[m] has quit [Quit: Idle timeout reached: 172800s]
<newam[m]>
I would be curious if it actually saves any time/space, or if it's just to make it read better.
<newam[m]>
If we mark it `#[inline]` rustc might be smart enough to figure it out?
<newam[m]>
Ah, I read the body of the PR... they want to make a nice static out of it.
<dirbaio[m]>
i'm not sure what you gain by const split, because then you also pay ram for the static of the consumer, which main does .take() on and never uses again
<newam[m]>
it's all just ease of use I think
<newam[m]>
it's not getting run in CI at the moment, we don't have anything that does --all-features
IlPalazzo-ojiisa has quit [Quit: Leaving.]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
newam: is 544 ready to merge? all lgtm but wasn't sure if you had anything else
<newam[m]>
Yup, it's ready, got all of it out of my system 😄
<newam[m]>
I still want to rework the cortex-m(-rt) CI to consolidate all the testing mechanisms (ci/script.sh, compiletest_rs, xtask, ect.) but that's probably for another day.