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.

CC3220MODA: Interfacing ADS8866

Part Number: CC3220MODA
Other Parts Discussed in Thread: ADS8866, CC3200

I am using the SPI interface to connect up to the ADS8866 ADC. I've set this up with the ADS886 in 3-wire mode, keeping DIN high which means that upon negative slope of the CONVST signal, data is available for clocking out with the SPI clock.

My code uses a timer interrupt running at 41kHz. The interrupt service routine sets the CONVST signal low and immediately thereafter calls SPI_transfer(). It works sort of; the delay between CONVST going low and the actual SPI clock starting is close to 9us - thats dang slow. What is the delay I can expect in the SPI_transfer() call?  If this 9us delay is sort of normal for that function, is there a way to speed this up?

Channel 1 (yellow) = SPI clock

Channel 2 (blue) = ADS886 data out

Channel 3 (yellow) = sample clock / ADC CONVST in

  • Hi,

    If you are looking to use the SPI drivers as-is, 9us is about as quick as you can expect for the SPI clock to be enabled and data clocked out. You're running the SPI_transfer() from an ISR already, so it's highest priority.

    You could try to optimize the SPI_transfer() function, especially if your use case is very rigid, to remove things like sanity checks, redundant setup, etc. . The source for the function can be found at source/ti/drivers/spi/SPICC32XXDMA.c, at SPICC32XXDMA_transfer(). However, the issue with modifying the driver is that the SPI transfer function will be used by the Wi-Fi host driver as well to interface your main MCU with the NWP over SPI. So you'll have to carefully test the Wi-Fi functionality if you were to modify the SPI drivers.

    Another alternate approach is to control the SPI interface without using the TI drivers, but using the low-level driverlib calls to write to the SPI registers and setup the DMA yourself. This could further reduce overhead, but implementing the code to perform the SPI transfers will be quite a bit of effort. There is a SPI example in the CC3200 SDK that uses this low level driverlib code that you can use as a reference. The SPI peripheral hardware as well as the driverlib API is common across the CC3200 and the CC3220.

    I suggest that you try to optimize your system so that a 8us delay is acceptable, but if it isn't then please try investigating the methods I describe above and see if they're suitable.



  • Hi Michael, thanks for your thoughts. I did think of optimizing the SPI_transfer() call also but backed off because of the amount of code and level of intertwinedness (new English word) with WiFi. Writing low level driver code myself I want to avoid also. I've been using the ADS8866 3 wire mode, but perhaps have more/better timing options with the 4 wire mode - I have some ideas.

    Since I had my eyeballs on the scope all day long I actually never looked at the sample values that SPI_transfer() returned. They are all zero!  The call to SPI_transfer() does not fail but the values are a big fat 0.  The scope picture clearly shows the ADS8866 spitting out data at the rate of the SPI clock and so the transfer should have _some value_.  Any idea what might be going on/what I should check for?

  • Thoughts on SPI_transfer() returning zeros?

  • Hi,

    Have you checked to ensure that when setting up the SPI interface you have set it up with the correct clock phase/polarity frameFormat?

    Also, have you ensured that you have selected the correct pin for MISO? If you see the data coming in correctly on your scope but the SPI driver returns all 0s, those are likeliest reasons why.



  • Going over my inputs again, yes I made that rookie mistake MISO wasnt hooked up properly :-)