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.

ADS8661: ADS8661 Application Note

Part Number: ADS8661
Other Parts Discussed in Thread: ADS8688, ADS8674, ADS8665

Hi All,

I bought a ADS8661 . I want to program this device but I couldnt find any Application Note for development. Is there any example or any code for the program.


  • Is there anyone else using this IC ?

  • Hello Fatih AKSOY,

    Unfortunately, we do not have a published example software code for the ADC ADS8661, but we do have a source code(.c) for ADS8688 which has similar internal front-end and SPI interface as ADS8661. Please refer to the web links for details:

    There is app note under ADS8661 product folder to understand associated errors for ADC with AFE which cover ADS8661 device, fyi:

    Please let me know if you need any further support.



  • I'm using the 8674 (14 bit, multi channel) which is similar to the 8661 in concept.

    A quick peek into the 8661 data sheet showed that for basic operation, it is quite straigthforward to use.
    After a power cycle/reset, all the default values are properly set for simple conversion operation. The device can be queried for conversion results out-of-the-box. If you use the default range (+-12V), you don't need to care for any of the configuration registers.
    And if you use standard SPI protocol, there are no surprises. Just standard SPI with a chip select line and two bytes per transfer while the chip select is low.

    To start a conversion/get the result, you simply make a 16bit transfer of any content (considered as NOP, as it is not 32bit for a valid register read ior write command) to trigger a new conversion, wait the maximum conversion time, then send the next NOP command (triggering the next conversion) while at the same time receiving the result of the last conversion in the 12 MSBs of the received 16 bit.
    Keep in mind that conversion starts at the rising edge of CS, so when you send a NOp command, you get a conversion result form right after the last NOP you sent (which might be stale if your last transmission was some time ago). You always have to start with a NOP and discard the received DATA, continue with NOPs while receiving data and end with an additional NOP to get the last conversion result.

    You may replace the delay of max conversion time with checking the RVS pin (goes low when CS goes low, and goes high when the conversion is complete) if you want. So you can automate querying the results by a port pin interrupt for the rising edge of RVS. Note that after conversion is done, a minimum acqusition time of 550ns is required, which starts when RVS goes high. It is matched with the 16 NOP command SPI clock cycles when SPI clock speed is 29MHz or less for the 8661 (16MHz for the 8665 for 1000ns)

    If you need a different input range, you need to set the range control register with a single 32bit write command once after each power-cycle / reset.

    how to use the SPI interface of your MCU depends on the MCU you use. And extracting the 12 MSBs from two received bytes and converting this value into a voltage value should not require any help.

    (p.s.: I'm not back to active work at E2E. I'm just answering this post because I got your friendship request and noticed that this is the initial question that brought you to E2E - reminding me of the reason why I entered E2E about 9 years ago)
  • Hi Jens,

    Thanks for your post, but ADS8674's timing is a little bit different from ADS8661'S timing. ADS8674 starts the conversion at the falling edge of /CS with following 15 during the conversion,  ADS8661 can start the conversion at the rising edge of CONVST/CS signal but does not need SCLK clocks and any DATA on SDI during the data conversion, this is different. Also, the SPI interface on ADS8661 is multiSPI which is a very flexible serial interface.

    Hello Fatih AKSOY,

    Please check ADS8661 datasheet.. If you have any question to use this ADC, please let me know, I will be happy to help and support you.



  • Dale, I was explicitly referring to the ADS8661/5 and their timing. However, I erroneously took the conversion time, not the acquisition time for the calculation (on the ADS8665, both are the same anyway).

    Of course, the device doesn't need SPI clocks for its operation, and I didn't mean it. My example just meant that at a certain maximum SPI clock, you can start sending the next NOP/reading the conversion result) and after these 16 SPI clock cycles, the required acqusition time has already passed and the conversion, starting with the end of this transfer, will give a valid result.
    If you use a higher SPI clock, you will have to delay the start of the next transfer beyond the RVS going high, so teh transfer doesn't end and therefore starts a new conversion before the required acquisition time has passed.
    It was not about the ADS needing the SPi clocks but rather synchronizing the SPI transfers with the required conversion timings so you don't have to care about them.
    It's 48MHz, not 29MHz for the ADS8661 due to me using the wrong timing.

    And even though the ADS8661 offers the multiSPI interface, it is an option, not a must, and requires additional configuration and software effort. I was speaking about a straight use without the need for studyiung applicaiton notes and writing libraries etc. After all, not many devices support it in hardware, so you'll need additional software to join the two parallel data streams, requiring CPU power and limiting the maximum useful SPI clock. This counteracts the speed gain. Using simple SPI with twice the SPI clock gives the same throughput and can be done in plain SPI hardware. Depending on the MCU it is the better way not to use multiSPI at all, and on any CPU, it is easier, since the SPI interface allows for 66.67MHz (and 48MHz is sufficient for maximum throughput and minimum handling overhead, 16MHz for the ADS8665)

    If your MCU runs in the low MHz instead of multi GHz, then having to care for timing often creates overhead that in the end reduces the maximum throughput. And in any case it increases the coding efforts and possible problemsBugs. Why not letting the hardware do as much of the job as possible?
  • Hi Jens-Michael!

    Thank you for your insightful comments! We'll take this into consideration for future generation devices.