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

[Mad_Ahab]

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

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

Передо мной стоит задача - разработать ДРАЙВЕР software-defined-radio прибора для LV.
После продолжительного гугления и чтения хелпа с ni.com, я выяснил, что мы с научным руководителем подразумеваем разные вещи под названием "драйвер для LaVIEW". Он имеет в виду специализированное ПО, которое обеспечивая связь с прибором, в отдельном thread операционной системы (или в отдельных - с элементами синхронизаци типа мьютексов) передает поток данных от прибора в хост, по одному из множества интерфейсов. Передача происходит в приложение, написанное на LV, и драйвер совершенно не интересует, что там будут делать эти "кубики LV" дальше. То есть, классическое нормальное программистское понимание драйверного ПО.
У меня же, после прочтения вайтпепера "Developing LabVIEW Plug and Play Instrument Drivers" (внимательно прочел, переведя его полностью), сложилось впечатление, что "драйвер LV" - это особым образом сконфигурированный VI, в котором реализованы стандартные базовые и кастомные функции работы с оборудованием в соответствии с предложенной в указанной статье схемой (стандартизированная NI древовидная структура subVI).
После этой статьи я попытался разобраться с рекомендуемыми в ней к использованию функциями VISA (а потом и к IVI), от них перешел на рассмотрение JKI и возможности создать свой Toolkit для LV (это я зря, наверное).
Поняв, что начинаю тонуть в информации и почти наверняка что-то важное упускаю, прошу ответить на следующие вопросы:

1. Достаточен ли подход, указанный в приведенной выше статье для написания полноценного драйвера прибора?
2. Можно ли средствами LV обеспечить тот функционал, который я описал как традиционный ("воткнувшись" между ОС и прибором)? Или на LV разработывается только user-mode приложение, которое нуждается в
более низкоуровневом ПО?
3. Если на LV можно сделать такое низкоуровневое ПО, то необходимо ли для разработки драйвера использовать VISA- или IVI-функции? В чем разница между VISA и IVI?
4. Вот у меня сделано приложение с помощью стандартных средств LV для какого-то интерфейса, например, для связи с прибором по Ethernet (используя TCP Open Connect и др. стндартные функции из палитры протокола TCP),
можно ли стандартными средствами LV так же подключать прибор по PCI-Express? Или лучше для каждого случая писать свою dll, которую потом звать из LV?
5. Много гуглил и читал про niUSRP - кто-нибудь с ним работал? Как можно разработать свое аналогичное LV-ПО для своей системы?

6. Или я все усложняю, и есть более очевидный подход (очень надеюсь на это)? Если да, то укажите, пожалуйста.

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

На данный момент в LV реализована возможность вызова прибора по TCP, его первоначальной инициализации.

Спасибо.

[Vitekkz88]

Mad_Ahab писал(а):Передо мной стоит задача - разработать ДРАЙВЕР software-defined-radio прибора для LV.

Ваш научный руководитель весьма оптимистичен. Давайте уточним: какой именно у Вас прибор? Какие интерфейсы ввода/вывода у него есть?
Возможно, что для Вашего прибора уже существуют драйвера.
Если же у Вас прибор "самодельный", то на чем реализован интерфейс?Это микроконтроллер или ПЛИС?
Возможно, Ваш руководитель имеет ввиду разработать виртуальный прибор?(virtual instrument)
То есть, это будет модель, имитирующая работу USRP(частотный синтезатор)?

