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

Приветствую!

Пытаюсь разобраться с выводом данных с АЦП E14-440 на основе примера test.cpp из из библиотеки lcomp_linux.tgz

Драйвера на 32-ную систему встали без проблем (кстати, с 64-ой системе почему то выскакивала ошибка даже на версии библиотеки 1.58). Пример из папки test успешно компилируется.

А вот дальше начинаются сложности. Опыта работы с С/С++ нет.

Чтение "руководства программиста" взятого отсюда: https://www.lcard.ru/support/developer результата не дало. Видимо оно всё таки для виндовой версии библиотеки. Хотя про
кольцевой буфер было полезно почитать.

Ранее удалось разработать проект для Windows на основе этой же платы в Delphi. Там удалось разобраться с примером.

На этом форуме прочитал про тестовый пример l7xx.tst В указанной библиотеке его нет.

Задача стоит банальная.
Подключаем АЦП к системе на базе Linux. АЦП принимает данные на один канал. Софт верхнего забирает эти оцифрованные данные и передает дальше для обработки.

Подозреваю что тестовый пример отправляет на вывод адреса ячеек, где лежат данные. Не понимаю где лежат сами данные. Полез разбираться с указателями. Оказалась эта тема для меня, увы, пока сложна. Надеюсь с ней разобраться при работе над данным проектом:)

Можете написать подробнее, какая ошибка возникает и при установке чего (драйвера или библиотеки, если драйвера, то лог сборки).

Сами функции библиотеки lcomp под Linux в целом соответствуют аналогичным под Windows, как и подход к работе аналогичный, отличается главным образом только начальная загрузка библиотеки, которая делается API ОС (Вместо LoadLibrary и GetProcAddress - dlopen и dlsym).
Опять же, не понятно, что конкретно у Вас не получается.
По поводу того, где лежат данные, то для приема данных выделяется буфер (массив отсчета). Выделяется он при вызове pI->SetParametersStream в примере и указатель на него сохраняется в переменную p, в size возвращается его размер, а в pp - указатель на память, где создана переменная синхронизации. В переменной синхронизации хранится номер отсчета в массиве данных, куда будет сохранен следующий пришедший отсчет.
Изначально значение переменной 0, затем когда будет запущен сбор и придет первый отсчет он станет 1 (что означает, что в p[0] появился первый действительный отсчет), второй - 2 (сохранены p[0] и p[1]) и т.д. пока не будет заполнен весь буфер, после чего сохранение следующих элементов начнется по кругу с начала массива (т.е. после *pp == size-1 идет *pp == 0). Но это для случая изменения по 1 отсчету, реально может быть сохранено сразу несколько отсчетов за раз драйвером. Программа смотрит за изменением значения переменной синхронизации, помнит с какой позиции она считывала данные и понимает сколько появилось данных в буфере, после чего их обрабатывает. Обработать она их должна до того, как они будут перезатерты при записи новых отсчетов по следующему кругу. В примере на экран выводится значение этой переменной синхронизации, которое должно меняться, а в отдельном потоке (thread_func) идет сохранение данных в файл по половинке буфера.

Ошибка возникала при сборке драйверов. Алгоритм действий был таков:

# обновляем ос и перезагружаемся
sudo apt-get update -y
sudo apt-get dist-upgrade -y
reboot

# устанавливаем зависимости 
sudo apt-get install  gcc g++ gdb cmake libfontconfig1 mesa-common-dev build-essential libglu1-mesa-dev 
sudo apt-get install libatomic*

# скачиваем библиотеку 
wget https://www.lcard.ru/download/lcomp_linux.tgz

# так получается версия драйвера 1.57. Пробовал обновлять пакеты lcomp-dkms liblcomp1-dev с репозитория https://download.opensuse.org/repositories/home:l-card/Debian_11/ Тогда версия становится 1.58. Правда результат прежний.


# распаковываем
tar -xvzf ./lcomp_linux.tgz

# переходим в папку с исходниками
cd dstr

# копируем рулезовский файлик в нужное место
sudo cp lcard.rules /etc/udev/rules.d/

# ковыряемся во внутреннотях демона udev
sudo udevadm control --reload-rules && udevadm trigger

# накатываем хедеры для raspberry pi
sudo apt-get install raspberrypi-kernel-headers

# пытаемся собирать из исходников драйвера
make

