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

Спасибо за подсказку. Посмотрим в эту сторону при первой же возможности.

Да, 4 канала. Просто опрос четырёх аналоговых каналов по очереди.

Если получится в пятницу забрать E20-10, то запущу у себя дома под Linux на прогон. Заодно посмотрю, как там прием в драйвере linux сделан, есть ли что-то подозрительное на переходе к следующему шагу приема.

А какой у Вас дистрибутив Linux используется?

А есть возможность выложить код работы с буфером данных устройства в Вашем случае (определение прихода новых данных и их обработку)?

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

В общих чертах ситуация выглядит так. На первом этапе работы мы использовали программу Lgraph и обрабатывали создаваемые ею бинарные файлы (*.dat).

Затем было написано собственное ПО, которое для совместимости с уже имеющимися программами имитирует работу Lgraph в части записываемых бинарных файлов. Сделано это было на основе примера из документации lcomp (того, где работа идёт с одной половинкой буфера, пока записывается другая). Никакой обработки данных помимо записи их на диск не осуществляется. Программа также осуществляет онлайн-визуализацию - для этой цели параллельный поток читает буфер, но не вносит туда никаких изменений.

Ранее Вы упоминали про промежуточный буфер. Если будет возможность прислать код передачи данных из буфера lcomp в промежуточный буфер и записи из промежуточного на диск, то могло бы быть полезным (графическая часть в данном случае не интересна, раз не влияет на записываемые данные). Размер буфера lcomp использовался как в примере - 8 * 32768 слов?

Ранее Вы писали:

Это речь идет про визуализацию или это вообще уже после сбора, т.к. вроде Вы пишите, что при записи обработки нет.

Настройки были такими:

adcPar.t2.FIFO = 32768;
adcPar.t2.IrqStep = 32768;
adcPar.t2.Pages = 8;
adcPar.t2.IrqEna = 1;
adcPar.t2.AdcEna = 1;

adcPar.t2.StartCnt = 0;
adcPar.t2.StopCnt = 0;
adcPar.t2.DM_Ena = 0;
adcPar.t2.SynchroMode = 0;
adcPar.t2.AdPorog = 0;

Речь идёт про визуализацию. Это - компромиссный вариант между точностью и скоростью. Используется только для визуального контроля эксперимента. Как я уже писал выше, не влияет на записываемые данные.

Фрагмент программы, осуществляющий взаимодействие с lcomp:

unsigned int L_buf=0, L_buf_old=0;

 for(;;)
 {
  L_buf=*pp;
  L_buf-=L_buf%4; // выравниваем по кадру (в кадре 4 канала)

  if(process_data_break==1) break;
  usleep(100);
  if(process_data_break==1) break;

  if(L_buf==L_buf_old) continue; // никаких новых данных не получено

  if(L_buf_old<L_buf)
  {
   sbor_dannyh(L_buf_old, L_buf);
  }
  else if(L_buf_old>L_buf)
  {
   // был "перескок" через максимум
   sbor_dannyh(L_buf_old, L_buf_max);
   sbor_dannyh(0, L_buf);
  }

  L_buf_old=L_buf;

 }//for(;;)

pp - это переменная из примера
sbor_dannyh - это функция, вычитывающая данные из буфера lcomp в указанных границах

1. Результаты прогона модуля ...
2 мая в 9:23 на прогон был поставлен модуль E20-10 (Rev.'B.01', S/N 5T232131, версия микроконтроллера  2.5 от 20.02.20, версия ПЛИС 2.00.14 от 28.01.20).  Мониторилась непрерывность  передаваемой модулем тестовой последовательности данных с периодической проверкой признака переполнения внутреннего буфера модуля.  Прогон модуля был остановлен 5 мая в 21:49. За время испытаний никаких сбоев в работе модуля обнаружено не было. Можно утверждать, что с точки зрения непрерывности  данных всё совокупное ПО (Lusbapi, микроконтроллер, ПЛИС) отработало штатно.
2. Сегодня вечером ещё раз поставлю на прогон модуль E20-10, но уже с целью помониторить непонятную ситуацию с появлением маркера начала непрерывного блока у цифровых каналов.
3. Библиотека LComp потенциально гораздо более надёжна в плане непрерывности сбора данных, поскольку собственно весь алгоритм сбора реализован на уровне ядра (в драйвере). И здесь, на мой взгляд, было бы весьма разумно в клиентском ПО увеличить как размер USB запроса IrqStep, так и размер буфера данных в драйвере. В пятницу готов передать Алексею модуль E20-10 (Rev.'B.01', S/N 5T232131, версия микроконтроллера  2.5 от 20.02.20, версия ПЛИС 2.00.14 от 28.01.20) для дальнейшего исследования под Linux.

