<re_irc>
<@adamgreig:matrix.org> what sort of time of day would be helpful? having another timezone option would be great for a lot of the wg members that really can't make the current time
<re_irc>
<@adamgreig:matrix.org> could potentially alternate weeks or something too
fabic_ has joined #rust-embedded
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 268 seconds]
tokomak has joined #rust-embedded
zBeeble42 has joined #rust-embedded
zBeeble has quit [Remote host closed the connection]
Darius has quit [Ping timeout: 245 seconds]
Darius has joined #rust-embedded
fabic_ has quit [Ping timeout: 252 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 252 seconds]
<re_irc>
<@nihal.pasham:matrix.org> does `cargo-flash` support flashing to a user-provided base-address, something akin to what `pyocd` offers -
<re_irc>
<@nihal.pasham:matrix.org> yatekii: ok so we can do that with probe-rs the library (not probe-run), keep getting confused.
<re_irc>
<@yatekii:matrix.org> some folks wanted to add it to cargo flash and some were against it
<re_irc>
<@yatekii:matrix.org> we should def. add it to the cli tho
<re_irc>
<@nihal.pasham:matrix.org> yep, it would be quite helpful for at least recurring workflow (if you're in security). Signed images binaries and flashing them at pre-determined mem offsets for easy and automatable testing.
<re_irc>
<@adamgreig:matrix.org> nihal.pasham: It's also possible to just stick the .bin into a .elf with the address you want and then flash the .elf, which can be done with cargo-flash today
<re_irc>
<@nihal.pasham:matrix.org> the .bin was originally extracted from an elf for signing. So, rather than reassemble it back to elf, I decided to just flash them as-is (as I have 3 of them to be flashed into non-contiguous memory offsets)
<re_irc>
<@yatekii:matrix.org> also include the crates below for arm?
<re_irc>
<@yatekii:matrix.org> I feel like I miss something obvious
<re_irc>
<@yatekii:matrix.org> ohhh is this the cargo feature resolver again
<re_irc>
<@yatekii:matrix.org> hmm
<re_irc>
<@yatekii:matrix.org> (embedded-graphics-simulator = "0.3.0") pulls in std features
<re_irc>
<@dirbaio:matrix.org> always the resolver 🤣
<re_irc>
<@yatekii:matrix.org> the feature resolver is so annying for real
<re_irc>
<@yatekii:matrix.org> but I thought they fixed it
<re_irc>
<@yatekii:matrix.org> so maybe I just need to update :D
<re_irc>
<@dirbaio:matrix.org> you have resolver=2 in your cargo.toml?
<re_irc>
<@yatekii:matrix.org> ohhh
<re_irc>
<@yatekii:matrix.org> hmm where exactly do I put that
<re_irc>
<@yatekii:matrix.org> invalid type: integer `2`, expected a string for key `package.resolver`
<re_irc>
<@dirbaio:matrix.org> resolver="2"
<re_irc>
<@dirbaio:matrix.org> because numbers are strings, *obviously*
<re_irc>
<@yatekii:matrix.org> ah sorry, I forgot we are coding JS here
<re_irc>
<@yatekii:matrix.org> ok it *seems* to be working now. lets wait until it finished building :D
<re_irc>
<@dirbaio:matrix.org> resolver'2 will be the default in rust 2021... I can't wait
<re_irc>
<@yatekii:matrix.org> ok it's building now :)
<re_irc>
<@yatekii:matrix.org> awesome!
<re_irc>
<@yatekii:matrix.org> thanks
<re_irc>
<@yatekii:matrix.org> if I can fix rust-analyzer to show errors again I am happy ... it stopped like randomly 2 weeks ago lol ... I can use autocomplete and typeannotations and follow types etc, but no red lines lol
<re_irc>
<@yatekii:matrix.org> but hey, I am so happy with everything :) getting to run the display in the simulator? 5 minutes. and I am sure once it is wired up it just works
<re_irc>
<@yatekii:matrix.org> folks are doing such an amazing job :)
<re_irc>
<@htms:matrix.org> Noob question: Hi, I'm preparing to dive into embedded Rust and now looking at ecosystem. Does probe-rs work seamlessly with JetBrains IDEs (PyCharm Pro available) or I should just follow tutorials and use VSCode?
<re_irc>
<@yatekii:matrix.org> htms: probe-rs has only a alpha-stage vscode plugin for debugging. most folks use commandline utilities.
<re_irc>
<@yatekii:matrix.org> a plugin for jetbrains was impossible last time I checked (1year ago; so might have changed)
<re_irc>
<@korken89:matrix.org> With that said, using `cargo-embed` or `probe-run` with VSCode and their RTT based logging/printing utilities makes it really easy to work though
<re_irc>
<@korken89:matrix.org> Since I started Rust embedded I've almost never went back to a "GDB like" debugger
<re_irc>
<@korken89:matrix.org> I think it's really easy to use VSCode or Vim with Rust embedded :)
<re_irc>
<@yatekii:matrix.org> on a similar note: jack has been working eagerly on full RTT integratiuon with defmt and all in vscode-debugging :)
<re_irc>
<@yatekii:matrix.org> will try this weekend I guess
<re_irc>
<@burrbull:matrix.org> need update rust embedded book with tutorial of starting with probe-run/cargo-embed & vscode. Also need good modern project templates
troth has quit [Quit: Leaving.]
<re_irc>
<@richarddodd:matrix.org> burrbull: PRs welcome I think :)
fabic has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> PyCharm with the Rust Plugin is fantastic
<re_irc>
<@firefrommoonlight:matrix.org> It should work in a similar way with Clion etc
<re_irc>
<@firefrommoonlight:matrix.org> VSCode is OK for editing single files, but for mult-file pojects, the JetBrains Rust plugin has a much deeper refactoring / error catching / introspection
<re_irc>
<@firefrommoonlight:matrix.org> *Misread the question. No probe-rs interaction
<re_irc>
<@dirbaio:matrix.org> wut? vscode is great even for huge projects :P
<re_irc>
<@dirbaio:matrix.org> and rust-analyzer can also do very fancy refactors
<re_irc>
<@firefrommoonlight:matrix.org> How do you switch between files?
<re_irc>
<@dirbaio:matrix.org> you open an entire directory, you get a tree at the left
<re_irc>
<@firefrommoonlight:matrix.org> I'm legit curious - I hear so much about VsCode, but I can't get it to work in the way I'd expect, adn am legit not sure what's going on
<re_irc>
<@yatekii:matrix.org> firefrommoonlight: click on tab or ctrl + P
<re_irc>
<@firefrommoonlight:matrix.org> Not doing anything
<re_irc>
<@yatekii:matrix.org> do you have rust-analyzer installed?
<re_irc>
<@firefrommoonlight:matrix.org> Nope - that's probably it
<re_irc>
<@yatekii:matrix.org> yes
<re_irc>
<@yatekii:matrix.org> and it does not work in 100% of the cases as ofc sometimes it has troubles resolving everythign but that's the case with CLion too
<re_irc>
<@firefrommoonlight:matrix.org> Oh sweet it's working now. I'll experiment more. This is definitely a nice addition for one-off files
<re_irc>
<@firefrommoonlight:matrix.org> And makes it viable for projects
zBeeble42 has quit [Remote host closed the connection]
zBeeble has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
<re_irc>
<@newam:matrix.org> Anyone know of an STM32 HAL that has an RCC interface that support low-power shenanigans?
<re_irc>
<@newam:matrix.org> I am trying to think of a good way to design an interface for the STM32WL clocks where the user will need to setup the clocks many times.
<re_irc>
<@newam:matrix.org> (some) low power modes disable clocks on entry, and (some) low power modes have a different wakeup clock.
<re_irc>
<@firefrommoonlight:matrix.org> Yea
<re_irc>
<@firefrommoonlight:matrix.org> the one I built/use
<re_irc>
<@firefrommoonlight:matrix.org> Has some helper functions for re-setting up the PLL etc after stop or stby
<re_irc>
<@firefrommoonlight:matrix.org> Note that you'll still need some things in user code. Eg to make sure the PLL kicks back on at the right time if an ISR triggers
<re_irc>
<@firefrommoonlight:matrix.org> WL support is WIP
<re_irc>
<@firefrommoonlight:matrix.org> The stopwuk setting is in the clocks module
<re_irc>
<@firefrommoonlight:matrix.org> Re selecting the post-eakeup default clock
<re_irc>
<@firefrommoonlight:matrix.org> Bottom line: stop and standby revert the clock to HSI or MSI depending on variant, and that setting
<re_irc>
<@firefrommoonlight:matrix.org> If that's not your main operating clock, you need to make sure the right clock is setup in the ISR that wakes it
<re_irc>
<@firefrommoonlight:matrix.org> See the reselect_input function in the Clocks module
<re_irc>
<@firefrommoonlight:matrix.org> Also has a simple method that checks if the PLL is enabled
<re_irc>
<@firefrommoonlight:matrix.org> Are there any other consideration?
<re_irc>
<@newam:matrix.org> firefrommoonlight: I'm still reading; at first glance the only one I see is that some STM chips require firmware to turn off clocks before entering lprun (HSE32 needs to be off before entering lprun in the case of the STM32WL).
tokomak has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 258 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
darknighte has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Some considerations:
<re_irc>
<@firefrommoonlight:matrix.org> - Sleep mode is straightforward
<re_irc>
<@firefrommoonlight:matrix.org> - StopN modes if using HSI or MSI, require you set StockWuk correctly, and are otherwise straightforward. StopN and standby modes with PLL require re-selecting, enabling, and waiting-for PPL, as well as potentially re-enabling oscillators.
<re_irc>
<@firefrommoonlight:matrix.org> - LP run has special considerations, but generally requires lowering the clock speed before entering, and resetting what you want after exit
<re_irc>
<@firefrommoonlight:matrix.org> -H7 is quite differen't and I don't understand it
<re_irc>
<@firefrommoonlight:matrix.org> In my own code, in ISRs that could wake from a low-power mode, I first check if the PLL is running. If not, (Ie another ISR hasn't already woken), I run the PLL and oscillator re-setup code
<re_irc>
<@firefrommoonlight:matrix.org> STMs designed for low-power use often have an MSI, which makes it easy to change speed dynamically
<re_irc>
<@firefrommoonlight:matrix.org> and without an external oscillator