Всем привет!
Возникла задача: одновременно подавать на объект
раздражающий сигнал (например, прямоугольные импульсы) и писать ответ с объекта.

В описании к библиотеке ldsp максимум, что я мог найти, это

while(1) {
x_out = ldspWrite(dev,bufer_out,count_out);
x_in =ldspRead(dev,buffer_in,count_in);

}

то есть что-то записали, что-то прочитали,
а нельзя ли это сделать как-то одновременно и
синхронизованно?

Занимался ли кто из вас чем-то подобным?
В какую сторону смотреть?

Спасибо.

смотреть в сторону писания программы для DSP, хотя и там это не строго одновременно

А если у меня l154 и DSP там нет?

А какие частоты тебя интересуют?

Вообще это интересует и меня.
С платами L305 и L1250.
Мне нужны частоты от 250 Гц до 25 кГц.
И ввод, и вывод - одноканальные.

P.S. Привет биофизикам от электрофизиологов.

Так оно еще и ISA ?

А в чём проблема- c ISA?

Привет и электрофизиологам от биофизиков!

Меня интересуют частоты около 10кГц, ввод и вывод
тоже одноканальные.

Если бы было можно синхронизовать потоки,
то ldspRead() и ldspWrite() можно было бы пустить
в параллельных потоках. Но увы.

Никто не знает, можо ли задать  драйвере функцию типа

ssize_t count = dev_read_write(sstruct file *file, char *buff_in, char *buff_out, size_t length, loff_t *offset);

ведь в драйвере всего-то отличие между
функциями device_read и device_write

в том, что в первой

fb = &d->InBuf
//..........
count = atomic_read(&fb.count)

а во второй

fb = &d->OutBuf
//.............
count = atomic_add(&fb.count)

тогда можно отдельно задать fb_in и fb_out
и поочередно делать
atomic_read(&fb_in.count)
и
atomic_add(&fb_out.count)

Но, насколько я понимаю (а, может, ошибаюсь?),
не так то просто задать в

static file_operations fops =
{
/*.....*/
write: dev_read_write,
/*.....*/
}

с произвольным количеством параметров.
И тем более с произвольным именем файловой
операции типа
static file_operations fops =
{
/*.....*/
read_write: dev_read_write,
/*.....*/
}

Зачем в разных потоках-то? ПМСМ синхронизировать замаешься.

P.S. Я из Лаб. ионных каналов клеточных мембран, ИнЦ РАН,СПб.

Да не вопрос, в параллельных потоках на катит.

P.S. А я из группы биофизики клетки, каф.
биофизики биофака МГУ. Но дипломная была
связана с ионными каналами. Так что вдвойне
привет! Кстати, а что вы там с каналами делаете?
(у меня был анализ последовательностей времен жизни
BK-канала, сейчас по этим материалам пишу статью).

См. PubMed - Mozhayeva, Kaznacheeva, Nikolayev, Zubov, Gusev, Bugaj.

Регистрируем одиночные каналы низкой проводимости.
Хочу свой ДООС-овый софт под Линь портировать, да вот пока никак. Хотя надо всего ничего - DMA_ALL_DA в рабочем виде. В приципе только её и хватило бы.  У меня всё на С++, и может компилироваиться в 32бит, так что

TO: Вадим Алексеенко - с ISA все тормознее - считайте сами сколько обращений к порту ввода-вывода, с учетом того, что на 1байт требуется в лучшем случае 1 микросекунда (и то, если не пользуетесь всякой древностью типа 486) - 25кГц наврядли получится

Athlon/600 - устраивает?
Сyrix M2 на шине 100, на частоте ядра 300 и 250 МГц?

И если приспичит, найду платы с ISA под Athlon XP 2000+...

Насколько тогда будет выигрыш в финансах
vs. проигрыш в производительности?

Читайте спецификацию ISA, елки-палки...при чем тут шина 100 и ядра ?

Каждый сам себе - злобный буратин...
Сэкономь бакс - потеряй сотню...

Уважаемый Папа Карло, ну нету под рукой спецификации
ISA. Может, проясните ситуацию, а заодно что и посоветуете? Я, например, был бы благодарен.

