1. Из описания я понял, что для нормальной работы надо задавать частоту работы АЦП, частоту каналов + частоту выборки кадров. В примере вижу что вроде можно или первое или второе. Какой рекомендуется порядок действий по настойке временных параметров?

2. Из каких соображений выбирается величина межкадровой задержки в set_adc_timing?

Уточняю вопросы.

Если устанавливать частоту АЦП (cf) то количество каналов определит частоту кадров (ff) исходя из приведённых соотношений. Получается что устанавливать (ff) до этого не имеет смысла. То есть (cf)/Nканалов = (ff)?

Если брать за основу времянку, нарисованную в описании, то получаем, что 1/2(ff) = fsd + (Nканалов-1)(cd) + (ifd), где
fsd - first sample delay (в клоках),
cd - channel delay (в клоках),
ifd - interframe delay (в клоках).
То есть протокол ADSP-AVR отлажен именно по этому рисунку?

Было бы неплохо добавить эту картинку с разьяснением подробностей в описание библиотеки LDSP.

У меня вот почему-то такое чувство, что т.н. rate как параметр вообще не нужен. Значения ft.channel_rate + channels определяют тайминг полностью. Поправьте меня, если я не прав и обьясните для чего он нужен конкретно и где без него не обойтись.

Хотелось бы также узнать, чем руководствовались при выборе одного минора для девайса, ведь это не совсем unix-way, обращение к adc/ttl/etc можно было бы выполнить на разных минорах, что явно повысило бы гибкость обработки данных в приложениях. А так - только одно приложение. Возможно ли такое разделение в ближайшем будущем (а пока идёт тестирование под ядро 2.6 так может и попробовать сейчас)?

Иван, ау!!! Приятно конечно с умным человеком беседовать (скромно так;) но хотелось и от разработчиков что-нибудь услышать.

Ещё вопрос. Какие минимальные значения могут принимать fsd и ifd? Какие ограничения в конструкции аналогового тракта/коммутатора имеются в L761? Я предполагаю что около 8мкс - правильно или нет?

1. Все это лучше устанавливать одним вызовом set_adc_timing().

2. Частота следования кадров зависит от установленной частоты АЦП, числа каналов и межкадровой задержки.

Наверно, стоит еще добавить функцию, прямо устанавливающую частоту АЦП и межкадровую задержку...

Отдельный минор имеет смысл делать для функций типа read/write - возможно, именно так будет реализован прямой доступ к памяти DSP. Для TTL и одиночных отсчетов достаточно отдельного вызова IOCTL.

> 1. Все это лучше устанавливать одним вызовом set_adc_timing().

Тогда имеет смысл избавить пользователей от вредного понятия rate, наследованного от Windows;) Чем меньше пустых определений, не несущих смысла, тем лучше, имхо.

> 2. Частота следования кадров зависит от установленной частоты АЦП,
> числа каналов и межкадровой задержки.

А как же fsd? Эта величина присутствует в расчёте тайминга. И как насчёт правильности соотношений (cf)/Nканалов = (ff)?

> Наверно, стоит еще добавить функцию, прямо устанавливающую частоту
> АЦП и межкадровую задержку...

Конечно. И чётко описать тайминг во времянке, чтобы взглянул - и всё стало ясно.

> Отдельный минор имеет смысл делать для функций типа read/write -
> возможно, именно так будет реализован прямой доступ к памяти DSP.

Это в обозримом будущем или как?

> Для TTL и одиночных отсчетов достаточно отдельного вызова IOCTL.

Я в общем-то думаю про свои проблемы;) Хотелось бы иметь возможность буферизовать как ацп, так и ттл, чтобы можно было из разных приложений по внешней синхронизации иметь доступ через разные миноры. (модификация lbios подразумевается)

Ну и остался открытым вопрос про минимальные величины межкадровой задержки и fsd. Я вижу что есть возможность оптимизировать протокол ADSP-AVR, да и гарантия скоро закончится - можно будет подрихтовать код AVR. Я ничего там не попорчу, если аккуратно подпаяюсь и подключу программатор? (с этим наверное не к Ивану)