Comments 14
Что-то я так и не понял, в чем преимущество Embox по отношению к той же FreeRTOS (да и к другим ОСРВ), которая при грамотном написании драйверов, переносится на другой МК вообще без проблем, просто с правкой конфига и заменой драйверов периферии, если это требуется. Причем без танцев с бубном и калокуба и сам перенос занимает, ну час. ОС в принципе мало зависит от МК. Да и сами STM нынче малопригодны для использования, сейчас в моде китайские МК.
Удачи вам там с модными китайскими чипами! И вот сразу три причины, из-за которых контроллер GD32F450 теряет UDP пакеты
Удачи, не удачи, а альтернатив на текущий момент нет и не предвидится. Да и реализовывать программный стек на любых МК занятие такое себе. Куда проще поставить сетевой контроллер, типа W5500 и не знать вообще никаких проблем в работе TCP/UDP. А по стоимости она не сильно отличается от PHY. Тем более проблема то оказалась по большей части именно в PHY, для которого не поставили отдельный генератор. А проблема чек суммы описана в Errata
Да, сейчас STM32 как-то продаются, даже ценник упал до более-менее приемлемых величин. Но что будет завтра, никто не скажет, а китаезные чипы как продавались, так и будут продаваться.
Что-то я так и не понял, в чем преимущество Embox по отношению к той же FreeRTOS (да и к другим ОСРВ)
Спасибо за вопрос. На самом деле преимущество не в драйверах, да мы их совершенствуем, развиваем dev-tree, но одно из наших слабых мест, это как раз количество поддерживаемых платформ. Для FreeRTOS вы скорее всего возьмете готовое решение. Так как пока популярность проекта далека от FreeRTOS, количество разработчиков драйверов сильно ограничено, и про разные платформы и драйвера у нас часто спрашивают. Эта статья показывает, что вы сами легко можете добавить новую платформу. постепенно компании начинают добавлять поддержку нужных платформ.
Поскольку по сравнению с различными RTOS (тем более FreeRTOS) у нас огромное преимущество при разработке вашей прикладной системы на Линукс, а уже затем перенос на железо, причем любое. Это отмечено в заключении
Как показано в статье, разрабатывать и отлаживать прикладные задачи под Embox очень удобно.
Да и сами STM нынче малопригодны для использования, сейчас в моде китайские МК.
STM ки просто пример, и да, у нас их часто спрашивают. GD мы сейчас рекомендуем как альтернативу, и там описание будет такое же. А на самом деле, в РФ вот вот появятся собственые МК, правда не уверен что по цене китайских.
Для FreeRTOS вы скорее всего возьмете готовое решение.
Ну как готовое. Если ядро остается тем же, то я просто перенесу сборку с одного МК на другой, заменив при необходимости драйвера периферии. Если же ядро другое, то возьму сборку RTOS под требуемое ядро и на нее перенесу уже все остальное. Ну как сборку, пару файлов исходников.
Эта статья показывает, что вы сами легко можете добавить новую платформу. постепенно компании начинают добавлять поддержку нужных платформ.
Платформа - имеется в виду конкретная плата с МК? Тогда вообще непонятно, зачем добавлять их поддержку в RTOS. Ведь для запуска именно ядра ОС, этой самой ОС требуется только знать, на каком ядре МК она запускается, и все. Периферия же к самой ОС отношения не имеет.
А на самом деле, в РФ вот вот появятся собственые МК, правда не уверен что по цене китайских.
Даааа, присылали нам на работу предложение ознакомиться с МК из РФ. Вот только даташит почему-то от GD32 был...
Даааа, присылали нам на работу предложение ознакомиться с МК из РФ. Вот только даташит почему-то от GD32 был...
Не знаю может Вы и правы, но у нас другой опыт https://habr.com/ru/articles/777302/
Ведь для запуска именно ядра ОС, этой самой ОС требуется только знать,
на каком ядре МК она запускается, и все. Периферия же к самой ОС
отношения не имеет.
Не хочется спорить. Коротко, если вы не сталкивались с подобными проблемами которые мы пытаемся решать (довольно успешно), я не смогу этого объяснить
но у нас другой опыт https://habr.com/ru/articles/777302/
Да, фирма у нас была другая.
Коротко, если вы не сталкивались с подобными проблемами которые мы пытаемся решать (довольно успешно), я не смогу этого объяснить
Это с какими? Портирование ОС под какие-то эвал борды? А в чем смысл? Это тоже самое, что делать сборку ОС под каждый конкретный ПК. ОС для встраиваемых систем поставляется в виде ядра, больше от нее ничего не нужно. Периферия все равно в каждом проекте будет использована своя. Так какой смысл заниматься созданием ОС под конкретные платы? Пока я вижу ваши проблемы в войне с ветряными мельницами. Хотя вы даже не особо в курсе, как к МК подключиться
Подключите плату с помощью jtag (сигналы (PA2 SWCLK, PA3 SWDIO, GND)
Открою страшную тайну, у JTAG совершенно другие сигнальные линии. А это SWD интерфейс.
И в статье про модбас вы пишите:
Ведь в случае с RTOS ами обычно просто делается новая библиотека под конкретную платформу, ну или берется уже написаная и самостоятельно прикручивается.
Ну начнем с того, что отдельная либа под модбас нужна только в том случае, если используется весь его функционал. На практике же используется буквально 3-4 типа запроса. Плюс даже если этого отдельная либа, то прикручивается к RTOS она куда проще и быстрее вашего варианта. Единственное, что там потребуется отредактировать - карта регистров под конкретное устройство. Зачем что-то для этого делать под линуксом, а потом портировать на МК? Особенно если учесть, что для этого нужен сам Линукс. Много каких-то лишних телодвижений, Telnet, веб морда и т.п. барахло, которое в 99% случаем не требуется и только без толку жрет процессорное время. Плюс я так и не нашел нигде сравнения скорости работы вашей RTOS с хотя бы одной не вашей.
Хотя вы даже не особо в курсе, как к МК подключиться
Приплыли! :)
Пока я вижу ваши проблемы в войне с ветряными мельницами.
Повторяю, не нужно тратить свое время на всякую чепуху, ну мало ли кто чего понаписал, в самом то деле :)
Приплыли! :)
Приплыли. Не уметь отличить интерфейсы друг от друга, это нонсенс для разработчика.
не нужно тратить свое время на всякую чепуху
Это уже мне решать, куда и как тратить время) Пока я вижу, что вы делаете работу ради работы. По сравнению с той же FreeRTOS у вас какие-то сплошные костыли и грабли. И вам об этом не раз писали в комментариях. Проекту вашему больше 10 лет, а вы до сих пор не можете внятно объяснить, зачем он нужен и чем лучше других RTOS. Даже сравнение быстродействия до сих пор нет. Да и судя по статьям, все, что он делает - это работа на различных отладках.
Это уже мне решать, куда и как тратить время) Пока я вижу, что вы делаете работу ради работы.
Не видите случайно двойных стандартов в ваших идущих подрят двух фразах?
Нет, зато я вижу, что вы опять уходите от ответа на технические вопросы. Как, впрочем, и во всех темах по Embox.
Нет, зато я вижу, что вы опять уходите от ответа на технические вопросы. Как, впрочем, и во всех темах по Embox.
А я вижу! И что Вы тратите мое время, вижу. Никаких вопросов Вы не задаете, просто с чего то решили, что вправе мне указывать, что мне делать, учить меня и давать мне зачем то оценку!
Хотите понять Embox читайте статью https://habr.com/ru/companies/embox/articles/440390/ и смотрите видео в которых мы объясняем, зачем это потребовалось и почему не получилось решить вопрос существующими средствами. Отчитываться ни перед кем я не намерен!
учить меня
Не делайте ошибки в статьях и учить никто не будет. А не нравится критика - так вообще не пишите статьи. Хотя ой, как же вы тогда будете продвигать свой продукт xD
Хотите понять Embox читайте статью
У меня вопрос, вы то эту статью читали хоть? В статье сплошная вода, типа да, можно какой-то код с линуха перенести на МК. Непонятно зачем (т.к. линух девайсы, как правило, используют недоступное для МК железо), но можно. Вот, а на другие RTOS не можно, даааа. И, опять же, нет ни одного сравнения хоть с какой-то ОС. Да ладно сравнения, ни слова не сказано даже о времени переключения контекста. Зато там есть программный TCP/UDP стек, который, по сути, требуется лишь для SoC с беспроводным интерфейсом на борту, а для проводной сети давно придумали ту же W5500, которая реализует всю работу со стеком внутри себя и общается с МК через SPI, при стоимости сопоставимой с PHY чипами. Или за 13 лет вы не удосужились провести хоть какое-то тестирование своей ОС? Но зато прикрутили ее к десятку бестолковых плат.
Про винду вообще какая-то чушь написана. Вы про Windows Embedded CE слышали то хоть? Так она еще в реал тайм умела, только еще и с GUI. Те же Keysight ее вполне себе в приборах используют. Например вот тут:
Отчитываться ни перед кем я не намерен!
Ой, какие мы нервные. А в чем тогда смысл постоянного пиара проекта? Вы же элементарно не можете объяснить, чем он лучше других RTOS. Не можете показать на примере конкретной задачи, почему другие RTOS не справились с задачей, а ваша справилась. Пока что у вас лишь статьи на тему "прикрутили очередную свистоперделку, потратив всего два дня времени" xD
Вы все таки определитесь, либо постоянный пиар проекта, либо статьи на тему "прикрутили очередную свистоперделку, потратив всего два дня времени" xD
Но за
всего два дня
Спасибо. Да, Вы правы, где на других RTOS требуется 2 месяца на embox всего два дня. Где полгода, на embox 2-3 недели.
И естественно, не нужно пихать embox везде, если вам мигание светодиодом нужно, FreeRTOS более чем достаточен!
Если хотите продолжать пиарить проект, то вот вам контекст свич как просили https://habr.com/ru/companies/embox/articles/330236/
Перенос вашего проекта под Embox на новую плату STM32