♻️ Separate LCD pins from board pins

[thinkyhead]

Gradual migration of LCDs to separate pins file(s) using defined connectors / interfaces.

[GMagician]

I'm not using anymore AGCM4 + RAMPS_144 but it seems that on AUX1 you have:

  VCC GND D1 D0
  VCC GND A3 A4

but VCC may be 5V/3V depending on J4 jumper (this goes also to IO pin)

AUX3 is (please note that SPI pins on AGCM4 are not like DUE but standard D50-52 may be redirected via solering pads):

 RESET GND SCK MISO VCC
  NC    5V D53 MOSI D49

AUX4 is:
VCC and not 5V

[GMagician]

RAMPS_1.4.4_C6.pdf
LCD144-A_Rev.A.pdf

As reference I add schematic

N.B. Ramps144 has been discontinued, because of developper health issues, then AGCM4 has de facto no shields available

[thinkyhead]

in #26719 you swapped the BNT buttons in the ReARM board for the CR10_STOCK_DISPLAY
can ask why?

To eliminate this pointless requirement only mentioned in the pins file:

// Requires REVERSE_ENCODER_DIRECTION in Configuration.h

[sl1pkn07]

oh. i forgot that

thanks

[thisiskeithb]

The following is what I think could be a safe way to approach this with minimal disruption for anyone:

• Stage and commit all of the non-functional changes. This touches a lot of comments which add noise and make it harder to spot which changes in the PR deserve attention. The smaller the scope of each PR, the easier it is for someone to volunteer to review and test those changes, and actually understand what they're looking at.

• Write a script which will set a board (one per pins file) and use the preprocessor to dump all the symbols it generates. This should be repeated for each screen which is being extracted into a new file. We have done something similar to this in the past when we were playing with adding embedded configurations, so I don't think this should be too hard.

• Add the new LCD pins files, but ONLY include them if the board pins file has "opted-in" by declaring something like USE_COMMON_LCD_PINS. This flag could be removed once the transition is complete.

• As pins files opt-in, re-run the script from step 2 and compare the output before/after output to check for unexpected differences. Fixing them at this stage will be a lot easier than figuring out what's wrong after people are using the change.

I'm sure there will still be some mistakes made...especially in the "weird' boards with non-standard connectors, but this should enable the majority to be transitioned without requiring any specific hardware testing.

I agree with all of this. We should also hold off on such a huge refactor until after 2.1.3.