|
- Участник
- Здесь с 28.12.2022
- Сообщений: 6
|
E2010 orangepi 4
Добрый день Успешно собрал lcomp под linux (debian x64), пытаюсь собрать для orangepi с ОС Orangepi4-lts_3.0.6_debian_bullseye_desktop_xfce_linux5.10.43 Файл Readme прочел, libatomic_ops собрал, атомарные операции в stubs.h раскомментировал. Получаю следующую ошибку make -C /lib/modules/5.10.0-18-arm64/build/ M=/home/orangepi/qt/e2010 modules make[1]: Entering directory '/usr/src/linux-headers-5.10.0-18-arm64' CC [M] /home/orangepi/qt/e2010/ldevice.o CC [M] /home/orangepi/qt/e2010/l760.o CC [M] /home/orangepi/qt/e2010/ldevpciu.o LD [M] /home/orangepi/qt/e2010/ldevpci.o CC [M] /home/orangepi/qt/e2010/e2010.o CC [M] /home/orangepi/qt/e2010/e140.o CC [M] /home/orangepi/qt/e2010/e440.o CC [M] /home/orangepi/qt/e2010/e154.o CC [M] /home/orangepi/qt/e2010/ldevusbu.o LD [M] /home/orangepi/qt/e2010/ldevusb.o CC [M] /home/orangepi/qt/e2010/l791.o CC [M] /home/orangepi/qt/e2010/ldevpcib.o LD [M] /home/orangepi/qt/e2010/ldevpcibm.o MODPOST /home/orangepi/qt/e2010/Module.symvers ERROR: modpost: "__aarch64_swp4_acq" [/home/orangepi/qt/e2010/ldevusb.ko] undefined! make[3]: *** [/usr/src/linux-headers-5.10.0-18-common/scripts/Makefile.modpost:123: /home/orangepi/qt/e2010/Module.symvers] Error 1 make[3]: *** Deleting file '/home/orangepi/qt/e2010/Module.symvers' make[2]: *** [/usr/src/linux-headers-5.10.0-18-common/Makefile:1760: modules] Error 2 make[1]: *** [/usr/src/linux-headers-5.10.0-18-common/Makefile:185: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-18-arm64' make: *** [Makefile:29: modules] Error 2 Подскажите пожалуйста куда копать?
|
|
- Сотрудник "Л Кард"
- Здесь с 17.04.2014
- Сообщений: 1,291
|
Re: E2010 orangepi 4
А какую версию исходников lcomp (по какой ссылке скачивали) пытаетесь собрать?
|
|
- Участник
- Здесь с 28.12.2022
- Сообщений: 6
|
Re: E2010 orangepi 4
В Readme указана версия 1.57.1 Скачано с сайта https://www.lcard.ru/download/lcomp_linux.tgz
|
|
- Сотрудник "Л Кард"
- Здесь с 17.04.2014
- Сообщений: 1,291
|
Re: E2010 orangepi 4
А в версии 1.58 это проявляется? Можно взять либо готовые пакеты для Debian aarch64 (описано в https://www.lcard.ru/download/lcard_lin … utions.pdf, пакеты lcomp-dkms и liblcomp1-dev), либо исходники есть на git (драйвер https://gitlab.com/l-card/acq/devices/e … iver_linux, библиотека https://gitlab.com/l-card/acq/devices/e … p_library)
|
|
- Участник
- Здесь с 28.12.2022
- Сообщений: 6
|
Re: E2010 orangepi 4
Установил пакеты lcomp-dkms и liblcomp1-dev. Версия 1.58.2. К проекту линкую libcomp из каталога /usr/lib/ Столкнулся со следующей странностью. Использую e2010 для оцифровки одиночных импульсов известной длительности со стартом по сигналу на DI16. При этом задаю размер буфера исходя из длительности, а также задаю номер канала. Размер буфера делаю кратным IrqStep. Вот код инициализации class e2010 : public QObject {
....
private:
....
unsigned short *adc_buffer_pointer = nullptr; /* ADC buffer pointer */
unsigned int *adc_buffer_offset = nullptr; /* ADC buffer offset in words */
unsigned int _channel_number = 1;
unsigned int _ freq = 10000000;
unsigned int _size = 0;
unsigned int _IrqStep = 4096;
};
void e2010::init() {
ADC_PAR adcPar;
PLATA_DESCR_U2 pd;
SLOT_PAR sl;
ULONG size;
m_pI->GetSlotParam( &sl );
m_pI->ReadPlataDescr( &pd ); // fill up properties
size = _freq * this->get_duration();
if ((size % _IrqStep) == 0) {
;
} else {
size = ((int)(size / _IrqStep)) * _IrqStep + _IrqStep;
}
if (size < _IrqStep) {
size = _IrqStep;
}
_size = size;
ULONG res = m_pI->RequestBufferStream( &size );
if (res == L_SUCCESS) {
qCDebug(logDebug()) << "e2010: success alloc size" << size;
} else if (res == L_ERROR) {
qCDebug(logDebug()) << "error";
}
switch( sl.BoardType )
{
case E2010B:
case E2010:
{
adcPar.t2.s_Type = L_ADC_PARAM;
adcPar.t2.AutoInit = 0; //1
adcPar.t2.dRate = _freq / 1000.0; /* частота в кадре (KHz)*/ // Fsampling
adcPar.t2.dKadr = 0; /* задержка между кадрами */ // 1000.0 / Fsampling //1000.0 / _freq;
adcPar.t2.SynchroType = EXT_START_UP; //INT_START
adcPar.t2.SynchroSrc = INT_CLK;
switch (this->get_channel_number()) {
case 1:
adcPar.t2.AdcIMask = SIG_0 | V30_0 | GND_1 | GND_2 | GND_3;
break;
case 2:
adcPar.t2.AdcIMask = SIG_1 | V30_1 | GND_0 | GND_2 | GND_3;
break;
case 3:
adcPar.t2.AdcIMask = SIG_2 | V30_2 | GND_0 | GND_1 | GND_3;
break;
case 4:
adcPar.t2.AdcIMask = SIG_3 | V30_3 | GND_0 | GND_1 | GND_2;
break;
default:
break;
}
adcPar.t2.NCh = 1; //NCh
adcPar.t2.Chn[0] = this->get_channel_number() - 1;
adcPar.t2.FIFO = 0; //32768 //not used
adcPar.t2.IrqStep = _IrqStep;
adcPar.t2.Pages = size / _IrqStep; //64; in words
adcPar.t2.IrqEna = 1;
adcPar.t2.AdcEna = 1;
// extra sync mode
adcPar.t2.StartCnt = 0;
adcPar.t2.StopCnt = 0;
adcPar.t2.DM_Ena = 0;
adcPar.t2.SynchroMode = 0;
adcPar.t2.AdPorog = 0;
m_pI->FillDAQparameters( &adcPar.t2 );
m_pI->SetParametersStream( &adcPar.t2, &size, ( void ** ) &adc_buffer_pointer, ( void ** ) &adc_buffer_offset, L_STREAM_ADC );
m_adcPar = adcPar;
} break;
}
m_pI->EnableCorrection();
m_pI->InitStartLDevice();
qCDebug(logDebug) << "e2010: StartLDevice";
m_pI->StartLDevice();
_buffer_size = m_adcPar.t2.IrqStep*m_adcPar.t2.Pages;
}
Затем по таймеру смотрю наполненность буфера void e2010::check_ready() {
qCDebug(logDebug()) << "adc_buffer_offset" << *adc_buffer_offset;
if (*adc_buffer_offset >= _buffer_size) {
this->stop();
}
}
void e2010::stop() {
m_pI->StopLDevice();
emit response(adc_buffer_pointer);
qCDebug(logDebug) << "e2010: StopLDevice";
}
При этом в некоторые моменты, раз в несколько импульсов, буфер наполняется по несколько раз. Вот лог, демонстрирующий этот момент. 2023-01-27 14:18:39.545 [Debug] : e2010: success alloc size 106496 2023-01-27 14:18:39.546 [Debug] : Buffer size(word): 106496 2023-01-27 14:18:39.546 [Debug] : Pages: 26 2023-01-27 14:18:39.547 [Debug] : IrqStep: 4096 2023-01-27 14:18:39.548 [Debug] : FIFO: 0 2023-01-27 14:18:39.548 [Debug] : Rate: 10000 2023-01-27 14:18:39.548 [Debug] : Kadr: 0.0001 2023-01-27 14:18:39.561 [Debug] : e2010: StartLDevice 2023-01-27 14:18:39.603 [Debug] : adc_buffer_offset 0 2023-01-27 14:18:39.617 [Debug] : adc_buffer_offset 0 2023-01-27 14:18:39.619 [Debug] : adc_buffer_offset 0 2023-01-27 14:18:39.621 [Debug] : adc_buffer_offset 0 2023-01-27 14:18:39.623 [Debug] : adc_buffer_offset 0 2023-01-27 14:18:39.624 [Debug] : adc_buffer_offset 4096 2023-01-27 14:18:39.625 [Debug] : adc_buffer_offset 8192 2023-01-27 14:18:39.625 [Debug] : adc_buffer_offset 12288 2023-01-27 14:18:39.626 [Debug] : adc_buffer_offset 16384 2023-01-27 14:18:39.628 [Debug] : adc_buffer_offset 20480 2023-01-27 14:18:39.628 [Debug] : adc_buffer_offset 24576 2023-01-27 14:18:39.629 [Debug] : adc_buffer_offset 24576 2023-01-27 14:18:39.630 [Debug] : adc_buffer_offset 32768 2023-01-27 14:18:39.631 [Debug] : adc_buffer_offset 32768 2023-01-27 14:18:39.632 [Debug] : adc_buffer_offset 40960 2023-01-27 14:18:39.633 [Debug] : adc_buffer_offset 45056 2023-01-27 14:18:39.635 [Debug] : adc_buffer_offset 49152 2023-01-27 14:18:39.635 [Debug] : adc_buffer_offset 53248 2023-01-27 14:18:39.637 [Debug] : adc_buffer_offset 57344 2023-01-27 14:18:39.638 [Debug] : adc_buffer_offset 61440 2023-01-27 14:18:39.638 [Debug] : adc_buffer_offset 61440 2023-01-27 14:18:39.639 [Debug] : adc_buffer_offset 65536 2023-01-27 14:18:39.641 [Debug] : adc_buffer_offset 73728 2023-01-27 14:18:39.643 [Debug] : adc_buffer_offset 81920 2023-01-27 14:18:39.644 [Debug] : adc_buffer_offset 86016 2023-01-27 14:18:39.645 [Debug] : adc_buffer_offset 94208 2023-01-27 14:18:39.647 [Debug] : adc_buffer_offset 102400 2023-01-27 14:18:39.649 [Debug] : adc_buffer_offset 106496 2023-01-27 14:18:39.650 [Debug] : adc_buffer_offset 4096 2023-01-27 14:18:39.651 [Debug] : adc_buffer_offset 8192 2023-01-27 14:18:39.652 [Debug] : adc_buffer_offset 12288 2023-01-27 14:18:39.653 [Debug] : adc_buffer_offset 16384 2023-01-27 14:18:39.654 [Debug] : adc_buffer_offset 20480 2023-01-27 14:18:39.654 [Debug] : adc_buffer_offset 24576 2023-01-27 14:18:39.656 [Debug] : adc_buffer_offset 32768 2023-01-27 14:18:39.658 [Debug] : adc_buffer_offset 36864 2023-01-27 14:18:39.659 [Debug] : adc_buffer_offset 40960 2023-01-27 14:18:39.659 [Debug] : adc_buffer_offset 45056 2023-01-27 14:18:39.661 [Debug] : adc_buffer_offset 49152 2023-01-27 14:18:39.663 [Debug] : adc_buffer_offset 57344 2023-01-27 14:18:39.664 [Debug] : adc_buffer_offset 61440 2023-01-27 14:18:39.665 [Debug] : adc_buffer_offset 65536 2023-01-27 14:18:39.665 [Debug] : adc_buffer_offset 69632 2023-01-27 14:18:39.667 [Debug] : adc_buffer_offset 73728 2023-01-27 14:18:39.668 [Debug] : adc_buffer_offset 77824 2023-01-27 14:18:39.669 [Debug] : adc_buffer_offset 81920 2023-01-27 14:18:39.669 [Debug] : adc_buffer_offset 81920 2023-01-27 14:18:39.671 [Debug] : adc_buffer_offset 90112 2023-01-27 14:18:39.672 [Debug] : adc_buffer_offset 94208 2023-01-27 14:18:39.673 [Debug] : adc_buffer_offset 98304 2023-01-27 14:18:39.673 [Debug] : adc_buffer_offset 98304 2023-01-27 14:18:39.675 [Debug] : adc_buffer_offset 102400 2023-01-27 14:18:39.684 [Debug] : e2010: StopLDevice
|
|
- Сотрудник "Л Кард"
- Здесь с 17.04.2014
- Сообщений: 1,291
|
Re: E2010 orangepi 4
Если я правильно понял, исходя из настроек Вы по первому фронту на DI16 запускаете сбор, который дальше уже идет непрерывно (судя по StopCnt = 0) с частотой 10 МГц независимо от внешних импульсов. Далее не совсем понятно, вы пишите про вызов check_ready() по таймеру. Каким образом и с каким периодом это происходит? Надо учитывать, что программный таймер имеет задержку (случайно меняющуюся от вызова к вызову) и на пути данных от модуля до буфера и проверки программой тоже могут быть задержки, поэтому если таймер выставлен исходя из IrqStep, то в общем в зависимости от соотношения задержек он может в каждую итерацию сработать чуть раньше или чуть позже, чем пришел новый пакет данных, что в общем и соответствует выводу, когда сперва значение счетчика повторяется (таймер сработал чуть раньше), а затем увеличивается сразу на два (пришел пропущенный ранее пакет и новый). При этом если частота у Вас 10 МГц, то время IRQStep 4096 получается вообще меньше пол мс? Не совсем понятно, как Вы его контролируете, ОС общего назначения может задерживаться и на более длительные времена. Также не совсем понял про "раз в несколько импульсов" - как контролируется число импульсов, т.к. сбор у Вас после первого фронта идет непрерывно?
|
|
- Участник
- Здесь с 28.12.2022
- Сообщений: 6
|
Re: E2010 orangepi 4
Да, я по сути хочу чтобы по фронту на DI16 запустился сбор и оцифровал мне некоторую длительность на некотором канале. Каждый мой импульс - это должна быть новая инициализация тк длительность и канал разные, и новый фронт. Новый фронт приходит только после обработки данных response(adc_buffer_pointer) и нового вызова init. Таймер в случае лога шел с периодом 1мс. Да, я понимаю что у меня не ОСРВ и мой таймер не синхронизирован с процессом сбора. По таймеру я не обрабатываю ничего, только смотрю завершился сбор или нет. Если я задал однократный сбор (adcPar.t2.AutoInit = 0;) и задал какое то количество страниц Pages, то я ожидаю что заполнив весь буфер процесс оцифровки остановится. Или я ошибаюсь?
|
|
- Сотрудник "Л Кард"
- Здесь с 17.04.2014
- Сообщений: 1,291
|
Re: E2010 orangepi 4
Теперь понял, проблема в том, что при AutoInit = 0 не выполняется останов на конце буфера. Тогда посмотрю, видимо действительно в нем проблема с работой в текущей версии. А как именно Вы проверяете, что сбор буфера завершился и по какому условию вызывается e2010::stop()?
|
|
- Участник
- Здесь с 28.12.2022
- Сообщений: 6
|
Re: E2010 orangepi 4
StopLDevice вызывается в stop, который вызывается исходя из проверки условия с adc_buffer_offset в check_ready.
|
|
- Сотрудник "Л Кард"
- Здесь с 17.04.2014
- Сообщений: 1,291
|
Re: E2010 orangepi 4
Точно. Смутил вывод, но видимо за время отладочного вывода adc_buffer_offset значение самого adc_buffer_offset успевает изменится на IrqStep, поэтому при выводе adc_buffer_offset == 106496 (_buffer_size) сбор продолжается (т.к. за время вывода до проверки успевает IrqStep стать 4096), а при выводе 102400 - останавливается (т.к. до проверки успевает стать 106496). По сути действительно сейчас автостоп не работает в этой версии и модуль продолжает собирать данные, а выполнится останов или нет зависит от того, попадете Вы при проверки на значение 106496 или нет. Тогда как поправлю выложу новую версию.
|
|
- Сотрудник "Л Кард"
- Здесь с 17.04.2014
- Сообщений: 1,291
|
Re: E2010 orangepi 4
Закинул на сервер сборки пакетов версию 1.58.3 для lcomp-dkms, должно быть доступно обновление в ближайшее время, тогда попробуйте - решится ли проблема. У меня этот режим теперь заработал, проверял для достоверности корректной работы, что за несколько проверок после дохождения до конца буфера позиция остается равной размеру буфера, а также, что первый отсчет остается неизменный, с момента прихода первых данных.
|
|
- Участник
- Здесь с 28.12.2022
- Сообщений: 6
|
Re: E2010 orangepi 4
Вроде заработало, спасибо!
|