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. Кроме того, для заполнения программного конвейера после перехода требуется тоже определённое время.
Короче, возьмите симулятор и попробуйте посимулять. По первой прикидке, у меня получилась вполне соответствующая цифра. Точно проверять щас лень, но могу это сделать в случае необходимости.

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