<re_irc>
<Lachlan> Is there any way I can use the defmt crate to disconnect from the connected defmt viewer?
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
causal has quit [Quit: WeeChat 3.5]
<re_irc>
<Lachlan> Is there any way I can get one package in a workspace to build with the host target instead of a separate one?
<cr1901>
Last time I wanted to do this, .cargo/config in the relevant workspace and using "cargo build" without any --target was the way to do this.
<cr1901>
.cargo/config declaring the targets you want to build for*
<re_irc>
<Lachlan> Ugh, can't seem to get an xtask to run not in the embedded target
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
explore has joined #rust-embedded
aspe has joined #rust-embedded
gsalazar has joined #rust-embedded
aspe has quit [Quit: aspe]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
aspe has joined #rust-embedded
<re_irc>
<omar_u8> Im trying to create a function where I pass a generic pin parameter to it, however I am getting errors regarding the generic type and I am not sure how to go about. What I am trying to do is create a function that I can pass a button handler to from the caller (main function) so that I can detect a button press in the function.
<re_irc>
<omar_u8> * I'm trying to create a function where I pass a generic pin parameter to it, however, I am getting errors regarding the generic type and I am not sure how to go about it. What I am trying to do is create a function that I can pass a button handler to from the caller (main function) so that I can detect a button press in the function. This is what I am trying to do
<re_irc>
<omar_u8> The following is the error:
<re_irc>
<omar_u8> error[E0747]: unresolved item provided when a constant was expected
<re_irc>
<omar_u8> Ah! Awesome How about if parameter is unused?
<re_irc>
<omar_u8> +a
<re_irc>
<bugadani> unused how?
<re_irc>
<omar_u8> Actually, never mind. I meant if it's not used in the function itself but it seems I'm mixing up things.
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
Amadiro has joined #rust-embedded
Amadiro_ has joined #rust-embedded
Amadiro has quit [Ping timeout: 260 seconds]
aspe has quit [Quit: aspe]
<re_irc>
<jamwaffles> I appreciate this might be a bit OT but does anyone know of a cross platform crate that can send ethernet II frames _that is also async_? I've found "pnet" but it's not async, and can use "smoltcp" with "async" but it doesn't have Windows support 😫
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<Sean Bolton> Hi all, I'm struggling a bit to understand where we're trying to go with embedded-hal. Before I ask a bunch of questions, I'm wondering if folks might recommend any resources (beyond the Rust Embedded book) that discuss its design goals and best practices. It seems to me the HAL is great for simple use cases, but where I run into trouble is when trying to implement more complex use cases, for example circular...
<re_irc>
... memory-to-PWM DMA with stm32f1xx-hal. As best I understand it, in trying to be safe, the HAL implementation makes it really hard for me to extend its behavior beyond what is already implemented -- struct members are not pub, trait impls are sealed, free/release methods shut down the peripheral before returning the inner struct. I'm not sure how to move forward without trying to implement some rather niche behavior in the HAL...
<re_irc>
... impl itself, or falling all the way back to PAC-only use. Any suggestions?
<re_irc>
<Lachlan> Sean Bolton: Don’t have an answer, but this is a great question
<re_irc>
<almindor> Sean Bolton: This is a very astute observation. I'm afraid there's no good answer apart from "that's the way it is right now". It's my personal opinion that at least some parts of embedded-hal are over-abstracted to the point of making them detrimental.
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
causal has joined #rust-embedded
<re_irc>
<dirbaio> one thing is the "embedded-hal" traits, another thing is the APIs for individual HALs (like stm32f1xx-hal)
<re_irc>
<dirbaio> the goal for the embedded-hal traits is to allow writing hal-independent drivers, so they have to be very abstracted, sticking to the "lowest common denominator" of what most hardware out there can do
<re_irc>
<dirbaio> individual HALs impl the traits, and additionally offer HAL-specific APIs to do more advanced chip-specific stuff
<re_irc>
<dirbaio> if the HAL is missing $FEATURE it's probably simply beacuse no one has needed it before you, so you could implement and contribute it
<re_irc>
<henrikssn> almindor: I literally just asked the same question in #stm32-rs today
<re_irc>
<henrikssn> It would be nice if there was a "low level HAL" which was feature complete w.r.t. the PACs
<re_irc>
<henrikssn> Using PACs directly means a lot of macros since there are no traits for the parts which are common between peripherals (for example: timers, gpio ports, etc)
<re_irc>
<dirbaio> an "exhaustive PAC wrapper" is a LOT of not-fun work, it's unlikely to get done
<re_irc>
<dirbaio> the "macro spam" you mention is due to an (IMO) design mistake in stm32-rs PACs
<re_irc>
<henrikssn> Tell me more :)
<re_irc>
<dirbaio> which have different register blocks for "gpioa", "gpiob", "gpioc" etc (the justification is there's tiny differences between the ports, such as reset values, but imo keeping these differences does more harm than good to usability)
<re_irc>
<dirbaio> including impls with "less capabilities"
<re_irc>
<dirbaio> for exmaple STM32F3 TIM2 is "32bit general-purpose"
<re_irc>
<dirbaio> so TIM2 impls "GeneralPurpose32bitInstance", but also "GeneralPurpose16bitInstance" and "Basic16bitInstance", because these are subsets
<re_irc>
<dirbaio> and the key thing is each timer trait lets you get the PAC register block for it
<re_irc>
<dirbaio> for example "TIM2" impls "Basic16bitInstance", so you can get a PAC "TimBasic" register block for it
<re_irc>
<henrikssn> This looks exactly like what I'm asking for
WSalmon has joined #rust-embedded
<re_irc>
<dirbaio> even though the "right" register block for the hardware is "TimGp32"
<re_irc>
<henrikssn> How "unstable" is this API?
<re_irc>
<dirbaio> which is fine because "TimBasic" is a strict subset of "TimGp32"
<re_irc>
<dirbaio> it's still marked as "unstable" but I think it's unlikely to change, it's been proven to be a solid model for stm32 timers (for ALL stm32 chip families!!)
<re_irc>
<dirbaio> +by now
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
<re_irc>
<henrikssn> Cool
<re_irc>
<henrikssn> Actually, are the traits shared across all stm32 families?
<re_irc>
<dirbaio> yup
<re_irc>
<dirbaio> pick the right chip on the top menu, then in the "peripherals" mod you can see which TIMx impls which traits :)
<re_irc>
<Sean Bolton> dirbaio: Yes, now that looks promising. I don't believe a HAL impl should try to implement every useful/desired combination of features, there are just too many combinations. So offering traits and building-block impls that can be combined into a "custom driver" looks good! Let me study it a bit. Thanks!
aspe has quit [Remote host closed the connection]
aspe has joined #rust-embedded
aspe has quit [Client Quit]
aspe has joined #rust-embedded
<re_irc>
<Tom> dirbaio does embassy still use svd2rust? the whole point of using stm32ral in imxrt-rs was the insane generated code size (1mloc) and compile time (15+ min) which drove me nuts
<re_irc>
<dirbaio> it generates simpler and less code than svd2rust: given the same svd, the generated code compiles ~2x faster
<re_irc>
<Tom> so not quite the instantaneous compile that stm32ral did (macros + modules with consts from what I recall... its been awhile)
<re_irc>
<dirbaio> but another cause svd2rust stm32 pacs compile so slowly is the giant amount of duplication (like gpioa, gpiob, gpioc...) and not using arrays of registers/fields in many places
<re_irc>
<dirbaio> all of these are cleaned up in stm32-metapac
<re_irc>
<Lachlan> is stm32-metapac only an embassy thing?
<re_irc>
<dirbaio> PAC for an h7 (fattest chips) builds in 4s :D
<re_irc>
<dirbaio> [dirbaio@mars stm32-metapac]$ time cargo build --release --features stm32h743vi,rt,memory-x
<re_irc>
Finished release [optimized] target(s) in 4.15s
<re_irc>
real 0m4.257s
<re_irc>
<Tom> that's about the same as the imxrt-ral
<re_irc>
<Tom> nice!
<re_irc>
<dirbaio> (it's a bit apples-to-oranges because it doesn't have all registers yet. it has registers for ~70 out of ~100 peripherals, so it'd build in ~6s if it hadd all peripherals)
<re_irc>
<dirbaio> * had
<re_irc>
<dirbaio> which is still fast
<re_irc>
<dirbaio> (it's a bit apples-to-oranges because it doesn't have all registers yet. it has registers for ~70 out of ~100 peripherals for h743vi, so it'd build in ~6s if it had all peripherals)
<re_irc>
<Tom> yes... the svd2rust version of this thing took _many_ minutes
<re_irc>
<dirbaio> Lachlan: it's just a PAC, it doesn't depend on embassy itself
<re_irc>
<dirbaio> it was created for embassy-stm32 (because building a HAL for all stm32 families on top of the svd-based PACs proved unmaintainable) but it's intended to be usable on its own too
<re_irc>
<dirbaio> +to be
<re_irc>
<firefrommoonlight> Sean Bolton: For this specific case, using STM32-HAL (Lib I wrote; important note: not compatible with F1), You'd use this API:
<re_irc>
<firefrommoonlight> With the "circular" field set to "Circular::Enabled" on the "channel_cfg" parameter there
<re_irc>
<firefrommoonlight> Pardon the repeating docs on that page, the "timers" module is a Macro mess internally, with the docs generating duplicated methods for each timer