@mrjames
The reply to the message is not here. There were 3 points made. The first point was to look for the parameters, and that is what I have been searching for. The second point was not to mix the drivers, which makes sense. I have not dug into the controllers on each MCU to see what the similarities or differences are.
The third point discussed using STM32CUBEMX as a guide. For the F769 platform I was able to use STM32CUBEMX and integrate the sample LCD_DSI_CmdMode_DoubleBuffer. The LCD works perfectly. The H747 platform is a different matter. For STM32CUBEMX the selections and settings for DMA2D, DSIHOST, and LTDC can be configured. The resulting project pulls in the HAL driver files and the suggested code in MAIN.C. The next step was to manually add the H747 BSP drivers to the project. This is where the problem comes in. The build fails since the BSP's LCD driver defines two function different than what STM32CUBEMX sets up. STM32CUBEMX sets up the following:
static void MX_DSIHOST_DSI_Init(void);
static void MX_LTDC_Init(void);
The stm32h747i_discovery_lcd.c defines the same functions as:
__weak HAL_StatusTypeDef MX_DSIHOST_DSI_Init(DSI_HandleTypeDef *hdsi, uint32_t Width, uint32_t Height, uint32_t PixelFormat)
__weak HAL_StatusTypeDef MX_LTDC_Init(LTDC_HandleTypeDef *hltdc, uint32_t Width, uint32_t Height)
Obviously, the build complains about conflicting types. Digging into the stm32h747i_discovery_lcd.c file, you can see the driver writer was trying to be all inclusive with a single call to set up everything with
BSP_LCD_Init(BSP_LCD_Init(uint32_t Instance, uint32_t Orientation). Any settings in STM32CUBEMX have no effect on the project. It's as if the driver developer didn't want to create a driver with the flexibility to support STM32CUBEMX.
If STM32CUBEMX is a tool to be used for configuration, then someone needs to go back and fix this H747 LCD driver to be in alignment with the direction of the STM32 tool chain.
