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

По уверениям авторов ChibiOS/RT полностью совместим с ChibiOS/HAL, т.е. логично было бы использовать HAL, но те обсуждения, что я видел используют RT, так что, наверное, не стоит оригинальничать sm.gif. Возможно RT опитимизированы. Я это встречал, когда пытался объединить проект из CubeMX (HAL драйверы и изначально делается под Keil) и тестовый пример, создаваемый EMBlocks, в котором многие вещи оптимизированы, т.е. далеко не все регистры 32 битные, есть 16 и 8 битные в зависимости от реального железа. Необходимые изменения ввёл, хэдеры подключил, откомпилировал, но споткнулся на том, что отладчик не хочет работать на Nucleo. Отличия в ассемблерном загрузчике. И вот тут я завис sm.gif Но, по крайней мере, некоторый опыт слияния получил. Возможно, в 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
Читаю текст сообщения, и какой-то разрыв шаблона происходит ... wacko.gif
Цитата(Chudik @ Jan 16 2015, 09:10) *
... в котором многие вещи оптимизированы, т.е. далеко не все регистры 32 битные, есть 16 и 8 битные в зависимости от реального железа.

А вот эта фраза вообще в голове не помещается ...
Chudik
Чему не помещаться? sm.gif
В HAL драйверах все регистры 32 битные. Реально в железе они есть 8 и 16 битные. Мне кажется достаточно очевидным, что использование 8 и 16 битных переменных вместо 32 там, где это возможно, может уменьшить использование памяти для программ и данных.
Для семейства L0 и некоторых L1 это может оказаться весьма актуальным. Там не так много памяти/

Да, вот здесь есть наборы файлов для разных плат
http://ehc.ac/p/chibios/svn/6712/tree/bran...l78_dev/boards/
SasaVitebsk
Вот видите... Оптимизация она разная бывает ...
В каждом конкретном случае будет по разному. Если речь идёт о структурах, то возможно.
Если о предаче параметра, то нет.
Передача параметра в ф-цию и из функции осуществляется через стек. То есть статически память не выделяется. Иными словами глубоко до фонаря, передавать в ф-цию байт или 32 бита. Но при передаче байта компилятор сгенерит значительно более сложную конструкцию. Чаще всего регистров при этом будет больше задействовано, и могут потребоваться дополнительные переменные локальные на стеке.
Короче выигрыш будет именно при применении слова.

HAL написан неэфективно, но это определяется совсем не разрядностью используемых данных
Kabdim
Цитата(Chudik @ Jan 16 2015, 10:23) *
Реально в железе они есть 8 и 16 битные. Мне кажется достаточно очевидным, что использование 8 и 16 битных переменных вместо 32 там, где это возможно, может уменьшить использование памяти для программ и данных.
Для семейства L0 и некоторых L1 это может оказаться весьма актуальным. Там не так много памяти

Очень забавно потом выгребать баги из-за невыравненного обращения к памяти после таких крохоборнических оптимизаций.
Chudik
В общем, в аттаче два файла:
ChibiOS_F429.7z - в качестве референса оригинальный файл примера для emblocks + ChibiOS 2.6.3 созданный автором EmBlocks для F429 Discovery board
ChibiOS_EMBlocks_Blinky.7z - адаптированный проект для STM32L152 Nucleo Board + ChibiOS 2.6.6.
SasaVitebsk
Прошу воспринимать моё сообщение, как мои личные рассуждения.
Выдалась минутка свободная (к сожалению их всё меньше и меньше), и я посмотрел ChibiOS. Бегло, конечно.
Для чего вообще ОС? Собственно для получения определённого уровня абстракции для разработчика, как я понимаю.
Это в свою очередь даёт преимущества при:
1) Переносе готового проекта с камня на камень.
2) Существенном развитии проекта (существенное изменение функционала) или переработки.
3) Работа над проектом в большом коллективе разработчиков. (Независимое написание и отладка разных кусков проекта).
Очевидно, что ChibiOS не исключение. Так например "HAL компонент поддержки различных абстрактных драйверов устройств" входит в явное противоречие с их объявлением о "эффективность и компактный код". То есть они сами подчёркивают что абстрактность является главенствующей над эффективностью. И в этом они пошли дальше FreeRTOS.
Но по выбору камней (см. п.1) они значительно хуже чем FreeRTOS. По поддержке (обновляемость, развиваемость, доработки) они также пока хуже. А эффективность обратно пропорциональна универсализму.
Пробовать что-то новое, конечно можно и нужно.
Вы HAL ChibiOS по верх HAL Cube планируете использовать?
Golikov A.
А я всегда думал что основное назначение ОС - разделение ресурсов между задачами.

halfdoom
Цитата(SasaVitebsk @ Jan 18 2015, 13:59) *
То есть они сами подчёркивают что абстрактность является главенствующей над эффективностью. И в этом они пошли дальше FreeRTOS.
Но по выбору камней (см. п.1) они значительно хуже чем FreeRTOS. По поддержке (обновляемость, развиваемость, доработки) они также пока хуже. А эффективность обратно пропорциональна универсализму.


Там абстракция HALa сводится к общему API, причем абстрактная функция часто определятся через макрос. Оверхед при этом совсем незначителен. Однако главным отличием от FreeRTOS является полная статичность объектов - в подавляющем большинстве случаев никакой динамической аллокации для системных объектов не требуется.
kostyan
Цитата(halfdoom @ Jan 19 2015, 09:32) *
Однако главным отличием от FreeRTOS является полная статичность объектов - в подавляющем большинстве случаев никакой динамической аллокации для системных объектов не требуется.


В режиме heap_1.c фриртосина вполне себе обеспечивает статичность объектов. Имхо главное отличие чибиоси от прочих ртос - добавление абстракции от железа. Но любая абстракция - это дополнительные накладные расходы.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.