06:56 <M-[m]> Please I m new here I started practicing this language newly coming from c background I wanna ask can rust be use to develop operating system kernel, device driver's and embedded system like c programming.

06:58 <K900> You've literally just asked that in the other room

06:58 <K900> And got an answer

06:58 <K900> Multiple answers, even

11:11 <Ralph[m]> <thejpster[m]> "The nice thing about them..." <- it'd be great to have more public support for (embedded) rust from big company names - the universities i know (in Switzerland) still teach C/C++ (and sometimes with basic memory safety issues in their example code 🤦) and state "nobody is using rust and the industry just asks us for C/C++ embedded devs". at least i just read that there's now an ASIL-D & SIL4 certified toolchain

11:11 <Ralph[m]> (nice blog post, btw: https://ferrous-systems.com/blog/new-safety-critical-rust-consortium/), so that takes one of their reasons away which they so far used against it (though they'll stick to the "nobody is using it, it'd be useless if we teach it" reason 🙄).

11:38 <ilpalazzo-ojiis4> Personally? Even as a Rust fanatic, I'm not sure I'd directly teach Rust either.

11:38 <ilpalazzo-ojiis4> It is possible, however to teach rust indirectly!

11:39 <ilpalazzo-ojiis4> 1) While teaching C/C++, make a mention of the safety guarantees that need to be upheld when using pointers;

11:39 <ilpalazzo-ojiis4> 2) At some point teach students functional programming;

11:39 <ilpalazzo-ojiis4> …and after those two, learning Rust ought to be piss-easy.

11:50 <thejpster[m]> University Polytehnica Bucharest teach embedded using Rust, to students who don’t know C

11:50 <diondokter[m]> The university of Delft also has some Rust in some of their courses

11:51 <thejpster[m]> Do they do embedded in Rust?

11:52 <thejpster[m]> Don’t forget that although Rust is complicated, there’s definitely a perfectly usable subset you can learn as a first language v

11:52 <thejpster[m]> * first language.

11:52 <diondokter[m]> thejpster[m]: IIRC yes with some robotics? But it's been a while since I heard it.

11:52 <diondokter[m]> Students can pick any language really, but lots of them use Rust since they've used it in other projects

11:52 <thejpster[m]> Hell, even I don’t know the deep type theory. I have no need to know it.

11:52 <diondokter[m]> https://www.youtube.com/watch?v=hGdYBEkQJPU

12:13 <Ralph[m]> i know that per.lindgren teaches embedded rust at Luleå university in sweden.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ysTSciSDtMSZLLNSRljGdNRk>)

14:10 <FrreJacques[m]> I hope it's okay to ask here some noob questions. I was thinking that giving a timer into a driver might be a bad idea, because it probably binds it forever and can't be used outside. So I thought I try out whether it's true or not. And created a quite useless struct that has one field that implements the... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dHpFWSKheJpsmiqsUrPPSmNN>)

15:06 <ryan-summers[m]> Only tangentially rust-related, but I'm going to stick some sensors right next to my plants in probably high humidity/moisture and want them to be protected during watering as well. Anyone know of any quick tips to environment proof a small PCBA? Could probably epoxy it, but I'll need to leave a humidity sensor exposed (it has an IP67 cover on the actual sensor portion though)

15:07 <FrreJacques[m]> Plastik70

15:08 <FrreJacques[m]> You can get it in a spray can and it creates a coating that would probably fine even on sea.

15:10 <ryan-summers[m]> Hmm conformal coating is indeed not a bad idea. I was under the impression it didn't fully waterproof though?

15:11 <FrreJacques[m]> I don't know. I guess it depends on how good the coating is.

15:12 <ryan-summers[m]> I actually think just dumping the thing in epoxy might be the simplest approach. It's only going to be a couple I2C sensors

15:12 <ryan-summers[m]> But re: your timer question, I imagine your issues are related to ownership semantics. Hard to say for sure without the full code or compiler output

15:14 <FrreJacques[m]> Yeah, it says when I run my_delay I do a mutable borrow. And if I run it a second time, I do a second mutable borrow, which isn't allowed. It looks like the function that borrows the self doesn't return it.

15:16 <ryan-summers[m]> I think you need to remove the `&'a mut self` and make it just `&mut self`

15:16 <ryan-summers[m]> Your lifetime is incorrect in the definition which is throwing off the borrow checker

15:16 <ryan-summers[m]> Because you're borrowing the actual timer in the struct for 'a, aka 'a is the whole lifetime that TinyTimer exists for. So if you borrow it out in my_delay for 'a, you're borrowing it out for the entire lifetime of the timer

