Пока нет.

Тут не всё так однозначно.

У BuguRTOS ядро выполняется в отдельном потоке, соответственно, есть возможность сэкономить на стеках процессов.

С другой стороны, это значит, что любой системный вызов - это два переключения контекста, а не 0-1, как у других ОСей.

Кроме того, в BuguRTOS нет костылей и таргет-специфичных спидхаков планировщика.

Соответственно, если взять Cortex-M3 и померять по DWT, сколько тактов занимает, например, освобождение семафора, то у BuguRTOS будет примерно 1680 тактов против примерно 1000 у одной известной свободной RTOS.

При этом, в BuguRTOS ядро полностью вытесняемое, соответственно обработка ВНЕЗАПНО поступившего прерывания начнется уже через примерно 210 тактов.

На Cortex-M3 и выше это не даст ощутимого преимущества, т.к. там есть регистр basepri, но на Cortex-M0-M1 таки даст, так как там приходится запрещать прерывания во время выполнения Ядерного кода…

так и вижу, SiPhone на базе TROOBA с поддержкой e-Sink

Я уже высказывал свое мнение о ненужности™ RTOS на микроконтроллерах, однако, это не значит что оно ни кому не нужно. Думаю все со мной согласятся, что проекту не хватает простых примеров, типа моргания светодиодом, ШИМ или USB, и все это в пару строк и не зависимо от типа контроллера, и т.п. Сейчас же мне просто лень разбираться с тем, что мне скорее всего не нужно™. Также порт на ESP8266 может быть пригодился бы, т.к. сама архитектура подразумевает наличие RTOS.

Тут все просто, если задача такова, что:

• Трудно реализуется в виде конечных автоматов (либо на это нет времени)
• Есть немного оперативы.

То тогда надо использовать RTOS. При правильном использовании сэкономишь FLASH-память, разгрузишь CPU, сбережешь энергию, сократишь время и стоимость разработки (ниже требования к квалификации исполнителей).

Примерно понятно. Для «тонких ценителей» :).

А ты не встречал на сях аналогов https://github.com/japaric/cortex-m-rtfm ? Там вроде как получаются плюсы от абстракций типа тасков и сообщений, но не приходится уродоваться со стеком.

Аналогов на Сях библиотеки на Rust???

Как минимум не получится гарантировать свободу от дедлоков (ну почти)!

Надо будет придумать, куда можно воткнуть твою RTOS

ржевский, молчать!!!

Оригинал был на сях, но благополучно протух.

Дедлоки - не та проблема, с которой вообще есть смысл заморачиваться. Гарантии это конечно хорошо, но на практике нужны гораздо более простые вещи - абстракции типа тасков и сообщений, чтобы удобно расписать 3-5 изолированных задач. Тащить под такое контексты конечно можно, но явно перебор.

Без кока жизнь уже не та...

бугурт ос

Кстати, про CoC

Индусы опять поломали GitHub здравый смысл.

Они считают, что у проекта нет CoC и предлагают на выбор следующие сорта коричневой субстанции:

• Contributors covenant (без комментариев);
• Citizen CoC, согласно которому основная цель проекта не создание свободной ОСРВ, а, цитирую:

быть инклюзивным наибольшему числу разработчиков с самым разнообразным бэкграундом, который только возможен.

Такие дела.

Индусы

Везде эти индусы....к черту их.

Осталось только сделать ОСью (c от отечественных создателей дистров) для смартфонов. После этого и заживём! (тут намёк на Symbian):D

"сделать переносимый аналог Колибри"

... можно, например, из https://github.com/embox/embox (отечественная ОСРВ, полноценно поддерживающая x86, ARM, Microblaze, и, постольку-поскольку - MIPS, SPARC и POWER).

предлагают на выбор следующие сорта коричневой субстанции

Ссылочку на issue, пожалуйста. Ко мне в nohang тоже приходил SJW-бот, например.

Скорей надо спроситьЖ а что надо купить на алиэкспресс чтобы поставить субж на поиграцца?

Ссылочку на issue, пожалуйста. Ко мне в nohang тоже приходил SJW-бот, например.

Про подобное. Недавно заметил, что на GitHub’е появился сквад собранный по программе Outreachy, который выискивает ошибки и опечатки в ReadMe-файлах популярных проектов и делает соответствующие PR’ы.

Пример: https://github.com/pulls?q=is%3Apr+author%3Amanaswinidas+archived%3Afalse+is%3Aclosed

Несомнненно, эти девушки (?) делают добрые хоть и малополезные дела.

Несомнненно, эти девушки (?) делают добрые хоть и малополезные дела.

ну да, а потом будут везде рассказывать что ихний код повсюду :-)

Да, я с разработчиками EmBox немножко общался на первом OS Day. Но у них с публичными ресурсами неразбериха какая-то. Сначала хостились на гуглокоде, после его смерти переползли на гитхаб, но на гуглокоде кроме собственно кода были интересные доки, в т.ч. на русском, так вот теперь я их найти нигде не могу...