А можно, я всё же буду биологом, и буду читать описание платы?
В котором написано что-то о трудностях ввода на частотах выше 150-200 кГц. О том, что пропускная способность ISA в 486 - 330 кГц.
Учитывая, что мне нужно 25 кГц максимум, как сказано выше, а можно ограничиться и 10 - запас по пропускной, мне кажется, изрядный. Учитывая работу по DMA - и процессор свободен.

<ПК> намекает, что шина pci больше подходит для реалтаймовых задач чем isa. Описание платы не указывает в каких ОС она должна использоваться, поэтому чтобы получить некое подобие реалтаймовых задач в многозадачных ОС, придётся немного поработать. Если есть дсп - то над текстом лбиоса и драйвером. Если нет дсп - то прикинуть влезет ли обработка в 1ms целочисленной арифметики. Потом поиграться с вызовом ioctl, но если плата не умеет генерить прерывания, то тогда проще остаться под досом. Или пробовать экзотические варианты типа патчей ядра user-mode kernel, rtlinux, rtai. Но прежде надо быть уверенным, что удастся самому доработать драйверы, поставляемые ЛКард, поскольку пока И.Горинову на смену никто не появился.

Если я правильно понимаю, 25 кГц- это 50 кБайт за секунду в обе стороны.
Неужели под нормальным, обычным Linux-ом нельзя гарантировать опрос платы хотя бы 2-3 раза в секунду?

Если не принимать специальных мер в драйвере, то линукс имеет право задержать любой процесс на 10ms (винды на 50ms). Насколько это критично в ваших экспериментах я не знаю. 25Кгц (40мкс) для одного канала ввода можно реализовать только сбором данных в драйвере, в user-space не получится. Если плата должна реагировать на изменения в жестком реалтайме, то цикл обработки ioctl вы должны уложить приблизительно в 1ms, как я говорил раньше. Не знаю как спроектирована ваша плата под isa, но для одного цикла ввода-вывода она имеет право занять до 16мкс времени. (возможно ЛКарду удалось сделать решение на коротком цикле, но оно не обязятельно будет работать на всех материнках) Итого останется на обработку 8мкс. Так что частоту 25КГц в многозадачных ОС реализовать не получится, если не было отступлений от стандарта isa. Но до 1Кгц можно попытаться.

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

То есть.
Загнали сложный профиль изменения командного потенциала в Out_DMA_Buffer, и пишем реакцию.
Главное, чтобы из In_DMA_Buffer ничего не терялось.

Да, софт, разумеется, я планировал не под Х-ми. svgalib достаточно.

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

Э, нет. Видимо, я плохо объяснил.
Мне не нужно иметь возможность в любой произвольный момент изменить команду(на ЦАП).
Но мне нужно иметь возможность чётко синхронизовать ЦАП и АЦП. То есть сгенерировать сигнал сложной формы, пустить его на вывод, и получить другой массив - введённых с АЦП данных, для которого я могу однозначно сказать- i-тому значению  массива ввода соответствует i-тое значение массива вывода.

А вот задача "если введено значение больше k - поменять команду" вообще не стоит.

То есть беспокоит только и исключительно синхронизация.
Если же я начну выводить этот сложный командный сигнал на 0.1 сек позже запланированного- это мне безразлично.

А как <<программа минимум>> даже проще:
чтобы ЦАП генерировал бы себе какой-нибудь
периодический сигнал, но при этом не мешал ЦАПу
читать свой вход, не пропуская точки.
То есть что-то вроде

ioct(dev,LDSP_START_IMP,params);
//и он себе выводит до бесконечости
//либо по кольцу читая из буфера, либо
//самостоятельно генерируя что-нибудь
//простенькое
//при этом чтобы можно было
ldspRead(dev,in_buf,big_count);
fwirte(in_buf,1,big_count,file)
ioctl(dev,LDSP_STOP_IMP);
//выводить прекращаем.

Хотя, конечно, то, что описал Вадим было-бы
намного предпочтительнее.

Да, при этом ввод на 99% достаточен- по одному каналу.
Ещё хорошо бы иметь возможность опрашивать еще полдесятка каналов АЦП (наши усилки могут свои параметры выводить как разные напряжения на спец-разъёмы), но это уже не обязательно.

В общем-то у нас и деньги могли бы найтись - 50-100 уе за такой драйвер(для 1250 и 305)...
И может, не одни мы страдаем такой проблемой