Jump to content

    
Sign in to follow this  
Chudik

ChibiOS и STM32L1/NUCLEOL152RE

Recommended Posts

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

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

Share this post


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

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

 

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

Share this post


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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this