LINUX.ORG.RU

Embox v0.4.3 Released

 , , ,


2

3

1 сентября состоялся релиз 0.4.3 свободной, распространяемой под лицензией BSD, ОС реального времени для встраиваемых систем Embox:

Изменения:

  • Улучшения в системе сборки
    • Переключились на использование абсолютных имен
    • Добавлена папка ‘project’ для проектов
    • Добавлена возможность подключать проекты из сторонних репозиториев и папок вне проекта
    • Начата работа над подсистемой ‘device tree’
  • Улучшена поддержка STM32
    • Добавлена поддержка cache для STM32F7
    • Драйвер uart переведен на ‘device tree’
    • Почищены порты для f4 & f7 серий
    • Библиотеки Cube переключены на версии с github
    • Добавлена поддержка UDC (usb device controller)
  • Улучшена поддержка RISC-V
    • Добавлена поддержка платы ‘MAiX BiT’
    • Улучшена подсистема таймеров
    • Улучшена 64-битная версия
    • Улучшена подсистема прерываний
  • Улучшена подсистема USB-gadget
  • Улучшена графическая подсистема
  • Улучшена поддержка библиотеки Qt4
  • Улучшена поддержка библиотеки OpenCV
  • Множество других улучшений и исправлений

>>> Подробности

А что там с эльбрусами? Его безопасный режим так и просится в эмбедщину и роботов. У вас вообще система может работать без виртуальной памяти и прочих таких вещей?

Улучшена поддкржка библиотеки Qt4 Улучшена поддкржка

тоже так хочу

uin ★★★ ()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от uin

А что там с эльбрусами

Эльбрусы поддержаны с виртуальной памятью (мепирование один к одному, но нужна для задания атрибутов страниц памяти (кеширование не кеширование). В коде все это есть, можно воспроизвести при наличии эльбруса. Мы проверяли на Моноблоке.

Его безопасный режим так и просится в эмбедщину и роботов.

Возможно, они действительно хорошо подходят для ряда задач, обработка сигналов числодробилки и так далее, но они конечно очень прожорливые.

У вас вообще система может работать без виртуальной памяти и прочих таких вещей? Да, прекласно запускаем Qt и OpenCV на микроконтроллерах, в которых как Вы понимаете нет виртуальной памяти.

По поводу эльбрусовского безопасного режима, наверное имеется в виду тэгированая память. Очень интересная концепция, но пока не очевидно кому это нужно! к тому же Эльбрусы имеют довольно закрытую экосистему и сферу применения. Нам стоило больших трудов сделать поддержку этой архитектуры у себя, ведь практически отсуствует документация.

Улучшена поддкржка библиотеки Qt4 Улучшена поддкржка

тоже так хочу

Спасибо, поправил!:)

abondarev ()
Ответ на: комментарий от SZT

Даже MMU и MPU часто нафиг не нужны

MMU да, порой добавляет проблем. Но MPU с одной стороны достаточно легкий с точки зрения аппаратуры, а с другой порой позволяет несколько упростить разработку, например, отслеживание переполнения стека или обращение не в ту память.

abondarev ()
Ответ на: комментарий от abondarev

к тому же Эльбрусы имеют довольно закрытую экосистему и сферу применения. Нам стоило больших трудов сделать поддержку этой архитектуры у себя, ведь практически отсуствует документация.

Там вроде документацию на инструкции недавно выкладывали http://elbrus.ru/efficient_elbrus_programming_book_2020-05

Ну и еще могу скинуть исходники бинутилсов с добавленной поддержкой эльбруса

SZT ★★★★ ()
Ответ на: комментарий от wandrien

Киллерфича там в том, что можно малой кровью переносить приложения из 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 ★★★★ ()
Последнее исправление: SZT (всего исправлений: 3)
Ответ на: комментарий от SZT

Киллерфича там в том, что можно малой кровью переносить приложения из Linux на контроллеры

Ещё есть NuttX и RTEMS (QT для девайсов на нем изначально запускалась).

