Khameleon tutorial

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

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


Подсунуть конфиг можно разными способами:
1. Через параметр -c (./idpws -c <имя_файла>.cfg). 
2. Сделать симлинк <имя_файла>; на idpws и запускать с симлинка.
3. Запускать idpws без параметров, при этом в качестве .cfg.user будет использоваться khameleon.cfg, а в качестве системного - имя, указанное параметром cfgfile (не рекомендуется).


Теперь, собственно, про конфиги самого tutotial-а. Рассмотрим их в порядке возрастания сложности:


1.  echoterm.cfg
В файле записана конфигурация для соединения друг с другом двух модулей через конвеерный (stream) интерфейс. Рассмотрим значение каждой строчки.  


Раздел [connections] содержит описание соединений между модулями. Формат записи:

<номер_cоединения>="id_<модуль_от>;signal_<имя_сигнала>;id_<модуль_куда>;slot_<имя_слота>" 

Здесь мы фактически средствами Qt соединяем сигнал одного модуля со слотом другого. Предусмотрено по одному сигналу и одному слоту на модель типа stream: через "ImReady(QVariantList)" модуль передаёт обработанные данные дальше по цепочке, а через "StartProcessing(QVariantList)" принимает данные от другого модуля. Есть ещё дополнительный сигнал "myStatus(QString)", через который может передать какие-либо сообщения в главное окно программы, где для этого предусмотрен объект logger со слотом  append(QString), или timedAppend(QString), если требуется отобразить время прихода сообщения.
 
Далее раздел [widgets]. Здесь мы пишем какие виджеты из каких модулей следует выносить на главное окно. Формат следующий:

id_<модуль>\<параметр>=<значение>

 Параметры бывают следующими: wmain, woptions, где значение, это имя заголовка окна или заголовка блока, содержащего данный виджет; wmainobjname  должно быть уникальным для каждого модуля и используется при сохранении параметров окна; woptionsdialog (true или false) - следует ли отображать виджет опций в меню опций программы; ismainlayout (true) - применяется только к одному виджету wmain, и говорит о том, что он является главным, остальные - перемещаемые.



Идём далее, раздел [modules]. Именно в этом разделе мы указываем, какие именно модули необходимо загрузить, а также присваиваем им id. Параметр id должен начинаться с нуля, быть уникальным для каждого модуля, и возрастать без пропусков (т.е. после 3 не может следовать 5). Формат записи как и в предыдущей секции:

id_<модуль>\<параметр>=<значение>

 Отличие в том, что се параметры в данной секции начинаются с точки, что говорит о том, что они являются скрытыми параметрами модуля.  ".name" - имя загружаемого модуля, ".thread" - номер потока, в который необходимо поместить данный модуль. Кроме этих параметров каждый модуль может содержать любое число индивидуальных скрытых параметров. От обычных параметров их отличает то, что они задаются в файле конфигурации и не могут изменятся во время работы программы.  Они предназначены для того, чтобы задавать конкретный вариант поведения модуля в конкретной конфигурации.


Уф, с этим файлом разобрались. Дальше будет проще и интереснее одновременно.


2.  echotermfb.cfg
Пример соединения модуля, использующего потоковый (конвейерный) интерфейс, и модуля, работающего через пропагаторы. Здесь в пояснении нуждается секция [connections], а именно, 2-ое и 3-е соединения. Остальные секции повторяют прошлую конфигурацию.  

02="id_0;out;id_1;slot_StartProcessing(QVariantList)"
03="id_1;signal_ImReady(QVariantList);id_0;in"

Во втором соединении вместо указания сигнала для первого модуля используется имя пропагатора, out. Важно, что в конструкторе модуля в лист "hpg" должен быть довавлен элемент, с именем "out" и значением NULL (создание объекта пропагатора происходит в ядре во время соединения модулей). Также важно заметить, что для связки таких разнородных модулей можно использовать только пропагаторы без обратной связи, сигнал пропагатора "trySendList(QVariantList)", чтобы ловить пришедшие данные, и функцию "sendList(QVariantList)", чтобы отправить данные.


