FYSETC S6: Allow redefine pin functions, enable eeprom

[LinFor]

Description

FYSETC S6 pin file enhancements

Benefits

• Allow override endstops, heaters and fans socket function in Configuration.h without redefinition warning
• S6 has i2c eeprom soldered onboard, enables it's support. Maybe not all boards have it soldered (board images on fysetc site shows not-soldered placeholder), but it present in schematic and my v1.2 have it soldered.

Configurations

None special

Related Issues

#18434 - Proper EEPROM support on Fysetc S6 (added by sjasonsmith)

[sjasonsmith]

Can you describe your use-case which makes overriding every basic pin necessary? We don't normally do it for every pin on other boards.

[LinFor]

Can you describe your use-case which makes overriding every basic pin necessary? We don't normally do it for every pin on other boards.

My case is as follows:

• I am using 4-pin coolers with PWM signal speed control. Because the power ports are switched by mosfets, I cannot control the coolers through the standard fan ports (there is, of course, a variant with a voltage divider, but it is very redundant in my opinion). For the purpose of controlling the speed of the coolers, I use endstop ports, which give out positive PWM.
• I am using a 220v table heater connected via a solid state relay. Because to control the relay does not require a lot of current, I use one of the free fan ports to control the heating of the bed - the xh 2.54 connector is more convenient to use (than screw terminals) and provides a reliable contact, at the same time freeing up the power port for future use.
• The backlighting of the case and the blowing of the extruder radiator also use fan ports due to their convenience.

Perhaps I'm going the wrong way, but I used a similar redefinition method on the Gen L board (variant of RAMPS) and found it very convenient.

[sjasonsmith]

To summarize, we have two decisions to make:

1. Do we change the default EEPROM to IIC, even though the first batch does not have it populated?
   My recommendation: Change it and risk inconveniencing the few people who don't have the EEPROM. It is an easy workaround to switch back. If it comes up we can consider forcing users to select in their config file, with no default.

2. Do we want to make all these pins conditional? I want @thinkyhead's input on this. Some consistency to our strategy across boards would be good.
   I personally feel that when you are straying wildly from the configs (as you are), you should just edit the pins file directly. Making every pin conditional clutters the file and makes it harder to read/maintain.

[sjasonsmith]

I am having some errors between my chair and keyboard with regard to using GitHub's review tooling. Please disregard my approval, as it is really contingent on the previous comment.

[thisiskeithb]

I personally feel that when you are straying wildly from the configs (as you are), you should just edit the pins file directly. Making every pin conditional clutters the file and makes it harder to read/maintain.

Ditto.

[sjasonsmith]

I have decided to roll most of this back, keeping only the fix to the EEPROM size.

My reasoning is as follows:

1. For pin overrides, this is inconsistent with other boards. When completely redefining pin meanings users should just edit the pins file. If we wish to allow overriding every pin we should do it in a way that is consistent across boards.

2. For default EEPROM mechanism, I decided it should not change. This contradicts my earlier statement, but the following are my reasons:

   • V2.0 boards already use I2C by default, and are probably most new users
   • Even for boards with I2C, this will cause users to lose their existing values, such as UBL meshes. The upset people when we first added the FLASH_EEPROM_LEVELING behavior, and I would like to avoid that if possible.
   • I didn't have a great way to communicate to early V1.2 users that their EEPROM may not work. I tried doing it to warnings, but this causes hundreds of warnings during an otherwise normal build.

Flash EEPROM emulation should be fine for most users, and they likely will not care or notice which mechanism they use. For those users (such as you) which want to use I2C, you can simply add #define I2C_EEPROM to your Configuration.h file, or edit the default in the pins file.