Добрый день!
В процессе работы у меня возникло два вопроса:
1. Я обнаружил, что в процессе сбора данных модуль ядра пишит в var/log/messeges ОГРОМНОЕ количаство сообщений

по каждой, полученной от 20-10 порции данных. Рутовый роздел очень быстро забивается, и как я понимаю, это снижает

бастродейсвие драйвера и библиотеки. Каким образом можно отключить запись этих сообщений?

2. Второй вопрос несколько сложнее, поскольку описываемое явление носит не регелярный характер.
20-10 не успевает перекачивать данные в машину (сигнальный светодиод мигает красным). Программа представляет собой

слегка переделаннй тестовый пример, поставляемый с библиотекой. Обработка данный не ведется ВООБЩЕ (я отключал

даже запись в файл).  Повышение приоритета процесса в плоть до максимального ничего не дает :-( Машина достаточно

мощная - Core 2 Duo, 2 Gb мозгов, и больше ни чем не занята. В процессе экспериментов я обнаружил сщественное

влияние параметров IrqSteps. Я менял IrqSteps в пределах от 64 до 8192 (по степеням двойки). В документации к

библиотеке сказанно, что этот параметр не должен быть больше 1 М (я так понимаю число 1024). В исходнике тестовой

програнны используется величина 4096, при этом мигание светодиода красным действительно прекращается, но при

визуализации полученных данных обнаруживается, что 3/4 данных - мусор, неимеющий никакого отношения, к поданному

на вход АЦП сигналу со звукового генератора, а одна четверть действительно представдяет сигнал :-(
Привожу кусок текста с инициалиизаций модуля, может какие либо другие переметры неверны?

    size=200000000; //размер буфера - кол uslong

    pI->RequestBufferStream(&size); //выделение мозгов под кольцевой буффер

    if (sl.BoardType == E2010)
    {
        adcPar.t2.s_Type = L_ADC_PARAM;
        adcPar.t2.AutoInit = 1;        //сбор данных 1- цикл 0-однократный
        adcPar.t2.dRate = 10000.0;        //частота опроса каналов в кадре кГц
        adcPar.t2.dKadr = 0;        //интервал м-у кадрами мс.
        adcPar.t2.SynchroType = 0x01;        //тип синхронизации
                    //     0x01 внутр с рахрешением трансляции на разъем
                    //     0x81 внутр старт
                    //     0x84 внешний во возрастающему
                    //     0x94 внешний по спдпющему
        adcPar.t2.SynchroSrc = 0x00;        //источник тактовых импульсов для АЦП 0 - внутренний с

трансляцией
        adcPar.t2.AdcIMask = SIG_0|V30_0|GND_1|GND_2|GND_3;    //режим ввода по каналам
                //     V30_0 диапазон 3 в
                //     V10_0 1 в
                //     V03_0 0.3 в
                //     GND_0 вход заземлен
                //     SIG_0 вход подключен к сигналу
         
        adcPar.t2.NCh = 1;        //кол опрашиваемых каналов
        adcPar.t2.Chn[0] = 0x0;    //массив с номерами каналов и усилением на них
        adcPar.t2.Chn[1] = 0x1;    //описывает порядок опроса каналов
        adcPar.t2.Chn[2] = 0x2;
        adcPar.t2.Chn[3] = 0x3;
        adcPar.t2.FIFO = 4096;        //фактически не используется
        adcPar.t2.IrqStep = 1024;    //IRQSTEPS4096//размер запроса циклической посылки данных к USB не

более 1МБайта
        adcPar.t2.Pages = 4096;    //PAGES32//размер кольцевого буфера в шагах перерываний
        adcPar.t2.IrqEna = 1;        //разрешение генерации прерываний от платы 0/1
        adcPar.t2.AdcEna = 1;        //разрешение работы АЦП 0/1

        pI->FillDAQparameters(&adcPar.t2);
        pI->SetParametersStream(&adcPar.t2, &size, (void **)&p, (void **)&pp,L_STREAM_ADC);

а на какой скорости они берутся?

Частота дискретизации - 10МГц, я проверял на 1 МГц, никаких изменений я не заметил.

на 1 с каким параметром IrqStep?

С такими же.

Вы писали: "чтобы не печатало дебуг отключить надо в makefile... "
Имеется в виду - заменить DEBUG=y на DEBUG=n?

типа да....

а как то, что я сейчас положил в библиотеку файлов?

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

завтра соберу тестовую систему ...буду смотреть внимательней...

чего-то я ничего плохого не увидел....свой тестовый пример прогонял и на 1 и на 10 мгц.
Машина - атлон xp 1000 256м озу... а тестовый пример запускать пробовали и анализировать потом файл?

вернее так, нашел... на предельной скорости не успевает драйвер и встает совсем... буду увеличивать буфера. а на скорости 1 должен работать нормально...

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

Попробовал собрать библиоеку и протестировать под openSuse 10.3 kernel 2.6.22.5-31. Все собралось нормально, модуль грузится, тестовая прога стартует, видит железку, но уже в потоковой функции, в стороке fl1=f12=(*pp<=halfbuffer)? 0:1; вываливается с ошибкой сигментирования.
Как я понимаю, указатель *рр в этот момент указывает куда попало, т.е. при вызове SetParametrsStream он корректно не проинициализировался.
С моей прогой тоже самое (чего, в общем, и следовало ожидать).

а по датам разве не видно что ничего не менялось...  сейчас там вроде последняя версия лежит...

Я имею ввиду разницу между последней версией, которая сейчас там лежит, и тем, что было выложено осенью...

это я уже не помню...

На сообщение:

fl1=f12=(*pp<=halfbuffer)? 0:1; вываливается с ошибкой сигментирования.

Оно не вываливается только из под рута.

Вот и вопрос. Как зделать чтобы не из под рута не вываливолось?

ОГРОМНОЕ спасибо Valeri Gladun! Проге можно биты суидности поставить - пусть от имени рута работает :-)

Poul, раньше необязательно было запускать прогу из под рута! Все и так работало. Я незнаю какие именно изменения привели к этой ситуации, но упоминание об этом сэкономило бы НЕДЕЛЮ моего времени, потраченного на малоприятное занятие с нецензурным названием!

ну типа да...я дошел то битов суидности, но я не нзаю что к этому привело... возможно что я перешел на Slack 12 с ядром 2.6.21.5.... я помню что раньше было все хорошо тк специально заводил юзера и проверял....а сейчас mmap блокируется.... а чтобы не терять недели надо оперативней и четче вопросы формулировать и задавать....

Неконец заработала моя прога с новой версией библиотеки...

Все предидущие баги - мусор и потеря данных - сохранились даже при частоте дескретизации 1000.

В результате возни с указателями обнаружено еще одно "веселое" явление  - при запуске программы (никакие параметры не меняються) функция  SetParametersStream (...) когда проинициализирует р и рр, а когда и нет. НО она при этом ВСЕГДА завершается успешно.

Вам не кажется, что логичнее было-бы вернуть ошибку, если что-то не получилось???

Я всетаки хочу вернуться к моей просьбе о низкоуровневневом протоколе общения с 20-10 через usb. Мне к маю нужно запустить свою систему, а последнее неработающее звено - Е20-10.
Незнаю как Вам, а мне рабочие дрова нужны очень...

К тому-же у нашей лаборатории имеется потребность еще в четырех устройствах Е20-10, меня начальник регулярно спрашивает как результаты и годится оно нам или нет. Я раньше говорил, что годится (час назад тоже самое сказал), но собственная уверенность с каждым днем слабеет.

есть такая бага... уже поправил, но еще не выложил... протокола как такового нет...я сам работаю по исходникам lusbapi от Windows что есть на нашем компакте... и просто задаю вопросы разработчикам.... и более того, сейчас идет в продажу новая 20-10 которая не похожа совсем на старую и я ее еще не подключил никуда.... работает она только с lusbapi пока...

обновил, теперь возвращать ошибку будет...

Хорошо, поглядим...
В связи с тем, что у нас есть еще заинтерисованность в покупке 20-10, интересно, в чем, собствено, отличая.
Было бы очень хорошо,если бы там появисась возможность по внешнему старту собирать фиксированное кол-во отсчетов, и ждать сдерующего старта - это самы распространенный режим работы для задач, связанных с радиолокацией (да, и локацией вообще).
Может мне имеет смысл написать об этом кому-нибудь еще?

Новая ревизия "В" изделия E20-10 действительно готовится к продаже. На следующей неделе будет выложено обновлённое руководство на E20-10.
В этом руководстве будет описано много отличий ревизии "В" изделия E20-10 в сторону расширения возможностей, в том числе, там будет режим аппаратного останова  сбора после получения заданного кол-во кадров. Режимы старта сбора данных будут не только по внешнему  перепаду сигнала START, но и по переходу через заданный уровень  сигнала в выбранном канале АЦП и другие.
Добавлю, что введение дополнительных возможностей в E20-10 рев."В" связано именно с пожеланиями пользователей, в том числе, и в этой конференции.