STM32: Using Port C or D for D0-7 for 8 bit parallel mode performance boost

[Bodmer]

Using a single port on STM32 processors for D0-7 reduces the bit manipulation required and thus improves rendering speeds for the 8 bit parallel interface.

The master branch library already supports use of Port A or B for the performance boost. The facility to also use Port C or D has been added to the library master copy.

Note that the 8 bit data rate when a single port is used like this improves rendering performance but the data rate may then exceed the capability of the display. This is particularly a problem when the fast clock rate processors like the STM32F767 are used. To mitigate this timing problem there are features built into the library driver to adjust the timing. This adjustment may need to be done on a case by case processor/ display combination. For some of the STM32 Nucleo and "Blue/Black Pill" boards in combination with certain displays this tuning has been done here. In some cases this tuning exceeds the manufacturers quoted data rates and thus the default timing values may need to be adjusted.

For maximum reliability the timing should be adjusted to meet the display data sheets values. Larger dalays may be required to bring the clock rate down for some displays, start with the maximum delay settings and ideally use an oscilloscope to verify the timing complies with the data sheet.

[CNC-Designs]

I am using port D on an STM32F417. The display I'm using is an Adafruit 3.5" with a HX8357D driver. This new branch works great and gives at least 3x faster refreshes when I was able to assign it to port D.

I did try the ILI9341 driver (on my same HX8357D display) and noticed that performance increased when using the regular, master branch, where I was not using port D. But if I try to use the new implementation with port D, the display stays all white and never shows any graphics with the ILI9341 driver. Now this is probably because I'm not using the right driver, but I'm curious if you have an idea of why the ILI9341 driver works with the master branch on my HX8357D display, but not with this branch using port D. It could be for the reasons you stated above and the timings aren't right anymore, but with the master branch they are close enough between the HX8357D and ILI9341 to work.

So there's not really an issue here, it's more that I'm curious if there could be a little extra performance to be gained since the display is faster using ILI9341 and the main branch, even though it should be a HX8357D chip on the display.

[Bodmer]

The correct driver should be used for the display. Sometimes the correct settings are already loaded in a display and using the wrong driver works until the display is power cycled. It is not a good idea to use the wrong driver.

The performance for whole screen updates will be proportionate to the number of pixels updated. An ILI9341 has a maximum of 240x320 so takes half the time to clear the screen compared to a 320x480 display. So the results depend on the test.

Also some displays accept lower delays in the tuning value and this is taken into account for those displays I have tested. Hence this line. An HX8357D has not been tested and thus the default delays are set to "slow" here to be safe.

[Bodmer]

The feature has been added to the master branch and the temporary test branch has been deleted.