ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
causal has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest8929
Guest8929 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
dc740 has joined #rust-embedded
causal has quit [Quit: WeeChat 3.6]
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #rust-embedded
<re_irc> <@kristoff:c.krbonne.net> Hi all, Can somebody help a newbie with my first rust program on a STM32F4-discovery board?
<re_irc> I want to make 'blinky' using the timer-delay function of cortex_m.
<re_irc> let mut d = cortex_m::delay::Delay::new(cp.SYST, 8_000_000);
<re_irc> I have this:
<re_irc> <@kristoff:c.krbonne.net> The "8_000_000" in the delay is the speed of the AHB bus.
<re_irc> So I like to find a way to know the speed of that bus.
<re_irc> let Some(p) = stm32::Peripherals::take()
<re_irc> I have this code:
<re_irc> <@kristoff:c.krbonne.net> But in this code, "hclfreq" is of the type "Herz" .. while I need a u32 value for the creation of the delay object
<re_irc> <@kristoff:c.krbonne.net> * "Hertz"
<re_irc> <@kristoff:c.krbonne.net> is there a way to convert a "herz" variable to a "u32", .. or am I using the wrong function to get the configured speed of the AHB bus?
<re_irc> <@kristoff:c.krbonne.net> * "hertz"
<re_irc> <therealprof> @kristoff:c.krbonne.net: That sounds off. That frequency should be the clock frequency of the internal clock of the SYSCTL peripheral which is implementation dependent as far as I'm aware.
<re_irc> <therealprof> Anyway, newer versions of the HAL are using "fugit" for timing functionality... You should be able to call https://docs.rs/fugit/0.3.6/fugit/struct.Rate.html#method.to_Hz to turn it into a "u32" with the frequency.
<re_irc> <@kristoff:c.krbonne.net> Thanks ... i'll look into that crate
<re_irc> <burrbull> why are you using delay from cortex_m? use delay from hal
<re_irc> <@kristoff:c.krbonne.net> burrbull: because that is what I found in the example-code :-)
<re_irc> If there is a better, more standard way to do delay, I am intertested to know
gsalazar has joined #rust-embedded
<re_irc> <@kristoff:c.krbonne.net> Do you mean I should use
<re_irc> "board::hal::delay::Delay::new() " ?
<re_irc> <@kristoff:c.krbonne.net> I need two parameters, SYST and clocks
<re_irc> <@kristoff:c.krbonne.net> I guess clocks is rcc.cfgr.freeze()
<re_irc> <@kristoff:c.krbonne.net> but where do I get SYST ?
<re_irc> <@kristoff:c.krbonne.net> Do you mean I should use
<re_irc> "d = board::hal::delay::Delay::new(SYST, clocks) " ?
Shell is now known as Shellhound
<re_irc> <burrbull> @kristoff:c.krbonne.net: p.SYST
<re_irc> <@kristoff:c.krbonne.net> yep .. just found it ... :-)
<re_irc> Wouhou .. I have a blinking LED!
<re_irc> YES! :-)
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
<re_irc> <firefrommoonlight> burrbull: I disagree
<re_irc> <firefrommoonlight> It's academic, but a systick delay uses a cortex m peripheral, so it makes sense to use it from that lib
<re_irc> <firefrommoonlight> The HALs that duplicate it have historically included various errors; may or may not be fixed
gsalazar has quit [Ping timeout: 252 seconds]
<re_irc> <explodingwaffle101> curious if anyone knows why this is a limitation? https://doc.rust-lang.org/error-index.html#E0436 i don't see why not
<re_irc> <dirbaio> what would that do if "c" is another enum variant?
<re_irc> <explodingwaffle101> ...totally right. for some reason i thought it did work with structs, but no https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=48ee90aee33fb6c999cd314779361c35
<re_irc> i guess it could just look at the names of the remaining fields, but i guess that would be weird
<re_irc> <dirbaio> yea it has to be the exact same type..
<re_irc> <dirbaio> and for enums it'd have to be the same variant, which you can't guarantee at compile time...
<re_irc> <dirbaio> struct-like enum variants are super annoying, they're "almost like structs" but not really
<re_irc> <dirbaio> I always end up doing a real separate struct :S
<re_irc> <dirbaio> there was some discussion about making enum variants "real" types iirc, so you could have a variable of type "PublicationFrequency" (the whole enum) or type "PublicationFrequency::SemiMonthly" (the struct for that variant) for example
<re_irc> <dirbaio> that'd allow using the "..c" syntax ;D
<re_irc> <explodingwaffle101> yeah i saw. i imagine that'd be a lot of effort though.
<re_irc> <explodingwaffle101> isn't there still the compile time issue there?
<re_irc> <dirbaio> dunno
<re_irc> <dirbaio> seems like it should be possible to get that to compile fast
<re_irc> <explodingwaffle101> dirbaio: oh uh i meant knowing the type _at_ compile time 😅 sry
<re_irc> <dirbaio> if there's separate types for each variant, dunno why not
<re_irc> <@kristoff:c.krbonne.net> Hi all, I have this error:
<re_irc> <@kristoff:c.krbonne.net> in the interrupt part, he says he cannot find 'EXTI'
<re_irc> <@kristoff:c.krbonne.net> he says I should import it
<re_irc> <@kristoff:c.krbonne.net> but I do import it (see some line above)
<re_irc> <@kristoff:c.krbonne.net> he says I should "use" it
<re_irc> <dirbaio> import the "interrupt" macro with "use stm32f407g_disc::stm32::interrupt;"
<re_irc> <@kristoff:c.krbonne.net> and for the "use stm32f407g_disc::EXTI0;" he says it is not use
<re_irc> <dirbaio> not from somewhere else like "cortex_m_rt::interrupt"
<re_irc> <@kristoff:c.krbonne.net> ah ok ... I'll try
<re_irc> <dirbaio> it's a very cursed side effect of how the "#[interrupt]" macro works, you have to import it from the PAC so that it can find the interrupt names
dc740 has quit [Remote host closed the connection]
<re_irc> <@kristoff:c.krbonne.net> yep ... error gone
<re_irc> <@kristoff:c.krbonne.net> thx :-)
<re_irc> <@kristoff:c.krbonne.net> dirbaio: ppfff ... these are things one would never find without the support of the matrix rooms