3.  echofbterm.cfg
Это также пример соединения разнородных модулей. Разность в конфиге с предыдущим примером минимальна, но заинтересовавшиеся могут найти немного нового в исходных кодах модулей.


4.  echofbtermfb.cfg
И наконец, пример взаимодействия двух модулей через пропагаторы. Здесь в секции [connections] последние две строчки заменены одной, но в конце появилась подпись "feedback":

02="id_0;interface;id_1;io;feedback"

Что здесь написано: пропагатор модуля id_0 соединить с пропагатором модуля с id_1, при этом первый пропагатор должен дождаться ответа от второго, и только после этого вернуть управления модулю с id_0. В конструкторе модуля такой пропагатор мы уже должны поместить в лист "hpgfb", и вместо функций "send(QByteArray)" и "sendList(QVariantList)" следует использовать read, write, readList и writeList, в зависимости от передаваемых данных. Единственное требование, оба модуля должны быть согласованы по типу данных. Т.е., фактически мы получаем возможность читать и записывать данные в модуль, и неважно, что он работает в другом потоке и живёт своей жизнью. Если заглянуть в код "ведомого" модуля (из которого читают), то там можно найти вызов функции readReturn writeReturn, readListReturn или writeListReturn. Если это обработка ведомого пропагатора, то необходимо вызывать одну из этих функций перед возвратом из обработчика. Какую именно - зависит от выполняемой операции и от типа данных. Данные, положенные в эти функции "вернуться" модулю, вызывающему соответствующие ответные функции из своего пропагатора.


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

Khameleon is opened

Наконец-то случилось то, о чём было уже столько разговоров! Исходники khameleon теперь доступны на sourceforge.  Теперь можно качать и пробовать, брать за основу уже написанные модули и писать свои, пробовать адаптировать её к новым девайсам. С чего начать? После сборки проекта скопируйте файлы из bin/configs/echo в bin и укажите имя конфига программе при запуске (./idpws -c echoterm.cfg). Здесь записана простейшая конфигурация системы - эхо и терминал завязаны друг на друга. Текст из поля уходит в эхо, а оттуда возвращается в терминал. Для демонстрации оба модуля грузятся в различные потоки. Они связаны простейшим интерфейсом (Stream), аналогичным первоначальной конвейерной концепции. Однако сейчас это не единственная возможность, но об этом в другой заметке, где я подробнее опишу на примерах различные варианты взаимодействия модулей друг с другом.

Khameleon Modular System - возрождение

Давненько я ничего не писал про столь важный проект, как модульная система хамелеон. Ровно год, одна неделя и один день, если быть точным. А дело, тем временем, совсем не стояло на месте. Об этих переменах я сегодня и расскажу.

Не буду повторять проблемы, о которых я писал в предыдущем посте, а перейду сразу к решениям.
1. Взамен концепции конвейера пришла концепция взаимодействия модулей через т.н. пропагаторы. Термин пришел из ядерной физики, где он означает "переносчик взаимодействия", или, буквально, от английского "propagate" - распространение. Возможно термин притянут за уши, но лучшего определения той сущности, которую я хотел создать, не нашлось. Это не труба (pipe), из которой к вам сыпется некое нечто, и в которое вы ссыпаете всё скопом. Это не очередь запросов (queue) и не сигнал, в терминологии Qt. Основная идея пропагатора состоит в том, чтобы обеспечить максимально-абстрактный интерфейс взаимодействия модулей друг с другом. Пропагаторы разделены на два подкласса, feedback и stream, т.е. те, что ожидают ответа от модуля и возвращают его (подобно фукциям read/write в блокирующем режиме), и те, посредством которых можно организовать "массовую рассылку" или поток (подобно функциям send/received). Внутри модуля создаётся список пропагаторов, через которые происходит взаимодействие, а ядро при загрузке создаёт сами объекты, и связывает их с другими модулями. Т.о. каждый пропагатор может являться точкой входа в модуль. В примеру, модуль построения графиков multiplot имеет пропагаторы plotxy и collectxy. Первый отвечает за рисование графика целиком, второй - за накопление и отрисовку потока данных. Взаимодействие с пропагатором внутри модуля выглядит как обычный вызов функции.

