smach has quit [Quit: Leaving]
rardiol has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
rektide has quit [Ping timeout: 250 seconds]
rektide has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
hwj has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <> Hi. I'm looking for a simple way to track elapsed time using hopefully systick on cortex-m, something similar to millis() on arduino. does anyone have any tips? doesn't need to be perfect.
starblue has quit [Ping timeout: 256 seconds]
<re_irc> <> You can use a simple timer module I would think.
<re_irc> <> Start/Stop and capture value.
<re_irc> <> Not sure if there is a high level function though.
<re_irc> <> gauteh: What device are you using? Are you using rtic?
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 252 seconds]
jringstad__ has quit [Quit: Leaving]
Amadiro has joined #rust-embedded
<re_irc> <> How long is the time you're tracking?
rardiol has joined #rust-embedded
<re_irc> <> any analysis I can run to figure out what's eating my stack? Running out of memory and not *quite* sure why.
<re_irc> <> (using RTIC fwiw)
<re_irc> <> dngrs (spookyvisiongithub):
<re_irc> <> thx!
<re_irc> <> And probe-run with —measure-stack
<re_irc> <> `stack-sizes` looks awesome and exactly what I need. Will also try `probe-run`
<re_irc> <> Can be useful
<re_irc> <> Have fun!
hwj has quit [Remote host closed the connection]
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
starblue has joined #rust-embedded
<re_irc> <> Hello rustaceans, my name is Jonas and I'm totally stoked by rust in the embedded context
<re_irc> <> I want to get up to speed and have decided to jump in at the deep end: A controller for a little rover-thingy based on the nRF52832. The rover part should be straight-forward, but I also want to integrate the Nordic SoftDevice for BLE connectivity. I also want to use RTIC because it's awesome. Do you think this is feasible?
<re_irc> <> it sounds like you already have a decent amount of embedded experience?
<re_irc> <> definitely sounds feasible! check out and maybe join
<re_irc> <> and is probably a good place to ask about the softdevice part (it's part of that project, but as I understand it you should be fine to use it with rtic too)
<re_irc> <> dngrs (spookyvisiongithub): Yes, on different MCUs, using different tooling, working with different communication stacks and of course not using rust. What could go wrong? :D
<re_irc> <> you're probably good to go, depending on your level of Rust knowledge :) I'm not intimately familiar with Nordic (used them only a few times) but one caveat to look out for on STM32 is that it's sometimes quite hard to find good documentation/HOWTOs for things that aren't yet available in Rust HALs/crates, since most people use the CubeMX HAL and that's an abstraction that will get you...
<re_irc> ... exactly nowhere in Rust
<re_irc> <> and/or articles will assume you've already memorized the entire reference manual
<re_irc> <> adamgreig: Saw those crates, I too think I have to go the "low level" of only basic wrappers for the SoftDevice. Will definitely check out the chatrooms!
<re_irc> <> perhaps I should have linked to, there's a high-level API
<re_irc> <> dngrs (spookyvisiongithub): I'm not very confident in regards to rust, but have always got myself unstuck. Yes I have used CubeMX stuff and was nervous concerning clock tree configurations in rust. Well there is no clock tree to speak of on the nRF52.
<re_irc> <> adamgreig: I judged getting an async library to work with RTIC will be too much trouble. Wouldn't even know where to start 🥴
<re_irc> <> I haven't tried it, but I think running a simple async executor in the RTIC idle task is quite popular and perhaps straightforward, possibly easier than using the low-level softdevice interface yourself?
<re_irc> <> possibly like, though I don't know if there's some reason that would or wouldn't work with nrf-softdevice
<re_irc> <> AFAIK, the best support for BLE on nRF in Rust is embassy. So, it may be worth trying to get it working
<re_irc> <> I think all the BLE support is inside nrf-softdevice, though?
<re_irc> <> Good pt
<re_irc> <> I think getting some hands-on experience with the SoftDevice is a good idea anyways
<re_irc> <> I should probably just learn it instead of relying on high level interfaces
<re_irc> <> It would be nice to have a high level API for SoftDevice not coupled to a framework though
<re_irc> <> Is anyone here working on a BLE project?
<re_irc> <> I'm not, but it would be nice should the use case arise in a future proj
<re_irc> <> (I'm going to add BT audio to a WIP project, but from what I gather, BLE is unsuitable for high quality audio; normal BT is the better choice)
<re_irc> <> If anyone has a non LE BT module they recommend btw, I'm all ears. Ideally something that can connect via I2S etc
<re_irc> <> nrf-softdevice _is_ that high-level API not coupled to a framework, I believe
<re_irc> <> Oh. I should just learn it
<re_irc> <> nrf-softdevice requires only async itself, it can run on any executor
<re_irc> <> if you care about low-power use embassy's though
<cr1901> Can someone help me merge this? Idk what bors wants
<cr1901> cc: adamgreig maybe you can help?
<cr1901> dirbaio: Tyvm
<cr1901> Guess I better take some time to figure out how bors actually works :/
<re_irc> <> it waits for the statuses in `status` to pass, then merges
<re_irc> <> travis is gone, so I guess you'd have to port the CI scripts to github actions, then update `status` in bors.toml to make it wait for that
<cr1901> Can I disable bors so I can merge?
<cr1901> I have admin rights on the repo, I just don't know how to disable bors for the time being so I can merge
<re_irc> <> you can disable enforcing bors in settings -> branches -> branch protection
<cr1901> dirbaio: Tyvm, that'll do as a stopgap for now
<re_irc> <> if you have admin rights you can just click merge on the PR, right?
<re_irc> <> or maybe you just need to disable branch protection also applying to admins
<cr1901> It was greyed out until I removed branch protection using bors
<re_irc> <> turning it off entirely seems fine too until CI is fixed, anyway
<cr1901> Yea, I'll have to set aside time for that. But this weekend is bad for that