один наш программист «нарисовал» скевоморфный дизайн приборной панели. just for fun. было много вариантов, но остановились на этом, пусть будет. надо собраться с силами и как-то передать код в проект qwt, чтобы у всех была возможность прикрутить вот такой симпатичный виджет со стрелочным индикатором:

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

зато портативные приборы Беркут-ET, Беркут-E1, Беркут-ETX готовы к работе уже через пару-тройку секунд после включения.

чего раньше нельзя было сказать про Беркут-ММТ, где процесс загрузки занимал около сорока секунд.

но в новой версии обновления программного обеспечения мы сократили время запуска до двадцати трёх! а ближайшая цель этого направления разработки — уменьшить время запуска до 15, а то и до 10 секунд. мелочь, а приятно.

для сравнения, для рефлектометра на платформе EXFO FTB-200 от нажатия кнопки включения до готовности к работе проходит 50 секунд.

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

а завтра выйдет очередной релиз ПО для Беркут-ММТ. размер слова релиз в облаке меток ещё немного увеличится.

сделали тестовую версию следующей аппаратной ревизии 10-гигабитного анализатора ethernet Беркут-ETX: теперь поддерживается весь диапазон скоростей соверменных локальных, и не только, сетей: от 10M до 10G. и всё это в одном небольшом устройстве!

напомню, это единственный прибор для тестирования сетей 10 gigabit ethernet, разработанный и выпускаемый в России. более 40 таких устройств успешно используются операторами связи и интернет-провайдерами. аналогов в таком форм-факторе не существует не только в нашей стране, но и во всём мире.

и да, это реклама.

готовится к выходу в mass production очередной релиз рефлектометрического модуля для Беркут-ММТ. по всем параметрам (динамический диапазон, мёртвые зоны, удобство использования) он получился не хуже зарубежных аналогов. красивые отчёты с приборчика тоже скоро будут выложены. а пока можно полюбоваться на картинки с экрана в руководстве (pdf) и в рекламной брошюре (pdf).

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

Что сделано:

• повышена надежность файловой системы
• одна версия ПО для двух ревизий аппаратных модификаций прибора
• исправлены некоторые ошибки в подсистеме GBE и OTDR

Скачать обновление можно отсюда, более подробный список изменений — вот.

Инструкция по установке находится на нашем wiki.

О замеченых ошибках и проблемах в работе прибора, пожалуйста, сообщайте нам через баг-трекер.

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

Через пару дней, надеемся, внедрим в прибор. Сейчас вовсю идёт процесс тестирования и следующая ревизия Беркут-ММТ будет радовать пользователя не только удобным интерфейсом, но и действительно безотказной работой.

ps. эту новость должен был запостить Юра Людкевич. но я успел раньше ;)

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

идея наших программистов Юры Людкевича и Вадима Попова воплощена в жизнь!

да, «холодный» старт нынче занимает 38 секунд. и это не предел. в планах — достичь скорости максимум 10 сек.

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

но в последней аппаратной ревизии нам таки удалось неимоверно повысить и надёжность, и юзабельность устройства.

в частности, больной вопрос для всех современных мобильных (читай: переносных, потому как портативным наш прибор назвать сложно, да) разработок — вопрос с управлением зарядом батарей и временем автономной работы.

как у нас это было устроено раньше: в платформе стоял специально обученный микроконтроллер (pmmcu — power management mcu), отвечающий за взаимодействие с контроллером заряда батарей по протоколу smart battery. кроме того, этот микроконтроллер занимался включением/выключением прибора, контролем температур, напряжений, управлением вентиляторами и пр.

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

параллельно выяснилось, что:
a) существует несколько разновидностей специализированного чипа, отвечающего за кнопку «on/off»;
b) контроль большинства напряжений нужен только на этапе производства, а в процессе эксплуатации совершенно бесполезен (минус несколько АЦП на плате);
c) батарея умеет заряжаться в автономном режиме;
d) чип, который управляет вентиляторами и температурой, может это делать как сам, так и при помощи центрального процессора;
e) usb hub тоже не требует специального управления.

теперь pmmcu у нас в приборе нет. и всё получилось строго по ТРИЗ: устройства нет, а функция выполняется.

