crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
fabic_ has joined #rust-embedded
Amadiro_ has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 260 seconds]
gsalazar has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic_ has quit [Ping timeout: 240 seconds]
causal has quit [Quit: WeeChat 3.5]
fabic_ has joined #rust-embedded
<re_irc>
<omar_u8> Is there a place in the docs.rs documentation of HALs where I can see what the default configuration is for a particular peripheral is (example ADC or UART)?
<re_irc>
<omar_u8> I typically end up looking up the trait implementation in the source.
<Lumpio->
There's no "standard" like that for HALs so if it's not in the docs the source is the place to look
<Lumpio->
I'd check the peripheral documentation page and then the source.
<re_irc>
<omar_u8> Yeah, I guess it would be good for it to become sort of standard practice to include that information in the documentation.
<re_irc>
<omar_u8> I figure as I am going through the journey of embedded Rust, incomplete descriptions in documentation can be a significant barrier for beginners. Working through completing many of the documentation for the HAL repos out there can be considered a significant contribution on its own.
<re_irc>
<omar_u8> * for the documentation of the different
<re_irc>
<omar_u8> I found myself at times for several methods jumping around repos trying to find a description for what the method does.
<re_irc>
<omar_u8> * a certain
explore has quit [Quit: Connection closed for inactivity]
starblue has quit [Quit: WeeChat 3.0]
starblue has joined #rust-embedded
<re_irc>
<9names (@9names:matrix.org)> omar_u8: people add things to a HAL to solve their problem. teaching someone else their code is someone else's problem ;)
<re_irc>
if you haven't found it yet there's a nightly-only cargo doc flag that scrapes snippets out of examples which I find _super_ useful, since it's easier to convince people to contribute examples when adding drivers since they've already half written them while developing + testing drivers.
<re_irc>
<omar_u8> 9names: You're probably right in that aspect. Ever since I started with Rust, I have this thing going where every time I tackle something I think about how it could be different 🙃 I guess it's from this "hard to learn" notion I see floating around all the time 😬
<re_irc>
<omar_u8> 9names: Awesome, thanks for the tip!
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 268 seconds]
<re_irc>
<vulpine_smelts> Hi! I have a sensor driver crate architecture/design question:
<re_irc>
*Is it good practice to use the type state pattern to enforce "correct" usage of the sensor?*
<re_irc>
As a simplified example, I was thinking of having the following states PoweredOff <--> Ready <--> ContinuousMeasurement
<re_irc>
- When PoweredOff the only method it can call is to power back on
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<James Munns> I don't have a great answer for you - but you've hit on the important distinction: Type State programming is _great_ for enforcing things at compile time, but can make runtime changes very painful
<re_irc>
- PoweredOff
<re_irc>
- ContMeasurement
<re_irc>
<James Munns> IMO, the best approach here would be to have four type states:
<re_irc>
- Ready
<re_irc>
- Dynamic
<re_irc>
<James Munns> Have the first three be "strongly typed", e.g. methods are only available in the correct type
<re_irc>
<James Munns> have the fourth mode, Dynamic, only have "try_*" methods, that can fail if you are in the wrong mode
<re_irc>
<firefrommoonlight> omar_u8: I've been using doc documments on fields
<re_irc>
<James Munns> this way you can USUALLY share code "under the hood", where essentially the strongly typed methods skip the error checking
<re_irc>
<firefrommoonlight> Not ideal since it's a subjective convention, and there's no standard way to do it
<re_irc>
<James Munns> This "dynamic" pattern is usually what we talk about with "degrade" types in things like GPIO pins
<re_irc>
<firefrommoonlight> Eg :
<re_irc>
continuous: Continuous
<re_irc>
Sample as one-shot, continuous, or continuous fast-mode. Defaults to continuous fast mode.
<re_irc>
<firefrommoonlight> Example output of using field-comments for default doc (manual):
gsalazar has quit [Read error: Connection reset by peer]
gsalazar_ has joined #rust-embedded
fabic_ has joined #rust-embedded
gsalazar has joined #rust-embedded
gsalazar_ has quit [Ping timeout: 244 seconds]
fabic_ has quit [Ping timeout: 246 seconds]
fabic_ has joined #rust-embedded
dc740 has joined #rust-embedded
explore has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
gsalazar has quit [Read error: Connection reset by peer]
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 244 seconds]
gsalazar has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
fabic_ has quit [Ping timeout: 256 seconds]
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/Qi3H-o5tTK6FKLwM9pEmNg, please add anything you'd like to announce or discuss and we'll start in a few mins
<re_irc>
<adamgreig> ok, let's begin! first up from me, we discovered svd2rust 0.24.0 had a codegen bug that meant some fields would not do the correct thing, fixed in the recently released 0.24.1
<re_irc>
<adamgreig> in related news, v0.15.0 and v0.15.1 of the stm32-rs were released
<re_irc>
<adamgreig> +PACs
<re_irc>
<adamgreig> and, riscv-rt 0.9.0 was also recently released
<re_irc>
<adamgreig> any other announcements?
<re_irc>
<adamgreig> the Earth Orientation Center announced that there won't be a leap second this december 31st, you'll all be glad to know
<cr1901>
Time based code won't break for at least another year :)
<re_irc>
<adamgreig> they send a bulletin C twice a year with this announcement, always makes my day :)
<re_irc>
<adamgreig> not least because it's addressed "To authorities responsible for the measurement and distribution of time"
<re_irc>
<adamgreig> the only other thing I noticed come up this week is an older issue around the embedded-hal CAN ErrorKind in https://github.com/rust-embedded/embedded-hal/issues/387#issuecomment-1174717433, which we agreed probably just needs a documentation update to say it's there because that's all possible CAN errors, but many implementations may never be able to return it because they won't know at the time they accept a message...
<re_irc>
... for transmission
<re_irc>
<adamgreig> (and the e-h traits don't offer a way to later check the status of an enqueued message, though a particular driver might and could use the error in that case)
<re_irc>
<eldruin> great, now in docs-y form? :D
<re_irc>
<eldruin> * way?
<re_irc>
<adamgreig> haha yea that's the trick huh
<re_irc>
<eldruin> we can do it later in the issue, no pressure
<re_irc>
<adamgreig> I'll see if I can come up with something if that seems like a reasonable concept anyway
<re_irc>
<adamgreig> and probably not worth re-litigating the "should we remove nb" question right now, but if anyone is interested in seeing how well an nb wrapper could live on top of the async traits it might be very interesting
<re_irc>
<therealprof> adamgreig: I had a brief look, too.
<re_irc>
<therealprof> Looks good in general. My only slight concern is the addition of "toml-edit" which is a major compile time killer...
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<adamgreig> hmm, is it worth it or should it just spit out a .toml fragment with the features?
<re_irc>
<adamgreig> * "features.toml"
<re_irc>
<burrbull> it should be optional dependency
<re_irc>
<therealprof> It's a bit unfortunate to add such a goliath just to read Cargo.toml. 😅
<re_irc>
<burrbull> also name of feature sounds strange
<re_irc>
<burrbull> although all cli part of svd2rust needs revise and update to clap3
<re_irc>
<emilgardis> I'd wait with clap 3, clap 4 is in the pipeline
<re_irc>
<therealprof> emilgardis: There're probably no major changes, mostly removal of now deprecated features.
<re_irc>
<emilgardis> true 👍️
<re_irc>
<therealprof> I've ported a few applications already. 😉
<re_irc>
<adamgreig> any thoughts on a better name than group_name_as_feature ?
<re_irc>
<adamgreig> maybe "group_features"?
<re_irc>
<therealprof> feature_group? 😄
<re_irc>
<emilgardis> naming stuff is hard
<re_irc>
<emilgardis> I think the features.toml way is to go btw, don't think toml_edit is worth pulling in
<re_irc>
<emilgardis> * is the way
<re_irc>
<emilgardis> it's a major compile time stealer, unfortunately
<re_irc>
<newam> emilgardis: speaking of major compile time sinks 😆
<re_irc>
beware with the derive interface, if you're not already using structopt it may not be worth the extra compile time
<re_irc>
<therealprof> newam: Guess what's being used. 😉 But it's not that bad.
explore has joined #rust-embedded
<re_irc>
<adamgreig> anything else anyone wanted to discuss?
<re_irc>
<TimSmall> I appear to have introduced a regression for stm32f413 in the latest PAC release via https://github.com/stm32-rs/stm32-rs/pull/713 (see post-merge comments in that issue) - I've opened another PR to fix this (and some related f4 UART and USART svd bugs which I uncovered) at: https://github.com/stm32-rs/stm32-rs/pull/754 . Sorry for the hassle - just running some extra checks on that PR now.
<re_irc>
<adamgreig> I saw the new PR, thanks! let me know when you're happy with it, perhaps it can be a 0.15.2 for stm32f4