Посмотрела на осцилограммы CS. Вроде все нормально. Глянула на полученный файл в бинарном виде в FARе и не увидела там никаких ступенек. Посмотрела на изображение в гляделке - ступеньки есть. Очень похоже, что ошибка в оболочке гляделки. Гляделку ваял сюшный програмер, который приходил срубить бабла. Похоже - накосячил. Может кто присоветует гляделку для просмотра 24разрядных двоичных файлов (имеется ввиду с выводом в виде графиков). Очень надо, плз

Origin

Спасибо. Однако начав тернистый путь ее пользования, споткнуласьДа я вообщем-то не об этом. СтОит ли эта прога моих мук? Может есть варианты попроще?

Отредактировал Ваш пост слегка. Надеюсь, понятно, почему .
Origin - для таких целей самое простое в использовании, хотя, наверное, не самое лучшее в мире.

Догадываюсь. Первый раз зашла, и так неудачно (во всех смыслах)

Что и как надо спрашивать в форуме "Доступ к FTP".

Adobe Audition (CoolEdit).

Первый - надо. Второй - не надо.

Ну, это же элементарно... Для правильного "опороса" АЦП Вам потребуется сидеть в этом цикле вечно, а период его исполнения не может быть бОльшим периода выборки АЦП. Вот это и есть "УЖОС".
Кстати, а что ещё BlackFin делать будет, кроме тупого ввода данных с АЦП? Не идёт ли здесь речь о девальвации самогО понятия "процессор"?
Прерывание же по DRDY Вас избавляет от каких-либо проверок бита готовности, и забрасывает в обработчик события автоматически. Остаётся только прочитать.
Применение RTOS для такого быстрого ввода через EBIU вряд ли вообще возможно. Нормальное решение - подключить АЦП к PPI, а уж с дисплеем разбираться "как-нибудь так".
Кстати, что за зверь в его качестве используется?

И точно. В аудио же 24 разряда давно прописались. Попробую.
А где первый и второй?


Я ни сижу в этом цикле вечно. Там используется свойство залипания бита, отвечающего за опрос DRDY. Получается быстрее, чем при прерывании.
Использую TFT дисплей NEC "NL2432HC22-41K" и он очень хорошо сопрягается через PPI.

Сверху вниз, по тексту прогги.
Вообще-то, и первый, скорее всего, не нужен. Для более точного ответа нужно посмотреть сгенерённый ассемблерный код (знаете, как это делать?).

