Added GPIO for SPI for Universal Touch Screen

[s-hadinger]

Description:

@gemu2015 please review before merging.

Changes:

• added SPI TS CS, SPI TS RST and SPI TS IRQ gpio types to templates
• pre-parse display template to replace * by the GPIO from template for line UTI:
• change from int8_t replacepin(char **cp, uint16_t pin) to int8_t replacepin(char **cp, int16_t pin) to allow negative value and replace unassigned GPIO with -1 (otherwise the value is 32767)
• minor changes in logging to align text and semicolon

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.6
• The code change is tested and works with Tasmota core ESP32 V.2.0.14
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[gemu2015]

a few comments:

1. since most touch drivers are i2c and i2c also may have IRQ and RESET pins the prefix SPI may not apply to TS_IRQ and TS_RESET
2. we have 3 kinds to touch drivers:
   a: simple resistive which has no pin assignments
   :UTI,SRES,R
   b: i2c which has parameters: address, reset, irq
   :UTI,FT5206,I2,38,-1,-1
   b: spi which has parameters: cs, reset, irq
   :UTI,XPT2046,S1,21,-1,22
   so we must distinguish these on pin replacement parsing
3. the CSx touch drivers are not yet tested but should be easy, the gt911 driver has a special issue.
   these ICs have to be initially flashed with a config block for several parameters like horizontal and vertical resolution.
   normally this should only happen once in the displays lifetime. the legacy drivers compares the resolution of the display and the touch ic on startup and on mismatch flashes the chip. i did not implement this in universal driver, so may be we should have a berry script to flash that chip if it ever should be necessary
4. some families of drivers (like FTx) have the same register assignments and so the code is identical, but the chip ID is different.
   currently we compare the chip id on startup. i will provide a multi compare opcode to match several ICs later
5. i would not remove other touch drivers now, but wait until more people have tested u-touch and all display.ini files have been updated. simply do not define them and make u-touch the default.

[s-hadinger]

1. since most touch drivers are i2c and i2c also may have IRQ and RESET pins the prefix SPI may not apply to TS_IRQ and TS_RESET

Good point, so it should be TS SPI CS, TS RST and TS IRQ.

2. we have 3 kinds to touch drivers:
a: simple resistive which has no pin assignments
:UTI,SRES,R
b: i2c which has parameters: address, reset, irq
:UTI,FT5206,I2,38,-1,-1
b: spi which has parameters: cs, reset, irq
:UTI,XPT2046,S1,21,-1,22
so we must distinguish these on pin replacement parsing

Yes currently I only parse SPI, but happy to add the others

3. the CSx touch drivers are not yet tested but should be easy, the gt911 driver has a special issue.
these ICs have to be initially flashed with a config block for several parameters like horizontal and vertical resolution.
normally this should only happen once in the displays lifetime. the legacy drivers compares the resolution of the display and the touch ic on startup and on mismatch flashes the chip. i did not implement this in universal driver, so may be we should have a berry script to flash that chip if it ever should be necessary

Needs to be added indeed, let's do this in a separate PR

4. amilies of drivers (like FTx) have the same register assignments and so the code is identical, but the chip ID is different.
currently we compare the chip id on startup. i will provide a multi compare opcode to match several ICs later

Nice

5. w, but wait until more people have tested u-touch and all display.ini files have been updated. simply do not define them an

Sure, we are not in any hurry, let's take the necessary time to have a smooth transition

[s-hadinger]

I renamed the GPIOs. Ok to merge ?

[gemu2015]

OK, thanks!

[s-hadinger]

1. and 2. are done now