Comments 40
Значит в M0 эксклюзивного доступа к памяти нет.
Просто он простой) И для большинства задач его хватает.
Почему бы вам не использовать М3, М4 или М7.
Со временем и их добавлю. Просто не было проектов пока домашних, где было бы необходимо что-то выше M0. Но в планах есть M7. Благо понадобится добавить совсем немного.
В М0 есть что то особенное?
Просто нравится максимальная простота) Ясное дело, что выбирать надо под задачу. В прошлом проекте вот (по ссылке в начале статьи), чтобы байтики копировать туда-сюда без математики почти - больше и не нужно. А вот будущий проект планируется с кучей математики внутри, там M7 рассматриваю с double аппаратным.
Все зависит от задачи и подхода. Я тут готовлю интересную статью. Там я одну и ту же задачу решаю 5-ю разными способами. Чисто чтобы показать разницу в ресурсах и производительности.
А про M3 и выше. У них я бы добровольно-принудительно при наличии в чипе MPU бы еще использовал) Тоже дополню, как руки дойдут.
Не. Это уже Embox. Они и сами с этим неплохо справляются. У меня цель "дешево и сердито". Дать минимально нужный от RTOS функционал, стараясь потреблять памяти по-минимуму.
Не тему "крупных" ОС много чего интересного есть. Та же ChibiOS. Так что те, кто хотел, уже нашел. Да и если много flash и хочется крупного, то embox хороший выбор. У них поддержка классная и примеры есть. Я как-то игрался, но меня больше привлекают мелкие микроконтроллеры. Так что тут увы.
Почему же? Просто цели такой не стояло перед этой разработкой. Вот и все. А чем не устраивают предложенные варианты? Они вроде как раз содержат все что вам нужно. Динамические библиотеки, консоль... По сути, почти Linux)
Так можно сделать во FreeRTOS. Вам нужно для этого собрать ваши задачи с флагом "-pie". При том, под Cortex-M0. Как самый младший обратно совместимый. А далее в начало полученного bin файла нужно положить информацию о том, где функция вызова. После этого можно создавать динамически task и ему скармливать функцию из вашего bin. Если нужны внешние зависимости, то можно в экосистеме сделать статическую секцию с указателями на различные функции. И из всех приложений использовать ее.
Если нет желания все это делать самому, то в EMBOX все это есть уже из коробки. Ради этого она и создавалась)
Спрашивал раньше, мне говорили что раньше был запуск с флешки. И если сейчас не работает, то надо просто допилить немного. Далее уже вам к ним) Я чате телеграмма спрашивал.
Просто надо понять, надо ли это делать. Сейчас есть одноплатники примерно за 500 рублей. И там все из коробки. Стоит ли оно того?
Но вот не знаю, правда. Тут нет MMU, значит динамику априори не закладывали. У нас на подобном на новой работе автопилот работает. Там куча матана крутится с приличной частотой. Проблем с производительностью нет, но это пока что) А вообще чипы огонь. Но они все же реального времени. Там даже классные секции есть мелкие чтобы мелкие ОС туда класть. Они без задержек в этом случае работают.
Немного поясню ситуацию.
Начнем с простого, Вы пишите что хотите чтобы код M0,..4,7 запускался, но например M0 это архитектура ARMv6-M а другие это ARMv7-M. Даже набор инструкций другой. Если одна архитектура то могут быть разные реализации плавающей точки (https://habr.com/ru/company/embox/blog/418295/) разные наборы инструкций и так далее.
Теперь о внешних приложениях. Embox можно сконфигурировать как полноценную ОС с изолированными линейными адресными пространствами, но только при наличии MMU. Более того, это направление не особо востребованно, поскольку ниша Embox специализированные устройства, а там известна тредуемая функциональность на помент проектирования. Получается возможность запуска произовльного приложения - просто дыра в безопасности.
На микроконтроллерах, в принципе мы запускаем Qt (и другие приложения) когда приложение и библиотека Qt лежат во внешней памяти а сам Embox во внутренней. То есть при доработке можно сделать вариант, когда одно или несколько приложений будут собраны для конкретной конфигурации Embox, положены во внешний носитель, и могут быть вызвано любое из них.
Если говорить о динамических библиотеках и приложениях, без MMU то тут не много вариантов. Компилируем без линковки и в загрузчик приложений добавляем линкер, который из PIC делает что то конкретное. Ну или добавляем таблицу внешних символов и модифицируем компилятор, чтобы он специальным образом вызывал эти символы. Все варианты, ну скажем имеют свои недостатки и главное особых запросов нет. Я бы в этом случае предложил ucLinux поковырять.
Если говорить о реальных запросах от пользователей то в последнее время спрашивают о возможности перезаписи образа, то есть есть системный загрузчик, который вызвает основной Embox. Ну и было пару запросов, о запуске единственного внешнего приложения.
Начнем с простого, Вы пишите что хотите чтобы код M0,..4,7
приложения (без перекомпиляции) для любого МК (конечно одной архитектуры типа М3, М4, М7)имелась ввиду именно одной архитектуры, с разными без перекомпиляции и так понятно что не возможно.
Если одна архитектура то могут быть разные реализации плавающей точкиПриложение должно проверить наличия сопроцессоров и спец. инструкций, как в х86 архитектуре.
Получается возможность запуска произвольного приложения — просто дыра в безопасности.Ну это из серии не баг, а фитчя. Дайте возможность выбора, а там пользователь уже решит как ему будет лучше(безопаснее).
модифицируем компиляторто есть текущие компиляторы не позволяют решить эту задачу?
Приложение должно проверить наличия сопроцессоров и спец. инструкций, как в х86 архитектуре.
Кому должно? И где вы видели чтобы оно проверяло? Приложение может это делать, например проверить что есть SSE инструкции и установить соотвествующие реализации вызовов, но это в сильно крутых приложениях. Обычно просто компилируют с минимальными требованиями. Благо SSE сейчас есть на всех современных процах.
Ну это из серии не баг, а фитчя. Дайте возможность выбора, а там пользователь уже решит как ему будет лучше(безопаснее).
Я и говорю, пользователи понимали что это дыра в безопасности. Ну или им намекали, что если они могут загружать любой код, то и другие смогут это сделать.
то есть текущие компиляторы не позволяют решить эту задачу?
Прочитайте пожалуйста мой комментарий.
И главное, поймите пожалуйста, ничего бесплатно не бывает. Если Вам кажется что реализовать это легко, реализуйте, я лишь говорил, что это возможно но трудно требует сущетсвенных затрат и лично я не вижу оснований чтобы этим заниматься, поскольку запросов таких нет, ну или за это не готовы платить.
это возможно но трудно требует существенных затрат
запросов таких нетЗначит это возможно, но никому не нужно кроме меня. Правильно я вас понял?
Нет не правильно.
Это возможно, но очень сложно. Настолько сложно, что одного желания, чтобы этим заниматься, недостаточно.
С другой стороны, Embox открытый и свободный проект, если Вам интересно причем настолько, что Вы готовы этим заниматься, мы всегда рады оказать посильную поддержку.
если Вам интересно причем настолькоНеужели Вам не интересно? Представьте что есть такая ОС которая запускается мгновенно и полностью разделяет программную и аппаратную составляющие, при этом программы независимы и защищены друг от друга, и общение между ними и аппаратурой осуществляется только по правилам ОС через её API. Это как ардуино, только в её лучшем виде. Неужели это ни кому не нужно?
Чем круче ос, тем больше она жрет и нужно более мощное железо, чтобы это сгладить. Моя текущая ОС может дать фору в производительности FreeRTOS-у, но лишь потому, что проще. ОС, что вы опишете, не факт, что будет сильно быстрее целого Linux ядра. А последнее можно настроить с минимальными надстройками и запустить на чипе дешевле, чем многие "мощные" микроконтроллеры. Так же не стоит забывать, что сейчас есть много SoC, внутри которых есть нормальный процессор Cortex-A, а так же куча периферии и памяти внутри. И формально, у вас 1 кристалл (хоть и довольно крупный), на котором сразу все есть. И памяти мегабайт 128, и ram, мегебайт 32. Все есть. И Linux стартует сразу из коробки. И тут уже отпадает всякое желание натягивать сову на глобус.
Все же напомню главное в разработке. Для каждого проекта свое решение. Пихать одно решение всюду (как Arduino), далеко не всегда оправдано. А иногда и вредно.
Все же напомню главное в разработке. Для каждого проекта свое решение.Для меня главное в разработке это затраченное время и средства, а если есть возможность сэкономить не потеряв качество, то это оправдано.
Если я правильно Вас понял, то Вы предлагаете другим потретить время и средства, чтобы Вы смогли съэкономить?
К тому же вам уже много раз сказали, что универсальное решение, уступает специализированным.И универсальное решение уже есть ucLinux. Дорабатывайте если необходимо.
Вот у автора получился интересный результат для совсем маленьких систем. Причем попутно предложено пара решений для проблем с которыми мы сталкиваемсяь. и даже рассматриваем аналогичные решения время от времени.
Приведенный вами ардуино не буду критиковать, но отмечу что у них нельзя запускать произвольный код, даже скомпиленный под аржуино. Нужно для задачи перекомпилировать.
универсальное решение, уступает специализированнымне спорю, но возможно цена универсальности окупится меньшим затраченным временем, доп. возможностями и можно оказаться в значительном выигрыше.
у автора получился интересный результатДа, даже интересно в каком направлении будет дальнейшее развитие.
ардуино не буду критиковать, но отмечу что у них нельзя запускать произвольный кодВы меня не так поняли, под ардуино имелось в виду простота и доступность для большой аудитории. По сути у начинающих просто нет другой альтернативы, которая не напугала бы их своей сложностью.
А чем не понравилась, scmRTOS?
Честно, даже не знал о ней. Сейчас почитал документацию, посмотрел код. В принципе, если описание не врет, то интересная ОС. Но увидев ее все равно бы писал свою, потому что:
На C++.
Несколько слоев абстракции. Тяжелее читать. Часть будут убраны компилятором, а вот часть нет.
А если бы писал проект на C++, то для интереса бы глянул.
Ух, ассемблера внутри... страшно)
Заглянул в надежде увидеть сразу терминал внутри, почему то подумалось что он там сразу встроен будет.
Терминал - это вам к Embox) Тут у нас борьба за каждый байт. Сейчас ОС уже прошла испытания временем (месяц устройство на ней проработало стабильно). Далее есть рад замечаний, что будут влиты по окончании тестов. По текущему раскладу удастся высвободит около 300 байт flash на Os, что не мало.
Ну и ассемблера там минимум. И то, только потому, что нет тега, говорящего GCC не трогать push при входе в функцию.
Спасибо за статью! Интересные результаты!
А не думали применить подход Embox, то есть компилировать только нужные части из FreeRTOS? Я имею в виду, у Вас получилось интересное и эффективное решение для определенного класса задач, и на мой взгляд главный недостаток не в меньшей гибкости, а в меньшей отлаженности и протестированности решения. Вы же не просто так сохранили совместимость по API, и если я правильно понял задумку то в идеале вам следует переиспользовать планировщик (может быть аддаптированный) и добавить свои фичи, типа статической инициализации задач.
Кстати, на счет последного и проверки переполнения, правильно ли я понимаю, что за счет статичекой инициализации вы и легко проверяете выход за границы стека. То есть в прерывании вы смотрите на текущую задачу и проверяете что указатель стека находится в ее границах?
А не думали применить подход Embox, то есть компилировать только нужные части из FreeRTOS?
Оставил только ядро, статические методы для регистрации объектов, мутексы и семафоры. Все остальное, что не использовалось, отключил.
а в меньшей отлаженности и протестированности решения
Само собой пока что не могу гарантировать что в ОС нет ошибок. На данный момент ее наработка в проектах безотказно только около 3 дней без остановки. Нужен куда более долгий срок анализа. Также сам код еще нуждается в улучшениях. Сейчас работаю над ними в нерелизной ветви.
Вы же не просто так сохранили совместимость по API, и если я правильно понял задумку то в идеале вам следует переиспользовать планировщик (может быть аддаптированный) и добавить свои фичи, типа статической инициализации задач.
Оставил для того, чтобы можно было легче переходить с одной на другую. Я не позиционирую свою, как заметили в личных сообщениях, "всрат-ос" (название оставлю, будет как PIDORA, запоминающимся) как замена FreeRTOS. Это скорее выход из положения, когда осознаешь, что не влез, а партия на руках.
А теперь насчет расширения ядра... Честно, FreeRTOS страшный. Я много лет смотрю на него. И это обилие ifdef убивает. Я пару раз делал его порты под мало кому известные архитектуры. Местами просто под давно уже мертвые... И достаточно насмотрелся на ее код. Но это не отменяет ее главного достойнства. FreeRTOS - работает. Если конечно настроена верна.
Кстати, на счет последного и проверки переполнения, правильно ли я понимаю, что за счет статичекой инициализации вы и легко проверяете выход за границы стека. То есть в прерывании вы смотрите на текущую задачу и проверяете что указатель стека находится в ее границах?
Да. Именно так. И, забыл написать в статье. Напишу тут. Есть киллер фича. Вы можете разместить основную структуру ОС в RTC регистрах у микроконтроллера. Тогда ее 100% никто не перепишет и если упадете, то 100% будете знать, где именно. Не обязательно RTC регистры. Куда угодно, где есть 4 32-х битных слова быстро изменяемой памяти.
Very simple real time operating system: что это и зачем нужно?