1. Завершён очередной прогон модуля E20-10 под Windows на предмет спорадического появлением маркера начала непрерывного блока у цифровых каналов.  Никаких отклонений от номинальной работы модуля обнаружено не было.
2. Передал модуль E20-10 Алексею для дальнейших испытаний c библиотекой LComp под Linux.

А какой размер передается в pI->RequestBufferStream()?
И как именно задается L_buf_max?
Также на всякий случай было бы неплохо увидеть код sbor_dannyh(). Запись из временного буфера в файл идет в потоке, отличном от сбора? Если возможно, то код записи в файл из буфера тоже был бы полезен.

ULONG size;
size=131072;
pI->RequestBufferStream(&size);

unsigned int L_buf_max = IrqStep*pages;

Да.

В функции sbor_dannyh() выполняется такой код, относящийся к сохранению данных:

(*buf_write)(p+pp_start, 1, (pp_end-pp_start)*sizeof(short), datafile);

В простейшем случае buf_write=fwrite.

Поскольку иногда это приводило к переполнению буфера E20-10, было сделано так. Созданы 32 буфера, таких же, как p. И дополнительные массивы size_t N[32] (номера) и size_t L[32] (длины). Соответствующая версия функции buf_write ищет такое t, что N[t]==0, вписывает в соответствующий массив данные и в L[t] - длину, после чего в N[t] вписывается порядковый номер записи (нумерация сквозная с самого начала с 1). А ещё один поток постоянно сканирует массив N[] и, заметив, что N[t] равно очередному порядковому номеру (на 1 большему, чем тот, с которым запись выполнялась прошлый раз), записывает содержимое соответствующего массива (его начальный кусок длиной длиной L[t]) в файл с помощью функции fwrite, после чего присваивает N[t]=0 (помечая, что buf_write сюда снова может складывать данные).

Алгоритм описываю словами, т. к. он запрограммирован не очень понятно и к тому же я удалённо (не имея доступа к управлению проектом в GUI) не могу быстро разобраться, какая конкретно версия файла была скомпилирована.

Мы нашли записи, сделанные с другим экземпляром E20-10. На нижней стороне корпуса на нём указан год изготовления 2014.

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

Видимо, можно сделать вывод об особенностях (неисправности) конкретного экземпляра E20-10.

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

Здравствуйте.

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

Кроме того, у меня на одной машине драйвер не успевал откачивать данные из E20-10 (средняя скорость была 9950 КСлов/c) при Ваших параметрах (там не очень оптимально была сделана постановка запросов чтения из устройства с паузами между блоками по IrqStep, что может быть критично при небольшом IrqStep, при увеличении шага драйвер уже успевал, но в изначальной версии больший шаг не совсем корректно работал). При этом при переполнении буфера разрывы данных у меня происходили как раз с шагом в IrqStep, т.к. при паузе между запросами происходило новое переполнение. Вполне возможно, что у Вас была похожая, но менее критичная ситуация, когда как правило драйвер успевал откачивать данные, но на пределе, и при некоторых условиях загрузки машины все же задержка увеличивалась и происходило его переполнение, так же повторяющееся несколько между обменами в IrqStep, после чего снова скорость восстанавливалась. По крайней мере такой вариант исключать нельзя, а из-за не совсем корректной индикации Вы вряд ли могли заметить, поэтому полагаться можно только на признак переполнения из модуля (правда в Вашей версии драйвера это было не доступно).

Сейчас в lcomp для linux было сделано:
1. Реализован более оптимальный опрос с постановкой в очередь сразу двух обменов по IrqStep, что приводит к отсутствию пауз между IrqStep, а также без дополнительных копирований данных
2. Реализована корректная работа с IrqStep боле 32КСлов вплоть до 1МСлова (максимальное значение для E20-10).
3. Реализован доступ к данным из памяти модуля через драйвер, с помощью чего можно включить тестовую последовательность, а также проверить признак переполнения буфера модуля и узнать максимальную его заполненность.
4. Реализован пример тестирования модуля в этом тестовом режиме счетчика с проверкой переполнения внутреннего буфера модуля.

Соответственно за счет 1 и 2 пункта должна увеличиться надежность откачки данных из модуля без переполнений даже при загрузках машины (я тестировал эту версию даже при активной работе на этой же машине, включая компиляцию больших проектов, и переполнений не возникало даже на той машине, где изначально было переполнение всегда).  За счет пункта 3 факт переполнения можно контролировать  при работе модуля в штатном режиме. На примере из пункта 4 можно будет сперва проверить корректность передачи данных на Вашей машине, затем с помощью тестового счетчика Вы можете проверить и всю последовательность в Вашей программе с Вашей записью данных.

