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

[Mad_Ahab]

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

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

Что у меня есть сейчас:

Общий вид

1. Есть кнопка автодетекта - первоначальной инициализации прибора
2. Есть кнопка загрузки всех прошивок (Load Program)
3. Есть командные кнопки (Get status и Random), по нажатию которых происходит либо запрос и начало приема статуса прибора и запрос и отображение приходящих псевдослучайных последовательностей - на рисунке как раз отображен результат работы этой команды.
4. Есть кнопки останова чтения и останова всей программы
5. Есть дисплей для отображения всех приходящих данных в текстовом виде и дисплей для всех же данных в "амплитудном" виде. Между ними расположены клавиши "Начать передачу" и "Остановить передачу" - они пока не функциональны.

Что я хочу сделать:

1. У меня используется один буфер для всех данных - и для текстовых, и для числовых, я хочу обрабатывать этот буфер в отдельном цикле, видимо, понадобятся очереди (я к этому еще вернусь), чтобы разделить приходящие данные - у меня есть форматы всех пакетов, распарсить можно и нужно, и разделить их на разные дисплеи.
Отдельный вопрос: как сделать "лог" из дисплея для текстовых данных - чтобы экран не перезаписывался при каждом чтении, а была возможность открутить всю ленту сообщений вверх?
2. Надо реализовать останов программы и чтения одной кнопкой - очень плохо, что сначала приходится нажимать "Stop reading", а только потом уже "Stop". Я пытался сделать как указано в топике http://www.labviewportal.org/viewtopic.php?f=23&t=153 , и все получилось, я привязал и чтение данных (нижний цикл), и цикл обработки событий интерфейса (верхний) к нажатию кнопки "Stop" - по нему стало все корректно останавливаться без выброса исключений, но перестали отображаться приходящие данные в дисплеях - в указанном топике было сказано, что аналогичный нижний цикл в примере автора топика не работает, пока не нажата кнопка "Stop" - как исправить это у себя - я не представляю. Подскажите пожалуйста.

Мои циклы-потоки

3. Есть какие-то элегантные архитектурные решения,о которых мне ничего не известно. Как должна выглядеть диаграмма более-менее серьезной программы для драйвера прибора? Какие-то элементы конечного автомата? Хорошая обработка ошибок? Чего еще нужно добавить, подскажите пожалуйста.

Спасибо, и за предыдущую помощь)

[Kosist]

Отвечу по второму пункту. Прилагаю пример - нужно просто второй цикл "зациклить" на стейт считывания.

[Mad_Ahab]

Спасибо за быстрый ответ.

Вы не могли бы немного пояснить: я запустил Ваш пример в Highlight Execution, посмотрел как работает очереди, но возник вопрос - перед case-структурой стоит Dequeue Element Function, который выдает элемент из очереди - куда? То есть, если я нажимаю "стоп", то в очередь помещается элемент типа string, в котором хранится слово "Stop", и это слово вот с помощью указанного мной узла определяет какой вариант в case-структуре выбрать? А очередь read тогда как работает? Она ведь нигде не уничтожается... То есть, каждую итерацию до нажатия "Stop" в нижнем цикле собирается очередь из слов "Read"?

[Kosist]

Dequeue Element Function выдает элементы из очереди, и они поступают на селектор Case Structure. В зависимости от значения строки, выполняется тот, или иной стейт. Мне больше нравится использовать для таких целей не строку, а enum - но код я делал на скорую руку, и со строкой быстрее.
Да, когда нижний цикл попадает на стейт Read, в очередь опять записывается стейт Read - т.е. нижний цикл зацикливается на одном стейте. По нажатию кнопки Стоп, в очередь на первое место - т.к. очередь работаете по принципу FIFO - записывается стейт стоп. И на следующей итерации нижнего цикла, Dequeue Element Function выдаст значение Stop, выполнится этот стейт, и цикл остановится, и очередь закроется.
Очередь работает по принципу One Reader - Multiply Writers. В нее данные записываются и в верхнем цикле, и в нижнем - все равно данные считаются в нижнем.
Как-то так...

[Vitekkz88]

Mad_Ahab писал(а):
1. Как сделать "лог" из дисплея для текстовых данных
2. Надо реализовать останов программы и чтения одной кнопкой - очень плохо, что сначала приходится нажимать "Stop reading", а только потом уже "Stop".
3. Как должна выглядеть диаграмма более-менее серьезной программы для драйвера прибора?.

