Добрый день. Изучаю CMake в среде разработки VScode на примере мк stm32f411ceu6. Код пишу на cmsis. Хочу попробовать внедрить в проект FreeRTOS Может есть у кого нибудь шаблон проекта из изходников ( без использования куба, кейла и т.д.)?

Что-то мне не верится, что на cmake проще написать подобную штуку, нежели Makefile вручную забульбенить!..
// что до ртоси, я совершенно против внедрения этого дерьма на микроконтроллеры! Если у тебя не получается на конечных автоматах сделать, то нефиг и лезть в это дело!!! А то эдак можно и до аллокаторов докатиться…

Есть классный проект https://github.com/ObKo/stm32-cmake
Там и FreeRTOS, и CMSIS (да и SPL/HAL тоже, да простит меня Эдуард) можно автоматически подтянуть с github.

Создавать автоматику для закачки чего-то из тырнета - совсем не промышленная история. Это отлично для одиноких сэмплов. А вот обеспечить повторяемость спустя года - это уже будет под вопросом. Посему - в CMake лучше реализовать все шаги для конкретного проекта, а вот подтягивать зависимости (причём не ввиде исходников а полноценных либ = для данного таргета) это вот внешняя по отношению к CMake-у автоматизация. Если система хранения гитлаб/гитхаб то тут CI/CD gitlaba/githuba идеально ложиться. Ну соответственно Вы подтягиваете не из тырнетов не понятно что, и без гарантии спустя время - а со своего прокси, типа сонатайп нексуса(рекомендую) стоящего во внутреннем контуре производства.

удачи Вам
(круглый)

linux_rulezz, Ну у всего ведь есть свои преимущества и недостатки. РТОС очень легко дополнять и обновлять. Да и как то там безопаснее все же... Не простой монолит как в суперлуп.

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



удачи Вам
(круглый)
ЗЫ
Кстати РТОС обычно поддерживают и не вытесняющий принцип работы а это = суперлуп

Вот именно. И их куда как больше… Начиная с излишней растраты ресурсов и снижения производительности и заканчивая зависимостью от кривизны рук того, кто эту ртось написал. В общем, надежность на нуле. Да и код излишне сложным получается. И отлаживать хрен пойми, как…
Кстати, как любители ртоси обходятся без systick - тратят на эти нужды другой таймер? А как умудряются запускать ртось без аллокаторов - или таки пользуются этой дрянью?

Говорила мне мама с троллями не связываться, а я не послушал...
Вы полный профан в программировании микроконтроллеров с RTOS.
Во-первых, FreeRTOS работает на любом таймере, хоть на систик, ей всё равно, откуда брать кванты времени.
Во-вторых, оверхед нагрузки не превышает 1-3%, и это доказано измерениями на самых слабых контроллерах, с тактовой частотой 40-60 мегагерц.
В третьих, нормальной практикой считается статическое выделение памяти под задачи, это же прописано в правилах безопасной разработки программ MISRA.

Ваше невежество видно невооружённым глазом, даже пованивает.

GARMIN, да мне плевать. Я ртось не использовал, не использую и не собираюсь использовать. Не существует таких задач, которые не решались бы конечными автоматами!
Кстати, я достаточно много чужого говнокода в интернетах видел. В 100% случаев, где автор пользовался бы ртосью, это был адов быдлокод на основе абдурины или калокуба. И ртось там была "просто потому, что пример так напейсали".

Кроме того: РТОС может вообще не использовать никакой таймер. Если в программе не использовать функции типа "приостановить задачу на N тактов" или "ожидать события X с таймаутом T" (т.е. - не использовать никакие функции связанные с временем), то можно вообще не отдавать никакого периодического прерывания РТОС-у.

ЗЫ: Речь не конкретно про FreeRTOS, а про РТОС-ы в целом.

Добавлено after 2 minutes 36 seconds:
Точно. А на МК класса ТС - доли %.

Я думаю, что вы не правы. RTOS нужен таймер для переключения контекста задач по времени. Но я ни разу не писал программу с RTOS без системного таймера.

Я думаю, что я абсолютно прав. Так как имею (и использую) собственную РТОС для Cortex-M. И совершенно точно знаю - как правильно переключать контекст на Cortex-M. Потому как сам это писал.
Для переключения контекста никакой таймер не нужен от слова "совсем". Переключение контекста РТОС на Cortex-M производится в прерывании PendSV. Которое собственно ради этого и создано.

