Разработка sdr-драйвера LabVIEW

[dadreamer]

Где взять эту DLL?

Нужно в опциях линкера подключить labview.lib:

Здесь CINTOOLS_DIR - это переменная среды, равная "C:\Program Files (x86)\National Instruments\LabVIEW [ваша версия LabVIEW]\cintools"

upd:
Mad_Ahab, долго же я ответ сочинял!

[Mad_Ahab]

В общем, бился-бился, пока вот такой вариант чтения данных: упрощенная схема Vitekkz88

Пока что у меня в цикле крутится функция read_data, пока я не останавливаю захват данных кнопкой stop.
Тем не менее, у меня никакие данные нигде почему-то не отображаются... и счетчик элементов очереди не меняет свое значение, в общем
Чего-то я не понимаю.. Вроде бы все просто: заводим очередь, в цикле пихаем в нее элементы, размером с буфер (1024 байт) и в параллельном же потоке читаем данные и выталкиваем их из очереди. Однако, не срабатывает, хотя функция из DLL работает корректно, я проверил в отладчике.

Хотя как минимум ответ от автодетекта read_data должна была забрать из аппаратного буфера.
Пока что работа с многопоточным чтением данных для меня - самое сложное во всей работе. Если справлюсь с этим то с прибором все получится.

[Mad_Ahab]

Может быть, т.к. чтение работает до тех пор, пока не нажата кнопка stop, то и вся остальная часть диаграммы не задействована? То есть, пока крутятся потоки с очередью и чтением, у меня не проходит конфигурация. Следовательно, читать нечего. А как сделать так, чтобы и чтение крутилось постоянно, и программа вся остальная выполнялась поэтапно дальше до самого конца? Решение в виде гигантского цикла с условием, в котором вся остальная часть программы выполняется, мне кажется некрасивым и неправильным.
И все же я не понимаю, где ответ от автодетекта...

[Mad_Ahab]

Сейчас я прошел свою программу по шагам - получается, что циклы с захватом и отображением данных в принципе работают неплохо - очередь заполняется сообщениями постепенно, и также постепенно они из очереди выводятся на экран. Но если программу запустить как положено, в непрерывном режиме, то на дисплеях просто ничего не отображается - видимо, не успевает. Только в конце программы, после останова, появится нечитаемое сообщение из последнего элемента очереди (она там действительно есть, все ОК)
Тем не менее, циклы для захвата и отображения данных полностью захватывают управление в программе и не освобождают его - потому что данные идут и идут, и перехода на следующие этапы не происходит. Может, нужно сделать конечный автомат какой-нибудь? Только там придется точно парсить пакеты посимвольно или по крайней мере, опрашивать пользователя, переходить дальше, или нет.
Вопрос: как сделать так, чтобы после инициализации хэндл прибора где-то сохранился, и его можно было использовать в произвольные моменты по требованию - то есть, работать следующим образом:
1. Запуск прибора
2. Инициализация, начинает крутиться цикл "захват-отображение данных"
3. Все встает, передняя панель доступна для работы, прибор ждет указаний пользователя
----
4. Нажимаю кнопку "Автодетект": происходит автодетект, на дисплее отображается акноледж от автодетекта
5. Все стоит, передняя панель доступна, прибор ждет действий
6. Нажимаю кнопку "Конфигурация": в устройство уходят конфигурационные команды, отображается акноледж, он текстовый
7. Все стоит ...
8. Нажимаю кнопку "Генерация псевдослучайной последовательности": прибор получает эту команду, отображается акноледж.
9. Все стоит, данные продолжаются отображаться
10. Нажимаю кнопку "Отобразить спектр": в амплитудном дисплее начинает отображаться текущий спектр
....
N. В конеце, или в любой момент когда все стоит и ждет указаний, я могу нажать кнопку "стоп", и соединение разорвется, работа будет остановлена.

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

[Mad_Ahab]

