Я нисколько не сомневаюсь, что Вы проделали гиганскую работу, но я о другом! Я исключительно о том, что Вы правильно поступили, не начав писать свой компилятор, а доработав обычный, сразу получили кучу отлаженной функциональности.
По поводу ОС (или программной платформы) я считаю что уместен тот же подход. То есть берем существующее и добавляем свою функциональность. Поскольку быть специалистом во всем, можно, но только плохим.
да, пришлось обучать линуер gcc, чтобы он делал раскладку по окнам правильно и за внутренними 8 килами, а также накатать свой пакет для жонглирования сегментами в коде.
Линкер конечно не ОС, но его все равно пришлось обучать:) А модуль сегментации, можно было и в Embox добавить, и не пришлось бы писать свою ОС:)
Или какая из существующих "ос" работает с sd уартридерами аки "жёсткий диск" с подгрузкой кода во флеш Меги?
Тут не очень понял, фактически все sd карты умеют spi режим. и да ничего не стоит в embox добавить прокидку команд не по SPI а по UART
Да, это была попытка выдать из Меги всё и чутка побольше.
Восхищаюсь тем что вы сделали, но у меня немного другой подход. Просто современные 32 битные мк стоит вполне сопостовимые с мегой деньги. И не понятно, что мы получаем в таком случае в качестве преимуществ платформы.
Здравствуйте! Мы общались с производителем Репки. Но не понятно, кому портирование Embox для Репки нужно? У них бизнес модель - продажа аналога Малины, там нет отечественного процессора или каких то особенностей. Поэтому они используют уже готорую экосистему Малины (с линуксом). Нам тоже не понятно зачем это нужно, затраты на портирование будут существенные Embox на малине работает в ограниченном варианте, а на третьей и выше которые armv8 (aarch64) мы еще не запускались. То есть, с нашей стороны, гораздо выгоднее в оригиналы (raspbery pi basana pi orange pi и так далее) вкладываться процессор то там такой же. Ну или в отечественную микроэлектронику, как в случае описанном в статье, и остальных уже описанных и будущих, будут еще аннонсы:)
когда вы позиционируете себя как разработчика собственной ОС
Вопрос только в том, кому нужна ваша ОС. Если она Линукс а Вы Линус Торвальдс, то не сомненно, у вас есть преимущество. Но если вы что то разработали, свое, то сначала вам нужно доказать что оно работает, и что лучше чем другие ОС (хотя бы в чем то что нужно для решаемой задачи вашего заказчика или работодателя)
А как это ОС для конкретного устройства? Там особенные файлы только для конкретного устройства? Особенные потоки, семафоры, очереди? Особенный TCP/IP стек?
У Embox было четкое почему не устроили существующие, хотя идеи мы конечно заисмтвовали.
И наверное единственное обоснование писать свою ОС, для меня, так человек лучше сможет разобраться. Хотя Embox например предоставляет возможность поковыряться в коде.
Тут точно другая ситуация. Вопрос возник, потому что хотелось разработать ОС для конкретного устройства. И не тиражировать ее, насколько я понимаю. Ну то есть, она не предполагала наличие каких то особенностей и конкурентных преимуществ.
На счет разработчиков который могут работать, только с: CubeMX, TI-RTOS, Segger embOS. или все сам, в регистры пишу... Ну тут такое, уровень точно техникума, мидлом может быть, и то если совпадут технологии. Тот же принцип если вот какой у меня опыт в каком нибудь модном или не очень фреймворке для чего бы то ни было.
Разработчик, для меня, как Вы поняли, это не кодер. И он понимает, почему использует ту или иную технологию, понимает базу и следовательно, способен разобраться в любой ОС (если конечно там есть смысл, а не только потому что мое :) )
Думаю как раз об ътом и комментарий. В современных условиях нельзя быть мастером во всем, сейчас нужна специализация и кооперация, чтобы делать качественные конкурентоспособные вещи. Иначе, все как то не очень получается.
То есть существует ряд проектов, тот же FreeRTOS (если не хотите Embo. И их необходимо использовать, велосипеды нормальная тема, но только для обучения и то, быстро упераешься, что нужно сравнивать с мировым опытом и тогда присоединяйся к opensource
На счет вливания бабла со стороны государства, не все так однозначно. Я о нашем печальном опыте осваивать бабло, по отчетам все хорошо, а результат...
Но вот в статье пример, реальной работы (пусть и капли в море) и кстати без вливания гос бабла, хотя мы бы не отказались получить деньги за проделаную работу :)))
Сами мы пришли скорее из Linux embedded, поэтому нам вообще трудно понять как без командной строки. У вас хорошая статья, но мы постоянно сталкиваемся с мнением, "мне не нужно, значит и вы должны делать, так как я". На попытку объяснить, насколько быстро разрабатывать переносимый и подерживаемый код например (https://habr.com/ru/companies/embox/articles/538416/ или https://habr.com/ru/companies/embox/articles/541662/) мы сталкиваемся с непониманием и утверждением, что нужно все делать чуть ли не бареметал.
У нас кстати, не только UART-CLI, а почти командный интерпретатор почти как в Linux. Показали удобство в статье про файловую систему https://habr.com/ru/companies/embox/articles/573244/ И да, можно зайти telnet ssh и делать тоже самое.
На счет подстветки, спасибо за идею, у нас она реализована в каком то shell через стандартные тертинальные последовательности. Но не получила распространение, не очень востребована. Но посмотрю вашу реализацию, возможно она более гибкая и удобная!
И конечно, когда нужно помигать светодиодом, embox скажем так избыточен. Хотя мы его затаскивали на совсем мелкие устройства https://habr.com/ru/companies/embox/articles/537408/, но выигрыш там сомнителен. С другой стороны, на том же востоке и их маленьким объемом, ребята смогли
Пфф мы тут на 16кб озу mqtt, Ethernet, modbus и DumbFS подняли)
цитата из нашего чата :) (Ethenet был на SPI чипе)
Нет, зато я вижу, что вы опять уходите от ответа на технические вопросы. Как, впрочем, и во всех темах по Embox.
А я вижу! И что Вы тратите мое время, вижу. Никаких вопросов Вы не задаете, просто с чего то решили, что вправе мне указывать, что мне делать, учить меня и давать мне зачем то оценку!
Хотите понять Embox читайте статью https://habr.com/ru/companies/embox/articles/440390/ и смотрите видео в которых мы объясняем, зачем это потребовалось и почему не получилось решить вопрос существующими средствами. Отчитываться ни перед кем я не намерен!
Да, за счет госфинансирования производства, ибо дело нужное.
То что описано в статье, сделано не за счет гос финансирования:)
Проблема с доступностью микроэлектроники, к сожалению, серьезная. Дело не в плате как таковой, ее то сделать не проблема, а в самих чипах. Поскольку идея развития технологической платформы и предполагает развитие чипостроения, а для этого нужны не только фабрики для производства кристаллов, но и многое чего другого. Иначе эти кристаллы будут производиться только под гос заказ, и далеьше не пойдет ничего. Я как раз это имел в виду когда говорил про экосистему.
Я нисколько не сомневаюсь, что Вы проделали гиганскую работу, но я о другом!
Я исключительно о том, что Вы правильно поступили, не начав писать свой компилятор, а доработав обычный, сразу получили кучу отлаженной функциональности.
По поводу ОС (или программной платформы) я считаю что уместен тот же подход. То есть берем существующее и добавляем свою функциональность. Поскольку быть специалистом во всем, можно, но только плохим.
Линкер конечно не ОС, но его все равно пришлось обучать:) А модуль сегментации, можно было и в Embox добавить, и не пришлось бы писать свою ОС:)
Тут не очень понял, фактически все sd карты умеют spi режим. и да ничего не стоит в embox добавить прокидку команд не по SPI а по UART
Восхищаюсь тем что вы сделали, но у меня немного другой подход. Просто современные 32 битные мк стоит вполне сопостовимые с мегой деньги. И не понятно, что мы получаем в таком случае в качестве преимуществ платформы.
Здравствуйте!
Мы общались с производителем Репки. Но не понятно, кому портирование Embox для Репки нужно? У них бизнес модель - продажа аналога Малины, там нет отечественного процессора или каких то особенностей. Поэтому они используют уже готорую экосистему Малины (с линуксом).
Нам тоже не понятно зачем это нужно, затраты на портирование будут существенные Embox на малине работает в ограниченном варианте, а на третьей и выше которые armv8 (aarch64) мы еще не запускались. То есть, с нашей стороны, гораздо выгоднее в оригиналы (raspbery pi basana pi orange pi и так далее) вкладываться процессор то там такой же. Ну или в отечественную микроэлектронику, как в случае описанном в статье, и остальных уже описанных и будущих, будут еще аннонсы:)
Вопрос только в том, кому нужна ваша ОС. Если она Линукс а Вы Линус Торвальдс, то не сомненно, у вас есть преимущество. Но если вы что то разработали, свое, то сначала вам нужно доказать что оно работает, и что лучше чем другие ОС (хотя бы в чем то что нужно для решаемой задачи вашего заказчика или работодателя)
Ну вопрос то в общем то не ко мне. Я как раз выступаю за вопрос, а чем существующие не устраивают. Вот тут говорю об этом https://habr.com/ru/articles/777302/#comment_26236694
У Embox было четкое почему не устроили существующие, хотя идеи мы конечно заисмтвовали.
И наверное единственное обоснование писать свою ОС, для меня, так человек лучше сможет разобраться. Хотя Embox например предоставляет возможность поковыряться в коде.
Тут точно другая ситуация.
Вопрос возник, потому что хотелось разработать ОС для конкретного устройства. И не тиражировать ее, насколько я понимаю. Ну то есть, она не предполагала наличие каких то особенностей и конкурентных преимуществ.
На счет разработчиков который могут работать, только с: CubeMX, TI-RTOS, Segger embOS. или все сам, в регистры пишу... Ну тут такое, уровень точно техникума, мидлом может быть, и то если совпадут технологии. Тот же принцип если вот какой у меня опыт в каком нибудь модном или не очень фреймворке для чего бы то ни было.
Разработчик, для меня, как Вы поняли, это не кодер. И он понимает, почему использует ту или иную технологию, понимает базу и следовательно, способен разобраться в любой ОС (если конечно там есть смысл, а не только потому что мое :) )
Думаю как раз об ътом и комментарий. В современных условиях нельзя быть мастером во всем, сейчас нужна специализация и кооперация, чтобы делать качественные конкурентоспособные вещи. Иначе, все как то не очень получается.
То есть существует ряд проектов, тот же FreeRTOS (если не хотите Embo. И их необходимо использовать, велосипеды нормальная тема, но только для обучения и то, быстро упераешься, что нужно сравнивать с мировым опытом и тогда присоединяйся к opensource
Так вроде я ссылки давал в том числе на их документацию и ПО, ну а Embox открыт (свободен) по определению:)
На счет катастрофической, возможно соглашусь.
На счет вливания бабла со стороны государства, не все так однозначно. Я о нашем печальном опыте осваивать бабло, по отчетам все хорошо, а результат...
Но вот в статье пример, реальной работы (пусть и капли в море) и кстати без вливания гос бабла, хотя мы бы не отказались получить деньги за проделаную работу :)))
Спасибо!
Сами мы пришли скорее из Linux embedded, поэтому нам вообще трудно понять как без командной строки. У вас хорошая статья, но мы постоянно сталкиваемся с мнением, "мне не нужно, значит и вы должны делать, так как я". На попытку объяснить, насколько быстро разрабатывать переносимый и подерживаемый код например (https://habr.com/ru/companies/embox/articles/538416/ или https://habr.com/ru/companies/embox/articles/541662/) мы сталкиваемся с непониманием и утверждением, что нужно все делать чуть ли не бареметал.
У нас кстати, не только UART-CLI, а почти командный интерпретатор почти как в Linux. Показали удобство в статье про файловую систему https://habr.com/ru/companies/embox/articles/573244/ И да, можно зайти telnet ssh и делать тоже самое.
На счет подстветки, спасибо за идею, у нас она реализована в каком то shell через стандартные тертинальные последовательности. Но не получила распространение, не очень востребована. Но посмотрю вашу реализацию, возможно она более гибкая и удобная!
А, да, такое есть. Но, насколько я знаю, оба упомянутых микроконтроллера на Микроне выпускаются. То есть, полностью локализованное производство.
Да, пытаемся так и делать. Вот например смешная довольно история с web-мордой на МК https://habr.com/ru/companies/embox/articles/541662/.
И конечно, когда нужно помигать светодиодом, embox скажем так избыточен. Хотя мы его затаскивали на совсем мелкие устройства https://habr.com/ru/companies/embox/articles/537408/, но выигрыш там сомнителен. С другой стороны, на том же востоке и их маленьким объемом, ребята смогли
цитата из нашего чата :) (Ethenet был на SPI чипе)
И да, на счет накладных расходов Вот статья про файловую систему https://habr.com/ru/companies/embox/articles/573244/ и в ней показано, да есть накладные расходы, но выигрышь от удобства очень ощущается.
Вы все таки определитесь, либо постоянный пиар проекта, либо статьи на тему "прикрутили очередную свистоперделку, потратив всего два дня времени" xD
Но за
Спасибо. Да, Вы правы, где на других RTOS требуется 2 месяца на embox всего два дня. Где полгода, на embox 2-3 недели.
И естественно, не нужно пихать embox везде, если вам мигание светодиодом нужно, FreeRTOS более чем достаточен!
Если хотите продолжать пиарить проект, то вот вам контекст свич как просили https://habr.com/ru/companies/embox/articles/330236/
:)
А что с ними? мы общаемся, надеюсь в обозримом будущем объявим о новых поддерживаемых чипах:)
О каких линуксах речь? embox это не linux
Если речь о средствах разработки то под виндой тоже вполне себе соберется
https://github.com/embox/embox/wiki/Building-and-debugging-embox-on-STM32-using-Win11-wsl2-openocd
А я вижу! И что Вы тратите мое время, вижу. Никаких вопросов Вы не задаете, просто с чего то решили, что вправе мне указывать, что мне делать, учить меня и давать мне зачем то оценку!
Хотите понять Embox читайте статью https://habr.com/ru/companies/embox/articles/440390/ и смотрите видео в которых мы объясняем, зачем это потребовалось и почему не получилось решить вопрос существующими средствами. Отчитываться ни перед кем я не намерен!
Не видите случайно двойных стандартов в ваших идущих подрят двух фразах?
То что описано в статье, сделано не за счет гос финансирования:)
Проблема с доступностью микроэлектроники, к сожалению, серьезная. Дело не в плате как таковой, ее то сделать не проблема, а в самих чипах. Поскольку идея развития технологической платформы и предполагает развитие чипостроения, а для этого нужны не только фабрики для производства кристаллов, но и многое чего другого. Иначе эти кристаллы будут производиться только под гос заказ, и далеьше не пойдет ничего. Я как раз это имел в виду когда говорил про экосистему.
Отличная идея!
Современный мир показывает, что нужно специализироваться, и выстраивать кооперацию (цепочки поставок) иначе не эффективно.
Спасибо, так и делаем!:)