<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
<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.
<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)
<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]>
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.
<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]
<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
<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]