В настоящий момент я использую в своей разработке АЦП ADS1256 (Работаю с резонатором 7,68 МГц на частоте дискретизации 3750 Гц, остальные параметры по default after reset). На стр 21. даташита указана последовательность смены каналов для каждого отсчёта. Синхронизация АЦП (переход DRDY в состояние 1) происходит не во время второго такта команды WAKEUP (Fig. 36 стр. 37 даташита), а в произвольные моменты между командами SYNC и WAKEUP. Я, честно говоря, не понял, зачем посылать команды SYNC и WAKEUP, если им полностью эквивалентно управление синхронизацией через вывод SYNC/PWDN, да к тому же можно спокойно достичь частот, указанных в таблице 14. В итоге, я теперь не посылаю команды SYNC и WAKEUP, а просто после появления спада на DRDY (переход из 1 в 0) устанавливаю вывод SYNC в 0. Затем произвожу смену каналов, потом устанавливаю SYNC в 1 и на выводе DRDY сразу же устанавливается 1 (как я понимаю, говорящий о том, что началось преобразование АЦП), затем посылаю команду на чтение предыдущего результата RDATA и считываю три байта результата. Переход DRDY в 0 наступает через 441 мксек (как в таблице 13 для частоты дискретизации 3750 Гц). Соответствующая осциллограмма приведена на рис 1, где жёлтый сигнал - SCLK (SPI CLOCK), зелёный DRDY, красный - данные, присылаемые по SPI от АЦП в микроконтроллер, синий - данные, посылаемые от микроконтроллера в АЦП. В итоге всё работает, но иногда, в произвольные моменты времени (может быть через несколько минут, а может и через полчаса) происходит сбой в частоте дискретизации, который также через несколько минут или через полчаса, как получится, прекращается. Сброса микроконтроллера не происходит. Сбой в частоте дискретизации выглядит следующим образом: рис 2 (самые широкие импульсы DRDY (состояние 1) не достигают 440 мксек, импульсы идут шириной 308 мксек и 208 мксек, чередуясь 308, 308, 208, 208, 308, 208, 308....). При этом последовательность связи по инетерфейсу SPI с АЦП не изменилась (как можно пронаблюдать на рис 3). Более того, провалов питания не наблюдается, частота на выводе CLKOUT НЕ ИЗМЕНЯЕТСЯ! В чём дело? Что может привести к такой работе и как такое вообще физически возможно?

P.S. 1. Осциллограммы находятся в приложенном архиве.
2. На осциллограммах для всех каналов, кроме жёлтого, не заморачивался с правильным подключением земли щупа осциллографа, поэтому виден "звон", которого на самом деле нет, все сигналы такие же "гладкие", как и жёлтый канал.
3. Последовательность данных при сбое частоты дискретизации следующая:
АЦП DRDY устанавливает в 0
Через 8 мксек переходим непосредственно к обработке прерывания по заднему фронту
SYNC переводим в 0
01010001 => в АЦП (WREG|MUX)
00000000 => в АЦП
00011111 => в АЦП (MUX)
SYNC переводим в 1
АЦП DRDY устанавливает в 1
00000001 => в АЦП (RDATA)
Считываем 3 байта данных из АЦП

Время 208 мксек, в течение которого DRDY находится в состоянии 1

АЦП DRDY устанавливает в 0
Через 8 мксек переходим непосредственно к обработке прерывания по заднему фронту
SYNC переводим в 0
01010001 => в АЦП (WREG|MUX)
00000000 => в АЦП
00110100 => в АЦП (MUX)
SYNC переводим в 1
АЦП DRDY устанавливает в 1
00000001 => в АЦП (RDATA)
Считываем 3 байта данных из АЦП

Время 308 мксек, в течение которого DRDY находится в состоянии 1

АЦП DRDY устанавливает в 0
Через 8 мксек переходим непосредственно к обработке прерывания по заднему фронту
SYNC переводим в 0
01010001 => в АЦП (WREG|MUX)
00000000 => в АЦП
00001111 => в АЦП (MUX)
SYNC переводим в 1
АЦП DRDY устанавливает в 1
00000001 => в АЦП (RDATA)
Считываем 3 байта данных из АЦП

Время 308 мксек, в течение которого DRDY находится в состоянии 1

АЦП DRDY устанавливает в 0
Через 8 мксек переходим непосредственно к обработке прерывания по заднему фронту
SYNC переводим в 0
01010001 => в АЦП (WREG|MUX)
00000000 => в АЦП
00001111 => в АЦП (MUX)
SYNC переводим в 1
АЦП DRDY устанавливает в 1
00000001 => в АЦП (RDATA)
Считываем 3 байта данных из АЦП

Время 208 мксек, в течение которого DRDY находится в состоянии 1
............. и так далее по циклу .............................

Сразу признаюсь, что ответов на ваш главный вопрос у меня нет, поскольку использую я не ADS1256, а ADS1255, у которого нет каналов, которые можно было бы переключать. Могу лишь ответить на этот:
"Я, честно говоря, не понял, зачем посылать команды SYNC и WAKEUP, если им полностью эквивалентно управление синхронизацией через вывод SYNC/PWDN...". Здесь, думаю, причина в том, что ипользовать выводы микросхмы для этих целей не целесообразно, когда АЦП и МК гальванически развязаны. Чтобы управлять этими сигналами через пины, пришлось бы дополнительно развязывать еще две линии, а управляя ими программно (через SPI) можно обойтись одним элементом ADuM для развязки.

Однако хотела бы спросить о причинах странности с сигналом SCLK, который у вас на осциллограмме желтый.
1) Там где идут отдельные пачки по 8, это понятно - передача байта. А отчего две последние пачки такие толстенькие? На 2 пачки по 8, следующие друг за другом, они не похожи - 16 импульсов в них нет, а есть где-то около 14.
2) Отчего SCLK в промежутках между передачами уходит на постоянный высокий уровень? Ведь если это CLOCK, стробирующий положительной полярностью, то и держаться он вроде бы должен низким уровнем, когда пассивен. А у вас не так. Почему?
3) Те две толстенькие пачки странны еще и тем, что заканчиваются высоким уровнем. Честно говоря, я в растерянности от случая, когда импульсы начинаются с нижнего уровня, а кончаются верхним. Как тут считать их количество?

По поводу гальванической развзяки полностью с Вами согласен. По поводу SCLK - вы абсолютно правы, там две последние пачки по 14 импульсов каждая, да и ещё на большей частоте. Они необходимы для обновления данных в ЦАПе DAC7612, который хоть и производства TI, но настройки по SPI там диаметрально противоположные, к примеру, нормальный уровень SCLK там не 0, а 1. После получения последнего третьего байта от АЦП сигнал CS устанавливается в 1 и дальнейшее общение с ЦАПом не влияет на АЦП никоим образом.