1. Делайте конкатенацию. Между текущим и предыдущим сообщением вставляйте возврат каретки.
2. Зачем 2 кнопки стоп? А если у Вас будет 10 потоков? На каждый поток по отдельной кнопке заводить будете?Mad_Ahab, может я не ясно выражаюсь или у dadreamer проблемы с изъяснением? Мы написали Вам две архитектуры Вашего приложения. С очередями и уведомителями. Если Вы не поняли, что там происходит - давайте это и обсудим. Вы же пошли дальше и решили на конечных автоматах делать. В итоге проблемы и с очередями и с уведомителями и с автоматами.
3. У Вас диаграмма НЕ драйвера прибора. У Вас диаграмма сбора и визуализации данных с использованием .dll для работы с прибором. По стилю программирования - примеры, которые Вам приложил я и dadreamer выполнены в хорошем стиле, его и придерживайтесь. Я надеюсь Вы ведете проект, а не одну .vi? Если код получается громоздким - делайте из него SubVI и сохраняйте в папке с проектом.
Заморочьтесь с парсингом и передачей данных через очереди в другие потоки, а не "бантиками" в проекте.

[Mad_Ahab]

Vitekkz88 , спасибо за ответ.

Да, я действительно как-то недопонял с очередями и уведомителями - 3 недели назад пытался сделать с ними, у меня не получилось, попробовал сделать просто разнеся два потока, чтобы разобраться с тем как вообще эта самая многопоточность в реализуется, как она вообще выглядит хот ь на самом примитиве - и заработало.
Конечный автомат - да, хорошая штука, я сделал его в проекте на С++ для этого прибора, очень удобно получилось, здесь я просто в экземплах смотрел, потому что в Тревисе-Кринге обработка сообщений с помощью автомата сделана была, я не стал в это все лезть, выгода неочевидна, т.к. в моем приложении больше действий у пользователя, чем в моем FSM на С++. Я не рассматриваю сейчас всякие свистелки в качестве задачи - мне надо понять, на какие subVI мне предстоит разбить прибор - мне кажется, что нужно это сделать так, чтобы было неважно - с помощью функций из DLL реализована какая-то конкретная функция, или все написано как положено средствами , в каждой функции. Как-то инкапсулировать все эти функции, в общем. Как это сделать некриво на - я не знаю, в этом и суть моего вопроса насчет каких-нибудь красивых и элегантных решений. Я читаю для разных видов оборудования из сети от разных производителей, и пытаюсь понять, какого слона я не вижу, откуда по-настоящему начинается проектирование, что учитывается с самого начала проектирования на .
В этой работе кроме оборудования, сторонних для меня прошивок, моей уже разросшейся DLL и данного нет ничего. И то, как будет выглядеть этот прект зависит от меня - и я прекрасно понимаю, что одним не обойдешься. Как только я полез в очереди, мне стало ясно, что пора выделять subVI, как именно- я пока не знаю, о чем уже говорил.

Проблема, разумеется не с Вашими объяснениями, и не с постами dadreamer'a, а с моим пониманием.

[dadreamer]

Mad_Ahab, вот вам ещё один пример для более лучшего понимания: http://www.labviewportal.org/viewtopic. ... 021#p57021

[Mad_Ahab]

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

Пока я в мелких проектах разбираюсь с нотифаерами и очередями, у меня есть вопрос по логике: я тут пытаюсь сделать обработку массивов. У меня есть не очень большой массив, в 500 с небольшим элементов (четное число), типа uint8_t, мне нужно взять элементы попарно, 1-2, 3-4, 5-6 и т.д., затем их развернуть (в LV есть, кажется, простой своп 8-разрядных чисел), потом эти развернутые пары по одной записать в uint16_t - с помощью Join Numbers Function, например.
Я уже мозг сломал, пытаясь подобрать нужный вид цикла для этого и как ввести множитель на итератор - чтобы хватать четные и нечетные элементы массива и оперировать ими. Как можно это сделать? Я не понимаю как управлять итератором в цикле for.
Сделаю это- и почти вся базовая обработка данных будет сделана.

[dadreamer]

Mad_Ahab, так надо?

[Mad_Ahab]

Mad_Ahab, так надо?

Да, совершенно верно, спасибо большое - я пытался сделать как в верхнем цикле, но допустил две грубые ошибки - с узлом Decimate 1D Array все гораздо проще. Я как-то даже не обращал на него внимания, думая, что он работает немного по-другому и не знал, что его можно растягивать и от этого зависит очень многое.

