08:34 <re_irc> <@luojia65:matrix.org> Hello! I submitted pull request to this repository: https://github.com/riscv-rust/fu740-pac/pull/3

09:49 <re_irc> <@diondokter:matrix.org> mdnj: You mean a rust `const`? That's fine. After your code has been compiled it doesn't even exist anymore

09:52 <re_irc> <@thejpster:matrix.org> Has anyone ever looked at Renode (https://renode.io/about/) for CI testing?

10:42 <re_irc> <@disasm-ewg:matrix.org> luojia65:matrix.org: Sorry, completely missed this one. Merged!

13:22 <re_irc> <@zentux:zwergenfreun.de> Hey! Is there a problem with putting peripheral initialisation code into a different function than your entry function? Because I'm trying to make a general timer interrupt work and when I put everything into main it works, but when I put it somewhere else The interrupt flag appears not to be correctly reset and it just executes the ISR forever.

13:29 <re_irc> <@jamesmunns:beeper.com> If you're using RTIC, the `init` function runs with interrupts disabled

13:29 <re_irc> <@jamesmunns:beeper.com> you'll generally need to (manually) clear the event flag that caused the interrupt at the start/end of each interrupt call.

13:30 <re_irc> <@zentux:zwergenfreun.de> jamesmunns:beeper.com: I'm not

13:31 <re_irc> <@zentux:zwergenfreun.de> jamesmunns:beeper.com: Yeah, I do. It works as long as it's all in the same file, but once the init code of the timer and it's ISR are in different files it doesn't work.

13:31 <re_irc> <@zentux:zwergenfreun.de> Trying to pinpoint if it's something else, currently, but I thought there may be some general pointers.

14:03 <re_irc> <@ryan-summers:matrix.org> I would check to see if your ISR is actually getting called, or if instead you're hitting a default handler?

14:03 <re_irc> <@ryan-summers:matrix.org> It's possible the file isn't getting included in the build

14:03 <re_irc> <@ryan-summers:matrix.org> Do you have a `mod <file>` in your `main.rs` file?

14:04 <re_irc> <@zentux:zwergenfreun.de> Yeah. I put in an rprintln inside of it and it gets called, but it never returns to the main loop

14:04 <re_irc> <@ryan-summers:matrix.org> Would be more helpful if you posted a minimal snippet for us to look up e.g. via a github gist

14:04 <re_irc> <@zentux:zwergenfreun.de> Yeah, I know. Sorry. I'm working on it.

14:04 <re_irc> <@ryan-summers:matrix.org> No worries :)

14:34 <re_irc> <@zentux:zwergenfreun.de> Cleaning it all up reveals that that theory was a dead end, apparently. Maybe I'm doing something wrong during initialisation of other peripherals.. 🤔

14:39 <re_irc> <@zentux:zwergenfreun.de> Anyway, I'll slowly start adding things back in, I'll get back to you once I know more. Thanks for you help so far :D

14:50 <re_irc> <@suizo:matrix.org> thejpster:matrix.org: I have been wanting to test something with that framework for quite some time, the bad / good news is that you must know C# to use it seriously

15:09 <re_irc> <@tinixoy:matrix.org> thejpster:matrix.org: tried it to experiment with beaglev stuff. real sketch experience on linux with mono. windows experience likely much better

15:17 <re_irc> <@firefrommoonlight:matrix.org> zentux:zwergenfreun.de: Are you clearing the flag in the timer's ISR?

15:19 <re_irc> <@zentux:zwergenfreun.de> firefrommoonlight:matrix.org: Yeah yeah. I was just being super stupid. I initialised the CAN controller in my hardware init function, but I set it to enabled, so when it's not hooked up properly it blocks forever, so the interrupt was actually working correctly the entire time, just a case of RTFM and I've been chasing smoke since then. ^^'

15:19 <re_irc> <@zentux:zwergenfreun.de> Don't know how I didn't notice it while debugging

15:24 <re_irc> <@firefrommoonlight:matrix.org> Hah

15:24 <re_irc> <@firefrommoonlight:matrix.org> I do stuff like that all the time

19:38 <re_irc> <@dnj:matrix.org> what's better, I want to have immutable variable inside ISR, it's better no to make it `mut` with just ```let s = 20u32;``` or shall I ```use const s: u32 = 20;```

19:39 <re_irc> <@k900:0upti.me> Very unlikely to ever matter

19:40 <re_irc> <@dnj:matrix.org> It's compile time constant, so I think it would be better to use const, but why just not let s..

19:40 <re_irc> <@k900:0upti.me> LLVM is smart enough to optimize that to the same code

19:41 <re_irc> <@dnj:matrix.org> yeah, I think It should do it but does const doesn't look kinda strange in code?

19:41 <re_irc> <@k900:0upti.me> Not really?

19:41 <re_irc> <@k900:0upti.me> Why do you think it's strange?

19:41 <re_irc> <@dnj:matrix.org> I mean in C it's normal but in Rust, shall I just const for really constants I mean value of PI etc.

19:42 <re_irc> <@dnj:matrix.org> I'm asking for advice, what it is more popular.

19:42 <re_irc> <@k900:0upti.me> Using `const` for constant values is totally fine

19:42 <re_irc> <@k900:0upti.me> Even if they're not fundamental constants

19:42 <re_irc> <@dnj:matrix.org> thanks then :)

19:42 <re_irc> <@jamesmunns:beeper.com> `const` in Rust is sort of like `#define` in C: It basically gets pasted everywhere it is used

