<firefrommoonligh>
<diondokter[m]> "Last time on my laptop I..." <- Thank you - I will try that
<firefrommoonligh>
<dirbaio[m]> "you can build inside WSL and run..." <- It could also be that I didn't tick the right things in the VS Studio installer; it's such a complicated thing
<firefrommoonligh>
Speaking of windws/linux etc, I appreciate how most of the tooling/programs etc I use don't care if you're on Windows or Linux. It's nice
<firefrommoonligh>
WSL is an escape hatch I use for certain OSS projects that only build on Linux (mainly Ardupilot for testing compatibility with the periopheral modules I have)
<firefrommoonligh>
* (mainly Ardupilot and PX4 for testing
<firefrommoonligh>
<diondokter[m]> "Btw, you sure you need llvm? And..." <- I'm not sure. I remember you have to install something to make it work, but it's been a while
<firefrommoonligh>
I don't think I've ever installed those ARM tools
<firefrommoonligh>
Pure rust things compile, but the bindgen CMSIS lib is breaking
<dirbaio[m]>
for building C code both work, but some libs out there don't have good clang support
<dirbaio[m]>
you need clang if you want cross-language LTO, otherwise try GCC
<firefrommoonligh>
So, the first error I got was about libclang; I installed LLVM and pointed the LIBGLANG path to its bin folder, and now I have this less helpful message about sqrt
<firefrommoonligh>
So, likely still a libclang thing
<dirbaio[m]>
ah you're still fighting bindgen, not trying to compile yet
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<dirbaio[m]>
yeah bindgen uses libclang...
<firefrommoonligh>
Well, I'm trying to comile
<firefrommoonligh>
The same firmwares that were compiling before I did the HD wipe
<dirbaio[m]>
oof
<firefrommoonligh>
I think it is easier on linux; the trick is just build-essential IIRC
<firefrommoonligh>
Honestly I find compiling C and C++ code to be a disaster in general
<firefrommoonligh>
In terms of user eperience
<firefrommoonligh>
I think avoiding that stuff is one of Rust's underrated strenghts
<firefrommoonligh>
Memory safety, algebraic data types sure, but how about "cargo run" just works if it's pure rust code
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<vrakaslabs[m]>
<mciantyre[m]> "> How should I eventually try to..." <- Added MIT License file 🤠
<ilpalazzo-ojiis4>
and, uh… is this relevant to embedded code any?
<ilpalazzo-ojiis4>
<firefrommoonligh> "Memory safety, algebraic data..." <- Personal opinion: Rust won't kill C++. Rust will just hold C++ in place while `cargo` delivers the coup de grace.
<FreeKill[m]>
ilpalazzo-ojiis4: I think it's a particularly interesting point in embedded. The safety arguments can ring quite hollow because at the end of the day, were doing dangerous things with hardware.
<FreeKill[m]>
But the usability? Hoo boy it's nice... In comparison with C, where I tried to incorporate a third party dependency into our cmake build and I've never emotionally recovered...
xfbs[m] has joined #rust-embedded
<xfbs[m]>
Considering the complexity of cross-compiling code under so many platforms with so many combinations of compilers, linkers, build options, CMake does a pretty decent job. I have worked with it a lot in the past. But I agree, you almost cannot compare them, because cargo exists in a different universe… a much happier one
<dirbaio[m]>
> at the end of the day, were doing dangerous things with hardware.
<dirbaio[m]>
the hardware is not actively evil. Stuff like parsing data that comes from the network though... being able to guarantee your IoT devie can't be hacked due to a stupid buffer overflow is priceless
<FreeKill[m]>
Just that I don't think it's the one-and-done argument that it honestly kind of can be in desktop
<ilpalazzo-ojiis4>
<FreeKill[m]> "I think it's a particularly..." <- > <@larunite:matrix.org> I think it's a particularly interesting point in embedded. The safety arguments can ring quite hollow because at the end of the day, were doing dangerous things with hardware.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XMeLpKFXKTRXWQIEIXcipRiJ>)
<ilpalazzo-ojiis4>
Still, even the “dangerous things we do in hardware” can be wrapped up in safe abstractions, most of the time.
<FreeKill[m]>
ilpalazzo-ojiis4: Certainly - but I think in embedded were far more liable to be making that sausage ourselves. Even if you're in the lucky position to use one of the HALs you're likely to need to get in the weeds yourself for some part of your business concern
<dirbaio[m]>
interacting with the linux kernel is also unsafe, sometimes horrifyingly so (see unix signals)
<dirbaio[m]>
* unix signals, /dev/mem)
<dirbaio[m]>
in that sense, firmware is not that special :)
<FreeKill[m]>
My expectation is that most desktop developers don't need to deal with that directly though, and see satisfied by some safe abstraction. My impression of embedded on the whole is that it's inevitable that you will need to get into the unsafety yourself.
<FreeKill[m]>
But I could be very wrong! My desktop experience is in managed languages and my embedded in C so it's a limited slice
<ilpalazzo-ojiis4>
<FreeKill[m]> "Certainly - but I think in..." <- Exactly! My point was that we can, in fact, turn that mess of offal into a nice, juicy, delicious sausage. In C we'd need to keep them as a mess of offal.
<ilpalazzo-ojiis4>
(I hope I used the term “offal” correctly here)
<ilpalazzo-ojiis4>
Anyway… could I politely repeat my question about whether PGO is relevant to embedded?
<dirbaio[m]>
I don't think the "instrument" step works for embedded, no
<ilpalazzo-ojiis4>
Right, thank you.
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hello @room , meeting time again! agenda is https://hackmd.io/5XBmP9iwSQSYnGMpI5YN3A, please add anything you have to announce or talk about and we'll start in a few mins
Farooq has joined #rust-embedded
<Farooq>
So meeting time is every week this time?
<JamesMunns[m]>
Farooq: yep, 8pm Berlin time every Tuesday
<Farooq>
How long does it last? an hour?
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
yup! or until we run out of topics/it goes off the rails.
<JamesMunns[m]>
(whatever comes first)
<Farooq>
:D
<JamesMunns[m]>
personal plug, put out a new podcast episode this week with Steve Klabnik, talked about a lot of embedded and rust stuff: https://jamesmunns.com/podcast/014-steve/
<Farooq>
I hope I could participate in the next weeks
<adamgreig[m]>
google is apparently deleting google podcasts 🥲 i'll have to find something else
<Farooq>
I think I'm gonna get my pack, which includes a lowend stm32, to arrive till the end of the week
<Farooq>
s/'m//, s/gonna/can/, s/get/expect/
<adamgreig[m]>
Farooq: nice, enjoy!
<JamesMunns[m]>
adamgreig[m]: I use podcast addict on android
<Farooq>
adamgreig Thanks!
<JamesMunns[m]>
(my podcast is also on spotify/itunes/rss/whatever)
<Farooq>
For the first project, I'm gonna create a magnet chasing robot
<adamgreig[m]>
do you know if it supports playing mp3 files from my phone and remembering where i got to on them too?
<adamgreig[m]>
not that google podcasts did but I'd like it lol
<JamesMunns[m]>
adamgreig[m]: Not sure! Only ever subbed to rss feeds, either manual input or they can search some public list of feeds
<adamgreig[m]>
I'll have a look, anyway, thanks
<adamgreig[m]>
ok, let's start! couple announcements this week
<Farooq>
Hope you a good time and hope to join the next weeks
<Farooq>
:)
<adamgreig[m]>
first off, welcome mabez to the wg! 🎉
<adamgreig[m]>
more hands in the push for embedded-hal 1.0 👀
<adamgreig[m]>
a few releases this week: embedded-io, -async, -adaptors 0.6 is out with the recent changes to make write_all errors easier to handle
therealprof[m] has joined #rust-embedded
<therealprof[m]>
adamgreig[m]: Anything that needs to be done organisation wise?
<adamgreig[m]>
svdtools 0.3.2 and 0.3.3, and svd2rust 0.30.1 released
<dirbaio[m]>
adamgreig[m]: not actually released yet lol
<thejpster[m]>
why two svdtools releases?
<adamgreig[m]>
I don't think so, I've added him to the org and teams, and the PR to rust-lang/teams has been merged too
<adamgreig[m]>
rust 1.73 is released thurs, though I didn't spot anything obviously embedded-related in the release notes
<therealprof[m]>
adamgreig[m]: Excellent, thanks.
<dirbaio[m]>
was hoping to release now, but I don't get why is CI failing
<adamgreig[m]>
and for those using rust in more regulated areas, ferrocene is having an announcement/release party/etc tomorrow, https://ferrous-systems.com/ferrocene/
<adamgreig[m]>
which they possibly spoiled with an early rss feed update 🙉 but perhaps thejpster will have more to say
<thejpster[m]>
I cannot comment on bloody cloudflare and their stupid ass bug making pages public that should not be public
<adamgreig[m]>
anyway, I hope it goes well, I look forward to catching up on it!
<thejpster[m]>
Hear from JF Bastien of Toyota, Tim Reed of Lynx, Oreste Bernardi of Infineon and many more.
<cr1901>
I thought JF Bastien was a C++ person :o
<adamgreig[m]>
next up, we're still testing the anti-spam bot Ruma Moderation , I think so far it banned one spammer _just_ after they sent their spam, but I haven't seen any problems with it yet, let me know if you spot anything
<dirbaio[m]>
they're for different use cases though?
<dirbaio[m]>
wasn't the goal of mutex-trait to be able to abstract over e.g. rtic mutexes?
mabez[m] has joined #rust-embedded
<mabez[m]>
Looking at the dependants, only 4 crates, two of which are xtensa based 😅, so I guess I have to remove those
<thejpster[m]>
last updated in 2020?
<mabez[m]>
dirbaio[m]: But I don't think rtic ended up using it? They have rtic-core which has there mutex impl
<mabez[m]>
s/impl/trait/
<dirbaio[m]>
yeah
<mabez[m]>
s/there/their/, s/impl/trait/
<adamgreig[m]>
thejpster[m]: this doesn't concern me in itself, because it's just a trait, if the trait design was right you'd hope to not need to update it much
<therealprof[m]>
thejpster[m]: Get it right once, never touch it again?
<adamgreig[m]>
that's the dream
<dirbaio[m]>
there's tradeoffs tho, that trait gives `&mut` to the contents, vs sometimes you want just `&`
<dirbaio[m]>
I think the goal of having "the one mutex trait" that works for everyone is unfeasible
<dirbaio[m]>
critical-section doesn't work for everyone either, for example rtic mutexes can't be modeled in it
<dirbaio[m]>
(mainly used to abstract embassy-sync data structures over "Sync but requires a CS" and "!Sync but doesn't block interrupts"
<adamgreig[m]>
I suppose c-s::Mutex couldn't impl this, but maybe c-s::Mutex::RefCell could?
<thejpster[m]>
if it's working for some people, and it's costing us nothing keeping it up, why change anything?
<mabez[m]>
dirbaio[m]: With that in mind, I suppose its worth keeping around, if it offers something different to `critical_section::Mutex` etc?
<thejpster[m]>
if someone finds a bug, then we can say "ok, we'll fix it" or "sorry, we give up"
<dirbaio[m]>
AFAIK there are no mutex_trait users using it as a trait
<dirbaio[m]>
like, to enable interoperability between unrelated crates
<adamgreig[m]>
thejpster[m]: I think the motivation would be whether we want to continue basically recommending its use or not
<adamgreig[m]>
for example, we could impl it for critical_section::Mutex<RefCell> and maybe that becomes popular enough that someone puts it into RTIC too, and then perhaps someone _does_ get to use it as a trait
<adamgreig[m]>
but the question then is whether it's a useful trait, or if every application ends up needing specific enough guarantees (e.g. embassy's various traits) that they can't use it in practice
<therealprof[m]>
thejpster[m]: I second the notion but at the very least we would want to keep it nice and tidy to not look totally abandoned. Which begs the question: Is is worth it?
<dirbaio[m]>
the design is odd too. why does it need `&mut self`?
<dirbaio[m]>
you'd have to `impl Mutex for &critical_section::Mutex<RefCell>` (note the `&`)
<dirbaio[m]>
then you have a pointer-to-a-pointer which is weird
<adamgreig[m]>
ah, that's more about &mut to the mutex to lock it, not what it gives the closure, huh
<adamgreig[m]>
oh, but that is what you're asking, I think
<dirbaio[m]>
yeah. So it's to protect against deadlock/reentrant locking.
<dirbaio[m]>
but in practice it makes you do impls like `impl Mutex for &critical_section::Mutex<RefCell>`
<dirbaio[m]>
and you *can* clone the `&critical_section::Mutex<RefCell>`
<dirbaio[m]>
so you can get two "handles" to the same lock, and lock it twice
<dirbaio[m]>
* so you can still get two "handles" to the same lock, and lock it twice
<dirbaio[m]>
it only works in cases like RTIC, where there's a "runtime" that ensures each task invocation only gets one "handle"
<adamgreig[m]>
and RTIC haven't ended up implementing the trait for their mutexes either, yet
<dirbaio[m]>
sure you can say "okay we keep `&mut self` so runtimes that can make use of it do, then everyone else does `impl Mutex for &...`
<dirbaio[m]>
but that makes it less ergonomic
<dirbaio[m]>
s/&...`/&...`, and don't get the protection but at least can still use the trait/
<thejpster[m]>
perhaps we shouldn't litigate a three year old crate that most of us didn't know existed until today
<thejpster[m]>
I don't see an urgent hurry to archive it. If people have thoughts, they could comment on the ticket?
<adamgreig[m]>
you approved the rfc :p
<dirbaio[m]>
imo it hasn't gained traction because these issues
<adamgreig[m]>
yea, I don't think there's any urgent hurry, but it does also seem like it has not thrived as a concept
<dirbaio[m]>
I certainly did look at it for embassy-sync then decided to write a different trait
<adamgreig[m]>
maybe people didn't need a trait for mutexes after all, or maybe this one wasn't right so didn't get used, or perhaps just having one shared trait isn't expressive enough
<dirbaio[m]>
it's not lack of exposure
<adamgreig[m]>
yea. we can leave it up, but if it's not actually useful and no one wants to use it, perhaps there's not much point
<dirbaio[m]>
yeah it's not a question of technical merit
<dirbaio[m]>
it's about messaging
<dirbaio[m]>
this is rust-embedded/mutex-trait
<dirbaio[m]>
it's THE embedded mutex trait
<dirbaio[m]>
:)
<adamgreig[m]>
I think these days we'd have put it in the hal team instead of the resources team, too
<therealprof[m]>
Have to step out, sorry... Unexpected guests... 👋
<dirbaio[m]>
so is it something the WG recommends HALs etc to implement and drivers to use, or not?
<adamgreig[m]>
right. it was, when it was released 2019/2020, but we haven't implemented it on our own crates, it's not been implemented in rtic despite being written with rtic in mind, so I think the question is why not
<adamgreig[m]>
at the time there was clearly some need for a shared trait for this sort of thing, I guess a similar need you had in embassy
<adamgreig[m]>
if we just need to actually implement it in a few places, but it's otherwise a useful idea, we could do that
<dirbaio[m]>
they're different use cases
<dirbaio[m]>
if you want it to work well for RTIC, it needs `&mut self`
<dirbaio[m]>
if you want it to work well embassy-sync, it needs `&self`
<dirbaio[m]>
* work well for embassy-sync, it
<adamgreig[m]>
so, should we have two traits in the crate?
<dirbaio[m]>
and let's say we pick `&mut self` so RTIC can implement it, and do hacks in `embassy-sync` to work with it
<dirbaio[m]>
even then, you couldn't make an embassy-sync channel be backed by an rtic mutex, because rtic gives a fresh reference to the lock at each task invocation, while embassy-sync channel wants to own the mutex every time
<dirbaio[m]>
s/every/for/, s/time/all its lifetime/
<dirbaio[m]>
if we do two traits then there's no interoperability, which was the whole point of the trait
<mabez[m]>
I think the reasons above sum it up pretty well from a technical perspective, but also I'd add that the closure based API can be tricky to work with at times, especially when mixing ? and async which might be another reason it hasn't taken off.
<mabez[m]>
RTIC has to do it this way to ensure its bounded wcet, but other implementations don't
<adamgreig[m]>
I wonder what the point of embassy-sync using it would even be? could you back the embassy-sync structures (channel, signal, etc) with some other mutex that way?
<adamgreig[m]>
what would be the point?
<adamgreig[m]>
presumably it's more for driver developers who want to use a mutex for some state that might be shared with an interrupt contex or similar, but what, the caller would have to pass the mutex reference in every time?
<dirbaio[m]>
currently embassy-sync data structures can either use NoopMutex (disables no interrupts) or CriticalSectionMutex (disable ALL interrupts)
<dirbaio[m]>
you need CriticalSectionMutex to make it Sync (for example, to make a channel to send stuff across prio levels)
<dirbaio[m]>
but then it disrupts interrupts at ALL prios
<dirbaio[m]>
if you're using RTIC and you could somehow plug it into an RTIC mutex, you could make it disable interrupts only at prio X or lower, so higher-prio stuff is still realtime
<dirbaio[m]>
you could kinda do it right now with a `PrioMutex<N>`, that does "assert current_prio <= N, raise basepri to N"
<dirbaio[m]>
but you'd have to specify N manually, you don't get the automatic analysis rtic does, and it has a higher runtime cost
<dirbaio[m]>
tldr I don't think this "one mutex trait to rule them all" is feasible
<dirbaio[m]>
there's tradeoffs
<dirbaio[m]>
ergonomics vs flexibility vs runtime cost
<dirbaio[m]>
* runtime cost vs realtimeness
<adamgreig[m]>
so basically "if you're an application, tough, just hardcode the mutex from whichever executor/framework you're using"?
<adamgreig[m]>
or perhaps "use critical_section::Mutex if those tradeoffs work"?
<adamgreig[m]>
I think the intended users are the hal/driver/application developers who want their mutexes to be generic over the eventual choice of mutex provider (rtic/embassy/c_s/std/...), but if we think that's not feasible anyway, then there's no point having a trait to abstract it
<dirbaio[m]>
exactly my thoughts
<adamgreig[m]>
and at least c_s::Mutex serves the role of "provides a mutex you can use in your application which might be backed by different providers on different platforms"
<dirbaio[m]>
btw i've clicked through some repos here and none uses it, what's up with that?
<dirbaio[m]>
* btw i've clicked through some repos here and none uses it, what's up with that?
<dirbaio[m]>
the status quo when writing a lib is kinda
<dirbaio[m]>
- if you do, either try to use atomics only, or delegate locking to the user (take &mut at every call)
<dirbaio[m]>
- if you don't care about realtime just use c-s::Mutex
<adamgreig[m]>
dirbaio: I guess they're all transitive dependencies on the esp stuff
<dirbaio[m]>
matrix is lagging badly
<dirbaio[m]>
ah transitive deps
<adamgreig[m]>
given it's already barely used, I guess the other question is how much it's worth marking it as such :P
<adamgreig[m]>
but I think we could have a pr to indicate it's not used, probably won't be used, don't bother implementing it, put that as 0.3 so it appears in the crates.io/docs.rs readme
<dirbaio[m]>
If a tree falls in a forest and no one is around to hear it, does it make a sound? :P
<dirbaio[m]>
(jk, I think people do see that repo)
<adamgreig[m]>
👍️, thanks for the discussion, I'll summarise it
<adamgreig[m]>
nothing else needed looking at on the agenda so let's end now, thanks everyone!
<adamgreig[m]>
basically "it takes &mut self to stop deadlocking but could be implemented for & and deadlock anyway, and it provides &mut to the contents but we probably just want &", so I think nothing dirbaio didn't say already in the end