вторник, 14 октября 2008 г.

Khameleon Modular System: О взаимодействии модулей со средой

И так, имеется заранее определённый интерфейс взаимодействия модулей, реализованный через qplugin. Как выглядит загрузка модуля через QPluginLoader — вначале необходимо получить список файлов модулей, которые хотим загрузить, затем создаём pluginloader и скармливаем ему в цикле эти файлы. Далее pluginloader.instance() возвращает нам указатель на QObject. И теперь осталось лишь получить объект с описанным нами интерфейсом с помощью qobject_cast(plugin). Однако тут есть тонкое место, интерфейсов у нас несколько, и различаться они могут как по типам, так и по версиям.
Оказывается в Qt есть механизм QMetaObject, с помощью которого сам Qt получает инфу о сигналах, слотах и ещё кое-каких параметрах объекта. Но самое вкусное для нас лежит рядом, в QMetaProperty. С помощью макроса Q_PROPERTY можно добавить к объекту свои «свойства», доступ к которым будет открыт на стадии, когда модуль представляет из себя лишь абстрактный QObject. И именно в этот момент можно будет узнать что у нас за модуль в руках, и какой именно интерфейс для него следует использовать. Т.о. фактически интерфейс разбивается на две части: некий мета-интерфейс, т.е. По сути список properties который фиксирован раз и навсегда, и рабочие методы объекта модуля. Интересно, а работать это будет...
P.S. представленная информация, по сути, вольный перевод разных частей Qt Assistant, для уточнения деталей следует обращаться непосредственно к первоисточнику.

Khameleon Modular System: О взаимодействии модулей

Модули взаимодействуют посредством сигналов и контейнеров QVariant для обмена данными.
Скажем, есть модуль получения данных с какого-либо девайса. Как только получена порция данных, модуль пускает сигнал, который связан со слотами модулей, которым эти данные необходимы. «Среда» отвечает за правильное связывание сигналов со слотами. Передача данных от модуля к модулю происходит посредством структур, обёрнутых в QVariant. Формат структуры заранее не определён, но описан в документации к модулю.
После того как отработали модули работы с данными каждый также пускает сигнал и результат их работы передаётся следующим и т.д.
У каждого модуля есть некоторые внутренние параметры, определяющие его работу. Необходимо предусмотреть чтение этих параметров, а так же их изменение другими модулями в процессе работы. Скорее всего это будет нечто вроде QStringList, где последнее слово в строке определяет значение параметра. Должны быть реализованы функции чтения всего списка параметров, чтение значения отдельного параметра (по строке с названием параметра), а также установка значения параметра.
Модуль представляет собой отдельный класс-библиотеку-виджет со стандартизованным интерфейсом. Возможно указание версии интерфейса, что может потребоваться для дальнейших улучшений. Рабочий код модуля исполняется в отдельном потоке (thread). Каждый модуль внутри себя содержит список пунктов меню (QMenu) для добавления в главное окно приложения, QToolBars and etc.

Khameleon Modular System: О главном окне приложения

Главное окно изначально содержит только строку состояния и общую строку меню, содержание которой заполняется самими модулями. Центральным виджетом окна является либо TabWidget или MDI. Список всех доступных модулей должен быть вынесен в отдельное меню, либо диалоговое окно, откуда происходит добавление/удаления модулей на рабочую область. Возможно потребуется создание менеджера модулей, для добавления, удаления модулей и установления связей между ними. Визуальное оформление модулей представлено в виде Widget-ов, которыми заполняются dockWidgets расположение которых задаётся пользователем. Модули могут иметь свои popupMenu и/или свои диалоговые окна.
При запуске программы список модулей читается из конфигурационного файла, который формируется после работы менеджера модулей. На основе этого списка происходит динамическое формирование рабочего окружения.

Khameleon Modular System

