ChibiOS и STM32L1/NUCLEOL152RE, Связываем ChibiOS/RT с этой платой под EM::Blocks Опции

[Chudik]

Делаю сейчас проект на STM32L152. Очень хочется его сделать под RTOS. FreeRTOS не хочу (где-то здесь описывал проблемы с ней, повторяться не хочу). Поскольку EM::Blocks поддерживает отладку в ChibiOS, то выбор пал на эту систему. Тем более, что авторы системы постарались - там есть поддержка SD/MMC карточек, FAT, USB... что-то ещё.

По уверениям авторов ChibiOS/RT полностью совместим с ChibiOS/HAL, т.е. логично было бы использовать HAL, но те обсуждения, что я видел используют RT, так что, наверное, не стоит оригинальничать . Возможно RT опитимизированы. Я это встречал, когда пытался объединить проект из CubeMX (HAL драйверы и изначально делается под Keil) и тестовый пример, создаваемый EMBlocks, в котором многие вещи оптимизированы, т.е. далеко не все регистры 32 битные, есть 16 и 8 битные в зависимости от реального железа. Необходимые изменения ввёл, хэдеры подключил, откомпилировал, но споткнулся на том, что отладчик не хочет работать на Nucleo. Отличия в ассемблерном загрузчике. И вот тут я завис Но, по крайней мере, некоторый опыт слияния получил. Возможно, в ChibiOS/RT сделана аналогичная оптимизация обращений к портам.

Автор EM::Blocks выложил пример проекта для этой системы для платы STM32F4Discovery

Естественно, простейший. Но это непринципиально - главное стартануть.
Если распаковать этот архив, загрузить проект в среду и откомпилировать, то всё чудненько компилируется (код великоват, конечно - 15к, но пока ладно).
Анализ структуры проекта показало те места, которые надо менять: это секция описания собственно процессора и используемой платы. Исследование входящих файлов привело к нахождению директории, где лежат описания всех поддерживаемых на данный момент процессоров:
...\ChibiOS_F429\Lib.Embedded.ChibiOS\os\ports\GCC\ARMCMx
Т.е. для F4: ...\ChibiOS_F429\Lib.Embedded.ChibiOS\os\ports\GCC\ARMCMx\STM32F4xx
Для L1: ...\ChibiOS_F429\Lib.Embedded.ChibiOS\os\ports\GCC\ARMCMx\STM32L1xx

Исключаем в проекте соответствующие файлы и подключаем новые.

Теперь есть директория
...\ChibiOS_F429\Lib.Embedded.ChibiOS\boards, а в ней ST_STM32F429I_DISCOVERY и файл readme.txt, который предлагает создать структуру для своей платы по образу и подобию.
Внимание вопрос: кто нибудь это делал? Для тестовой платы или для своей? Может быть кто-то может поделиться либо файлами, либо хотя бы методой формирования.

[SasaVitebsk]

Прошу воспринимать моё сообщение, как мои личные рассуждения.
Выдалась минутка свободная (к сожалению их всё меньше и меньше), и я посмотрел ChibiOS. Бегло, конечно.
Для чего вообще ОС? Собственно для получения определённого уровня абстракции для разработчика, как я понимаю.
Это в свою очередь даёт преимущества при:
1) Переносе готового проекта с камня на камень.
2) Существенном развитии проекта (существенное изменение функционала) или переработки.
3) Работа над проектом в большом коллективе разработчиков. (Независимое написание и отладка разных кусков проекта).
Очевидно, что ChibiOS не исключение. Так например "HAL компонент поддержки различных абстрактных драйверов устройств" входит в явное противоречие с их объявлением о "эффективность и компактный код". То есть они сами подчёркивают что абстрактность является главенствующей над эффективностью. И в этом они пошли дальше FreeRTOS.
Но по выбору камней (см. п.1) они значительно хуже чем FreeRTOS. По поддержке (обновляемость, развиваемость, доработки) они также пока хуже. А эффективность обратно пропорциональна универсализму.
Пробовать что-то новое, конечно можно и нужно.
Вы HAL ChibiOS по верх HAL Cube планируете использовать?

[halfdoom]

То есть они сами подчёркивают что абстрактность является главенствующей над эффективностью. И в этом они пошли дальше FreeRTOS.
Но по выбору камней (см. п.1) они значительно хуже чем FreeRTOS. По поддержке (обновляемость, развиваемость, доработки) они также пока хуже. А эффективность обратно пропорциональна универсализму.

Там абстракция HALa сводится к общему API, причем абстрактная функция часто определятся через макрос. Оверхед при этом совсем незначителен. Однако главным отличием от FreeRTOS является полная статичность объектов - в подавляющем большинстве случаев никакой динамической аллокации для системных объектов не требуется.

[kostyan]

Однако главным отличием от FreeRTOS является полная статичность объектов - в подавляющем большинстве случаев никакой динамической аллокации для системных объектов не требуется.

В режиме heap_1.c фриртосина вполне себе обеспечивает статичность объектов. Имхо главное отличие чибиоси от прочих ртос - добавление абстракции от железа. Но любая абстракция - это дополнительные накладные расходы.