Driving an ILI9163c based display with the NUCLEO-F446RE (+library questions)

[Vex1]

As per the question I'm trying to run a ILI9163c based display on the NUCLEO-F446RE. I'm using this library: (https://github.com/Spirit532/ILI9163C_STM32_HAL_DMA). My questions are:

• The library tells you to put DMA into circular mode. However, after every SPI transmit complete event it calls HAL_SPI_DMAStop. Isn't the entire point of putting it in circular mode to leave it running constantly. I thought it might be to avoid having to manually reload the DMA_SXNDTR register but won't calling HAL_SPI_Transmit_DMA to start DMA back up again reload it anyway. The interrupt handler is as follows:

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) {
	SPI_DMA_CNT--;
	if(SPI_DMA_CNT == 0) {
		HAL_SPI_DMAStop(&hspi1);
		SPI_DMA_CNT = 1;
		SPI_DMA_FL = 1;
	}
}

• Related to the previous question what is the point of the SPI_DMA_CNT variable. It isn't incremented or decremented anywhere else in the program. I'm not sure what it's suppose to do.
• I would like to use the F446RE at or close to it's maximum clock frequency i.e. 180MHz. However, when I try to change the clock frequency the display no longer seems to receive any data. The only time the display works is when I put the SPI baud rate at 2MBit/s and set all the configurable clocks to 32MHz. Funnily enough setting the baud rate to less than 2MBit/s also seems to stop the display working. What am I missing here? Is the baud rate not what controls the rate of the transaction. Is it because I'm using DMA? Does the DMA clock i.e. AHB/APB2 influence the rate of the transaction?
• How do I figure out what the maximum SPI frequency the ILI9163c can operate at is. The ILI9163C datasheet (in table 17.3.2.2) has a serial clock cycle (read) value with a minimum of 150ns. Does this mean that (assuming you want to read and write at the same frequency) the maximum frequency is ~6.67MHz?

This question is a bit of a mess. I'm sorry. I don't know how to present the questions in a clearer way; largely because I don't know what information is relevant and what is not.

Thanks.

[MM..1]

As first with display you need choice mode of operation. Full screen refresh or only changes ( if LCD have own framebuffer)

After this calculate for desired framerate amount of data, for example RGB888 over SPI on 60Hz 640x480 == 55MB/s in serial x8 = 443MHz SPI

As you can see this is over normal SPI. ... But this is only example.

And CNT is for block prepare in time when HALF buffer complete interrupt is used.

[Vex1]

Hi,

• As first with display you need choice mode of operation
  • It's running as a full screen refresh
• for example RGB888 over SPI on 60Hz 640x480 == 55MB/s in serial x8 = 443MHz SPI
  • Can you please run me through your math there. My display is 160 x 128 (16bit colour) so 160 x 128 x 2 = 40960 bits / 8 = 5120 Bytes * 60Hz = 307 200 B/s = 0.3072 MB/s. Which seems wrong. The display is being set to DIVA = 8, VPA = 8 (I can't figure out what these values represent on the display). The formula in the datasheet says this gives a framerate of 99.21Hz which seems very fast to me.
• And CNT is for block prepare in time when HALF buffer complete interrupt is used
  • What does block prepare mean?

Thanks

[MM..1]

You have mismatch in bytes and bits.
Right is 160 x 128 x 2 = 40960 bytes x 8 = bits per frame x 60 = bits per sec ... MHz
DMA in circular mode always work in two block .. first half buffer and second half buffer..
in time when first half is complete then can be prepared new data in...

[Vex1]

Ah yeah I messed up my bits and bytes. But I still can't see how you got 55MB/s. Can you explain how you got that value?

[MM..1]

RGB888 is three byte per pixel then 640x480x3X60 is bytes per sec try use calc on my is 55296000

[Vex1]

Got it. I didn't realize it was 3 bytes per pixel :D Thanks

[Vex1 · Accepted solution]

So I think I figured out part of the reason why changing the CLK was causing issues. I was under the impression that SPI was blocking i.e. it would just busy wait until it was finished transmitting...However, it appears that by increasing the clock frequency it was causing the CS (chip select) line to go high before the SPI transmission was complete. Adding an asm("nop") before driving the CS line high seems to have fixed the issue.