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.

ADS1256: SPI Interrupt Handling for ADS1256

Part Number: ADS1256

HI TI,

I am using ESP32 Thing as Master and ADS1256 as slave on an SPI connection. ESP32 is capable of FreeRTOS.

I know that ADS1256 has a DRDY pin that we could connect it to a hardware interrupt pin on ESP32 for data transmission. However, ADS1256 also provides its own SPI interrupt

"ESP32 SPI generates two types of interrupts. One is the SPI interrupt and the other is the SPI DMA interrupt.
ESP32 SPI reckons the completion of send and/or receive operations as the completion of one operation from
the controller and generates one interrupt. When ESP32 SPI is configured to slave mode, the slave will generate
read/write status registers and read/write buffer data interrupts according to different operations."

The above quote from the user manual makes me think that the SPI interrupt function on ESP32 is triggered only after the data transfer (send/receive) is complete. I guess this is useful when we want to process data after we receive the bytes.

Is it logical to use two interrupts, one with the DRDY going low and the other with the SPI interrupt function? Will this be an interrupt (data transfer completion) inside another interrupt (data ready for transfer)

So far it makes the most sense to me to setup a hardware interrupt for the DRDY Pin going LOW, but I don't really find any use of the SPI interrupt function.

Thanks,

Khoi Ly

  • Hi Khoi,

    Unfortunately I am not too familiar with the ESP32, so if you have questions specific to that device you may need to contact the company that makes that device for help.

    However as it relates to the ADS1256, the /DRDY signal is generally what is used to initiate a data read operation. The falling edge of /DRDY indicates to the MCU that it has data available to read from the ADS1256 (after reading the data your MCU may generate additional SPI interrupts to indicate that the SPI peripheral is no long busy or to trigger a DMA transfer, but those are internal functions that you can decide to use or to ignore if not needed).

    How you handle the GPIO interrupt in software is also up to you...you can read the data directly in the GPIO interrupt routine, OR you could just set a flag and exit interrupt (allowing some other part of your code to decide what is the next highest priority task to run). The advantage of the first method is that is handles the interrupt immediately; however, if your MCU has other high-priority tasks to complete, then you would probably want to go with the second method to minimize the amount of time spent in each interrupt.