<thalesfragoso[m]> <dirbaio[m] "yes! useful for opendrain. you c"> g0 is better, they have bonded pins, so you can put both at output and drive one low the the other high, software smoke
<dirbaio[m]> set this pin high AND low please!!!
<adamgreig-m> lmao yea that is real galaxy brain shit
<adamgreig-m> they even advertise that you could set the pin high three times to get a lower impedance high
<dirbaio[m]> LOL
<thalesfragoso[m]> Also know as Higher in electrical engineering
<adamgreig-m> I'm sure verilog has a type for it
<dirbaio[m]> so what next
<dirbaio[m]> timers, exti..?
<thalesfragoso[m]> If you do timers we can do the "rtc"
<thalesfragoso[m]> Btw we should change this name so I can stop using " "
<dirbaio[m]> the metapac already has timers
<thalesfragoso[m]> Maybe do the yml with the addresses ?
<dirbaio[m]> yeah :\
<dirbaio[m]> that's gonna be fun
<dirbaio[m]> BTW the RCC mess could be simplified by making all the ahbXenr etc registers an array `[u32]` and removing all the field names
<dirbaio[m]> and storing the "enable bit number" in the peripheral yaml
<thalesfragoso[m]> You still have a lot of differences in PLL stuff
<thalesfragoso[m]> But that could help already
<dirbaio[m]> so to enable you just do `rcc.ahbenr(bit/32).modify(|w| w.set_enabled(bit%32, true))`
<dirbaio[m]> yeah but at least removes lots of cfg in the uart/spi/etc drivers that want to enable/disable themselves
<thalesfragoso[m]> Yeah, makes sense
<adamgreig-m> definitely don't call the collection ahbenr lol
<adamgreig-m> could you overlap them?
<dirbaio[m]> oh yeah you can totally overlap them
<adamgreig-m> that seems a bit less divergent
<thalesfragoso[m]> And make that bit number public, would you ? So it's easier and so we can use with bit-banding
<adamgreig-m> just have enr[..] and rstr[..], neat
<adamgreig-m> the bit numbers might even be fairly consistent between a single family at least
<thalesfragoso[m]> Hmm, how would you get the address of a register with your pac ?
<adamgreig-m> (and the reset bit number will probably always match the enable bit number)
<thalesfragoso[m]> To use with bb
<dirbaio[m]> <thalesfragoso[m] "Hmm, how would you get the addre"> you don't, not yet :(
<thalesfragoso[m]> <adamgreig-m "the bit numbers might even be fa"> My experience is that they are very consistent, at least the enables and resets
<dirbaio[m]> ah you mean of a reg
<thalesfragoso[m]> Within a family
<dirbaio[m]> the inner `*mut u8` is public
<thalesfragoso[m]> Isn't that the address of the whole block ?
<dirbaio[m]> for blocks yes, for Reg it's the register's
<adamgreig-m> yea, i'm not aware of any that are different, so hopefully it's easy
<dirbaio[m]> currently it's public so you do `.0`
<thalesfragoso[m]> <dirbaio[m] "for blocks yes, for Reg it's the"> So, `rcc.ahbenr.0` ?
<dirbaio[m]> maybe it's better to do `.as_ptr()`, `.from_ptr()` ?
<dirbaio[m]> `rcc.ahbenr().0`
<dirbaio[m]> I think the `.0` thing is ugly
<thalesfragoso[m]> I don't care much, but `.as_ptr()` isn't a bad idea
<dirbaio[m]> also full-blown methods are harder to miss in the docs
<firefrommoonligh> Re GPIO disabling. As agg said, Analog is the default state. And if you want to save power, you have to kill the whole port
<firefrommoonligh> Good to know it's teh lowest power state too
<firefrommoonligh> I think the point is to "reduce parasitic power draw" or something
<firefrommoonligh> (ie ADCs and DACs will still work if the pin is not configured as analog)
<adamgreig-m> the DAC only works if the pin is configured as analogue aiui, I don't think the analogue output path is enabled otherwise
<adamgreig-m> not completely sure though
<firefrommoonligh> gotcha
<adamgreig-m> I think the power reduction entirely comes from turning off the schmitt trigger at the input, so that it no longer uses power every time the voltage crosses its threshold
<adamgreig-m> makes sense in sleep modes though I guess, even if it's a tiny difference you're playing with nA there
<adamgreig-m> which parts were you looking at with analog as the default state?
<adamgreig-m> I thought most of the F parts had input-floating as default but this l4 is clearly analog default
<firefrommoonligh> Related: Do you need to kill teh various RCC clocks to save the most power during stop mode? Or will stop do that for you? Documentation on stop isn't clear on that pt
<adamgreig-m> in general no, in STOP mode all clocks arestopped
<firefrommoonligh> H7 is analog default too
<adamgreig-m> in sleep mode you would need to control which clocks are running, but various stm32s have SMENR bits for controlling that
<firefrommoonligh> So is L5
<adamgreig-m> in standby mode all clocks are off too
<adamgreig-m> I guess they changed the default with the newer parts then
<firefrommoonligh> Awesome; thanks for teh Stop wisdom. Wasn't sure if I needed to add a "disable_clocks" fn or something to run with it
<adamgreig-m> worth checking the RM for the specific chips you care but but generally: sleep = core stopped, peripherals on, stop = all clocks off, standby = also no power to cpu domain, SRAM is lost
<firefrommoonligh> It looks like F4 resets to input, but everything else I've seen resetes to analog
<firefrommoonligh> F3 is Input too i guess
<adamgreig-m> maybe just all the F series
<adamgreig-m> F1 has a different GPIO anyway
<dirbaio[m]> what things do we want in the per-chip yaml?
<firefrommoonligh> Guess so
<firefrommoonligh> I think on some MCUs there's a way to retain part of SRAM during stby mode.PWR.crx.rss bit or something for SRAM2 on L4 and maybe others
<firefrommoonligh> * I think on some MCUs there's a way to retain part of SRAM during stby mode. PWR.crx.rss bit or something for SRAM2 on L4 and maybe others
<adamgreig-m> there's also usually some 'backup' sram that (optionally) retains power
<dirbaio[m]> depending on the svd, which peripheral has which interrupt seems completely random :o
<dirbaio[m]> f401 has GPIOA -> TIM2, GPIOB -> TIM1_TRG_COM_TIM11, etc
<dirbaio[m]> wtf
tonke[m] has joined ##stm32-rs
<tonke[m]> Hi, I'm currently in the progress of moving a project from the f1xx crate to the f4xx crate. I struggle with the pwm, as I can't find a way to change the period. I'm I correct that it is not possible at the moment due to a lack of a Pwm trait (not PwmPin) implementation?
<tonke[m]> * Hi, I'm currently in the progress of moving a project from the f1xx crate to the f4xx crate. I struggle with the pwm, as I can't find a way to change the period. is it correct that it is not possible at the moment due to a lack of a Pwm trait (not PwmPin) implementation?
<tonke[m]> * Hi, I'm currently in the progress of moving a project from the f1xx crate to the f4xx crate. I struggle with the pwm, as I can't find a way to change the period. Is it correct that it is not possible at the moment due to a lack of a Pwm trait (not PwmPin) implementation?
<henrik_alser[m]> Do you mean you want to update the period on the fly?
<tonke[m]> <henrik_alser[m] "Do you mean you want to update t"> Exactly, I was previously doing that using the (try_)set_period method of the Pwm trait of embedded_hal
<henrik_alser[m]> Ahh! No it’s not yet implemented in the f4 hal afaik...
<tonke[m]> <henrik_alser[m] "Ahh! No it’s not yet implemented"> Okay, thanks for the confirmation. If there is no other workaround I might look into that myself :)
<henrik_alser[m]> Should be a straight forward addition, you can look at how the prescaler and auto reload registers are set in the initialization and add these functions and make a PR :)
<henrik_alser[m]> If you don’t wanna mess with unsafe access using raw pointers in your app 💀
<tonke[m]> To me (as a user) it seems like there is a noticeable amount of redundant work in the different stm32 device family crates, is there an effort to maybe share common implementations in a crate? Or is it not like it seems and the amount of redundancy is not significant?
<ryan-summers[m]> It's a very common theme brought up in this chat, and there's a number of efforts underway, but I don't know if anything will ever come of some "globalized stm32 HAL"
<ryan-summers[m]> There's just so many families and silicon versions that ST has released floating out there over the last decade that it would be an immense undertaking to develop and support
<tonke[m]> ok, that makes sens, is there a tracking issue to follow?
<tonke[m]> * ok, that makes sense, is there a tracking issue to follow?
<ryan-summers[m]> No, as I don't think that there's a unified `rust-embedded` effort underway - it's largely just some people seeing if they can get something going. The `rust-embedded` approach is the current stm32XXX-hal ecosystem.
<ryan-summers[m]> For reference though, take a look at the most recent https://crates.io/crates/stm32-hal2
<ryan-summers[m]> Which (I think?) firefrommoonlight is working on?
<ryan-summers[m]> Or maybe I tagged the totally wrong person. I don't remember anymore
<dirbaio[m]> yeah it's him
<dirbaio[m]> I don't buy the "massive undertaking" argument though, stm32-rs is the only opensource project out there that copypastes everything per-family
<ryan-summers[m]> The "massive undertaking" arises when you try to maintain all the workarounds for individual device quirks and errata imo
<ryan-summers[m]> That's not to say that the general design couldn't benefit from reuse a bit though
<wallacejohn[m]> dirbaio: It's definitely a bigger undertaking than it appears at first sight.
<dirbaio[m]> yeah but getting all stm32-rs hals to support everything is also a massive undertaking
<dirbaio[m]> especially when the hals themselves are diverging, on top of actual hw differences
<firefrommoonligh> @tonke see the set_freq fn, and enter 1/period
<firefrommoonligh> So the syntax is `my_timer.set_freq(1/period)`
<firefrommoonligh> IMO the issue you brought up is more due to small community/not much free time/maintainers being roadblocks than technically
<firefrommoonligh> I tried for a long time to fix the existing HALs, but couldn't get PRserged or issues addressed
<tonke[m]> <firefrommoonligh "So the syntax is `my_timer.set_f"> Uh, thanks for the hint, I will try that in a minute!
<tonke[m]> <firefrommoonligh "@tonke see the set_freq fn, and "> can you point me to the documentation?
<tonke[m]> Oh I see, in the new hal. I think it does not yet provide everything I need for the f4, but I will keep it in mind. Thanks!
<firefrommoonligh> What do you need specific ally?
<tonke[m]> <firefrommoonligh "What do you need specific ally?"> pwm, countdowntimer, monotimer, spi, usart (the last one is not yet supported for the F4 according to the errata)
<xoviat[m]> tonke: do you have an spi dma example for f4?
<tonke[m]> <xoviat[m] "tonke: do you have an spi dma ex"> no, sorry, I just use it via device crates not in dma mode
<firefrommoonligh> PWM, countdowntimer and spi are implemented. USARt and monotimer (Not familiar with that) aren't
<firefrommoonligh> Just added a PWM setup fn taht combines what was prev a combo of setup steps
<firefrommoonligh> Looking for thoughts on this API to enable PWM:
<firefrommoonligh> ```rust
<firefrommoonligh> timer.enable_pwm_output(Channel::One, OutputCompare::Pwm1, CountDir::Up, 0.5);
<firefrommoonligh> ```
<firefrommoonligh> With a similar API for PWM input. Might add more advanced configs like center-aligned, combined, assymetric etc later
<tonke[m]> I've just noticed the commit :)
<firefrommoonligh> This might not work for F4 on that lib yet
<firefrommoonligh> Dont' remember if I impled it
<firefrommoonligh> *nvm, should work
<tonke[m]> I will going to give it a try in the next days, I could skip the usart part for now (it's not a critical component, just interfacing a Bluetooth module to send data to a smartphone)
<tonke[m]> Thanks for your awesome work, it looks really promising!
<firefrommoonligh> I need to add USART; it's a big missing feature
<firefrommoonligh> Thx; mainly using for my own projects, but will keep updating the repo
<tonke[m]> I will post you feedback as soon as I've tried it, looking forward to it!
<firefrommoonligh> Great. Open to suggestions / fixes / feature suggestions etc