Исправление SZT, (текущая версия) :
Киллерфича там в том, что можно малой кровью переносить приложения из Linux на контроллеры, там они какой-то слой позикс-совместимости реализовали. https://www.youtube.com/watch?v=5YcwnoVKu5M - доклад на эту тему
Кому-то это может очень нужно, но вот лично мне это не требуется. Ну и оверхеда многовато, https://habr.com/ru/company/embox/blog/431134/ - использовать жирный контроллер STM32F7 для SIP VoIP это явно перебор, VoIP это ж тупо - взяли PCM семплы из кодека, закодировали их в какой-нибудь u-Law (кодирование там тупо через таблицу подстановки), делаем RTP пакет с тем пейлоадом из семплов и отправляем по UDP. Ничего особо ресурсоемкого там нет. Если SRTP требуется - ну блин, берем криптографическую либу какую-то, по RFC реализуем то что надо (можно подсматривать в готовые реализации, ну типа как там HMAC подписывается, сеансовые ключи генерятся, roll-over counter https://tools.ietf.org/html/rfc3711#section-3.3.1 и прочая такая фигня). Фишка этого Embox видимо в том, чтоб вот просто взять что-то готовое (PJSIP), взять значительно более жирный контроллер, чтоб скомпенсировать всякий оверхед от лишних абстракций, как-то это портировать по-быстрому и заставить работать. Если взять обычную типичную программу под Linux на C, она почти наверняка у себя внутри будет дергать malloc. Если эта программа на C++, там еще нужно жирный кусок рантайма обеспечить (RTTI, исключения всякие, ну и хип нужен будет т.к. конструкторы-деструкторы). Если писать чисто под контроллер изначально, держа в голове что тут у нас столько-то ресурсов, и надо вот такой-то конкретный функционал обеспечить, можно вообще обойтись без всякого хипа, чисто на статической памяти
Исправление SZT, :
Киллерфича там в том, что можно малой кровью переносить приложения из Linux на контроллеры, там они какой-то слой позикс-совместимости реализовали. https://www.youtube.com/watch?v=5YcwnoVKu5M - доклад на эту тему
Кому-то это может очень нужно, но вот лично мне это не требуется. Ну и оверхеда многовато, https://habr.com/ru/company/embox/blog/431134/ - использовать жирный контроллер STM32F7 для SIP VoIP это явно перебор, VoIP это ж тупо - взяли PCM семплы из кодека, закодировали их в какой-нибудь u-Law (кодирование там тупо через таблицу подстановки), делаем RTP пакет с тем пейлоадом из семплов и отправляем по UDP. Ничего особо ресурсоемкого там нет. Если SRTP требуется - ну блин, берем криптографическую либу какую-то, по RFC реализуем то что надо (можно подсматривать в готовые реализации, ну типа как там HMAC подписывается, сеансовые ключи генерятся, roll-over counter https://tools.ietf.org/html/rfc3711#section-3.3.1 и прочая такая фигня). Фишка этого Embox видимо в том, чтоб вот просто взять что-то готовое (PJSIP), взять значительно более жирный контроллер, чтоб скомпенсировать всякий оверхед от лишних абстракций, как-то это портировать по-быстрому и заставить работать. Если взять обычную типичную программу под Linux на C, она почти наверняка у себя внутри будет дергать malloc. Если эта программа на C++, там еще нужно жирный кусок рантайма обеспечить (RTTI, исключения всякие, ну и хип нужен будет т.к. конструкторы-деструкторы). Если писать чисто под контроллер, можно вообще обойтись без всякого хипа, чисто на статической памяти
Исправление SZT, :
Киллерфича там в том, что можно малой кровью переносить приложения из Linux на контроллеры, там они какой-то слой позикс-совместимости реализовали. https://www.youtube.com/watch?v=5YcwnoVKu5M - доклад на эту тему
Кому-то это может очень нужно, но вот лично мне это не требуется. Ну и оверхеда многовато, https://habr.com/ru/company/embox/blog/431134/ - использовать жирный контроллер STM32F7 для SIP VoIP это явно перебор, VoIP это ж тупо - взяли PCM семплы из кодека, закодировали их в какой-нибудь u-Law (кодирование там тупо через таблицу подстановки), делаем RTP пакет с тем пейлоадом из семплов и отправляем по UDP. Ничего особо ресурсоемкого там нет. Если SRTP требуется - ну блин, берем криптографическую либу какую-то, по RFC реализуем то что надо (можно подсматривать в готовые реализации, ну типа как там HMAC подписывается, сеансовые ключи генерятся, roll-over counter https://tools.ietf.org/html/rfc3711#section-3.3.1 и прочая такая фигня). Фишка этого Embox видимо в том, чтоб вот просто взять что-то готовое (PJSIP), взять значительно более жирный контроллер, чтоб скомпенсировать всякий оверхед от лишних абстракций, как-то это портировать по-быстрому и заставить работать.
Исходная версия SZT, :
Киллерфича там в том, что можно малой кровью переносить приложения из Linux на контроллеры, там они какой-то слой позикс-совместимости реализовали. https://www.youtube.com/watch?v=5YcwnoVKu5M - доклад на эту тему
Кому-то это может очень нужно, но вот лично мне это не требуется. Ну и оверхеда многовато, https://habr.com/ru/company/embox/blog/431134/ - использовать жирный контроллер STM32F7 для SIP VoIP это явно перебор, VoIP это ж тупо - взяли аудиосемплы из кодека, закодировали их в какой-нибудь u-Law, делаем RTP пакет с тем пейлоадом и отправляем по UDP. Если SRTP требуется - ну блин, берем криптографическую либу какую-то, по RFC реализуем то что надо (можно подсматривать в готовые реализации, ну типа как там HMAC подписывается, сеансовые ключи генерятся, roll-over counter https://tools.ietf.org/html/rfc3711#section-3.3.1 и прочая такая фигня). Фишка этого Embox видимо в том, чтоб вот просто взять что-то готовое (PJSIP), взять значительно более жирный контроллер, чтоб скомпенсировать всякий оверхед от лишних абстракций, как-то это портировать по-быстрому и заставить работать.