Miscellaneous TFT improvements

[jmz52]

Description

Hardware IO
STM32F1 and STM32F4 use DMA2 to for data transfers from/to SDIO-connected cards.
Original implementation for FSMC interface also used DMA2 to send data to TFT display.
SDIO data transfer has low priority and can be delayed by on-going FSMC data transfer.

STM32F1 can use both DMA1 and DMA2 to send data to FSMC, so FSMC IO is reconfigured to use DMA1 controller.
STM32F4 can use DMA2 only to send data to FMC, so it will continue to share DMA2 with SDIO cards.
Maple-specific FSMC_DMA_DEV and FSMC_DMA_CHANNEL options removed from various pins.h files.

As a fail-safe measure the TFT_SHARED_SPI option is extended to TFT_SHARED_IO and it now affects both SPI and FSMC interfaces. It is not expected to be needed on STM32F4 MCUs though.

Update:
HAL STM32F1 (maple) uses DMA1_CH1 for ADC1 (temperature reading).
To avoid conflicts with ADC the FSMC in maple HAL is left on DMA2_CH5.
MCUs that could not handle two concurrent data transfers on same DMA controller should use #define TFT_SHARED_IO option to avoid FSMC/SDIO conflict.

TFT Screen Initialization
There are four possible orientations of TFT screen - landscape and portrait, upside down landscape and upside down portrait.
Marlin has 12 possible values for TFT_ROTATION option.
These 12 variants were created to address mirrored image issue on ILI9488 screens. Issue was caused by incomplete initialization sequence where several important parameters were left undefined i.e. were set by bootloader. Different bootloaders used different initialization sequences, so Marlin had to have different settings for different boards.

There are three parameters used by Marlin to configure TFT display orientation - "mirror X", "mirror Y" and "swap XY".
There are other parameters that affect how image is draw on the display, primarily the "Gate Scan Direction" and "Source Scan Direction". Those were undefined in current implementation of initialization sequence, leaving them at the mercy of bootloaders.

Initialization sequences for ILI9341 (320x240), ST7789 (320x240), ILI9488 (480x320) and ST7796 (480x320) were updated to have these parameters set in stone, to simplify screen orientation configuration. Reference sets of parameters for landscape and portrait modes were added/verified to corresponding headers files.

Initialization sequences for SSD1963 (480x272) and old ILI9328 (320x240) and R61505 (320x240) controllers are still in need of rework and update, but it can't be done without access to hardware.

Ultimate goal to to replace TFT_ROTATION with some simpler parameter that will define whether landscape of portrait UI is used.

Requirements

TFT screen

Benefits

Improved FSMC and SDIO performance on STM32F1.
Bootloader-independent behavior of TFT screen (for 4 most common controllers)

[thisiskeithb]

Ultimate goal to to replace TFT_ROTATION with some simpler parameter that will define whether landscape of portrait UI is used.

TFTs were also installed "upside down" in some machines (intentionally), so having the full list of rotation options will still be wanted/necessary.

[jmz52]

Full list of four rotations - sure, but 12 is a bit too much.
These four are listed as a refference in header files, named after side FPC cable is coming from - _RIGHT and _LEFT for landscape, _TOP and _BOTTOM for portrait.

[tpruvot]

i didn't test the DMA1 yet, but i remember conflicts vs some maple hardcoded values when i decided to use the "free" channel 5

(test on Longer3D F103VE with SDIO + FSMC)

[quiret]

In order for jmz52 to properly test his changes it could be helpful to supply Configuration.h and Configuration_adv.h for anything questionable so he can investigate. But good that Longer3D was mentioned. I hope it does not feel like chasing after a conspiracy theory to him.

[jmz52]

@tpruvot, do you remember any details about this conflict with DMA2_CH5? Or maybe someone from your local alfawise community dealt with similar problem?
pins_LONGER3D_LK.h has the same DMA2_CH5 settings for FSMC, so it is likely that they were used for a year or two before FSMC support was added to HAL STM32 along with the with Color_UI.

[jmz52]

@tpruvot, thanks a lot!
I've completely forgot how maple HAL deals with ADC. DMA1_CH1 will ruin temperature measurement.

[quiret]

@jmz52 The Marlin Firmware would greatly appreciate if you solve this peripheral resource collision altogether. Like if you could identify a location in the source code where all STM32(F1) Marlin peripherals using DMA can get their fixed DMA channel (stream) assigned distinctively (C++ preprocessor magic). But maybe this is too big of a task for this PR?

[tpruvot]

@jmz52 The Marlin Firmware would greatly appreciate if you solve this peripheral resource collision altogether. Like if you could identify a location in the source code where all STM32(F1) Marlin peripherals using DMA can get their fixed DMA channel (stream) assigned distinctively (C++ preprocessor magic). But maybe this is too big of a task for this PR?

its in maple framework...

STM32F1/libraries/SPI/src/SPI.cpp:146:    _settings[0].spiDmaDev = DMA1;
STM32F1/libraries/SPI/src/SPI.cpp:147:    _settings[0].spiTxDmaChannel = DMA_CH3;
STM32F1/libraries/SPI/src/SPI.cpp:148:    _settings[0].spiRxDmaChannel = DMA_CH2;
STM32F1/libraries/SPI/src/SPI.cpp:153:    _settings[1].spiDmaDev = DMA1;
STM32F1/libraries/SPI/src/SPI.cpp:154:    _settings[1].spiTxDmaChannel = DMA_CH5;
STM32F1/libraries/SPI/src/SPI.cpp:155:    _settings[1].spiRxDmaChannel = DMA_CH4;
STM32F1/libraries/SPI/src/SPI.cpp:160:    _settings[2].spiDmaDev = DMA2;
STM32F1/libraries/SPI/src/SPI.cpp:161:    _settings[2].spiTxDmaChannel = DMA_CH2;
STM32F1/libraries/SPI/src/SPI.cpp:162:    _settings[2].spiRxDmaChannel = DMA_CH1;

STM32F1/libraries/STM32ADC/src/STM32ADC.cpp:82:        dma_set_num_transfers(DMA1, DMA_CH1, BufLen);
STM32F1/libraries/STM32ADC/src/STM32ADC.cpp:83:        dma_enable(DMA1, DMA_CH1); // Enable the channel

STM32F1/system/libmaple/include/libmaple/sdio.h:41:#define SDIO_DMA_DEV        DMA2
STM32F1/system/libmaple/include/libmaple/sdio.h:42:#define SDIO_DMA_CHANNEL    DMA_CH4

There was no conflict with DMA2 Channel 5... but with the previous channel, 4 if i remember right

on DMA1 CH6 & CH7 may be free
on DMA2 CH3, and CH1 & 2 if SPI3 is not used

the F4 SPI ones are different, they can have 5 SPI pins .. see STM32F4/libraries/SPI/src/SPI.cpp:252

[jmz52]

So much for code unification.
It does not look like maple has room for improvement at all, so FSMC DMA is reverted to DMA2_CH5.

Maple ADC uses DMA1_CH1 with default priority, so it will be slowed down by FSMC data transter.
SDIO is less likely to cause fire, so it is better to slow down SDIO operations than temperature measurements.
Everyone's favorite GD32 has flawed DMA controller which can't handle two concurrent data transfers, so using DMA1 for FSMC is not an option at all.

For GD32 to avoid FSMC/SDIO DMA conflicts in maple environment the #define TFT_SHARED_IO should be enabled in Configuration.h file

[thinkyhead]

This seems pretty safe in its current state. I will go ahead and merge this (soon) if there are no objections.