есть подозрение, что ребята ещё сами это не осознали. но скоро они прозреют и тогда…

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

А сколько интересного нас ожидает в наступающем году, зависит только от нас — от дружного, талантливого, толкового, изобретательного и способного находить решение для любых задач коллектива НТЦ Метротек.

Нельзя не вспомнить добрым словом пользователей, которые с пониманием отнеслись к известным проблемам в наших приборах и, тем самым, помогли эти проблемы побороть. За это пользователям отдельное спасибо!

В общем, всех — с праздником! Пусть сбудутся все наши мечты и желания, пусть следующий год будет легче, чем предыдущий, но не менее насыщенный событиями, ведущими к успеху! Ура!

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылка на сайт сделано у нас: http://sdelanounas.ru/blogs/8024/

очень интересный эффект получается. сигнал на входе измерительного тракта уменьшается в тридцать тысячу раз.

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

Такой подход позволяет использовать стандартные средства 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 (0×02), подкласс EEM (0x0c), и протокол EEM (0×07). На этом все тонкости и заканчиваются. Пакеты в EEM передаются как есть, в виде ethernet фреймов, с дописанным в начале двухбайтным заголовком.

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

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

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

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

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

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

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