Форум: Техническая поддержка

Добрый день

Необходимо собрать работоспособную систему на linux Slackware 12.2 с версией ядра 3.2.21
Дистрибутив брался с репозитория https://bitbucket.org/lcard/lpcie_sdk
Не совсем гладко, но собрать библиотеку и драйвер получилось.

Суть проблемы, попробовал собрать и запустить пример, имеющийся по адресу
http://www.lcard.ru/support/developer в разделе L-502 / E-502
"Пример потокового сбора с АЦП/DIN на языке C для Microsoft Visual C++ 2008 или GCC"
Так же пробовал пример который ставится вместе с инсталятором на windows.
Результат одинаковый:
функция L502_ProcessData возвращает ошибку:

"Ошибка обработки данных: Неверный номер канала в обрабатываемом потоке синхронного ввода"

Если сохранять сырые данные, содержимое rcv_buf на данные с АЦП не похоже.
Слишком много подряд 0х00000000 иногда сменяются на серии полной неразберихи.

Драйвер запущен, lpcie в списке значится.

Пробовал запустить данный пример на windows 10, все прекрасно функционирует.

В чем может быть проблема?

Добрый день.
А что подразумевается под "не совсем гладко"? Вы вносили какие-то изменения в драйвер или библиотеку для сборки?

Тестировалось на Windows и на Linux на одной машине или разных? Что вообще за машина, на которой L502 не работает?

Если попробовать оценить скорость поступления данных из Recv(), то она соответствует установленной частоте вообще?

Ну в принципе 0x0 это действительное слово с цифровых линий, которое разрешается в примере (если Вы уменьшили частоту АЦП, но оставили макс. частоту сбора с цифровых линий, то такой вариант может быть и возможен). Для более наглядной проверки данных думаю лучше запретить ввод с цифровых линий, для чего заменить

err = X502_StreamsEnable(hnd, X502_STREAM_ADC | X502_STREAM_DIN);

на

err = X502_StreamsEnable(hnd, X502_STREAM_ADC);

А также разрешить побольше каналов идущих подряд и не степень 2, например 7, для чего поменять определения:

#define ADC_LCH_CNT  7

/* номера используемых физических каналов */
static uint32_t f_channels[ADC_LCH_CNT] = {0,1,2,3,4,5,6};
/* режимы измерения для каналов */
static uint32_t f_ch_modes[ADC_LCH_CNT] = {X502_LCH_MODE_DIFF, X502_LCH_MODE_DIFF, X502_LCH_MODE_DIFF, X502_LCH_MODE_DIFF, X502_LCH_MODE_DIFF, X502_LCH_MODE_DIFF, X502_LCH_MODE_DIFF};
/* диапазоны измерения для каналов */
static uint32_t f_ch_ranges[ADC_LCH_CNT] = {X502_ADC_RANGE_10, X502_ADC_RANGE_10, X502_ADC_RANGE_10, X502_ADC_RANGE_10, X502_ADC_RANGE_10, X502_ADC_RANGE_10, X502_ADC_RANGE_10};

и выложить дамп (изменится он тогда вообще?)

Нет, в сам драйвер или библиотеку никаких изменений не вносилось, пришлось немного подкорректировать Cmakelists.
Иногда корректировке подвергались makefile, но все это можно поправить и в Cmakelists.

Тестировалось все на промышленном компьютере на основе процессорной платы PICMG1.3
4U/19"/Intel Core-i3 3220 3.3ГГц/2x2Гб DDR3 1600/1000Гб SATA3 HDD/DVD-RW/DVI-I/2xГб LAN/8xPCI/3xPCIEx1/1xPCIEx16/1xRS-232, 1xRS-232,422,485/ 400Вт ATX
На нем имеются обе системы Windows 10 и Slackware 12.2 с ядром 3.2.21, тестировалось все на нем, как на windows так и на linux.
Попробовал просто оценить скорость принятия данных, предварительно закомментировав кусок кода в котором происходит ошибка, умозрительно совпадает, 1024000 отсчетов на частоте 100кГц собирает примерно секунд за 11-12, при частоте 200кГц секунд за 6. 

Что бы откомпилировать пример под linux пришлось закомментировать функции
`E502_MakeDevRecordByIpAddr'
`E502_UsbGetDevRecordsList` 
иначе компилятор выдает: "undefined reference to" (строчки выше)

По данной ссылке можно скачать пример который я использовал:
http://www.lcard.ru/forums/img/members/287/example.rar
в архиве 4 файла:
main.c - исходный код используемого примера
outn.txt - перенаправленный вывод с консоли
dumpBefore.txt - содержит дамп области rcv_buf до выполнения функции X502_Recv
dumpAfter.txt - содержит дамп области rcv_buf после выполнения функции X502_Recv

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

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

Пока проблему решить не удалось.

По видимому не подключена библиотека e502api, но так как у Вас и используется только L502, то это не принципиально.

Да, похоже буфер не имеет никакого отношения к принимаемым данным... Скорее всего какая-то специфическая проблема в драйвере при получении данных по DMA от модуля... Я могу попробовать поставить на следующей неделе эту версию Slackware, хотя есть вероятность, что для воспроизведения нужна не только версия ОС но и вариант железа...
В любом случае на следующей неделе внимательно еще раз просмотрю, с чем может быть проблема или как можно сделать какой-то тестовый вариант драйвера чтобы ее выявить.

Проблема проявлялась на 32-битной версии linux и была исправлена в версии драйвера 1.0.12