Comments 26
Зацепила фраза «Основная идея Embox — прозрачный запуск Linux программного обеспечения везде, в том числе и на микроконтроллерах.»
Поясните, что имелось в виду?
Поясните, что имелось в виду?
Берем обычное приложение Qt компилируем его в составе Embox выкинув все лишнее и умещаемся внутрь микроконтроллера.
Ну или тоже самое с PJSIP или OpenCV.
На самом деле, разработка и отладка под Линукс гораздо удобнее чем под микроконтроллеры. Это экономит очень большое количество времени и нервов. Мы скоро несколько статьей напишем по данному вопросу. Пока что написали небольшую статью на эту тему
Ну или тоже самое с PJSIP или OpenCV.
На самом деле, разработка и отладка под Линукс гораздо удобнее чем под микроконтроллеры. Это экономит очень большое количество времени и нервов. Мы скоро несколько статьей напишем по данному вопросу. Пока что написали небольшую статью на эту тему
Сколько ресурсов забрала сама Embox?
Точно не замеряли. Но исходя из того что есть всего 2 kB один из которых идет на стек, сколько то еще тратится на сами данные BSP. то получается несколько сотен байт. Скажем 512. Половина это данные для трех легких потоков. Один основной, один для таймеров и еще для обработки GPIO как кнопки по прерываниям
Так есть ли смысл использовать Embox на таких мелких контроллерах?
А какие МК вы бы рекомендовали для использования с Embox?
А какие МК вы бы рекомендовали для использования с Embox?
Полностью согласен. Так и написал в заключении:
В принципе достаточно хорошо уже начинает сказываться на stm32vl-discovery (128кб RAM). А на каком нибудь stm32f4-discovery (196 кб) вообще удается много чего запустить.
Но все конечно должно исходить не от аппаратной платформы, а от задачи. Чем больший функционал требуется тем лучше проявляются преимущества
Конечно, данный пример во многом искусственный. Ведь при столь ограниченных ресурсах и функциональность будет ограниченной. Преимущества Embox начинают сказываться на более мощных платформах. Но в то же время это можно считать предельным случаем работы Embox.
А какие МК вы бы рекомендовали для использования с Embox?
В принципе достаточно хорошо уже начинает сказываться на stm32vl-discovery (128кб RAM). А на каком нибудь stm32f4-discovery (196 кб) вообще удается много чего запустить.
Но все конечно должно исходить не от аппаратной платформы, а от задачи. Чем больший функционал требуется тем лучше проявляются преимущества
Чем больший функционал требуется тем лучше проявляются преимущества
А по сравнению с FreeRTOS или другой подобной ОС, удастся ли получить какие-нибудь отличительные преимущества?
Конечно, об преимуществах я и говорю.
В Embox можно использовать готовый софт из Linux или разработать его не на плате в на хосте со всеми удобствами. А потом легким движением руки перенести его на целевую платформу.
Повторюсь, если вам потребовался функционал OpenCV, у вас есть две возможности, долго разрабоатывать свой непереносимый код на небольшой плате или взять и быстро запустить OpenCV на Linux на большой плате. Embox позволяет достаточно быстро запустить на небольшой и надежной платформе.
В Embox можно использовать готовый софт из Linux или разработать его не на плате в на хосте со всеми удобствами. А потом легким движением руки перенести его на целевую платформу.
«Основная идея Embox — прозрачный запуск Linux программного обеспечения везде, в том числе и на микроконтроллерах.»
Повторюсь, если вам потребовался функционал OpenCV, у вас есть две возможности, долго разрабоатывать свой непереносимый код на небольшой плате или взять и быстро запустить OpenCV на Linux на большой плате. Embox позволяет достаточно быстро запустить на небольшой и надежной платформе.
Что мешает разрабатывать только библиотеки типа OpenCV (и т.п.) для уже популярных и зарекомендовавших себя ОС для МК? В чём преимущества самой Embox как ОС?
Что мешает разрабатывать только библиотеки типа OpenCV (и т.п.) для уже популярных и зарекомендовавших себя ОС для МК?
Ничто не мешает.
В чём преимущества самой Embox как ОС?
Не понимаю в чем вопрос, поясните пожалуйста. Приведите пример преимущества которое есть на Ваш взгляд у любой популярной ОС для МК.
Я даже не говорю, что Embox это не ОС для МК («в том числе для МК» это не значит, что она только для МК). И, что преимуществом является сам факт того, что OpenCV не нужно разработывать под эту ОС, а можно просто взять готовое и отлаженное решение. Просто хотелось бы понять, в чем по вашему мнению преимущества FreeRTOS или любой другой RTOS на ваш выбор?
Просто интересно наблюдать за проектом. Так что извините за назойливость, нахожусь в поиске «идеальной» ОС для МК.
нахожусь в поиске «идеальной» ОС для МК
Не так давно делал доклад на конференции OSDAY под названием «Какая она идеальная ОС для встроенных систем?». Вроде на сайте есть трансляция.
Я не сказал, что Embox эта самая идеальная ОС. Сказал что идеальной не существует, но в Embox были учтены многие особенности подобных систем и мы стараемся удовлетворять потребности разработчиков. Для МК критична экономия ресурсов, собственно все RTOS ориентированны на этот параметр. У нас изначально был другой стимул мы старались обеспечить только требуемую функциональность в Linux (немного в статье «Многообразный мир embedded systems и место Embox в нем» ), но в результате удалось добиться приведенных в данной статье результатов.
По поводу идеальности Embox для МК скажу так. все зависит от задачи, но Embox позволяет оторваться от ОС. То есть надоел Embox, запустили на другой ОС. Большинство RTOS, как Вы сами правильно заметили, заставляют разрабатывать под конкретную ОС. И выбор той или иной ОС это дело вкуса и привычки конкретного разработчика.
Что мешает разрабатывать только библиотеки типа OpenCV (и т.п.) для уже популярных и зарекомендовавших себя ОС для МК? В чём преимущества самой Embox как ОС?Как я понял вся идея в том, чтобы не разрабатывать или портировать библиотеки, а брать готовые для Linux и лёгким движением руки перекомпилировать под МК.
А если писать свои библиотеки, то отлаживать их в Linux намного проще, а потом практически готовое решение скормить Embox. Как по мне — очень интересная идея. Поправьте если ошибся.
Вы абсолютно правы. Спасибо!
Хотел узнать, почему для внедрения в МК линух библиотек потребовалось создавать целую ОС, почему бы не направить силы в развитие уже готовых и просто снабдить их этим функционалом?
Потому что это невозможно. Архитектура, точнее даже подход или идеалогия, не позволяет добавить подобные возможности в FreeRTOS и аналаги. Там можно добавить POSIX слой, но это не позволит запускать как отдельные приложения. Аналогично с Linux, да, он модульный, но все равно ядро будет монолитное и весить минимум несколько мегабайт. Да есть попытки приблизить RT-Linux, uCLinux, но идеалогия другая. Требуется предусмотреть эти возможности и заложить их в архитектуру.
Собственно идея не нова, мы предлагаем один из подходов, который показывает хорошие результаты. Есть и другие eCos, NuttX, если говорить о RTOS. Или zephyr который использует близкий к линуксовому devtree.
Собственно идея не нова, мы предлагаем один из подходов, который показывает хорошие результаты. Есть и другие eCos, NuttX, если говорить о RTOS. Или zephyr который использует близкий к линуксовому devtree.
Забавно и интересно. Давно присматривался к Вашеу ОС. Думаю попробовать на stm32l010 в домашнем проекте. Как раз BSP написал для периферии. Думал снова FreeRTOS, а для потоков сильно жирно. Все же у меня 8 кб RAM на все.
Спасибо!
Если если возникнут вопросы обращайтесь, будем рады помочь.
Да, согласен, для 8кб использование полноценных потоков со стеком может быть избыточно. В конце концов один стек всегда присуствует на нем можно и многозадачночь организовать.
Если если возникнут вопросы обращайтесь, будем рады помочь.
Да, согласен, для 8кб использование полноценных потоков со стеком может быть избыточно. В конце концов один стек всегда присуствует на нем можно и многозадачночь организовать.
Сейчас читаю описание на вики. Как вообще начать. Просто статьи уровня «А сейчас мы поднимим embox на блюпилке с нуля» я не увидел. Буду по статьям и вики собирать по крупицам. Или есть другой путь и я чего-то не увидел?
Прост ооткрыл git, а там сплошные make-филе. Аж поплохело сначало) Но вот сейчас читаю что да как. Пока интересно.
А насчет в одном потоке. Мне посути и сопраграмм бы хватило для текущего проекта от FreeRTOS. Но они их забросили. Увы.
Прост ооткрыл git, а там сплошные make-филе. Аж поплохело сначало) Но вот сейчас читаю что да как. Пока интересно.
А насчет в одном потоке. Мне посути и сопраграмм бы хватило для текущего проекта от FreeRTOS. Но они их забросили. Увы.
Есть вот такая страница для STM-ок
На счет документации, да с этим есть некоторые сложности. Я бы кстати начал с русской документации отсюда, лучше ее собрать, последняя релизная версия содежит исправленных ряд опечаток.
Начал бы я все таки с запуска на qemu, есть например stellaris тоже в близкой конфигурации. Затем наверное взял бы ближайшую STM-ку например stm32vl-discovery (тоже кб) и на ее основе создал бы конфигурацию.
Да к сожалению пока таких нет, приходится по шагам входить в проект :(
На счет документации, да с этим есть некоторые сложности. Я бы кстати начал с русской документации отсюда, лучше ее собрать, последняя релизная версия содежит исправленных ряд опечаток.
Начал бы я все таки с запуска на qemu, есть например stellaris тоже в близкой конфигурации. Затем наверное взял бы ближайшую STM-ку например stm32vl-discovery (тоже кб) и на ее основе создал бы конфигурацию.
Просто статьи уровня «А сейчас мы поднимим embox на блюпилке с нуля» я не увидел.
Да к сожалению пока таких нет, приходится по шагам входить в проект :(
Прочитал документацию. Запустил в QEMU. Потыкал в загруз. Есть такой перечень вопросов. В документации как-то не увидел:
В омщем-то концпция интересная. Но документации очень мало. Это отталкивает. То есть непонятно. Вот у меня есть железка. Я на нее хочу эту ОС. Что я получу? Аналог FreeRTOS где нет возможность (предположительно) отлаживать утилиту причем запускать можно только одину утилиту в единый момент врмени без демонов и autoexec файла, или полноценный аналог Linux уровня QNX +-.
Это, если что, не наезд и не обвинение. Просто информации мало и хотелось бы узнать, как обстоят дела. Про модульность и прочее я слышал. Кстати. вроде где-то писали, что для этой ОС можно запускать утилиты отдельно собранные с micro-sd например. Ну я слышал такое. Утверждать не могу. Вот интересно было бы развеять все мифы и в итоге получить какой-то FAQ.
- Можно ли запускать несколько приложений разом? Как в этом случае идет распределение памяти?
- Если приложений запустить можно много, то через что они будут взаимодействовать между собой? Ресурс менеджер как в QNX каком-то или как?
- Как отлаживать конкретное приложение в составе образа этой системы? Возможно ли это вообще? Про отладку что-то как-то мало накопал. Не туда сомтрел может.
- Есть ли возможность отлаживать отдельное приложение через ETH/GDB удаленно в составе работающей системы?
- Использует ли ОС runtime библиотеку? Типа newlib. Очень хотелось бы, чтобы такого не было.
- Есть ли какая-то интерграция с cmake? Вот FreeRTOS можно собирать как часть проекта и отлаживать отдельно потоки. А тут как с этим?
В омщем-то концпция интересная. Но документации очень мало. Это отталкивает. То есть непонятно. Вот у меня есть железка. Я на нее хочу эту ОС. Что я получу? Аналог FreeRTOS где нет возможность (предположительно) отлаживать утилиту причем запускать можно только одину утилиту в единый момент врмени без демонов и autoexec файла, или полноценный аналог Linux уровня QNX +-.
Это, если что, не наезд и не обвинение. Просто информации мало и хотелось бы узнать, как обстоят дела. Про модульность и прочее я слышал. Кстати. вроде где-то писали, что для этой ОС можно запускать утилиты отдельно собранные с micro-sd например. Ну я слышал такое. Утверждать не могу. Вот интересно было бы развеять все мифы и в итоге получить какой-то FAQ.
Тоже хотелось бы услышать ответы на эти вопросы, т.к. полноценной ОС для МК найти так и не удалось. У всех одно приложение за запуск. По сути все «ОС» для МК это такой фреймворк который лишь предаёт прошивке дополнительный ряд возможностей (квазипараллельные потоки, общий API, и т.д.). А так же возникает вопрос — нужна ли полноценная ОС для МК (пусть даже для ARM Cotrex M)? Или это только я один задаюсь этим вопросом? Иначе уже кто-нибудь бы да и сделал.
Тоже хотелось бы услышать ответы на эти вопросы, т.к. полноценной ОС для МК найти так и не удалось. У всех одно приложение за запуск. По сути все «ОС» для МК это такой фреймворк который лишь предаёт прошивке дополнительный ряд возможностей (квазипараллельные потоки, общий API, и т.д.).
Тогда Вам нужен как раз Embox.
А так же возникает вопрос — нужна ли полноценная ОС для МК (пусть даже для ARM Cotrex M)? Или это только я один задаюсь этим вопросом? Иначе уже кто-нибудь бы да и сделал.
Нет, не Вы один. uCLinux пример реализации полноценного Linux на системах без MMU (МК). Не случайно на STM32F7 есть порты этой системы.
Можно ли запускать несколько приложений разом? Как в этом случае идет распределение памяти?
Да, конечно. Стандартные темплейты /qemu (arm/qemu) по умолчанию стартуют с кучей вяких сервисов которые крутятся парраллельно. Можно зайти телнетом на адрес 10.0.2.16 и параллельно открыть тот же адрес в браузере. Распределения памяти могут быть разными, зависит от конфигурации, но если это именно несколько приложений (команд), то нужно ставить что то типа kernel.task.multi. и у каждого приложения (задачи) будет как минимум один полноценный поток со стеком, плюс другие ресурсы, индексные дескрипторы, адресное пространство и так далее. Все эти вещи настраиваются. Запустить из консоли можно с помощью команды service (service telnetd) или пожно также добавить & (telnetd &). Можно воспользоваться вызовами vfork exec.
Если приложений запустить можно много, то через что они будут взаимодействовать между собой? Ресурс менеджер как в QNX каком-то или как?
Обычно они взаимодействуют через POSIX, например pipes sockets итак далее. Но в принципе можно настройками делать общее адрессное пространство и в принципе даже дергать вызовы из общих библиотек. Хотя это и не приветсвуется, все на совести разработчика.
Как отлаживать конкретное приложение в составе образа этой системы? Возможно ли это вообще? Про отладку что-то как-то мало накопал. Не туда сомтрел может.
Отладка это обычный gdb. Вроде там все можно сделать. Точку останова можно поставить и в конкретном приложении. А то что при этом еще будет доступна иннформация о ядре и можно получить информацию о других частях системы обычно не мешает, а лишь помогает. У нас есть в планах разработка gdb сервера, чтобы запускать его отдельно в окружении как на линукс, но пока острой необходимости в этом небыло, делаем в фоне. Причем приложение, очень часто отлаживается на Linux и легко и не пренужденно переносится на тот же микроконтроллер. Немного об этом в статье про SIP телефон. Причем, если на EFM32 это скорее странное применение Embox, то вот это прямо преимущества в полный рост. Разработка функционала заняла 2 дня.
Есть ли возможность отлаживать отдельное приложение через ETH/GDB удаленно в составе работающей системы?
Пока нет, но как и сказал выше, думаем добавить. Если наберется достаточное количество запросов, поставим в приоритет и следаем за пару недель.
Использует ли ОС runtime библиотеку? Типа newlib. Очень хотелось бы, чтобы такого не было.
Уточните пожалуйста, имеется в виду стандартная библиотека Си или рантайм для C++. Просто для Си обычно не говорять про рантайм. Стандартная библиотека С своя. Это вынужденная мера, поскольку тащить всю библиотку слишком накладно. То есть она есть но ее можно отключить, можно использовать только нужные части и указать требуемые параметры. И да, все исходники также доступны. То есть в конечный образ включается только требуемый код и данные. Например в данном образе доступны стандарные stdin, stdout, stderr, jони занимают каждый порядка 40 байт и их можно было выкинуть, но раз влезло я етого делать не стал.
О рантайм С++ мы скоро опубликуем статью и да там будет затрагиваться newlib
Есть ли какая-то интерграция с cmake? Вот FreeRTOS можно собирать как часть проекта и отлаживать отдельно потоки. А тут как с этим?
Уточните пожалуйста. У нас есть механизм использования сторонних проектов целиком, в том числе и на cmake. Но обычно мы собиарем этот проект в составе Embox, не он линкуется. Было один раз, но я считаю это изврат. А отлаживать отдельную утилиту можно на Linux
Но документации очень мало. Это отталкивает.
Да, согласен. Мы стараемся исправить ситуацию.
То есть непонятно. Вот у меня есть железка. Я на нее хочу эту ОС. Что я получу? Аналог FreeRTOS где нет возможность (предположительно) отлаживать утилиту причем запускать можно только одину утилиту в единый момент врмени без демонов и autoexec файла, или полноценный аналог Linux уровня QNX +-.
Embox точно не замена FreeRTOS. Мы говорим что это Linux без Linux. То есть стремимся сделать так чтобы это был Linux без нескольких присущих ему недостатков.
- Большое количество исходников
- Относительно большое количество ресурсов
- Трудности в реальным временем.
Написали об этом в статье Многообразный мир Embedded и место Embox в нем
Это кстати, самый важный на мой взгляд вопрос. Ведь просто созадавать очередную ОС не имеет смысла.
Кстати. вроде где-то писали, что для этой ОС можно запускать утилиты отдельно собранные с micro-sd например.
Да, отдельные приложения мы запускали. Такую конфигурацию также можно создать. Но не уверен что сейчас это работает. Преимущества в другом и соотвественно основные (наиболее часто используемые ) режимы работы тоже другие
Это, если что, не наезд и не обвинение. Просто информации мало и хотелось бы узнать, как обстоят дела.
Да, все нормально. Спасибо за интерес к проекту. Надеюсь немного прояснил ситуацию.
Кстати, возможно будет удобнее в русском телеграм чате (https://t.me/embox_chat), там есть другие разработчики и пользователи и возможно реакция будет более оперативной и полной.
Да, отдельные приложения мы запускали. Такую конфигурацию также можно создать.
А можно поподробнее, как это примерно выглядит. Есть возможность создавать исполняемые файлы (типа exe как у windows)?
Есть возможность создавать исполняемые файлы
Скорее можно задать такие параметры системы, что это сделается возможным. Ну а дальше два варианта для внешних приложений, либо загрузчик который будет линковать по свободным адресам, либо полная изоляция пространства процесса через MMU. Вообще это очень широкая тема даже в одну статью не уложишь.
Но повторюсь, Embox предназначен (эффективен) в специализированных системах, а не уриверсальных. Например, если можно вызвать прилетевшее приложение, то снижается уровень безопасности системы. В нашем подходе подразумечается, что можно задать сколь угодно сложную и функциональную систему с каким угодно количеством приложений задач и так далее, но проверку парамметров вынести на этап проектирования.
Sign up to leave a comment.
Embox на плате EFM32ZG_STK3200. Как уместить RTOS в 4кБ ОЗУ