Итак, на счет вопросов:
1. Драйверы для приборов можно писать вручную(на Си например), а можно использовать средства автоматизации типа Jungo WinDriver. Я Вам второй вариант советую. Для PCIe устройства без проблем драйвера генерируются. Взаимодействовать с устройством сможете. Это в случае реального устройства, но без драйверов. То, что написано в статье Вам вряд ли подойдет. Если посмотреть внутрь одного из блоков для какого-нибудь устройства - то Вы заметите вызов функции из dll(картинку прилагаю).
Если же устройства нет - этот пункт пропускаете.
2. Если у Вас "голое" устройство - то одним LabVIEW не обойтись. Необходимо использовать низкоуровневый подход для написания "моста" между компьютером и устройством.
3. http://www.ni.com/white-paper/4803/en/
4. В LabVIEW нет стандартных средств для работы с PCIe.
5. Можно, и разработать такое ПО будет значительно проще, чем отлавливать лузлы при отладке разработанного(самостоятельно написанного) драйвера.
6. Вам следует немного отдохнуть от количества информации. Просто взять и пару дней расслабиться.
Вы ниже пишете, что На данный момент в LV реализована возможность вызова прибора по TCP, его первоначальной инициализации.
Если у Вас есть возможность работать с этим прибором по TCP - то драйверов писать не надо. Надо написать софт для управления, сбора данных и визуализации.

[Mad_Ahab]

Спасибо за ответ!
Вы вчера мне очень помогли "войти" в язык)

Вы правы, у меня "голый" прибор, к нему нет уже готовых драйверов. Устройство использует ПЛИС. И нет, мой руководитель не имеет в виду VI, потому что он не представляет что такое LV, в сущности, его интересует только результат, и, как я написал, я занимаюсь этим один. Руководитель занимается самим прибором непосредственно, и в нем специалист. Да, по сути это некая имитация niUSRP.

Далее по вопросам:

1. " Если посмотреть внутрь одного из блоков для какого-нибудь устройства - " - а как посмотреть? Как вообще посмотреть реализацию того же TCP Open Connect к примеру? Хочется поменьше использовать решений "из коробки" вслепую. То есть, очень хорошо их использовать, но хочется знать что и как внутри. Я пытался скачивать ВП для niUSRP типа niUSRP EX Spectral Monitoring.vi http://forums.ni.com/ni/attachments/ni/ ... itoring.vi, но в данном VI есть subVI, которые не раскрываются, и ничего особенно посмотреть нельзя, кроме логики соединений макроблоков (subVI).

2. Это как я и предполагал - я просто делаю свои dll, которые потом вызываю из LV?

3. Разберусь, спасибо за ссылку.

4. Понял, спасибо.

5. Вот это самое интересное - с чего начать, куда рыть? И чем это ПО отличается от самописного драйвера?
Это важнейший для меня пункт, хотелось бы обойтись именно так, мне кажется, это "малая кровь".

6. Да, я стараюсь с ума не сходить) Просто надо очень)
Насчет TCP - это простейший прототип, потом будут PCIe и что еще принесут. Хочется как-то абстрагироваться от интерфейса, но это решаемо, напишу на С++. В любом случае, я лезу внутрь пакетов TCP, по крайней мере считаю их, может, буду парсить data-часть.

[Vitekkz88]

Mad_Ahab писал(а):Спасибо за ответ!...

Итак, если в устройстве ПЛИС - то PCIe интерфейс реализуется там. Скорее всего используется IP-Core(готовое ядро для PCIe). Может и самостоятельно написано.
1. Я, в качестве примера, открыл блок из палитры инструментов для взаимодействия с прибором(генератор сигналов, в стандартном наборе драйверов нет). Это был просто пример.
Не в каждый блок Вы можете заглянуть. В том числе и в блоки TCP/IP - скажем так, что это черный ящик и как там что реализовали специалисты NI нам не известно. Нам предоставлен готовый инструмент, работоспособность которого была проверена и разработчиками и клиентами продукта. То, что Вы скачали, требует дополнительных установленных драйверов для данного прибора. Как результат - у Вас в палитре Instrument I/O -> InstrDrivers появятся инструменты для работы с этим прибором. У меня эти драйвера не установлены - как следствие диаграмму вижу в виде неизвестных .vi . Это не информативный пример - он Вам не поможет. Готового или почти готово решения не найдёте.
2. Да, Вам потребуется реализовать функции типа: Инициализация(открытие сессии взаимодействия с прибором), конфигурация прибора, чтение/запись данных, закрытие прибора и т.д. Но если PCIe реализован - то можете попробовать использовать WinDriver(если не работали с ним - объясню). Получите драйвера и исходники за 5 минут. Сможете сами их допилить или убрать ненужное. А так же проверить работу приёма и передачи данных. Dll в LabVIEW вызывать несложно.
5.Я имел ввиду, что у Вас уже есть драйверы взаимодействия с прибором. В этом случае реализовать интерфейс, визуализацию и прочие элементы ПО верхнего уровня будет несложно. Гораздо сложнее сделать сопряжение Вашего устройства с компьютером.
По этой причине NI и другие производители различной аппаратуры предлагают драйвера для работы в LabVIEW - это позволяет экономить много времени при разработке. Драйвера есть, а управление и логику, обработку, отображение, сохранение данных можно быстро реализовать в LabVIEW.

