ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <dirbaio> > It is currently tied to Embassy's Async framework, and isn't suitable for use standalone.
<re_irc> you can use stm32-metapac standalone, and embassy-stm32 in blocking mode only without any executor
<re_irc> <dirbaio> and in async mode under any executor, for example it already works with rtic's upcoming async support
<re_irc> <firefrommoonlight> Thx; will correct
<re_irc> <firefrommoonlight> Done
<re_irc> <firefrommoonlight> Do you have a link to the standalone version?
<re_irc> <dirbaio> it's the same crate
<re_irc> <firefrommoonlight> nvm foudn it
<re_irc> <firefrommoonlight>
<re_irc> <dirbaio> if you simply don't use any async stuff
<re_irc> <firefrommoonlight> But the docs are blank?
<re_irc> <firefrommoonlight> Ah - will clarify
<re_irc> <dirbaio> docs are broken, have to investigate
<re_irc> <adamgreig> probably worth mentioning cargo-embed under probe-rs?
<re_irc> <firefrommoonlight> Do you use the crate I linked, or the main embassy crate?
<re_irc> <dirbaio> oh I thought you meant embassy-stm32. stm32-metapac has no idea about async
<re_irc> <firefrommoonlight> For standalone use
<re_irc> <adamgreig> i generally use it instead of probe-run, since it handles rtt but also gdb or just standalone flashing
<re_irc> <dirbaio> stm32-metapac is just a PAC :)
<re_irc> <firefrommoonlight> Sweet. Not on the HAL section yet lol
<re_irc> because they're different for each chip, and doesn't support that
<re_irc> (see the chip picker at the top)
<re_irc> <dirbaio> I'll probably make document one random chip and have a warning pointing to ... :S
<re_irc> <firefrommoonlight> Yea, IIRC getting unique docs for variants was a hosting hassle, as Agg pointed out
<re_irc> <firefrommoonlight> I guess you solve by self-hosting
<re_irc> <firefrommoonlight> (I'm doing what you describe, picking arbitrary variatn for
<re_irc> <dirbaio> even if supported it... it takes 1h to build for all 1200 chips 😂
<re_irc> <dirbaio> * chips, using 12 cpu cores
<re_irc> <firefrommoonlight> adamgreig: Also cargo flash
<re_irc> <dirbaio> so I don't think it'd fit in limits 😂
<re_irc> <dirbaio> 1h to build docs, which is running "cargo doc" 1200 times :P
<re_irc> <GrantM11235> Is that 1h with your cargo batching hack?
<re_irc> <dirbaio> no, it can't batch rustdoc
<re_irc> <dirbaio> just running rustdoc many times in 12 threads :P
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
causal has joined #rust-embedded
<re_irc> <firefrommoonlight> Article above fleshed out; has the basics I want
<re_irc> <firefrommoonlight> Some of it is kind of sparse and there are errors; lmk if you see any, eg for a lib you use that I don't or w/e
<re_irc> <Kevin Clark> firefrommoonlight: This is already way better than the status quo. Thank you!
<re_irc> <firefrommoonlight> Thanks for bringing this up earlier
<re_irc> <firefrommoonlight> I think most of the people here are regulars who already have a feel for things
<re_irc> <firefrommoonlight> So, it's easy to take knowing what all the stuff is for granted
<re_irc> <firefrommoonlight> I imagine this article might be tough to maintain though as things change
<re_irc> <omar_u8> For starters in embedded Rust, what are the best chat servers/forums to ask questions? Compared to my experience learning Rust programming, it seems the options are much more limited. Back then I used to be able to quickly get answers and navigate my way. Right now there’s the Discord rust language server embedded channel and the Matrix chats though I’m wondering if there’s more. Especially in the Matrix server...
<re_irc> ... chat servers I feel the level of questions I ask here are not up to the level of discussion already happening. Sort of like everybody talking about how an engine works and I jump in with a question on where do I fill gas? 😄
<re_irc> <dirbaio> I'd say the best place is this very chat!
<re_irc> <dirbaio> questions of all levels are welcome, don't be shy to ask :)
<re_irc> <omar_u8> Awesome, thanks. For what it’s worth the Rust community is something else. It’s part of what makes the experience better for a language considered tougher than others to learn. I hope the community stays that way as the language grows in popularity.
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Ping timeout: 244 seconds]
aspe has joined #rust-embedded
<re_irc> <henrikssn> I love how rust is able to inline the string parsing which is going on here: "AnyPin::from_str("PB12")"
<re_irc> <henrikssn> It compiles to "AnyPin {.port_pin: 0x1C }"
dc740 has joined #rust-embedded
aspe has quit [Remote host closed the connection]
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
funsafe has quit [Ping timeout: 248 seconds]
funsafe has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
dc740 has quit [Remote host closed the connection]
seer has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <Nathaniel Brough> Hey, I'm new here. Reaching out, as I've just just open sourced a fuzzed backend framework for embedded_hal. Is there anyone here that maintains a device driver that would be willing to work with me to battle test this framework with me?
<re_irc> <Nathaniel Brough> All that would be required on your end is a little guidance on how the driver is expected to be used, so I can craft a fuzzing harness :)
<re_irc> <barafael> Nathaniel Brough: are you looking for a simple or complex driver, any specific features it should use?
<re_irc> <Nathaniel Brough> Needs to use embedded_hal. Prefferably i2c, spi, digital as that's all I've implemented for now (though uart isn't that far off). For it to be worthwhile the driver must use some sort of inputs from the device e.g. or an InputPin. You'll get some limited benifit using it with a output only device.
<re_irc> <Nathaniel Brough> Any complexity is fine. The more complex the more likely it will find a bug.
<re_irc> <Nathaniel Brough> Even better if you have a driver, where you've previously had a bug that caused a panic. That way I can validate the fuzzing system against a known bug, and then test it again in a later version after the fix.