ADS1256: One-shot mode with SYNC#/PDWN# pin instead of WAKEUP command?

Hi Niclas,

Yes you can use the SYNC/PWDN pin to control conversion timing. This is described on page 20 of the datasheet and shown in Figure 18. Using synchronization will continuously convert data on the selected channel however - this is mentioned on page 22 in the datasheet. You would have to issue the STANDBY command again to stop the conversion process, or you could simply ignore the additional conversions until you are ready to toggle the SYNC/PWDN pin again.

Please keep in mind the timing requirements for SYNC/PWDN, t16 and t16B. This other e2e posts describes some of the challenges in meeting this timing: https://e2e.ti.com/support/data-converters/f/73/t/218644

-Bryan

Hi Bryan,

Sorry if I was a bit unclear. This especially relates to one-shot conversion mode (for reduced power consumption) and exiting STANDBY.

Page 37 of the datasheet says "To exit Standby mode, issue the WAKEUP command. This command can also be used to perform single conversions (see One-Shot Mode section) ." and "After issuing the STANDBY command, make sure there is no more activity on SCLK while CS is low, as this will interrupt Standby mode."

Page 22: "A dramatic reduction in power consumption can be achieved in the ADS1255/6 by performing one-shot conversions using the STANDBY command; the sequence for this is shown in Figure 20. Issue the WAKEUP command from Standby mode to begin a one-shot conversion."

Page 20 and figure 18 don't mention standby mode, so based on the p37 and p22 quoted texts my assumption was that the SYNC#/PDWN# pin is for starting a measurement in continuous conversion mode only. If the waking up is actually caused by SPI clock activity when CS# is low, the SYNC#/PDWN# will not wake up the ADS1256.

However, in continuous conversion mode the SYNC#/PDWN# pin -> LOW -> HIGH transitions seem equivalent to the SYNC and WAKEUP command sequence so I thought I should double-check. Does the SYNC#/PDWN# pin -> LOW -> HIGH transitions wake up the ADS1256 from standby mode?

(The timing aspect will not be an issue here.)

Best regards

Niclas

Hi Niclas,

Out of curiosity, why did you not want to issue the WAKEUP command? Is it purely to get more standby time, or is there some other reason?

Many of our newer ADCs offer the functionality you are looking for e.g. ADS124S08. The ADS1256 is a great ADC with a proven track record for sure, and I know it would not make sense for this project, but I would consider looking at some of our other ADCs whenever you start your next grounds-up design.

-Bryan

Hi Bryan,

Yes, it's a matter of reduced power consumption and also of MCU idle time, but it's much bigger than that:

We're upgrading from an 8051-based MCU to a latest-generation ARM, so there are huge differences in terms of MCU integrated peripherals, not to mention the raw difference in effective operations/s (and more). This means that every part of the low-level SW must be rewritten. A proper approach to this is to understand exactly what the platform can offer (MCU <-> ADS1256) - before the programming begins. With your eminent help I have reached this point.

In the HW trig version, the ADS1256 CLKIN and SYNC#/PDWN# pins are driven by two synchronized PWM timers. The SYNC#/PDWN# timer also provides (most of) the time event generation for the system. Everything is centred on the start of the ADS1256 conversion, after which no communication is allowed until DRDY# goes low (quiet system). The STANDBY command is the natural end to the RDATA read-out, but the WAKEUP needs to be allotted a dedicated time event at a suitable time before SYNC#/PDWN# is driven low by PWM. The timer has 6 channels, so it in itself can indicate 6 compare match and 1 update event, most of which have interrupt handlers. Losing one compare match to WAKEUP isn't too 'expensive' but it would have been better to be able to use it for other functionality (in case need should arise). (The ADS1256 DRDY# falling flank is an 8th time event via GPIO external interrupt.)

The first revision of the board can only do SW trig (SYNC and WAKEUP commands) and it is also a fall-back solution in case the HW trig version doesn't perform well. (Clock and/or sync signal coupling into the analog part.) I will now start programming on the SW version in a fashion that can easily be converted into HW trigging. All in all I will have maximum freedom to fiddle with clock frequencies, clocks being in phase or just the right amount of out-of-phase, and so on.

Any corner-cutting would likely have ruined the chance of success with the future HW trig version, but now I know exactly how to make it work:

It's very easy to change the number of conversions/s (and also the ADS1256 data rate (that affects conversion time)), simply by adjusting the timer period and compare values. It also eliminates the need for a system watchdog. Much of the data that is being output (e.g. communication or ADS1256 control) is done via circular buffers so that you can do non-blocking sending of an array of bytes (when you're in a time slot in which it is permitted). All of this (and more) contributes to a maximum performance and very 'user interface responsive' product.

So, there is method to my seemingly mad interest in details.

---

That said, for the next major upgrade we will probably be looking for a 3V-only ADC in the same class as the ADS1256 as this would make it possible to remove the 5V step up regulator. When that day comes, the excellent support I have received in this forum will make Texas Instruments my first place to look. I can't exaggerate the importance of this level of support. Don't let the bean counters take it away.

Best regards

Niclas