Hi
I am running a small TFT LCD display on SPI from DA14580 - SPI clock running @8MHz, and I am trying to send data over SPI to display. I observed that in a stream of continous write to SPI port, there is still a gap of 4.8uSec between the two 8-bit data sent over the SPI. Actual data of 8-bit takes about 1uSec but the gap between the two data bytes is 4.8uSec and hence the complete data transfer is 5times longer than expected (i have attached the image showing the oscilloscope image)
How can I reduce this gap? There is no other routine in the code at this time, the SPI interrupt is disabled. I need to run this data trasnfer as quickly as possible, my estimate is about 40mSec but with this gap, it takes about 200mSec or more. Can anyone help me please..?
thanks in advance:)
Silas
Hi SilasValera,
Please have a look at this posthttps://support.dialog-semiconductor.com/spi-master-better-performance
Thanks MT_dialog
Hi MT_dialog
Thanks for the link and the information in there :) I used that approach and it worked perfectly fine!
For now I am testing the peripherals with this approach for SPI, I also have devices on I2C and GPIO ports. My next question is : how the would the system behave finally with the sleep mode on and with BLE connection to smart phone (or other app) now that there is no latency for SPI data transfer since the processor is busy on SPI ? Also when the interrupts are enabled?
thanks in advance
Silas Valera
Hi SilasValera,
I dont get your point and the question is very generic, the fact that the SPI has no latency doesn't affect the BLE, the BLE behaviour of your system i suppose that will remain the same with or without the SPI latency, the 4.8usec that your system stalled weren't there in order for the processor to execute BLE commands. And also what do you mean when the interrupts are enabled ?
Thanks MT_dialog
Hi MT_dialog
Thanks for your reply. What I mean is that since this approach does not allow for the latency, the response of the system to any other important functions would not be affected, correct? Also no delay in serving the interrupts?
thanks
Silas Valera
Hi SilasValera,
The fact that the SPI implementation had some latency doesn't mean that the latency was there in order to allow for BLE events to occur, if that is your concern. In any case you will have to make sure that the SPI transaction dont take too much time in order for the system to schedule upcomming events, but this doesn't have to do with the SPI latency, theoretically the response of your system should remain the same, i dont see anything that could be affected.
Thanks MT_dialog
Hi MT_dialog
Thanks for your reply. So happy to learn that this approach is not going to affect any other system functionality or response time to BLE events. At this time my guess is that any LCD refresh/write toutine over SPI is not expected to be greater than 50ms.
Thanks again for your help and right approach.. :)
Silas Valera
Hi SilasValera,
Just to be clear, if your routine lasts for 50 ms then the interaction between the 580 and the SPI interface it will take long enough, you will have to schedule the next BLE connection event (as mentioned in my previous post) in order for the BLE event to occur. You will have to make sure that your connection interval (the time between succesive connection events) is more than your SPI interaction, in order for the 580 to finish the SPI interaction and schedule the next BLE event.
Thanks MT_dialog