Ясно. ТФТ так ТФТ на PPI, ничего не поделаешь. Стало быть, Вы сначала накапливаете блок данных, а потом его "абсчитываете". Менее корявой от этого логика работы, однако, не становится (уж простите).
О пользе чтения мануалов.
Процессор BlackFin силён не только, и даже не столько своими вычислительными возможностями (есть DSP и покруче). Он, ко всему прочему, обладает развитой многошинной архитектурой, многопортовой по множеству 4к внутренней памятью данных, а также лучшей из тех, с коими приходилось сталкиваться, системой ввода-вывода. Имеется в виду, прежде всего, контроллер ПДП (DMA) - по сути, процессор в процессоре, который может выполнять даже записанные в памяти программы пересылки для каждого из каналов и подключать устройства В/В к независимым друг от друга шинам и страницам памяти (здесь, конечно, и программисту есть над чем поработать - втупую компилер с линкером вряд ли всё это разрулить способны). И всё это - совершенно независимо от вычислительного ядра.
В Вашем случае можно превратить EBIU в эффективный параллельный порт ввода-вывода, работающий по запросу. Для этого нужно настроить один из каналов MDMA, включив аппаратный режим HandShake. Каналы MDMA в процессоре работают не напрямую, а "вперекидку" (тот, кто работал с аппаратом БСЛ - Большая Совковая Лопата - в бригаде, поймёт, о чём я), однако, для программиста это не представляет практически никаких дополнительных сложностей.
У Вашего АЦП есть сигнал DRDY, а у чёрного фина - ножки DMAR0 и DMAR1. Если сигнал объединить с одной из них, получим аппаратный запрос контроллеру HMDMA на ввод данных (в данном случае, видимо, либо одного 32-битного слова, либо 2-х 16-битных). При этом процесс ввода будет "прозрачным" для вычислительного ядра процессора, которое может в это время заниматься своими делами. В конце каждого акта ввода будет выработано прерывание, сигнализирующее о его окончаниии, после чего контроллер MDMA должен быть перезапущен.
Кроме того, организовав ввод подобным образом, Вы сможете сократить до минимума джиттер выборки (скорее всего, его величина будет определяться только тактом рассинхронизации генераторов SCLK фина и АЦП.
Естественно, тайминг ввода нужно настроить в соответствием с требуемой времянкой шины данных АЦП. Достигается путём программирования регистров EBIU должным образом.
Далее, ввод данных Вашим способом, если я правильно понял, подразумевает разрывы в данных, что, вообще говоря, для системы измерения в реальном времени нежелательно (по моему мнению, во всяком случае). Для реализации обработки сигнала по-настоящему real-time, без его разрывов, стоит позаботиться о правильной организации буферов памяти ввода. В простейшем случае, это может быть циклический буфер, длиной минимум в два блока; в более сложном, но и более эффективном - пинг-понг буферы в разных страницах внутренней памяти данных. Последний способ имеет то преимущество, что вычислительное ядро и контроллер (HM)DMA не будут мешать друг другу в попытках достучаться до памяти (не будет возникать stall-ов в работе ядра при чтении заполненного буфера).
Все эти вещи Вам будет очень полезно изучить самостоятельно, благо документация у AD хорошая. Если будут непонятки - обнародуйте, постараюсь помочь.
Далее, по схеме (не ногами, но по сути).
Мне кажется, что в схеме Вашей платы есть недостатки по сравнению с референсной от AD. Это касается способа подачи тактового сигнала на АЦП.
1. AD применяют генератор MXO45HS с невысокой долговременной стабильностью, но с малым джиттером фазы выходного сигнала - 1пс (хорошей кратковременной стабильностью). В Вашей же схеме применён генератор CFPT-126 с высокой долговременной стабильностью, но с неизвестным джиттером (по крайней мере, в даташите обнаружить его не удалось).
2. AD применяет в качестве формирователя тактовых импульсов АЦП ультрабыстрый логический элемент NC7SZ08, вы же - его гораздо более медленную версию NC7S08.
Всё это может привести к существенному увеличению шумов АЦП в Вашей конструкции по сравнению с референсной. Именно вследствие возрастания неопределённости (джиттера) времени выборки.
Справедливости ради, надо сказать, что при постоянных уровнях сигнала на входе возрастания шума практически не будет, но в динамике этот фактор ни в коем случае нельзя сбрасывать со счетов.
По-любому, джиттер тактового сигнала к наблюдаемой Вами картине отношения иметь не может. Налицо грубые ошибки либо при организации ввода информации в процессор, либо при конкатенации цифровых данных уже внутри проца.
Если хотите выяснить причину, повторяю, нужно привести соответствие выводов процессора цепям на приведённой схеме. По только лишь фрагментам конструкции поставить диагноз невозможно.

Во первых, большое спасибо за Ваш подробный анализ и рекомендации. Все они полезны.
Ассемблерный код, который генерит компилятор я посмотрела. Ssync-и стоят ровно там, где я их поставила и ничего более.
У моего BF537 указанных Вами входов DMAR0 и DMAR1. я не обнаружила.
Посмотрите фрагмент проги на ASM, отвечающий за анализ появления сигнала DRDY от АЦП. При скорости SCLK=133MГц после прихода DRDY до появления CS проходит более 100нс. Непонятно откуда такая задержка.

lw_start:
//ожидание DRDY
r1=w[p1](z);
CC=!bittst(r1,5);
if CC jump lw_start;

// w[p1+4]=r2; //сброс залипающего бита DRDY

r0.h=w[i0]; // считывание первого слова DATA_ADC (высталение CS) ssync;

Это понятно. Вопрос в том, нужно ли их вообще там ставить. Ну да Бгъ с ним...

Плохо смотрите. PF0 и PF1.

ЗЫ. Поиском текста в pdf-ах пользоваться умеете?

Почему же непонятно? 100 нС - это при частоте ядра 400 МГц - 40 тактов. Посмотрите время выполнения команд, в частности условных переходов, и убедитесь, что здесь всё нормально.

Нашла. Оказались альтернативные функции, а я смотрела по пинам . Буду думать. PF0/1 у меня тоже заняты под UART0: boot-загрузка и передача данных на Комп.
С количеством тактов еще хуже . Там управление периферией, а след-но не 400, а 133 Мгц. Надо переходить на прерывание. Два дня возилась с ассемблерной вставкой, теперь - прерыванием ХЕЗ_сколько . Зато опыт копится...

На комп можно поробовать второй УАРТ заюзать. С загрузкой несколько сложнее - без дополнительного коммутатора сигналов обойтись, скорее всего, не получится. Правда, если Вам в процессе работы нужно только передавать данные на комп, задача сильно упрощается: в этом случае, нужно использовать UART0 TX (PF0) ножку на передачу, а DMAR1 (PF1) - как вход для запроса HMDMA. Коммутировать сигналы RxD и DRDY можно при помощи простейшего двухвходового переключателя, управляемого одной из ножек GPIO процессора.
Как вариант - загрузка из SPI флешки. Сам так делаю.

Времена выполнения команд, в том числе и с обращением к периферии, принято отсчитывать в тактах ядра.

Salome, дорогая, у меня есть серьёзное предположение, что никакими программными ухищрениями положение Вы не исправите. Нужно внимательно проанализировать аппаратную часть, для чего придётся хотя бы поверхностно научиться читать схемы и управляться с осциллоскопом.

Прерывания, скорее всего мало что изменят. В лучшем случае уменьшите время начала CS после прихода DRDY. Надо смотреть на временные диаграммы считывания по шине EBIU. При скоростях SKLK>100MHz скорее всего процессор считывает НЕустановившиеся на шине АЦП данные, т.е. мусор. Программная регулировка времени считывания данных ARDY относительно выставления AMSx (CS_ADC) - не более 4-х тактов. т.е 40нс. А по даташиту AD7760 - более 41нсек. Это без учета задержек буферов.


Что-то не совсем понятно. Ведь в приведенном фрагменте идет обращение к порту GPIO
lw_start:
//ожидание DRDY
r1=w[p1](z); --> Считывание с периферийного порта GPIO. и время выполнения надо считать в SCLK (т.е 1 такт 7,5нс)
CC=!bittst(r1,5);--> А здесь в CCLK (т.е. 1 такт 2,5нс)
if CC jump lw_start
Разве не так?
И потом, в самом деле, откуда в этом цикле набегает более 100нс?

Опять двадцать пять...
Простите, а Вы точно знаете, как именно ноги EBIU процессора подключены к терминалам приведённой схемы?
По-моему, даже уважаемая SALOME имеет об этом весьма смутное представление...
Лично я же сильно подозреваю, что трабл именно в этом, а именно: в неправильной подаче сигналов управления на АЦП. О чём уже неоднократно высказался.

EBIU не является GPIO.
100 нс набегает не только в этом цикле. Есть ещё обращение к внешнему устройству через EBIU.
Дело в том, что для синхронизации ядра и перифериии требуется определённое время, зависящее от соотношения CCLK и SCLK. При этом не нужно забывать, что данные при операции чтения из периферии и записи в неё становятся в конвейер (за мегагерцы приходится платить). Для его гарантированной выгрузки и используются команды SSYNC. Кроме того, для заполнения программного конвейера после перехода требуется тоже определённое время.
Короче, возьмите симулятор и попробуйте посимулять. По первой прикидке, у меня получилась вполне соответствующая цифра. Точно проверять щас лень, но могу это сделать в случае необходимости.

ЗЫ. Плохой разработчик систему, функционирующую с /редкими/ сбоями, считает условно работающей. Хороший - безусловно не работающей.

Я Вас понимаю. Жещина-разработчик уже по определению - курица .
Распределение выводов таково: за выбор АЦП отвечает AMS1 (EBIU). За опрос DRDY отвечает PortH.5(GPIO).
Направление передачи RD/WR - PortH.7. При этом направление передачи в ходе считывания выборке не меняется. А меняется только при настройке АЦП. Поэтому уточняю мой фрагмент :

lw_start:
//ожидание DRDY
r1=w[p1](z); //Считывание состояния PortH, р1 - адрес PortH
CC=!bittst(r1,5); //Проверка состояния залипающего бита PortH.5
if CC jump lw_start //Если DRDY не пришел, то продолжить опрос

Вот здесь задержка между DRDY и спадом AMS1~150нс

[i]//Считывание данных с АЦП
r0.h=w[i0]; // считать старшие 2 байта DATA_ADC. i0 - адрес АЦП (EBIU)
ssync;
//считать младший байт DATA_ADC + байт STATUS
r0.l=w[i0]; // считать младший байт DATA_ADC + байт STATUS

w[i2++]=r0.h; // сохранить старшие 2 байта в SRAM
w[i2++]=r0.l; // сохранить младший в SRAM

BLA...
BLA...[/i]



С настройкой прерываний разобралась и теперь встал вопрос как организовать цикл опроса АЦП по прерываниям. Приходит в голову IDDLE. Однако есть подозрение, что выход из спячки не скор. А по другому как?

Дело вовсе не в этом. А в том, что для получения сколь-нибудь полезного совета нужно научится правильно задавать вопрос, не упуская при этом существенных деталей.
К сожалению, этим часто пренебрегают представители обоих полов в равной степени.

Ну, наконец-то.
Подключение логичное, и, с моей точки зрения, правильное (если не рассматривать всё-таки возможность ввода по HMDMA).
Продолжим "пытку".
1. Как инициализирован PORT H? Интересуют все значения регистров, которые Вы изменяете.
2. Почему не подано питание V_EXT на ногу VccY транслятора уровней U30 в Вашей схеме?
3. Каков период сигнала DRDY?

150нс - это минимальная или максимальная задержка? И что тогда есть 100нс?
ЗЫ. Задержка возникает не только, и не столько здесь.


Сдаётся, уважаемая Salome, что у Вас слишком мал интервал между последовательными чтениями. Попробуйте вместо одной команды SSYNC вставить подряд две или даже три.

В данном случае, команда IDLE нужна не для изменения режима, а именно для ожидания прерывания. "Мёртвое" время будет всяко меньше, чем в Вашей программе.
Однако, длительность задержки даже в 100нс не может вызвать сбой в работе АЦП.

/ ******** Настройка порта H: **************************************
PH5-in ADC_DRDY
PH6-in ADC_MX2(SYNHRO)
PH7-out ADC_RESET
PH9-out ADC_R/W
PH10-out ADC_SYNC
*/
*pPORTH_FER=0x0000;
*pPORTHIO_DIR =0x179C;
*pPORTHIO_INEN =0xE060; // Разрешение буфера приема порта H
*pPORTHIO_POLAR =0x8060; // 1- активен низкий (спадающий) уровень ~~~~~~~~~|_____
*pPORTHIO_EDGE =0x8060;; // 0 - уровень (не залипает),т.е. повторяет pin
*pPORTHIO =0x1FFF;
Напряжение Vext реально подано. А в схеме упущено. Спасибо.
Период DRDY пробовала разный: от 156КГц до 1,25МГц.
Установить сколько точно задержка сложно, т.к. фронт сильно CS дрожит. Полагаю из-за асинхронности поступления DRDY и момента его определения GPIO PH5. Но по любому оно не должно влиять на устойчивость работы. Просто не понятно почему такая большая задержка. У меня еще одно подозрение. Может в процесс опроса АЦП вмешивается еще кто-то, заложенный компилятором? Пробовала запретить прерывания в теле ассемблерной вставки - программа виснет.

Вроде, всё правильно.

Тогда "наползаний" быть точно не должно.
Продолжим: что записано в регистры управления АЦП?

С этим разберётесь пожже.
Ещё раз: у Вас слишком мало время между чтениями первого и второго слова из АЦП (t6). По даташиту, оно должно быть не менее 1 периода внутреннего тактового сигнала АЦП, а у Вас оно - меньше, это видно даже без осциллографа. Увеличьте его, и всё станет ОК.

А разрешить при выходе не забыли?
Если в программе используются прерывания, такое поведение вполне закономерно.

В регистрах управления трудно накосячить, чтобы к такому результату привело.
По поводу времени между чтениями - совершенно верно, обязательно надо выдерживать 50 нс. НО - судя по предыдущим данным, сбоит и старшее слово. Состояние выходного автомата АЦП сбрасывается по DRDY, поэтому это не должно влиять на старший байт. Надо искать в тракте данных. Через сколько стробируется от начала CS при описанном SALOME включении ?

При желании, можно. Например, делитель на 2 для 40 МГц MCLK не включить.

В зависимости от момента прихода падающего фронта DRDY внутри цикла ожидания, задержка CS относительно DRDY может сильно меняться. Но меньше минимально допустимых 10нс (t2) быть не может.
Длительность CS - 82,5нc. Промежуток между последовательными CS тоже может слегка гулять, и составляет минимально около 30 нс (точно считать лень), что, по моему мнению, и приводит к сбоям.
Защёлкивание данных в процессоре происходит через 75нс после начала сигнала CS.
Если времена другие, это означает косяк в настройках самогО процессора.

Так можно и входной буфер или модулятор забыть включить . Работать совсем не будет.

Не, вопрос не про задержку DRDY-CS, а про строб данных в процессор относительно начала CS. Все говорит, что проблема в этом. Если, конечно, не какая нибудь глупость типа порванного проводника на плате. Данные на АЦП могут появляться аж череж 40+ нс после CS, если еще и буфер есть, могут быть пробемы именно с этим.

Дописал уже...

2 SALOME
Попробуйте вставить ещё одну команду SSYNC вот здесь:

w[i2++]=r0.h; // сохранить старшие 2 байта в SRAM
SSYNC;
w[i2++]=r0.l; // сохранить младший в SRAM

Или сразу после второго чтения. В данном случае, он всё-таки нужен.

Я в своей программе не использую прерывания. Но когда в ассемблерной вставке их запрещаю, то вся прога виснет. А если в конце вставки разрешаю прерывания, то все нормально. Разобраться, что нагенерил компилятор кроме моей программы пока нет времени. Но наверное придется.


регистр 1= 0x020A, регистр 2= 0x0002. Хотя пробовала и другие комбинации. Например, включала фильтр_3 (User), но коэффициентв не загружала.


Сейчас буду еще раз перетряхивать железо в обвязке АЦП и тыкать туда осцилом. Дело затрудняется сложностью доступа. Придется делать переходники...


Вставляла SSYNC всяко и разно. Проверю версию с проблемой в старшем байте шины данных. Очень похоже на это. Мусор начинается, при появлении нулей в старшем разряде 24битового слова и всегда в битах статуса, где возможны нули. Может буфер косячит...

Хорошо, тогда покажите, как именно запрещаете.

Отсебятины он нагенерить не может. Разве что его хорошо попросить.
В стартапе, вообще-то, система прерываний инициализируется, и прерывания глобально разрешаются но все, кроме 0,1 и 15, попадают в ловушку (__unknown_exception_occurred), откуда выхода уже нет. Кроме того, при запуске main они индивидуально замаскированы. Так штаа...

Вроде, тоже ничего плохого. Только степень децимации надо бы повысить...

Осциллограммы не забудьте выложить.

ЗЫ. Вообще-то, Вам пора позаботиться о приобретении JTAG эмулятора. Без него отлаживать систему весьма тяжко...

Выкладываю осцилограмы. Первые две - на КИТ от ADI: обмен идет через PPI c шинами сформированными альтерой.
Нажмите для просмотра прикрепленного файла Все хорошо.
Нажмите для просмотра прикрепленного файла На второй диаграмме видно, что при чтении АЦП выставляет данные почти сразу после прихода CS. Это радует.
А теперь предмет мучений - тот же кит, но обмен через EBIU. Альтера выключена. По временам поступления CS не так все плохо, но замусорено и видна тянучка при возвращении в 1. Кстати, на КИТе линия CS подтянуты к 2,5В через резистор 10К и последовательно 2 резистора по 100 Ом. При касании щупом CS на ноге АЦП прога виснет.
Нажмите для просмотра прикрепленного файла.
Хотелось бы иметь JTAG. Однако руководство пока не созрело платить по ценам, которые выставляет ADI. А есть варианты по проще?

Замусорено, говорите?
Дык, этож не сигнал чтения, а Тихий Ужос... Если это "буратина", надавайте по шее вашим монтажникам, и поясните, что провода нужно делать не более 12-15см, и "земли" нужно кидать в несколько толстых проводов.
А Вы точно использовали однократный захват осциллограммы?

ЗЫ. И ещё: "земля" осциллографа точно была подключена к плате?
ЗЗЫ. Выложите здесь фото Вашего изделия. Интересно полюбоваться...

Есть.
http://www.insys.ru/device/emu-ad.htm
Пользуйтесь поиском по форуму, все средства отладки для BF здесь уже обсуждались.

И еще фото, как осцилограф подключаете

А в этой цепи случаем не стоит ADшный транслятор уровня с автоматическим выбором направления ?
Что-то я не думаю, что так наводки или земли могут выплясывать.

Именно он и стоит: ADG3308.


Нет не однократный. Все три "АВТО". Это видно на картинках. Методика измерений в обоих случаях одинакова. И про щуп "земля" я не забыла .Однако с земляными проводами в межплатном разъеме действительно напряженка: он всего ОДИН из 30! Я посчитала, что для таких скоростей (ед. МГц) это не так критично. Однако попробую понатыкать еще ЗЕМЛИ проводами.
А что по поводу тянучек от CS скажите и резистора 400 Ом в линии?

Тем более, что у нее этот буфер имеет выводы, работающие в разных направлениях...

Попробовала таки воспльзоваться прерыванием от DRDY c организацией цикла записи через IDLE. УЖОС на CS прекратился .
Нажмите для просмотра прикрепленного файла
Картинка преобразования стала много чище. Выбросы редки, но увеличиваются с ростом частоты перефирии, что позволяет судить о взаимовлиянии шин данных и управления. Всем спасибо

Для измерения временнЫх диаграмм нужно использовать однократный захват, в противном случае, такой примитивный (даром, что цифровой - одно название) скоп способен выдать неадекватную картинку.
Смущают большие выбросы на сигнальных проводах. Это говорит о неправильном землении шины и/или осциллографа.
Все измерения нужно делать на стороне Фина (а не АЦП), и пользоваться, по возможности, "короткой землёй".
Хе-хе. Ещё как критично.
Не забывайте, что проц - скоростной, и может ловить "звон" на шине с периодом в единицы наносекунд. О чём я писал уже на 1-й странице.
На таком осциллке Вы его попросту можете не увидеть.

Постарайтесь их расположить равномерно по ширине трассы, чтобы уменьшить площади паразитных контуров.

Какого ещё резистора и в какой такой линии?
Тянучки бывают из-за отсутствия связи по постоянному току. Скорее всего, у Вас в процессе измерения отвалилась "земля" осциллографа (кстати, и "мусора" при этом возникает значительно больше). Или включили какой - нибудь режим усреднения в осциллке, чего нельзя делать в данных условиях.

Что-то не оченно оно лучше, просто картинка стала стабильнее, как и ожидалось...
ВременА не соответствуют CCLK=400 МГц и SCLK=133МГц.

ЗЫ. Теперь осталось совместные осциллограммы CS и глючащих данных выложить.

Однократный захват на моем GDS-840C вообще плох.
Резистор имеется ввиду последовательно в линии CS на КИТе AD7760.
А почему не соответствует? И как видна частота CCLK=400 МГц?
Выкладываю картинку CS_Date. На ней ясно видно, что данные выставляются не сразу после CS. Причем второе слово (или переход 1-->0 ?) выставляется быстрее.
Нажмите для просмотра прикрепленного файла

Посмотрел характеристики Вашего прибора на сайте Instek.
Моё мнение: с такими приборами измерять параметры устройств, подобными Вашему - НЕЛЬЗЯ.
Можете от моего имени передать его Вашему руководству.
Простите, но ваша контора замахнулась на изделие, в котором вы не можете элементарно проконтролировать происходящие процессы. И, видимо, за которое хочет получить "мнока тенек".
100 мегавыборок в секунду, при частоте внешней шины 133 МГц... курям на смех. Ваши УжосНах-овые диаграммы обусловлены использованием скопа в стробоскопическом режиме, после чего он начинает рисовать на экране невесть что (не забывайте, что дивайс делали наши друзья-китайцы).
Мой Вам совет: убедите руководство оснастить Вас хотя бы минимально необходимым прибором для выполнения порученной работы. Таковым может считаться недорогой WaveSurfer или даже WaveJet от Lecroy (с "минимально необходимыми" ТЕКами дела не имел, а те, что видел в натуре, дешёвые, - примерно такое же д....о, что и дивайс, используемый Вами).
Вообще, рекомендую почитать на электрониксе баталии, посвящённые осциллографам. Там много полезных ссылок и информации.

SALOME, дорогая, режьте меня с маслом, но я не могу понять, какой такой резистор "последовательно в линии CS на КИТе AD7760" изображён на схеме, приведённой Вами, и где о нём вообще ранее упоминалось?
Я, конечно, осознаю, что Настоящая Женщина должна полагать, что мужчина обязан догадываться обо всём без лишних слов. Посему, остаётся только заочно и безоглядно в Вас влюбится.

400 - точно не видна, но предполагать о её порядке можно (не спрашивайте, как, пожалуйста). Но несоответствие режима работы EBIU (при заданной Вами его времянке) частоте SCLK видно невооружённым глазом.
Явно видно несоответствие временнОй диаграммы из поста №83 рассчитанным мной временам в посте №72.
Что правильнее, - Ваш прибор, или мой расчёт - решать Вам.

Во! Теперь нормально - длительность CS не превосходит 100нс, а составляет оценочно предреченные 83нс.
При частоте ядра 400 МГц, Вы, вероятно, посадили между циклами чтения около трёх SSYNC-ов. Ну, или написали проггу не слишком уж "оптимально" (простите).
Выставляться данные сразу и не должны. Нужно время на синхронизацию выхода дециматора АЦП после поступления асинхронного запроса на выдачу данных (CS), а переход 0-1 или 1-0, в данном случае, никого не имает.
Различия времён задержек выдачи данных на шину при первом и втором обращении, вероятно, поясняются расхождением фаз генераторов SCLK BlackFin-а и MCLK АЦП. Вот Вам предположение: второе время будет зависеть от интервала между последовательными чтениями.
В любом случае, если EBIU запрограммировано так, как Вы привели, защёлкивание данных в фине будет происходить, когда они уже "успокоились". Ищите засаду в помехах.

ЗЫ. Похоже, Ваш осциллок нужно выбросить, или отдать молодым и неопытным . Если не дадут приличный цифровой осциллограф, лучше уж попросите (нет, потребуйте!) у начальства отечественный аналоговый луческоп не хуже С1-99 (правда, потесниться придётся).
ЗЗЫ. "Землите" Вы осциллок некачественно. Неправильно землите. Таких выбросов на фронтах быть не должно.
Ну да ладно, это мелочи...

Осцилок на самом деле - Г...Он вообще всякие чудеса кажет. Но зато дешев . Убеждать начальство пока не время. Это будет выглядеть так, что я оправдываю собственную беспомощность плохим осцилографом. И поддержать меня в этом проекте пока некому.
Макет я пока откладываю в сторону и жду разрешения на разводку новой печатки. Я этого уже два месяца жду. Стоимость этой платки ~ 10тр. Однако их жаба душит. И они все время оттягивают эту "страшную растрату". Каждый раз говорят:"Ну попробуйте еще вот так, вот эдак...". Ненавижу отечественную администрацию в любом виде вместе с ее офисным планктоном .
Спасибо за участие.

Вопрос к тем, кто реально использовал AD7760:
Можно ли подавать на входы встроенного в кристалл операционника отрицательное напряжение(относительно земли)?
В даташите наблюдается некоторое противоречие:
на стр. 26 написано: "Figure 52 shows the signal conditioning that occurs using the circuit shown in Figure 50 with a ±2.5 V input signal biased around ground and the component values and conditions listed in Table 8." и нарисованы графики двуполярного входного сигнала относительно "0"-вольт. В то-же время, в таблице "ABSOLUTE MAXIMUM RATINGS" указано, что на любых входах не должно быть меньше -0,3В. Кому верить???

можно, никакого противоречия нет.
картинка 52 относится к схеме с рис. 50, на которой кроме усилителя есть еще резисторы Rin и Rfb, при этом встроенный дифф усилитель выходы приподнимает на 2.048В (правая часть рис 52).

Внимание, вопрос: если на выходе усилителя (он же вход АЦП, обозначен Vin-) напряжение +3.68В, а на входе А, до резистора -2.5В, какое напряжение непосредственно входе усилителя, после резистора Rin.

Спасибо, я так и думал.
Понятно, что на входе ОУ не будет отрицательного напряжения.
Вопрос был в том - нет ли на входе (на самих ножках мс) защитных цепей, которые не позволят подать отрицательный сигнал?
Вы сами использовали сигналы отрицательной полярности?

думаю есть, и прикладывать непосредственно на выводы сигналы больше питания и меньше земли не стоит,
однако отрицательных напряжений на ножках там не бывает при таком включении.

Нажмите для просмотра прикрепленного файла

Спасибо, всё понял, Ваша схема всё прояснила!