И всё-таки на счет TCP: Вы взаимодействуете с прибором по этому интерфейсу?Или это симуляция?Пакеты от кого приходят?От Вашего устройства? Какая скорость передачи данных требуется?

[Mad_Ahab]

В общем, я стал что-то представлять постепенно.

1. По сути, мне предстоит именно реализация указанных драйверов. В конечном результате должны появиться элементы в палитрах LV, их работу обеспечит разрабатываемый драйвер. Их, если будет необходимо, я буду отдавать пользователю устройства.
2. Сам драйвер буду разрабатывать в виде указанных Вами модулей, на С++, в виде dll. Некоторая часть ПО поддержки каких-то (я еще толком не смотрел) протоколов написана задолго до меня, в какие-то давние времена, разрозненными кусками.
5. Ну, попробую сделать это самое сопряжение. Главное - не сделать все для всех видов протоколов и сообщений, а сделать гибко, чтобы можно было дописывать и встраивать реализацию новых протоколов впоследствии.

TCP: пока да, только по TCP, это не симуляция, пакеты идут от устройства, и от хоста в устройство. Ответы, конечно, не "человеческие", просто наборы определенным образом сформированных последовательностей чисел-значений параметров, ну и длинные данные.
Скорость передачи - до 1 Гбита/с, не больше.
Про PCIe пока толком ничего не знаю, сказали, что дадут другое устройство с ним, я спрашиваю заранее, хочу просто сделать расширяемый продукт.

[Vitekkz88]

Mad_Ahab писал(а):...пакеты идут от устройства, и от хоста в устройство.

Если знаете протокол, то можете адекватно передавать и принимать пакеты. Взаимодействие возможно.
1. Да, вы можете встроить свою dll с функциями в палитру приборов. Только напишите её сначала. Учитывая, что делать будете с использованием mutex-ов - готовьтесь основательно, чтоб коллизий не получилось.
2. У Вас есть опыт разработки и написания драйверов?
Допустим есть и со своей задачей Вы справитесь. Я надеюсь, что ребята, которые делают прошивку с PCIe в ПЛИС будут действовать в равной степени профессионально. Иначе вся затея будет большой профанацией и Ваши драйвера будут пылиться в ожидании аппаратуры.
5. Надеюсь, не самостоятельно. Я вижу это так: разработчики прошивки и Вы - минимальный набор. А лучше еще и более опытный инженер-программист Вам в придачу. А как всё заработает - Вам предстоит еще и LabVIEW подключать.
Какие еще микросхемы, кроме ПЛИС, есть в Вашем приборе? И каким образом Вы собираетесь проводить конфигурацию устройства?Какое кол-во регулируемых параметров предполагается?Какое количество настроек будут костантными?
И самое главное: сколько времени отводится на это дело?

[Mad_Ahab]

