LINUX.ORG.RU

BuguRTOS-4.0.0

 , , ,


3

5

Седьмого января 2019 года вышла встраиваемая операционная система реального времени BuguRTOS-4.0.0.

За чуть более чем год с релиза третьей версии BuguRTOS по рекомендациям пользователей linux.org.ru, а так же по собственной инициативе, введены следующие изменения:

  • Добавлен CoC. Разработчики BuguRTOS рады приветствовать разработчиков в нашем инклюзивном сообществе.
  • Добавлены API программных таймеров, позволяющие осуществлять точную синхронизацию процессов по времени.
  • Добавлены проверки на нулевые указатели на входе функция библиотеки native API.
  • Добавлен extern «C» для проектов на C++.
  • Добавлен ASSERT для последующей переработки тестов.
  • Добавлен порт на Cortex-M7.
  • Переработаны пространства имен Ядра и библиотеки native API.
  • Исправлен стиль комментариев.
  • Планировщик отвязан от слоя виртуализации прерываний и переработан.
  • Изменен подход к сбережению энергии. Теперь операции, связанные с энергосбережением, выполняются только в режиме ядра.
  • Исправлен API для макроса BGRT_KBLOCK_HPFIC_HOOK.
  • Исправлено неправильное поведение программных таймеров при переполнении таймера Ядра.
  • Тесты перенесены на обновленную libopencm3.
  • Из библиотеки native API удалены сигналы.
  • Удалены ненужные файлы.
  • Обновлена документация.

Разработчики BuguRTOS желают всем счастливого Нового года и Рождества, а KRoN73 скорейшего выздоровления.

>>> Подробности

Ответ на: комментарий от Vit

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

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

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

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

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

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

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

shkolnick-kun ★★★ ()

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

Rupricht ()
Ответ на: комментарий от Rupricht

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

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

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

shkolnick-kun ★★★ ()
Ответ на: комментарий от shkolnick-kun

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

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

Vit ★★★★★ ()
Ответ на: комментарий от shkolnick-kun

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Odalist

Кстати, про CoC

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

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

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

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

Такие дела.

shkolnick-kun ★★★ ()
Последнее исправление: shkolnick-kun (всего исправлений: 4)

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

anonymous ()
Ответ на: комментарий от hakavlad

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

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

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

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

EXL ★★★★★ ()
Ответ на: "сделать переносимый аналог Колибри" от anonymous

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

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

hobbit ★★★★★ ()
Ответ на: "сделать переносимый аналог Колибри" от anonymous

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

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

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

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

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

anonymous ()

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

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

Gargamel ()
Ответ на: Кстати, про CoC от shkolnick-kun

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

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

Gargamel ()

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

anonymous ()
Ответ на: комментарий от Gargamel

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

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

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

shkolnick-kun ★★★ ()
Последнее исправление: shkolnick-kun (всего исправлений: 1)

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

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

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

torvn77 ★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от torvn77

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

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

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

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

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

shkolnick-kun ★★★ ()
Ответ на: комментарий от shkolnick-kun

Порта на AR100

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

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

anonymous ()
Ответ на: комментарий от torvn77

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

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

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

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

shkolnick-kun ★★★ ()
Ответ на: комментарий от hobbit

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

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

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

anonymous ()
Ответ на: "сделать переносимый аналог Колибри" от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от Deleted

ButtHURD

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

anonymous ()