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

[SALOME]

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

[DS]

Диаграмму сигнала CS на АЦП и момента строба данных нарисуйте, а то так не понятно. Процессор может данные защелкнуть через, скажем 5нс после выдачи CS, в общем случае. 7760 Из-за большой задержки данных с быстрым процессором как раз и может работать неправильно. И время между выполнениями считываний с АЦП у Вас чем контролируется ? Оно не может быть меньше 50 нс.

[SALOME]

Диаграмму сигнала CS на АЦП и момента строба данных нарисуйте, а то так не понятно. Процессор может данные защелкнуть через, скажем 5нс после выдачи CS, в общем случае. 7760 Из-за большой задержки данных с быстрым процессором как раз и может работать неправильно. И время между выполнениями считываний с АЦП у Вас чем контролируется ? Оно не может быть меньше 50 нс.

Частота ядра 400МГц, перефирии 133МГц. Время между CS > 50нс
Интерфейс считывания данных от АЦП у меня организован через EBIU. В качестве CS используется пин AMS0 (выбор асинхронной памяти). Соответственно все задержки согласно даташита BF. Фрагмент настройки EBIU (извеняюсь - вертик черточки не совпали с цифрами)
*pEBIU_AMBCTL0 = 0xF644F644; //управление АЦП-банк_0 (один цикл - 7,5нс)
// 1111 0110 0100 0100 - регистр управления АМС банков_0 и 1
// |||| |||! |||| |||| |||| |||! |||| |||+-B0RDYEN=1-разрешение сигнала ARDY банка_0 (in)
// |||| |||! |||| |||| |||| |||! |||| ||+--B0RDYPOL=1-полярность сигнала ARDY банка_0
// |||| |||! |||| |||| |||| |||! |||| ++---B0TT=01-время переключения банка_0(1цикл)
// |||| |||! |||| |||| |||| |||! ||++------B0ST=00-время установки банка_0 (до ARE)(4цикл)
// |||| |||! |||| |||| |||| |||! ++--------B0HT=01-время удержания банка_0 (после ARE) (1цикл)
// |||| |||! |||| |||| |||| ++++-----------B0RAT=0100-время доступа при чтении банка_0 (ARE) (6циклов)
// |||| |||! |||| |||| ++++----------------B0WAT=1010-время доступа при записи банка_0 (10циклов)

Момент считывания находится во время действия ARE и находится явно дальше 5нс.
Другое дело, что на осцилограмме пина CS видно, что первый импульс считывания боле_мене привязан к DRDY от АЦП, хотя его дрожание определяется асинхронностью захвата DRDY. А вот интересный нам второй импульс считывания гуляет шибче. Я отношу это за счет команды SSYNC, время действия которой так и не удалось установить. Эмпирически она длится где-то 30 нс и меняет свю длительность. Может вы скажите, какова длительность SSYNC?
Но в целом процесс считывания не выходит за рамки следующего DRDY. Хотя всяко может быть. Ведь сбои носят нерегулярный характер.

Кроме того, такие процедуры лучше писать на асме.

Полность с Вами согласная. У меня на ассемблере и лучше получается. Однако сделать ассемблерную вставку прооцедуры пока не умею. Была бы благодарно за простой рабочий пример.

[Stanislav]

Фрагмент настройки EBIU (извеняюсь - вертик черточки не совпали с цифрами)

Надо делать так:

Код

*pEBIU_AMBCTL0 = 0xF644F644; //управление АЦП-банк_0 (один цикл - 7,5нс)
// 1111 0110 0100 0100 - регистр управления АМС банков_0 и 1
// |||| |||! |||| |||| |||| |||! |||| |||+-B0RDYEN=1-разрешение сигнала ARDY банка_0 (in)
// |||| |||! |||| |||| |||| |||! |||| ||+--B0RDYPOL=1-полярность сигнала ARDY банка_0
// |||| |||! |||| |||| |||| |||! |||| ++---B0TT=01-время переключения банка_0(1цикл)
// |||| |||! |||| |||| |||| |||! ||++------B0ST=00-время установки банка_0 (до ARE)(4цикл)
// |||| |||! |||| |||| |||| |||! ++--------B0HT=01-время удержания банка_0 (после ARE) (1цикл)
// |||| |||! |||| |||| |||| ++++-----------B0RAT=0100-время доступа при чтении банка_0 (ARE) (6циклов)
// |||| |||! |||| |||| ++++----------------B0WAT=1010-время доступа при записи банка_0 (10циклов)

