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.

RTOS/CC1310: How to reduce CC1310 SPI transfer delay

Part Number: CC1310
Other Parts Discussed in Thread: DAC7811EVM,

Tool/software: TI-RTOS

Hi,

I'm trying to use CC1310 to control my DAC7811EVM,

so I used SPI MOSI to send my digital value to DAC7811EVM.

The purpose in here was repeated this process as fast as possible.

But I found that CC1310 over a complete SPI transfer to next transfer had a 17.43us delay.

Could it had any way to reduce this transfer gap?

  • Are you using our SPI driver using the UDMA controller? From the following post it looks like it should be fully possible to transmit back-to-back:

    e2e.ti.com/.../785623

    Siri
  • Hi Siri,

    I modified the example "spimaster_CC1310_LAUNCHXL_tirtos_ccs" from the official provided.

    The following was the main part of my code, so could it possible be more shortly in the SPI gap delay?

    I try to use a while loop to sending SPI repeatedly. 

    I wonder that if it always exist this delay just because I used the RTOS, or maybe I should try the noRTOS version?

    Thanks

    Best Regards

    void *mainThread(void *arg0)
    {
        SPI_init();
        SPI_Handle      masterSpi;
        SPI_Params      spiParams;
        SPI_Transaction transaction;
        bool            transferOK;
    	int8_t 			flag=1;
        int32_t         status;
    
        /* Open SPI as master (default) */
        SPI_Params_init(&spiParams);
        spiParams.frameFormat = SPI_POL0_PHA0;      //must be (SPI_POL0_PHA0)
        spiParams.mode = SPI_MASTER;
        spiParams.dataSize = 16;
        spiParams.bitRate = 12000000;        //4M
        masterSpi = SPI_open(Board_SPI_MASTER, &spiParams);
    
        while(1)
        {
            /**************** DAC7811EVM *******************/
            if(flag){
                masterTxBuffer[0] = 0x1800;
                flag=0;
            }
            else{
                masterTxBuffer[0] = 0x177F;
                flag=1;
            }
            /***********************************************/
    
            //Clean MOSI/MISO Buffer
            memset((void *) masterRxBuffer, 0, 1);       //SPI_MSG_LENGTH
            transaction.count = 1;      //SPI_MSG_LENGTH
            transaction.txBuf = (void *) masterTxBuffer;
            transaction.rxBuf = (void *) masterRxBuffer;
    		
            /* Perform SPI transfer */
            transferOK = SPI_transfer(masterSpi, &transaction);
        }
    
        SPI_close(masterSpi);
    
        return(NULL);
    }

  • the reason it take so long between each byte is that yo set transaction.count to 1. If you want to transmit for example 5 bytes as fast as possible, you need to set transaction.count to 5 and write all the bytes you want to transfer to the masterTxBuffer. Is you run the example without modifications, you will see that 30 bytes are sent back-to-back (SCn held low for the entire transfer). If you reduce the SPI_MSG_LENGTH to a number below 10, you will not use the DMA anymore, and there will be a delay between the bytes, and CSn is pulled high between each byte. I measured the delay between each byte to be. If you want to use the DMA when sending less than 10 bytes in a transfer, you can simply reduce minDmaTransferSize to a number below 10.

    Siri
  • Hi Siri,

    If this really the limit of CC1310 SPI, and I would tried other ways to resolve it.

    No matter what, thanks for your help.

    Best Regards

  • Not sure I understand your comment. You can use the CC1310 SPI to transmit packets without any delay between each byte, and I just explained you how to do that.

    Siri
  • Siri,

    My aim in here was let my CC1310 "repeatedly" and "unlimitly" communicated to DAC7811EVM by SPI.

    I followed what you said that increase the "transaction.count"  up to 126bytes. (Actually idk why the max length in here is 126 bytes)

    The sky blue curve was the DAC7811EVM analog output.

    It seemed that it could be updated in time, but the serious problem was the curve wasn't continued.

    Over a SPI action to next SPI action , it would have a  "delay" between it.

    I just want my DAC7811EVM output could be a continue waveform, and as higher sample rate as possible.

    Could you please give me some recommend of how to deal this problem?

    Or the only way I could used was put this SPI "delay" time to be sample time of my DAC7811EVM? (but I think the efficiency would not be very well...)

    Best Regards

  • Not sure where the 126 bytes comes from. The UDMA controller only supports data transfers of up to 1024 data frames. A transfer with more than 1024 frames will be transmitted/received in multiple 1024 sized portions until all data has been transmitted/received. A data frame can be 4 to 16 bits in length.

    That means that you can have 1024 data frames of 16 bits each transmitted back-to-back, without any delay in-between. After these 2048 bytes has been transmitted, there will be a delay before the next 2048 bytes are transmitted.

    Siri

  • Siri,

    I think I could get your point, thanks for your help.

    Best Regards,
    Victor