Introduce PinGuard and reconnecting an output signal to a different pin now clears previous connections #3012
Conversation
bugadani
force-pushed
the
feat/pinguard
branch
from
6eea50e to
7b0e891
Compare
| crate::into_mapped_ref!(mosi); | ||
| mosi.enable_output(false); | ||
|
|
||
| self.driver().info.mosi.connect_to(&mut mosi); | ||
| self.pins.mosi_pin = OutputConnection::connect_with_guard(mosi, self.driver().info.mosi); |
There was a problem hiding this comment.
I'm not quite happy that we need to pass in the peripheral signal here. :/ We could do OutputConnection::connect_with_guard(mosi, &mut self.pins.mosi_pin) instead, but whether that's better is another question.
There was a problem hiding this comment.
I'm not sure what we can do better here, either we store the signal or the pin directly into State right? Unless I'm missing something (which is likely).
If it's a case of storing the pin or signal, imo storing the signal is fine here.
There was a problem hiding this comment.
We don't want to store anything in State, since we don't drop State 😅 My issue is just that we have to pass the signal, which comes with a possibility of passing in the wrong signal. It's not a big deal I guess.
There was a problem hiding this comment.
I guess it's on us to pass the right signal, as long as a user can't mess this up we can make this nicer for us later.
bugadani
force-pushed
the
feat/pinguard
branch
from
a8b2dd9 to
4f9af36
Compare
|
Funnily enough, the failed test or the original push demonstrates that the PR works 🙃 |
bugadani
force-pushed
the
feat/pinguard
branch
from
4e89618 to
2974889
Compare
bugadani
force-pushed
the
feat/pinguard
branch
from
f222d97 to
7b940b7
Compare
closes #2928