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

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

тоже так хочу

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

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

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

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

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

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

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

тоже так хочу

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

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

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

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

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

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

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

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

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

А тебя за это не посадят?

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

Киллерфичи?

А тебя за это не посадят?

Вряд ли, ведь я в Харькове

Киллерфича там в том, что можно малой кровью переносить приложения из 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, исключения всякие, ну и хип нужен будет т.к. конструкторы-деструкторы). Если писать чисто под контроллер изначально, держа в голове что тут у нас столько-то ресурсов, и надо вот такой-то конкретный функционал обеспечить, можно вообще обойтись без всякого хипа, чисто на статической памяти

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

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

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 засунуть, чем все это переписывать на что-то менее жрущее.

Qt может запускаться вообще без ОС

ждем Qt-процессоры которые сразу QML исполняют

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

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

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

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

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

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

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

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

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

Да и Linux есть, очень старый.

https://repo.or.cz/linux/elbrus.git

У грядущего 2С3 потребление будет 10Вт. Для автомобилей не сойдет, но на этом уже можно будет непрожорливый ноутбук. Не в тему Embox конечно.

У грядущего 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

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

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

Интересно, на каких еще архитектурах такие выверты нужны?

На любых где стеки подобным образом защищены, очевидно же.

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

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

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

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

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

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

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

Киллерфичи?

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

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

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

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

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

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

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

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

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

Да, сорян, наверное и правда что-то перепутал.

Ну и оверхеда многовато, 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 избычен

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

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

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

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

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

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

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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Embox в деле

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

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

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

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

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

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

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

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

Вы совершенно правы, вопрос только в сложности функционала который можно таким образом разработать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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