Тайный смысл чёрточек и крестиков постигнуть, однакож, не удалось...
Хорошо, теперь дайте соответствие выводов BF и платы, схему которой Вы привели. Интересуют только сигналы управления АЦП.

...Момент считывания находится во время действия ARE и находится явно дальше 5нс.
Другое дело, что на осцилограмме пина CS видно, что первый импульс считывания боле_мене привязан к DRDY от АЦП, хотя его дрожание определяется асинхронностью захвата DRDY. А вот интересный нам второй импульс считывания гуляет шибче. Я отношу это за счет команды SSYNC, время действия которой так и не удалось установить. Эмпирически она длится где-то 30 нс и меняет свю длительность. Может вы скажите, какова длительность SSYNC?

Минимум 10 тактов, если склероз не изменяет. Только нафиг она Вам нужна во всех местах, также уразуметь неполучаецца.
Вообще-то, гулять сильно не должно...
Теперь по существу программного фрагмента из Вашего поста №42.
Делать чтение АЦП таким ужасным способом нельзя - проц только этим и будет заниматься.
Для подобных целей существуют автоматический ввод через PPI с DMA, или, на худой конец, прерывания. Организуйте его по запросу от сигнала DRDY, при вызове считывайте данные с АЦП и курите бамбук всё остальное время.
Только учтите, что макросы EX_INTERRUPT_HANDLER будут сильно тормозить - там в стэке весь контекст сохраняется, а потом восстанавливается. Так что писать прерывание нужно на асме.
А прерывания запрещены во время считывания? Если нет, временно запретите.

...Полность с Вами согласная. У меня на ассемблере и лучше получается. Однако сделать ассемблерную вставку прооцедуры пока не умею. Была бы благодарно за простой рабочий пример.

Лехко:

Код

/********************************************************************************
***********
Description : This function performs FIR filter operation on given input.
Input:   R0-current address of input circular buffer, R1-address of coeff. vector,
         R2-number of taps*2.
Output:  R0-next address of input circular buffer.
Prototype: fract16* FIR_fract(fract16*, fract16*, u32).
*/
#include "Tru_def.h"
#include <defBF534.h>

.extern _Host_MC_Out; //output array

.section program;
.global _FIR_fract;
.align  8;

//-----------------------------------------------------------------------------------
_FIR_fract:
  L0=INPUT_LEN*2(Z);      // L0 = length of input buffer in bytes
  L1=R2;                  // L1 = length of coeff buffer in bytes
  I0=R0;                  // set up input pointer
................................
БЛА-БЛА-БЛА
................................
  L0=0;                    // Clear modulo registers
  L1=0;
  RTS;    
_FIR_fract.end:

Вызывается как обычная сишная функция с тремя входными параметрами и одним выходным, передавая их наиболее простым и быстрым способом - через регистры, не используя стек.
Обработчики прерываний писать на асме ещё проще.
Вообще, читайте хэлп к вижуалдиэспи, там всё очень подробно прописано. Начните с глав:

C/C++ Compiler Language Extensions,
C/C++ Run-Time Model and Environment,
C/C++ and Assembly Interface.

[SALOME]

Минимум 10 тактов, если склероз не изменяет. Только нафиг она Вам нужна во всех местах, также уразуметь неполучаецца.

Вообще-то, гулять сильно не должно...

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

Я понимаю буквально, что SSYNC надо ставить там, где идет обращениии к перфирии. В исходниках от ADI так и сделано. А как надо?
Кстати без SSYNC ситуация ухудшается.
Однако гуляет... Кстати, посмотрела CS на плате КИТа AD7760, который сформирован Алтерой. Там все чистенько. Джиттер вообще не просматривается.
А под УЖАСОМ вы имеете ввиду программный опрос состояния DRDY от АЦП? Отчего же? И чем тут прерывание будет лучше?
Воспользоваться PPI для загрузки - не в этот раз. Платы (3штуки) уже разведены и распаяны. Шеф бьет копытом в предвкушении результата.
Спасибо за фрагмент, буду его осмысливать. И вообще спасибо за участие. Сейчас займусь ревизией проги считывания АЦП.

[Stanislav]

А под УЖАСОМ вы имеете ввиду программный опрос состояния DRDY от АЦП? Отчего же? И чем тут прерывание будет лучше?

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