15:17 <ryan-summers[m]> * Because you're borrowing the actual timer in the struct for `'a`, aka `'a` is the whole lifetime that `TinyTimer` exists for. So if you borrow it out in `my_delay` for `'a`, you're borrowing it out for the entire lifetime of the timer, and thus it's borrowed out for more than just the call of `my_delay`. If you omit the lifetime, rust will figure out the appropriate `&mut self` lifetime to use automatically

15:17 <FrreJacques[m]> hundred percent right :)

15:17 <FrreJacques[m]> now it compiles

15:18 <ryan-summers[m]> Yeah it's easy to footgun yourself with lifetimes like that. When possible, don't specify any lifetime unless you know why you're specifying it

15:20 <FrreJacques[m]> It didn't came to my mind writing it with lifetimes. But I struggled to figure out how to define a generic stuct field by defining a trait it needs to implement. I found that I either have to use &Trait with lifetimes or I would need to make a Box.

15:21 <ryan-summers[m]> Yeah generic timers are not idea

15:21 <ryan-summers[m]> s/Yeah/lYeah/

15:21 <ryan-summers[m]> Generally, instead of a borrow, I use a proxy structure similar to shared-bus

15:22 <ryan-summers[m]> For example, this is such a proxy structure for the embedded-nal TCP/UDP stack traits: https://github.com/quartiq/smoltcp-nal/blob/main/src/shared.rs

15:22 <FrreJacques[m]> Cool thing is. It is working now to delay via the t3 or via tiny, as I like. So I could hand over the timer as &mut and use it for other stuff too.

15:24 <ryan-summers[m]> I think it may break when you try handing things around though

15:24 <ryan-summers[m]> Borrows like that tend to be quite fragile, which is why I reference proxy structures to handle it instead. Proxy structures also have the benefit of not having generic lifetimes

15:25 <ryan-summers[m]> The general idea of a proxy structure is to move the actual timer into some 'static memory location and then make new, owned structs with cell references to it. Then you provide some synchronization API (i.e. critical sections, atomic bools, whatnot) to handle concurrent access

15:25 <ryan-summers[m]> So you'd have `&'static MyTimer` and then some `ProxyTimer` where `ProxyTimer: DelayUs`

15:26 <ryan-summers[m]> * some `ProxyTimer { _ref: Mutex<&MyTimer> }` where

15:33 <FrreJacques[m]> Okay. That is interesting. Some days ago I started my first embedded rust journey with a problem which I tried to solve with something like a proxy. But I didn't get it running. I wanted to make create a struct that holds a countdown with fugit duration and behaves like a countdown with core duration.

15:33 <FrreJacques[m]> But as far as I understand that is something which is more relevant for the main application as for the driver.

15:40 <FrreJacques[m]> And having the struct taking a timer that implements the delay and a function that use it, is like the first starting point to get my driver project started :)

18:46 <GrantM11235[m]> Frère Jacques: You don't need `dyn` https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=adbf8692ff03789e6b46f409a6e34cd7

18:47 <GrantM11235[m]> By the way, embedded_hal 1.0 solves this problem with this blanket impl https://docs.rs/embedded-hal/latest/embedded_hal/delay/trait.DelayNs.html#impl-DelayNs-for-%26mut+T

18:49 <GrantM11235[m]> It means that `&mut MyTimer` will always impl delay as long as the non-reference `MyTimer` does

18:49 <FrreJacques[m]> I had it first without dyn. But the compiler says Trait objects must include the dyn keyword.

18:51 <GrantM11235[m]> The thing I posted uses generics instead of a trait object

18:53 <FrreJacques[m]> Ah okay. So it's not a different way to express it, it's a different thing with the where.

18:54 <FrreJacques[m]> I should reread those sections in the rust book. But those things are stretched over different chapters,which is a bit like a maze hunt.

18:58 <GrantM11235[m]> Chapter 10 covers generics, but I don't think it explains trait objects/dyn, or how they are different

19:00 <FrreJacques[m]> Do you have a good ressource for that?

19:01 <GrantM11235[m]> Ah, here is the section on trait objects https://doc.rust-lang.org/book/ch17-02-trait-objects.html

19:03 <FrreJacques[m]> But what you did in your example is creating a struct and implementing the two Delay traits for it. In the end this is not what I want. I want to have a struct that takes a type that already implements those traits.

19:04 <FrreJacques[m]> Because I want to create a struct that takes different pins and a timer and than communicates with another device.

19:07 <GrantM11235[m]> Ah, I didn't realize you were writing your own driver, I thought you were trying to use an existing driver

19:08 <FrreJacques[m]> Thats how I started. And then I saw that the existing is outdated and doesn't have full feature set and I thought it would be a nice project.

19:09 <FrreJacques[m]> And to have it quite generic I want to specify only that the fields have the needed embedded-hal 1 traits.

19:13 <GrantM11235[m]> If you hold the delay in your driver struct, you won't be able to use the delay for anything else for the lifetime of your driver, unless you use some sort of mutex

19:17 <FrreJacques[m]> Hmm, but this works. After creating an instance of the struct I still can call the delay on the Delay I put into the struct.

19:17 <GrantM11235[m]> One option is to not hold the delay in the struct and to just pass it in whenever you need it. Compare these two examples https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b98f03126c82d69b064f0beb0453a520

19:19 <GrantM11235[m]> FrreJacques[m]: That's because the struct is being dropped when you use the delay again. If you create the struct, use the delay, then use the struct, you will get a borrow checker error

19:20 <FrreJacques[m]> Yeah that was my other idea. To initialize it with only the pins that really can't be used for anything else and then reach in a delay for each function call.

19:23 <FrreJacques[m]> GrantM11235[m]: Ah you are right.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/evBjxVSmoiRHyPHbAwzRJNIi>)