Комментарии 26
Не понял все же в чем заключается упрощение.
Не хватает сравнения, как этот процесс мог бы выглядеть на другой RTOS.
Не хватает сравнения, как этот процесс мог бы выглядеть на другой RTOS.
Хм, ну тут сложно проводить сравнение. Ведь в случае с RTOS ами обычно просто делается новая библиотека под конкретную платформу, ну или берется уже написаная и самостоятельно прикручивается. При этом все обычно происходит на целевой платформе. В случае с Linux дистрибутивом берем и устанавливаем нужные пакеты. В случае с Linux в виде yocto project и аналогов, составляем рецепты которые компиляруют файловую систему в статике. Разрабатывать конечно можно на обычном хосте. Вот последний вариант иблизок к Embox. Но при этом конечно все ядро не нужно тащить и мы влезаем в несколько киллобайт. как написано встатье про EFM
Но почему разработка на Linux-е рассматривается как некое упрощение?
Фактически же делается двойная работа.
Сначала делается симуляция на линуксе и для этого делаются cgi скрипты ( которые тоже надо отлаживать), а потом все равно надо все отлаживать на целевой платформе.
Есть же STM32CubeMonitor, быстрый STLink, симуляторы прямо в IDE под STM и прочие средства делающие разработку и отладку на платформе STM быстрой и удобной.
Фактически же делается двойная работа.
Сначала делается симуляция на линуксе и для этого делаются cgi скрипты ( которые тоже надо отлаживать), а потом все равно надо все отлаживать на целевой платформе.
Есть же STM32CubeMonitor, быстрый STLink, симуляторы прямо в IDE под STM и прочие средства делающие разработку и отладку на платформе STM быстрой и удобной.
Не понял где двойная работа? Запустили на хосте один раз, а на плате заработало. Чем сложнее функциональность тем больше выгода. Конечно если речь идет о мигании светодиодом, то выгода сомнительная. Но даже в этом урезанном примере, есть файловая система, сеть, потоки, веб сайт и так далее. При этом на плате вообще не отлаживалось ничего, просто запустилось!
Запустили на хосте один раз, а на плате заработало.
Вот в это я и не верю.
Сколько раз я соединялся по modbus с промышленными контроллерами это всегда был челендж. 90% времени уходит на исследование проблем коммуникации.
Поскольку отсутствует исчерпывающая документация. О какой симуляции в линуксе может идти речь?
А если вы применили modbus для соединения одного своего дивайса с другим, то это исскуственный пример. Это история не про реальный modbus, а про то как сотворили оверхед. Т.е. по любому выполнили лишнюю работу.
Я даже не верю что линуксовые либы вообще можно использовать на STM32 без хитроумных рефакторингов, поскольку на STM самый дефицитный ресурс RAM, а в линуксе безоглядно используют heap. Да даже ограничения на стек заставляют стократно перепроверять все линуксовые сорсы чтобы не дай бог там не надумали делать массивы на стеке или списки со строками в автоматических переменных. Эт я еще не упомянул ретаргетинг С-ишных функций.
Тот же libmodbus вы должны были проверить на фрагментацию и исчерпание кучи, поскольку там вовсю используют malloc. Т.е. либо вы нам не рассказали о том как вы симмулируете фрагментацию на линуксе, либо вы не можете утвержадать что ваше приложение рабочее, поскольку не отлаживали его на целевой платформе.
Вот если в линуксовой либе специально указывают что она годная для embedded, то это другой разговор. Сам с удовольствием использую различные парсеры, интерпретаторы, протоколы из линукса. Но для этого не требуется сам линукс. Это лишний компонент.
Вот в это я и не верю.
Верить или не верить это личное право каждого человека!
Но не понимаю, что вас смущает? Вы например верите, что можете разработать ПО (с тем же libmodbus) на хосте (x86) и запустить на малине, без каких то изменений (пересобрать понятно прийдется)?
Сколько раз я соединялся по modbus с промышленными контроллерами это всегда был челендж. 90% времени уходит на исследование проблем коммуникации.
Может в этом проблема? Я не потрицаю что есть нюансы связанные с аппаратурой, но 90 % времени от всей задачи. Конечно не останется ни на какую бизнес логику.
А если вы применили modbus для соединения одного своего дивайса с другим, то это исскуственный пример. Это история не про реальный modbus, а про то как сотворили оверхед. Т.е. по любому выполнили лишнюю работу.
Пример естественно упрощенный, для лучшего понимания самого процесса разработки. Но оврхеда, как и лишней работы, не вижу. Вижу что не пришлось разбираться в тонкостях modbus. Уверен что там есть тонкие места, которые потребуют времени и тщательного изучения вопроса. Ну да, еще естественно, остльное ПО, включая драйвера, которые имеют стандартный интерфейс, один раз разработал, потом используешь, нашел огибку правишь в общем месте.
Я даже не верю что линуксовые либы вообще можно использовать на STM32 без хитроумных рефакторингов, поскольку на STM самый дефицитный ресурс RAM, а в линуксе безоглядно используют heap.
Вот не пойму, о чем вы говорите. Посмотрите в нашем блоге, куча софта запущено на STM32 без изменений Первое же (https://habr.com/ru/company/embox/blog/538416/). Или посмотрите особенности запуска плюсовх приложений. Я к тому что это делается, не скажу что это легко, но Embox автоматизировал этот процесс и с ним это делать быстро и просто.
Тот же libmodbus вы должны были проверить на фрагментацию и исчерпание кучи, поскольку там вовсю используют malloc. Т.е. либо вы нам не рассказали о том как вы симмулируете фрагментацию на линуксе, либо вы не можете утвержадать что ваше приложение рабочее, поскольку не отлаживали его на целевой платформе.
Опять к сожалению не понял. Вы имеете в виду проффелирование распределения памяти? Но это опять же гораздо легче делать со средствами на хосте. Смотрите уже упомянутую статью
Вот если в линуксовой либе специально указывают что она годная для embedded, то это другой разговор. Сам с удовольствием использую различные парсеры, интерпретаторы, протоколы из линукса. Но для этого не требуется сам линукс. Это лишний компонент.
То есть если в libmodbus появится надпись что можно запускать на STM32 с помощью Embox. Вы будете использовать Embox, или саму библиотеку?
В общем повторюсь, Ваше право использовать то что Вы считаете правильным! Мы лишь предлагаем подход. Попробовать его, использовать или нет, это ваше решение. Наш взгляд с немного другого ракурса. Для меня например, удивительно когда люди 90 % времени на разработку тратят на аппаратуру, на функционал, понятно остается очень мало времени.
То есть если в libmodbus появится надпись что можно запускать на STM32 с помощью Embox. Вы будете использовать Embox, или саму библиотеку?
Точно, если такая надпись будет, то это будет верный сигнал о возможности легкого переноса библиотеки на любую RTOS.
А пока вы не показали как на линуксе вычислили минимальный размер heap для этой библиотеки.
Да я вижу что вы немало времени провели над анализом расхода памяти в симуляциях под линуксом. Это говорит о том что проблему прекрасно понимаете и сорсы вы все таки дорабатываете. Либо вынуждены брать чипы с большим объемом памяти.
Но на целевой платформе эти тестовые прогоны в любом случае точнее. Поскольку они учитывают и расход памяти низкоуровневым слоем работы с периферией. Уж периферию то никак в линуксе просимулировать не удастся.
Конечно если вы эти статьи пишете для самого себя с целью само убеждения, то понять можно.
Но вроде как посыл был в утверждении превосходства вашего метода.
Так вот фактов превосходства представлено не было на мой взгляд.
Это говорит о том что проблему прекрасно понимаете
Ну хотя бы проблему понимаю, троечку поставите ?:)
Да я вижу что вы немало времени провели над анализом расхода памяти в симуляциях под линуксом
а где Вы видете что немало времени?
и сорсы вы все таки дорабатываете
А это откуда Вы взяли?
Но на целевой платформе эти тестовые прогоны в любом случае точнее.
С чего это вдруг? Точнее конечно, это правда если сравнивать x86 64 разряда и 32 битную версию, но если распределяется память одинакового размера, то вообще непонятно, откуда возьмется разница.
Поскольку они учитывают и расход памяти низкоуровневым слоем работы с периферией. Уж периферию то никак в линуксе просимулировать не удастся.
Не понял о чем все таки Вы. куча это куча, пулы в драйверах это пулы. То есть это принципиально разные памяти. В одном случае мы используем Линукс. Как я и сказал, там гораздо более развитые профайлеры и отладчики. Во втором случае, это уже относится к разработке драйверов и там нужен свой учет памяти. Например в Embox можно задать количество сетевых пакетов, которые будут выделяться из специального пула
Конечно если вы эти статьи пишете для самого себя с целью само убеждения, то понять можно.
С целью самоубеждения, я могу писать что угодно, но публиковать при этом не нужно :)
Но вроде как посыл был в утверждении превосходства вашего метода.
Так вот фактов превосходства представлено не было на мой взгляд.
Все то Вам кажется, Вы во что то верите или не верите…
Не смущает что Вы видете где то какую то попытку и при этом говорите что не видете фактов этой попытки?
Так вот никакого превосходства нет, так же как и серебрянной пули. Все зависит от ситуации и задачи. В статье предложен не превосходный а отличный метод. Для каких то случаев он позволяет упростить разработку, для каких то нет. Для ваших задач (90% сложности аппаратная часть) сомневаюсь что наш подход следует применять. 90% сложности бизнес логика, вот тут следует подумать.
Контроль за кучей стоит делать сразу в приложении на целевой платформе.
Тогда не надо будет мучится в симуляторах под линуксом.
Мучится — это потому что такой процесс требует времени и создания симуляции реальных условий.
Опять же кучу лучше сделать единой для всего, и для драйверов периферии и для верхнего уровня, так буде более экономно.
Словом ну ничего не способствует портированию линуксовых библиотек на STM32.
Как косвенное доказательство — отсутствие таких библиотек в STM32Cube.
Тогда не надо будет мучится в симуляторах под линуксом.
Мучится — это потому что такой процесс требует времени и создания симуляции реальных условий.
Опять же кучу лучше сделать единой для всего, и для драйверов периферии и для верхнего уровня, так буде более экономно.
Словом ну ничего не способствует портированию линуксовых библиотек на STM32.
Как косвенное доказательство — отсутствие таких библиотек в STM32Cube.
Контроль за кучей стоит делать сразу в приложении на целевой платформе.
Тогда не надо будет мучится в симуляторах под линуксом.
Мучится — это потому что такой процесс требует времени и создания симуляции реальных условий.
Где у нас симуляция для профилирования кучи? Не пойму кто вообще мущается? Мы на Линуксе, точно нет. Там все обычно, никаких мучений. Может Вы мучаетесь на целевой платформе? В это верю, там все гораздо сложнее.
Опять же кучу лучше сделать единой для всего, и для драйверов периферии и для верхнего уровня, так буде более экономно.
что значит более экономично? А как на счет более надежно? А как на счет более быстро? А как, хотя все таки более экономично? То есть Вы устверждаете, что если в системе есть ряд объектов с известными свойствами (одного размера) то более экономично поместить их в общую кучу? Вы что то там говорили про фрагментируемость…
Ну и да никто не отменяет всякие нюансы по памяти, например кешируемость регионов см статью
Ну и да, добавим еще разные шины и памяти в микроконтроллерах, наличие DMA.
Словом ну ничего не способствует портированию линуксовых библиотек на STM32.
Embox вроде способствует, делая этот процесс значительно проще :)
Как косвенное доказательство — отсутствие таких библиотек в STM32Cube.
Как прямое докозательство — наличие порта ucLinux
Как прямое доказательство — появление серии STM32MP1
Значительно проще все делает только значительное количество RAM.
Кстати я посмотрел ваш репозитарий проекта Embox.
Во-первых там черт ногу сломает, какая-то масса непонятных названий директорий сторонних опенсорсных проектов даже косвенно не намекающих зачем они нужны.
Во-вторых, действительно важные и мощные проекты типа SQLite, каких-то скриптовых движков, компрессоров и т.д. отлично портируются сразу на embedded платформу без линукса и симуляций.
То что действительно можно смело без привязки к аппаратуре симулировать — GUI. Для STM32 есть не менее 3-х прекрасных библиотек с которыми идут их демо платы, и они имеют адаптеры симуляции под Windows, но не под линукс. QT потрированный на STM32 по сравнению с ними мягко говоря бледнеет.
С другой стороны я не понял как можно компилировать библиотеку libmodbus под линукс и быть уверенным что она так же заработает на STM если у компиляторов разный retargeting
Как например выводить диагностические, отладочные, аварийные сообщения и куда?
Сколько они еще заберут стека, а сколько займут процессорного времени?
Вопросы риторические.
Кстати я посмотрел ваш репозитарий проекта Embox.
Во-первых там черт ногу сломает, какая-то масса непонятных названий директорий сторонних опенсорсных проектов даже косвенно не намекающих зачем они нужны.
Во-вторых, действительно важные и мощные проекты типа SQLite, каких-то скриптовых движков, компрессоров и т.д. отлично портируются сразу на embedded платформу без линукса и симуляций.
То что действительно можно смело без привязки к аппаратуре симулировать — GUI. Для STM32 есть не менее 3-х прекрасных библиотек с которыми идут их демо платы, и они имеют адаптеры симуляции под Windows, но не под линукс. QT потрированный на STM32 по сравнению с ними мягко говоря бледнеет.
С другой стороны я не понял как можно компилировать библиотеку libmodbus под линукс и быть уверенным что она так же заработает на STM если у компиляторов разный retargeting
Как например выводить диагностические, отладочные, аварийные сообщения и куда?
Сколько они еще заберут стека, а сколько займут процессорного времени?
Вопросы риторические.
Значительно проще все делает только значительное количество RAM.
Не понял
по вашему мы каким то магическим образом увеличиваем объем памяти?
Или вы имеете в виду что на хосте памяти больше по этому и проще, такя и говорю, те вещи которые можно сделать на хосте, проще делать на хосте.
Кстати я посмотрел ваш репозитарий проекта Embox.
Зачем? Ну не нравится Вам идея, ну пройдите мимо. Зачем убеждать нас что мы не правы?
Во-первых там черт ногу сломает, какая-то масса непонятных названий директорий сторонних опенсорсных проектов даже косвенно не намекающих зачем они нужны.
В том то и проблема, вопрос, зачем вы полезли туда, если хотели найти что то непонятное, то и нашли. Если бы вам было бы что то нужно, ну скажем, есть ПО под линукс, и вам нужно запустить его под микроконтроллер, или запустить в реалтайм окружении, или еще по каким то реальным задачам. Вы бы попытались найти то что нужно.
Во-вторых, действительно важные и мощные проекты типа SQLite, каких-то скриптовых движков, компрессоров и т.д. отлично портируются сразу на embedded платформу без линукса и симуляций.
То есть Вы таки нашли, важные и нужные части? Почему Вы считаете, что какие то вещи нужны для embedded а какие то фигня, только загрязняющая репозиторий?
Что то есть сомнения на счет отлично портируются. В нашем то случае портировать не нужно,
./configure; make; make install. Да, конечно это в том случае если есть возможность, если ПО написано так что требуется 16 мб стек, то наверное его не стоит запускать на МК, ну или действительно аддаптировать.То что действительно можно смело без привязки к аппаратуре симулировать — GUI. Для STM32 есть не менее 3-х прекрасных библиотек с которыми идут их демо платы, и они имеют адаптеры симуляции под Windows, но не под линукс. QT потрированный на STM32 по сравнению с ними мягко говоря бледнеет.
Как Вы все таки непонятно выражаетесь.
Ну есть 3 библиотеки под STM, мы позволяем использовать lvgl nuklear, qt. То есть у разработчика увеличивается выбор. Но главное никакой симуляции, ничего не нужно портироватью Запускается под ЛИнукс, на QEMU (можно например ARM) и уходит 90 % проблемб остальные 10% да приходится отлаживать на плате. Но только 10 %. И повторюсь, если у вас задачи, заключающиеся в настройке аппаратуры, например опрос какого то датчика, то врядли вам нужна оптимизация работы. Берем ардуино и вперед.
С другой стороны я не понял как можно компилировать библиотеку libmodbus под линукс и быть уверенным что она так же заработает на STM если у компиляторов разный retargeting
В нашей жизни ни в чем нельзя быть уверенным. Речь о том что уверенности становится существенно больше.
Как например выводить диагностические, отладочные, аварийные сообщения и куда?
Что значит куда? Они как в линуксе выводятся куда указывают stdin stdout stderr. Куда направите туда и выведется, можете зайти по телнету и запустить ваше приложение, вывод будет у вас в консоли.
Сколько они еще заберут стека, а сколько займут процессорного времени?Столько сколько написано…
Вопросы риторические.
так зачем вы их задаете?
Зачем вы тратите время на доказательство что наш подход ошибочен? Повторюсь ситуации могут быть разные, и если вам такой подход не улучшает жизнь, то не нужно на это тратить время
Что значит куда? Они как в линуксе выводятся куда указывают stdin stdout stderr. Куда направите туда и выведется, можете зайти по телнету и запустить ваше приложение, вывод будет у вас в консоли.
Понятно.
Т.е. вы сразу какое бы простенькое приложение ни было всегда неявно требуете наличие TCP стека, файловой системы и операционной системы.
Потому что все должно сработать как в линуксе.
Оверхед доказан?
Лезу я в ваш репозитарий потому что вы сами предлагаете в него лезть. Для чего тогда все эти статьи?
Ок, я залез. Там пусто. Предлагается видимо идти в места расположения оригинальных пакетов. Но все что есть для этого — это какие-то невнятные аббревиатуры, даже минимальных подсказок нет. Спрашивается зачем такое выкладывать и пиарить? Где демки на этих проектах, доказавающие работоспособность?
Скажем из тройки lvgl nuklear, qt достоин внимания только lvgl.
Но он одинаково трудно портируется что под линукс что под windows. Там надо писать драйвер и под Chrom-ART там конечно драйвера нет!
Т.е. отсутствие преимущества доказано?
Ну и не забывайте что эти коменты читает весь интернет.
От того как вы отвечаете зависит в какой-то мере успешность вашего пиара.
Я же просто хочу отделить рациональные вещи от чисто субъективных предпочтений.
По сути диалог и заходит в область сравнения (которого вашей статье так не хватает) что есть в линуксе для embedded и что есть в RTOS растущих от железа.
Понятно.
Т.е. вы сразу какое бы простенькое приложение ни было всегда неявно требуете наличие TCP стека, файловой системы и операционной системы.
Потому что все должно сработать как в линуксе.
Оверхед доказан?
Что вам понятно. В каком месте что то доказано, о каком Оверхеде вы горорите? Подобными комментариями вы доказываете только что вообще не понимаете о чем говорите!
Как по вашему Embox запускается с 4кб RAM? См. статью, где там оверхед?
Лезу я в ваш репозитарий потому что вы сами предлагаете в него лезть. Для чего тогда все эти статьи?
В который раз говорю, статьи не для вас, а для тех у кого возникают похожие проблемы и ситуации. И мы не предлагаем лезть в репозиторий, а не запрещаем. Да хотим чтобы использовали, но если вам не нужно, то зачем вы лезете куда не понимаете?
Ок, я залез. Там пусто. Предлагается видимо идти в места расположения оригинальных пакетов. Но все что есть для этого — это какие-то невнятные аббревиатуры, даже минимальных подсказок нет. Спрашивается зачем такое выкладывать и пиарить? Где демки на этих проектах, доказавающие работоспособность?
простите, а вы не того, будете мне говорить, что мне выкладывать а что нет?
Ну и не забывайте что эти коменты читает весь интернет.
От того как вы отвечаете зависит в какой-то мере успешность вашего пиара.
Вашу ж мать, при чем тут пиар? Мы сделали что то, рассказали миру, не хотите не пользуйтесь.
Я же просто хочу отделить рациональные вещи от чисто субъективных предпочтений.
А вот об этом вас никто не просил. Вы высказали мнение, что это не нужно, но из аргументов привели только, «я так не делаю». Даже не посмотрели, что ниже, ктото написал, что симулирует на Linux а потом переносит на FreeRTOS (без Embox). Кто то очень хорошо описал, что Linux не следит за временами и так далее.
То есть повторюсь, никто вас не приглашал арбитром или экзаминатором. Мир слегка многообразнее чем вам кажется. И если в вашей работе таких проблем нет, то не факт что их вообще нет.
Скажем из тройки lvgl nuklear, qt достоин внимания только lvgl.
И не вам решать кто достоин внимания а кто нет!
НЛО прилетело и опубликовало эту надпись здесь
1. Modbus, если делать его прям очень правильно и в полном соответствии со стандартами
По сути дела, статья о том, что хотя я и не очень силен в modbus, я взял и запустил, устройство с его использованием. На Linux куча готового ПО на все случаи жизни. При этом вы правильно заметили, что в отличие от Linux у нас легко можно обеспечить требуемые тайминги, ведь можно забраться прямо в ядро и установить жесткие приоритеты для потоков.
интересно было бы посмотреть на реализацию.
Это к сожалению выходит за рамки статьи, сделать точно можно!
2. Если у нас Modbus RTU на RS-485 с «тупым» конвертером, управляемым по RTS — поддерживается ли такое на уровне ОС (драйвера UART)? В Linux такое легко делается с помощью ioctl c TIOCSRS485.
Опять же легко можно добавить, и да конкретно TIOCSRS485 не поддерживается, но прокидывали различные ioctl, для различных драйверов, поскольку сам механизм есть.
Ведь мы по сути дела, взяли готовый модуль, разработали бизнес логику на Linux используя при этом несколько приложений. И запустили все это на нашей целевой платформе. Тем самым существенно упростив и ускорив саму разработку.Я тоже сперва разрабатываю под Linux, а потом уже отлаженный код разработанного класса приложения запускаю на целевой платформе под FreeRTOS.
И для этого Embox не нужен.
> Я тоже сперва разрабатываю под Linux, а потом уже отлаженный код разработанного класса приложения запускаю на целевой платформе под FreeRTOS.
Как у Вас это получается?
Ваше право. :)
Как у Вас это получается?
Embox не нужен.
Ваше право. :)
Цитируйте пожалуйста правильно без передергивания и изменения контекста.
А уже после отладки основной логики на микроконтроллере запускается отлаженный код в потоках FreeRTOS под STM32CubeIDE.
Таким способом получается очень легко разделять бизнес логику и аппаратно-зависимую часть кода и значительно ускорить процесс разработки.
И для этого Embox не нужен.Под Linux я разрабатывают приложение в виде одного или нескольких классов + тесты и ответные части интерфейсов (если они есть). Если планируется задействовать специфические особенности аппаратуры, тогда под Linux реализуется только интерфейс с заглушкой.
А уже после отладки основной логики на микроконтроллере запускается отлаженный код в потоках FreeRTOS под STM32CubeIDE.
Таким способом получается очень легко разделять бизнес логику и аппаратно-зависимую часть кода и значительно ускорить процесс разработки.
Цитируйте пожалуйста правильно без передергивания и изменения контекста.
Извините, не правильно понял контекст. Просто порой поражают люди которые говорят, что что то не нужно, потому что лично они это делают по другому.
Под Linux я разрабатывают приложение в виде одного или нескольких классов + тесты и ответные части интерфейсов (если они есть). Если планируется задействовать специфические особенности аппаратуры, тогда под Linux реализуется только интерфейс с заглушкой.
Таким способом получается очень легко разделять бизнес логику и аппаратно-зависимую часть кода и значительно ускорить процесс разработки.
Да, по сути дела, в статье описан похожий процесс. И даже больше. Например, как Вам удастся под FreeRTOS использовать приведенную в статье библиотеку? Она как минимум POSIX требует.
А уже после отладки основной логики на микроконтроллере запускается отлаженный код в потоках FreeRTOS под STM32CubeIDE.
Ну и запускать отлаженный код в потоках FreeRTOS, если я правильно понимаю, то нужно модифицировать код или что то куда то копировать. В случае Embox запускается несколько процессов на Linux, и для запуска на микроконтроллере нужно добавить Mybuild файл, простой описанный в статье. И еще хочу обратить внимание, используется строняя библиотека их может быть много. В случае с Embox Вы по сути дела делаете
./configure; make; make install; опять же в статье описано. То есть у вас потенциально огромная отлаженная кодовая база. А если уж дойдет до отладки, то никто не мешает точно также отлаживать с помощью любого IDE на микроконтроллере вот например Eclipse или у нас в чате t.me/embox_chat, любят VSCode. Мы gdb обычно используем.Вы рассматриваете разработку для микроконтроллера не с того ракурса. Какие сторонние библиотеки, которых «может быть много», какие процессы Linux, если вы делаете прошивку, например для STM32F1хх? Да там флеша для памяти программ может быть меньше, чем стек на Linux машине.
Вы рассматриваете разработку для микроконтроллера не с того ракурса
Простите, что значит не с того? Допускаю что наш ракурс, отличается от вашего, но это не значит что он не тот
Какие сторонние библиотеки, которых «может быть много», какие процессы Linux, если вы делаете прошивку, например для STM32F1хх? Да там флеша для памяти программ может быть меньше, чем стек на Linux машине.
Поясню ракурс.
Он заключается в том, что смотреть не со стороны микроконтроллера который уже лежит на твоем столе. А со стороны функционала, которым должно обладать устройство. И от функционала уже идет выбор какую аппаратную платформу положить на стол. Если вам нужен экран с разрешением 1024x768 с хотя бы 8 битной цветностью, странно будет смотреть на STM32F1 без дополнительной памяти.
При этом Embox позволяет уменьшить накладные рассходы. Уже приводит эту статью, но (конечно без линуксового ПО) но Embox запускается на efm32_zero
Допускаю что наш ракурс, отличается от вашего, но это не значит что он не тотСогласен.
Просто у меня при упоминании про микроконтроллер, внимание акцентируется на первой части слова. Поэтому считаю важным разрабатывать код под любую элементную базу, а не только для самой производительной серии.
Вы же не будете какой нибудь миниатюрный автономный датчик делать с цветным экраном? Либо вам придется шаманить, как в упомянутой выше статье про efm32_zero.
Просто у меня при упоминании про микроконтроллер, внимание акцентируется на первой части слова. Поэтому считаю важным разрабатывать код под любую элементную базу, а не только для самой производительной серии.
Да, но с моей точки знания, микроконтроллер всего лишь средство, то есть слово разработка важнее. Почему пишем микроконтроллер как раз для того, что на них все сохраняется. И не нужно разрабатывать как то специально. Естественно, всегда нужно заботиться о качестве вашего ПО, и стараться уменьшить его требования.
Вы же не будете какой нибудь миниатюрный автономный датчик делать с цветным экраном? Либо вам придется шаманить, как в упомянутой выше статье про efm32_zero.
Нет конечно, все стандатно. Разработчик заботиться только об отрисовки, (Другой о драйверах ) И может использовать различные библиотеки. Qt, LVGL и так далее. В статье с EFM прямо написано, это из разряда «смотри как я могу»
Как у нас написано
Embox main idea is using Linux software everywhere includes MCUs
На самом деле стоит читать без Linux. Просто у него ну очень хорошая кодовая база. так и напрашивается чтобы ее использовали :)
И кстати, по поводу экранов на микроконтроллерах вот статья про это
Опять же можно читать без микроконтроллеров, но что удивительного в обычных цветных экранах :)
Но параметры, по которым порой предлагают сравнение, лично меня повергают в легкое недоумение. Например, сколько нужно памяти для работы Embox? А какое время переключения между задачами?
А почему Вас повергают в недоумение вполне логичные вопросы по весьма важным для микроконтроллерных RtOS параметрам? :)
А почему Вас повергают в недоумение вполне логичные вопросы по весьма важным для микроконтроллерных RtOS параметрам? :)
Возможно потому, что Embox не только для микроконтроллеров. И как было выше в комментах, что ставить во главу угла. Мы ставим разработку, и считаем что микроконтроллер, только хорошая платворма для решения определенного класcа задач.
Ну а на конкретно приведенные вопросы, ответ такой, что вам даст количество тактов в контекст свитче, и вообще версию с какими характеристиками вам нужно использовать. А насколько у вас загружена система (сколько в ней крутиться задачи и вообще функциональности), это касается и времени реакции и количества необходимой памяти. На счет памяти в статье показано насколько малым можно сделать потребления памяти если использовать Embox. Но не это главное.
В общем я постарался рассказать об этих сомнительных вопросах в статье «RTOS или не RTOS вот в чем вопрос». А в статье постарался объяснить, что вам нужен Embox если проектируется система с приличной функциональностью и при этом затруднено использвование Linux.
Тенденция использования взрослого ПО и процессов разработки налицо, NuttX Zephyr… Но мы прошли по этому пути значительно дальше
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Добавляем modbus в Embox RTOS и используем на STM32 и не только