02:35 <M9names[m]> <zachariasfrings[> "> <@9names:matrix.org> the hal..." <- i'm not sure i understand the question, but if you're asking how to use the hd44780-driver crate the best places to look are the docs:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zFZFpnCyZcdtPHhgLdtTAuRp>)

02:37 <M9names[m]> this is true for basically every crate out there. most have at least got examples, even if they don't have any docs.

05:24 <David[m]12> I'm using the `singleton!()` macro to create a `&'static mut` of my type in my FW init, and I want to move the ownership of this reference to my IRQ handler. Is there a "best/cleanest" way to achieve this?

09:04 <JamesMunns[m]1> <David[m]12> "I'm using the `singleton..." <- It's difficult for IRQs to "own" anything, as they have no persistent context, and can be called multiple times. Are you using RTIC or Embassy or anything? Or just building the application directly?

09:04 <JamesMunns[m]1> Both Embassy and RTIC provide tools to allow you access to resources, though typically in Embassy the drivers will handle interrupts for you automatically.

10:31 <thejpster[m]> How do I get github to stop pinging me for reviews on rust-embedded repos?

10:38 <JamesMunns[m]1> <thejpster[m]> "How do I get github to stop..." <- https://github.com/watching

11:14 <David[m]12> <JamesMunns[m]1> "It's difficult for IRQs to "own"..." <- Maybe "own" isn't the best word. I set up and start a peripheral in my init method, giving me `&'static mut T`, and then I want to access that in the IRQ and only the IRQ for the rest of the program

11:14 <David[m]12> David[m]12: I am using Embassy but I am writing my own interrupt handler in this case

11:16 <David[m]12> David[m]12: This is what I currently am doing... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vNWevcnvFdDoicXYXswFgzaD>)

11:19 <thejpster[m]> No, It’s pinging me because it still thinks I’m in a team

11:48 <JamesMunns[m]1> <thejpster[m]> "ima_63cc57d.png" <- yeah, you might need to manually unfollow anything you were subscribed to already: https://github.com/notifications/subscriptions?reason=team_mention

11:48 <JamesMunns[m]1> JamesMunns[m]1: there's the subscription tab where you can filter by "reason", which might help drill it down.

11:52 <JamesMunns[m]1> <David[m]12> "This is what I currently am..." <- > <@davidcole1340:matrix.org> This is what I currently am doing... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/mCRPSpEuZIheXzDBepzCvuMM>)

11:57 <JamesMunns[m]1> <JamesMunns[m]1> "> <@davidcole1340:matrix.org..." <- > <@jamesmunns:beeper.com> Gotcha! Yeah - basically I'm not sure how to do it better than that in "safe" + "userspace" code, if that makes sense?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DQlceujltQCjcIuimahLAoqg>)

11:59 <JamesMunns[m]1> JamesMunns[m]1: David if you think you'd be interested in writing something like that, I can give you some more notes about how I'd do it, and I'd be happy to review the PR for it!

14:47 <thejpster[m]> subscriptions aren't the problem - it's that I'm still in these teams: https://github.com/orgs/rust-embedded/teams/tools

14:48 <thejpster[m]> probably because https://github.com/rust-lang/team/blob/master/teams/wg-embedded-tools.toml still contains me.

14:48 <thejpster[m]> Whose job is it to update the official project team repo when someone PR's the WG's team repo?

15:01 <thejpster[m]> did it myself: https://github.com/rust-lang/team/pull/1471

15:34 <firefrommoonligh> <David[m]12> "This is what I currently am..." <- Use a critical section in the ISR. LMK if you need an example

15:35 <firefrommoonligh> firefrommoonligh: Use the CS to unpack your Mutex; this gives you a mutable ref to the global

15:35 <firefrommoonligh> firefrommoonligh: Use macros if the syntax becomes unpleasant, which is likely

16:45 <Curid[m]> > Nope. In fact I have a drone engine running C code on 8K of RAM and Rust would never be able to run on it.

16:45 <Curid[m]> is this true? https://matrix.to/#/!bUUVbPAXYHHAWqLRkc:matrix.org/$dK38kC098J8JeTssftxxHqS8YLc9yNuqxmE5gx0iMuU?via=matrix.org&via=tchncs.de&via=mozilla.org

16:46 <diondokter[m]> Curid[m]: > <@curid:matrix.org> > Nope. In fact I have a drone engine running C code on 8K of RAM and Rust would never be able to run on it.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/IfHfxqRGQfkHNiqVerexDSZo>)

17:06 <thejpster[m]> Curid: here's a Rust application (an SPI-controlled device that operates a buzzer, some LEDs, some buttons and a PS/2 keyboard) which works in 4K of RAM - https://github.com/Neotron-Compute/Neotron-BMC/blob/main/neotron-bmc-pico/memory.x

17:07 <thejpster[m]> We know that things like the panic! and write! macros generating some fairly chunky machine code, but that takes up Flash, not RAM. Generally RAM usage isn't too bad.

19:23 <Lumpio-> The most complains I've heard about excessive RAM usage in Rust is when people return/move large-ish things on stack and the compiler does not optimize it properly and it allocates like 4x the stack space for copies

19:24 <Lumpio-> Flash usage can get a bit out of hand though.

19:24 <Lumpio-> Other than that the RAM usage is usually pretty reasonable.

19:25 <diondokter[m]> Lumpio-: Working on it! https://github.com/rust-lang/rust/issues/125612

21:01 <barafael[m]> Curid: Here is an application using embassy to drive an i2c display where a little logo gradually slides from one random location to the next while blinking an led. The target has 2k SRAM and 16k flash (10 Cent MCU by wch). Looking for ideas what else to add to it

21:03 <barafael[m]> https://github.com/barafael/scurrying-beetle

21:04 <barafael[m]> It's using embassy for concurrency. Is this 8k ram drone controller public somewhere?

21:15 <cr1901> Curid[m]: https://github.com/cr1901/AT2XT Rust in 2kB flash, 128 bytes of RAM

22:37 <cr1901> RobertJrdens[m]: https://docs.rs/idsp/latest/idsp/ Do you provide plain-old "I have a set of coefficients for an FIR filter and I just want to plug those into a struct and call filter()" functionality?

22:39 <JamesMunns[m]1> Robert Jördens ^

22:40 <cr1901> Or alternatively, "I have a set of coefficients for an FIR filter and I cannot be arsed to convert to SOS form"

22:42 <cr1901> (Oh right, SOS form is only for IIR, nvm)

23:11 <firefrommoonligh> Do you like Python?

23:11 <firefrommoonligh> I do something like this. See the commented-out python code. I paste the output in the rust coeffs:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZZXIzdhmNbneeITTTXenCacc>)

23:12 <firefrommoonligh> So, the scipy.signal.iirfilter gets it in SOS. Then you run the line below to convert to the form the rust libs use

23:16 <cr1901> I have an FIR filter, so SOS doesn't apply

23:16 <cr1901> (AFAICT)

23:17 <cr1901> But I'll keep that in mind for the future. I just ran my stuff thru octave for tonight

23:18 <cr1901> >Do you like Python? <-- I do; I don't care for using numpy/scipy/notebooks unless I'm in the mood to play around for hours (which isn't tonight :P)

23:57 <rmsyn[m]> re: the `Timer` trait, what if we expose two traits `Timer32` and `Timer64` for 32-bit and 64-bit timers, respectively. Then, 32-bit platforms could just implement the `Timer32` trait, and easily wrap `Timer64` to provide a 64-bit interface for drivers. For even smaller platforms, it may make sense to also do a `Timer8` and `Timer16`.

23:58 <rmsyn[m]> alternatively, we could do a single `Timer` trait that requires 64-bit interfaces, and auto-implements 8-bit, 16-bit, 32-bit, and 128-bit interfaces

23:59 <rmsyn[m]> then, users could override the other interfaces for more efficient implementations