Onboard (always-on) pullups support

[ManuelMcLure]

Allow specifying that a board has onboard pull-ups to satisfy sanity checks.

Description

Some modern boards such as Re-ARM or the BigTreetech SKR 1.3 have built in pull-ups, but there is no way to tell Marlin this. This causes some sanity checks to fail and forces users to enable internal pull-ups even though they are not necessary.
This fix adds a new ONBOARD_ENDSTOPPULLUPS option that can be defined in a pins file that will satisfy the sanity check and not require having the internal pull-up in parallel with the onboard one.
It also enables this option in the Re-ARM and BTT SKR 1.3 pins files.

Benefits

Allows using boards with onboard pull-ups without also setting ENDSTOPPULLUPS in cases where a pull-up is needed.

[thinkyhead]

It may be better to just enable ENDSTOPPULLUPS in Conditionals.h for certain boards / platforms, or set the individual endstop options based on which pin they're assigned to. That way if an endstop is reassigned to some pin that doesn't have the always-on pullup, then the behavior can adapt.

Along the same line, instead of setting pullups on pins that have them always-on, we should detect that and do nothing.

[ManuelMcLure]

Isn’t setting ENDSTOPPULLUPS in Conditionals.h going to have the same effect as setting it in the configuration, i.e. activating the internal pull-up? That’s exactly what we don’t want - this is a way to say “endstops on this board already have pull-ups so don’t complain about the user not explicitly enabling them.”

[ManuelMcLure]

I just noticed that my description can be interpreted wrong - I’ve updated it to make it clearer.

[thinkyhead]

It's an open question how to handle it. If a pin's pullup can't be turned off, then it may make sense to both:

• require the pullup option to be enabled for the pin in the config, and
• leave the pin in its natural pulled up state.

In this way the configuration (when read later) accurately expresses the state of the pullup in relation to the endstop. This still requires no change to configs, and is still handled transparent to the user in the conditionals or the sanity-check, but adds the extra burden for us to know more about each pin.

The main (maybe minor) issue I'm concerned about is that the pin might be edited, and the new pin might not have the pullup, and it would be nice to be able to handle that transparently in some way, basically just by changing how the pin is initialized.

This becomes more important if we later allow pin assignments to be changed at runtime (like RRF).

[ManuelMcLure]

Usually for this type of board the endstop pins have extra circuitry (a couple of resistors and a cap) that makes them unusable for other features without surgery with a soldering iron, so I think it's pretty unlikely that other pins on the board will be used for endstops. However, if they do use a different pin they can still explicitly set ENDSTOPPULLUP_* on that pin to get the internal pullup.

If I understand your comment correctly, you want code like this in endstops.cpp:

 166   #if HAS_X_MAX
 167     #if ENABLED(ENDSTOPPULLUP_XMAX) && DISABLED(ONBOARD_ENDSTOPPULLUPS)
 168       SET_INPUT_PULLUP(X_MAX_PIN);
 169     #elif ENABLED(ENDSTOPPULLDOWN_XMAX)
 170       SET_INPUT_PULLDOWN(X_MAX_PIN);
 171     #else
 172       SET_INPUT(X_MAX_PIN);
 173     #endif
 174   #endif

instead of just disabling the sanity check? I think that ends up being less flexible, unless we add ONBOARD_ENDSTOPPULLUP_XMIN and such.