You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is that currently MpuConfig<MODE> has only default builders which return Self or setters which return &mut Self. That makes it really difficult to use. Would a refactor of the configuration be possible. My current idea would be to add:
Actually, just that would pose a problem as the Device creation is now to be handled by the final user. But we could imagine having two build for I2C and SPI which create the Device.
Like for my previous issue, I am up for it.
The text was updated successfully, but these errors were encountered:
Yeah, I have seen this article on reddit, I don't know if everything he uses is stable or not (neither if all that this crate use is stable too as I work with nightly) but this would be a good idea.
@tchamelot btw, "Like for my previous issue, I am up for it" — sure, I agree that current approach to configuration is not ideal and would love to improve it, so feel free to take a stab (either by improving builder pattern or by using "struct init" or maybe other approaches)! %)
Currently,
MpuConfig<MODE>
tries to follow the Builder Pattern. However, to fully match the pattern,MpuConfig<MODE>
is missing a function likeThe problem is that currently
MpuConfig<MODE>
has only default builders which returnSelf
or setters which return&mut Self
. That makes it really difficult to use. Would a refactor of the configuration be possible. My current idea would be to add:Actually, just that would pose a problem as the
Device
creation is now to be handled by the final user. But we could imagine having twobuild
for I2C and SPI which create theDevice
.Like for my previous issue, I am up for it.
The text was updated successfully, but these errors were encountered: