| Внутреннее устройство стека uIP |
|
| Добавил(а) microsin | |||||||||||||||||||||||||||||||||||||||||||||
|
Стек uIP позволяет Вам добавить поддержку сети к маленьким встраиваемым системам, основанным на DSP (и даже на 8-битных AVR). Далее перевод статьи Drew Barnett и Anthony J. Massa [1]. Также добавлен перевод на русский язык документации uIP [3]. [Как встроить поддержку сети] С одной стороны, добавление сети к встраиваемой системе может быть грандиозной задачей, прежде всего потому что сетевые стеки весьма требовательны к ресурсам. С другой стороны, если Вы сумеете пройти через это испытание, то добавление сети позволяет сделать стандартизированный доступ к системе, потому что сетевые протоколы портируются между многими платформами. TCP/IP, к примеру, делает возможным беспроводный доступ к узлу датчика, и обмен с ним данными через обычный протокол большинства сетевых инфраструктур, где каждый сенсор становится доступным с десктопа PC, планшета, PDA, или даже с сотового телефона. Поддержка сети также улучшает базовый набор возможностей каждого узла. Например, если в сети произойдет сигнал тревоги, то устройство, которое стало причиной события, сможет сгенерировать e-mail и отправить его для немедленного оповещения оператора сети о проблеме. Другая выгода в том, что становится намного проще добавить технологии WEB во все устройства с поддержкой сети. Технические специалисты могут напрямую подключиться к узлу сенсора для его конфигурирования или мониторинга, используя обычный планшет PDA, оборудованный стандартным web-браузером. И действительно, web-сервер и страницы HTML, встроенные в датчик, добавляют новый удобный интерфейс с пользователем устройства. Есть много доступных сетевых стеков, которые предназначаются даже для очень маленьких встроенных систем, где циклы процессора и память ограничены. В этой статье мы всесторонне рассмотрим один из них — сетевой стек uIP, и затем портируем его на беспроводную DSP-плату датчика.
Рис. 1. Карта сети беспроводных сенсоров.
Рис. 2. Если кликнуть на узел сети, то можно управлять параметрами узла. На рис. 1 в качестве примера показана сеть датчиков, в которые встроен стек протоколов и web-сервер, чтобы разрешить управление на основе web-технологий. Теперь отдельные узлы сети можно отслеживать и управлять ими через страницы HTML, отображаемые web-сервером узла, как это показано на рис. 2. Протокол обмена файлами (File Transfer Protocol, FTP) может использоваться сетевым узлом сенсора для обновления имеющегося программного обеспечения. Это позволяет быстро добавлять новые свойства датчика и исправлять ошибки в программном обеспечении. Можно также динамически посылать конфигурационную информацию в каждый отдельный узел сенсора. [Проводные и беспроводные сетевые узлы датчиков] Это один из ключевых моментов, который определяет выбор стека для устройства, чтобы он лучше всего удовлетворял требованиям к программному обеспечению. На выбор стека также влияет объем и скорость передаваемых и принимаемых данных. Например, если Ваш сенсор пробуждается каждый час для передачи нескольких байт данных, то идеально подойдет компактная реализация сетевого стека. С другой стороны, системы с постоянной передачей многих пакетов данных могут потребовать реализации стека с улучшенной поддержкой буферизирования пакетов. При выборе и тестировании облегченной реализации сети важно уделить внимание тому, насколько она удовлетворяет стандартному обмену с наибольшим количеством полноценных стандартных устройств TCP/IP. Реализация, которая ориентирована только на отдельное устройство и сеть могут создать проблемы и ограничения в расширении сети датчиков, и усложнить интеграцию сети в общую стандартную сетевую инфраструктуру. Всегда можно реализовать Ваш собственный сетевой стек, и иногда это необходимо из-за определенной специфики требований к устройствам. Однако использование готовых решений сообщества разработчиков ПО с открытым исходным кодом намного усилит существующую технологию, и позволит разработке быстрее двигаться вперед. Следующие программные стеки являются open-source, и подходят для малых встраиваемых систем. Их можно иметь в виду, когда делаете выбор стека для системы с точки зрения используемых ресурсов. Приведенный здесь список не является всесторонним описанием возможностей стеков, это скорее начальная точка для дальнейших исследований: • lwIP (см. LwIP site:en.wikipedia.org). Аббревиатура расшифровывается как "lightweight IP" (облегченный IP) стек. Он значительно упрощен, однако имеет полную реализацию TCP/IP. lwIP разработан для работы в многопоточной среде с приложениями, работающими на основе конкурентных потоков; однако стек может быть также реализован в системе без операционной системы реального времени (real-time operating system, RTOS). Протоколы включают в себя ICMP, DHCP, ARP и UDP. Предоставляется поддержка нескольких локальных сетевых интерфейсов, и стек достаточно гибко настраивается для различных устройств, чтобы удовлетворять различным требованиям к ресурсам. Следует также отметить, что некоторые RTOS-ы имеют встроенные, портированные на них сетевые стеки, или подключают их. Один из таких примеров eCos (eCos site:ecos.sourceware.org), open-source RTOS, которая включает в себя оба сетевых стека, и OpenBSD, и FreeBSD, а также включает поддержку слоя приложения со встроенным embedded web-сервером (дополнительную информацию см. Embedded Software Development with eCos, by Anthony Massa, Prentice Hall PTR, 2003, для поиска введите запрос GoAhead Web Server site:embedthis.com). Если сетевой стек подключен или уже встроен в Ваше устройство, то можно применить несколько embedded web-серверов, чтобы реализовать управление через технологии web. Одно из таких решений - GoAhead WebServer (см. "Integrating the GoAhead WebServer & eCos," by Anthony Massa, DDJ, November 2002). Есть также некоторые ресурсы, которые детализируют подходы и основы в разработке упрощенного стека TCP/IP, предназначенного для embedded-систем (TCP/IP Lean: Web Servers for Embedded Systems, by Jeremy Bentham, CMP Books, 2002). [Сетевой стек uIP] Стек uIP (произносится как "micro IP") был разработан специально для embedded-устройств с ограниченными ресурсами. Тем не менее получилась полная реализация стека TCP/IP, и её размер и требования к ресурсам делают её идеальным кандидатом для приложений, таких как сетевые узлы беспроводных датчиков. Любой процессор, который содержит подходящий объем внутренней памяти, может запустить поддержку полного сетевого стека на своей плате, и при этом не понадобится тратиться на добавление внешней памяти RAM. Общая структура стека показана на рис. 3.
Рис. 3. Блок-схема сетевого стека uIP, на которой показаны поддерживаемые протоколы и добавленные приложения. Стек uIP использует один глобальный буфер, размер которого конфигурируется на базе максимального поддерживаемого размера пакета для входящих и исходящих пакетов (см. uip-master\unix\uip-conf.h, макроопределение UIP_CONF_BUFFER_SIZE). Поэтому приложение должно обработать пришедший пакет до того, как придет следующий пакет, или приложение может копировать данные пакета в свой собственный буфер, чтобы его обработать позже. Приходящие данные не будут сохранены в буфер пакета, пока приложение не обработает уже имеющиеся данные в буфере. Интерфейс сокета стандартный, BSD socket API. Для правильной работы этот интерфейс полагается на нижележащую многозадачную операционную систему. Из-за этого требования, приводящего к чрезмерным расходам ресурсов, uIP не поддерживает полный интерфейс сокета. Вместо этого uIP использует события. Таким образом данные, поступающие через соединение (или приходящий запрос соединения) приводят к возникновению события, которое отправляется к приложению для обработки. Чтобы избежать буферизирования исходящих данных до того, как они были подтверждены, uIP требует от приложения поддержки повторных передач пакета (retransmission). Когда стек uIP определил, что должна произойти повторная передача, приложению посылается событие. Приложение заново создает данные, которые были отправлены ранее. Отправка данных первый раз и повторная отправка с точки зрения приложения одинаковые, так что может использоваться тот же самый код. Сложность по определению того, когда должна быть повторная передача, берет на себя сам стек uIP, что освобождает приложение от этой задачи. Для того, чтобы оценить требования к ресурсам для реализации стека uIP, были использованы процессор архитектуры Atmel AVR и компилятор GNU версии 3.3. Таблица 1 показывает затраты ресурсов для конфигурации uIP с одним прослушиваемым портом TCP, 10 слотами соединений TCP, 10 записями в таблице ARP, буфером пакета 400 байт, и простым сервером HTTP. Таблица 1. Расход памяти uIP в байтах для типичной системы.
Стек uIP включает в себя скрипт Perl для преобразования web-страниц в массивы данных в памяти, так что они могут быть вставлены в код. Это устраняет необходимость в использовании какой-либо файловой системы для реализации несложного web-сервера. Общий расход RAM зависит от различных конфигурируемых компонент в стеке uIP. Выбор этих компонентов может быть просто настроен установкой опций в подключаемом заголовочном файле (uip-conf.h). Вы можете сконфигурировать количество поддерживаемых соединений TCP (чем меньше соединений, тем больше экономится RAM) размер блока памяти, выделенного на буфер приема/передачи, особенно если в сети размеры пакета обычно меньше. Определенные модули кода могут быть убраны целиком, если Вы используете последовательный сетевой интерфейс. Доступны последовательные протоколы, такие как SLIP или более устойчивый PPP. Выбор последовательного интерфейса вместо Ethernet позволяет удалить код поддержки ARP и таблицы ARP. Если не нужно использовать UDP, то это тоже может уменьшить размер кода. В стеке uIP эти опции могут быть удалены довольно просто с помощью макросов. Поток входящих пакетов можно отрегулировать путем подстройки максимального размера сегмента приходящих данных, допустимого для узла сенсора. Есть другие оптимизации, идеально подходящие для беспроводных сетей сенсоров, однако они требуют более глубокого конфигурирования. Области для дальнейшего исследования включают технику сжатия заголовка TCP/IP, чтобы уменьшить нагрузку от различных заголовков протоколов. Это будет наилучшим для систем сенсоров, состоящих из узлов, передающих маленькие пакеты данных. Для TCP доступны схемы повторной передачи пакетов которые перемещают переотправку пропавших пакетов ближе к месту назначения данных вместо того, чтобы полагаться на исходную точку. Это также может уменьшить длину, на которую подтверждение должно пройти через систему. [Портирование стека uIP на DSP TMS320C5509] Чтобы дополнительно проверить работу стека uIP, была создана плата прототипа беспроводного радиосенсора, которая основана на цифровом сигнальном процессоре (DSP) TMS320C5509 компании Texas Instruments. Для большинства портов стека uIP, код TCP/IP не нуждается в модификации. Однако уникальные возможности TMS320C5509 сделали необходимым ввести некоторые изменения в файлы ядра uIP. Ниже показана структура каталогов uIP. Для нового порта можно создать каталог, соответствующий специфике архитектуры, куда будут сделаны копии файлов из оригинальной директории UNIX.
Плата радиосенсора не имеет обычного порта Ethernet, используемого стеками сети; это отдельный добавочный модуль, который не представлен на основной плате. Система использует программно организованный последовательный порт для подключения к сети. Должно быть сделано некоторое конфигурирование хоста PC, чтобы настроить его для обмена с использованием SLIP через последовательный порт. Стек uIP включает в себя пример драйвера SLIP, который был модифицирован для того, чтобы он подошел к аппаратуре платы радиосенсора. Оригинальный драйвер SLIP опрашивал последовательный порт на предмет приходящих данных, и сохранял каждый символ, прикладывая транслирование данных SLIP по мере необходимости, как они поступят. Кот платы сенсора использует прерывание для последовательного порта, позволяющее ISR сохранить пришедшие данные. Когда принят полный сетевой пакет, устанавливается флаг, сигнализирующей о необходимости обработать данные. Одним из основных отличий TMS320C5509 от других типов процессоров является интерпретация типа char. На TMS320C5509 char имеет размер 16, а не 8 бит, как бывает у обычных микроконтроллеров. Это добавляет некоторые проблемы при портировании кода uIP, который был разработан для 8-битного типа char. В процессоре TMS320C5509 типы char, short и int все имеют разрядность 16 бит, и ячейки памяти данных адресуются по 16 бит. Как только данные попадают к драйверу последовательного обмена, они сохраняются в буфере. Данные в буфере обычной системы (у которой тип char 8-битный) будет выглядеть так, как показано на рис. 5(a), а рис 5(b) показывает буфер системы TMS320C5509. Когда на этот буфер накладывается структура для парсинга буфера, то поля старой структуры не будут содержать правильные значения данных. Из-за этого различия должна быть модифицирована основная структура заголовка TCP/IP, uip_tcpip_hdr (она размещена в файле uip.h). Кроме того, должен быть изменен код, который использует эту структуру. Адрес Данные 0x0000 45 00 00 30 7D 64 40 00 0x0008 80 06 d3 fc c0 a8 14 0a Рис. 5(a). Как выглядит буфер данных в 8-разрядной системе. Адрес Данные 0x0000 0045 0000 0000 0030 007D 0064 0040 0000 0x0008 0080 0006 00d3 00fc 00c0 00a8 0014 000a Рис. 5(b). Как выглядит буфер данных в 16-разрядной системе TMS320C5509. Листинг 1(a) показывает структуру заголовка оригинальной версии uip_tcpip_hdr. //Листинг 1(a) - оригинальный код uIP. typedef struct { /* IP header. */ u8_t vhl, tos, len[2], ipid[2], ipoffset[2], ttl, proto; u16_t ipchksum; u16_t srcipaddr[2], destipaddr[2]; /* TCP header. */ u16_t srcport, destport; u8_t seqno[4], ackno[4], tcpoffset, flags, wnd[2]; u16_t tcpchksum; u8_t urgp[2]; u8_t optdata[4]; } uip_tcpip_hdr; Поля структуры, которые имеют тип u8_t, менять не нужно, потому что разница есть только для платформы C5509, на которой будет занято 16 бит памяти вместо 8. Однако поля данных типа u16_t нуждаются в изменении. Листинг 1(b) показывает модифицированную структуру, которая подходит для платы прототипа датчика на основе процессора семейства C5509. //Листинг 1(b) - модифицированный код uIP. typedef struct { /* IP header. */ u8_t vhl, tos, len[2], ipid[2], ipoffset[2], ttl, proto; u16_t ipchksum[2]; u16_t srcipaddr[4], destipaddr[4]; /* TCP header. */ u16_t srcport[2], destport[2]; u8_t seqno[4], ackno[4], tcpoffset, flags, wnd[2]; u16_t tcpchksum[2]; u8_t urgp[2]; u8_t optdata[4]; } uip_tcpip_hdr; Затем изменения в структуре должны быть встроены в сетевой код uIP. Пример кода, использующего новую структуру uip.c, где номера портов TCP source и destination переключены на формат заголовка исходящего пакета. Листинг 2(a) показывает оригинальный код, а Листинг 2(b) модифицированный. Другие переменные, которые показывают ту же проблему, связанную с платформой C5509, должны быть модифицированы подобным образом. //Листинг 2(a) - оригинальный код uIP. /* Перестановка номеров портов. */ tmp16 = BUF->srcport; BUF->srcport = BUF->destport; BUF->destport = tmp16; //Листинг 2(b) - модифицированный код uIP. /* Перестановка номеров портов. */ tmp16 = ((BUF->srcport[1] << 8) | BUF->srcport[0]); BUF->srcport[0] = BUF->destport[0]; BUF->srcport[1] = BUF->destport[1]; BUF->destport[0] = (tmp16 & 0x00FF); BUF->destport[1] = ((tmp16 >> 8) & 0x00FF); В этом примере BUF является указателем на тип uip_tcpip_hdr, и он указывает на начало приходящего сетевого пакета. Поскольку мы поменяли оригинальный srcport с типа 16-bit unsigned short на массив из 2 элементов 16-bit unsigned short, то нам нужно сохранить массив элементов srcport должным образом. Этот пример также показывает модификацию, связанную с кодом для destport. Эти модификации были сделаны для исходного кода uIP, управляющего потоком данных. Другой файл, на который нужно обратить внимание uip_arch.c, он размещен в каталоге, зависящей от архитектуры. Этот файл содержит подпрограммы подсчета контрольных сумм TCP и IP. После портирования сетевого кода uIP на C5509, был реализован главный цикл обработки. Листинг 3 показывает незначительно модифицированную версию цикла обработки, который имеется в исходном коде uIP. //Листинг 3. // Инициализация и запуск таймера uIP, чтобы он срабатывал каждую 1 мс. timer_init(); // Инициализация последовательного порта для использования совместно со стеком uIP. serial_init(); // Инициализация, связанная с сетевым стеком uIP. slipdev_init(); uip_init(); httpd_init(); // Главный цикл обработки. while (1) { // Если длина полученных данных не равна 0, то мы знаем, что пакет готов // к обработке. Иначе сделаем вызов периодической функции 1 раз в секунду. uip_len = slipdev_poll(); if (uip_len == 0) { // Вызов периодической функции 1 раз в секунду, и сделаем цикл // по всем соединениям. if (ulTimer0Count >= 1000) { ulTimer0Count = 0; for (uiConn = 0; uiConn < UIP_CONNS; uiConn++) { uip_periodic( uiConn ); // Если результатом периодической функции были данные, которые надо отправить, // то длина данных будет больше нуля. if (uip_len > 0) slipdev_send(); } } } else { // Обработка пришедших данных. uip_input(); // Если в результате работы функции обработки были данные, которые нужно отправить, // то длина данных будет больше нуля. if (uip_len > 0) slipdev_send(); } } // Конец главного цикла. Инициализация выполняется для всех необходимых драйверов и модулей uIP, включая последовательный порт (serial_init), таймер (timer_init), и драйверы SLIP (slipdev_init), как и для стека uIP (uip_init), и для web-сервер HTTP (httpd_init). Функция slipdev_poll проверяет - есть ли пакет, принятый последовательным драйвером. Если пакет пришел, то uip_len устанавливается на размер пакета. Затем данные обрабатываются вызовом uip_input, который является макросом, вызывающим главную подпрограмму обработки uIP uip_process, которая разбирает принятый пакет. Если пакет данных не был принят, то проверяется счетчик таймера - нужно ли вызвать периодическую функцию (она называется uip_periodic). Счетчик таймера ulTimer0Count инкрементируется каждую миллисекунду в ISR таймера. Эта периодически вызываемая подпрограмма также вызывает основную подпрограмму обработки uip_process, чтобы поддерживать любые открытые соединения в системе. При портировании нужно также учитывать следующее: • Если таймер недоступен, то может использоваться переменная для подсчета секунд, и в эти моменты вызвать периодическую функцию. Однако в этом случае код должен быть откалиброван на основе тактовой частоты и загрузки процессора, и любые модификации кода могут повлиять на отсчет времени. [Словарик] ARP Address Resolution Protocol - протокол для преобразования IP адреса в MAC-адрес, в результате чего строится таблица IP:MAC для хостов сети, с которыми идет обмен данными. BOOTP Bootstrap Protocol - сетевой протокол, используемый для автоматического получения клиентом IP-адреса. Это обычно происходит во время загрузки компьютера. BOOTP определён в RFC 951. BOOTP позволяет бездисковым рабочим станциям получать IP-адрес прежде, чем будет загружена полноценная операционная система (из Википедии). DHCP Dynamic Host Configuration Protocol, протокол динамической настройки узла - сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP, и получает от него нужные параметры (из Википедии). DNS Domain Name System, система доменных имён - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства) и для других целей идентификации в сети. Создана потому, что человеку работать с обычными именами проще, чем запоминать цифры IP-адреса, а также для размещения на одном IP нескольких серверов под разными именами. embedded встраиваемая система на микроконтроллере. ICMP Internet Control Message Protocol, протокол межсетевых управляющих сообщений - сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают. Также на ICMP возлагаются некоторые сервисные функции (из Википедии). Например, команда ping как раз использует протокол ICMP. IGMP Internet Group Management Protocol, протокол управления группами Интернета - протокол управления групповой (multicast) передачей данных в сетях, основанных на протоколе IP. IGMP используется маршрутизаторами и IP-узлами для организации сетевых устройств в группы (из Википедии). IP Internet Protocol, маршрутизируемый протокол сетевого уровня стека TCP/IP. Именно IP стал тем протоколом, который объединил отдельные компьютерные сети во всемирную сеть Интернет (из Википедии). ISR Interrupt Service Routine, подпрограмма обработчика прерывания. HTTP Hypertext Transfer Protocol, протокол передачи гипертекста - протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов в формате HTML, в настоящий момент используется для передачи произвольных данных). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом (из Википедии). POP3 Post Office Protocol Version 3, протокол почтового отделения, версия 3 - стандартный Интернет-протокол прикладного уровня, используемый клиентами электронной почты для получения почты с удаленного сервера по TCP/IP-соединению (из Википедии). PPP Point-to-Point Protocol, двухточечный протокол канального уровня (Data Link) сетевой модели OSI. Обычно используется для установления прямой связи между двумя узлами сети, причем он может обеспечить аутентификацию соединения, шифрование (с использованием ECP, RFC 1968) и сжатие данных. Используется на многих типах физических сетей: нуль-модемный кабель, телефонная линия, сотовая связь и т. д. (из Википедии). SLIP Serial Line Interface Protocol, устаревший сетевой протокол канального уровня эталонной сетевой модели OSI для доступа к сетям стека TCP/IP через низкоскоростные линии связи путём простой инкапсуляции IP-пакетов. Используются коммутируемые соединения через последовательные порты для соединений клиент-сервер типа точка-точка. В настоящее время вместо него используют более совершенный протокол PPP (из Википедии). SMTP Simple Mail Transfer Protocol, простой протокол передачи почты - широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP (из Википедии). TCP Transfer Control Protocol, протокол управления передачей - один из основных протоколов передачи данных Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP (из Википедии). TFTP Trivial File Transfer Protocol, простой протокол передачи файлов) используется главным образом для первоначальной загрузки бездисковых рабочих станций. TFTP, в отличие от FTP, не содержит возможностей аутентификации (хотя возможна фильтрация по IP-адресу) и основан на транспортном протоколе UDP (из Википедии). UDP User Datagram Protocol, протокол пользовательских датаграмм) — один из ключевых элементов Transmission Control Protocol/Internet Protocol, набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных (из Википедии). [Ссылки] 1. Inside the uIP Stack site:drdobbs.com. |