Khameleon Modular System
Модульная Система для обработки данных с экспериментальных приборов, управления приборами.
И так, начинаем цикл заметок-соображений о subj-е. Что это вообще такое, и что из себя представляет... это нечто для обработки всего :)
На самом деле всё больше появляется экспериментальных приборов, очень тесно связанных с ПК и требующих порой весьма нетривиальной обработки первичных данных. При таком подходе львиная доля в реализации функционала устройства ложиться на ПО, что и хорошо и плохо одновременно... Почему хорошо, понятно - проще аппаратная часть, дешевле. Плохо же оттого, что софт можно написать и на скорую руку, и через жопу, и чтобы он при этом как-то работал, а количество потраченных нервных клеток конечного пользователя никого не интересует. Даже написаны специальные системы а-ля LabView, которые стоят кучу бабок и содержат в себе всего на все случаи жизни... Но от вида программ, написаных такими монстрами, от скорости их работы, костлявости и кривоты порой "слегка" подташнивает.
Т.о. данный проект в своём зачатке нацелен на "построение коммунизма", хоть и в пределах "своей квартиры", а дальше видно будет.

пятница, 3 октября 2008 г.

о природе мышления

Я мыслю, следовательно... хотя до следовательно ещё рано. Что вообще такое "я мыслю". Очевидно, мысление есть некий процесс, происходящий в наших головах.. хотя это всё-таки у кого как, но не суть. А вот в чём суть самого этого процесса? Что он из себя представляет, ну или хотя бы может представлять чисто гипотетически?
Обратимся к эволюции, ибо именно ей мы всем обязаны (что тоже спорно, но не будем останавливаться на таких мелочах). Итак, в ходе эволюции, или другими словами, естественного отбора, постоянно происходит соревнование между видами "кто лучше адаптируется" к текущим условиям окружающей среды. Это жестокие состязания, т.к. проигравшие навсегда уходят в небытие. И что мы имеем на сегодняшний день в результате этой долгой борьбы? А сегодня мы имеем вид, наделённый максимальным адаптационным потенциалом за всю историю планеты, т.е. человечество. При этом надо отметить, что физические данные человека весьма заурядны, весь этот огромный потенциал сконцентрирован лишь в его мозге. Так, запомнили, теперь возвращаемся к теме разговора.
Роль мозга определили. С другой стороны более/менее известно, что мозг представляет собой сеть нейронных клеток, которые сами по себе относительно просты, но являясь элементами сети способны выполнять задачи гигантской сложности.
Каждая сеть, кроме своих элементов характеризуется также связями этих элементов друг с другом. Связи эти, скорее всего, случайны и статистичны, и во всяком случае не определены раз и навсегда. Информация в сеть поступает от нервных окончаний, зрительных, слуховых и пр., которые уже тяготеют к определённым частям мозга, как некой субстанции. Таким образом, в самой сети как целом происходит формирование центров (зрительного, речевого), в которых "данные проходят предварительную обработку". И когда мы видим какой-то предмет, то данные о нём поступают в сеть, и формируют в ней связи между отдельными нейронами. Когда мы видим другой предмет, то он порождает другие связи, и очень важно, что все они существуют "внутри одного объёма", т.е. активно переплетаются друг с другом (если предметы похожи), вытесняют друг друга (когда мы забываем что-либо), отпечатываются тем сильнее, чем сильнее ощущения и чем из больших источников они получены (для лучшего освоения материала надо почитать, пощупать, попробовать сделать самому).
И теперь самое важное, к чему я веду всё это время. Итак, есть два предмета, и каждый порождает свои связи, пусть изначально совершенно различные, пусть даже в различных физических областях мозга. Но потом мы понимаем, что предметы-то похожи, что у них есть общие черты, и что они вообще есть проявления одной сущности! В этот момент образовавшиеся связи уже настолько переплетены друг с другом, что мы просто не в состоянии мыслить о каждом из этих предметов по отдельности!!!
Но что произошло между этими двумя крайними точками?! А между этими точками мы размышляли, используя какие-то дополнительные данные, опыты или просто более внимательно разглядывая и сопоставляя, т.е. мы мыслили! И что же произошло в результате? А в результате связи между нейронами "адаптировались" так, что представляют собой уже нечто целое и абсолютно неразрывное!!
Таким образом, процесс мышления в сущности есть процесс адаптации мозга, процесс адаптации связей между нейронами и приведение их к такому виду, чтобы все полученные данные укладывались в голове! Можно называть это смекалкой, аналитикой или ещё чем, но очевидно одно - тот человек побеждает, который способен выявить правильные взаимосвязи, построить правильную картину мира (слово "правильный" стоит воспринимать в относительном смысле). А в сущности, всё это лишь адаптация, и потенциал её не просто огромен... он ужасно огромен!!!
P.S. по мотивам рассказа Станислава Лема "Сумма технологий".
Выражаю искреннюю благодарность Алёне Ч. за сопоставление вышеизложенного с правилами русского языка.