2. Нет, к сожалению, опыта работы с драйверами нет, но я давно хотел попробовать и рад, что сейчас занимаюсь этим. Прошивка уже сделана, и у меня есть возможность общаться с парнем, который писал ее.
5. Как пойдет, мне помогут по вопросам самого железа, научный руководитель и его старшие ребята. А в приборе еще точно есть DSP. Остальное пока неизвестно, надо говорить с о старшими. Собственно, я потому тут и написал, чтобы понять, какие вопросы и как задавать потом научному руководителю.

Времени на что? На конфигурацию оборудования, или на написание работы?

[Vitekkz88]

Mad_Ahab писал(а):Времени на что? На конфигурацию оборудования, или на написание работы?

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

[Mad_Ahab]

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

Спасибо) Я постараюсь выложиться и получить результат)

Я буду дальше тут писать по ходу работы, посмотрим, что получится - повторюсь, я только разбираюсь с LV.

[Mad_Ahab]

К счастью, самый нижний уровень взаимодействия с прибором уже был когда-то давно реализован, и теперь я смог сделать на основе предоставленных мне функций (по сути тоже из старых DLL) свою DLL(С++, MS Visual Studio 2010 Ultimate), которую я буду предоставлять пользователю прибора для использования в LV.
Попытался подключить "в лоб" DLL через палитру Connectivity, однако в окне Arguments, при настройке возвращаемого значения функции не смог задать указатель на void для самой главной функции (коннекта к прибору). Это вообще можно как-то сделать или нужно перепахивать свою функцию в DLL?
Попробовал сделать подключение через меню Tools»Import»Shared Library, я предоставил .dll и .h - файлы мастеру подключения, однако он ругается следующим образом:

The Import Shared Library tool cannot get exported function names from the input shared library file. Please check the input shared library file whether it contains functions. If you want to create VIs only based on the functions in the input header files, please go back to the Select File Page and check the Shared library file is not on the local machine checkbox.

Разумеется, DLL лежит на этом же компьютере.

В чем проблемы в обоих случаях? Есть стандартные пути решения без переписывания библиотеки? (очень не хотелось бы, я много сил затратил на нее)

[dadreamer]

Это вообще можно как-то сделать или нужно перепахивать свою функцию в DLL?

Задайте тип Numeric и обращайтесь с ним далее, как с обычным числом. LabVIEW не позволяет напрямую работать с памятью и указателями, в отличие от текстовых языков.

[Mad_Ahab]

dadreamer, спасибо, попробую...

[Vitekkz88]

Mad_Ahab писал(а):Попытался подключить "в лоб" DLL через палитру Connectivity, однако в окне Arguments, при настройке возвращаемого значения функции не смог задать указатель на void для самой главной функции (коннекта к прибору). Это вообще можно как-то сделать или нужно перепахивать свою функцию в DLL?

Сделайте скрин функции(объявление с входными параметрами) и прототип Вашего вызова этой функции в LabVIEW.

[Mad_Ahab]

Здравствуйте)
Вот:

Функция с прототипом и аргументами

И весь базовый набор функций, который я для начала хотел бы использовать в LV:

Объявление всех функций

Видимо, придется переписать часть функций, если LV не работает с памятью напрямую - мне последнее в голову как-то не пришло. Но все равно, надо как-то обращаться к прибору, и в программе на С++ будет фигурировать void* - указатель на устройство, и он повсюду передается как параметр.

[dadreamer]

Mad_Ahab, если в LabVIEW не планируется работать с памятью, а только "гонять" между указатель, можно оставить его в виде числа (хэндла), и во все функции передавать так же как число. Многие разработчики так делают, когда подключают DLL в , видел уже много раз. В принципе, в самом есть кое какие функции, которые могут быть использованы в работе с указателями, хотя и с ограничениями. Посмотрите здесь или во встроенной справке . Лучше сперва внимательно прочитать описания и разобраться в том, как LabVIEW хранит данные.
Вижу у вас там std::string, замените на char * или массив, C-классы в не поддерживаются.