ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
emerent_ has joined #rust-embedded
emerent is now known as Guest7183
Guest7183 has quit [Killed ( (Nickname regained by services))]
emerent_ is now known as emerent
<re_irc> <kevlan> Does anyone know when the link to the CTCFT recording will be posted? It's still missing here
<re_irc> <adamgreig> it's up on
<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.
radens has joined #rust-embedded
<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 (> Which interrupt are you looking for?
<re_irc> <9names (> 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 (> Just pre-empting your questions here: you normally get interrupt via the 'rt' feature of your PAC.
<re_irc> Assuming you're targeting some variant of stm32f7 here: the interrupt handler you're looking for here is probably [QUADSPI] (
<re_irc> <willeml> Oh ok, so I would use the QUADSPI interrupt name. Strange thing is that when I set the interrupt like so
<re_irc> #[interrupt]
<re_irc> rprintln!("QSPI Threshold interrupt.");
<re_irc> fn QUADSPI() {
<re_irc> <willeml> Actually, I guess the obvious answer is that the interrupt is not firing at all...
<re_irc> <9names (> 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 (> 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 (> 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 (> 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 (> 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 (> 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 (> 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 (> 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> Oh, thank you, CR it is then
<re_irc> <willeml> So does "" 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 (> 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> <ryan-summers> Specifically, I get:
<re_irc> Compiling adhoc v0.1.0 (/home/ryan/cargo-rtic-trace-libadhoc)
<re_irc> // Large command
<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
<cr1901> I like James Munns' idea
<re_irc> <dirbaio> lol :D
<re_irc> <James Munns> huh, what?
<cr1901> Click my link
<re_irc> <James Munns> oh lol
<re_irc> <James Munns> :D
<cr1901> Things go spinny are cool. But so is a passive, quiet data protector.
<cr1901> dirbaio: Is there a timeline for 0.3 release?
<re_irc> <dirbaio> it's "done", it's just a matter of releasing it
<re_irc> <dirbaio> deciding what to do with bare-metal first maybe
<re_irc> <dirbaio> and transferring it to the WG github adamgreig )
<re_irc> <dirbaio> +(cc
<re_irc> <dirbaio> and then releasing cortex-m 0.8 supplying the impl:P
<re_irc> <dirbaio> * impl :P
<re_irc> <dirbaio> perhaps make it 1.0 instead of 0.3
<cr1901> Hmmm I better get the msp430 critical section port done at some point soon then
<cr1901> But this week is NOT the right week :P
vancz has quit []
vancz has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
gsalazar has quit [Ping timeout: 272 seconds]
dc740 has quit [Remote host closed the connection]