2. Многопоточность. Так получилось, что реализация многопоточности оказалась тесно связанной с реализацией идеи о пропагаторах. Просто по тому, что сейчас feedback пропагатор реализован таким образом, что связывать им можно только модули, находящиеся в разных потоках, иначе будет deadlock.
Как это работает? При загрузке модуль может попросить (через параметр в конфиге) для своей работы отдельный поток. Ядро стартует новый тред со своим eventloop-ом, и помещает туда модуль, вызывая для него moveToThread(). Поскольку работа пропагаторов крутиться вокруг qt-ной концепции сигнал-слотов, то все вызовы между модулями из разных потоков полностью безопасны.

Казалось бы, зачем так всё усложнять, если требуется "просто" связать два модуля и сделать между ними практически синхронный обмен данными? На этот вопрос я подробно напишу в отдельной заметке. Несомненно, задачу можно было бы решить и в рамках одного потока, и без надуманных пропагаторов, и, возможно, более красиво. Однако, в свой подход я закладываю некоторые плюшки, реализация которых другими способами (имхо) будет уже совсем не тривиальной. Ну например, раздать нескольким модулям задания по обработке, запустить при этом чтение их третьего, после дождаться завершения обработки от первых, и выполнить какие либо действия по результатам их работы. и всё это в виде линейного кода.

На данный момент могу сказать, что с введением многопоточности и концепции пропагаторов жить стало заметно легче, и уже в ближайшее время я выложу кратенький обзор нескольких практически применимых творений. Это будет простая оболочка для снятия данных с измерителя мощности ThorLabs, и ModBus Debugger - приложение для отладки устройств по протоколу modbus (постоянный мониторинг регистров, флагов, запись в регистры).

ftd2xx library on wine

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

И так, исходные данные, автокоррелятор от Avesta project, подключающийся к ПК по USB, и программа Irtac для работы с прибором. В приборе USB аппаратно реализовано на микросхеме ftdi, что можно увидеть по логам при подключении устройства (dmesg или /var/log/messages). Программа Irtac собрана под windows с использованием коммерческой (закрытой) версии библиотеки ftd2xx. Реализации под linux нет и ждать не приходится, а перегружаться в винду ради одного прибора очень не хочется, тем более, что реально он часто нужен не один. Есть вариант с использованием виртуальной машины. Неопенсорсный virtualbox умеет прокидывать USB в систему, и, например, поляриметр от thorlabs так заставить работать удалось. Ситуацию осложняет то, что такой трюк оборачивается существенными тормозами в работе виртуалки, и Irtac тупо отваливался по таймауту. Под wine сама программа хоть и запускается, но работать с прибором не хочет. Оно и понятно, если я ей подсуну windows-версию библиотеки, то она понятия не имеет как работать с USB  в linux, а linux-версию программа, собранная под винду, по ясным причинам подцепить не сможет. И так, выход один, надо разобраться, как wine реализует свои библиотеки, и написать обёртку (fake) для linux-версии libftd2xx.

