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​> Pinned a policy tweet to the rustembedded twitter (I tend to re-state these things periodically anyway):
neceve has quit [Ping timeout: 268 seconds]
<re_irc> <@r​icharddodd:m​> Teach a man to fish... :)
<re_irc> <@z​partacoos:m​> 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]( 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​> are you able to interrupt (ctrl-c) while it's hanging and see what code it's in?
<re_irc> <@a​damgreig:m​> 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​> (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​> uuuuugh I thought we killed all of these bad copy/paste impls 😭
<re_irc> <@s​irhcel:m​> 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​> sirhcel: could you link me to the hal please?
<re_irc> <@j​amesmunns:m​> If it has the old+bad delay impl, I will open a PR fix right now.
<re_irc> <@j​amesmunns:m​> I tried my best to find and squish them all a while back, but I bet I missed one.
<re_irc> <@j​amesmunns:m​>, right?
<re_irc> <@j​amesmunns:m​> hmmm, that uses the `stm32f3xx-hal` under the hood...
<re_irc> <@s​irhcel:m​> The current release of `stm32f3xx-hal` looks [like this]( and the next release is about to get [the following](
<re_irc> <@s​irhcel:m​> Yes, it does.
<re_irc> <@j​amesmunns:m​> Ah, looks good
<re_irc> <@j​amesmunns:m​> though that impl has an off-by-one error. I'll open up a PR
<re_irc> <@f​irefrommoonlight:m​> Nailed it
<re_irc> <@j​amesmunns:m​>
<re_irc> <@j​amesmunns:m​> (if there are any stm32f3 maintainers idling in here)
<re_irc> <@j​amesmunns:m​> but, the code that was already in there (with or without my fix) is the biggest difference.
<re_irc> <@s​irhcel:m​> Thank you jamesmunns
<re_irc> <@s​irhcel:m​> Works like a treat now. :)
<re_irc> <@s​irhcel:m​> 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​> 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​> 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​> 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​> I hope you could live with the shorter delays meanwhile.
<re_irc> <@z​partacoos:m​> Yes it's no problem
<re_irc> <@s​irhcel:m​> While looking into the delay issue i came across a [`_delay_us` in `cortex_m`]( 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​> 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​> 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​> maybe in some cases the HAL has a better understanding of the actual clock frequencies though
<re_irc> <@f​irefrommoonlight:m​> Hmmm... I'll look into this more and switch to it if it looks apt
<re_irc> <@f​irefrommoonlight:m​> I did end up implementing a EH delay based on timers, but don't see much use
<re_irc> <@a​damgreig:m​> 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​> the HAL could probably just wrap cortex_m's delay though and handle the frequency
<re_irc> <@f​irefrommoonlight:m​> Yea - that's how you'd have to do it I think
<re_irc> <@f​irefrommoonlight:m​> Would be a small internal change, but prevents wheel reinvention
<re_irc> <@l​achlansneff:m​> Are there any examples with using bluetooth with the nrf-rs crates?
<re_irc> <@f​irefrommoonlight:m​> Maybe this:
<re_irc> <@f​irefrommoonlight:m​> I wonder if there a softdevice example somewheres
<re_irc> <@f​irefrommoonlight:m​> I'd like to add an example for stm32wb as well
<re_irc> <@f​irefrommoonlight:m​> 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​> I think wb is designed to be used with special official BT software, but I haven't tried it
<re_irc> <@t​halesfragoso:m​> 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​>
rjframe has joined #rust-embedded
<re_irc> <@s​irhcel:m​> Thank you, that explains a lot. :)
<re_irc> <@s​irhcel:m​> 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​> Hey... So, I implemented that cortex-m wrapper:
<re_irc> <@f​irefrommoonlight:m​> I haven't confirmed it handles wraps correctly
<re_irc> <@f​irefrommoonlight:m​> 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​> You should be able to use the delay without importing EH
<re_irc> <@f​irefrommoonlight:m​> Otherwise, I'd delete my delay module intirely
<re_irc> <@f​irefrommoonlight:m​> 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​> Why you don't need a wrapper:
<re_irc> <@f​irefrommoonlight:m​> ```rust
<re_irc> <@f​irefrommoonlight:m​> delay = cortex_m::delay::Delay(cp.SYST, clock_cfg.systick())
<re_irc> <@f​irefrommoonlight:m​> I can't justify deleting my impl though until it's de-EHed
<re_irc> <@f​irefrommoonlight:m​> [Issue](
<re_irc> <@f​irefrommoonlight:m​> I've tested this new wrapper at 5 and 10s delays. works fine
<re_irc> <@f​irefrommoonlight:m​> (Ie the cortex-M delay doesn't need the wrap patch)
<re_irc> <@f​irefrommoonlight:m​> jamesmunns: Does the cortex-m delay loop correct to you?
<re_irc> <@j​amesmunns:m​> It looks very different
<re_irc> <@j​amesmunns:m​> I'm not sure if they're equivalent
<re_irc> <@j​amesmunns:m​> maybe two attempts to solve the same problem? Not sure.
<re_irc> <@f​irefrommoonlight:m​> Yea - I don't really understand the code myself
<re_irc> <@f​irefrommoonlight:m​> Works anecdotally though!
<re_irc> <@f​irefrommoonlight:m​> FYI I'd been using your code before
<re_irc> <@f​irefrommoonlight:m​> [PR](
<re_irc> <@f​irefrommoonlight:m​> I think [this]( may be how they're handling overflow