Ensure setPinInput actually sets input high-Z

[Duckle29]

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

The documentation here says that setPinInput() sets the pin to a high-z input. This is true only if the PORTx register is 0, meaning you have to use writePinLow() to go from setPinInputHigh to input high-z again. This fixes that.

[drashna]

@nooges @mtei @pelrun Could you double check this?

[fauxpark]

I think this should probably be labelled a breaking change, as this macro is used in a few keyboards and keymaps, and in matrix.c. I do like that it now matches the ChibiOS implementation though.

[nooges]

So from digging into previous usage of using pinMode from pincontrol.h, this change actually brings setPinInput() in line with that. I’ll dig into its use in matrix.c in a bit.

[mtei]

Looks Good To Me.

And the following source file writePinLow() is an AVR-dependent implementation, so I think those writePinLow() should be removed.

 % find . -name '*.[ch]' | xargs grep -A1 'setPinInput(' | grep -v quantum/quantum.h

./keyboards/kbdfans/kbd75/keymaps/tucznak/keymap.c:        setPinInput(B2);
./keyboards/kbdfans/kbd75/keymaps/tucznak/keymap.c-        writePinLow(B2);
--
./keyboards/yd60mq/yd60mq.c:        setPinInput(F4);
./keyboards/yd60mq/yd60mq.c-        writePinLow(F4);
--
./keyboards/gh60/gh60.h:inline void gh60_caps_led_off(void)     { setPinInput(B2); writePinLow(B2); }
./keyboards/gh60/gh60.h:inline void gh60_poker_leds_off(void)   { setPinInput(F4); writePinLow(F4); }
./keyboards/gh60/gh60.h:inline void gh60_fn_led_off(void)       { setPinInput(F5); writePinLow(F5); }
./keyboards/gh60/gh60.h:inline void gh60_esc_led_off(void)      { setPinInput(F6); writePinLow(F6); }
./keyboards/gh60/gh60.h:inline void gh60_wasd_leds_off(void)    { setPinInput(F7); writePinLow(F7); }
./keyboards/gh60/gh60.h-
--
./keyboards/hineybush/h87a/keymaps/wkl/keymap.c:    setPinInput(D5);
./keyboards/hineybush/h87a/keymaps/wkl/keymap.c-    writePinLow(D5);
--
./keyboards/hineybush/h87a/keymaps/wkl/keymap.c:    setPinInput(E6);
./keyboards/hineybush/h87a/keymaps/wkl/keymap.c-    writePinLow(E6);
--

In addition, we will need to check the following source files:

--
./keyboards/gingham/matrix.c:        setPinInput(row_pins[x]);
./keyboards/gingham/matrix.c-    }
--
./keyboards/touchpad/matrix.c:  setPinInput(D2);
./keyboards/touchpad/matrix.c-
--
./keyboards/wasdat/matrix.c:        setPinInput(row_pins[x]);
./keyboards/wasdat/matrix.c-    }
--
./keyboards/kmac/matrix.c:        setPinInput(row_pins[x]);
./keyboards/kmac/matrix.c-    }
--
./keyboards/staryu/backlight_staryu.h:      setPinInput(backlight_pins[index]);
./keyboards/staryu/backlight_staryu.h-  }
--
./keyboards/ai03/orbit/split_util.c:    setPinInput(SPLIT_HAND_PIN);
./keyboards/ai03/orbit/split_util.c-    return readPin(SPLIT_HAND_PIN);
--
./quantum/split_common/split_util.c:    setPinInput(SPLIT_HAND_PIN);
./quantum/split_common/split_util.c-    return readPin(SPLIT_HAND_PIN);
--

[mtei]

Then I opened #6243 because I found a small bug in quantum/matrix.c regarding the use of setPinInput().

[pelrun]

LGTM.

[fauxpark]

@mtei the Wasdat can be ticked off your list as of #6247 :)

[mtei]

In quantum/split_common/split_util.c, I opened #6268 that adds SPLIT_HAND_PIN_WITH_PULLUP to use setPinInputHigh().

[drashna]

This looks to have a merge conflict now. If that could be resolved?

[Duckle29]

Ah forgot about that, should be resolved now :)

[drashna]

It looks like there is a merge conflict for this now. Could you fix this?

[Duckle29]

Good catch that's a mistake, I'll get that fixed :)

[emdarcher]

We also need sign off from the users whos keymaps have been modified:
@emdarcher
@tucznak

Otherwise it would have to target the breaking changes process.

Ok, looks fine to me now. 👍

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[hineybush]

seems good to me regarding my PCBs.