shkolnick-kun ★★★★ ()
Последнее исправление: shkolnick-kun (всего исправлений: 1)
Ответ на: комментарий от shkolnick-kun

Qt может запускаться вообще без ОС: https://www.qt.io/product/develop-software-microcontrollers-mcu

Qt for MCUs is a complete graphics framework and toolkit with everything you need to design, develop, and deploy GUIs on MCUs. Run your application on bare metal or a real-time operating system.

Ну лично я для себя в этом смысла не вижу. Это конечно может быть как-нибудь оправдано если есть какой-то готовый код на Qt и экономически и/или по времязатратам выгодней использовать более жирный контроллер и туда этот Qt засунуть, чем все это переписывать на что-то менее жрущее.

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от anonymous

Судя по современным тенденциям, нас ждут скорее JS-процессоры. (хотя QML как раз на JS и основан и при этом JS там вызывыать можно https://doc.qt.io/qt-5/qtqml-javascript-expressions.html)

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 2)
Ответ на: комментарий от cvs-255

Зависит от нюансов

Он имеет полное право. Ведь binutils - GPL. И мцст не вправе запрещать распространять исходники

…при условии, что эти исходники (или бинарники) ему передали без нарушения закона.

Если я пропатчил binutils и пользуюсь ими индивидуально, не распространяя их, то кража их с моего личного компа — нарушение закона.

Передача программы в пределах одного юрлица не является распространением программы от лица к лицу в трактовке GPL и не попадает под условия GPL.

wandrien ()
Ответ на: комментарий от SZT

Нет, не просится. Даже MMU и MPU часто нафиг не нужны

Ну для какого нибудь станка или терминала - да
А вот какое нибудь беспилотное такси или робот курьер подключенные к интернету, тут одно из двух - либо корячить тяжелую практически десктопную ОС с пользователями, правами, виртуальной памятью программ и всем соответствующим железом. Либо взять особое железо которое аппаратно не позволяет никаким программам за границы выделенной им памяти ходить и сделать легкую встраиваемую ос даже для таких систем, которые общаются с внешним миром.

uin ★★★ ()
Ответ на: комментарий от a1batross

У грядущего 2С3 потребление будет 10Вт. Для автомобилей не сойдет

чего ? причем тут ватты, там рабочие температуры важны

https://en.wikipedia.org/wiki/Operating_temperature

Для примера серия процессоров i.mx8 старшие модели специально для автопрома спроектированы

https://www.toradex.com/community/questions/38070/power-consumption-of-the-apalis-imx8.html

The Power Consumption of Apalis iMX8 can be in worst case 15-20W

anonymous ()
Ответ на: комментарий от a1batross

Да, забавно конечно, что у них longjmp в пространстве ядра реализуется https://repo.or.cz/linux/elbrus.git/blob/HEAD:/arch/e2k/kernel/signal.c#l1404

Это все оттого, что стек там это не обычная память, которую так просто можно взять и поменять. Интересно, на каких еще архитектурах такие выверты нужны?

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от uin

Ну вот хотелось бы про такие архитектуры узнать. Где это еще надо просить ядро ОС, работающее в привилегированном режиме, чтобы оно переставило стекпоинтер куда-то?

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от SZT

Там вроде документацию на инструкции недавно выкладывали

Ага, спасибо, видели. Но мы то раньше это делали. Думаю мы даже внесли свой посильный вклад в открытие и популяризацию данной платформы:) И конечно даже в этой документации далеко не все хорошо и полно описано, я имею в виду с точки зрения системного программирования. Я бы даже предложил в дополнение к этой документации ознакомиться с нашими статьями

Ну и еще могу скинуть исходники бинутилсов с добавленной поддержкой эльбруса

О, поздравляю! Вы таки добились исходников :) Нам они особо не нужны, так нет информации о прерываниях переключении контекстов и остального, можно попытаться вытащить как правильно работать со стеками, но для нас этого не достаточно. Но спасибо за предложение!