А если не верите - изучите Cortex-M-порт любой РТОС. Например - uCOS-II. Там ясно видно как переключается контекст.

Конечно, программное прерывание используется для переключения контекста. Собственно, одно из двух, используемых RTOS. Скорее всего, я не до конца объяснил свою мысль.
Есть две задачи с одинаковым приоритетом. Они периодически отдают управление планировщику задач. Во всех учебниках была картинка с графиком переключения этих задач по системному времени. То есть одну миллисекунду работает одна задача, вторую - другая.
Я думаю, системный таймер нужен, чтобы не переключать задачи слишком быстро, не загружать контроллер бессмысленным переключением контекста.
Возможно это не так, поясните.

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

Вы невнимательно читаете то, на что отвечаете. Я писал:
В этом случае таймер не нужен. А вы опять пишете про случай использования каких-то таймингов.

Ещё раз: Использование каких-либо времязадающих условий при вызове функций RTOS - это опциональная вещь. Реальная конкретная программа может не использовать ни одну из таких функций. Если программист способен так построить алгоритм решения задачи. За всю свою многолетнюю практику с МК, я ни разу не использовал задачи с одинаковым приоритетом. Не испытывал в этом никакой нужды. А то, что например в uCOS-II даже и возможности такой нет (давать задачам одинаковый приоритет), говорит о том, что не я один такой.
Да и функции РТОС, требующие каких-то времязадающих параметров (таймауты и т.п.) я тоже использую редко. И (имхо) - очень часто их используют там, где они совершенно не нужны. Или используют для "заметания г* под ковёр".

Добавлено after 56 seconds:
Не знаю где именно "имеется в виду", но я всегда говорил о вытесняющей.

Итого: PendSV - это прерывание необходимое для работы вытесняющей РТОС, а вот периодическое прерывание (SysTick или любое другое) - опциональное.

У меня есть пример: `https://github.com/ViacheslavMezentsev/demo-stm32-cmake/tree/main/stm32f4xx/ethernet-rndis-nicokorn`

Но я ушёл от прямой настройки cmake в его конфигурирование через yml. Более ранние ревизии содержат пример как собирать проект под cmake без yml. Дальше доработать напильником.

Я вот видел достаточно чужого кода. И могу сказать, что из всех случаев применения РТОС ее впилили туда просто "потому что могëм", а не потому что она реально нужна была. В итоге народ теряет ресурсы задарма, да еще и производительность проседает.
Ну и с РТОСями возникают новые проблемы: например, отсутствие атомарных операций в "младших ARMянах" → приходится выдумывать обходной путь с этими LDREX/STREX, что, опять же, снижает производительность.
Самый элементарный и проще всего отлаживаемый путь — старые добрые конечные автоматы.

Выскажу некоторые моменты по РТОС.
В целом, самая частая причина использования РТОС - избавление от ручного решения проблемы распределения процессорного времени. Особенно это актуально при значительном числе выполняющихся задач или значительном времени выполнения каждой задачи.
РТОСы делятся на системы "жесткого" и "мягкого" реального времени. Вытесняющая операционка - система "жесткого" времени, когда передача управления планировщику происходит через заданные интервалы времени. Кооперативная операционка - система "мягкого" времени, когда вызов планировщика инициируется программно из каждой задачи.
Заметьте, не переключение задач, а именно передача управления планировщику! А планировщик уже решит, переключить задачу или оставить эту же самую, руководствуясь настройками приоритетов и списком ожидающих задач.

Тут кое-кто сказал, что для ВЫТЕСНЯЮЩЕЙ операционки не нужен таймер системных тиков. Но это неверно. Принцип ВЫТЕСНЯЮЩЕЙ операционки основан на прерывании (вытеснении) выполнения задачи на любом её шаге, в отличие от КООПЕРАТИВНОЙ операционки с явным вызовом планировщика из текущей задачи.
Внешний сигнал передачи управления в вытесняющей операционке поступает именно с периодичностью системных тиков, отсчитываемых аппаратным таймером.

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

Так что, следует правильно использовать эти понятия, чтобы в среде программистов вас правильно понимали. Поскольку здесь как раз и возникло недопонимание из-за того что один из участников подразумевал совсем другое. Если сомневаетесь в правильности, загуглите инфу!

