LINUX.ORG.RU

BuguRTOS: версия 0.8.2 и смена хостинга

 , ,


0

2

В связи с предстоящим закрытием хостинга Google code проект ядра встраиваемой операционной системы BuguRTOS переехал на GitHub, на старой странице проекта висит объявление о преезде.

Смена хостинга совпала с обновлением BuguRTOS до версии 0.8.2. В новой версии произошли следующие изменения:

  • Добавлен базовый механизм синхронзации с таймаутами.
  • В планировщик добавлена политика планирования FIFO, дополняющая Round-robin.
  • В дескриптор процесса добавлено поле cnt_lock, флаг состояния процесса PROC_FLG_BLOCK переименован PROC_FLG_LOCK, изменена его обработка (теперь она происходит независимо от обработки поля proc->lres).
  • Удалены неиспользуемые функции.
  • Исправлено три ошибки.
  • В опциях компиляции тестовых проектов для ARM и AVR добавлен флаг -Os.

Также обновлен список запланированных дел, теперь в нем значится перевод тестов для ARM на библиотеку libopencm3 и другие изменения.

Архивы с исходниками и документацию по-прежнему предлагается качать с Gdrive.

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

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: anonymous_incognito (всего исправлений: 2)

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

POHMELFS Евгений написал, ты всё путаешь.

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

Демьяну не повезло, когда они перешли на систимД.

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

Автору не повезло - сделал релиз одновременно с debian.

Поттеринговская подстилка всё равно скоро загнётся, так что ТС вполне нормально дату для релиза выбрал.

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

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

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

Порт STM8 под sdcc не планируется? :(

неожиданно обнаружил, что этот бугурт делан и под STM8. всё равно как распоследний нищеброд я не пользуюсь ничем, кроме sdcc для этой платформы. надо будет посмотреть. обычно портикрование из-под резонанса не очень сложное. надо глянуть в сырьё: чегои сколько наворотил автор

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

есть подозрение, что этот проект может не влезть в память STM8 после компиляции sdcc. из-за совершенно невменяемого оптимизатора у данного компилятора.

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

Когда я глядел на sdcc для stm8, он был адово сырой, например: поддерживалось только 64кб кода, а с учетом реальных карт адресов - 32кб; плюс в трекере висело несколько багов годовалой и более давности. Поэтому порт писать не стал.

Как там сейчас?

Что там с генерацией прологов и эпилогов обработчиков прерываний?

Используются ли «виртуальные регистры», и сколько их?

И да, порт под резонанс написан без асма совсем.

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

Релиз я сделал. Но есть проблема: есть сторонний код, используемый тестами для ARM, в репу этот код не включен, ибо там копирастические файлы могут быть...

Вот когда перейду на libopencm3, тогда всякого стороннего гуано не будет и можно будет пользоваться только релизами.

Там pdf можно в репу сложить?

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

Как там сейчас?

Что там с генерацией прологов и эпилогов обработчиков прерываний?

Используются ли «виртуальные регистры», и сколько их?

И да, порт под резонанс написан без асма совсем.

я в потроха бинарников даже не лазил после того, как неожиданно sdcc мне влинковал в бинарник все неиспользованые функции. от статических библиотек пришлось отказаться, функции, которые используются, копировать руками. почитав их руководство по «эффективному использованию sdcc», выяснил, что switch, for, while и т.д.нужно писать определённой формы если хочешь получить в результате что-то вменяемое.

чесслово, лучше бы появилось что-то использующее llvm, чем вот ЭТО. но, STM8(32 Кб) в наших палестинах чуть ли не в 3-4-5 раза дешевле, чем ATMega(4Кб). так что пока «напоиграться» использую.

но скорее всего переползу на Cortex-M0 от тех же STM, NXP. цена и потребление не сильно отличаются, а использовать гораздо легче именно из-за наличия openocd + gcc-arm

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

Просто он не умеет помещать функции в отдельные секции.

А с циклами и матчами это вообще пушка.

Да уж пока в топку.

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

Попробуй стм, они более часто используются сообществом.

Под них софта больше написано. И лучше м-ноль-плюс, там с электричеством аппетит поменьше вроде как.

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

Попробуй стм, они более часто используются сообществом.

Под них софта больше написано. И лучше м-ноль-плюс, там с электричеством аппетит поменьше вроде как.

лежит их нуклео L058. надо заняться. опять же mbed.org

hawai
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.