I’m playing with AdaFruits 320x240 ILI9340 hooked up to one of my cores.
All the library code is illuminating, if a little odd as some setup code doesn’t map to the data spec sheets, but if you take it out the display looks bad.
Trying to do some some optimising on the library - mainly around shuttling chunks of data to the display and so trying to us the SPI transfer call using the DMA.
The firmware documents detail a call for SPI.transfer() that takes a tx_buffer, rx_buffer, size and callback handler, using the DMA.
// INO file // In global int RowBufferByteSize = 480; // 240 rows, 2 byte per pixel byte RowBuffer; // needed hard-coded number for compiler? // In screen clear function (c is passed in so I can change it and see action of call) memset(RowBuffer, c, RowBufferByteSize); SPI.transfer(RowBuffer, NULL, RowBufferByteSize, NULL); // Syncronous as callback is NULL
However, when I call it, it appears no data gets pushed over the interface. The screen stays set as it was, no change at all.
If I pass a byte at a time, it’s all fine, but that seems a pretty inefficient way to use the SPI sub system.
I’m just about to dig out the scope to check this, but the reaction from the screen appears that this call is actually just a stub and as I’m pretty new to the SPI interface (I’ve only used the I2C and GPIO on the Cores so far as access control systems for work), I thought I’d drop a line into here before digging into the code base.
From looking around on here it looks like the SPI DMA calls are implemented to communicate with the WiFi module, so I thought it’d be coded, but wanted to tap the knowledge of the community