Итого:
- В вытесняющей РТОС текущая задача вытесняется планировщиком по внешнему сигналу без желания самой задачи. Таким сигналом служит периодический таймер. Этим таймером может быть любой аппаратный таймер или иной периодический аппаратный сигнал. Логичнее всего конечно таймер микроконтроллера.
- В кооперативной РТОС текущая задача сама инициирует передачу управления планировщику. Она НЕ вытесняется, а передает управление явно, вызовом соответствующего инструментария.
Это общепринятые понятия и их следует придерживаться в среде программистов, чтобы коллеги тебя понимали.


Второй момент.
Подавляющее число программ, кроме самых примитивных, так или иначе используют в работе различные тайминги, периодические и непереодические. Даже мигание светодиодом использует тайминги. Начинающие конечно вместо таймера напишут блокирующий цикл for() для создания задержки. Более продвинутый ученик напишет хотябы программный счетчик, инкрементирующийся в главном цикле и будет сравнивать его значение с пороговым.
Но в основном программисты опираются на какой-либо аппаратный таймер, создающий стабильную базу тиков. И построение системы таймеров - важная составляющая подавляющего большинства программ. Опрос механической клавиатуры, периодический опрос датчиков, времязависимые процессы - они не могут работать без подсистемы отсчета времени. Причем, этот отсчет времени должен иметь достаточную стабильность периодов и независимость от текущей выполняемой задачи.
Без системы отсчета времени в общем то может работать программа, реализованная по принципу "запрос-ответ". Но как правило таких программ не так уж и много и они достаточно просты и не требуют РТОС как таковой, поскольку их структура имеет мало зависимостей.

Бред.

Снова бред.
Никакого обязательного "сигнала передачи управления" поступающего "с периодичностью системных тиков" в РТОС не нужно в принципе. В общем случае - программа сама решает когда запросить вытеснение задачи. И может это делать вообще без каких либо таймеров или любых других периодических процессов.
В какой-то конкретной реализации многозадачности могут присутствовать некие опциональные периодические процессы, что-то там переключающие периодически. Но это именно - опциально, для данного случая и никак не относится к обязательным элементам вытесняющей РТОС.

Снова бред.
PendSV инициируется только при наличии запрошенного переключения задач. Никакой периодической его инициации по таймеру - не нужно. Перемешали мух с котлетами. Таймер - отдельно (и опционален), PendSV - отдельно.

Мне "гуглить" ничего не надо. Так как я сам писал свою вытесняющую РТОС. А также писал порты для существующих вытесняющих РТОС (uCOS-II). Потому - прекрасно знаю внутреннюю кухню РТОС и не по-наслышке (из инетика), а на своём собственном опыте.
Можно полюбопытствовать: Сколько своих вытесняющих РТОС (или портов для готовых РТОС) вы написали?

Да ладно! Например: программа управления BLDC-мотором со встроенным HTTP(S)-сервером, несколькими чипами FLASH/FRAM + датчиками сидящими на общей шине SPI и кучей других плюшек - "недостаточно сложна"? И как именно прикажете такой программе обслуживать тяжёлые запросы от HTTP(S)-клиентов, не мешая работе управления мотором и работе диспетчера SPI без вытесняющей ОС? И ведь для всего этого никакой периодический таймер не нужен:
Задача HTTP-сервера вызывается задачей TCP-стека, которая в свою очередь вызывается ISR Ethernet.
Задача управления мотором - вызывается ISR АЦП (например или из любого другого удобного ISR).
Задача диспетчера транзакций SPI - вызывается из ISR SPI и из ISR SPI-DMA.
И на кой тут периодически вызывать некий "планировщик"? (которого кстати в вытесняющих ОС как правило нет) Можете объяснить?


PS: В качестве ликбеза - загуглите "tickless OS". Та же вики https://en.wikipedia.org/wiki/Tickless_kernel говорит:
"A tickless kernel is an operating system kernel in which timer interrupts do not occur at regular intervals, but are only delivered as required."
Также советую изучить потроха например uCOS-II. Посмотреть как там устроено переключение задач и планирование этого переключения. И что там делается внутри прерывания таймера. Чтобы не нести бред как выше.

Молодец. Только это НЕ вытесняющая РТОС
Вы были неверно информированы, потому и заблуждаетесь. А если бы загуглили с самого начала, что есть вытесняющая, а что кооперативная РТОС, то сразу бы и не совершили столько ошибок.

Скажите, по какому сигналу у вас переключаются задачи? То есть, в задаче вы вызываете механизм передачи управления?