Получается, что для многоканального N-канального устройства-приемопередатчика должно быть 2*N независимых потоков: по 1 потоку управления и 1 потоку данных на каждый канал.
Как организовать такую многопоточность? С помощью подписки на поток, как описывал dadreamer? Я пока не очень разобрался с тем примером, потому что непонятно, зачем переназначение указателя на массив, если в нижней петле возбуждается событие по изменению буферного массива - у нас же, значит, уже есть новое состояние массива и тогда зачем дополнительно назначается новое значение указателя... Но это к слову.
Мне надо понять как унифицированно, просто, и в самом начале организовать такую многопоточность для управления каналами и передачи команд

[dadreamer]

у меня никакие данные нигде почему-то не отображаются...

У вас на скрине я вижу как минимум одну некорректность. Она также есть и на диаграмме Vitekkz88.

Нужно сделать так:

[dadreamer]

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

По большей части для универсальности: ведь указатель может поменяться по ходу работы программы, а нам нужно иметь всегда актуальный указатель, иначе мы ничего не получим, а то и, хуже того, заработаем access violation. Но если вы на 100% уверены, что у вас указатель не изменится, то передайте его 1 раз в где-то в начале программы, а потом можете генерировать эвент чем угодно: логической переменной или произвольным числом.

[Mad_Ahab]

У вас на скрине я вижу как минимум одну некорректность.