P.S. Спасибо за issue :)

abondarev ()
Ответ на: комментарий от wandrien

Из каких соображений потребовалось делать еще одну RTOS, а не использовать и дорабатывать существующие?

Киллерфичи?

Как уже отметили, киллерфичей является возможность практически бесплатного использования ПО под Linux в системах где его использование:

  • не возможно
  • не требуется (избыточно)
  • не позволено

Пример Линукс ПО на микроконтроллерах Конечно скорее всего можно разработать ПО любой сложности и с нуля поскольку стандартное не влезет для микроконроллеров, но вопрос в стоимости, времени, сложности разработки, количестве ошибок и так далее.

Embox же предлагает отладить свое ПО на Линуксе что очень удобно, а затем поместить на целевую платформу.

abondarev ()
Ответ на: комментарий от abondarev

О, поздравляю! Вы таки добились исходников :)

Ну я их не от МЦСТ добился, мне их i-rinat скинул. Где он их взял - понятия не имею.

Нам они особо не нужны, так нет информации о прерываниях переключении контекстов и остального, можно попытаться вытащить как правильно работать со стеками, но для нас этого не достаточно.

Ну те исходники могут быть полезны кому-то, кто будет JIT реализовывать свой, по ним можно понять алгоритм кодирования конкретных инструкций, хотя это можно и без исходников отреверсить.

Ну а по поводу стеков - можно исходники ядра Linux посмотреть, ссылку выше скинули.

SZT ★★★★ ()
Ответ на: комментарий от SZT

Ну и оверхеда многовато, https://habr.com/ru/company/embox/blog/431134/ - использовать жирный контроллер STM32F7 для SIP VoIP это явно перебор

Не соглашусь с Вами, конечно есть еще версия для [STM32F4 https://habr.com/ru/company/embox/blog/259721/], но не в этом суть. SIP телефон должен уметь не только передать пакеты (в обе стороны) но и реализовывать SIP то есть сигнальный протокол, в принципе и его можно реализовать, и файловую систему и так далее, и даже взять планировщик из какого нибудь FreeRTOS (пакеты то должны быть синхронизированы по времени + между собой (ввод/вывод) Но когда Вы все это сделаете, есть сомнения что требования по ресурсам получатся уж сильно меньше. Например, Вам же нужно где то хранить буфера для сетевых пакетов, буфера для аудио, ну и стеки (про минимум два потока я написал), ну и другие вещи.

Фишка этого Embox видимо в том, чтоб вот просто взять что-то готовое (PJSIP), взять значительно более жирный контроллер, чтоб скомпенсировать всякий оверхед от лишних абстракций, как-то это портировать по-быстрому и заставить работать.

С фишкой согласен, а вот с оверхедом нет, можно же рассматривать и с той точки зрения, что не требуется брать полноценный одноплатник с 512 МГб на борту, который потребляет много и еще не понятно с температурными режимами, а ограничится пусть мощьным но все же микроконтроллером.

Если взять обычную типичную программу под Linux на C, она почти наверняка у себя внутри будет дергать malloc. Если эта программа на C++, там еще нужно жирный кусок рантайма обеспечить (RTTI, исключения всякие, ну и хип нужен будет т.к. конструкторы-деструкторы). Если писать чисто под контроллер изначально, держа в голове что тут у нас столько-то ресурсов, и надо вот такой-то конкретный функционал обеспечить, можно вообще обойтись без всякого хипа, чисто на статической памяти

Ну мы то запускаем большое ПО, так что как то это работает. А вот если переписывать функционал для конкретного микроконтроллера (платформы) то стоимость и количество ошибок, на мой взгляд будет не радовать. Я имею в виду конечно не мигание светодиодом, для таких задач Embox избычен

abondarev ()
Ответ на: комментарий от shkolnick-kun

Ещё есть NuttX и RTEMS (QT для девайсов на нем изначально запускалась).

Согласен, у NuttX очень близкая идея, просто шли разными путями.

RTEMS ну так он только Qt с одним приложением может делать, то есть есть POSIX прослойка, но у нас гораздо больше возможностей по переносу приложений

abondarev ()
Ответ на: комментарий от SZT

Ну лично я для себя в этом смысла не вижу. Это конечно может быть как-нибудь оправдано если есть какой-то готовый код на Qt и экономически и/или по времязатратам выгодней использовать более жирный контроллер и туда этот Qt засунуть, чем все это переписывать на что-то менее жрущее.

Фишка в том, что не нужно под каждое устройство писать код. Ну а контроллеры сейчас довольно жирными могут быть

abondarev ()
Ответ на: комментарий от uin

А вот какое нибудь беспилотное такси или робот курьер подключенные к интернету, тут одно из двух - либо корячить тяжелую практически десктопную ОС с пользователями, правами, виртуальной памятью программ и всем соответствующим железом. Либо взять особое железо которое аппаратно не позволяет никаким программам за границы выделенной им памяти ходить и сделать легкую встраиваемую ос даже для таких систем, которые общаются с внешним миром.

Собственно Embox и есть легкая встраиваемая ОС:)

