Issue with TFT lcd screen speed

Question

I am using TFT LCD screen (ILI9163c - 160*128). It is connected with athros AR9331 module with spi. Athros AR9331 is running with OpenWRT linux distribution. So, I am driving my LCD with spidev0.1. While filling screen or writing any string on LCD, it is taking too much time to print. So, what can i do to get sufficient printing speed.

Thanks.

This is the function i'm using to write data on spi pin using spidev...

void spi_transactor(unsigned char *write_data, int mode,int size)
{
    int ret;
    struct spi_ioc_transfer xfer[4];

    unsigned char *init_reg;
    init_reg  = (unsigned char*) malloc(size);
    memcpy(init_reg,write_data,size);

    if (mode)
    {
        gpio_set_value(_rs, 1);    // DATA
    }
    else
    {
        gpio_set_value(_rs, 0);    // COMMAND
    }

    memset(xfer, 0, sizeof xfer);

    xfer[0].bits_per_word = 8;
    xfer[0].tx_buf = (unsigned long)init_reg;
    xfer[0].rx_buf = 0;               //( unsigned long ) &buf_rx[0];
    xfer[0].len = size;               //wlength + rlength;
    xfer[0].delay_usecs = 0;
    xfer[0].speed_hz = speedx;       // 8MHZ
    //xfer[0].speed_hz = 160000000;    // 40MHZ
    ret = ioctl(spi_fd, SPI_IOC_MESSAGE(1), &xfer);

    gpio_set_value(_rs, 1);
}

Answer 1

The main performance issue here is that you make a hard copy of the data to send on the heap, every time the function is called. You also set up the communication parameters from scratch each time, even though they are always the same. To make things worse, the function has a massive bug: it leaks memory as if there's no tomorrow.

The hard copies aren't really necessary unless the SPI communication takes too much time for the program to sit and busy-wait on it to finish (rather likely). What you can do in that case is this:

• Outsource the whole SPI business to a separate thread.
• Create a work queue for the thread, using your favourite ADT for such. It should be a thread-safe FIFO.
• Data is copied into the ADT as hard copies, by the caller.
• The thread picks one chunk of work from the ADT and transmits it from there, without making yet another hard copy.
• The thread waits for the SPI communcation to finish, then makes sure that the ADT deletes the data, before grabbing the next one. For hard real-time requirements, you can have the thread prepare the next message in advance while waiting for the previous one.
• The communication parameters "xfer" are set up once by the thread, it just changes the data destination address from case to case.