Да, действительно, спасибо за поправку, я пока даже не замечаю подобные нюансы( Слишком много вопросов.

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

[dadreamer]

Однако, все равно, обработка не заканчивается и управление не отпускает.

Так вам нужно остановить программу? Введите ещё один кадр эвента на нажатие кнопки Stop (Value Change), в котором запишите в нотифаер True. Остальные циклы должны остановиться. А в вашей библиотеке должна быть какая-нибудь функция Stop_Transfer или типа того, чтобы там тоже остановить все потоки.

Посмотрел внимательней, у вас получается нотифаер Captured используется для старта передачи данных. Тогда вам придётся завести ещё один нотифаер Stop для останова. Хотя, как-то запутанно получается. В идеале, конечно проще было бы иметь две обычных кнопки Start и Stop. Нажатия на них обрабатывать в Event Structure. А нотифаер всего один на всю программу - Stop.

[Mad_Ahab]

Так вам нужно остановить программу? Введите ещё один кадр эвента на нажатие кнопки Stop (Value Change), в котором запишите в нотифаер True. Остальные циклы должны остановиться. А в вашей библиотеке должна быть какая-нибудь функция Stop_Transfer или типа того, чтобы там тоже остановить все потоки.

Нет, мне нужно, чтобы программа работала дальше, попутно выводя на дисплей проходящие данные. Просто оставаться только на обработке и выводе данных не должна. Я выше подробно описал, как я представляю работу , управляющего прибором. Я ищу сейчас архитектурное решение - оказалось, что многопоточность в очень сильно отличается от многопоточности в С++
.

[Mad_Ahab]

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

В результате, и счетчик бежит, и автомата переходит совершенно независимо из состояния в состояние по нажатию соответствующих клавиш на передней панели. Просто мечта.
Но вот у меня в программе для устройства все же есть некоторая зависимость по данным: это указатель на прибор. Мне кажется, параллельность идеальной не получается потому, что одновременно дергать этот самый хэндл разными функциями в программе одновременно нельзя. Или я неправ?

[Vitekkz88]

У вас на скрине я вижу как минимум одну некорректность. Она также есть и на диаграмме Vitekkz88.
Нужно сделать так:

Ничего подобного. Что действительно НУЖНО, так это полноценный FlowControl - это будет корректно. А таймаут для ожидания элемента в данном случае - фигня

многопоточность в очень сильно отличается от многопоточности в С++

В LabVIEW многопоточность представлена в максимально простом для понимания виде.
http://mp.fizteh.urfu.ru/Users/Kalinin/ ... tithrd.pdf
http://www.physics.utah.edu/~jui/3620/s ... 49ch09.pdf
Можете глянуть по ссылкам, там правда на английском. Да и посковик по запросу "Multithreading in LabVIEW" выдает много чего.

[dadreamer]

Тогда вам придётся завести ещё один нотифаер Stop для останова.

Накидал вот такой простой пример с двумя нотифаерами. Может быть, вам окажется полезным.

Test.vi

lv2013

(18.07 КБ) 197 скачиваний

А таймаут для ожидания элемента в данном случае - фигня

Ну как же, если таймаут, то данные пусты и на индикаторе ничего нет. И полезные данные можно увидеть (если повезет) только мельком, а потом их сразу же затирает пустое сообщение. Не вижу тут ничего корректного. Нужно сразу отсеивать такие вещи.
upd:
Хотя, может быть, чуть-чуть поспешил, там по дефолту -1 стоит, т.е. будет ждать бесконечно. Но в этом случае мы программу никогда не остановим. Это тоже неправильно.

Мне кажется, параллельность идеальной не получается потому, что одновременно дергать этот самый хэндл разными функциями в программе одновременно нельзя.

Вы имеете в виду параллельные обращения к вашей библиотеке в коде ? Лучше бы, конечно, обращаться к ней последовательно и исключить наложения вызовов в разных потоках.

[Vitekkz88]

dadreamer,

Хотя, может быть, чуть-чуть поспешил, там по дефолту -1 стоит, т.е. будет ждать бесконечно. Но в этом случае мы программу никогда не остановим. Это тоже неправильно.

http://www.labviewportal.org/viewtopic. ... =75#p62401
Это мой пример. Скачайте его и убедитесь, что все потоки завершаются корректно! Даже с таймаутом "-1" на чтение. Элементарное уничтожение очереди вызовет ошибку для элементов одноименной очереди!
Другое дело, если у Вас в очередь будут данные наваливать постоянно и никто их выгребать не будет. Но это уже другая история.

И полезные данные можно увидеть (если повезет) только мельком, а потом их сразу же затирает пустое сообщение. Не вижу тут ничего корректного.

Это если данные снимаются один раз. То есть прилетело одно сообщение и дальше ничего не приходит. И даже в этом случае на индикаторе будет отображаться последнее снятое значение! Вы запустите мой пример, начните захват, а потом остановите захват. И что? Всё стёрлось? Ну а если данные поступают с пропусками или так: данные-данные-данные-пустое сообщение-пустое сообщение-данные-пустое сообщение и т.д. - то уж извините - тут надо на протокольном уровне разруливать и делать реализацию соответсующую. Чтоб не получить то, что Вы говорите. Пустые сообщения надо либо пропускать(условие завести) либо не формировать на передающей стороне. А из очереди "пустота" не полезет. Есть че - выгребает, нет ничего - ждем-с прихода. И раз на то пошло, то можно поставить блок с информацией о количестве элементов в очереди. И если их ноль - то ничего не делать(кейс завести с соответствующим условием), иначе выгребать.
С прибора гонится стрим, не? Или чтение происходит единожды и всё? Снимается пачка данных определенного размера?Или чтение по байту?Если пакет снимается, то в таком случае можно всё на одном регистре сделать. Запоминать текущее сообщение и ждать следующее. Пришло следующее - добавлять к предыдущему(если надо) или удалять предыдущее и снова ждать следующее. Тем временем регистр будет хранить последнее значение. А если запрос данных производится по нажатию кнопки - то можно вообще обойтись одним циклом с event-структурой без всякой многопоточности. Кнопочку нажал - данные получил. Еще раз нажал - получил новый срез и т.д. А если чтение идет по одному байту непрерывно(что является верхом нерациональности) - то копите эти байты по одной штучке до необходимого объема и потом разбирайте в отдельном потоке.
Mad_Ahab,

Лучше бы, конечно, обращаться к ней последовательно и исключить наложения вызовов в разных потоках.

Именно так Вы и должны действовать. Не усложняйте, всё гораздо проще

[dadreamer]

Скачайте его и убедитесь, что все потоки завершаются корректно!

Пример-то я качал, но внимания не обратил, что

Элементарное уничтожение очереди вызовет ошибку для элементов одноименной очереди!

Я, признаться даже, таким методом никогда не пользовался (кроме как для нотифаера), всегда ставил тайм-аут. Век живи - век учись.