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
AtleoS has quit [Ping timeout: 268 seconds]
AtleoS has joined #rust-embedded
omniscient_[m] has joined #rust-embedded
<omniscient_[m]> postcard
<omniscient_[m]> Are you typically does TLS with MQTT? I need all communication to be encrypted but I'm strugglign to figure out the TLS story in Rust (for embedded). There seems to be a few options that vary in how maintained they are
<omniscient_[m]> s/does/doing/
<ryan-summers[m]> There's embedded-tls and rustls if you're on standard, but TLS on embedded is pretty complex
<ryan-summers[m]> It's been on my to-do list to look into, but our use case doesn't need TLS because everything is on a private network
psukys has left #rust-embedded [Textual IRC Client: www.textualapp.com]
<omniscient_[m]> Maybe doing some sort of custom handshake into encrypted channel might be the way.. Not my forte but worth some experimentation
<omniscient_[m]> * encrypted channel (around a raw TCP socket) might be
<omniscient_[m]> or application-level encryption
<omniscient_[m]> Hmm I'm just doing some research and the Noise protocol also sounds interesting 🤔
<lulf[m]> If you control both ends, something like noise is more lightweight and simpler.
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]> CC Henk and bartmassey - I updated the `rust-lang/team` repo with you, as it is used to manage our `rust-embedded` team membership and permissions.
Henk[m] has joined #rust-embedded
<Henk[m]> <JamesMunns[m]> "CC Henk and bartmassey - I..." <- > <@jamesmunns:beeper.com> CC Henk and bartmassey - I updated the `rust-lang/team` repo with you, as it is used to manage our `rust-embedded` team membership and permissions.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PnfvxQYiXsIYFnonPlHmoxlN>)
HumanG33k has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]> I broke the Rust compiler: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/armv7r-unknown-none-eabihf.20weirdness/near/448803070
<thejpster[m]> (TL;DR: armv7r-unknown-none-eabihf gets very upset if you use a VMSR instruction in global_asm!, unless you force codegen-units=1. No one knows why)
<diondokter[m]> <thejpster[m]> "I broke the Rust compiler..." <- Huh, that looks super weird haha
<sourcebox[m]> Is this for supporting the Cortex-M85?
pronvis has joined #rust-embedded
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
pronvis has quit [Ping timeout: 260 seconds]
<JamesMunns[m]> <sourcebox[m]> "Is this for supporting the..." <- > armv7r-unknown-none-eabihf
<JamesMunns[m]> That would be Cortex-R targets
<sourcebox[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> > armv7r-unknown-none-eabihf... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vpzZisqkpMLrlSSxiZVvdJog>)
<omniscient_[m]> <lulf[m]> "If you control both ends..." <- Have you used it on bare-metal successfully? I'm looking into it now and really appeals to me. I'd like to find a way to contribute back to the ecosystem.
<JamesMunns[m]> <sourcebox[m]> "> <@jamesmunns:beeper.com..." <- yep, there are armv7 and armv8 Cortex-R targets as well
<lulf[m]> <omniscient_[m]> "Have you used it on bare-metal..." <- We're using it in production at work. I didn't implement it personally so I don't know that much about noise specifically. Fwiw embedded-tls works on bare metal too.
<omniscient_[m]> lulf[m]: Using an existing crate? I found two. One that seems to be less maintained but for no_std, and then `snow` which seems quite active
<omniscient_[m]> Sorry for all the questions haha. I'm very new to embedded and trying to get up to speed quickly but feelin' hella imposter syndrome
<lulf[m]> <lulf[m]> "We're using it in production..." <- no, internal thing
<omniscient_[m]> Love it.
<dngrs[m]> <omniscient_[m]> "Sorry for all the questions haha..." <- Everybody is just winging it 🙃
<thejpster[m]> <JamesMunns[m]> "> armv7r-unknown-none-eabihf..." <- > <@jamesmunns:beeper.com> > armv7r-unknown-none-eabihf... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/eEgiBXWmtzxBXLFrsvaxAKSl>)
<thejpster[m]> Cortex-R52 implements the Armv8-R Architecture in Aarch32 execution mode, whilst the Cortex-R82 implements the Armv8-R Architecture in Aarch64 execution mode.
<thejpster[m]> The Cortex-A53 meanwhile implements the Armv8-A Architecture and supports both Aarch64 modes and Aarch32 modes (the latter of which is compatible with Armv7-A code).
<thejpster[m]> The Cortex-M85 implements Armv8-M Mainline, like the M33 and the M55, so the target is thumbv8m.main-none-eabi or -eabihf. Plus a bunch of feature flags / a target-cpu configuration option, to enable all the fancy features in the M85 like the vector engine.
M9names[m] has joined #rust-embedded
<M9names[m]> > Cortex-${Foo} as a brand-name for a particular type of CPU core.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GwxbyQsYozkFNRgVvHXkuqRV>)
<ryan-summers[m]> Is there a preferred method to deprecate a crate on crates.io? I want to redirect users from https://github.com/ryan-summers/shared-bus-rtic to embedded-hal-bus
<diondokter[m]> ryan-summers[m]: Serde-yaml pushed a new version with a deprecation notice in the readme and the word 'deprecated' in the semver: https://crates.io/crates/serde_yaml/versions
<diondokter[m]> Not sure if that's the preferred way, but it works
<ryan-summers[m]> Ah I like a +deprecated build tag
<diondokter[m]> Yep
<thejpster[m]> probe-run I think builds with a deprecation notice telling you to use probe-rs instead.
<thejpster[m]> > You could be more specific and say it's the brand name that Arm holdings uses for their CPU designs.
<thejpster[m]> *A* brand name. They also have cores called Neoverse.
<JamesMunns[m]> Aren't the Neoverse ones Cortex-X cores?
<thejpster[m]> "derived from", like Cortex-X is "derived from" Cortex-A
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
sauce has quit []
AtleoS has quit [Ping timeout: 255 seconds]
sauce has joined #rust-embedded
kenny has quit [Ping timeout: 268 seconds]
kenny has joined #rust-embedded
henrik_alser[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Ping timeout: 264 seconds]
kenny has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
HumanG33k has quit [Quit: WeeChat 3.8]
HumanG33k has joined #rust-embedded
<yruama_lairba[m]> hello, i have a quest about https://docs.rs/bare-metal/1.0.0/bare_metal/struct.Mutex.html, why there is no "borrow_mut" method ?
<dirbaio[m]> use `Mutex<RefCell<T>>`
<dirbaio[m]> then m.borrow(cs).borrow_mut()
<yruama_lairba[m]> dirbaio: that not my question. I Actually don't see what could be the issue with a 'borrow_mut' method
<dirbaio[m]> because bare_metal::Mutex has no "locked" flag
<dirbaio[m]> which is needed to safely give a `&mut T`
<dirbaio[m]> std Mutex does two things: convert Send into Sync, and interior mutability
<dirbaio[m]> bare_metal::Mutex only does convert Send into Sync
<dirbaio[m]> you have to bring your own interior mutability, with e.g. RefCell
<dirbaio[m]> the advantage is you can save RAM with `Mutex<Cell<T>>` if you want. Cell only allows get/set, so there's no need for a "locked" flag.
<dirbaio[m]> `Mutex<Cell<T>>` is the same size as `T`
<dirbaio[m]> `Mutex<RefCell<T>>` is bigger than `T`
<yruama_lairba[m]> dirbaio: i don't undestand why you need a "locked" flag. when you enter into the critcal section you have guarantee that your ressource cannot be accessed elsewhere
<dirbaio[m]> nothing prevents entering a CS and borrowing the same mutex twice
<yruama_lairba[m]> ok, no so straightforward to unserctand
<yruama_lairba[m]> s/unserctand/understand/
<dirbaio[m]> `borrow` has signature `pub fn borrow<'cs>(&'cs self, _cs: CriticalSection<'cs>) -> &'cs T`
<dirbaio[m]> it takes `&self`, not `&mut self`
<dirbaio[m]> so you can do
<dirbaio[m]> wihch is fine, you get two `&u32` pointing to the mutex contents
<dirbaio[m]> but
<dirbaio[m]> if it had `borrow_mut` you could obtain two `&mut u32` pointing to the contents at the same time
<dirbaio[m]> which is UB
<yruama_lairba[m]> thanks i understood the issue,
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok> Has anyone ever had any issues with the input capture mode on the stm32h7 line? I had issues with two different projects over the years where I would get some rare spurious captures while the lines had no edges. Reading the channels directly to ensure the level change seemed to fix it in both cases. Just curious because I haven't found anything in the errata. Never had similar issues with other lines.
IlPalazzo-ojiis1 has quit [Quit: Leaving.]
Sophie[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901_> JamesMunns[m]: Remind me... how do you do this in postcard? https://github.com/serde-rs/json/issues/345#issuecomment-323592752
<cr1901_> This is exactly the code snippet I want. I just want to use a postcard serializer with serialize_seq
<cr1901_> Error: The length of a sequence must be known <-- nevermind (impossible in this situation)
<cr1901_> Which uhhh, makes perfect sense in retrospect, seeing that postcard prepends the length of sequences
<cr1901_> For those curious, this probably would do what I want if I knew the sequence length ahead of time: http://gopher.wdj-consulting.com:70/paste/62a46ef3-6343-4e23-a409-a9ae52a44698.txt