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

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

Опять двадцать пять...
Простите, а Вы точно знаете, как именно ноги 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.
Если времена другие, это означает косяк в настройках самогО процессора.

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

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

Не, вопрос не про задержку 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битового слова и всегда в битах статуса, где возможны нули. Может буфер косячит...