inherent gpio methods

[burrbull]

See #1273 (comment)

[jessebraham]

Thanks for the PR.

We're still discussing what we're going to do regarding the various embedded-hal traits, so I'm hesitant to start refactoring our drivers specifically to accommodate them. Assuming that embedded-hal-compat gets updated, I'm leaning towards dropping the [email protected] trait implementations entirely, though there still needs to be some discussion surrounding this.

I think given our current implementations that this PR is completely reasonable, however I think I would prefer to come to a decision regarding embedded-hal before committing to refactoring a bunch of drivers.

[MabezDev]

Maybe we could split this PR into two bits, the inherent infallible methods on the GPIO structs and the eh trait refactoring? Imo the inherent infallible methods we can accept now, before figuring out what to do with the traits.

[bjoernQ]

I like the idea of putting the hal implementations into modules

[burrbull]

Rebased.

[jessebraham]

I like the idea of putting the hal implementations into modules

I very much don't, but guess I won't be too stubborn about it. I'd like some guarantee that all of the other modules implementing these traits will be updated, because otherwise I have a feeling I will have to do this myself.

[burrbull]

I very much don't, but guess I won't be too stubborn about it. I'd like some guarantee that all of the other modules implementing these traits will be updated, because otherwise I have a feeling I will have to do this myself.

Is problem in mod's or different files?

[bjoernQ]

I like the idea of putting the hal implementations into modules

I personally like to have it in modules - I don't like to have it in different files t.b.h.

[jessebraham]

Is problem in mod's or different files?

At the end of the day it's largely just a matter of consistency, I guess my personal preferences don't matter as much (I seem to be in the minority as is often the case, anyway).

I've been putting a lot of work into trying to make our code base more consistent (this is still ongoing), and this feels like a step backwards unless these changes are made for all applicable modules. I think it's reasonable for contributors to expect our drivers to be structured in similar ways, and I can see having only one or two driver like this causing confusion (or, we'll have to explain to contributors constantly what is expected in this regard).

Given the above, it follows that we should also split out modules for all other third-party trait packages, and this seems tedious and like a lot of work for essentially zero tangible gain.

But, I won't argue any more about this I suppose. Just my $0.02

[burrbull]

Is now better?

[MabezDev]

From my perspective, this LGTM. I'm a big fan of the infallible inherent methods, and I'm indifferent about the module layout, though I think cfg gated modules in the same file is a nice compromise between the two approaches.

[bjoernQ]

LGTM

[burrbull]

Rebased.

[MabezDev]

Sorry @burrbull, could you also update the tests inside hil-test? I will update the CI so we are building these before it gets to the HIL stage :).

[MabezDev]

Thanks!