patrickod has joined #rust-embedded
dcz_ has quit [Ping timeout: 256 seconds]
jackneilll has quit [Quit: Leaving]
jackneill has joined #rust-embedded
troth has quit [Ping timeout: 240 seconds]
troth has joined #rust-embedded
fabic has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
PyroPeter has quit [Ping timeout: 245 seconds]
nohit has quit [Ping timeout: 264 seconds]
PyroPeter has joined #rust-embedded
nohit has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
richardeoin has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
x56 has quit [*.net *.split]
GenTooMan has joined #rust-embedded
richardeoin has joined #rust-embedded
x56 has joined #rust-embedded
dkm has quit [*.net *.split]
dkm has joined #rust-embedded
richardeoin has quit [Ping timeout: 256 seconds]
richardeoin has joined #rust-embedded
radens has joined #rust-embedded
fabic has joined #rust-embedded
cpk has joined #rust-embedded
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <> Hello! I submitted pull request to this repository:
dcz_ has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <> mdnj: You mean a rust `const`? That's fine. After your code has been compiled it doesn't even exist anymore
<re_irc> <> Has anyone ever looked at Renode ( for CI testing?
<re_irc> <> Sorry, completely missed this one. Merged!
fabic has quit [Quit: Leaving]
<re_irc> <> 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.
sauce has quit [Read error: Connection reset by peer]
sauce has joined #rust-embedded
<re_irc> <> If you're using RTIC, the `init` function runs with interrupts disabled
<re_irc> <> you'll generally need to (manually) clear the event flag that caused the interrupt at the start/end of each interrupt call.
<re_irc> <> I'm not
<re_irc> <> 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.
<re_irc> <> Trying to pinpoint if it's something else, currently, but I thought there may be some general pointers.
<re_irc> <> I would check to see if your ISR is actually getting called, or if instead you're hitting a default handler?
<re_irc> <> It's possible the file isn't getting included in the build
<re_irc> <> Do you have a `mod <file>` in your `` file?
<re_irc> <> Yeah. I put in an rprintln inside of it and it gets called, but it never returns to the main loop
<re_irc> <> Would be more helpful if you posted a minimal snippet for us to look up e.g. via a github gist
<re_irc> <> Yeah, I know. Sorry. I'm working on it.
<re_irc> <> No worries :)
<re_irc> <> Cleaning it all up reveals that that theory was a dead end, apparently. Maybe I'm doing something wrong during initialisation of other peripherals.. 🤔
<re_irc> <> 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
<re_irc> <> 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
<re_irc> <> tried it to experiment with beaglev stuff. real sketch experience on linux with mono. windows experience likely much better
<re_irc> <> Are you clearing the flag in the timer's ISR?
<re_irc> <> 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. ^^'
<re_irc> <> Don't know how I didn't notice it while debugging
<re_irc> <> Hah
<re_irc> <> I do stuff like that all the time
cpk has quit [Ping timeout: 252 seconds]
cpk has joined #rust-embedded
cpk has quit [Ping timeout: 264 seconds]
<re_irc> <> 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;```
<re_irc> <> Very unlikely to ever matter
<re_irc> <> It's compile time constant, so I think it would be better to use const, but why just not let s..
<re_irc> <> LLVM is smart enough to optimize that to the same code
<re_irc> <> yeah, I think It should do it but does const doesn't look kinda strange in code?
<re_irc> <> Not really?
<re_irc> <> Why do you think it's strange?
<re_irc> <> I mean in C it's normal but in Rust, shall I just const for really constants I mean value of PI etc.
<re_irc> <> I'm asking for advice, what it is more popular.
<re_irc> <> Using `const` for constant values is totally fine
<re_irc> <> Even if they're not fundamental constants
<re_irc> <> thanks then :)
<re_irc> <> `const` in Rust is sort of like `#define` in C: It basically gets pasted everywhere it is used
<re_irc> <> Interestingly that's how I expect const to work in every language but that's not always the case
PyroPeter has quit [Ping timeout: 265 seconds]
fooker has quit [Ping timeout: 265 seconds]
x56 has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
x56 has joined #rust-embedded
fooker has joined #rust-embedded
<cr1901> Not all languages want to require parsing/evaluating the entire language when determining a constant value :)
cpk has joined #rust-embedded
cpk has quit [Client Quit]
sauce has quit [*.net *.split]
radens has quit [*.net *.split]
edm has quit [*.net *.split]
hifi has quit [*.net *.split]
inara` has quit [*.net *.split]
kehvo has quit [*.net *.split]
creich has quit [*.net *.split]
Rahix has quit [*.net *.split]
Shell has quit [*.net *.split]
Ekho has quit [*.net *.split]
cyrozap has quit [*.net *.split]
bpye has quit [*.net *.split]
jasperw has quit [*.net *.split]
<re_irc> <> inline-asm FCP finished :D
<re_irc> <> 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.
<re_irc> <> What can be done here?
<re_irc> <> if those buffers are `static` they go into `rodata` and live in flash forever
<re_irc> <> if they are `static mut` or you put them on the stack, they have to live in RAM
<re_irc> <> (more or less: `static`s that contain interior mutability will _also_ go into ram)
<re_irc> <> oh, right
<re_irc> <> if they are zeroed, they also don't go into flash, they are only put into `bss` in RAM
<re_irc> <> They are in a struct that is initialized in RTIC 0.5.
<re_irc> <> 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?
<re_irc> <> yes
hifi has joined #rust-embedded
inara` has joined #rust-embedded
radens has joined #rust-embedded
creich has joined #rust-embedded
Rahix has joined #rust-embedded
sauce has joined #rust-embedded
cyrozap has joined #rust-embedded
Ekho has joined #rust-embedded
kehvo has joined #rust-embedded
Shell has joined #rust-embedded
edm has joined #rust-embedded
bpye has joined #rust-embedded
jasperw has joined #rust-embedded
<re_irc> <> that is the case
<re_irc> <> might be better asked in , hmm
<re_irc> <> 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
<re_irc> <> I could actually live with it. Thanks.
<re_irc> <> I don't think `MaybeUninit` would help here because the whole struct's presumably still going to go into `data`
<re_irc> <> seems like best bet is to make them their own object so they live in `bss`
<re_irc> <> Yes it was the same with `MaybeUninit`. Moving them out now.
dcz_ has quit [Ping timeout: 252 seconds]
<re_irc> <> andres what's in the structs? I noticed that heapless mpmc queues are non zero on init, so i had to hack around that
jackneilll has joined #rust-embedded
jackneill has quit [Ping timeout: 245 seconds]
<re_irc> <> 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 :)
<re_irc> <> I expect we'll soon merge which basically completely replaces the crate with a new, actively maintained, version
<re_irc> <> ( 👋 hi btw! I love how active nix users are at packaging rust stuff up for people!)
<re_irc> <> Thanks for the reply! And cool! I'm guessing that means the relevant chapters of the Discovery book will need to be updated?
<re_irc> <> (hi and thanks!)
<re_irc> <> yea, I think they will need to be, though the new version should be able to do pretty much the same thing
<re_irc> <> 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)
<re_irc> <> but the current version of the book will remain hosted and maintained
<re_irc> <> ( for that)
<re_irc> <> Ah, so `itmdump` 0.3.1 is still used by the original Discovery book, then?
<re_irc> <> yea, though that will need updating to talk about the new version of `itm`/`itmdump` once it's merged and released
<re_irc> <> 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..
<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?