ADS1248 reading digital inputs problem

Hi Alexandra,

It appears as if you are communicating correctly, but I can't verify or determine the output result as I can't line up the edges of the data to tell what is exactly being clocked out of the device (nor can I tell what is being written to the device).  The default startup operation of the ADS1248 is RDATAC mode.  I would suggest that after the RESET command is sent (and you must wait a minimum of 0.6ms after the reset command is sent before the next SPI command) you send the SDATAC command.  This will stop the automatic posting of conversion results to the output register.  The SDATAC command will not take effect until after the next conversion is complete.  Even if SDATAC has been issued, you can still get corrupted results if the data has been posted to the output register while you are trying to read register data if the device state machine has not finished the conversion cycle to enter the SDATAC mode.  This can be confusing.  Issuing SDATAC right away should prevent this condition as writing to the registers will have no negative impact, and hopefully by the time you wait for the DRDY pulse, the ADS1248 should then be in SDATAC mode.  Leave the device in SDATAC mode and use the RDATA command to read the conversion results.  This will make sure you are using the correct timing and you should have the expected GPIO read.

Best regards,

Bob B

Thanks, Bob, I'll try reading data in SDATA mode and asking for the GPIO after reading.

Hi Bob,

Thanks for your suggestions, I'll work on RDATA mode, it looks it may give me less problems.

I just changed my firmware to work without RDATAC mode. Now the algortih is (to read a Pt100, I'll ask for GPIOs later, since this readings are giving me problems)

• Initialization at power-on: 
  • Reset (write 0x07) to the ADC.
  • Wait 1ms.
  • Write 0x16 (SDATAC)
  • Write Register 0x02 = 0x30
  • Write Register 0x03 = 0x02
  • Wait for ADCDRDY pulse (acknowledge)
  • Write Register 0x0A = 0x02
  • Write register 0x0B = 0x2F
  • Wait for ADCDRDY pulse (acknowledge)
  • Write Register 0x00 = 0x01
  • Write register 0x03 = 0x51
  • Wait for ADCDRDY pulse (acknowledge)
  • Self offset calibration.
• On DRDY pulse:
  • Send command 0x13.
  • Read using 24 clock pulses.

I have many different readings at the output. Find attached some of the results, as well as the SDATAC command.

What am I doing bad? Is it correct to wait for a DRDY pulse, is it better to put a 0.5ms delay between the commands o any other delay?

Thanks.

Hi Alexandra,

You may have some confusion as to the meaning of DRDY.  DRDY is Data Ready from the completion of a new conversion cycle.  When the DRDY transitions from high to low, the latest conversion data is ready to be read from the device.  So it is always best to read the conversion data based on the DRDY.

There are a couple of things that may be confusing your results.  One is you are actually sending 25 clocks instead of 24 after the RDATA command (0x13).  I also noticed that in WP_RDATA_2 that the command byte has a stretched clock which violates the duty cycle for the ADS1248.  How are you controling CS on the ADS1248?

Best regards,

Bob B

Hi Bob,

So I should wait for 0.513ms between commands instead of waiting for a DRDY?

I'll keep an eye on those 25 cycles and will make 1 less. The strecched one is because another interruption on the microcontroller has interupted the reading interruption. Is this so crytical? If so, I'll change my interruption settings. (I have interruptions for 3 timers and the ADC, i'll change priorities).

I'm not controlling CS because there were not many pins and the ADC is "alone" in my SPI bus.

Hi Alexandra,

If you issue the SDATAC command, there is no need to issue a delay between commands.  The stretched clock and the 25 clocks instead of 24 will cause you many issues.  The SPI interface for the ADS1248 works in byte sequences.  A stretched clock confuses the state machine.  Another confusion occurs when you issue 3 bytes of clocks and then issue another clock.  This has the similar effect of stretching the clock but in a major way as the 25th clock relates to the next byte sequence.  We have no idea what data is sent back or how the internal buffer of the ADS1248 is being loaded.  The best case scenario is you shift the data by one every read cycle.  The commands are lost as well as the data because of the clock shifting.  Toggling CS will remedy this problem as well as sending the correct clocking pattern.  If you tie CS to DGND, then you must make sure you are sending the correct number of clocks to represent the data you are communicating.

Best regards,

Bob B

Hi Bob,

Everything is working fine!! I adjusted the interrupts so the communication in ADC is the most prioritary and remade the clock loop, so the clock now is accurate in time and number! Thanks for your support! 5 stars!