IlPalazzo-ojiisa has quit [Remote host closed the connection]
paulyoung[m] has joined #rust-embedded
<paulyoung[m]>
Does anyone have any advice on how I can determine if an STM32F723IEK6 needs `eabi` or `eabihf`?
<paulyoung[m]>
None of the resources I’ve found say anything about ARM Cortex M7F (only M7) but the RM0431 reference manual mentions “M7 with FPU” on the first page.
<adamgreig[m]>
you can use either
<adamgreig[m]>
eabihf will enable the FPU and use the hard-float ABI when compiling
<adamgreig[m]>
so you probably want that, if you're going to use floats
<adamgreig[m]>
but if you don't use floats at all, you can sometimes save some memory/power/latency by using eabi
<adamgreig[m]>
in terms of how you find out, it's indeed just knowing that it has an fpu, which ST tell you
<paulyoung[m]>
paulyoung[m]: Am I right in thinking that `eabi` is safe to use either way?
<paulyoung[m]>
Thanks adamgreig!
<paulyoung[m]>
I thought it was a bit ambiguous.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
paulyoung[m]: Yes.
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
<cr1901>
Can someone remind me... there's a crate that adapts e-hal 1.0 to 0.2.7 and vice-versa?
mathu has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed (erbium.libera.chat (Nickname regained by services))]
<thejpster[m]>
how do you specify which toolchain to use in that folder? and is VS Code using the rust analyser proc-macro server from that toolchain?
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
<romancardenas[m]>
I'll take a look. My settings.json does not contain any reference to the toolchain, I only use it to select features. I assumed it used the toolchain specified in the workspace by the rust-config.yaml file
<JamesMunns[m]>
Not familiar with the rust-config.yaml file, but using a rust-toolchain.toml usually gets picked up by R-A
Guest7221 has left #rust-embedded [Disconnected: Replaced by new connection]
IlPalazzo-ojiisa has joined #rust-embedded
<spinfast[m]>
I wish we had something that could run tests on various hardware with various feature enablements, MxN builds and yes runs kind of thing
<spinfast[m]>
* I wish we had something that could run tests on various hardware with various feature enablements, MxN builds and t test runs kind of thing
lehmrob has quit [Remote host closed the connection]
nuid64[m] has joined #rust-embedded
<nuid64[m]>
What problems specific to Rust have you faced working on bare metal?
<JamesMunns[m]>
also, MaybeUninit and UnsafeCell are both repr(transparent), which means you are allowed to treat pointers to the container as if they were a pointer to the containee
<dirbaio[m]>
without explicitly going through .get(), though?
<sirhcel[m]>
Does anyone how the recommended way of overriding the version of a sub-dependency looks like? I'm asking because a later minor release of a sub-dependency of _serialport-rs_ breaks its msrv. The dependency chain in question is _serialport_ > _clap_ > _clap_lex_ > _os_str_bytes_. The last is defined as `os_str_bytes = "6.0"` by _clap_lex_ an with 6.6.0 _os_str_bytes_ increased its msrv to from 1.56.x (with wich we are fine) to
<sirhcel[m]>
1.60.1 (which breaks our msrv).
<sirhcel[m]>
I failed to address this with `[patch.crates-io]` so far and the best thing I've come up with was to specify `os_str_bytes = "<6.6.0"` from serialport and let the resolver sort this out.
<sirhcel[m]>
I'm asking for a friend. 😉
<JamesMunns[m]>
I don't think you can influence your dependencies like that. patch can only be used by the bin/"root" crate, you can't influence it as a midway dep
<sirhcel[m]>
Thank you very much for your explanation and the absolution James Munns! Then this is the way.
<JamesMunns[m]>
also, do you have a particular reason for supporting 1.56.1 (is that the 2021 edition release?)?
<JamesMunns[m]>
like, that's 18 releases ago, so a little over 2 years?
<JamesMunns[m]>
not gunna tell you how to run your project, just wondering if it was for a specific reason, or just a line in the sand.
<sirhcel[m]>
No. Our goal is to support yocto lts (with rust support, this is kirkstone) right now. They bumped their rust support to 1.59 this year. But this still dones not satisfy the "modern times" os_str_bytes 6.6.0 assumes.
<JamesMunns[m]>
Interesting!
<dirbaio[m]>
always linux distros packaging ancient rustc 💀
<JamesMunns[m]>
I went to go look, that's debian's rustc version
<JamesMunns[m]>
so, seems yocto is worse than debian atm :p
<sirhcel[m]>
JamesMunns[m]: You are absolutely right with that. And being behind debian is definitely priceless. 😄
<sirhcel[m]>
I've got a project where we upgraded to kirkstone this year. Beforehand with meta-rust is was even worse. Upgrading this project to the latest lts does not look like something happening soon because the specific kernel and its bespoke set of patches stands in the way.
<sirhcel[m]>
And sure, this definitively influences my decisions when maintaining serialport-rs. And i already thought about a clean slate and a new major release for getting just such things straight.
fu5ha[m] has quit [Quit: Idle timeout reached: 172800s]