• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 599 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Data Polling from End Device - CPU time?

DMMT
Intellectual 420 points
Other Parts Discussed in Thread: CC2530

Hi All,

My system mainly utilizes two functionalities: UART SPI and RF

When my end device polled at 1000 ms intervals (100 ms - queued poll rate; 100 ms - response poll rate), my SPI communications (CC2530 is slave- 375 KHz SPI clock) seem to operating properly.

However, we have been fighting issues in which we are trying to speed up the system throughput because each "request" requires about 395 98-byte packets. Therefore, I started playing with the poll rates and as I started speeding up the queued poll rates to an extreme of 1 ms.... it seems that my SPI data is becoming corrupt (ie dropping bytes)...

Therefore I am trying to understand what really occurs when an ED polls for data and how much CPU time is taken up... My theory is that each poll request from the ED takes a certain time for the coordinator to process, and that during that time, the CPU is held up and cannot process the SPI IRQs in time....

Any insight into this problem would be greatly appreciated.

Thank you.

 

  • 0
    Intellectual 805 points

    Hello DMMT - I think that your theory is spot on. The insight to the problem is this: a SPI slave can never rely on CPU ISR, you must use a DMA channel if you want to ensure loss-less SPI transactions. In order to reliably implement a SPI slave using only CPU ISR, you would have to be able to deterministically determine (sounds redundant, I know, it probably is) the combined maximum ISR latency in all other higher priority interrupts. Because you are working with a 3rd party library (namely the TI ZStack) which uses higher priority interrupts, you cannot ensure or control or even measure (at least not very easily) the maximum latency in higher priority interrupts. Thus, working around the obstacle of an in-determinant higher priority interrupt by using a DMA channel to feed the SPI is the solution to the problem - wu wei.

  • 0 in reply to codesmith
    Intellectual 420 points

    Hi codesmith,

    Thanks for your reply. Could you possibly tell me where I can find a good example of setting up the DMA channel for SPI?

    Thanks.

  • 0 in reply to DMMT
    Guru 31280 points

    Hi DMMT,

     

    Edit: Try DN113

     

    Br,

    Igor

  • 0 in reply to DMMT
    Intellectual 805 points

    Also, I see that there is an implementation of UART by DMA, so with minor modifications, the C-code should easily support SPI:

    C:\Texas Instruments\ZStack-CC2530-2.5.0 - Copy\Components\hal\target\CC2530EB\_hal_uart_dma.c

    And the more I think about it - the SPI by DMA should be very much more simple than the UART by DMA because bursty SPI transactions should be coordinated by a SPI master/slave ready handshake line(s). Unless you are taking on the task of creating a SPI slave that is always ready for a max message size at max rate. On your SPI protocol, when considering whether or not to implement a master/slave ready handshake, you will need to consider whether your SPI transactions should be single duplex or full duplex or either.