о методологии науки

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

*см А.Л. Симанов, "Методологические принципы физики"
P.S. ну вот, пока писал, была какая-то большая мысль, а как написал, так и всё как-то просто получается и вроде всем должно быть известно... Ну раз уж написал, то публикую.

четверг, 17 апреля 2008 г.

Transparent proxy в домашних условиях или как я просветлял Squid

И так, захотелось подключить бук к сети через стационарную машинку. При этом выход в сеть со стационара осуществляется через прокси, а сама локалка есть объединение нескольких сетей, запросы к которым идут напрямую. Настраивать прокси на буке не охота, т.к. работать он будет не только в этой сети, а перенастраивать всё это дело каждый раз лениво. Пусть сеть, к которой подключен стационар есть сеть А, а сеть между стационаром и буком есть сеть В.
Т.о. для решения проблемы надо сделать две вещи:
  1. настроить маскарадинг для сети между буком и стационаром
  2. перенаправлять все пакеты, не принадлежащие ни одной из сетей на локальный сквид, настроенный на внешний прокси.
1. Маскарадинг
...делается легко, тем более что в моём любимом AltLinux есть фронтенд для создания правил iptables. Т.о. делаем маскарад для всех tcp,udp,icmp пакетов из сети В, если адресат не принадлежит этой сети:
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE tcp -- 192.168.0.0/24 !192.168.0.0/24
MASQUERADE udp -- 192.168.0.0/24 !192.168.0.0/24
MASQUERADE icmp -- 192.168.0.0/24 !192.168.0.0/24
После этого необходимо убедиться, что у нас в ядре разрешено перенаправление пакетов:

#cat /proc/sys/net/ipv4/ip_forward

Если внутри единичка, то всё ок, иначе ищем файл, откуда этот параметр управляется, в моём случае это /etc/net/sysctl.conf строчка net.ipv4.ip_forward = 1 (на выяснение этого обстоятельства у меня ушло несколько часов). Можно, конечно, сделать #echo 1 > /proc/sys/net/ipv4/ip_forward, но это слетит после перезагрузки. Можно засунуть эту команду в какой-нить из загрузочных скриптов, но это костыль.
И так, с маскарадингом разобрались. Бук успешно заходит на ftp, smb локалки.

