<re_irc>
I am building a PAC for a family of microcontrollers. It currently uses a cargo workspace to create multiple library crates, one for each subfamily of devices. All devices are ARM, but their architecture varies (M3, M4, M4F). Is there a way to specify the target for each such that "cargo build" at the top level works?
<re_irc>
What I have tried is to make a "pacs/PAC/.cargo/config.toml" that specifies the target triple, but still "cargo build" at the root of the repo seems to choose darwin. If I run "cargo build --target=thumbv7em-none-eabihf" then it is happy, but I hoped to not do this since not all devices are M4F.
<re_irc>
<@seanmlyons22:matrix.org> * darwin (my host OS).
<re_irc>
<@seanmlyons22:matrix.org> -I
<re_irc>
<@9names:matrix.org> : there was a discussion about this problem 13 hours ago in this channel, if you don't mind scrolling back up.
<re_irc>
i don't know if there was any solutions given, but i've seen folks use "make", "just" and "cargo-xpath" to build multiple things from the root.
<re_irc>
<@9names:matrix.org> * "cargo-xtask"
<re_irc>
<@9names:matrix.org> i usually write shell/batch scripts for this sort of thing but i also don't normally have very complex projects
<re_irc>
<@korken89:matrix.org> Does anyone know how to get "rustc" to use double precision instructions with e.g. STM32H725 that has a double precision floating point unit?
<re_irc>
<@korken89:matrix.org> the "thumbv7-none-eabihf" target seems to only use single precision instructions?
<re_irc>
<@korken89:matrix.org> As expected, it does not know I have a double precision FPU available
<re_irc>
<@ryan-summers:matrix.org> I think was looking at the last year and it had something to do with llvm support upstream? I can't remember and can't find it in our issue trackers
<re_irc>
<@ryan-summers:matrix.org> But I think the issue is that the target triple doesn't properly tell LLVM that there's a double-precision FPU available
<re_irc>
<@korken89:matrix.org> Yeah, I was sort of looking for a rustc flag that would be needed
<re_irc>
<@korken89:matrix.org> +to be added to enable it
<re_irc>
<@korken89:matrix.org> But if LLVM does not have support yet it's a shame
<re_irc>
<@korken89:matrix.org> I guess I can write that small thing in C and compile that lib with "-mfpu=fpv5-d16"
<re_irc>
<@korken89:matrix.org> Hello CASADI my old friend, plz generate C code math for me again
<re_irc>
<@korken89:matrix.org> Thanks for the insight !
<re_irc>
<@ryan-summers:matrix.org> No problem, Robert might have some better tips, I don't know how heavily we looked into it
<re_irc>
<@ryan-summers:matrix.org> +though
<re_irc>
<@9names:matrix.org> you should also be able to use a custom target.json to add those features, if you're okay with using nightly
<re_irc>
<@jordens:matrix.org> --mcpu=cortex-m7 or something like that. See the stabilizer .cargo/config.toml iirc
<re_irc>
<@adamgreig:matrix.org> : What's the question? In short you give it a new stack pointer and reset vector, it sets that stack pointer active and jumps to that reset vector
<re_irc>
<@adamgreig:matrix.org> Which emulates what the cpu does at boot: read sp and rv from the first two words in memory, set the sp, jump to the rv
<re_irc>
<@adamgreig:matrix.org> : Aah, I guess this is new since they put that comment in the target file and since I last used it
<re_irc>
<@9names:matrix.org> it doesn't warn on adding +fp-armv8, and readelf on the target binary shows that's the FPU type being used by the executable
<re_irc>
<@adamgreig:matrix.org> The cm7 fpu is the same as the armv8 one iirc so I think that would work but maybe it's nicer to just set the cpu to avoid the warning then. Odd that fp64 isn't on that list maybe
<re_irc>
<@9names:matrix.org> i did up a basic fp64 multiply example.
<re_irc>
+fp64 does eliminate the calls to __aeabi_dmul
<re_irc>
; without +fp64
<re_irc>
objdump fails to decode the instructions generated with +fp-armv8, so i guess that's a bad idea 😄
<re_irc>
<@korken89:matrix.org> Awesome! Thanks for the help!
<re_irc>
<@thejpster:matrix.org> I made my PSoC6 work. Turns out if you write to the register "cm4_vector_table_base" it doesn't actually change the vector table on the Cortex-M4. And the Cortex-M0+ doesn't seem to boot with the stack pointer set to the first value in the vector table - it always defaults to the top of SRAM.
<re_irc>
<@mvirkkunen:matrix.org> I wonder if someone has managed to implement a stable USB audio interface in Rust in practice, considering yet another version of my niche audio mixer project
<re_irc>
<@thejpster:matrix.org> The datasheet says:
<re_irc>
> This register is used for CM4 warm and cold boot purposes: the CM0+ CPU initializes the CM4_VECTOR_TABLE_BASE register and the CM4 boot code uses the register to initialize the CM4 internal VTOR register.
<re_irc>
Perhaps I was supposed to write the "boot code" that copeis it over? I assumed the on-board ROM would do it.
<re_irc>
<@jordens:matrix.org> : Do use target-cpu=cortex-m7 because that also makes llvm use the right insn scheduling. The CM7 has a different pipeline.
<re_irc>
<@korken89:matrix.org> Oh
<re_irc>
<@korken89:matrix.org> I'll add this to the project template in RTIC so it's not forgotten :)
<re_irc>
<@thejpster:matrix.org> Why does the Cortex-M4 CPU option on the thumbv7em-none-eabi target still use vmul.f32? I though the single-precision FPU was optional?
<re_irc>
<@thejpster:matrix.org> How would you teach Rust not to emit a "vmul.f32" instruction?
<re_irc>
<@thejpster:matrix.org> Uhh, I'm so confused.
<re_irc>
"--target=thumbv7em-none-eabi -C target-cpu=cortex-m7" emits "vmul.f64" but "--target=thumbv7em-none-eabihf -C target-cpu=cortex-m7" does not and calls "__aeabi_dmul" instead.
<re_irc>
<@thejpster:matrix.org> Are Rust's target's set right? Or is godbolt broken?
<re_irc>
<@thejpster:matrix.org> (I'm aware that the difference between eabi and eabihf is _supposed_ to just be whether floating point arguments are passed in FPU registers or integer registers, but I'm also aware we sort of use it as a flag for 'has FPU' - because if you have an FPU you always always want to use the FPU registers for argument passing).
<re_irc>
<@admin:orangemurker.com> : I'm making a looper station and have considered implementing it but I am still working on the core functionality and haven't started working on the USB audio part
<re_irc>
<@mvirkkunen:matrix.org> I'm considering spending a stupid amount of time just to be able to listen to multiple PCs at once with remote control for volume (and route a microphone)
<re_irc>
<@mvirkkunen:matrix.org> The only existing product for this I could find was a multi-k€ rackmount mixer
<re_irc>
<@admin:orangemurker.com> : A simple mixer with FX send could do the same other than the remote control for volume part.
<re_irc>
<@jordens:matrix.org> : That doesn't look right.
<re_irc>
<@mvirkkunen:matrix.org> : Yes I found a lot of almost-solutions
<re_irc>
<@adamgreig:matrix.org> you could presumably add another flag to tell LLVM there's no FPU ("-vfp4")?
<re_irc>
<@adamgreig:matrix.org> maybe in practice there's very few cortex-m7 in the world without the fpu option, but lots of cortex-r4? dunno
<re_irc>
<@adamgreig:matrix.org> it does seem inconsistent but it's presumably much too late for llvm to make cortex-m4 and -m7 default to not having an fpu and add a new cortex-m4f/cortex-m7f
<re_irc>
<@adamgreig:matrix.org> (but in that case maybe Rust could have the non-hf target set -vfp4 to disable the FPU? not sure if that would work and it's still a slightly nervous change but might make sense)
<re_irc>
<@adamgreig:matrix.org> so much for that then
<re_irc>
<@adamgreig:matrix.org> given as it's the "default fpu" I feel like there should be some way to disable it with a target feature but no idea what it is if that doesn't work
<re_irc>
<@jordens:matrix.org> : Note that non-hf is not desirable here even if you convince it to use the FPU since that's a different ABI (costing the additional vmovs in your example)
<re_irc>
<@diondokter:matrix.org> Ah... crates.io down for you all as well?
<re_irc>
<@thejpster:matrix.org> depends on your use-case. Sometimes you need to interact with pre-existing systems that use the non-HF ABI and sometimes you don't want to pay the cost of stacking the FPU registers (even if the Cortex-M is fairly smart about that).
<re_irc>
<@thejpster:matrix.org> > Ah... crates.io down for you all as well?
<re_irc>
It seems fine here?
<re_irc>
<@jamesmunns:beeper.com> : website and cargo seem to be working for me atm
<re_irc>
<@diondokter:matrix.org> Seems to be up again
<re_irc>
<@jamesmunns:beeper.com> maybe you just caught a deploy :D
<re_irc>
<@jamesmunns:beeper.com> ah, my CI did see it though:
<re_irc>
Downloading crates ...
<re_irc>
Updating crates.io index
<re_irc>
warning: spurious network error (10 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (9 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (8 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (7 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (6 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (5 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (4 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (3 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (2 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
warning: spurious network error (1 tries remaining): [6] Couldn't resolve host name (Could not resolve host: static.crates.iocrates)
<re_irc>
<@jessebraham:matrix.org> Ahh good it's not just me
<re_irc>
<@jessebraham:matrix.org> Our CI got very angry and I didn't understand why haha
<re_irc>
<@ryan-summers:matrix.org> Question: if rustc beta is throwing a SIGSEGV: invalid memory reference on compile, should that concern me?
<re_irc>
<@jamesmunns:beeper.com> Customer project is on a nightly version of cargo (because embassy), so it could be specific to nightly defaults. I can't remember if everyone uses the non-git crate index
<re_irc>
<@jamesmunns:beeper.com> I assume that's the HTTP crate index... thing
<re_irc>
<@guenther_rostig:matrix.org> I found an intreseting Link: Apollo Labs (https://apollolabsblog.hashnode.dev/). There are ESP32 and STM32F4 articles.
<re_irc>
<@thejpster:matrix.org> ooops
<re_irc>
<@azzentys:matrix.org> : I'm looking into building some firmware at my company. Just as an introduction to Rust. It's a simple uart-bridge application.
<re_irc>
<@fuse117:matrix.org> i am developing a library that i ultimately want to use in an embedded application, but much of it is target independent and can thus be tested on my host machine. i would like to include examples (and maybe integration tests) that run on target. i am not sure how best to structure the project to support host development and testing as well as on target examples and tests. can someone point to an example project that i...
<re_irc>
... can use as reference?
lightningwright has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> Check out https://github.com/quartiq/minimq - there's no examples that run on-device, but it does have integration tests and is structured for embedded targets
<re_irc>
<@ryan-summers:matrix.org> But in general, the approach in the ecosystem is to keep the target-specific examples etc. in a different crate still
<re_irc>
<@fuse117:matrix.org> : this is what i have been doing, but i am interested in something more self-contained
<re_irc>
<@ryan-summers:matrix.org> I'd just keep them in a mono-repo and have multiple crates in the repo then
<re_irc>
<@ryan-summers:matrix.org> Keeping them in a single cargo workspace isn't currently supported
<re_irc>
<@jordens:matrix.org> : I meant using non-hf ABI as a way to get f64 insns in your table.
<re_irc>
<@thejpster:matrix.org> ah yes you said not desirable, I see. Yes turning _off_ HF to get hardware f64 is a wild step.
<re_irc>
<@sourcebox:matrix.org> As I said, I'm playing around with having different build targets in a workspace. There are mainly 2 things:
<re_irc>
1. Rust Analyzer doesn't get it correctly, it just takes the target configured in the outer workspace.
<re_irc>
2. "cargo build -c PATH" would solve the build issues, but is still only on nightly. So you have to cd into each crate subdir and start the build from there.
IlPalazzo-ojiisa has joined #rust-embedded
dc740 has joined #rust-embedded
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 264 seconds]
GenTooMan has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
crabbedhaloablut has quit []
<re_irc>
<@gussius:matrix.org> Hi there, I am trying to make a test harness in rust, by creating a sub crate called self-tests. It all compiles, but the rust analyser tells me "file not included in module tree (unlinked-file) for the sub-crate files. I have had this before when I did not add mod <module-name>; to my entry point. But it seems like the rust-analyzer is looking back to parent crates and starting the module tree search from there. Any clues?...
<re_irc>
<@gussius:matrix.org> Ok, so using the workspace approach, the rust-analyzer is now behaving itself. But now, my test crate, that was running tests before, now is having a linking error with memory.x. I don't think I understand quite how workspaces and testing works.
<re_irc>
<@gussius:matrix.org> Looks like I might need a build.rs file to expose the memory.x file where I need it. Hmm, what is a build.rs? I'll look into it.