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

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

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

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

Тут следует рассмотреть, что же из себя представляет контроллер WIZnet W5100. В далёкие времена, когда контроллеры были 8-битными, памяти было мало, а реализация TCP/IP требовалась, появились микросхемы реализующие аппаратно стек TCP/IP. Вроде бы хорошая вещь и, например, для дистанционного управления устройством вполне подходит, позволяя не задумываться о тонкостях протокола TCP/IP, но у всего есть свои ограничения. О том нужны ли такие контроллеры сейчас, при наличии свободно распространяемых IP-стеков для микроконтроллеров и больших объёмах памяти — вопрос спорный и, возможно, заслуживающий отдельной статьи.

И тут мы подходим к тому, что же у нас пошло не так. W5100 можно подключить по трём возможным интерфейсам: двум разновидностям параллельного и по SPI. В нашем случае, для экономии выводов контроллера и упрощения подключения, wiznet подключили по SPI. О производительности в тот момент просто не задумывались, так как сразу использовать его планировалось только для дистанционного управления.

Когда же возникла потребность прогнать через wiznet 2Мбит/с данных, этот вопрос встал в полный рост. И тут в дело вступили ограничения чипа. Как оказалось, максимальная тактовая частота по SPI для wiznet была ограничена 14-ю мегагерцами. Это не было бы проблемой, если бы wiznet поддерживал burst режим и позволял гнать данные непрерывным потоком. Но тут в дело вступило ещё одно ограничение интерфейса SPI у wiznet’а — каждая SPI транзакция у него должна состоять ровно из 4-х байт и содержать код операции, два байта адреса и один байт данных. То есть, на каждый байт полезной нагрузки требовалось передавать 3 байта дополнительных данных. И это — не считая управляющих транзакций, которые передаются по той же схеме. Максимальная пропускная способность, которую мы считали равной 14Мбит/с, оказалась в 4 (!!!) раза меньше и оказалась 3.5Мбит/с.

Второй проблемой оказался SPI-контроллер в процессоре STM32 — делители частоты в нём могут быть только степенью 2. В результате на максимальной тактовой частоте процессора, которую мы использовали до того времени, частота шины к wiznet’у оказалась только 9 мегагерц.

Помимо проблемы передачи данных к wiznet’у так же требовалось эти данные получить из контроллера линии E1. К счастью, решение, использованное для чтения данных из E1, поддерживало burst-режим передачи данных. Попытки получить максимальную возможную скорость передачи к wiznet’у привели к использованию следующей схемы передачи данных:

1. Из E1 данные вытягиваются по SPI с помощью контроллера DMA, встроенного в процессор STM32. Так как посылки имеют большую длину, DMA работает с высокой эффективностью и накладные расходы невелики.
2. Данные в wiznet передаются без использования DMA или прерываний, так как это резко снижает производительность на коротких посылках в связи с высокими накладными расходами.
3. Для получения возможности одновременной передачи данных в wiznet и приёма данных с линии E1 введена двойная буферизация.
4. Основное ограничение по времени — это передача данных в wiznet, в связи с тем, что приём данных из E1 практически не требует процессорного времени.

В результате всех этих исследования мы пришли к следующим выводам:

1. Иногда целесообразном снизить тактовую частоту процессора с целью повышения производительности передачи данных по внешним интерфейсам.
2. DMA у контроллера STM32 эффективно можно использовать только при достаточно длинных транзакциях. Для случая коротких (4 байта ) транзакций потери в скорости слишком велики.

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

Долгое время наши программисты мечтали получить для аппаратного тестирования удобный JTAG-разъем… Сначала мы ставили DIN колодки на 6-10 контактов с шагом 2 и 2.54мм — надежное и дешевое решение, но имеет ряд недостатков:

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

Поэтому, приводя схемотехнику наших приборов на соответствие требованиям CE, мы решили отказаться от DIN-разъемов и повсеместно перейти на плоские ленточные FFC кабели и, соответственно, разъемы для них. В наших приборах мы используем 8-ми пиновые односторонние вертикальные и горизонтальные FFC-разъемы. С этими разъемами все оказалось неплохо, и  электростатических помех меньше, и места на плате не так много занимают. Однако, и в этой реализации нашлись кой-какие недостатки:

• для подключения ленточного кабеля к JTAG-разъему нужно разбирать прибор (например, в Беркут-ET необходимо снять плату GbE, что занимает какое-то время и требует отвертки);

• довольно высокая стоимость разъемов и ленточных кабелей;
• недолговечность ленточных кабелей (при активном использовании, а также неаккуратном использовании кривых руках кабели приходят в негодность);
• ещё одна особенность ленточных разъемов кабелей состоит в том, что необходимо использовать заводские кабели, выполненные точно в размер, требуемый для разъема, иначе кабель будет болтаться и коротить контактные площадки. С этим мы и столкнулись, когда стали работать COM-модулями Colibri от Toradex.

Разъем JTAG-на этом модуле — 6-пиновый FFC, и мы сделали кабель для него из 8-пинового… Получилось, но, так как разъем сам по себе маленький и кабель не точно обрезан в размер, то и дело возникали проблемы с  контактом. Чуть кабель криво повернул или под углом вставил — всё, контакта нет — не работает. Попутно пришлось еще разработать переходник JTAG-ARM на 8-пиновый кабель.

В общем, работать с такой системой, мягко говоря, не комфортно… К счастью, на плате Сolibri параллельно контактам разъема разведены площадки для pogo-пинов. Через эти площадки с помощью специального программатора их и прошивают и тестируют на заводе. И мы для удобства пользования, а также для освоения современной технологии тестирования электронной аппаратуры решили повторить такой программатор… И получилось!!!

Что же такое pogo pin…? Да просто говоря по русски, это пружинящий контакт.

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

Суть технологии не очень сложна — на печатную плату устройства вместо технологического разъема разводятся контактные площадки. Тестирующая головка состоит из pogo-пинов, прижимающихся к этим площадкам на время работы. За счет пружины, находящейся внутри контакта, обеспечивается небольшое усилие на наконечник pogo-пина, прижимающее его к площадке и, тем самым, хороший контакт.

У этой технологии, как и у любой другой, есть преимущества и недостатки… Она, конечно, вне конкуренции при больших партиях оборудования и при конвейерной сборке (тестировании) оборудования, но при небольших партиях — не эффективна, так как появляются затраты на создание тестирующей головки, обеспечивающей точное позиционирование и на надежный прижим к контактным площадкам.

Если нам удастся придумать надежную и не дорогую конструкцию такого тестового разъема, то есть шанс перейти на  данную технологию и в наших серийных приборах… Вдруг получится?..

Невооруженным взглядом видно, что платформа общая с небезызвестным 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 интерфейс.

В общем, полноценный набор инструментов железячника. Кстати, у нас на сервере установлено всё, кроме ng-spice.

А вот ссылка на устройство из серии just for fun, сделанное с использованием GEDA streaming alarm clock. С картинками, принципиальными схемами, историей создания. Там и другие разработки присутствуют. Аппаратчикам рекомендую посмотреть. Просто для информации.

А мы? Где мы?