SIP телефон из stm32f4-discovery
Всем привет.В этой статье я расскажу, как мы делали sip-телефон на базе stm32f4-discovery с помощью своей встраиваемой ОС Embox. Характеристики stm32f4-discovery (144MHz, 192Kb RAM, 1Mb ROM) могут вызывать сомнения о возможности такой реализации. Нам самим было интересно, получится ли? В качестве ответа можно посмотреть видео, а в самой статье — технические подробности.[embedded content]
Как это работаетПО этого устройства состоит из софт-телефона PJSIP и уже упомянутой ОС Embox. PJSIP отвечает за поддержку sip-протокола, декодирование звука. Embox предоставляет PJSIP стандартную библиотеку, библиотеку pthread, сетевой стек, драйвера для вывода аудио и остальной набор функций ОС. Для этого используется POSIX-интерфейс, что позволяет практически без изменений перенести широкий класс приложений с unix-подобных ОС на встраиваемые системы. Перенос PJSIP на ОС Embox прошел ожидаемо легко, а вот с запуском PJSIP на конкретной аппаратной платформе возникли некоторые трудности. О них — дальше.Для тех, кто хочет повторить наш успех, мы подготовили небольшую инструкцию. Вам потребуется stm32f4discovery + stm32dis-bb, подключение по com-порту к ней (есть на плате расширения), хост с линуксом, ethernet соединение между платой и хостом.
Нужно взять github.com/embox/pjsip и перейти в этот каталог. Здесь лежат скрипты сборки, приложения и файлы, которые мы использовали для подготовки к демонстрации.
Первый простой шаг заключается в запуске Embox’а на discovery. В качестве формата образа мы используем ELF.Можно взять предварительно собранный образ, файл embox.Либо можно собрать Embox самостоятельно. Для этого:
После прошивки нужно подключиться по последовательному порту к discovery, подключить эмулятор терминала, выставить настройки 115200 8n1. После запуска система выведет немного статусной информации, отобразит и выполнит команды стартового скрипта и предоставит шелл-интерфейс. Далее предполагается, что все команды нужно выполнять в консоли discovery.Далее, нужно собрать и запустить хост-клиент. Возвращаемся на консоль на хосте.Зачем это? Нам очень хотелось сделать на обычной встраиваемой платформе что-то необычное. Было понятно, что платформа должна быть очень популярной и дешёвой, поэтому выбрали stm32f4-discovery — не 8-разрядный контроллер, но и не гигагерцовая RaspberryPi или Beaglebone. Стали смотреть, что есть на discovery: помимо ethernet обратили внимание на возможность вывода звука.А тут сошлись звёзды: коллеги «по цеху» разрабатывали sip-телефон на OMAP137 с Линуксом. И писать специальный софт там было какое-то мучение: bitbake, который с минуту думает о том, что и как ему собирать, рекомендации чистить проект по любому поводу, а первая сборка занимает с несколько часов.
Поэтому мы для себя устроили challenge: SIP-устройство, максимально похожее по функциональности на телефон, на существенно более слабом железе.
Дополнительным пунктом в этом разделе стал комментарий Indemsys, в котором он спрашивал про софт, который есть только на Линуксе и нет на контроллерах (голом железе или классических RTOS).
Подготовка Первый этап — выбор стороннего ПО для поддержки sip-протокола и сопутствующей передачи аудио. Первым в результатах выдачи google оказался www.pjsip.org, который умеет всё нужное, позволяет обработку топором и напильником в широких масштабах, переносим и имеет низкие требования к объему ОЗУ (заявляются 150 кб).Для начала нужно создать файлы описания сборки. Для тех, кто слышит о Embox в первый раз: у нас используется своя система сборки (статья на хабре), которая оперирует понятием «модуль». Для облегчения сборки стороннего ПО мы ввели расширение, которое поддерживает автоматическое скачивание, применение патчей, конфигурацию, сборку и установку.
Библиотека PJSIP будет как раз модулем. Первый зафиксированный коммит на эту тему. Здесь можно оценить, как описание сборки отличается от сборки для хост системы (никак) и какие модификации понадобились в PJSIP: отключаем плюсовые приложения для простоты; сообщаем об отсутствии SOCK_RDM.
В дальнейшем эти файлы конечно менялись, но основа осталась той же. Дополнительно понадобились объявления макро-значений для уменьшения объема структур в памяти, отключения кодеков, и т.д. Современный вид описаний можно оценить под спойлером.
Модули PJSIP package third_party.pjproject
@Build (stage=2, script=»$(EXTERNAL_MAKE)») @BuildDepends (third_party.STLport.core) module core {
depends embox.net.lib.getifaddrs
depends embox.compat.posix.pthreads depends embox.compat.posix.pthread_key depends embox.compat.posix.pthread_rwlock depends embox.compat.posix.semaphore depends embox.compat.posix.fs.fsop depends embox.compat.posix.idx.select depends embox.compat.posix.net.getaddrinfo depends embox.compat.posix.net.gethostbyname depends embox.compat.posix.util.gethostname
depends embox.compat.posix.proc.pid depends embox.compat.posix.proc.exit depends embox.compat.libc.stdio.fseek depends embox.compat.libc.time
depends third_party.STLport.core }
@AutoCmd @Cmd (name=«streamutil», help=», man=») @BuildDepends (core) @Build (stage=2, script=«true») module streamutil { source »^BUILD/extbld/third_party/pjproject/core/install/streamutil.o» depends core }
@AutoCmd @Cmd (name=«pjsua», help=», man=») @BuildDepends (core) @Build (stage=2, script=«true») module pjsua { source »^BUILD/extbld/third_party/pjproject/core/install/pjsua.o» depends core }
@AutoCmd @Cmd (name=«pjsip_simpleua», help=», man=») @BuildDepends (core) @Build (stage=2, script=«true») module simpleua { source »^BUILD/extbld/third_party/pjproject/core/install/simpleua.o» depends core } Описание сборки PJSIP PKG_NAME:= pjproject PKG_VER:= 2.2.1
PKG_SOURCES:= http://www.pjsip.org/release/$(PKG_VER)/$(PKG_NAME)-$(PKG_VER).tar.bz2 PKG_MD5:= 6ed4bb7750c827dc1d881e209a3b62db
include $(EXTBLD_LIB)
PKG_PATCHES:= pjproject.patch \ simpleua_default_loglevel.patch \ mutex_loglevel_increase.patch \ kmalloc.patch
DISABLE_FEATURES:= \ l16-codec \ ilbc-codec \ speex-codec \ speex-aec \ gsm-codec \ g722-codec \ g7221-codec \ #g711-codec
PJPROJECT_ROOT:= $(ROOT_DIR)/third-party/pjproject PJSIP_CPPFLAGS:= -I$(PJPROJECT_ROOT)/include $(EMBOX_DEPS_CPPFLAGS) -I$(SRC_DIR)/compat/cxx/include BUILD_ROOT:= $(BUILD_DIR)/$(PKG_NAME)-$(PKG_VER)
$(CONFIGURE) : export EMBOX_GCC_LINK=full; \ cd $(BUILD_ROOT) && (\ ./aconfigure \ CC=$(EMBOX_GCC) \ CXX=$(EMBOX_GXX) \ CPPFLAGS=»$(PJSIP_CPPFLAGS)» \ --host=$(AUTOCONF_TARGET_TRIPLET) \ --target=$(AUTOCONF_TARGET_TRIPLET) \ --prefix=/ \ $(DISABLE_FEATURES:%=--disable-%) \ --with-external-pa; \ echo export CFLAGS+=»$(PJSIP_CPPFLAGS)» > user.mak; \ echo export CXXFLAGS+=»$(PJSIP_CPPFLAGS)» >> user.mak; \ ) cp ./config_site.h $(BUILD_ROOT)/pjlib/include/pj/config_site.h touch $@
$(BUILD) : cd $(BUILD_ROOT) && (\ make -j1 dep; \ make -j1 MAKEFLAGS='$(EMBOX_IMPORTED_MAKEFLAGS)'; \ ) touch $@
$(INSTALL) : for f in $(BUILD_ROOT)/pjsip-apps/bin/samples/$(AUTOCONF_TARGET_TRIPLET)/*; do \ cp $$f $(PKG_INSTALL_DIR)/$$(basename $$f).o; \ done for f in $(BUILD_ROOT)/pjsip-apps/bin/*-$(AUTOCONF_TARGET_TRIPLET); do \ fn=$$(basename $$f); \ cp $$f $(PKG_INSTALL_DIR)/$${fn%-$(AUTOCONF_TARGET_TRIPLET)}.o; \ done touch $@ Звук Для демонстрации мы изначально использовали пример под названием streamutil, который умеет передавать только медиа-поток.После того как мы добавили скрипты сборки и немного помахали напильником, streamutil стал останавливаться с сообщением об отсутствующем устройстве для вывода звука. С нуля воспроизведение делать было не нужно, производитель поставляет демо-приложения для проигрывания wav-файлов с флешки. Этот код и послужил основой для будущей реализации.
С другой стороны, стоял вопрос, с помощью какого интерфейса будет осуществляться взаимодействие: можно разработать звуковой плагин для PJSIP или использовать один из уже существующих для популярных звуковых API. Среди них оказался portaudio, заметно более простой чем, например, ALSA API. Мы приступили к реализации драйвера с этим интерфейсом.
В двух словах интерфейс описывается так: регистрируем callback, который будет вызываться при необходимости, когда буфер звуковой карты будет близок к опустошению. Замечательный простой API не регламентирует, в каком контексте будет вызываться callback, и в реальных системах для этого запускается отдельный поток, который спит большую часть времени и выполняет callback в нужный момент времени.
С такой схемой возникают проблемы типа «дырявая абстракция»: PJSIP явно предполагает отдельный поток. Попытки вызвать callback по сигналу приводили к deadlock«у. Пришлось делать как во «взрослых» системах, с потоками. В конце этого этапа драйвер стал выглядеть так.
В будущем, мы собираемся по возможности отказаться от использования обычных потоков в пользу легких потоков. Главным отличием лёгкого потока является отсутствие собственного стека, вычисления ведутся на стеке последнего выполнявшегося потока. К легким потокам предоставляется pthread-совместимый интерфейс с доступными средствами синхронизации. В теории, это позволит использовать их в качестве реализации portaudio-потока, и тем самым сократить потребление памяти.
Нехватка памяти Основной проблемой, с которой мы боролись, была нехватка динамической памяти.Здесь надо сделать ремарку про динамическое выделение в нашей системе. Мы используем pool«ы — зарезервированные участки статической памяти для фиксированного количества объектов фиксированного же размера. Способ не самый гибкий и порой заставляющий писать некоторое количество boilerplate кода, зато взамен получаем возможность контролировать расход памяти и отлавливать потенциальную нехватку памяти на этапе компиляции. На самом деле, конфигурировать размер pool«ов гораздо проще, чем может показаться.
Во-первых, они задаются в глобальном файле конфигурации, где описаны все остальные параметры системы, такие как: подсистемы, команды, политики управления, например, планировщиком. Размер этого файла редко превышает 100 строк, правда это число может сильно зависеть от состава системы.
Во-вторых, размеры pool«ов часто являются следствиями естественных требований, например, в нашей stm32f4discovery может быть только 2 сетевых адаптера: набортный ethernet и loopback. Удивительно, но такую определённость можно наблюдать в других подсистемах: число открытых файлов, приоритетов планировщика, количества обработчиков irq, многое другое — всё это хорошо поддаётся анализу во встроенной системе.
Возвращаясь к PJSIP, он использует собственную библиотеку для динамического выделения памяти, которая, в свою очередь, реализована поверх стандартных вызовов malloc/free. Предсказать потребность streamtuil в объеме динамической памяти достаточно трудно. Но так как вся куча монопольно используется streamutil, мы можем контролировать её размер и расширять за счёт системных pool«ов.
Одним из самых больших pool«ов в системе были буфера сетевых пакетов. Тут я сделал небольшой хак: изменил максимальный размер пакета со стандартных 1514 байт до 214, зато увеличил максимальное количество пакетов. Дело в том, что тестирование показало: от/к streamutil ходят пакеты не более 214 байт, поэтому такой трюк сработал.
Нам понадобилось несколько итераций увеличения кучи, но после них streamutil стал выдавать чистый звук.
SIP-телефон Понятно, что streamutil — демо-приложение, мало похожее на нужный телефон. Нужно было взять что-то более функциональное. Хороший кандидат — pjsua, референсный sip-телефон на PJSIP. Модифицировали скрипты сборки, начали запускать. Не хватает памяти. Окей, утянули размеры pool«ов ещё туже. Не хватает памяти. Тут нас начали терзать смутные сомнения, а возможно ли в принципе удовлетворить запросы pjsua? Первая попытка это выяснить заключалась в трассировке запросов pjsua к malloc/free на хосте. Но, оказалось, стандартная библиотека слишком активно использует динамическое выделение для собственных нужд (например, форматирование даты в строку), поэтому вывод трассировки был сильно захламлён.
Мы пошли другим путем: в своей стандартной библиотеке мы не используем malloc/free, поэтому трасса будет гораздо более информативной. Мы добавили трассировку в библиотеку выделения памяти, затем собрали embox с pjsua для beagleboard и запустили его на qemu. Результаты нас несколько расстроили, получилось чуть больше 200 кб только на кучу, без учёта фрагментации и статической памяти pjsua. Такой объем в stm32f4 не поместится. Возможных выходов было два: серьёзным образом модифицировать pjsua, либо искать более легкую альтернативу.
К счастью нашлась альтернатива — демо-приложение simpleua. Трассировка динамического выделения simpleua показала максимальный размер живой кучи около 110 кб. Если сложить с .data (~4 кб) и .bss (~25 кб), то остаётся достаточно места под основной стек и потоки, буфера сетевых пакетов и аудио-интерфейса.
В процессе реализации пришлось добавить поддержку нескольких регионов памяти для кучи, увеличить размер пакета (требуется 810 байт) и уменьшить их количество.
Результат вы видели на видео.
Вывод Статья написана сразу по успешному запуску. Мы не успели отловить возможные баги, поэтому, если встретите их, вы предупреждены. А если серьезно, мы будем рады любым отзывам и комментариям. Спасибо за внимание!
