<chrysn[m]>
Following the 0.2-to-1.0 upgrade guide: How common, or how recommended is it to have own `fn is_high(&self) -> bool` methods on input GPIOs? The guide just says "can also provide infallible versions".
<chrysn[m]>
I'm torn between "it's convenient because a user of the concrete type thus needs less unwrapping and type sharing" and "it's confusing as hell".
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
"dealers choice"? If you can provide it there's no reason not to.
<JamesMunns[m]>
ah, that's fair.
<JamesMunns[m]>
maybe have separate is_pin_high methods that don't name collide?
<chrysn[m]>
I can, I'm just undecided whether I want, and gathering opinions.
<chrysn[m]>
JamesMunns[m]: Thanks, I'll add that to my options list; might even go a step further with this and have `read()` and `set()` methods that use the true-is-high convention that is prevalent on that backend (RIOT)
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
I'd include them, it's nice for users to not have to import the e-h traits when they are dealing with your concrete types
<adamgreig[m]>
and then might as well make them infallible if the hardware is
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
notgull has quit [Ping timeout: 252 seconds]
thejpster[m] has joined #rust-embedded
<thejpster[m]>
Again, it feels like a guide for HAL authors would be useful to answer these questions. Or even a Golden Reference HAL for the Luminary Micro LM3S that nobody ever uses but that QEMU happens to sort of emulate.
<thejpster[m]>
It certainly makes example code easier if you don’t have to import traits before “is_high” will work (or even appear in the autocomplete list)
<thejpster[m]>
But I’ve also heard it suggested that getting people used to the Eh traits is no bad thing.
<JamesMunns[m]>
We've attempted to have a standards guide before, Jonas wrote part of one.
<thejpster[m]>
A guide might involve attempting to resolve the great Input<Pin7> vs Pin<Pin7, Input> schism though.
<JamesMunns[m]>
My $0.02 is "do what embassy does", e.g. `Input<'a, P: Peripheral>`
<JamesMunns[m]>
It's already working and consistent for nrf, stm32, RP, etc.
<thejpster[m]>
Well yeah, I know dirbaio has Strong Opinions on this one.
<JamesMunns[m]>
My opinion is that I agree with his strong opinions :D
<thejpster[m]>
But to adopt that is to tell the other HALs they got it wrong.
<thejpster[m]>
Maybe they did! But I’m just realising there may be some pain in trying to harmonise the HALs or suggest how they should work.
<JamesMunns[m]>
I mean, tbh maybe embassy should just write the embassy style guide first
<thejpster[m]>
I like my idea less the more I think about it
<JamesMunns[m]>
If nobody else writes one, then people will just follow the only/best written one.
<JamesMunns[m]>
thejpster[m]: IMO rewg has never been that prescriptive
<thejpster[m]>
For good reason
<JamesMunns[m]>
And any time we try to it's arguing in meetings for a year about minutiae :D
<JamesMunns[m]>
Which fair: if we have to be perfect and right forever, like a formal standards doc!
<JamesMunns[m]>
But there's some benefit to documenting "this is the best way we know how today, take it or leave it, might change next week if we figure out how"
<JamesMunns[m]>
Not "you must do it this way", because what are we gonna do about it?
<thejpster[m]>
And here’s a bunch of other options and here’s the trade offs
<thejpster[m]>
Interestingly the HAL guide is the “classic” way around and not the “embassy” way around
<thejpster[m]>
So step 1 might be for embassy to document their thinking and then step 2 might be to revise the guide
<JamesMunns[m]>
Following up on this in the embassy room.
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Follow up to my H7 ADC problem: Turns out on H7, you need the CR reg, BOOST bit set if the ADC clock is above 20Mhz.
<dirbaio[m]>
IMO it's too early to write a "how to write a Hal" guide
<dirbaio[m]>
(and it was too early as well when the embedded book was written ofc)
<dirbaio[m]>
and i'm not sure there should be a "this is THE way how to write a HAL" guide
<dirbaio[m]>
because there's tradeoffs
<adamgreig[m]>
yea. i think the motivation is coming from people discovering embedded rust, wanting to use a chip that doesn't have a hal, deciding they should write a hal, and then asking what a hal should look like
<dirbaio[m]>
(in fact i'd remove or soften the "HAL guildeines" sections of the book)
<adamgreig[m]>
but i don't think "ah, here's the official hal api you should copy" is the answer there really
<adamgreig[m]>
but "here's a couple of hals you could reference" or perhaps "here's an overview of common patterns"?
<adamgreig[m]>
I dunno, I don't think that would answer the question because the question is usually "literally what should the exact type signatures be, I just want to write the implementation code"
<adamgreig[m]>
so an answer of "no you don't, you should think about rust api design and see if you fancy coming up with something totally different" is probably not mega helpful
<dirbaio[m]>
yeah :(
<adamgreig[m]>
the most immediately helpful answer is probably "use a chip that already has a hal, because it will also already have support and people who've used it and you'll have a much better time"
<JamesMunns[m]>
My suggestion was to document "what does embassy do (today)", e.g. being DESCRIPTIVE rather than PRESCRIPTIVE
<adamgreig[m]>
depends who's asking and how much rust/embedded/bare-metal experience they have generally/with that specific chip/...
<dirbaio[m]>
my personal Strong Opinion is "simplify the API as much as possible, in particular remove as much generics as you can"
<dirbaio[m]>
and embassy is kinda the product of that
<dirbaio[m]>
but the embassy api is not "done" either 🥲
<adamgreig[m]>
but often it's someone who's more or less starting out, but has an uncommon chip, so believes their first step has to be writing a hal or generating a pac or something (probably having found an old rewg document that says "here's how to get started with a new chip")
<dirbaio[m]>
so if someone asked me "I want to make a HAL, how should my API look like" I would tell them "don't copy embassy as it is today, try to do it without instance generics"
<adamgreig[m]>
yea. which is a good answer if a clone of you comes along wanting to make a new hal, and probably not what a newcoming with minimal experience in rust and/or embedded wants to hear
<dirbaio[m]>
the reason embassy doesn't have it is there's way too much code that has to be refactored 😭
<adamgreig[m]>
("instance generics? what are they?")
<dirbaio[m]>
generic param indicating the peripheral instance
<adamgreig[m]>
(example question from hypothetical newcomer)
<dirbaio[m]>
`Uart<USART5>` -> `Uart`
<dirbaio[m]>
I sort of lean lately towards removing even the GPIO instance generics
<dirbaio[m]>
`Input<PA5>` -> `Input`
<dirbaio[m]>
out with all generics 🔥
<adamgreig[m]>
just keep it all as runtime state?
<dirbaio[m]>
yeah
<dirbaio[m]>
like C HALs
<adamgreig[m]>
yea. the C hals that don't implement it all with preprocessor macros anyway :P
<dirbaio[m]>
it's the same as in C hals, they've always done something like fn set_high(pin_num: u8) and it's never resulted in perf problems, the compiler is good at optimizing it
<adamgreig[m]>
all the simple baby HALs I end up writing for my no-hal firmwares are the same, an Input that knows which port+pin, or a DmaChannel that knows which periph+channel, that sort of thing
<adamgreig[m]>
sometimes just storing the pointer to the relevant register...
<adamgreig[m]>
anyway
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
i think the underlying question is here is not about performance, rather the "source of truth" for your device tree / gpio tree setup. The above api allows for arbitrary device creation / addressation by value. In contrast if you get all your devices/gpios from a fixed struct.
<vollbrecht[m]>
Both have pro's and con's but don't have anything todo with using generics here in the first place?
<vollbrecht[m]>
s/if/to,/, s/get/getting/
<vollbrecht[m]>
* i think the underlying question is here is not about performance, rather the "source of truth" for your device tree / gpio tree setup. The above api from firefrommoonlight allows for arbitrary device creation / addressation by value. In contrast to, you getting all your devices/gpios from a fixed struct.
<vollbrecht[m]>
Both have pro's and con's but don't have anything todo with using generics here in the first place?
<JamesMunns[m]>
<dirbaio[m]> "out with all generics 🔥" <- I use AnyPin like 99% of the time I have to name a type anyway :p
emerent has quit [Ping timeout: 260 seconds]
<JamesMunns[m]>
(And wish there was an AnyUart/AnySpi etc to go with it)
<JamesMunns[m]>
IMO I like "generics to create an instance, no generics after you have the instance"
<JamesMunns[m]>
so I like generics that help enforce "those pins dont work with that uart instance"
emerent has joined #rust-embedded
<JamesMunns[m]>
but once I pass that check, a uart is a uart IMO
<JamesMunns[m]>
"generic constructors, ungeneric hal peripherals"
<firefrommoonligh>
s/, features = ["f401", "f4rt"]//
<JamesMunns[m]>
You can also always do pub(crate) use very-long-hal-crate-name as hal; in the Rust code
<firefrommoonligh>
V nice
<firefrommoonligh>
Hey so a note on generics that could be addressed upstream, that would ease a pain point: If there was a way to make it so the docs would auto-generate with a specific implementation of a trait, it would make learning the APIs easier.
<firefrommoonligh>
For a non-generic API, you may have a constructor, listed in the docs, as `my_fn(param: Param)`. You can click `Param`, and find its fields to initialize manually, or a `Param.new(u8)` or w/e method.
<firefrommoonligh>
With a generic, you get a `my_fn(param: T)`. You can't click the T, and the docs' usefullness ends there; you hope there is a provided code example in the repo or third-party docs.
<firefrommoonligh>
There are a few ways this could be approached, but I think something along these lines would help
<firefrommoonligh>
s/./::/
cgc17[m] has joined #rust-embedded
<cgc17[m]>
Hi everyone, I’m new to embedded (not as new to rust) and wondering if there’s a best or right/wrong place to ask beginner level questions. Nothing specific right now but chats like these have been super valuable while learning other areas. Just want to get the lay of the land. Thanks!
<adamgreig[m]>
yea, this is a good place to ask beginner questions on embedded or embedded-rust
<firefrommoonligh>
And as a summary of my take on generics: Great in theory; I avoid them because I've found the APIs in practice end up making the benefits not worth it for me. Would love if there was a best-of-both-worlds in the future.
<firefrommoonligh>
* on generics for embedded hardware abstractions: Great
<firefrommoonligh>
* on generics for embedded hardware abstractions: Great, * in theory for making reusable code, leveraging common hardware features; I
emerent has quit [Remote host closed the connection]