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.

ADC128D818: Continuous Conversion Mode implementation, when registers are stable.

Part Number: ADC128D818

I am using the ADC128 in continuous conversion mode.  We are getting bad data on the I2C line and are trying to decipher what it is from.  I am looking at everything from noise on the I2C line to  the stability of the registers when I'm doing the read.  The logic that I am using now is that I check the register on address 0x0C to see if the ADC128 is converting, if it is not I start reading my registers being used and have up to 5 reads on a giving ADC128 address.  The data that we are getting will have zero a lot of the time and will also have some other erroneous values that are somewhat random.  I think the zeros are coming for the register address getting corrupted on the way over and reading a disabled register which is zero; and, the other data to be either corrupted from the read or I2C transport.  I can see that the ADC128 takes 12.2 ms for a voltage and 3.6 ms for the temperature, so I am looking at 40-80 ms that the ADC128 is busy. 

 

The questions that I need answered are:

    1)  In the Continuous Conversion Mode, what sets off the next conversion cycle?  Is it on a timer or does a read trigger it.

    2)  What is the length of time between Conversion cycles?

    3)  If it is triggered off a read, does just that register do a conversion leaving the other registers safe for a read? (That makes no sense because you only have one busy bit)

   4)  Is only doing one Busy Status check and then doing 5 read register OK or do I need to do it before each register read, this would be a problem if the read triggered the Conversion cycle?

   5)  What happens if the Conversion cycle triggers before I am done reading all the registers?

Thanks,

Todd Horting 

ACT Inc.

  • Hi Todd,

    Welcome to our e2e forum!  Great questions on the ADC128D818!  Can you send over a screen short showing your I2C comms?

    The best place to start with this device is probably section 9.2.2.2.1.  Step 4 is where you would setup for continuous mode.  The typical use case would be to set the limit registers and then 'Start' the conversion process.  From there you are basically monitoring everything internally, based on the limit settings you applied.  So for Q1 - Conversions are started automatically, essentially a timer, and round-robin convert depending on what channels are enabled.  For Q2 - There isn't really a 'time between cycles' - the ADC128D818 will keep on going in continuous mode until you choose to stop.  Refer to section 9.2.2.2.6 in the datasheet, if everything is enabled, the cycle time to convert everything is ~40.2mS but the process just keeps on going.  For Q3, refer to section 9.2.2.2.9 - You can read conversion information through Channel Reading Registers 20h - 27h.  

    For Q's 4 and 5 - I don't think BUSY has an impact on accessing the Channel Reading Registers, and if you start reading a register where a conversion is taking place, the new conversion result should be written to the register after the communication is complete.

  • Thank you Tom.  This is my interpretation of the documentation and your answers to what my concerns/questions, please correct me where I am wrong.  

    If I am using all the registers to convert data to voltages it can not be done in ~40.2 mS (This is only for 3 voltages and 1 temp so 3 * 12.2 + 3.6) and not the following formula for mode 1, (section 9.2.2.2.6): 8 register * 12.2 mS/register for 97.6 mS, so worst case that I have is ~100 mS per cycle unless there is parallel processing.  The concern of reading data while a write is taking place I am hoping is protected by a hardware semaphore so I will not get data that is corrupted of being shifted in or unstable by the write.

    Todd

  • Hi Todd - 

    The ADC128D818 was intended to be a 'system monitor', so basically a means to set up multi-channel ADC and then passively observe anything that runs outside of some pre-defined limits.  You should not get corrupted data while reading if a conversion is ongoing, but it may not be the latest conversion result.  If you want to actively observe each and every conversion result 'real time' then you could possibly use the device in one-shot mode or we could help you find an alternative that better suits your application needs..