<re_irc>
<James Munns> firefrommoonlight: If you allow writing “live” memory, including program memory, id say it should be unsafe
<re_irc>
<James Munns> (That also includes any live “read” borrows)
<re_irc>
<willeml> So strange thing, I can only read the first 4 bytes of QSPI flash in memory mapped mode once, after reading the first 4 bytes again it fails, but only if I read the first 4 bytes (I can randomly read 1000 bytes and it's fine, unless one of those is the first 1)...
<re_irc>
<willeml> +Never mind, that only happened once, fluke, now it just always fail after stress test.
<re_irc>
<willeml> Any idea on why this happens? I have the cortex_m_rt::interrupt imported...
<re_irc>
<willeml> RTFM moment...
<re_irc>
<willeml> Although the interrupt I actually want does not seem to exist in the hal or pac crate...
<re_irc>
<9names (@9names:matrix.org)> Which interrupt are you looking for?
<re_irc>
<9names (@9names:matrix.org)> Typically multiple sources can trigger a single interrupt line, and it's up to the interrupt service routine to check registers to work out the interrupt source and clear it.
<re_irc>
<9names (@9names:matrix.org)> Just pre-empting your questions here: you normally get interrupt via the 'rt' feature of your PAC.
<re_irc>
<willeml> Actually, I guess the obvious answer is that the interrupt is not firing at all...
<re_irc>
<9names (@9names:matrix.org)> The other way that it often goes is that it's actually triggering continuously - you often need to clear the interrupt source before leaving your interrupt function
<re_irc>
<willeml> So either it's not going at all, or it's going too fast for probe-rs to read the prints? But wouldn't that cause probe-run to crash?
<re_irc>
<9names (@9names:matrix.org)> Turning on an led inside the interrupt is usually a safe bet for finding out if it's ever triggered
<re_irc>
<thejpster> Is it enabled in both the peripheral and the NVIC?
<re_irc>
<willeml> The NVIC? I have it enabled on the peripheral.
<re_irc>
<willeml> Switched to an LED, nothing happens, so I guess the interrupt is not firing
<re_irc>
<9names (@9names:matrix.org)> You need to enable generation (on the peripheral side) and unmask the IRQ handler (in the CPU core, on the NVIC)
<re_irc>
<willeml> "cortex_m::peripheral::NVIC::unmask(interrupt)" using this?
<re_irc>
<9names (@9names:matrix.org)> Yep
<re_irc>
<willeml> Ah ha! Now it works, LED turns blue.
<re_irc>
<willeml> I tried re-adding the print, and it does fire continuously. So I guess I need to clear the interrupt source?
<re_irc>
<willeml> Would "cortex_m::peripheral::NVIC::unpend(interrupt::QUADSPI)" do it?
<re_irc>
<willeml> No.
<re_irc>
<9names (@9names:matrix.org)> you need to clear it from the peripheral side
<re_irc>
<willeml> Oh, so change a bit in one of the QSPI registers then?
<re_irc>
<9names (@9names:matrix.org)> Yeah. Check which register the C HAL touches, it could be disabling the FIFO interrupt, emptying the FIFO, or clearing a status register.
<re_irc>
<willeml> It runs a function "__HAL_QSPI_DISABLE_IT" do you know if github has a built in file search? Or should I just clone and grep?
<re_irc>
<9names (@9names:matrix.org)> The procedure is different for each bit of hardware so you either have to read the reference manual for the chip or look through the vendor's examples or sdk
<re_irc>
<9names (@9names:matrix.org)> It does have a built-in function but clone and ripgrep does a better job
<re_irc>
<willeml> I should have done depth one... Already at half a gig downloaded...
<re_irc>
<willeml> So does "qspi.cr.ftie().set_bit()" need to be done to enable the interrupt? Or is that flag just there to say that the interrupt has been/should be fired ASAP while the NVIC unmask actually enables it?
<re_irc>
<willeml> (ftie being the enable control bit for the interrupt I want)
<re_irc>
<willeml> I guess that actually the interrupt is supposed to be enabled when a transfer is initiated (hard to do in memory mapped mode then...) and not just on chip init.
<re_irc>
<9names (@9names:matrix.org)> I would not expect you to want the interrupt in mapped mode - the controller should handle everything for you
<re_irc>
<willeml> Ah, guess something else must be wrong then, but supposedly memory mapped mode shouldn't even start to work if something is misconfigured...
<re_irc>
<willeml> Anyways I'm going to bed, thanks for the help! I had no idea on how to use interrupts before in Rust.
radens has quit [Quit: Connection closed for inactivity]
nort has quit [Ping timeout: 272 seconds]
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
<re_irc>
<ryan-summers> I'm trying to build a (fairly standard) crate with output type "cdylib" (as part of RTIC-scope'
<re_irc>
<ryan-summers> * RTIC-scope) but I'm getting a cc link error about an invalid VERSION file
<re_irc>
<ryan-summers> Anyone have any idea what that might be from? As far as I can tell, it's related specifically to "cdylib". If I just make it "lib" (and it generates an rlib) it works fine
<re_irc>
error: linking with `cc` failed: exit status: 1
<re_irc>
<ryan-summers> tmplt: Did you ever see this while working on rtic-scope?
<re_irc>
<ryan-summers> Ah interesting. It has to do with default-features on the PACs. My best guess is that the device/rt feature is being enabled somehow
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
tafama is now known as tafa
iyed has joined #rust-embedded
iyed has quit [Client Quit]
dc740 has joined #rust-embedded
aspe has joined #rust-embedded
<re_irc>
<James Munns> There's a "cargo tree" subcommand that shows you which features are activated by which reverse dep
<re_irc>
<James Munns> e.g. to see which reverse dep is causing which feature in "$CRATE", you would run (in the binary crate folder):
<re_irc>
cargo tree -e features -i $CRATE
<re_irc>
<James Munns> (I ran into this recently figuring out why a "std" feature was being enabled somewhere)
<re_irc>
<ryan-summers> Yeah, it was pretty easy to figure out based on the size, but the error code didn't really give me any info on what was going wrong
dc740 has quit [Remote host closed the connection]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
nort has joined #rust-embedded
<re_irc>
<bradleyharden> adamgreig or others, would it make sense to cut a release of bare_metal?
<re_irc>
<bradleyharden> Not many changes, but there have been some, and it's been several months
<re_irc>
<adamgreig> there was talk of adding a few more methods for dealing with wrapped rc iirc?
<re_irc>
<adamgreig> there's also talk of gutting it for critical-section but that doesn't need to impact a 1.1 with these new methods
causal has joined #rust-embedded
Socke has quit [Quit: WeeChat 3.5]
Socke has joined #rust-embedded
dc740 has joined #rust-embedded
aspe has quit [Quit: aspe]
aspe has joined #rust-embedded
aspe has quit [Read error: Connection reset by peer]
aspe has joined #rust-embedded
aspe has quit [Client Quit]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<cr1901>
I wonder if this observation is reasonable: the critical_section crate is the moral equivalent of #ifdef #elif #else #endif C preprocessor chains. But embedded Rust discourages these in favor of generics/traits.
<cr1901>
But critical_section is one case where it makes sense to do the #ifdef dance rather than punt to impl'ing a trait
<re_irc>
<dirbaio> it's more the equivalent of a ".h" file
<re_irc>
<dirbaio> where another crate supplies the implementation, the ".c" file
<re_irc>
<dirbaio> and the linker links everything together
<cr1901>
Ahhh
<re_irc>
<dirbaio> so any crate can go and use the ".h" directly, without generics
<re_irc>
<dirbaio> but if no one supplies the implementation, linking fails
<cr1901>
This is how I used to do cross-platform C code myself to avoid proliferation of ifdef crap
<cr1901>
I would have a function boundary where you would supply a platform-specific C file for the remaining functions
<re_irc>
<dirbaio> (c-s 0.2 does have ifdef for common archs, but it's gone in 0.3, the plan is for crates like cortex-m, riscv to supply the impl)
<cr1901>
I'll prob wait for 0.3 if it's not too far off
* cr1901
had a hard drive failure this week, and while everything was backed up, migrating is still a PITA
<cr1901>
Doing new embedded code is not on my mind this moment
<re_irc>
<dirbaio> :(
<cr1901>
Ahhh well, it was an old drive, and could be far worse lol. Two types of people: Those who lost data, those who will.
<cr1901>
I'm in the former, I learned my lesson 11 years ago
<re_irc>
<dirbaio> scary
<re_irc>
<dirbaio> and spinning rust sucks yeah
<re_irc>
<dirbaio> (or was it an SSD?)
<cr1901>
spinning rust. It was an older drive too, so I probably should've bought a new one
<cr1901>
Now using an SSD I was given as a gift that I was saving for a new build when this laptop dies
<cr1901>
But ahhh well, it's there, might as well use it