Да, pjsip не оставил впечатление простой библиотеки. Некоторые его фичи были полезными: собственные политики выделения памяти и, самое главное, возможность их отключить :-) т.е. по умолчанию pjsip ест сильно больше памяти, чем ему необходимо, примерно раза в 1.5-2. Видимо, это сделано для ускорения, но непонятно, действительно ли их стек рассчитан на такие большие нагрузки, что обычние аллокатры не подходили.
Из-за того, что делали в свободное время, да, микрофон к сожалению не поддерживаем.
А перед тем, как приступать к микрофону, хотелось получить сначала какой-нибудь отклик на такой девайс. И потом уже пилить микрофон.
Я видел, что просто микрофон запустить легко. А вот можно ли запустить воспроизведение и запись одновременно, и какого типа гарнитуру для этого использовать ещё не исследовал.
Фишка с modbus'ом не в том, что есть какая-то реализация, а в том, что она весьма конкретная (http://libmodbus.org/) и самое главное, исходный код для Linux и для Embox один и тот же. Мы так и разрабатывали свой веб интерфейс, сначала собрали modbus-сервер на хосте, который вместо управления GPIO делал printf. А затем перенесли modbus-сервер на Embox, заменив только GPIO часть.
Другой пример: httpd, один исходный код работает под Linux и под Embox.
Этот modbus сервер и httpd работают в составе системы на STM32. И там же ещё запускаются CGI-программы, которые генерируют контент, которые тоже можно просто скомпилировать на хосте и разрабатывать/отлаживать.
позволяет экспортировать флаги компиляции для зависящих модулей. Т.е. только те модули, которые зависят от core, получают -Ipath, где можно найти его хидеры.
В настоящее время, все модули просто компилируются и линкуются в один образ в конце сборки. В новой версии системы сборки обещаем поправить =)
Перенесли из-за желания сделать команды максимально стандартными, тем самым уменьшив порог вхождения. Как бонус, получили возможность собирать команды из нашей ОС на unix хостах (без изменений), наоборот — тоже получается достаточно хорошо.
При добавлении новой команды нужно сообщать системе сборки о новом файле. Описание лежит рядом с исходником, как например Cat.my и cat.c.
Отделение исходников от информации о межмодульных взаимодействиях является одной из основных фич проекта, с её помощью нам удается включать в целевой образ только необходимый программный код.
Конечно, расхождение возможно и случается. Это больше относится к другим типам описаний, чем к информации о командах, забыть изменить мануал можно и в текущем файле. Над автоматическим извлечением другой метаинформации мы работаем в следующей версии системы сборки. Пока же, проверка соответствия исходников их описанию не представляет больших неудобств.
Но в случае с командами деление даже полезно: справка в одном файле, исходник — в другом.
Наша ОС Embox начиналась как монитор для встраиваемых систем. С тех пор у нас есть очень похожий репозиторий команд, основанный на линкер секции.
Со временем мы решили перенести регистрацию команд из исходных файлов в файлы описания системы сборки (она, кстати, описывалась на хабре: habrahabr.ru/post/144935/). Туда же мы помещаем метаинформацию о командах: краткую справку и man. Получается как-то так: описание для системы сборки
@AutoCmd
@Cmd(name = "help", help = "Shows all available commands", man = '''...'''
module help {
source "help.c"
...
}
А в help.c
int main(int argc, char **argv) {
...
}
Никакой высокой науки, но команды выглядят как обычные хостовые программы (точка вхождения — функция main), хотя внутри реализуются так же, как статье.
Для нас перечисленные в этой статье минусы не играли большой роли. Для разных архитектур используется gcc с единообразными линкер скриптами. Для тулчейнов других производителей линкер скрипт действительно может потребовать изменений, но они должны быть косметическими.
Конечно, вокруг команд есть много всего интересного: шеллы (управление задачами), терминал/консоль. Если сообществу интересно, как у нас это реализовано, то можно расписать подробнее.
На сколько я понимаю, нет. mips_first_exception_handler это такой длинный jump. Возможно, Вы правы, что можно было бы использовать атрибут: с __attribute__((interrupt)) на mips_c_syscall_handler получится обойтись без mips_second_exception_handler (точнее, аналогичный ему код подтянется из компилятора).
Я обычно предпочитаю не использовать этот атрибут, получается более прозрачно (и переносимо).
Из перечисленного, лучше всего под описанные задачи (среди которых «Система сборки не тянула за собой уйму зависимостей») подходит waf, но и он тянет за собой python.
Я выкинул много исходного текста, видимо, зря. Может и действительно не стоило выбрасывать его весь, но нет ничего слишком интересного, на мой взгляд, в том как я записывал битики в регистры (слишком просто) и выделял строки из потока (не относится к предметной области). Всё же, в конце есть ссылки на исходники, где не только перечисленное, но и как это работает в целом. Зато, по моему мнению, получилось легко и весело.
Статья может помочь тому, кто не задумывался, например, о блютус модуле или андройд пульте управления для своего проекта. Ну и помочь использовать какой-либо представленный элемент, опять же, ссылки внизу.
Извините, если обманул ожидания. Порекомендуйте, пожалуйста, что бы вы хотели увидеть в статье?
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
А вы свой стек куда-нибудь выкладывали?
А перед тем, как приступать к микрофону, хотелось получить сначала какой-нибудь отклик на такой девайс. И потом уже пилить микрофон.
Я видел, что просто микрофон запустить легко. А вот можно ли запустить воспроизведение и запись одновременно, и какого типа гарнитуру для этого использовать ещё не исследовал.
Другой пример: httpd, один исходный код работает под Linux и под Embox.
Этот modbus сервер и httpd работают в составе системы на STM32. И там же ещё запускаются CGI-программы, которые генерируют контент, которые тоже можно просто скомпилировать на хосте и разрабатывать/отлаживать.
Мы старались добавлять фичи по необходимости, поэтому pic не поддерживается.
Но есть такая запись в src/framework/mod/Mybuild:
позволяет определить макрос. Разворачивается в -D__FRAMEWORK__ опцию во время компиляции
Другой пример: страшный файл third-party/qpid/Mybuild
позволяет экспортировать флаги компиляции для зависящих модулей. Т.е. только те модули, которые зависят от core, получают -Ipath, где можно найти его хидеры.
В настоящее время, все модули просто компилируются и линкуются в один образ в конце сборки. В новой версии системы сборки обещаем поправить =)
При добавлении новой команды нужно сообщать системе сборки о новом файле. Описание лежит рядом с исходником, как например Cat.my и cat.c.
Отделение исходников от информации о межмодульных взаимодействиях является одной из основных фич проекта, с её помощью нам удается включать в целевой образ только необходимый программный код.
Конечно, расхождение возможно и случается. Это больше относится к другим типам описаний, чем к информации о командах, забыть изменить мануал можно и в текущем файле. Над автоматическим извлечением другой метаинформации мы работаем в следующей версии системы сборки. Пока же, проверка соответствия исходников их описанию не представляет больших неудобств.
Но в случае с командами деление даже полезно: справка в одном файле, исходник — в другом.
Со временем мы решили перенести регистрацию команд из исходных файлов в файлы описания системы сборки (она, кстати, описывалась на хабре: habrahabr.ru/post/144935/). Туда же мы помещаем метаинформацию о командах: краткую справку и man. Получается как-то так: описание для системы сборки
А в help.c
Никакой высокой науки, но команды выглядят как обычные хостовые программы (точка вхождения — функция main), хотя внутри реализуются так же, как статье.
Для нас перечисленные в этой статье минусы не играли большой роли. Для разных архитектур используется gcc с единообразными линкер скриптами. Для тулчейнов других производителей линкер скрипт действительно может потребовать изменений, но они должны быть косметическими.
Конечно, вокруг команд есть много всего интересного: шеллы (управление задачами), терминал/консоль. Если сообществу интересно, как у нас это реализовано, то можно расписать подробнее.
Я обычно предпочитаю не использовать этот атрибут, получается более прозрачно (и переносимо).
Что выглядит весьма иронично, если вспомнить, что Gnome когда-то был аббревиатурой.
Статья может помочь тому, кто не задумывался, например, о блютус модуле или андройд пульте управления для своего проекта. Ну и помочь использовать какой-либо представленный элемент, опять же, ссылки внизу.
Извините, если обманул ожидания. Порекомендуйте, пожалуйста, что бы вы хотели увидеть в статье?