ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
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))]
emerent_ is now known as emerent
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
lehmrob has joined #rust-embedded
lehmrob has quit [Read error: Connection reset by peer]
K900 has quit [Quit: Idle timeout reached: 172800s]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 255 seconds]
lehmrob has joined #rust-embedded
romancardenas[m] has joined #rust-embedded
<romancardenas[m]> rust-analyzer on VSCode is showing me hundreds of errors like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nSXKxrwQlSeHvZdDDtEIGBdL>)
richardeoin has quit [Quit: WeeChat 2.8]
richardeoin has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<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?
Guest7221 has joined #rust-embedded
<JamesMunns[m]> pointer addresses don't exist at const time, iirc
<JamesMunns[m]> oh hmm, it's complaining about the &mut thing
<dirbaio[m]> yeah, this is allowed `static mut PTR: *const u8 = unsafe { &ARENA } as *const _ as _;`
<dirbaio[m]> and this is not `static mut PTR: *const u8 = unsafe { &mut ARENA } as *const _ as _;`
<dirbaio[m]> seems it cares about whether the pointer comes from `&mut` or `&`, not whether it's `*const*` or `*mut`
<JamesMunns[m]> static mut PTR: *mut u8 = unsafe { ARENA.as_ptr() }.cast::<u8>().cast_mut();
<dirbaio[m]> I imagine using *const and casting it at runtime violates pointer provenance... :S
<JamesMunns[m]> if you want a mut ptr to it you should probably make it a `MaybeUninit<UnsafeCell<...>>`
<dirbaio[m]> ARENA.as_ptr() makes the pointer get readonly provenance too
<dirbaio[m]> JamesMunns[m]: lol this works
<dirbaio[m]> ¯\_(ツ)_/¯
<JamesMunns[m]> btw, casting ptrs from const to mut is okay and doesn't violate provenance, IIRC
<dirbaio[m]> it does if the pointer originally came from a `&T`
<dirbaio[m]> `&mut T -> *mut T -> *const T -> *mut T` is fine
<dirbaio[m]> `&T -> *const T -> *mut T` is not
<JamesMunns[m]> Yeah, I think that's why the unsafecell is load bearing
<JamesMunns[m]> you are allowed to & -> *mut with UnsafeCell
<dirbaio[m]> yea but that's due to unsafecell being special
<JamesMunns[m]> yeah but that's what its for.
<JamesMunns[m]> like, UnsafeCell is the "one true inner mutability" type.
<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?
<JamesMunns[m]> as far as I know, yes.
<dirbaio[m]> miri says yes
<dirbaio[m]> huh
<JamesMunns[m]> Yeah, I use this construct in all of my cursed crates
<JamesMunns[m]> which typically have a clean miri bill of health
<JamesMunns[m]> I ended up with that construct specifically after battling miri
<JamesMunns[m]> because the MU is transparent, we can treat a pointer/reference to it as if it was an unsafecell
<dirbaio[m]> I thought .get() was the special sauce, not the UnsafeCell itself
<JamesMunns[m]> you could do an additional addr_of! if you wanted, but I don't think it's necessary.
<dirbaio[m]> but gues snow
<dirbaio[m]> * but guess not
<JamesMunns[m]> no, it's a container attribute, afaik
<dirbaio[m]> i'm making a task arena for embassy-executor
<dirbaio[m]> so it'll work on stable :D
<dirbaio[m]> * on stable 1.75 :D
<JamesMunns[m]> Nice@
<dirbaio[m]> no more TAIT
<JamesMunns[m]> * Nice!
<JamesMunns[m]> the static-alloc crate has a bump allocator that you can use for that, btw
<dirbaio[m]> I need to be able to alloc different types tho
<dirbaio[m]> there's bumpalo and other crates that can do that
<JamesMunns[m]> static-alloc isn't like Pool
<dirbaio[m]> but they're all massively complex
<JamesMunns[m]> you can alloc arbitrary Ts
<JamesMunns[m]> I mean it's just the same as what I wrote.
<dirbaio[m]> ah wtf
<dirbaio[m]> the generic param in `Bump<[u8; 1 << 16]>` threw me off
<dirbaio[m]> I guess it's because it predates const generics :|
<JamesMunns[m]> hmm maybe I flipped the MU/UC
<JamesMunns[m]> lemme look up what I did in bbqueue lol
<JamesMunns[m]> but I think since it's transparent it doesn't matter
<JamesMunns[m]> Ah no, I did do `Uc<Mu<bytes>>`: https://docs.rs/bbqueue/latest/src/bbqueue/bbbuffer.rs.html#23
<JamesMunns[m]> I still think either are acceptable. and I also made sure that BBBuffer always ended up in .bss
<dirbaio[m]> still these "bump allocator / arena" crates tend to grow a ton of features
<dirbaio[m]> i'd rather keep deps lean
<JamesMunns[m]> ¯\_(ツ)_/¯ im never gunna tell you not to write your own
<JamesMunns[m]> just letting you know a thing exists
<dirbaio[m]> yeah
<JamesMunns[m]> I mean, I've written that snippet enough times for various different things lol
<JamesMunns[m]> I did it backwards in mnemos too, to define the heap ram section lol: https://github.com/tosc-rs/mnemos/blob/main/platforms/allwinner-d1/d1-core/src/ram.rs
<JamesMunns[m]> But I do actually prefer this over using linker symbol pointers: https://github.com/tosc-rs/mnemos/blob/main/platforms/allwinner-d1/src/lib.rs#L37-L39
<JamesMunns[m]> well that's a worrying comment
<dirbaio[m]> hah
<JamesMunns[m]> Maybe I should be less sloppy with `Uc<Mu<T>>` and `Mu<Uc<T>>` :)
<JamesMunns[m]> Properly cleaned up:
<JamesMunns[m]> s/64e459e5511fcb6d054a772250b55b54/d8a2f1c2e9d763720044348de14599c1/
<JamesMunns[m]> Opened a T-Opsem topic to figure out if I was actually full of shit :)
<JamesMunns[m]> https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/How.20transitive.20is.20repr.28transparent.29.2FUnsafeCell.3F
sirhcel[m] has joined #rust-embedded
<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]
crabbedhaloablut has quit []