# в итоге получаю такой выход в консоль:
make -C /lib/modules/5.15.84-v8+/build M=/home/user7/dstr modules
make[1]: Entering directory '/usr/src/linux-headers-5.15.84-v8+'
  CC [M]  /home/user7/dstr/ldevice.o
  CC [M]  /home/user7/dstr/l760.o
  CC [M]  /home/user7/dstr/ldevpciu.o
  LD [M]  /home/user7/dstr/ldevpci.o
  CC [M]  /home/user7/dstr/e2010.o
  CC [M]  /home/user7/dstr/e140.o
  CC [M]  /home/user7/dstr/e440.o
  CC [M]  /home/user7/dstr/e154.o
  CC [M]  /home/user7/dstr/ldevusbu.o
  LD [M]  /home/user7/dstr/ldevusb.o
  CC [M]  /home/user7/dstr/l791.o
  CC [M]  /home/user7/dstr/ldevpcib.o
  LD [M]  /home/user7/dstr/ldevpcibm.o
  MODPOST /home/user7/dstr/Module.symvers
ERROR: modpost: "__aarch64_swp4_acq" [/home/user7/dstr/ldevusb.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:133: /home/user7/dstr/Module.symvers] Error 1
make[2]: *** Deleting file '/home/user7/dstr/Module.symvers'
make[1]: *** [Makefile:1817: modules] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.15.84-v8+'
make: *** [Makefile:28: modules] Error 2

# при попытке установки драйверов также было сообщение что это не удалось
./start

# поэтому собирать библиотеку даже не стал пробовать.

Манипуляции проводил на Raspberry Pi 4 Model B с операционкой raspios-bullseye-arm64-lite скачанной с официального сайта устройства. Позже попробовал на это же устройство поставить raspios-bullseye-armhf-lite. С этой ОС всё заработало без проблем. Ранее пробовал устанавливать по выше приведённому алгоритму драйвера с библиотекой на старый ноутбук с дебиано подобной системой (Linux antiX 32-bit). Там тоже всё прошло как по маслу с первого раза.

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

Кажется разобрался.

Тогда при изменении исходника test.cpp путём задания значения переменной multi = 2

и вы выводе данных в консоль стройкой

printf(" shared word %d %d \n", *pp, p[(*pp-1)]);

где мы в десятичном виде указываем место куда будет писаться следубщий отсчёт *рр и значение последнего записанного отсчёта p[(*pp-1)] получим  следующий вывод:

Press any key
 shared word 0 0 
 shared word 0 0 
 shared word 4096 372 
 shared word 8192 62519 
 shared word 12288 63431 
 shared word 16384 273 
 shared word 20480 62203 
 shared word 24576 63919 
 shared word 28672 63 
 shared word 32768 61989 
 shared word 36864 64397 
 shared word 40960 65291 
 shared word 45056 61866 
 shared word 49152 64846 
 shared word 53248 64907 
 shared word 57344 61848 
 shared word 61440 65228 
 shared word 65536 64446 
 shared word 69632 61945 
 shared word 73728 6 
 shared word 77824 63962 
 shared word 81920 62150 
 shared word 86016 243 
 shared word 90112 63488 
 shared word 94208 62454 
 shared word 98304 378 
 shared word 102400 63022 
 shared word 106496 62841 
 shared word 110592 381 
 shared word 114688 62644 
 shared word 114688 62644 
 shared word 118784 63289 
 shared word 122880 320 
 shared word 126976 62287 
 shared word 131072 63775 

Press any key

Тут на вход АЦП подаётся синус постоянной частоты с генератора.

в этом выводе меня смутили значения отсчёта порядка 63 тысяч. Ранее в документации к АЦП я читал что оцифрованные значения формируются в диапазоне от -8 тыс до + 8 тыс (это примерно, сейчас точно не помню). Видимо я в этом месте где то заблуждаюсь.

Это связано с представлением отрицательных чисел, значения представлены в дополнительном коде, т.е. отрицательное значение кодируется как  65536 - модуль числа, т.е. 65535 - это -1, 65534 - это -2 и т.д.). Это соответствует кодированию чисел со знаком для стандартных типов языков программирования, поэтому для корректного вывода Вам должно быть достаточно преобразовать тип переменной отсчета из беззнакового в знаковый (unsigned short в short),  чтобы язык понял, что это число в дополнительном коде.

Т.е. по идее достаточно изменить вывод на:

printf(" shared word %d %d \n", *pp, (short)p[(*pp-1)]);

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

Благодарю за помощь!!! Теперь всё работает как надо!!!

Про ошибку при компиляции на 64-битных системах находил информацию об этом на этом форуме. Тема там осталась не раскрытой. Видимо у автора темы получилось решить проблему обновлением пакетов lcomp-dkms и liblcomp1-dev
https://www.lcard.ru/forums/viewtopic.php?id=10556