starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> Pinned a policy tweet to the rustembedded twitter (I tend to re-state these things periodically anyway): https://twitter.com/rustembedded/status/1403675307413065733
neceve has quit [Ping timeout: 268 seconds]
<re_irc> <@r​icharddodd:m​atrix.org> @dirbaio:matrix.org: Teach a man to fish... :)
<re_irc> <@z​partacoos:m​atrix.org> Hi, I'm going through the discovery embedded book and ran into a strange issue with the blinky example. All I did was try to increase the time to 5 seconds and now gdb just hangs. I wrote a comment on an existing [thread on github](https://github.com/rust-embedded/discovery/issues/295) to a similar issue. If...
<re_irc> ... you know how to fix this I'd really appreciate the help as I'm just getting started with embedded rust.
<re_irc> <@a​damgreig:m​atrix.org> are you able to interrupt (ctrl-c) while it's hanging and see what code it's in?
<re_irc> <@a​damgreig:m​atrix.org> it might be a bug/limitation of the delay function that it can't do very long delays, depending on how it's been implemented
<re_irc> <@a​damgreig:m​atrix.org> (for example, you could try `for _ in 0..10 { delay(500_u16) }` to get the same effect and see if that works)
<re_irc> <@j​amesmunns:m​atrix.org> @adamgreig:matrix.org: uuuuugh I thought we killed all of these bad copy/paste impls 😭
<re_irc> <@s​irhcel:m​atrix.org> zpartacoos: I could confirm your observation with the code i'm working on right now (for serial output). When using `delay_ms(5000u32)` my example hangs. According to the docs of the current git revision of the hal i'm working with, `delay_ms` is implemented using `delay_us` which should allow delays up to almost...
<re_irc> ... a minute.
<re_irc> <@j​amesmunns:m​atrix.org> sirhcel: could you link me to the hal please?
<re_irc> <@j​amesmunns:m​atrix.org> If it has the old+bad delay impl, I will open a PR fix right now.
<re_irc> <@j​amesmunns:m​atrix.org> I tried my best to find and squish them all a while back, but I bet I missed one.
<re_irc> <@j​amesmunns:m​atrix.org> https://github.com/rubberduck203/stm32f3-discovery, right?
<re_irc> <@j​amesmunns:m​atrix.org> hmmm, that uses the `stm32f3xx-hal` under the hood...
<re_irc> <@s​irhcel:m​atrix.org> The current release of `stm32f3xx-hal` looks [like this](https://docs.rs/stm32f3xx-hal/0.6.1/src/stm32f3xx_hal/delay.rs.html#49-63) and the next release is about to get [the following](https://github.com/Sh3Rm4n/stm32f3xx-hal/blob/bbe8d5a44d79f97dc5fe3bb916ed0f2ca7544688/src/delay.rs#L58).
<re_irc> <@s​irhcel:m​atrix.org> Yes, it does.
<re_irc> <@j​amesmunns:m​atrix.org> Ah, looks good
<re_irc> <@j​amesmunns:m​atrix.org> though that impl has an off-by-one error. I'll open up a PR
<re_irc> <@f​irefrommoonlight:m​atrix.org> Nailed it
<re_irc> <@j​amesmunns:m​atrix.org> https://github.com/stm32-rs/stm32f3xx-hal/pull/237
<re_irc> <@j​amesmunns:m​atrix.org> (if there are any stm32f3 maintainers idling in here)
<re_irc> <@j​amesmunns:m​atrix.org> but, the code that was already in there (with or without my fix) is the biggest difference.
<re_irc> <@s​irhcel:m​atrix.org> Thank you jamesmunns
<re_irc> <@s​irhcel:m​atrix.org> Works like a treat now. :)
<re_irc> <@s​irhcel:m​atrix.org> zpartacoos: There are several changes in the `stm32f3xx-hal` ahead which actually prevent you from using jamesmunns 's fixed hal directly from github. sh3rm4n works on getting a new release of the hal out soon (tm).
<re_irc> <@z​partacoos:m​atrix.org> Wow thank you all for the quick response. Just to confirm, sirhcel does that mean once the new hal is released this issue should be fixed?
<re_irc> <@s​irhcel:m​atrix.org> I'm working on getting the discovery examples updated for this new release. But we need the hal at first.
<re_irc> <@s​irhcel:m​atrix.org> @zpartacoos:matrix.org: You are welcome! :) I'm not a maintainer for the hal but I bet the fix will make it into the upcomming release.
<re_irc> <@s​irhcel:m​atrix.org> I hope you could live with the shorter delays meanwhile.
<re_irc> <@z​partacoos:m​atrix.org> Yes it's no problem
<re_irc> <@s​irhcel:m​atrix.org> While looking into the delay issue i came across a [`_delay_us` in `cortex_m`](https://github.com/rust-embedded/cortex-m/blob/1a4e09646aa37c3408d69fe4452265f405400593/src/delay.rs#L32). At a first glance, I don't see why not to use this implementation in hals for cortex-m mcus like the `stm32f3xx-hal`. Does...
<re_irc> ... anyone of you know, if there is a reason for that?
<re_irc> <@s​irhcel:m​atrix.org> In case it could be used independently of the actual cortex-m mcu: wouldn't this reduce the sources for potential issues with delays to one?
<re_irc> <@a​damgreig:m​atrix.org> yea, I think just cortex-m didn't have a delay impl at first, so hals had to do it themselves
<re_irc> <@a​damgreig:m​atrix.org> maybe in some cases the HAL has a better understanding of the actual clock frequencies though
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hmmm... I'll look into this more and switch to it if it looks apt
<re_irc> <@f​irefrommoonlight:m​atrix.org> I did end up implementing a EH delay based on timers, but don't see much use
<re_irc> <@a​damgreig:m​atrix.org> yea, you have to pass ahb_frequency into cortex_m::delay to make the delay source, whereas the HAL can get that from whatever it uses to manage timing
<re_irc> <@a​damgreig:m​atrix.org> the HAL could probably just wrap cortex_m's delay though and handle the frequency
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - that's how you'd have to do it I think
<re_irc> <@f​irefrommoonlight:m​atrix.org> Would be a small internal change, but prevents wheel reinvention
<re_irc> <@l​achlansneff:m​atrix.org> Are there any examples with using bluetooth with the nrf-rs crates?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Maybe this: https://github.com/jonas-schievink/rubble/tree/master/demos/nrf52-demo
<re_irc> <@f​irefrommoonlight:m​atrix.org> I wonder if there a softdevice example somewheres
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'd like to add an example for stm32wb as well
<re_irc> <@f​irefrommoonlight:m​atrix.org> The nrf manual has a decent section on its radio, but not much useful info for protocols impl. WB's radio section has little useful info
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think wb is designed to be used with special official BT software, but I haven't tried it
<re_irc> <@t​halesfragoso:m​atrix.org> Hmm, so I have some of those ssd1306 AliExpress modules, it has 2 0ohm resistors/jumpers on the back, does anyone happen to know which one is used to changed the address (if any) ?
<re_irc> <@d​irbaio:m​atrix.org> @lachlansneff:matrix.org: https://github.com/embassy-rs/nrf-softdevice
rjframe has joined #rust-embedded
<re_irc> <@s​irhcel:m​atrix.org> @adamgreig:matrix.org: Thank you, that explains a lot. :)
<re_irc> <@s​irhcel:m​atrix.org> @firefrommoonlight:matrix.org: The cortex-m implementation looks a bit different from the one @jamesmunns was writing his pr for. May be it needs some care too to support 32 bit values and wrapping around.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hey... So, I implemented that cortex-m wrapper: https://github.com/David-OConnor/stm32-hal/blob/main/src/delay.rs
<re_irc> <@f​irefrommoonlight:m​atrix.org> I haven't confirmed it handles wraps correctly
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think we can do 1-better: We really can skip it in HAL and direct users to use cortex_m::delay::Delay directly. However... it relies on EH traits, which I don't think is the way to go
<re_irc> <@f​irefrommoonlight:m​atrix.org> You should be able to use the delay without importing EH
<re_irc> <@f​irefrommoonlight:m​atrix.org> Otherwise, I'd delete my delay module intirely
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: Do you own that cortex_m? Thoughts on moving EH impl to bolt-on, as in the file I linked? If we do that, I'll delete that module entirely in HAL
<re_irc> <@f​irefrommoonlight:m​atrix.org> Why you don't need a wrapper:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> delay = cortex_m::delay::Delay(cp.SYST, clock_cfg.systick())
<re_irc> <@f​irefrommoonlight:m​atrix.org> I can't justify deleting my impl though until it's de-EHed
<re_irc> <@f​irefrommoonlight:m​atrix.org> [Issue](https://github.com/rust-embedded/cortex-m/issues/343)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've tested this new wrapper at 5 and 10s delays. works fine
<re_irc> <@f​irefrommoonlight:m​atrix.org> (Ie the cortex-M delay doesn't need the wrap patch)
<re_irc> <@f​irefrommoonlight:m​atrix.org> jamesmunns: Does the cortex-m delay loop correct to you? https://github.com/rust-embedded/cortex-m/blob/master/src/delay.rs#L32
<re_irc> <@j​amesmunns:m​atrix.org> It looks very different
<re_irc> <@j​amesmunns:m​atrix.org> I'm not sure if they're equivalent
<re_irc> <@j​amesmunns:m​atrix.org> maybe two attempts to solve the same problem? Not sure.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - I don't really understand the code myself
<re_irc> <@f​irefrommoonlight:m​atrix.org> Works anecdotally though!
<re_irc> <@f​irefrommoonlight:m​atrix.org> FYI I'd been using your code before
<re_irc> <@f​irefrommoonlight:m​atrix.org> [PR](https://github.com/rust-embedded/cortex-m/pull/344)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think [this](https://github.com/rust-embedded/cortex-m/blob/master/src/delay.rs#L59) may be how they're handling overflow