Comments 65
А бывают архитектуры, когда RTOS является в некотором смысле гипервизором для OS более высокого уровня?
Тогда получается что основная функциональность (например, управление клапаном) будет находится на уровне RTOS, а свистелки — в OS более высокого уровня
Тогда получается что основная функциональность (например, управление клапаном) будет находится на уровне RTOS, а свистелки — в OS более высокого уровня
янипонил :( В итоге, Embox это RTOS или нет?
Встпуление хорошее, а непосредственно о вашем проекте мало сказано. Давайте продожение :)
для изменения состояния одного пина из пользовательского режима необходимо 3 мсека в Embox?
Встпуление хорошее, а непосредственно о вашем проекте мало сказано. Давайте продожение :)
скорее RTOS, чем нет:)
Embox можно сконфигурировать таким образом, что из прикладных приложений будет фактически прямой доступ к регистрам. Это конечно менее безопасно, но предполагается, что программист знает, что делает. Поэтому у нас можно из tcl скрипта фактически без накладных расходов писать и читать регистры.
Спасибо. Продолжение следует, надеюсь в ближайшем будущем!
Embox можно сконфигурировать таким образом, что из прикладных приложений будет фактически прямой доступ к регистрам. Это конечно менее безопасно, но предполагается, что программист знает, что делает. Поэтому у нас можно из tcl скрипта фактически без накладных расходов писать и читать регистры.
Спасибо. Продолжение следует, надеюсь в ближайшем будущем!
Если можно в регистры, то вероятно и непосредственно в DRAM адреса можно? ;)
Ну да, во все адресное пространство, в том числе и DRAM. Но это конечно если сконфигурировать без MMU и остального.
А есть в плане безопасности в вашей архитектуре между модулем ядра и юзерским процессом?
Странички например с кернелом никто же не мешает попортить.
Странички например с кернелом никто же не мешает попортить.
Планы у нас большие:) Про безопасность в том числе.
На самом деле, у нас есть поддержка MMU, некоторая необходима на некоторых платформах для включения cache. Просто ее можно не включать или настроить трансляцию один к одному. Для небольших устройств мы хотим добавить поддержку MPU, как раз для защиты страниц,
Ну, и как я написал выше, при статической линковке образа, ответственность можно переложить на программиста, ведь он должен осознавать, что он делает. А для многих устройств, которые управляют ножками, алгоритм работы можно описать заранее.
На самом деле, у нас есть поддержка MMU, некоторая необходима на некоторых платформах для включения cache. Просто ее можно не включать или настроить трансляцию один к одному. Для небольших устройств мы хотим добавить поддержку MPU, как раз для защиты страниц,
Ну, и как я написал выше, при статической линковке образа, ответственность можно переложить на программиста, ведь он должен осознавать, что он делает. А для многих устройств, которые управляют ножками, алгоритм работы можно описать заранее.
«The project has been started by few employees of Hardware Engineering Department of Lanit-Tercom, Inc.» — Привет коллегам! Плюсанул вам карму )
Про недостатки FreeRTOS как-то невнятно сказано.
Сейчас во встраиваемых системах хорошо известны как минимум 5-ть операционных систем реального времени (RTOS) способных работать на STM32F407 и ниже с открытыми исходными текстами (хотя и под разными лицензиями).
Это: FreeRTOS, Micrium (uC/OS-II, III), Keil (RTX) она же mbed.org, Freescale MQX, Texas Instruments RTOS
Они все! идут с демонстрационными примерами включающими WEB сервер и работу в интернете по разным протоколам.
Некоторые из них совместимы с POSIX.
Так в чем же смысл Embox?
Сейчас во встраиваемых системах хорошо известны как минимум 5-ть операционных систем реального времени (RTOS) способных работать на STM32F407 и ниже с открытыми исходными текстами (хотя и под разными лицензиями).
Это: FreeRTOS, Micrium (uC/OS-II, III), Keil (RTX) она же mbed.org, Freescale MQX, Texas Instruments RTOS
Они все! идут с демонстрационными примерами включающими WEB сервер и работу в интернете по разным протоколам.
Некоторые из них совместимы с POSIX.
Так в чем же смысл Embox?
Изначально смысл Embox был в фане, который мы получали, плюс мы обучали (и обучаем) студентов архитектуре ОС и embedded systems на практике, что оказалось очень эффективным.
Ну, а потом, найдя нескольких заказчиков, мы подумали, что можем улучшить жизнь простых разработчиков, достаточно простым образом, просто позволив в ОСРВ использовать приложения из Linux. Эта идея была у uCLinux. Кроме того, изначально у нас была возможность включать только минимум приложений, это действительно похоже на различные ОСРВ которые Вы привели, но в отличие от остальных у нас нет единственного main и в нем цикла обработки, а есть main для каждого приложения.
В общем, мы хотим совместить в проекте плюсы от Linux и RTOS. И надеемся, что это может кому нибудь пригодиться.
Ну, а потом, найдя нескольких заказчиков, мы подумали, что можем улучшить жизнь простых разработчиков, достаточно простым образом, просто позволив в ОСРВ использовать приложения из Linux. Эта идея была у uCLinux. Кроме того, изначально у нас была возможность включать только минимум приложений, это действительно похоже на различные ОСРВ которые Вы привели, но в отличие от остальных у нас нет единственного main и в нем цикла обработки, а есть main для каждого приложения.
В общем, мы хотим совместить в проекте плюсы от Linux и RTOS. И надеемся, что это может кому нибудь пригодиться.
А для чего на конечном железе поднимать веб-сервер? В чем минус решения когда на микроконтроллере крутится только критичный функционал, а интерфейс выносится на внешнее устройство, где падения высокоуровневого кода не сломает работу критичных задач? Конечно получится лишнее звено, но на него можно навесить много переферийных задач и оно вполне окупится.
Т.е. например ардуино которая по тому же modbus обменивается командами с полноценным компьютером, большую часть времени при этом работая автономно, и не зависящая от работы ОС на компьютере.
Т.е. например ардуино которая по тому же modbus обменивается командами с полноценным компьютером, большую часть времени при этом работая автономно, и не зависящая от работы ОС на компьютере.
Не уверен, что это достаточная аргументация, но…
В общем, когда то мы хотели сделать квадракоптер, сделать мы его хотели на gumstix, и к нему шла отдельная плата с автопилотом. И тогда нам пришло в голову, а почему же не перенести функциональность автопилота на большой процессор. Естественно должна быть защита, чтобы критичные задачи не могли сломаться прикладным ПО. Это можно было достичь, например, с помощью гипервизора о котором говорилось в первом комментарии. Мы же пошли немного другим путем, описанным в статье. То есть, позволили совмещать критичную и не критичную функциональность, а разруливается это программистом с помощью приоритетов и остальных плюшек нашего проекта.
Кроме того, с увеличением компонентов и связей между компонентами надежность устройства падает, ну и следовательно в системе нужно оставить как можно меньше процессоров.
В общем, когда то мы хотели сделать квадракоптер, сделать мы его хотели на gumstix, и к нему шла отдельная плата с автопилотом. И тогда нам пришло в голову, а почему же не перенести функциональность автопилота на большой процессор. Естественно должна быть защита, чтобы критичные задачи не могли сломаться прикладным ПО. Это можно было достичь, например, с помощью гипервизора о котором говорилось в первом комментарии. Мы же пошли немного другим путем, описанным в статье. То есть, позволили совмещать критичную и не критичную функциональность, а разруливается это программистом с помощью приоритетов и остальных плюшек нашего проекта.
Кроме того, с увеличением компонентов и связей между компонентами надежность устройства падает, ну и следовательно в системе нужно оставить как можно меньше процессоров.
Интересно, что Pixhawk — крутейшая железка для беспилотников — именно так и работает: «функциональность автопилота на большом процессоре». Учитывая размер комьюнити, разрабатывающего ArduPilot и Pixhawk, подозреваю, что эти решения станут вездесущими не только в мире беспилотников.
Pixhawk построен на PX4 Flight Stack.
А тот в свою очередь базируется на одной из старейших RTOS — NuttX
Начиналась эта RTOS еще от 8-и разрядных микроконтроллеров AVR
Никакого большого процессора там нет.
Автопилоты этого класса делаются на нескольких средненьких STM32F.
RTOS там вообще только в одном из них применяется.
Хотя да, NuttX поддерживает POSIX, но никогда к Линуксу и большим процессорам с MMU никакого отношения не имела.
А тот в свою очередь базируется на одной из старейших RTOS — NuttX
Начиналась эта RTOS еще от 8-и разрядных микроконтроллеров AVR
Никакого большого процессора там нет.
Автопилоты этого класса делаются на нескольких средненьких STM32F.
RTOS там вообще только в одном из них применяется.
Хотя да, NuttX поддерживает POSIX, но никогда к Линуксу и большим процессорам с MMU никакого отношения не имела.
Это коммерческий AR.Drone делают на Линуксе. Но нельзя забывать что у них там всегда есть еще оконечные интеллектуальные ESC модули и проч. Вот они то и работают в жестком риалтайме.
А Линукс там нужен чтобы запускать для забавы пользователям JavaScript.
А Линукс там нужен чтобы запускать для забавы пользователям JavaScript.
Вот когда для забавы ставится Линукс, причем только для забавы, это все таки отдельный мощный процессор и память и остальное, вот именно этого можно постараться избежать. То есть, если развлекухи будут работать с низким приоритетом и не затронут работу задач с жестким реалтаймом, то можно ограничится одним корпусом, пусть даже с несколькими ядрами.
В СССР, уже на излете, проблему совместимости железячников и программистов в оборонке решили убиранием программистов на уровень писания средств разработки. А средство разработки сделали доступным для железячников — это ДРАКОН.
Да, я слышал о таком графическом языке, насколько я знаю, его сейчас пытаются применять. Еще можно отметить различные языки для ПЛК. Но мне кажется чисто графические языки не дают достаточно возможностей программисту. Это хорошо для верхнего уровня и для определенного класса задач, например, где нужно ограничивать, эти самые возможности, но всю разработку вести на них крайне трудно.
Ну а идея убирания программистов на написание средств разработки понятна. Сами мы начинали на кафедре системного программирования СПбГУ. И Андрей Николаевич Терехов, зав кафедрой, как раз и придерживается тех самых взглядов. В свое время на кафедре написали графический язык REAL, он конечно меньше известен, но применялся для создания АТС. Кроме того было еще несколько технологий для оборонки и даже своя вычислительная машина Самсон.
Да и Embox в принципе можно отнести к технологиям. :) Поскольку инженеры нас используют и у них получается.
Ну а идея убирания программистов на написание средств разработки понятна. Сами мы начинали на кафедре системного программирования СПбГУ. И Андрей Николаевич Терехов, зав кафедрой, как раз и придерживается тех самых взглядов. В свое время на кафедре написали графический язык REAL, он конечно меньше известен, но применялся для создания АТС. Кроме того было еще несколько технологий для оборонки и даже своя вычислительная машина Самсон.
Да и Embox в принципе можно отнести к технологиям. :) Поскольку инженеры нас используют и у них получается.
UFO just landed and posted this here
1. Уточните пожалуйста по каким параметрам интересует сравнение. Первое, что приходит в голову, мы русские и нашим студентам было проще общаться с нами, в том числе и лично.
2. Сейчас к сожалению нет. Но мы сейчас разрабатываем новую версию системы сборки в которой такая возможность обязательно будет. Раньше просто такой проблемы не было.
3. На нашем вики можно найти некоторую информацию. К сожалению с документацией у нас крайне плохо, поэтому лучше спрашивать в нашей группе рассылки или вообще обращаться лично. Со временем, надеюсь это исправится.
2. Сейчас к сожалению нет. Но мы сейчас разрабатываем новую версию системы сборки в которой такая возможность обязательно будет. Раньше просто такой проблемы не было.
3. На нашем вики можно найти некоторую информацию. К сожалению с документацией у нас крайне плохо, поэтому лучше спрашивать в нашей группе рассылки или вообще обращаться лично. Со временем, надеюсь это исправится.
UFO just landed and posted this here
Вы нам льстите, к сожалению, у нас нет отношений с Таненбаумом:)
Мы безусловно изучаем код Minix и порой заимствуем идеи, но мы не так категоричны по поводу микроядерности.
На самом деле, я считаю, что у нас из за нашей модульной структуры, система получилась порой даже более подходящая для изучения чем в Minix. Но конечно за Minix огромный опыт и нам трудно с ним соревноваться, все таки классика ее нужно знать.
С документацией согласен, много ее не бывает. Конечно перенесем, ниже в комментариях об этом где то было.
По поводу отдельных приложений и модулей ядра. Да идея у нас приблизительно следующая, а давайте сделаем библиотеки которые не будут зависеть от конкретного ядра, и тогда из них можно собрать и микроядерную архитектуру и монолитную и гибридную, в общем по-экспериментровать от души. А приложения, хотим вообще свои маленький аналог busybox сделать, но с преферансом и поэтессами:) В общем идей много, постараемся реализовать.
Под нашей OS вы подразумеваете отечественную разработку? Нам бы хотелось, чтобы проект был интернациональным. У нас даже несколько иностранных контрибьютеров было, к сожалению, мало. Это кстати к слову о сообществе. Конечно мы пытаемся его создать и будем рады любому сотрудничеству!
Мы безусловно изучаем код Minix и порой заимствуем идеи, но мы не так категоричны по поводу микроядерности.
На самом деле, я считаю, что у нас из за нашей модульной структуры, система получилась порой даже более подходящая для изучения чем в Minix. Но конечно за Minix огромный опыт и нам трудно с ним соревноваться, все таки классика ее нужно знать.
С документацией согласен, много ее не бывает. Конечно перенесем, ниже в комментариях об этом где то было.
По поводу отдельных приложений и модулей ядра. Да идея у нас приблизительно следующая, а давайте сделаем библиотеки которые не будут зависеть от конкретного ядра, и тогда из них можно собрать и микроядерную архитектуру и монолитную и гибридную, в общем по-экспериментровать от души. А приложения, хотим вообще свои маленький аналог busybox сделать, но с преферансом и поэтессами:) В общем идей много, постараемся реализовать.
Под нашей OS вы подразумеваете отечественную разработку? Нам бы хотелось, чтобы проект был интернациональным. У нас даже несколько иностранных контрибьютеров было, к сожалению, мало. Это кстати к слову о сообществе. Конечно мы пытаемся его создать и будем рады любому сотрудничеству!
UFO just landed and posted this here
Я наверное не совсем правильно выразился.
По busybox я имел в виду набор легковесных библиотек и приложений которые легко отделяются и включаются в проект.
Стандартная библиотека у нас своя, пытались использовать nelib, но не получилось. У нас слишком конфигурироемое решение. То есть не понятно как быть с системными вызовами, которые в каждой системе свои, но они одинаковые для системы, а у нас все может меняться, и системных вызовов может не быть, а быть прямые вызовы функций.
По поводу свободы. Да, мы пытаемся сделать максимально открытый проект, именно поэтому мы задумали новую систему сборки, которая позволит сообществу легко отделять и включать куски. Ну, это одно из требований.:)
По busybox я имел в виду набор легковесных библиотек и приложений которые легко отделяются и включаются в проект.
Стандартная библиотека у нас своя, пытались использовать nelib, но не получилось. У нас слишком конфигурироемое решение. То есть не понятно как быть с системными вызовами, которые в каждой системе свои, но они одинаковые для системы, а у нас все может меняться, и системных вызовов может не быть, а быть прямые вызовы функций.
По поводу свободы. Да, мы пытаемся сделать максимально открытый проект, именно поэтому мы задумали новую систему сборки, которая позволит сообществу легко отделять и включать куски. Ну, это одно из требований.:)
Скажите, кто тот человек, который написал систему сборки Embox, и как он это сделал?
UFO just landed and posted this here
Скорее всего, тоже на Гитхаб. Автоматически переносить не стали, поскольку хотим перетрясти структуру, да и вообще в порядок привести.
С переездом на Гитхаб (всего остального) вообще целая эпопея вышла, потому как мы заморочились еще и переносом всех ишью с сохранением авторства и дат. Плюс добавили к гитовой истории самые ранние коммиты, которых не было на Гугл Коде. Вики будем воссоздавать скорее всего вручную.
С переездом на Гитхаб (всего остального) вообще целая эпопея вышла, потому как мы заморочились еще и переносом всех ишью с сохранением авторства и дат. Плюс добавили к гитовой истории самые ранние коммиты, которых не было на Гугл Коде. Вики будем воссоздавать скорее всего вручную.
Можете объяснить, как она работает? 18кБ кода это как-то немало) Я так понимаю, система сборки решает довольно много проблем, связанных с зависимостями и конфигурацией сборки.
Оу, боюсь, это на целую статью потянет, в прошлой, пожалуй, только поверхностное описание. А какая именно часть вас интересует?
Вообще мы сейчас работаем над следующей инкарнацией системы сборки (пишем на Питоне, а под капотом Waf). Вот про неё, думаю, было бы круто рассказать, но пока что мы только пилим сам код. =)
Вообще мы сейчас работаем над следующей инкарнацией системы сборки (пишем на Питоне, а под капотом Waf). Вот про неё, думаю, было бы круто рассказать, но пока что мы только пилим сам код. =)
Ого, даже статья есть, спасибо! В общем-то нашёл ответы почти на все свои вопросы. Остался вопрос с реализацией генерации всяких файлов. В статье упоминается генерация списка загрузки модулей. Как это сделано или где на это можно посмотреть?
Сам скрипт генерации вот тут, а вызов его декларируется в модуле, который отвечает за разрешение зависимостей в рантайме. Скрипт просто генерирует Сишный код в stdout, а вывод сохраняется в файл, который уже компилируется и линкуется как обычный.
Ещё забыл: как работает определение тулчейна, параметров компиляции и всяких таких вещей, зависящих от архитектуры? Кто предоставляет путь к тулчейну и все эти параметры?
Эта часть не менялась очень давно, там все просто задается руками в конфигурации, например, для ARM:
TARGET = embox
ARCH = arm
CROSS_COMPILE = arm-none-eabi-
CFLAGS += -O0 -g
CFLAGS += -march=armv7-a -mtune=cortex-a8
LDFLAGS += -N -g
То есть все модули компилируются с одними и теми же параметрами? Или можно скомпилировать, скажем, отдельно с PIC и без PIC? И как система сборки определяет, когда нужно просто скомпилировать, а когда слинковать что-то в один файл?
Тот файл задаёт глобальные флаги, конкретно для процессора.
Мы старались добавлять фичи по необходимости, поэтому pic не поддерживается.
Но есть такая запись в src/framework/mod/Mybuild:
позволяет определить макрос. Разворачивается в -D__FRAMEWORK__ опцию во время компиляции
Другой пример: страшный файл third-party/qpid/Mybuild
позволяет экспортировать флаги компиляции для зависящих модулей. Т.е. только те модули, которые зависят от core, получают -Ipath, где можно найти его хидеры.
В настоящее время, все модули просто компилируются и линкуются в один образ в конце сборки. В новой версии системы сборки обещаем поправить =)
Мы старались добавлять фичи по необходимости, поэтому pic не поддерживается.
Но есть такая запись в src/framework/mod/Mybuild:
@DefineMacro("__FRAMEWORK__")
source "core.c"
позволяет определить макрос. Разворачивается в -D__FRAMEWORK__ опцию во время компиляции
Другой пример: страшный файл third-party/qpid/Mybuild
@BuildArtifactPath(cppflags="-I$(abspath $(EXTERNAL_BUILD_DIR))/third_party/qpid/core/install/include")
...
module core {
...
позволяет экспортировать флаги компиляции для зависящих модулей. Т.е. только те модули, которые зависят от core, получают -Ipath, где можно найти его хидеры.
В настоящее время, все модули просто компилируются и линкуются в один образ в конце сборки. В новой версии системы сборки обещаем поправить =)
Не могли бы вы развить мысль, почему использование Linux как ОС автоматически увеличивает время реакции до 3 мс, и о каких именно дополнительных накладных расходах идет речь при прямой работе с регистрами под Linux?
Это из обсуждения статьи olartamonov из Black Swift:
3 мсек требуется для переключения из user space, прохождения всего стека Linux vfs и отработки драйвера sysfs (ну и на то, чтобы вернуться по стеку обратно, наверное). При прямой работе с регистрами из ядерного драйвера Linux таких накладных расходов, конечно, нет.
Через sysfs минимальный квант — 3 мсек, прямая работа с регистрами — 100 нсек.
3 мсек требуется для переключения из user space, прохождения всего стека Linux vfs и отработки драйвера sysfs (ну и на то, чтобы вернуться по стеку обратно, наверное). При прямой работе с регистрами из ядерного драйвера Linux таких накладных расходов, конечно, нет.
Иными словами если работать с портами так как это должно быть сделано под Linux то никаких 3мс задержек не будет. Да и из userspace есть вариант как дергать регистры без накладных расходов с той же скоростью как и из ядра, правда совсем не переносимый между разными платформами.
Это как?
По-моему это делается через ioremap в ядре в ответ на mmap из user space. Т.о. в user space получаем кусок памяти в который драйвер отобразил диапазон адресов I/O переферии.
Один из драйверов аппаратного видеодекодера, который я видел, именно так и работал. В ядре только ремапинг, в вся логика работает напрямую с регистрами из user space.
Один из драйверов аппаратного видеодекодера, который я видел, именно так и работал. В ядре только ремапинг, в вся логика работает напрямую с регистрами из user space.
Вы правы, есть ряд ухищрений в Линукс для работы с памятью напрямую. Например через файл /dev/mem. Но это совсем не безопасный метод, к тому же непонятно как это использовать в скриптовых языках, в общем это не самые правильные методы работы в системе общего назначения.
Работа с GPIO
Там же замеры скорости на самой дубовой задаче — дёргать ножку 0-1 в бесконечном цикле.
Там же замеры скорости на самой дубовой задаче — дёргать ножку 0-1 в бесконечном цикле.
Буквально недавно на LWN была статья о том, что для ARM'ов сделали гибридные процессоры (не путать с big.LITTLE), когда рядом с обычными computational cores находятся низкопроизводительные (200МГц) сопроцессоры с фиксированными таймингами доступа к памяти, без прерываний и прочих затруднений для realtime.
lwn.net/Articles/639258
lwn.net/Articles/639258
Прикольно, спасибо за инфу. Раньше, в такоей конфигарации, в основном встречал DSP ядра
у Freescale есть семейство Vybrid ARM Cortex-A5. В нем старшие модели имеют встроенный дополнительно Cortex-M4.
Младший процессор может работать в режиме реального времени, а старший разгребать более глобальные задачи.
Младший процессор может работать в режиме реального времени, а старший разгребать более глобальные задачи.
Для Vybrid Freescale имеет специальную RTOS MQX которая портирована на оба ядра этого SoC-а.
Так что и глобальные задачи можно без Линукса решать.
Так что и глобальные задачи можно без Линукса решать.
Различных решений, достаточно эффективных много. Но возникает вопрос, почему так упорно используют Линукс. Мое мнение, потому что в нем есть удобство отладки и огромное количество готового ПО.
А я бы посмотрел на это иначе.
Почему Линукс полностью не захватил все встроенные системы?
По прогнозам 2014 Embedded Market Study в этом или следующем году лидером по применяемости станет FreeRTOS обогнав Android!
Мой ответ.
Потому что Линукс реально очень трудно отлаживать. И в нем не так уж много готового ПО для встраиваемых систем.
Вот какой софт вы взяли из Линукса для встраиваемых систем?
Почему Линукс полностью не захватил все встроенные системы?
По прогнозам 2014 Embedded Market Study в этом или следующем году лидером по применяемости станет FreeRTOS обогнав Android!
Мой ответ.
Потому что Линукс реально очень трудно отлаживать. И в нем не так уж много готового ПО для встраиваемых систем.
Вот какой софт вы взяли из Линукса для встраиваемых систем?
На вскидку libmodbus. Вообще мы взяли довольно много ПО: Qt, dropbear, ZeroMQ ну и еще куча всего, но наверное вопрос именно для мелких устройств, поэтому лучше всякие легковесные языки типа lua, tynypy и так далее назвать.
FreeRTOS безусловно хорошая штука и очень популярная. Но как я уже отмечал, сейчас даже от чайника хотят чтобы он твитил. Ну а такую «продвинутую» функциональность все же проще брать готовой или отладить по максимуму на десктопном линуксе.
На самом деле, это всего лишь мое личное видение ситуации. Но из опыта в системах все же присуствует и богатый линукс (например для qt графики) и отдельно части работающие в реальном времени, тот же ардуино. И если удастся совместить эти вещи, то возможно это будет то что нужно.
FreeRTOS безусловно хорошая штука и очень популярная. Но как я уже отмечал, сейчас даже от чайника хотят чтобы он твитил. Ну а такую «продвинутую» функциональность все же проще брать готовой или отладить по максимуму на десктопном линуксе.
На самом деле, это всего лишь мое личное видение ситуации. Но из опыта в системах все же присуствует и богатый линукс (например для qt графики) и отдельно части работающие в реальном времени, тот же ардуино. И если удастся совместить эти вещи, то возможно это будет то что нужно.
Qt это интересно. Но почти 100% уверен, что под STM32 у вас не работает.
dropbear это не готовое приложение, а просто SSH канал доступа к неким функциям которые разработчик сам должен реализовать на своей платформе. Дублирование по сути встроенного WEB сервера по SSL.
ZeroMQ не приложение, а инструмент. Эт еще понять надо как его приладить и для разработки чего он нужен.
libmodbus тоже еще не приложение, а только реализация протокола, причем настолько примитивного что он в свое время на ATMEGA8 делался без всяких осей.
Скрипты? Так они тоже без осей есть достаточно реализованых. И LUA (eLUA) и JavaScript (Espruino) и Python (в OpenPilot реализован) и т.д. Опять же это не готовое ПО. Скрипты требуют серьезной низкоуровневой прослойки доступа к периферии.Которую писать самому надо.
И, как я уже говорил, на сегодняшний день все! малые RTOS умеют твитать в интернет. Для этого есть общеизвестные lwIP и uIP.
И SSL для них тоже есть.
Все же хотелось бы услышать какое же реальное практическое приложение или инструмент для встраиваемой системы можно взять только из Линукса и которого еще нет под малые RTOS.
dropbear это не готовое приложение, а просто SSH канал доступа к неким функциям которые разработчик сам должен реализовать на своей платформе. Дублирование по сути встроенного WEB сервера по SSL.
ZeroMQ не приложение, а инструмент. Эт еще понять надо как его приладить и для разработки чего он нужен.
libmodbus тоже еще не приложение, а только реализация протокола, причем настолько примитивного что он в свое время на ATMEGA8 делался без всяких осей.
Скрипты? Так они тоже без осей есть достаточно реализованых. И LUA (eLUA) и JavaScript (Espruino) и Python (в OpenPilot реализован) и т.д. Опять же это не готовое ПО. Скрипты требуют серьезной низкоуровневой прослойки доступа к периферии.Которую писать самому надо.
И, как я уже говорил, на сегодняшний день все! малые RTOS умеют твитать в интернет. Для этого есть общеизвестные lwIP и uIP.
И SSL для них тоже есть.
Все же хотелось бы услышать какое же реальное практическое приложение или инструмент для встраиваемой системы можно взять только из Линукса и которого еще нет под малые RTOS.
Фишка с modbus'ом не в том, что есть какая-то реализация, а в том, что она весьма конкретная (http://libmodbus.org/) и самое главное, исходный код для Linux и для Embox один и тот же. Мы так и разрабатывали свой веб интерфейс, сначала собрали modbus-сервер на хосте, который вместо управления GPIO делал printf. А затем перенесли modbus-сервер на Embox, заменив только GPIO часть.
Другой пример: httpd, один исходный код работает под Linux и под Embox.
Этот modbus сервер и httpd работают в составе системы на STM32. И там же ещё запускаются CGI-программы, которые генерируют контент, которые тоже можно просто скомпилировать на хосте и разрабатывать/отлаживать.
Другой пример: httpd, один исходный код работает под Linux и под Embox.
Этот modbus сервер и httpd работают в составе системы на STM32. И там же ещё запускаются CGI-программы, которые генерируют контент, которые тоже можно просто скомпилировать на хосте и разрабатывать/отлаживать.
Безусловно libmodbus достаточно простой и может быть сделан без помощи осей и библиотек, но:
А если взять стандартную реализацию то всего этого можно избежать
По поводу Qt, ZeroMQ и других платформ, то же самое если ваш код уже написан под данную библиотеку, то переписать его можно и может это будет более эффективно, но все те же перечисленные проблемы.
И кстати можете пояснить почему Вы уверены, что Qt на STM32 не возможен? Если мы говорим об объеме памяти, то соглашусь, но если говорим о STM в внешней памятью, то вполне решаемая задача. Если Вы беспокоитесь по поводу отсутствия виртуальной памяти, то вот статья в которой описано как мы обходим эту проблему.
На ваше желание услышать реальное практическое приложение, у меня встречное предложение. Уточните какое приложение для Вас будет доказательством?
- Придется потретить время
- Новый код может содержать ошибки
- Собственный код нужно поддерживать
А если взять стандартную реализацию то всего этого можно избежать
По поводу Qt, ZeroMQ и других платформ, то же самое если ваш код уже написан под данную библиотеку, то переписать его можно и может это будет более эффективно, но все те же перечисленные проблемы.
И кстати можете пояснить почему Вы уверены, что Qt на STM32 не возможен? Если мы говорим об объеме памяти, то соглашусь, но если говорим о STM в внешней памятью, то вполне решаемая задача. Если Вы беспокоитесь по поводу отсутствия виртуальной памяти, то вот статья в которой описано как мы обходим эту проблему.
На ваше желание услышать реальное практическое приложение, у меня встречное предложение. Уточните какое приложение для Вас будет доказательством?
Моя мысль была в том, что не нужно Линукса и линуксоподобных сервисов операционки, чтобы иметь все то что вы имеете на STM32 в вашей ОС. И сил это потребует меньше.
Я не за то чтобы переписать что-то, а говорю о том что это уже сделано, написано, портировано без Линукса и POSIX-а.
И вряд ли вы найдете что-то готовое, вот прям под STM32 чтобы оно было только в Линуксе и больше нигде.
Я не за то чтобы переписать что-то, а говорю о том что это уже сделано, написано, портировано без Линукса и POSIX-а.
И вряд ли вы найдете что-то готовое, вот прям под STM32 чтобы оно было только в Линуксе и больше нигде.
Поздравляю с открытием блога! Так держать! :)
Буду ждать новых публикаций о Embox.
Буду ждать новых публикаций о Embox.
Sign up to leave a comment.
Железячники vs. Программисты