Все это тестировалось на 3-х машинах, но особенно из-за изменения в пункте 1 нужно будет Вам также сперва на тестовом примере хорошо протестировать.
За все время работы проблемы с данными были только изначально при переполнении внутреннего буфера модуля, в случае отсутствия его переполнения каких-то ошибок данных не наблюдалось (у самого режима тестового счетчика есть некоторые особенности в зависимости от настроек модуля, но они учитываются в примере и не мешают тестированию).

В общем это все нужно еще привести к финальному варианту для выдачи, думаю смогу сделать это к началу следующей недели.

А Вы софт под ltr из пакетов готовых у себя ставили?

Спасибо. На данный момент спешки нет. Наш институт в течении ближайших двух недель как минимум не перейдёт на нормальный режим работы, поэтому полноценно протестировать и использовать сделанные Вами усовершенствования в ПО мы всё равно не сможем.

Да, всё было сделано по инструкции. В список репозиториев Ubuntu был добавлен репозиторий L-CARD и оттуда установлен готовый пакет.

Ещё вопрос.

Если вы будете исправлять эту проблему - возможно ли за одно реализовать режим полного отключения светодиода. Сейчас мигание светодиода приводит к паразитной засветке ФЭУ, подключённого к E20-10, и избавиться от этого достаточно сложно (недостаточно просто заклеить светодиод, пластиковый корпус E20-10 тоже "отсвечивает"). Об этом уже шла речь в соседней ветке форума.

Насколько я знаю было решено, что отключение светодиода будет реализовано, по ориентировочным срокам позже сориентируют, т.к. тут основная работа будет в AVR, в lcomp для linux я после этого сделаю небольшой пример, как через доступ к памяти модуля этим управлять.

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

Здравствуйте!

В связи со снятием противоэпидемических ограничений в ближайшие дни (надеюсь) мы сможем приступить к работе.
Уточните, пожалуйста, готова ли версия lcomp с дополнениями, о которых идёт речь выше.

