Когда дело дошло до отладки, я обнаружил, что куда-то делся udev-monitor,
который раньше позволял мониторить появление и удаление устройств. Позже оказалось, что никуда он не пропал, а стал по-другому называться.
Теперь, чтобы запустить мониторинг нужно использовать:

$ udevadm monitor --udev

И будет счастье! ;)
Но ещё не полное. Ведь при отладке приходится убивать разъём и делать много телодвижений, вынимая и вставляя карту. Этого можно избежать, поскольку добавление устройства происходит после так называемого binding-а драйвера и подходящего к нему устройства. А для инициирования binding-a можно использовать маленький трюк.
Он заключается в следующем. Определяем, к какому драйверу подходит устройство, hotplug которого мы отлаживаем. «Подходящесть» драйвера к устройству определяется их именами
(см. сюда). Далее для симуляции выдёргивания/вставления устройства выполняем unbinding, а потом binding:

$ echo -n device_name > /sys/.../drivers/driver_name/unbind

После этой команды устройство пропадёт из системы. Будет выполнено правило
«remove» udev’ом.

$ echo -n device_name > /sys/.../drivers/driver_name/bind

После этой команды устройство cнова появится в системе. Будет выполнено правило «add» udev’ом.

Вот и всё.
А отлаживать происходящее в скриптах можно обычной связкой logger + syslogd.
И будет счастье ;)

Ну и ещё один трюк, в актуальности которого я, правда, сомневаюсь. Есть такая команда

$ udevadm test,

которая позволяет симулировать появление/пропадание устройства. Её плюс в том, что она пишет, какие программы и скрипты запускает udev! Чтобы устранить сомнения насчёт того, выполняется ли вообще скрипт. Меня смутило только предупреждение в man’e относительно этой команды. А вообще она мне помогла :)

Но чтобы удовольствие от отладки было полным, мы решили прикрутить gdb к vim’у. В этом нам помог проект Clewn.

Последовательность действий такова:

1. Подключаем прибор к компьютеру через ARM-USB-OCD и запускаем утилиту openocd на этом компьютере.
2. Запускаем gdb и vim:
   clewn -gc arm-elf-gdb -ga <путь-к-elf-файлу>
   Появляется GDB-shell и открывается gvim.
3. Присоединяемся к openocd:
   (gdb) target remote :3333
4. Прошиваем прибор нужной прошивкой:
   (gdb) load <путь-к-elf-файлу>

Все готово для отладки. Теперь можно открывать в gvim исходники, ставить breakpoint’ы, смотреть значения переменных и наблюдать за текущем местом выполнения. Список горячих клавиш описан в документации Clewn и, естественно, может модифицироваться.

update. А починили. Как обычно, сгорел предохранитель. Наши скептически настроенные аппаратчики принимают ставки на «сколько проработает». Принципы «ничего сделать нельзя», «всё равно сдохнет», «это не поможет», «и ничего не получится» — в жизнь!

Невооруженным взглядом видно, что платформа общая с небезызвестным Bercut-ET, но все самое интересное спрятано в интерфейсной плате.

На данный момент прибор работает в режиме шлейф (aka loopback) и имеет следующий функционал:

• заворот пакетов размером от 64 до 65000 байт – прочие пакеты уничтожаются
• Фильтрация фреймов по результату проверки CRC – ошибочные фреймы уничтожаются
• Шлейф 1 уровня – заворот трафика без изменений на физическом уровне
• Шлейф 2 уровня – заворот пакетов без CRC ошибок + обмен мак адресов
• Шлейф 3 уровня = шлейф 2 уровня + обмен IP адресов
• Шлейф 4 уровня = шлейф 3 уровня + обмен UDP/TCP портов
• Возможность задания MAC адреса интерфейса – весь входящий трафик проходит фильтрацию по этому адресу
• Сетевой интерфейс. Прибор отвечает на пинги и arp запросы (на arp запросы отвечает даже в режиме шлейфа)
• Распознавание во входящем пакете до 3-х VLAN и до 3-х MPLS меток.
• Отображение статуса линка

И это только начало :)

Cей девайс оттестирован с помощью коммутатора D-Link DGS-3426, который был снабжен двумя 10G модулями. В качестве физического уровня у нас были XFP модули и многомодовое волокно.  Сердцем системы является FPGA Arria GX, трансиверы которой были использованы, чтобы организовать XAUI интерфейс.

Мы при разработке приборов стараемся придерживаться принципа «Это вам никогда не понадобится» (aka «you ain’t gonna need it»). И действительно, почти на все задачи, появляющиеся после вопросов «А если?..», можно не обращать внимания и не терять времени на поиск решения. Впрочем, слово «почти» здесь, наверное, всё же имеет значение.

А метод MoSCoW становится понятным после расшифровки: M — MUST have, S — SHOULD have if it’s possible, C — COULD have this if it does not affect anything else, W — WON’T have this time but WOULD like in the future.

KISS, если кто не помнит или забыл, — «Keep It Simple, Stupid».

А YAGNI означает «You ain’t gonna need it».

Парное программирование, каким мы его видим:

парное программирование, каким мы его видим

А вы практикуете парное программирование?

1. В преамбуле tex-документа подключён пакет graphicx с опцией dvips:

\usepackage[dvips]{graphicx}

Драйвер dvips — программа, которая экспортирует dvi-файл в PostScript файл с расширением ps, что необходимо для последующего вывода печатного документа на принтер.

2. Исходными форматами картинок для наших руководств являются svg и png. Наиболее рациональным для LaTeX’а является использование формата eps. Многие графические приложения позволяют создать файл в данном формате, у нас для преобразования исходных файлов с расширением svg и png в формат eps используются следующие команды, прописанные в Makefile:

%.eps: %.png
convert    $< $@

%.eps: %.svg
inkscape -z -E $@ $<

3. В преамбуле tex-документа опрделяем команду \image:

\newcommand{\image}[4][размер_картинки]{%
\begin{figure}[H]%
\noindent\centering\includegraphics[width=#1]{#2}%
\caption{#3}%
\label{fig:#4}%
\end{figure}}

4. В самом tex-документе там, где необходимо вставить рисунок, пишем:

\image[размер_картинки]{путь к файлу с картинкой}{подрисуночная подпись}{метка}

Например:

\image[50mm]{pics/picture}{Картинка}{pic}

Размер картинки имеет смысл указывать в том случае, если он отличается от размера, заданного командой \image в преамбуле.

Расширение файла указывать не нужно,  по умолчанию оно .eps.

DFU — или Device Firmware Upgrade — это протокол для обновления прошивок по USB. Главные его преимущества в том, что он определён спецификацией USB и в том, что он достаточно прост. Вот только реализация этого протокола от ST оказалась не совсем стандартной. В результате вместо того, чтобы использовать готовую утилиту из проекта OpenMoko (dfu-util), её пришлось переписывать.

Утилита умеет загружать прошивку в RAM и FLASH, и запускать её на исполнение.

Ах, да, самое главное  – исходники лежат здесь.

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

Подробная документация на английском языке – здесь.