abondarev ()
Ответ на: комментарий от SZT

Да почитай уже что нибудь https://habr.com/ru/post/328542/
еще где то была статья или видео про интел 432
идея древняя как мир. То что современные ядроразрабы и ты про нее не знаете, проблема исключительно вашей недалекости.

uin ★★★ ()
Ответ на: комментарий от abondarev

SIP телефон должен уметь не только передать пакеты (в обе стороны) но и реализовывать SIP то есть сигнальный протокол, в принципе и его можно реализовать, и файловую систему и так далее, и даже взять планировщик из какого нибудь FreeRTOS (пакеты то должны быть синхронизированы по времени + между собой (ввод/вывод) Но когда Вы все это сделаете, есть сомнения что требования по ресурсам получатся уж сильно меньше.

Как раз получится сильно меньше почти наверняка.

Из того что я вижу, чтоб тот же PJSIP работал, ему нужно обеспечить динамическую память чтоб он дергал malloc(), ему нужна файловая система (зачем? Чтоб он с нее читал какие-то конфиги? А почему б просто не в флеше хранить?), нужны какие-то позикс-совметимые вызовы для мьютексов, нужно сделать какой-то совместимый с этим PJSIP интерфейс для звука (в вашем случае там portaudio)... да дофига всего надо, и всё это надо чисто чтоб обеспечить совместимость, т.е. если писать с нуля, можно обойтись без malloc, без поддержки ФС, без позикс-совместимых мьютексов, взаимодействие с звуковым кодеком можно реализовать в каком-нибудь очень минималистичном стиле. Т.е. флеш-памяти в контроллере точно нужно сильно больше, просто чтоб создать условия для работы этого PJSIP без серьезных переделок.

SZT ★★★★ ()
Ответ на: комментарий от abondarev

Вообще, когда стоит задача отладить по на линуксе перед тем, как в мк пихать, можно поступить как я: всю целевую логику реализовать в виде библиотеки, не завязанной на железо. А затем сделать пару оберток для запуска из линукса и на целевой платформе

cvs-255 ★★★★★ ()
Ответ на: комментарий от uin

Я не про конкретно идею с тегированной памятью, я про «где еще надо просить ядро ОС для выполнения longjmp?». Если на какой-то архитектуре память тегированная, это еще совершенно не означает, что для перестановки стекпоинтера надо непременно просить ядро ОС

SZT ★★★★ ()

Улучшена поддержка библиотеки Qt4

А gtk? Ведь внешний вид gtk3 по-умолчанию как раз в сторону сенсорных экранчиков поменяли. Да и с Си попроще должно быть.

gag ★★★★★ ()
Ответ на: комментарий от SZT

Если на какой-то архитектуре память тегированная, это еще совершенно не означает, что для перестановки стекпоинтера надо непременно просить ядро ОС

То есть ты считаешь что теги и вот это вот все можно тупо так же подменить не на уровне ядра. Тогда это петушиные какие-то теги получаются.

uin ★★★ ()
Ответ на: комментарий от gag

Ведь внешний вид gtk3 по-умолчанию как раз в сторону сенсорных экранчиков поменяли.

О да. Всегда мечтал парсить CSS на микроконтроллёре, чтобы нарисовать две кнопки.

Впрочем, и qt5 тоже не фонтан.

wandrien ()

Embox в деле

Что такое в контексте Embox project, platform и template? Чем они отличаются?

PS. Очень скудная документация на Embox, чтобы что-то сделать, нужно много догадываться и разбираться с её исходниками. Хотелось бы полноценной документации и обучающих материалов на различные темы: от того, как создать свой проект, и до, как портировать на свою систему.

EvAn ()
Ответ на: комментарий от uin

То есть ты считаешь что теги и вот это вот все можно тупо так же подменить не на уровне ядра.

Какое отношение теги имеют к setjmp/longjmp? Почему наличие этих тегов должно мешать делать setjmp/longjmp в юзерспейсе?

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от wandrien

но всё же возникает вопрос, почему это должна быть именно RTOS, а не библиотека для существующей RTOS, например.

Не очень понял вопроса. Что значит библиотека для существующей RTOS, Вы имеете в виду что, для RTEMS написать слой POSIX совместимости? Но он там уже есть. Правда это не позволяет запускать Linux ПО, на данной ОС.

Вопрос в том что ядро переконфигурируется под конкретную задачу. Приложений может быть при этом много, но устройство решает конкретную задачу, то есть имеет ограниченный функционал, и ядро уже настраивается под этот функционал, просто библиотекой тут не обойтись, если бы можно было так поступить, конечно это было бы добавлено во все RTOS. Идея то как Вы сами отметили, прикольная.

abondarev ()
Ответ на: комментарий от abondarev

Ну все таки gtk больше для десктопов, как не меняй внешний вид все равно через чур жирно будет

Ну так тот же Qt по жирноте тоже из той же категории

Можете видео https://youtu.be/EIoBvWTzkTY посмотреть, ну вот все эти плавные анимации и прочие спецэффекты.

SZT ★★★★ ()
Ответ на: Embox в деле от EvAn

Что такое в контексте Embox project, platform и template? Чем они отличаются?

template - это набор конфигураций, то есть когда делается make confload-<что то> берется из этой папки

platform хотели сделать папки с темплейтами и кодом для конкретных платформ, но что то пошло не так, и там мешанина. Недавно чтобы улучшить ситуацию добавили project - предполагается перенести туда всякие Qt, OpenCV, и так далее. То есть не специфичные для платформы а именно для проектов вещи. Но этот процесс пока только начат. Добавили в этой версии. Так же как возможность использовать закрытые репозитории.

PS. Очень скудная документация на Embox, чтобы что-то сделать, нужно много догадываться и разбираться с её исходниками. Хотелось бы полноценной документации и обучающих материалов на различные темы: от того, как создать свой проект, и до, как портировать на свою систему.

Да согласен, мы работаем в данном направлении, но к сожалению идет медленно :(

В принципе начальная документация есть тут. Русская версия мануала позволяет понять как собрать добавить свои приложения и так далее

abondarev ()
Ответ на: комментарий от SZT

Ну так тот же Qt по жирноте тоже из той же категории

Согласен Но у нас были конкретные запросы и заказчики, которые имели код на Qt, а вот c gtk никто серьезно не спрашивал

abondarev ()
Ответ на: комментарий от cvs-255

При грамотной архитектуре приложения не вижу проблем

Ну да, если писать хороший код, то нет проблем. Интересно откуда только проблемы берутся, чего людям просто хороший, не содержащий ошибок код, то не пишется. Просто наверное потому, что вредные:)

abondarev ()
Ответ на: комментарий от abondarev

Если при написании программы с самого начала разделяется целевая логика и аппаратно зависимые вещи - то проблем не будет

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)