[Chudik 0]

Делаю сейчас проект на 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, который предлагает создать структуру для своей платы по образу и подобию.

Внимание вопрос: кто нибудь это делал? Для тестовой платы или для своей? Может быть кто-то может поделиться либо файлами, либо хотя бы методой формирования.

 

[SapegoAL 0]

Читаю текст сообщения, и какой-то разрыв шаблона происходит ...

... в котором многие вещи оптимизированы, т.е. далеко не все регистры 32 битные, есть 16 и 8 битные в зависимости от реального железа.

А вот эта фраза вообще в голове не помещается ...

 

[Chudik 0]

Чему не помещаться? :)

В HAL драйверах все регистры 32 битные. Реально в железе они есть 8 и 16 битные. Мне кажется достаточно очевидным, что использование 8 и 16 битных переменных вместо 32 там, где это возможно, может уменьшить использование памяти для программ и данных.

Для семейства L0 и некоторых L1 это может оказаться весьма актуальным. Там не так много памяти/

 

Да, вот здесь есть наборы файлов для разных плат

http://ehc.ac/p/chibios/svn/6712/tree/bran...l78_dev/boards/

[SapegoAL 0]

Вот видите... Оптимизация она разная бывает ...

В каждом конкретном случае будет по разному. Если речь идёт о структурах, то возможно.

Если о предаче параметра, то нет.

Передача параметра в ф-цию и из функции осуществляется через стек. То есть статически память не выделяется. Иными словами глубоко до фонаря, передавать в ф-цию байт или 32 бита. Но при передаче байта компилятор сгенерит значительно более сложную конструкцию. Чаще всего регистров при этом будет больше задействовано, и могут потребоваться дополнительные переменные локальные на стеке.

Короче выигрыш будет именно при применении слова.

 

HAL написан неэфективно, но это определяется совсем не разрядностью используемых данных

[Kabdim 0]

Реально в железе они есть 8 и 16 битные. Мне кажется достаточно очевидным, что использование 8 и 16 битных переменных вместо 32 там, где это возможно, может уменьшить использование памяти для программ и данных.

Для семейства L0 и некоторых L1 это может оказаться весьма актуальным. Там не так много памяти

Очень забавно потом выгребать баги из-за невыравненного обращения к памяти после таких крохоборнических оптимизаций.

[Chudik 0]

В общем, в аттаче два файла:

ChibiOS_F429.7z - в качестве референса оригинальный файл примера для emblocks + ChibiOS 2.6.3 созданный автором EmBlocks для F429 Discovery board

ChibiOS_EMBlocks_Blinky.7z - адаптированный проект для STM32L152 Nucleo Board + ChibiOS 2.6.6.

ChibiOS_EMBlocks_Blinky.7z

ChibiOS_F429.7z

[SapegoAL 0]

Прошу воспринимать моё сообщение, как мои личные рассуждения.

Выдалась минутка свободная (к сожалению их всё меньше и меньше), и я посмотрел ChibiOS. Бегло, конечно.

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

Это в свою очередь даёт преимущества при:

1) Переносе готового проекта с камня на камень.

2) Существенном развитии проекта (существенное изменение функционала) или переработки.

3) Работа над проектом в большом коллективе разработчиков. (Независимое написание и отладка разных кусков проекта).

Очевидно, что ChibiOS не исключение. Так например "HAL компонент поддержки различных абстрактных драйверов устройств" входит в явное противоречие с их объявлением о "эффективность и компактный код". То есть они сами подчёркивают что абстрактность является главенствующей над эффективностью. И в этом они пошли дальше FreeRTOS.

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

Пробовать что-то новое, конечно можно и нужно.

Вы HAL ChibiOS по верх HAL Cube планируете использовать?

[Golikov 0]

А я всегда думал что основное назначение ОС - разделение ресурсов между задачами.

 

 

[halfdoom 0]

То есть они сами подчёркивают что абстрактность является главенствующей над эффективностью. И в этом они пошли дальше FreeRTOS.

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

 

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

[kostyan1 0]

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

 

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