19:43 <re_irc> <@nevercast:matrix.org> jamesmunns:beeper.com: Interestingly that's how I expect const to work in every language but that's not always the case

21:21 <cr1901> Not all languages want to require parsing/evaluating the entire language when determining a constant value :)

21:42 <re_irc> <@adamgreig:matrix.org> inline-asm FCP finished :D https://github.com/rust-lang/rust/issues/72016#issuecomment-981814343

21:42 <re_irc> <@andresv:matrix.org> I am using some huge buffers on STM32G081 and I am almost out of flash space, but I have plenty of RAM to use. So `.data` section is in RAM and it is filled with initial values that are copied from flash. In my case I do not care what is in those buffers after startup, so it is not crucial that they are zeroed or inited. I would like to just get flash space back.

21:42 <re_irc> <@andresv:matrix.org> What can be done here?

21:42 <re_irc> <@adamgreig:matrix.org> if those buffers are `static` they go into `rodata` and live in flash forever

21:42 <re_irc> <@adamgreig:matrix.org> if they are `static mut` or you put them on the stack, they have to live in RAM

21:43 <re_irc> <@adamgreig:matrix.org> (more or less: `static`s that contain interior mutability will _also_ go into ram)

21:43 <re_irc> <@adamgreig:matrix.org> oh, right

21:43 <re_irc> <@adamgreig:matrix.org> if they are zeroed, they also don't go into flash, they are only put into `bss` in RAM

21:43 <re_irc> <@andresv:matrix.org> They are in a struct that is initialized in RTIC 0.5.

21:44 <re_irc> <@adamgreig:matrix.org> ah, so they're part of a larger structure, and since some of it is being initialised, the buffers are ending up in `data` too, and so using up flash?

21:44 <re_irc> <@andresv:matrix.org> yes

21:44 <re_irc> <@andresv:matrix.org> that is the case

21:44 <re_irc> <@adamgreig:matrix.org> might be better asked in #rtic:matrix.org , hmm

21:45 <re_irc> <@adamgreig:matrix.org> you could move them out of the RTIC structure and make them their own statics, but then you lose some of the convenient of rtic's safe access

21:45 <re_irc> <@andresv:matrix.org> I could actually live with it. Thanks.

21:46 <re_irc> <@adamgreig:matrix.org> I don't think `MaybeUninit` would help here because the whole struct's presumably still going to go into `data`

21:46 <re_irc> <@adamgreig:matrix.org> seems like best bet is to make them their own object so they live in `bss`

21:49 <re_irc> <@andresv:matrix.org> Yes it was the same with `MaybeUninit`. Moving them out now.

22:17 <re_irc> <@jamesmunns:beeper.com> andres what's in the structs? I noticed that heapless mpmc queues are non zero on init, so i had to hack around that

22:21 <re_irc> <@jamesmunns:beeper.com> Here's the commit where I hacked up my library to use MaybeUninit: https://github.com/anachro-rs/powerbus/commit/1a048c22736f7eac7406f3007c0bda3321602722#diff-c7397132f9bc35eed80960875044c1368ba26f932355c09eb0ce78a9a7f74d81

23:42 <re_irc> <@davidarmstrongbarahonalewis:matrix.org> Hey all, would anyone here happen to be in the know around the state of `itmdump` and its use in the Discovery book? I was going about packaging up the tool for nixpkgs and it looks unmaintained. Just want to get chat with someone who knows the state of that part of the embedded learning resources :)

23:43 <re_irc> <@adamgreig:matrix.org> I expect we'll soon merge https://github.com/rust-embedded/itm/pull/41 which basically completely replaces the crate with a new, actively maintained, version

23:43 <re_irc> <@adamgreig:matrix.org> ( 👋 hi btw! I love how active nix users are at packaging rust stuff up for people!)

23:44 <re_irc> <@davidarmstrongbarahonalewis:matrix.org> Thanks for the reply! And cool! I'm guessing that means the relevant chapters of the Discovery book will need to be updated?

23:45 <re_irc> <@davidarmstrongbarahonalewis:matrix.org> (hi and thanks!)

23:46 <re_irc> <@adamgreig:matrix.org> yea, I think they will need to be, though the new version should be able to do pretty much the same thing

23:47 <re_irc> <@adamgreig:matrix.org> that said, we are _also_ expecting to release a new version of the discovery book soon, using a newer micro:bit development board, which doesn't use itm at all (since it's proven quite tricky for people to set up and use, and these days rtt and probe-rs-based tooling is very popular)

23:47 <re_irc> <@adamgreig:matrix.org> but the current version of the book will remain hosted and maintained

23:50 <re_irc> <@adamgreig:matrix.org> (https://github.com/rust-embedded/discovery/pull/414 for that)

23:51 <re_irc> <@davidarmstrongbarahonalewis:matrix.org> Ah, so `itmdump` 0.3.1 is still used by the original Discovery book, then?

23:52 <re_irc> <@adamgreig:matrix.org> yea, though that will need updating to talk about the new version of `itm`/`itmdump` once it's merged and released

23:58 <re_irc> <@davidarmstrongbarahonalewis:matrix.org> Reason I'm poking around is that there's some hesitation to package up `itmdump` in the official `nixpkgs` channel if it's not actively maintained. Until these releases are made, would it make sense to you to add a section in the Discovery book about getting `itmdump` installed on a Nix system? For reasons related to not following the traditional Linux Filesystem Heriarchy, doing something..

23:58 <re_irc> ... like `cargo install itmdump` can fail on a Nix system. Or would it make sense to assume that a NixOS user would generally know how to work around the issue?