Но проект интересный и с кучей платформ.

полноценно поддерживающая x86, ARM

без виртуальной памяти ? посмотрел видео про историю создания

https://www.youtube.com/watch?v=ol2vyPdZPSE

через пару лет разработки к ним пришло осознание что они просто переписывают Linux, только зачем-то для микроконтроллеров. Понятно что деньги не пахнут - можно годами дрочить вприсядку.

Из библиотеки native API удалены сигналы.

Реализация сигналов была перемещена куда-то ещё или вообще удалена? Если удалена, что тогда вместо сигналов в ОС юзается?

быть инклюзивным наибольшему числу разработчиков с самым разнообразным бэкграундом, который только возможен.

Здрасте, у меня крайне разнообразный бэкграунд(опытный разработчик в среде Кумир), возьмёте меня?!?!?!

CoC великолепен! 5 баллов, моё почтение..
проект прекрасен, мечта - участвовать, но «увы»(ц), квалификация давно потеряна..
моё почтение, Господа!

Это не те сигналы.

Вместо них счас условные переменные.

Сейчас я поступлю очень предсказуемо...

Здрасте, у меня крайне разнообразный бэкграунд(опытный разработчик в среде Кумир), возьмёте меня?!?!?!

https://github.com/shkolnick-kun/bugurtos/blob/master/CODE_OF_CONDUCT.md

Мопед не мой, я только разместил объяву. https://github.com/mniip/wtfcoc

Это великолепно, это то, что нужно

shkolnick-kun, на всяких Cortex-M7 есть четыре сопроцессора которыми очень удобно управлять GPIO, если надо создать синал частотой сотню другую килогерц и более. Такие сигналы создаются в ЧПУ станках управляющих моторами по протоколу step/dir.

Применительно Cortex-M7 задействование этих сопроцессорв столкнулось с проблемой *Re: LinuxCNC + Orange Pi #552*.

Как у твоей Bugurt_OS обстоят с этим дела и насколько она готова для запуска LinuxCNC?

Как у твоей Bugurt_OS обстоят с этим дела и насколько она готова для запуска LinuxCNC?

BuguRTOS не поддерживает POSIX и у него нет API по типу RTAI/XENOMAI, которые, насколько я слышал, раньше использовались в LinuxCNC.

Порта на AR100/OpenRISC тоже пока нет даже в проекте.

Соответственно, ответ - никак.

Кстати, насколько я понял из этого треда, AR100 таки запустили и проблемы вроде больше нет.

И PREEMPT не поддерживает?
А в чём тогда смысл BuguRT_OS?
Я и подумать не мог что ты не поддерживаешь ни одного из RT API.

Порта на AR100

Ты не понял, в Cortex-M7 это просто сервисный сопроцессор с очень ограниченными возможностями в который закачивают бинарник которым реализуется какой нибудь функционал, например watchdog таймер или генератор шагов.

то есть будет ли твоя ОС способна запускать на нём бинарники?

а правда что у вас косынка реалтаймовая?

И PREEMPT не поддерживает? А в чём тогда смысл BuguRT_OS?

Смысл в том, что это библиотека, которая делает многозадачность и синхронизацию задач.

Я и подумать не мог что ты не поддерживаешь ни одного из RT API.

Поддерживаю. Вот: https://github.com/shkolnick-kun/bugurtos/tree/master/libs/native

Cortex-M7 это просто сервисный сопроцессор

Ссылку на документацию можно?

Вот единственное, что я нашел по AR100: http://linux-sunxi.org/AR100

Да, я с разработчиками EmBox немножко общался на первом OS Day. Но у них с публичными ресурсами неразбериха какая-то. Сначала хостились на гуглокоде, после его смерти переползли на гитхаб, но на гуглокоде кроме собственно кода были интересные доки, в т.ч. на русском, так вот теперь я их найти нигде не могу...

Тут добрые люди подсказали, что есть в архиве в том числе и русская версия ( http://web.archive.org/web/20160105031702/https://code.google.com/p/embox/wik... )

И как раз сейчас активно работаем над новой версией документации :)

постольку-поскольку - MIPS, SPARC и POWER

C PPC соглашусь, а вот с MIPS и SPARC уточню, а в чем заключается ограниченность поддрежки? Обе поддержаны только для 32 разрядных версий, это правда. Но в качестве SPARC v8 поддержан процессор leon (2 и 3) c достаточным набором переферии. На qemu просто нет поддержки сетевухи для данной платформы. MIPS тоже поддержали пару небольших платформ, но для qemu в том числе и сеть работает. и telnetd + httpd включены по умолчанию в темплейт mips/qemu

ButtHURD

Лежу на полу. Такими темпами скоро будет создана альтернатива ядру товарища Троллвальдса. Название проекта, кстати, весьма символичное.

Вот, проект явно будет популярным!