2. Просветление Squid
С настройкам сквида я немного схалтурил. Взял пример настройки, что уже был с ним и работал для localhost. Разрешил запросы из сети В, указал parent-proxy, сказал перенаправлять ssl-пакеты сразу на parent:
#/etc/squid/squid.conf
acl SSL method CONNECT
never_direct allow SSL //заворачиваем ssl-конекты через parent
acl our_networks src "/etc/squid/our_networks" //в our_networks список сетей, которым разрешено пользоваться прокси
http_access allow our_networks
http_port 3128 transparent //говорим, что работать надо в прозрачном режиме.
cache_peer my.proxy.ru parent 8080 0 default
#hierarchy_stoplist ... //снимаем какие-либо ограничения на загрузку контента
Так, с настройками сквида разобрались. Теперь осталось настроить прозрачность. Один из методов, использовать iptables для перенаправления пакетов, предназначенных наружу, на 3128 порт нашего прокси.
Самое простое - перенаправлять все пакеты, выходящие за рамки нашей сети, на прокси. Проблема в том, что наша сеть объединяет несколько диапазонов. Я сделал вот как:
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 0 -- anywhere 10.0.0.0/8
ACCEPT 0 -- anywhere 192.168.0.0/16
ACCEPT 0 -- anywhere 172.16.0.0/19
ACCEPT 0 -- anywhere 127.0.0.0/8
REDIRECT tcp -- anywhere anywhere redir ports 3128
REDIRECT udp -- anywhere anywhere redir ports 3128
Т.е. если пакет принадлежит хоть одной сети, то для него выполняется ACCEPT и он вылетает из цепочки. Если же он не принадлежит ни одной из перечисленных сетей, то он докатывается до правила REDIRECT, и там уже прокси решает что с ним делать.
И так, прозрачность для локальной машинки настроили (коли мы уж заморочились с прокси, то почему бы не поиметь его преимущества и локально?). Но тут кроется один очень серьёзный подвох. ssl не работает через прозрачный прокси, никак, никогда. Дело в том, что по-сути iptables выполняют роль посредника между клиентом и прокси, что недопустимо для ssl, который направлен против этих самых посредников. Т.о. ни тебе jabber по ssl, ни почты.. для всего этого надо настраивать прокси явно. Сам же я ограничился лишь указанием ssl-proxy в браузере, как неким компромисным решением, т.к. на сквиде лежит кеширование и в перспективе - вырезка рекламы.
Теперь, для того чтобы прозрачность работала и для сети В, добавляем цепочку правил подобную OUTPUT в PREROUTING, указав eth2 (куда подключен бук), в качестве исходного интерфайса. Выглядит всё это немного необтёсано, может со временем созреет что-нить покрасивее :).

вторник, 25 марта 2008 г.

Python как инструмент обработки экспериментальных данных

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

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

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

И так, мне понадобиться: работа с болшьими массивами чисел, численное интегрирование, интерполяция, численное нахождение корней уравнения F(x)=0 где F - нелинейная функция, аппроксимация по методу наименьших квадратов произвольной функцией.

Выбираем средства: 1.Origin - хорош при обработке малого числа графиков, но в данном случае терпит полный крах, т.к. мне проще будет повеситься, чем работать в нём с таким количеством данных, а это ведь только начало. 2.MathCad - курит в сторонке, т.к. с его интерфейсом я без матов работать не могу - порой кучу усилий надо приложить, чтобы только скобаку поставить в нужном месте, к тому же нет версии под lin. 3.MATLAB - отличный инструмент, но его функционал явно избыточен. 4.SciLab - замечательная штука, в которой есть всё то, что мне необходимо, и которую я уже было подорвался использовать для всех нужд, однако столкнулся с проблемой: скриптами можно организовать пакетную обработку данных (нормировку, аппроксимацию и пр.), но когда появляется необходимость максимально быстро сконструировать график зависимости одной величины, определяемой из пакетной обработки, от другой, приходиться поломать голову. По сути, это язык программирования высокого уровня, но это функциональный язык, в то время как объектно-ориентированный подход мог бы дать большую гибкость. 5. Python - ооп язык программирования высокого уровня в котором я и нашел спасение:

Python как инструмент обработки экспериментальных данных

И так, нам потребуются модули numpy, matplotlib, scipy. Эти модули предоставляют замечательный функционал, включающий всё, что мне может понадобиться на данном этапе.

