AD7760-АЦП 24 разряда, 2,5 МГц, кто пользовал? Опции

[SALOME]

Сделали выбор АЦП с неожиданно скоростным для 24 разрядных дельта-Сигма. Просьба поделиться впечатлениями от применения. Чую, что есть подводные камни... Подозрительно хорошие характеристики

[DS]

Origin

[SALOME]

Origin

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

[Stanislav]

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

Adobe Audition (CoolEdit).

Я понимаю буквально, что SSYNC надо ставить там, где идет обращениии к перфирии. В исходниках от ADI так и сделано. А как надо?

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

[SALOME]

Adobe Audition (CoolEdit).

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

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

Ну, это же элементарно... Для правильного "опороса" АЦП Вам потребуется сидеть в этом цикле вечно, Кстати, что за зверь в его качестве используется?

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

[Stanislav]

А где первый и второй?

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

...Я ни сижу в этом цикле вечно. Там используется свойство залипания бита, отвечающего за опрос 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.
Всё это может привести к существенному увеличению шумов АЦП в Вашей конструкции по сравнению с референсной. Именно вследствие возрастания неопределённости (джиттера) времени выборки.
Справедливости ради, надо сказать, что при постоянных уровнях сигнала на входе возрастания шума практически не будет, но в динамике этот фактор ни в коем случае нельзя сбрасывать со счетов.
По-любому, джиттер тактового сигнала к наблюдаемой Вами картине отношения иметь не может. Налицо грубые ошибки либо при организации ввода информации в процессор, либо при конкатенации цифровых данных уже внутри проца.
Если хотите выяснить причину, повторяю, нужно привести соответствие выводов процессора цепям на приведённой схеме. По только лишь фрагментам конструкции поставить диагноз невозможно.

[SALOME]

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

У Вашего АЦП есть сигнал DRDY, а у чёрного фина - ножки DMAR0 и DMAR1.

Во первых, большое спасибо за Ваш подробный анализ и рекомендации. Все они полезны.
Ассемблерный код, который генерит компилятор я посмотрела. 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;

[Stanislav]

Ассемблерный код, который генерит компилятор я посмотрела. Ssync-и стоят ровно там, где я их поставила и ничего более.

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

...У моего BF537 указанных Вами входов DMAR0 и DMAR1. я не обнаружила.

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

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

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

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

[SALOME]

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

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

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

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

[Linker]

Надо переходить на прерывание.

Прерывания, скорее всего мало что изменят. В лучшем случае уменьшите время начала 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нс?

Сообщение отредактировал Linker - Feb 3 2008, 16:59

[Stanislav]

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

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

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

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

[SALOME]

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

Я Вас понимаю. Жещина-разработчик уже по определению - курица .
Распределение выводов таково: за выбор АЦП отвечает 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. Однако есть подозрение, что выход из спячки не скор. А по другому как?

[Stanislav]

Я Вас понимаю. Жещина-разработчик уже по определению - курица .

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

...Распределение выводов таково: за выбор АЦП отвечает AMS1 (EBIU). За опрос DRDY отвечает PortH.5(GPIO).
Направление передачи RD/WR - PortH.7. При этом направление передачи в ходе считывания выборке не меняется.

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

...А меняется только при настройке АЦП. Поэтому уточняю мой фрагмент :
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нс

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

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

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

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

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

[SALOME]

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

150нс - это минимальная или максимальная задержка? И что тогда есть 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. Но по любому оно не должно влиять на устойчивость работы. Просто не понятно почему такая большая задержка. У меня еще одно подозрение. Может в процесс опроса АЦП вмешивается еще кто-то, заложенный компилятором? Пробовала запретить прерывания в теле ассемблерной вставки - программа виснет.

[Stanislav]

/ ******** Настройка порта H: **************************************
..................

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

...Период DRDY пробовала разный: от 156КГц до 1,25МГц.

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

...Установить сколько точно задержка сложно, т.к. фронт сильно CS дрожит. Полагаю из-за асинхронности поступления DRDY и момента его определения GPIO PH5. Но по любому оно не должно влиять на устойчивость работы. Просто не понятно почему такая большая задержка.

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

...У меня еще одно подозрение. Может в процесс опроса АЦП вмешивается еще кто-то, заложенный компилятором? Пробовала запретить прерывания в теле ассемблерной вставки - программа виснет.

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

[DS]

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

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

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

[Stanislav]

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

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

...Через сколько стробируется от начала CS при описанном SALOME включении ?

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

Сообщение отредактировал Stanislav - Feb 5 2008, 22:35