<re_irc>
<korken89> firefrommoonlight: Do you have a minimal example for this? I double-checked the codegen and "idle" does not have any code that I can find that could cause such behavior. Maybe you have tripped over something interesting
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<therealprof> riskable: If you want to print numbers there's a variety of options, you can use the standard formatting if you can anything implementing the "Write" trait (like an "e-h" Serial port), you can also use heapless to create a buffer on the stack you can use that on. Easy to do, somewhat expensive in terms of code size. There's also "ufmt" allowing you do formatting a bit cheaper. And then there're crates doing nothing...
<re_irc>
... else than integer-to-string fromatting like "itoa".
gsalazar has quit [Ping timeout: 260 seconds]
gsalazar has joined #rust-embedded
cr1901_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
gsalazar has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc>
<firefrommoonlight> korken89: Not sure yet! I'll post back once I sort it out. Will have to eventually
<re_irc>
<firefrommoonlight> -sure
<re_irc>
<caspinol> firefrommoonlight: I had some issues with RTIC recently when used the latest cortex-m and cortex-m-rt. I forgot which combination it was thoug. I had to roll back the cortex-m to earlier version. Sorry but i dont remeber which version was it
<re_irc>
<firefrommoonlight> Weird! I'll experiment with that. Of note, I'm using the same cortex-m and corte-m, cortex-m-rt, and rtic versions on a different project with no issue
<re_irc>
<firefrommoonlight> -corte-m,
<re_irc>
<firefrommoonlight> Could be the noop too??
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
<re_irc>
<firefrommoonlight> I uncommented the idle loop and it works now. So... No idea!!
<re_irc>
<firefrommoonlight> Gremlins from some combo of new board design, MCU not used often with Rust, and new code base??
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 260 seconds]
bjc has quit [Remote host closed the connection]
<re_irc>
<firefrommoonlight> Not sure I chose the correct LED resistor, but the 3v3 line definitely works
<re_irc>
<newam> What's the use case of having Not on never?
<re_irc>
<K900> Useful for when you're passing callbacks around and such
<re_irc>
<K900> "!" unifies with any named type
<re_irc>
<K900> But not "impl T"
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 248 seconds]
gsalazar has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 272 seconds]
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 268 seconds]
hwj has joined #rust-embedded
hwj has quit [Client Quit]
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 260 seconds]
<re_irc>
<Radu> Hello, I'm new in Rust and embedded, when we write code for embedded do we have those abstractions like map, sort, fold ...etc, or we have to write out own implementations of it?
<re_irc>
<Radu> * our
<re_irc>
<James Munns> Yup! Iterators are part of the "core" library, which means all of the methods for those are included!
<re_irc>
<riskable> dirbaio: I figured something out about this! I no longer have to flash my RP2040 board twice in order for it to actually flash. Here's what fixed it: I assigned a keyboard shortcut/macro in my code that ultimately calls "cortex_m::peripheral::SCB::sys_reset();"
<re_irc>
<riskable> I bet if you just "use cortex_m::peripheral::SCB;" and have "SCB::sys_reset()" _somewhere_ as a possible runtime call in your code that might fix it. I dunno though.
<re_irc>
<dirbaio> huh
<re_irc>
<dirbaio> so
<re_irc>
<dirbaio> flash, run, flash again -> fails
<re_irc>
<dirbaio> flash, run, have the firmware do a sys_reset, flash again -> works
<re_irc>
<dirbaio> ?
<re_irc>
<riskable> dirbaio: As long as my firmware is running with that "sys_reset()" somewhere I can flash it like normal without having to run "cargo run --release" twice
<re_irc>
<dirbaio> as long as the reset is actually run, right?
<re_irc>
<dirbaio> strange
<re_irc>
<dirbaio> I guess this means there's probably something we can do in probe-rs or the flash algo to fix it
<re_irc>
<riskable> dirbaio: I'm not even calling that function (unless I press the specific keystroke I've bound it to: More Fun->ESC)! It seems to fix the problem just by having it _somewhere_ (anywhere) in the code (can't get optimized out as an unused import)
<re_irc>
<dirbaio> whaaaat
<re_irc>
<riskable> dirbaio: EXACTLY! It makes no sense!
<re_irc>
<riskable> If I unbind that keystroke I have to go back to flashing twice
<re_irc>
<riskable> Wait: Let me try some things
<re_irc>
<riskable> I'm going to unbind the keystroke but "use" the full path to sys_reset()
<re_irc>
<riskable> Ugh, now it works fine! haha
<re_irc>
<riskable> Must've been some other change I made that fixed it
<re_irc>
<dirbaio>
<re_irc>
<riskable> dirbaio: Not only am I only flashing once now but I can actually reset my RP2040 without having the probe disconnect! Well, if I reset via "sys_reset()" (it still disconnects if I reset via the switch)
<re_irc>
<dirbaio> that's because "sys_reset()" is "instant", while the chip is deep-reset-fried for as long as you hold the button :P
<re_irc>
<9names (@9names:matrix.org)> Is this the spinlock problem? (spinlocks aren't released by reset, are used by RTT so everything locks up if it held the lock at reset time).
<re_irc>
But then how does the second reset fix it?