Вся изюминка кроется в реализации обработки эксперимента: создаем класс "spectr" который будет служить обёрткой для экспериментально-измеренного спектра. Добавляем в качестве методов всё, что мы можем с этим спектром сделать: умножение на другой спектр, центральная блина волны, пиковая мощность, ширина на полувысоте, нормировка по мощности, умножение на константу, обрезание шума, сохранение в файл, открытие из файла. Это краткий список того, что мне понадобилось в первую очередь, что важно, список этот легко может быть расширен в дальнейшем. Далее, создаём класс, описывающий нашу теоретическую модель, который включает в себя все формулы, все параметры, методы аппроксимации, методы расчёта теоретических параметров. Теперь создавая несколько экземпляров класса с разными параметрами легко можно сравнить влияние этих самых параметров на предсказания модели, которые в свою очередь легко сравнить с реальными данными.

Основной скрипт обработки читает экспериментальные спектры, создавая из них массив объектов класса "spectr" в цикле извлекает параметры полуширины, мощности как на выходе, так и внутри резонатора, проводит аппроксимацию и поиск подгоночного параметра для каждого участка спектра. Теперь, имея в руках все эти данные одновременно, можно легко с ними оперировать, концентрируясь на физике дела, которая сейчас, не обременённая техническими деталями обработки, становиться весьма интересной.

среда, 12 марта 2008 г.

python-qt-qwt

И так, захотелось мне писать проги с "окошками" за минимальное время и с максимальной быстротой (т.к. возможно вскоре это будет производственной необходимостью). Кроме того, поскольку контора сейчас сидит под виндами, а в дальнейшем стоит планировать хотя бы частичное внедрение пингвина, то уже сейчас стоит закладываться на кросплатформенность, которая присуща всем 3-м инструментам.

Почему питон? - потому, что легкий синтаксис, потому что много модулей, потому что кросплатформенный и в конце концов, потому что имхо модно.

Почему Qt? - потому что обывателя интересуют окошки, потому что мне понравились методы использования сигналов/слотов, потому что всё грамотно объектно-ориентировано.

При чём тут qwt? - qwt, как известно, библиотека для qt, которая предоставляет различные элементы оформления, востребованные в научной среде (plot с автомасштабированием, различные крутилки, ползунки и пр), так что прикрутить это к нашим окошкам было бы очень недурно.

Отдельной строкой стоит отметить, что интерфейс на Qt может быть легко "нарисован" в дизайнере, а получившейся .ui-файл транслирован на питон, т.о. руками остаётся лишь написать обработчики для элементов окна, и должна получиться вполне рабочая прога.

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

...продолжение следует.

среда, 20 февраля 2008 г.

Спецификация USB, заметки по сути.

USB - универсальная последовательная шина, позволяющая подключать до 127 устройств самого различного плана и имеющая пропускную способность до 480Мбит/сек (USB 2.0), бла-бла и бла-бла... Это все знают, это можно легко прочитать на той же вики и интересно это может быть лишь для общего развития. ИМХО куда интересней собрать какую-нить свою поделку взаимодействущую с ПК через эту шину.

Задача:

Организовать soft-usb на МК AVR серии ATmega.

Но перво-наперво надо понять как в принципе работает эта шина.