ай да мы! ай да молодцы!

на очереди — контроллер smart battery.

Такой подход позволяет использовать стандартные средства ping и traceroute.

Для реализации сетевого интерфейса (как собственно и консоли карты) использовался любимый нами USB-шный класс CDC (Communication Device Class). В этот класс входят подклассы позволяющие реализовать интерфейсы к телефонным линиям, модемы и сетевые карты (проводные и беспроводные). Большим плюсом использования стандартного класса USB-устройства, является отсутствие необходимости писать драйвера (в Linux/*nix, Windows всё равно требует хотя бы .inf файл).

Так вот сетевых устройств в классе CDC может быть несколько видов. Это подклассы ECM,EEM, NCM и вариации на тему ACM (вместе с rndis), которые так любит windows. Устройства отличаются степенью поддержки операционной системы, степенью документированности и некоторыми другими особенностями.

Итак:

• Rndis — нестандартная вариация на тему ACM. Вообще-то подкласс ACM — это последовательный порт или модем, но microsoft, традиционно наплевав на все имеющиеся стандарты создала собственный. Rndis, по своей сути, представляет собой реализацию ndis API поверх usb. Используется microsoft-ом и в КПК под windows mobile для синхронизации и связи с компьютером. Так как этот класс не полностью документирован, да и не стандартен — это не наш путь.
• ECM — Ethernet Control Model — это реализация сетевой карты (в стандарте есть поддержка проверка состояния линка, мак-адрес карты хранится в дескрипторе и тд). Данный стандарт требует двух интерфейсов: для передачи данных и управляющего. За терминологией обращаться на usb.org или сюда: http://www.beyondlogic.org/usbnutshell/usb1.shtml. Вторая ссылка намного короче и более просто расписана :).
• EEM — это Ethernet Emulation Model — в этом случае USB используется исключительно как транспорт ethernet пакетов. Состояние линка не передаётся, скорость не настраивается и так далее. Зато интерфейс просто и для него нужно только 2 endpoint-а.

Отсюда мы и подходим к выбору варианта сетевого интерфейса. Тут всё оказалось совсем просто — для реализации ECM нам просто не хватило доступных endpoint-ов в контроллере. Так что выбор остановился на EEM. Даже с ним, доступные 6 endpoint-ов, разделились полностью, и пришлось слегка обмануть реализацию консоли, указав в дескрипторе несуществующий endpoint.

Так вот, в stm32f105 есть 6 доступных endpoint-ов, не считая нулевого (по 3 IN и OUT). В итоге хватает впритык и резерва не остаётся. Для ECM уже endpoint-ов не хватает, так как под эту модель требуется по 3 endpoint-а на интерфейс.

Передача данных в модели EEM, или как же это заставить работать….

Для того, чтобы сетевое устройство с классом EEM зарегистрировалось в системе, достаточно правильно написать USB дескриптор. Создаётся интерфейс состоящий из двух bulk endpoint-ов, одного IN и одного OUT, ему приписывается класс CDC (0x02), подкласс EEM (0x0c), и протокол EEM (0x07). На этом все тонкости и заканчиваются. Пакеты в EEM передаются как есть, в виде ethernet фреймов, с дописанным в начале двухбайтным заголовком.

Выглядит он так:

Пятнадцатый бит определяет — является ли этот кадр данными идущими в интерфейс или служебной командой EEM. Всего есть 6 команд, из которых обязательными являются только Echo и Echo response. (Хотя как выяснилось, линуксовый драйвер, даже без реализации разбора этих команд вполне нормально работает).

Четырнадцатый бит определяет, используется ли реальный подсчёт CRC, или на месте CRC передаётся последовательносьт 0xdeadbeef.

Оставшиеся биты кодируют длину фрейма следующего за этими двумя байтами заголовка.

После реализации разбора заголовков, приём и передача заработали без проблем, за исключением того, что USB-шная библиотека от ST не позволяет реализовать USB-transfer длинее чем размер FIFO в stm32, а ethernet пакеты в EEM нельзя разбивать между transfer-ами.
Таким образом, сейчас реализован приём и передача пакетов до 254 байт длиной. Пропускная способность не измерялась.