Если речь идет о изменениях, что я писал 27.05.2020, то я аналогично ltr и x502 сделал пакеты для драйвера и библиотеки lcomp. Думаю так удобнее будет распространять обновления.
Так как пакеты все ставят автоматом, то лучше удалить вручную установленные в системных директориях файлы прошлых версий (включая .rules файл для udev).
Появилось три пакета (названия для deb):
liblcomp1 - библиотека + загружаемые во время работы прошивки модулей (то что нужно для работы собранной программы)
liblcomp1-dev - заголовки и доп. файлы нужные для сборки программы с библиотекой lcomp
lcomp-dkms - драйвер собираемый через dkms (аналогично драйверу для L-502 lpcie-dkms, про который описано в пункте 2.7 https://www.lcard.ru/download/x502api.pdf)

Дополнительные функции, специфичные для E20-10, не входящие в штатный интерфейс, сейчас выполняются через работу с памятью модуля c помощью функции inm, outm. Пример использования всех этих дополнительных возможностей можно взять отсюда https://gitlab.com/l-card/acq/devices/e … r/main.cpp.
Там есть включение режима передачи тестовой последовательности и ее проверка в принимаемых данных, а также проверка переполнения/заполненности внутреннего буфера модуля.  Там много сохраняется доп данных для вывода статистики в случае ошибки, но вроде я постарался добавить комментарии, чтобы понятно было и можно было выделить нужный код.
Для сборки примера достаточно вызвать (ну и остальные штатные флаги по желанию):

g++ main.cpp -ldl -lpthread 

Тестовую последовательность лучше испытывать на таблице без цифровых каналов для тестирования на полной скорости, т.к. текущая версия прошивки ПЛИС не передает слово в интерфейс для логического канала, связанного с опросами цифровой линии, и скорость передачи соответственно меньше реальной. Также для более надежной передачи лучше использовать IRQ_STEP в 1 МСлово (1024 * 1024) и увеличить сам размер буфера драйвера lcomp.

Для избежания пересечений по именам файлов, то все заголовочные файлы lcomp помещены в поддиректорию lcomp, т.е. их нужно включать через #include "lcomp/...". Также пакет библиотеки ставит прошивки в штатное место (/usr/share/lcomp/firmware) и если в LoadBios передать нулевой указатель или пустую строку, то библиотека автоматически выбирает прошивку из стандартного места установки, чтобы не таскать все прошивки с каждой программой.

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

Отредактировано Алексей L Card (15.06.2020 16:45:31)

Спасибо!
Возникло 2 вопроса.

1. Всё это должно работать с E20-10 ревизий B, C или и той, и другой?

2. Какие файлы старых версий lcomp могут помешать установке и работе новых пакетов? Что конкретно и откуда нужно удалить?
(В данный момент lcomp собран в локальной директории проекта. Правильно ли я понимаю, что в этом случае ничего удалять не потребуется?)

1. Я проверял все это с ревизией B. Ревизия C должна быть совместима с B, но на всякий случай попробую проверить и на C.
2. У Вас должен был быть в системе установлен файл lcard.rules либо в /etc/udev/rules.d, либо в /usr/lib/udev/rules.d (по идее вручную должны ставиться в первую директорию, а вторая для автоматической установки пакетами, но т.к. в исходном readme явно не указано место копирования, точно не знаю точно, куда именно  скопировано у Вас).
   Драйвера Вы запускали каждый раз вручную через start из lcomp? Если запуск start каким-либо образом выполнялся автоматом при старте системы, то этот автозапуск понятно нужно будет убрать.
   Ну и Ваш проект должен использовать установленные заголовки (включать файлы через lcomp/<имя файла> и не должно быть локального файла в локальной директории lcomp относительно файла проекта) и загружать системную библиотеку (в dlopen можно использовать просто "liblcomp.so", если Вы ранее вручную не добавляли пусть к локальному liblcomp.so в LD_LIBRARY_PATH), как это  сделано в указанном примере по e20-10

Запуск драйверов (загрузка модулей ядра *.ko) у нас реализован из прикладной программы, управляющей экспериментом. Сделано этот так потому, что иногда наблюдается потеря доступа к E20-10. И выгрузка модулей ядра и последующая их загрузка обратно решает проблему. В связи с этим прошу уточнить, как в новых пакетах lcomp осуществляется загрузка модулей ядра и как вручную их можно выгрузить и загрузить (на случай, если это понадобится).

Модули ядра после сборки устанавливаются в системное дерево модулей в специальную ветку для внешних модулей, собранных с помощью dkms (она разная в разных дистрибутивах). Соответственно они могут загружаться при наличии подключенного устройства автоматически.
В принципе перезагрузить при желании вручную их можно также, за исключением того, что не нужно указывать расширение .ko и вместо insmod нужно использовать modprobe, т.е. файл restart может выглядеть следующим образом:

#! /bin/sh

rmmod ldevpcibm
rmmod ldevusb
rmmod ldevpci
rmmod ldevice

modprobe ldevice
modprobe ldevpcibm
modprobe ldevpci
modprobe ldevusb

Другой вопрос, что это не совсем нормальная ситуация, если приходится перезагружать модули ядра (к тому же это же еще требует запуск от root'а перезагрузки модулей). А как именно выглядит эта "потеря доступа к E20-10", какая-то конкретная функция перестает выполняться?

При вызове функции pI->GetSlotParam(&sl) начинает выдаваться неправильный тип платы: не выполняется условие if((sl.BoardType==E2010)||(sl.BoardType==E2010B)).
Дальше мы не разбирались.

Такая ошибка возникает достаточно редко, ориентировочно после месяца и более непрерывной работы компьютера и устройства E20-10 без перезагрузки.
Экспериментально установлено, что исправить это можно как выгрузкой и повторной загрузкой модулей ядра, так и просто отключением питания E20-10 и повторным подключением.

Здравствуйте!

Тестовая программа (https://gitlab.com/l-card/acq/devices/e … r/main.cpp) с E20-10 ревизии B работает нормально, а с ревизией C всегда возникает одна ошибка в самом начале. Прошу помочь разобраться. Вывод программы:

kuligin@emr102:~/0_E20-10$ ./a.out
Get IDaqLDevice interface
IDaqLDevice get success 
Free IUnknown

Read FLASH
SerNum       7T652704
BrdName      E20-10
Rev          B
DspType      AVR ATmega162
IsDacPresent 
Quartz       7500000
MCU Firmware info:
  Version:   3.1
  Date:      Feb 13 2020
Module temperature grade: commercial
Bootloader info:
  Version:   3.0
  Date:      Jul  3 2019
Buffer size(word): 33554432
Pages:             1024
IrqStep:           32768
FIFO:              0
Rate:              10000 KHz
Kadr:              0.0001 ms
Use dig channels   no
Use test sequence  yes
Dev buf ovf check  no
data thread started...
Data acquisition started. Press CTRL+C for stop...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!^C
data thread finished...
Data acqusition finished...
 Total samples processed: 117604352
 Total time (mks):        11754949
 Max block len:           32768
 Max block time (mks):    4456
 Avg receive freq         10001.9 KHz
 Module buffer state:
   overflow cntr:         0
   max words:             69490 of 8390144
   max request dtime:     722
 Total errors:            1
 Error 1:
   lcomp buf pos:         0
   proc block pos:        0
   proc block len:        32768
   block start dtime:     0
   error point dtime:     6
   receive word:          256
   expected word:         0
dump last data buffer to file...
dump finished

Ревизия показывается неверно (B вместо C).
После IsDacPresent отображается мусорный символ.