Такой подход позволяет использовать стандартные средства 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 байт длиной. Пропускная способность не измерялась.

Тут следует рассмотреть, что же из себя представляет контроллер 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Мбит/с с небольшим резервом, используемым для целей удалённого управления, а так же как «запас прочности».

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

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

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