Пойдем путём настоящих джедаев и скачаем с www.usb.org полную версию спецификации 2.0...

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

  1. Все транзакции определяются хостом: устройство должно принять данные по запросу хоста, устройство может передать данные только после того как хост спросит, нет ли данных на отправку и пр.
  2. Каждое устройство при подключении проходит стадию конфигурирования: получает от хоста уникальный адрес, передаёт информацию о типе, о производителе (об этом чуть позже).
  3. Хост идентифицирует каждое устройство по его адресу на шине, поле адреса занимает 7 байт, отсюда максимальное число устройств на шине - 127 (нулевой используется при конфигурации и не может быть назначен в качестве рабочего)
  4. Данные по шине передаются пакетами, каждый пакет начинается с поля синхронизации, затем идёт поле PID, определяющее тип пакета, дальнейший формат определяется типом пакета. Особо стоит обратить внимание на типы Token, DATA, Handshake. (В спецификации описание взаимодействия конечного устройства с ПК переплетается с описанием взаимодействия ПК с USB-хабом, функционал хаба мы не предусматриваем и не рассматриваем всё что его касается)
  5. Для контроля правильности передачи в каждом пакете предусмотрено поле CRC.
  6. Для кодирования данных в линии используется формат NRZI в котором постоянство логического уровня в линии соответствует единице, а изменение - нулю.
  7. Процесс передачи/получения данных выглядит следующим образом: хост посылает token с адресом устройства и указанием чего хочет - либо передать данные, либо принять их. В первом случае после token-а следует пакет с данными, после которого устройство должно ответить ASK в случае успеха или NAK в случае невозможности принять данные, ошибок CRC и пр. Во втором случае устройство само передаёт пакет данных и ожидает ASK от хоста, а с случае неудачи повторяет попытку.
  8. Процесс конфигурирования. ИМХО самая сложная стадия... Есть token-пакет типа SETUP. После него устройство должно ожидать пакета DATA0 в котором в поле данных особым образом сформирован запрос хоста (request), стандартные запросы описаны в секции Standart Device Request спецификации. Наше устройство должно уметь распознавать все типы запросов. Кроме прочего в запросе есть информация о том, куда должен быть направлен следующий пакет данных - в хост или в устройство.
  9. Более того, устройство должно уметь формировать ответ на запросы - должно сообщить хосту о своих свойствах через так называемые дескрипторы (Standart USB Descriptor). Полное их описание также довольно хорошо представлено в спецификации. Более того, именно этим разделам стоит уделить особое внимание. Отмечу лишь что через дескрипторы устройство сообщает свои Class, SubClass, Protocol, которые уже активно используются на уровне ОС и драйверов.

P.S. в дальнейшем тема обязательно будет продолжена, но уже с точки зрения железа и подготовки прошивки для МК.

понедельник, 18 февраля 2008 г.

Optical Spectrum Analyzer: сливаем данные

преамбула:

Приятно смотреть когда растёт материальная база научны лабораторий, появляются новые, современне приборы и пр, но как мы с ними работаем? Как правило для того чтобы хоть как-то проводить измерения зачастую можно даже не читать инструкции, и в единичных случаях это оправдано, ибо зачем читать толстую книжку, да ещё на английском, чтобы провести одно измерение... Другое дело, когда приходиться промерять некоторые зависимости, хотелось бы свести к минимуму рутинную и однообразную работу, тем более что приборы, о которых идёт речь, обладают множеством функций, скрытых от глаз обывателя.

удалённое управление:

Первый этап, сохранение графиков, с анализатора спектра на флеш. Прибор может быть подключён к компу посредством Ethernet, rs-232, GP-IB, остановимся на первом варианте (последний - пока экзотика, а ком-порта у меня на ноуте нет). К анализатору предлагается хороший мануал с описанием команд, которые можно посылать прибору через любой из этих интерфейсов. Таким образом задача сводиться к отправке команд в прибор,и в некоторых случаях, к анализу ответа. В качестве инструмента я остановился на python-е, погуглил как с его помощью работать с сетью, постаивл доки по стандартным функциям языка.

постановка задачи:

Чего хотелось бы прямо сразу:

  1. Скрипт, который по заданному шаблону формировал имена для файлов с крафикой и с данными. (для каждого типа - свой фиксированный префикс файла, основная часть имени задаётся пользователем)
  2. Сохранение графики и указанных спектров (в csv) на флеш (напрямую по сети можно получить лишь сырые csv, но с другой стороны есть простые команды для сохранения всего на флеш, т.е. нет необходимости заморачиваться ещё и обработкой, так что выбираем второй вариант)
  3. Файловые операции: переход в рабочую директорию или её создание, если таковой не существует, создание директории формата ггммдд для сохранения всех файлов.

