EE-312: построение сложных LwIP-приложений на основе VDK Blackfin
Добавил(а) microsin
Компания Analog Devices предоставляет порт облегченного стека TCP/IP (light-weight TCP/IP, LwIP) для семейства встраиваемых процессоров Blackfin®. Стек LwIP на процессорах Blackfin можно использовать для разработки встраиваемых сетевых приложений в комбинации с приложениями для звука/видео или приложениями для индустриальной автоматизации и управления. LwIP это привлекательный инструмент для быстрого портирования отдельных встраиваемых приложений во встраиваемые сетевые приложения.
Интеграция друг с другом нескольких программных компонентов в одно приложение является сложной задачей. Когда Вы используете многие программные компоненты, сложность системы растет в контексте анализа утилизации ресурсов системы, требований к пропускной способности, разрешения программных и аппаратных конфликтов, отладки приложения, и т. д. Для построения эффективных и надежных приложений при интегрировании LwIP нужно выполнить несколько определенных шагов. Этот документ (перевод статьи Ссылки/[1]) предоставляет руководство по интеграции LwIP в другие системы или приложения. Основная цель руководства - минимизировать распространенные ошибки при создании приложений на основе стека LwIP на процессорах Blackfin. Этот документ также обсуждает техники оптимизации системы, которые делают возможным достижение максимального быстродействия приложений на процессорах Blackfin в контексте интеграции стека LwIP. Также описаны процессорные ресурсы, которые задействованы для порта LwIP, чтобы помочь Вам разработать эффективную систему.
[Обзор LwIP и выгоды от его использования]
Встраиваемые сетевые приложения сейчас все чаще приспосабливаются к передаче мультимедийного контента (звук, видео и т. п.) через проводные и беспроводные сети. Индустриальные приложения автоматизации и управления - другая область, которая нуждается в возможности подключения к сети. На рис. 1 показаны приложения, в которых требуется наличие подключения к Интернет.
Компания Analog Devices предлагает свободные от выплат (при условии соблюдения лицензионного соглашения) программные блоки, позволяющие быструю разработку сложных встраиваемых сетевых приложений. Ниже приведен список основных и базовых программных компонентов, которые доступны вместе со средствами разработки для процессоров Analog Devices VisualDSP++® 4.5 и более свежей версии:
• LwIP – облегченный стек TCP/IP (см. Список дополнительной литературы/[1]), который был портирован на процессоры ADSP-BF52x, ADSP-BF54x, ADSP-BF53x и ADSP-BF56x1.
• Драйверы устройств и библиотеки системных сервисов (SSL) – функции API для конфигурирования и управления системными ресурсами и периферийными устройствами (см. Ссылки/[2]).
• VisualDSP++ Kernel (VDK) (Ссылки/[3]) – ядро реального времени (RTOS). Используйте это не требовательное к ресурсам ядро для эффективного управления системными ресурсами в многозадачном рабочем окружении для приложения.
• MM SDK – Multimedia Software Development Kit (см. Список дополнительной литературы/[16]). От включает примеры кода общих приложений, встречающихся в реальном мире мультимедиа.
Примечание 1: стек LwIP недоступен на процессорах ADSP-BF535 Blackfin.
Рис. 1. Типичное встраиваемое сетевое приложение.
Реальные сетевые встраиваемые приложения могут интегрироваться с этими программными блоками, чтобы реализовать систему с необходимыми функциями. Интеграция различных программных компонентов может привести к различным программным и аппаратным конфликтам. Дополнительно использование программных компонентов с подобным высоким уровнем абстракции в условиях изначально ограниченных ресурсов встраиваемой платформы может привести к чрезмерным затратам ресурсов системы и ошибкам в их управлении.
Этот EE-Note специально предназначен раскрыть несколько аспектов интеграции LwIP вместе с вышеописанными программными компонентами. Следующие процедуры, описанные в этом документе, помогут Вам быстрее разработать основанные на LwIP приложения на процессорах Blackfin. Остальная часть документа организована следующим образом:
• Обзор LwIP. • Бенчмарки, затраты памяти для LwIP с процессорами Blackfin. • Руководства по интеграции программных и аппаратных компонентов вместе с LwIP и другими частями приложения. • Техники оптимизации на платформе Blackfin, чтобы помочь увеличить быстродействие системы и ядра.
Этот EE-Note не заменяет руководство LwIP, руководство VDK и системных служб (SSL) другую связанную документацию (см. Список дополнительной литературы/[1, 2, 3, 4, 5, 6, 7, 8]).
LwIP это облегченная реализация стека протоколов TCP/IP (библиотека). Она бесплатна, с открытым исходным кодом, доступна для загрузки по ссылке [4]. Из-за низких требований к объему памяти, LwIP хорошо подходит для встраиваемых приложений.
Библиотека LwIP была портирована на процессоры ADSP-BF52x, ADSP-BF53x, ADSP-B54x и ADSP-BF56x, и этот порт доступен вместе с системой разработки VisualDSP++. Для начала разработки приложения TCP/IP на процессорах Blackfin можете использовать оценочные платы ADSP-BF537 EZ-KIT Lite®, ADSP-BF548 EZ-KIT Lite, ADSP-BF527 EZ-KIT Lite, или ADSP-BF526 EZ-KIT Lite, на которых установлен интерфейс Ethernet. Для процессоров ADSP-BF533/BF532/BF531 и ADSP-BF561 можете использовать карту расширителя сетевого интерфейса (USBLAN extender card). Подробнее про то, как начать разрабатывать проект TCP/IP, см. LwIP User Guide (Список дополнительной литературы/[1]). Порт LwIP для Blackfin использует библиотеку ядра RTOS (VisualDSP kernel, VDK), драйверов устройств (Device Drivers) и системных служб (system services libraries, SSL). Обратитесь к документации по VDK (Ссылки/[3]) и SSL (Ссылки/[2]) для получения дополнительной информации.
Функции, поддерживаемые LwIP. Список текущих доступных возможностей LwIP для релиза, относящегося к этому EE-Note, см. в прилагаемом .ZIP файле (Ссылки/[5]).
[Ресурсы процессоров Blackfin, используемые для LwIP]
В этом разделе статьи обсуждается пропускная способность, требования к памяти и системные ресурсы, задействованные при запуске в работу LwIP на процессорах Blackfin.
Пропускная способность LwIP на процессорах Blackfin была измерена с использованием инструмента ADI-TTCP, адаптированного к свободно доступному инструменту PCATTCP. Подробности о том, как использовать этот инструмент, и условия применения PCAUSA описаны в прилагаемом файле .ZIP (Ссылки/[5]). Рис. 2 показывает пиковую производительность LwIP в зависимости от размера буфера на платформе ADSP-BF537. Имейте в виду, что показанный результат может меняться в зависимости от загруженности (имеющегося трафика) сети и её поддерживаемой пропускной способности. Как показано на рис. 2, стек LwIP поддерживает до 11 мегабит/сек для стека протоколов TCP и UDP.
Рис. 2. Взаимосвязь размера буфера и пиковой производительности.
Объем используемой памяти LwIP на процессорах BF53x. Как уже упоминалось выше, порт LwIP использует библиотеки VDK и SSL. Затрачиваемые ресурсы памяти поделены на отдельные части, соответствующие этим компонентам - чтобы можно было лучше оценить затраты для систем, где VDK и SSL уже используются встроенным программным обеспечением. Показанные в таблице значения являются приблизительными, и они были получены для простой программы с использованием LwIP, наподобие "Hello world".
Таблица 1. Объемы памяти, задействованные для LwIP-приложения.
Программный компонент/протокол
UDP (код)
TCP (код)
UDP (данные)
TCP (данные)
Стек LwIP
35 килобайт
52 килобайта
10 килобайт
12 килобайт
Библиотека системных служб (SSL)
15 килобайт
15 килобайт
1.2 килобайта
1.2 килобайта
Библиотека VDK и другое
28 килобайт
28 килобайт
43 килобайта
43 килобайта
Всего
78 килобайт
95 килобайт
54.2 килобайта
56.2 килобайта
Таблица 2. Область кучи, необходимая для LwIP.
Тип приложения
Буферы драйвера
Куча
Пул памяти
Буферы пакета
Всего
По умолчанию
Rx=8*1560 Tx=2*1548 ~16 килобайт
~64 килобайта
~7 килобайт
~64 килобайт
~151 килобайт
Аудио/видео (большой размер пакета)
Rx=16*1560 Tx=8*1560 ~50 килобайт
~128 килобайт
~7 килобайта
~128 килобайта
~313 килобайта
Маленькие приложения, управление (малый размер пакета)
Rx=8*256 Tx=8*256 ~4 килобайта
~8 килобайт
~7 килобайта
~8 килобайта
~27 килобайт
Прерывания и DMA. Когда LwIP используется на процессорах ADSP-BF537, ADSP-BF527 и ADSP-BF526, драйверы используют их контроллер Ethernet. По умолчанию Ethernet DMA привязан на группу прерываний IVG11, и для него имеется специальный канал DMA.
Для процессоров ADSP-BF533, ADSP-BF532, ADSP-BF531, ADSP-BF54x и ADSP-BF561 стек LwIP использует для сетевого интерфейса USB-LAN extender card. По умолчанию драйвер устройства использует один уровень прерываний для завершения приема и передачи фрейма. IVG8 используется процессорами ADSP-BF533 как уровень прерывания хоста, и IVG11 используется процессорами ADSP-BF561. Дополнительную информацию по разработке драйвера устройства см. Список дополнительной литературы/[3] и Ссылки/[2, 6].
[Указания по программному обеспечению и аппаратуре]
Программное обеспечение. LwIP был портирован на Blackfin с использованием платформы VDK. Ожидается, что пользователи LwIP знакомы с общей концепцией операционной системы реального времени (real-time operating system, RTOS), какой является библиотека VDK. Подробное обсуждение концепции RTOS выходит за рамки этого документа, подробнее см. Список дополнительной литературы/[22].
В этой секции перечислены и описаны общие программные конфликты, которые могут возникнуть при интеграции LwIP с другими программными компонентами или приложениями.
• Любой программный компонент, который использует библиотеку SSL (а VDK использует), как минимум потребует задействования Менеджера Прерываний (Ссылки/[7]) и Менеджера DMA (Ссылки/[8]) (это отдельные службы библиотеки SSL). Интегрирование друг с другом двух или большего количества проектов, которые используют библиотеки SSL, потребует только одного экземпляра Менеджера Прерываний и одного экземпляра Менеджера DMA для всего приложения. То же самое справедливо и для Менеджера Устройств (Ссылки/[6]), и для Менеджера DCB (Ссылки/[9]), и всех других служб, используемых в системе.
• Интегрирование большего количества устройств или ресурсов в систему потребует дополнительного выделения памяти для Менеджера Устройств и Менеджера Прерываний. Следующие листинги показывают макросы, используемые для назначения памяти каналам DMA и устройствам. Используйте походящий коэффициент умножения, основанный на количестве задействованных в системе каналов/устройств.
// Данные Менеджера DMA (базовая память + память для 2 каналов DMA):
• Каждый программный компонент может иметь свои подпрограммы для инициализации, которые могут вызвать конфликт в процессе интеграции. Общие подпрограммы инициализации включают инициализацию прерываний, устройств, настроек тактирования и системного питания, внешней памяти, памяти кучи и т. д. Следующие листинги кода взяты из функции sys_init() проекта VisualDSP++ LwIP.
Аппаратура. Проблема, которая часто не дает отдельной функциональной системе работать с другими компонентами, заключается в ограниченной пропускной способности встраиваемой платформы. Процессоры Blackfin имеют внутренние шины с разной шириной (ADSP-BF53x и ADSP-BF52x имеют 16-битную шины, и ADSP-BF54x и ADSP-BF561 имеют 32-битную шину). Каждая шина может работать с максимальной частотой 133 МГц, что подразумевает максимальную скорость данных 266 или 532 мегабайта/сек, в зависимости от ширины внутренней шины. Несколько факторов могут снизить максимально доступную полосу, такие как время переключение системной шины между чтением и записью, конфликты банков, задержки из-за логики арбитража, конфликты ядра и DMA, и так далее. Эти факторы специфичны для приложения, и зависят от взаимодействия в реальном времени между перемещением данных периферийного устройства и доступом к данным со стороны ядра. В разделе "Оптимизация системы" обсуждаются техники, которые помогут минимизировать действие факторов, влияющих на снижение полосы пропускания системы, которые в результате дают более эффективное использование ресурсов системы.
Обслуживание прерываний. Несколько периферийных устройств могут быть привязаны к одному уровню IVG, и некоторые программные компоненты могут принять свой ISR как первичный обработчик для определенного уровня IVG (термины "первичный" и "вторичный" обработчик относятся к цепочке обработчиков прерываний, как обеспечивает Менеджер Прерываний, см. Ссылки/[7]). При интеграции обработчик прерывания от одного программного компонента будет зарегистрирован в таблице векторов прерываний (event vector table, EVT), перезаписывая любой ISR, привязанный на этот уровень IVG. Другими словами, убедитесь, что Вы привязали только один первичный обработчик прерываний на один уровень IVG с дополнительными обработчиками прерываний периферийных устройств, привязанные как вторичные обработчики на один уровень IVG. Чтобы избежать использования вторичных обработчиков, распределите периферийные устройства по разным приоритетам обслуживания, и привяжите их на различные уровни IVG, если это возможно.
Распределение кода/данных по областям памяти. Любые оптимизации, связанные с привязкой к памяти (например, расположение критических и наиболее часто запускающихся участков кода или часто используемых данных в быстрой памяти L1), должны быть повторно проанализированы при интеграции программных компонентов. Часто это игнорируется, когда программные компоненты были получены из разных источников, которые имели свою привязку к секциям памяти, настроенную под требования используемого ранее программного обеспечения. Поведение приложения (в контексте процентного использования процессорного времени для определенных секций кода/данных) может поменяться в новом интегрированном приложении, что может привести к повышенным задержкам доступа к памяти в сравнении с использование программных компонентов по отдельности. Таким образом, в приложении, где по-новому интегрируются разные программные компоненты, необходимо повторно проанализировать (и возможно подстроить) привязку к памяти кода и данных.
Обработчики исключений и ошибок аппаратуры (Exception, Hardware Error Handlers). VDK использует исключения служб для обслуживания планирования запуска задач и других активностей ядра. Это подразумевает привязку обработчика исключения к подпрограмме в коде ядра. Привязка передает все исключения ошибок к подпрограмме обработки исключений пользователя, которая создается по умолчанию. Для приложения, которое использует только библиотеки SSL, у Вас имеется привязка такого обработчика исключений. Однако, когда приложение с библиотекой SSL интегрируется в проект VDK, этот обработчик исключений не может быть привязан отдельно, и все исключения должны быть обработаны в подпрограмме обработки исключений по умолчанию пользователя, которая создается в VDK-проекте. Листинг ниже показывает обработчик по умолчанию для исключений, создаваемый в проекте VDK.
/* UserExceptionHandler */
/* Точка входа в обработчик исключений пользователя */
.GLOBAL UserExceptionHandler;
UserExceptionHandler:/**
* Здесь происходит обработка исключения...
*
* Помните, что VDK резервирует exception 0 для пользователя,
* к которому осуществляется доступ следующей инструкцией:
*
* EXCPT 0;
*
* Любое другое исключение (пользователя или системы), должно
* быть обработано Вами в этом месте. */
RTX;
.UserExceptionHandler.end:
Прерывания ошибок (Error Interrupts). Большинство прерываний ошибок периферийных устройств привязываются к IVG7. Таким образом, для эффективной отладки приложения важно явно реализовать обработку различных ошибок DMA или периферийных устройств. Использование прерываний ошибки в Вашей системе - самый лучший способ определить, когда в периферийном устройстве произошли переполнение или недогрузка данных (overrun или underrun). Например, ресурс с более высоким приоритетом не дает для ресурса с меньшим приоритетом вовремя обратиться к памяти, в котором могут находиться данные или даже дескриптор DMA.
[Оптимизация системы]
В этом разделе представлены несколько техник оптимизации, связанных с использованием программного обеспечения и аппаратуры, что поможет Вам полностью использовать достоинства архитектуры Blackfin. Пользователи, которые хорошо знакомы с платформой Blackfin и системой отладки VisualDSP++, могут пропустить чтение этого раздела.
Использование аппаратуры. Несмотря на то, что могут быть применены различные техники оптимизации системы, рекомендуется как минимум использовать следующее:
• 16/32-битные передачи: используйте максимальную полосу шины для всех передач DMA от периферийных устройств (PDMA) и всех пересылок DMA по памяти (MDMA). Инициируйте 16-битные передачи для процессоров ADSP-BF53x и ADSP-BF52x, и соответственно инициируйте 32-битные передачи процессоров ADSP-BF561 и ADSP-BF54x.
• Эффективное распределение каналов DMA: не применяйте две одновременные передачи DMA на одном и том же канале DMA.
• Банки памяти SDRAM: разбейте использование SDRAM по 4 банкам, чтобы гарантировать одновременный доступ к нескольким буферам данных и минимизировать время переключения доступа. Например, на плате разработчика ADSP-BF561 EZ-KIT Lite имеется 64 мегабайта SDRAM, которую можно сконфигурировать как четыре банка памяти по 16 мегабайт. Чтобы задействовать пользу от разбиения на банки, не размещайте в одном банке SDRAM два буфера данных, к которым осуществляется одновременный доступ.
• Управление трафиком DMA: используйте регистры управления трафиком DMA (см. Ссылки/[10], "Приоритизация и управление трафиком") для эффективной утилизации полосы пропускания системы. Регистры управления трафиком предоставляют способ влиять на то, как частот может меняться направление передачи на шинах данных, путем автоматического группирования передач в одном направлении. Подробнее см. Ссылки/[11, 12], где описывается оптимизация работы DMA.
• Минимизация конфликтов DMA и ядра. Избегайте доступа к внешней памяти со стороны ядра. По умолчанию у ядра имеется приоритет по доступу к внешней памяти перед DMA, но это можно поменять путем установки бита CDPRIO в регистре EBIU_AMGCTL. Если дать DMA приоритет выше, чем у ядра, то входящие или исходящие передачи трафика данных от периферийных устройств не будут приостанавливаться, когда ядро осуществляет доступ к внешней памяти.
• Кэширование инструкций и данных: разрешение кэширования инструкций и данных может значительно повысить быстродействие приложения. Если размер приложения велик, что обычно так и есть в случае приложений LwIP/VDK, то кэширование может помочь увеличить производительность приложения.
Подробнее техники оптимизации рассмотрены в статьях Ссылки/[11], и Список дополнительной литературы/[8, 13].
Программное обеспечение - выполнение ISR. Избегайте обработки данных в ISR или функциях обратного вызова (callback). Обрабатывайте буферы данных в потоках пользователя. Прерывания запускаются с более высоким приоритетом, чем потоки, определяемые пользователем. Пользовательские потоки всегда работают на уровне IVG15 (т. е. с самым низким приоритетом), и ISR-ы и callbacks-и (Ссылки/[9]) выполняются на своем соответствующем уровне приоритета IVG. Используйте отложенные функции обратного вызова (deferred callbacks, DCB) чтобы понизить приоритет выполнения некоторых участков кода по сравнению с ISR, позволяя более эффективно распределить время процессора.
ISR с менее высоким приоритетом не даст запуститься более приоритетному ISR, когда не разрешено вложение прерываний друг в друга для этого низкоприоритетного ISR. Процессоры Blackfin могут предоставить вложенность прерываний друг в друга, что позволит более высокоприоритетным периферийным устройствам прерывать выполнение обработчиков менее приоритетных прерываний.
Эффективная схема управления буферами. Используйте схему двойной буферизации, чтобы избежать приостановок процессора. Двойная буферизация или применение несколько буферов гарантируют, что процессор может обработать текущий буфер, пока другие буферы заполняются через DMA периферийного устройства. Рис. 4 показывает простую диаграмму потока данных в реализации с двойным буфером. Подробнее см. Ссылки/[11], где приведено больше диаграмм потоков данных, и даны рекомендации по обслуживанию двойной буферизации и применению нескольких буферов в приложении.
Рис. 4. Диаграмма потока данных для схемы с двойной буферизацией.
Оптимизации компилятора. Для увеличения быстродействия могут использоваться некоторые опции оптимизации компилятора. Обычно лучший эффект дают использование опций –O и –ipa (см. Ссылки/[13]). Использование оптимизации, управляемой профилем (profile-guided optimization, PGO Ссылки/[11]) также помогает дополнительно увеличить быстродействие. Подробнее про техники оптимизации см. главу "Achieving Optimal Performance from C/C++ Sources" в руководстве компилятора (см. Список дополнительной литературы/[18]). Некоторые ISR и функции критических вычислений могут быть оптимизированы вручную написанием на ассемблере, чтобы увеличить их скорость работы.
Оптимизации линкера. На кристалле процессора Blackfin имеется быстрая память L1 SRAM, которая часто не используется эффективно. Привязка критической памяти и наиболее часто выполняемого кода к L1 SRAM может устранить пропуск циклов ожидания из-за промахов кэша. Используйте статистический профайлер (Tools -> Statistical profiler), чтобы обнаружить наиболее часто выполняемый код, и привязать эти функции к памяти L1 SRAM. Также делайте привязку критических ISR к памяти L1 SRAM, чтобы гарантировать определенное время доступа. Подробнее про привязку кода к различным областям памяти процессоров Blackfin см. Ссылки/[11].
[Основные советы по отладке]
Кроме обычных возможностей отладки, таких как точки останова, (breakpoints) и окно просмотра переменных (окна Expressions или Locals), набор регистров архитектуры Blackfin и среда разработки VisualDSP++ предоставляют богатый инструментарий для отладки сложных систем. Вот некоторые из этих ключевых инструментов отладки:
Окно VDK History. Используйте окно VDK History (см. рис. 5), чтобы отслеживать состояние потоков, событий и гонок между потоками и т. п. Это окно в частности полезно, когда Вы отлаживаете приложения, которые вовлекают применение нескольких потоков. Открыть окно VDK History можно из меню VisualDSP++ путем выбора View -> VDK windows -> History.
Рис. 5. Окно VDK History.
Окно VDK Status. Окно VDK Status (рис. 6) отображает состояние (status) всех потоков, семафоров, сообщений и т. д., определенных в системе. Окно VDK Status также показывает код ошибки в случае паники ядра (Kernel Panic). Общие ошибки, которые приводят к панике ядра, включают вызов в ISR запрещенных для ISR или callback-ов функций VDK API, или попытка доступа к ресурсу потока, который был уничтожен. Открыть окно VDK Status можно из меню VisualDSP++ путем выбора View -> VDK windows -> Status.
Рис. 6. Окно VDK Status.
Блок отладки (Trace Unit) и регистры секвенсора (Sequencer). Чтобы отладить исключение (exception), сначала Вы должны определить причину исключения путем анализа поля EXCAUSE (эта мнемоника означает EX: exception и CAUSE: причина) в регистре SEQSTAT (SEQ от слова sequence, последовательность и STAT от status, т. е. состояние). Адрес инструкции, которая привела к исключению, сохраняется в регистре RETX. Повторно запустите приложение, предварительно разместив точку останова по адресу, где ожидается исключение, а также разрешите блок буфера трассировки (Trace Buffer Unit) путем установки двух бит в регистре TBUFCTL (Trace Buffer Control). После этого Вы можете проанализировать последовательность инструкций из Trace Buffer Unit, чтобы точно определить причину исключения.
Блок просмотра содержимого переменных (Watchpoint Unit). Регистр watchpoint предоставляет средство для отладки ситуаций, когда ошибка возникает на n-доступе к инструкции или данным. В таких случаях событие эмуляции может быть сгенерировано с использованием регистров watchpoint для n-1 по счету доступа к инструкции или данным; затем Вы можете выполнить пошаговую отладку, чтобы найти причину исключения или ошибки.
Регистры состояния периферийного устройства (Peripheral Status Registers). Если была определена ошибка DMA или периферийного устройства, Вы можете проанализировать регистры состояния DMA/периферии, чтобы обнаружить причину ошибки. Кроме ошибок конфигурации, ошибки (такие как переполнение или недогрузка DMA, т. е. ошибки overrun или underrun) происходят из-за неэффективного проектирования системы. В этом месте может помочь более эффективное управление буферами, или дополнительное деление приложения на более мелкие задачи.
Также, если используются библиотеки системных служб (system service libraries, SSL), большинство ошибок идентифицируются по кодам возврата из вызовов функций API системных служб, и кодов событий в callback-функции. SSL покрывают события, причиной которых были ошибки DMA или периферийных устройств. За подробностями обратитесь к примерам, которые включены в Multimedia starter kit (Список дополнительной литературы/[16]).
Здесь был приведен обзор наиболее часто используемых техник отладки. За дополнительной информацией обращайтесь к Ссылки/[14].