[Stanislav 0]

...На картинке, где показаны результаты програмного изменения смещения видно, что статистика появления нулей меняется с изменением смещения. з-я выборка практически нулей не содержит, а другие содержат причем по разному. Но при этом алгоритм считывание данных-то не меняется... Ну разве, что АЦП меняет темп выдачи данных при изменении содержимого своего регистра "OFFSET".

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

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

[SALOME 0]

Диаграмму сигнала 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. Хотя всяко может быть. Ведь сбои носят нерегулярный характер.

 

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

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

[DS 0]

Все-таки снимите осциллограммы. То, что Вы пишете, это "как должно работать". А как на самом деле может только осциллограф показать.

По BF Stanislav большой специалист, может, правда, он и сходу увидит в чем дело.

[Stanislav 0]

Фрагмент настройки 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 0]

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

 

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

 

Делать чтение АЦП таким ужасным способом нельзя - проц только этим и будет заниматься.

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

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

Кстати без SSYNC ситуация ухудшается.

Однако гуляет... Кстати, посмотрела CS на плате КИТа AD7760, который сформирован Алтерой. Там все чистенько. Джиттер вообще не просматривается.

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

Воспользоваться PPI для загрузки - не в этот раз. Платы (3штуки) уже разведены и распаяны. Шеф бьет копытом в предвкушении результата.

Спасибо за фрагмент, буду его осмысливать. И вообще спасибо за участие. Сейчас займусь ревизией проги считывания АЦП.

[SALOME 0]

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

[DS 0]

Origin

[SALOME 0]

Origin

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

[DS 0]

Отредактировал Ваш пост слегка. Надеюсь, понятно, почему :) .

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

[SALOME 0]

Отредактировал Ваш пост слегка. Надеюсь, понятно, почему :).

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

[DS 0]

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

[Stanislav 0]

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

Adobe Audition (CoolEdit).

 

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

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

[Stanislav 0]

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

Ну, это же элементарно... Для правильного "опороса" АЦП Вам потребуется сидеть в этом цикле вечно, а период его исполнения не может быть бОльшим периода выборки АЦП. Вот это и есть "УЖОС". :)

Кстати, а что ещё BlackFin делать будет, кроме тупого ввода данных с АЦП? Не идёт ли здесь речь о девальвации самогО понятия "процессор"?

Прерывание же по DRDY Вас избавляет от каких-либо проверок бита готовности, и забрасывает в обработчик события автоматически. Остаётся только прочитать.

Применение RTOS для такого быстрого ввода через EBIU вряд ли вообще возможно. Нормальное решение - подключить АЦП к PPI, а уж с дисплеем разбираться "как-нибудь так". :)

Кстати, что за зверь в его качестве используется?

[SALOME 0]

Adobe Audition (CoolEdit).

 

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

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

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

 

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

Я ни сижу в этом цикле вечно. Там используется свойство залипания бита, отвечающего за опрос DRDY. Получается быстрее, чем при прерывании.

Использую TFT дисплей NEC "NL2432HC22-41K" и он очень хорошо сопрягается через PPI.

[Stanislav 0]

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

Сверху вниз, по тексту прогги.

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

 

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

Всё это может привести к существенному увеличению шумов АЦП в Вашей конструкции по сравнению с референсной. Именно вследствие возрастания неопределённости (джиттера) времени выборки.

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

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

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