решение:

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

понедельник, 11 февраля 2008 г.

Синхронизуемся!

преамбула:

констатируем факт, что зачастую можно прекрасно выполнять свою работу не находясь на своём рабочем месте. В данном контексте речь идёт о обработке данных, программировании, написании статей и пр. Если "менять место работы" приходиться лишь периодически, то проблема синхронизации рабочих файлов неактуальна - пару файлов можно и вручную скопировать на что угодно и перенести на основное рабочее место. Однако если работа на дому является обычной практикой, а кроме домашней и рабочей машины есть ещё и бук, то проблема синхронизации предстаёт во всей красе.

что имеем:

Домашний комп, ОС Linux; Ноут, ОС Linux; Рабочий комп, ОС Windows.

что хотим:

Двухсторонняя синхронизация рабочих файлов через флешку с рабочим компом и напрямую (или через ssh) с буком.

что делаем:

Идём на гугл с запросом "linux синхронизация файлов" и буквально первой строкой находим на opennet список программ для самвх различных нужд. Из описаний находим, что то что надо, называется unison.

Если коротко, программа использует алгоритм rsync но кроме того сохраняет сведения о дате последней синхронизации благодаря чему правильно обрабатывает изменения и удаления файлов в обоих направлениях, проста в настройке, является кроссплатформенной и свободной. Синхронизация осуществляется по профилям - файлы с расширением *.prf которые лежат в ./unison, настройку которых рассмотрим чуть позже.

установка:

altlinux

# apt-cache search unison

# apt-get install unison-beta

В windows для начала необходимо скачать и установить gtk2 for win32 после чего скачать винарник unison с домашней страницы проекта. Не имея желания разбираться с путями, я скинул бинарник прямо в папку bin, что находиться в дирктории с установленним gtk и вынес ярлык на стол.

настройка:

# unison --help даёт список доступных параметров, из которого сходу трудно выделить значимое. С домашней странички проекта http://www.cis.upenn.edu/~bcpierce/unison/docs.html идём по ссылке "User manual" читаем по выбору что интересно, но главное - останавливаемся на "Sample Profiles". В секции "Sample Profiles" находим несколько примеров профилей. За основу берём "A Basic Profile", поскольку бекап пока не интересен, удаляем все связанные с ним строчки. Указываем корневые директории для синхронизации (локальную, и удалённую)

# Roots of the synchronization

root = /home/bcpierce/Documents

root = /media/disk/Documents

Указываем пути, которые необходимо синхронизовать.

# Paths to synchronize

path = current

path = common

path = .netscape/bookmarks.html

Без этих параметров под синхронизацию попадаут все "Documents", более того, при первом запуске программы через GUI можно указать директории root1 и root2 но нельзя указать переменные path (может я конечно недостаточно внимательно всё осмотрел), именно по этой причине и рассматриваю настройку через прямую правку профилей. Ещё одна особенность - в windows при графической настройке пути root не должны содержать русских символов, т.к. программа почему-то не может зайти в них. Однако все вложенные директории обрабатываются вполне корректно.

Отметим что unison кроме содержания файлов также обращает внимание и на их права. В случае с флешкой от этой роскоши мы отказываемся, а чтобы программа не обращала внимания на различие прав добавляем в профиль строчку:

perms = 0o1600

Теперь сохраняем файл в ~./unison/flash.prf после чего запускаем:

# unison flash

При первой синхронизации программа выдаст предупреждение, что нет инфомации о прошлых сессиях, но при следующх запусках этого уже быть не должно. Аналогично настраивается синхронизация с буком, для чего можно сделать профиль, например, notebook. Параметр perms в этом случае уже лишний, если конечно устраивает его значение по-умолчанию 0o1777.

Успешной синхронизации!

День Рождения блога

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