Теперь я обнаружил у себя еще одну ошибку, при разборе получаемых данных - думал, что я ее обошел, но это не так:
у меня в отдельном while loop крутится функция из dll "read_data", она считывает из аппаратного буфера все, что в него валится по мере появления. Появляются там и данные, которые надо обсчитать и визуализировать: для данной задачи - это 523 пачки данных с небольшой вариацией в размере (как правило - около 500 байт, но бывают исключения). Будет другая задача - будет другое число пачек, это варьируется. Каждая пара элементов в одной пачке обрабатывается так, как мне показал уважаемый dadreamer.
Суть моей проблемы: мне надо конкатенировать как-то массивы-пачки, отображать мне нужно не одну (сейчас у меня - последняя отображается, собирается из автоиндексированного цикла, после всяких разворотов и ЦОС над каждой развернутой и объединенной парой элементов), а все, по мере их накопления. То есть есть цикл большой, цикл-поток: в нем происходит чтение данных, потом принятая пачка, как только принимается - сразу идет в цикл for там, разбирается, обрабатывается, и собирается опять на выходе из него - и теперь ее отображаю. После того как пройдет серия пачек, само собой, замечаю только последнюю.

Как создать такой массив, в котором можно было бы накапливать пачки, присоединяя их одну за другой после обработки, попутно отображая их по мере накопления? То есть, показывая растущий вправо плотный график? (в нем будут от 0 до 510 отрезков по оси абсцисс, на каждый отрезок- новая пачка данных после обработки).
Уже промучился с несколькими вариантами, но наращивать массив, созданный вне большого цикла чтения, просто так не удается (

[Mad_Ahab]

Вот диаграмма:

1 - отображение текста, ели он пришел
2 - я попытался создать накапливающийся массив, но в итоге не смог его правильно включить в большой цикл
3 - собственно, сбор одной пачки из 523 с помощью автоиндексации и ее отображение

[Kosist]

Вам нужно или использовать Build Array - чтобы постоянно добавлять значения в массив, или Replace Array Subset - чтобы сначала проинициализировать массив, а затем заполнять его, как буфер. Ну, и сдвиговые регистры нужно использовать.

[Mad_Ahab]

Да, спасибо, я не знал, что вид Build Array настраивается. Сделал верхним способом, с заданием пустого массива без длины с нулем и пополнением в цикле со сдвиговыми регистрами.

Теперь, я считываю пришедшие данные, которые были повернуты и превращены в int16_t, и вот что вижу на выходе: это все пачки, все значения в них:

Грубый график, на нем отображены все пришедшие в 500-х пачках 130000 с лишним байтов - почему-то происходит переполнение (?)

Это может быть из-за использования сдвиговых регистров?

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

[Vitekkz88]

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

Несколько сотен "чего"? Вольты, мВ, мкВ или отсчетов АЦП? На графике у Вас максимум в районе 32768 - возможно задействована вся разрядная сетка 16-битного АЦП(если данные с АЦП идут на визуализацию). Либо это ограничение из-за преобразования данных в int 16. Скорее всего у Вас ошибка в разворотах байт. Выводите полученные данные в массиве и смотрите их в hex-е. Сравнивайте что посылаете и что получаете. Если данные по TCP передаются - то возможны развороты байт в слове(кстати, какая длинна слова в пакете?) на транспортном уровне.

[Mad_Ahab]

Несколько сотен "чего"? Вольты, мВ, мкВ или отсчетов АЦП?

Да, это отсчеты АЦП. Получилось исправить страшенную "пилу" - у меня в пакетах есть поле номера пакета - а часть данных, хранящих его, я неправильно вырезал из массива - теперь все в порядке, я получил данные с АЦП, без потерь и страшных пил, получил и синус с генератора, и шум на АЦП, который туда приемник помещает посмотрел - все в порядке.
Постепенно я подхожу к концу всей идеологической части - получить сигнал, отобразить, спектр посмотреть и т.д. - и буду переписывать работающий функционал через очереди и нотифаеры, потом выделю подприборы и уже что-то должно принять хоть какой-то не такой позорный вид.
Однако, надо доделать простые вещи - я сейчас читаю об отображении данных на интерфейсе, смотрю у Тревиса. Пользуюсь я
Waveform Graph, и пока не очень понимаю какие настройки у всех этих дисплеев: я не понимаю, как можно заставить обновляться весь отображаемый ряд данных при новом запросе данных из АЦП. У меня накапливается массив, но я хочу понять как (когда?) его снова сбрасывать весь, чтобы начать собирать снова пачки пришедших данных из буфера - чтобы по нажатию кнопки на интерфейсе для запроса АЦП у меня просто перерисовался график. Сейчас он у меня пририсовывается к старому в конец
Еще есть вопрос, пока не очень для меня ясный в терминах вообще - у меня синус несколько ломаный, частоты дискретизации не хватает, для того чтобы отобразить данные плавно - чего-то я пока не догоняю, это же такие данные приходят? Я с ними в общем-то ничего не делаю такого особенного... (все еще график отсчетов АЦП от их номера)

а вот и каракули)

Безымянный1.jpg (52.72 КБ) 10299 просмотров