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.

CC3100 UDP Throughput

Other Parts Discussed in Thread: CC3100, CC3200

Folks, I am evaluating the use of the CC3100 for a UDP streaming application and I am unable to get more than 4.5Mbps using the SDK UDP example and Iperf. I am using the Tiva C launchpad at 80MHz with the CC3100 boosterpack, and I have increased the SPI clock to 20MHz, and turned on all compiler optimisation.

In comparison, the same test on the CC3200 launchpad connecting to the same AP at the same distance (about 18") to the same wired iperf server works well and consistently at 11.4Mbps, which is good enough for my application, but I have concerns over the current lack of code protection in the first revision of the CC3200.

Has anyone had any success with higher UDP throughput with the CC3100?

  • I have, to a large extent, figured this out, and can achieve 13Mbps fairly consistently.

    The first problem was that the MPU was only running at 50MHz. That was fixed by changing the initClk function inboard.c, changing the SysCtlClockSet function:

        SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN
                |SYSCTL_XTAL_16MHZ);

    The SPI clock is set in spi.c in the call to SSIConfigSetExpClk, and I already increased that to 20MHz:

        SSIConfigSetExpClk(SSI2_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,
                SSI_MODE_MASTER, 20000000, 8);

    On the logic analyser there was a lot of space in between each byte. This is because of the way the spi_Write and spi_Read functions work, both in low level functional terms and in terms of the peripheral library overhead.

    These are my new functions.

    int spi_Write(Fd_t fd, unsigned char *pBuff, int len)
    {
    	int nLenOut=len;
    	int nLenIn=len;
    
    //    ASSERT_CS();
    	HWREG(GPIO_PORTE_BASE + GPIO_O_DATA + (GPIO_PIN_0<<2) ) = 0;
    
    	{
           	while (1)
        	{
        		if (nLenOut>0)
        		{
        			if ((HWREG(SSI2_BASE+SSI_O_SR) & SSI_SR_TNF)!=0)
    				{
    					HWREG(SSI2_BASE + SSI_O_DR) = *pBuff++;
    					nLenOut--;
    				}
        		}
           		if ((HWREG(SSI2_BASE+SSI_O_SR) & SSI_SR_RNE)!=0)
        		{
        	        HWREG(SSI2_BASE + SSI_O_DR); // Read Rx FIFO without assigning
        			if (--nLenIn==0)
        			{
        				break; // I hate "break" in a "while", but it saves unnecessary checks in the "while"
        			}
        		}
        	}
        }
    //    DEASSERT_CS();
    	HWREG(GPIO_PORTE_BASE + GPIO_O_DATA + (GPIO_PIN_0<<2) ) = 255;
    
        return len;
    }
    
    
    int spi_Read(Fd_t fd, unsigned char *pBuff, int len)
    {
    	int nLenOut=len;
    	unsigned char *pBuffEnd=pBuff+len;
    
    //    ASSERT_CS();
    	HWREG(GPIO_PORTE_BASE + GPIO_O_DATA + (GPIO_PIN_0<<2) ) = 0;
    
        {
    		while (1)
        	{
        		if (nLenOut>0)
        		{
        			if ((HWREG(SSI2_BASE+SSI_O_SR) & SSI_SR_TNF)!=0)
    				{
    					HWREG(SSI2_BASE + SSI_O_DR) = 0xFF;
    					nLenOut--;
    				}
        		}
           		if ((HWREG(SSI2_BASE+SSI_O_SR) & SSI_SR_RNE)!=0)
        		{
        	        *pBuff++ = HWREG(SSI2_BASE + SSI_O_DR);
           			if (pBuff>=pBuffEnd)
        			{
        				break; // I hate "break" in a "while", but it saves unnecessary checks in the "while"
        			}
        		}
        	}
        }
    //    DEASSERT_CS();
    	HWREG(GPIO_PORTE_BASE + GPIO_O_DATA + (GPIO_PIN_0<<2) ) = 255;
    
        return len;
    }

    There is still a tiny bit of delay in between each byte sent in an SPI stream, about one SPI clock cycle, so the SSI FIFOs never see more than one byte deep. although the code is written to take the FIFO into account. Looking at the dissassembly, I can see that it's only really running at about 40MHz instruction time, I assume at least part of this is because it's running in flash, but as a newbie to the TI ARM processors that'll take a bit more work for me to figure out. For 13Mbps, the modified spi.c is compiled at -O3 --opt_for_speed=5 but the rest is at -Ooff --opt_for_speed=2.

  • Howard,

    Apologies - I completely missed this thread. Let me know if you are looking for any information here.

    -Praneet

  • After further investigation I figured it out, thank you. I left the code fixes above, to help anyone else (and me when I come back to this in a few months time and forgot what I did!).