Немного рутины - необходимо достать исходники установленного у вас wine, распаковать их, потом наложить прилагаемый патчик, запустить configure и make, а после скопировать ftd2xx.dll.so и ftd2xx.dll.fake в /usr/lib/wine/ftd2xx.dll.so и /usr/lib/wine/fakedlls/ftd2xx.dll (или куда там установлен штатный wine) соответственно. Как получился этот патч? Сначала всё казалось проще пареной репы: у нас есть две библиотеки с идентичными функциями, значит, нам даже толком не надо ничего писать, а просто "связать" вызов функции из программы с той же функцией в нативной библиотеке. Сказано - сделано. Но было бы наивно предполагать, что Irtac сходу заработает, тем более что мы не знаем функции, которые он использует. Для тестирования я взял примеры из libftd2xx1.0.2 и собрал их как под linux, так и под винду (через mingw). Тут количество используемых функций и порядок их вывода строго определён, и можно отследить на каком месте что у нас порушилось. На первом этапе я никак не мог понять, как сделать этот самый вызов функций с одним и тем же названием и метался от простой сборки wine-библиотеки статиком с libftd2xx.a до написания обёртки с другим именем, из которой бы цеплялась нативная библиотека, а сама обёртка использовалась бы нашей fake-либой, и тем самым, мы избежали бы конфликта имён. Однако, найти правильный путь помогла wine-библиотека glu32. Здесь реализовано фактически именно то, что нам необходимо. А вся изюминка кроется в том, что заголовки функций для windows- и для linux-версии ftd2xx немного различаются. Это обстоятельство учтено в ftd2xx.h, и правильные заголовки определяются при сборке define-ами. Нам же необходимо подставить define-ы, которые использовались бы при сборке под виндой (чтобы прога могла найти функции), хотя фактически, собираем мы всё это дело под пингвином. Однако, после этого прозрения вылезла ещё одна проблема, и заключается она вот в чём. Функции, которые мы хотим отдать wine-у на экспорт, перечисляются в ftd2xx.spec, где первый параметр - некий номер функции... Я не понимаю, что это за номер, но на практике, этот номер как-то связан с тем, где именно находится данная конкретная функция. И если мы правильно пишем обёртку, но вместо номера ставим "@", что в соответствии с http://linux.die.net/man/1/winebuild означает автоматическое присвоение номера, то не факт, что этот номер совпадёт с реальным. И при попутке запустить программу получим что-то типа:

wine: Call from 0x7ef918f0 to unimplemented function FTD2XX.dll.32, aborting

wine: Unimplemented function FTD2XX.dll.32 called at address 0x7ef918f0 (thread 0009), starting debugger...

Но это и ключ к разгадке! Если мы знаем, какую именно функцию дергает приложение, а это можно установить по исходникам, то данный вывод означает, что эта функция должна находится по номеру 32, но её там почему-то нет. Ставим этот номер вместо собаки в ftd2xx.spec, и двигаемся дальше...

В результате, я написал обёртки для всех функций из ftd2xx.h кроме тех, где есть префикс W32 (просто я не знаю как уложить их параметры в концепцию wine). Получилось 49 штук. Из них я подобрал номера к 16-ти. Для этой процедуры я использовал примеры  BitMode, EEPROM/read, LargeRead, Simple и Timeouts. Вывод данных программ был идентичен про запуске в linux, и при запуске под wine-ом. В качестве "прибора" использовалась заглушка в виде микросхемы FT232RL с замкнутыми Rx/Tx и питанием от USB-порта. В ближайшее время буду пробовать на реальном железе.

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

Патчик можно найти тут.

upd: Оказывается, кое-что всё-таки "уже украдено до нас". Так, вот тут автор ещё в 2005 году сделал вызов основных функций через libusb. Кроме того, он приводит spec, в котором уже указаны адреса для всех функций.. Что-то мне подсказывает, что их узнать можно гораздо проще, чем я описал выше...

upd2: Поразительно, но мне действительно удалось заставить эту прогу корректно работать с прибором! Однако, обнаружилось пара нюансов:
1. Значения Timeout-ов и LatencyTimer пришлось увеличить в 10 раз возможно, хватило бы и пары, но взял с запасом, и оно попёрло)
2. Если функция FT_ListDevices используется с флагом FT_LIST_BY_INDEX, то перед вызовом нативной функции стоит вызвать FT_CreateDeviceInfoList, т.к. без этого всё или виснет или crash-ится.
Обновлённый патчик со всеми этими изменениями, а также с некоторым количеством отладочной информации для wine-1.2_rc7 можно найти тут.