Операционная система FreeRTOS. Самый полный курс на русском языке. Часть 5. Управление памятью. 

Спасибо.

Здравствуйте! Что за лекции, если не секрет?

Спасибо.

Динамическое выделение требуется, если у вас не хватает памяти, если дефицита нет - то и в динамике смысла нет. Это объективно. Тем более если вы не сами пишете аллокаторы(или хотя бы не имеете исходников) - то это в принципе не безопасно. Достаточно вспомнить гнушый аллокатор используемый той же atmel studio.

Это граница находится в голове каждого из нас. Как профессионалы мы должны знать и владеть технологиями. А какую технологию применить в каждом конкретном проекте должны решать вы. Вы как разработчик как автор, как инженер.

Все помнят стека задаче не хватало

Пересмотрел. Да, действительно, ка минимум 4я схема тоже приостанавливает переключение задач для безопасности. Но, думаю, Владимиру не нравится что мы встаем в зависимость от "каких-то там" библиотек и компиляторов. Типа, ждать Фриэртэосовский малок - это хорошо, а ждать непонятночей (и при этом у всех разный) малок - это плохо.

@@johnkoffee не уверен что в принципе есть возможность сделать потокобезопасный маллок, не объявился маллок критической секцией кода.

да, этот момент очень странный. Но вообще 3ий вариант плох как минимум тем, что не всегда есть исходники аллокаторов конкретной используемой реализации стандартной библиотеки, а некоторые и в принципе опасно использовать

@@dmitryveselov5546 Да, очевидно именно дефицит памяти и есть причина динамического ее использования.

Нет проблем нету.

Разные. Только это не глупый вопрос

@@VladimirMedintsev спасибо

На это есть отдельное видео.

МК

Они размещаются на стэке для этой задачи.

Вот тут непонятка. когда компилятор видит вызов любой функции он генерирует создание стекового фрейма для этой функции в котором есть память под все локальные переменные. Если утверждается что локальные переменные функций лежат в стеке фриртос то возникает вопрос - откуда компилятор в момент сборки бинаря знает где стек этой конкретной задачи freeRtos? компилятор понятия не имеет ни о том что какаято фриртос существует, ни темболее о том сколько у нас задач и темболее что у этих задач есть какойто фриРтосовый стек! Нестыковочка, что локальные переменные в стеке задач. Если я выделю всю ram контроллера под кучу фриРтос и фриРтос напилит там стеки под свои задачи (а напилит он их там уже в рантайме) то никак не получается компилятору об этом знать на момент компиляции! Тут идея в другом: есть системный стек контроллера (где будут лок переменные функций) и его параметры заданы в конфиге файл *xx.s и стек микроконтроллера движется от макс адресов вниз. А стеки задач фриртос, tcb, и то что выделяется malloc-ами растет снизу вверх (от меньших адресов). поэтому они встретятся только тогда когда память исчерпается. Утверждение что стек микроконтроллера используется только для прерываний - не верно. Для функций (всех) тоже используется он же. В стеках задач фриртос сохр регистры контроллера когда задачу вытесняют и восстанавливают их оттуда (регистры) когда задача получает процессорное время.

Временные переменные это локальные или динамические?

@@Ololoshize это когда ты пишешь функцию и внутри определил переменную int i=0; например. она живет пока выполняется тело функции, а адрес ее в системном (НЕ фриртосовом) стеке микроконтроллера.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fX1TTGHeVCg.html Вот видео в котором я говорю об этом проекте без рассказа о программной части. Разбора кода этого проекта в открытом доступе нету.

например какой нибудь времязавсимый протокол приема передачи данных

@@CrazyPit его делать нужно не задачей в РТОС а модулем связанным с аппаратурой, очевидно напрашивается таймер. вы ж не будете тот же 1wire делать в задаче РТОС :)

Дело не в отсчетах времени. Операционная система реального времени предполагает жесткие рамки времени отклика на внешнее событие.

@@VladimirMedintsev Так я ж об этом. В принципе не сложно протестировать скорость работы, хотя бы среднюю. И я что-то сомневаюсь что там будет значение много превышающее время выполнение самого шедулера. Т.е. шедулер вас не смущает, а выделение памяти очень. К тому же подумайте еще вот о чем, не обязательно это вызывает задержку переключения задачи. Задержка будет только в том случае если будет более высокоприоритетная задача. Если выделение памяти будет в высокоприоритетной задаче, то отключение шедулера вообще никак не скажется так как все-равно переключение не произошло бы. Если же выделение памяти будет в низкоприоритетной задаче, то возможно выделение памяти закончится быстрее чем придет следующий SysTick. К тому же равномерного выполнения задач не стоит ожитать еще по причине наличия прерываний. Вот сейчас возьму и замеряю время работы этих функций.

@@VladimirMedintsev Вот осликом померял, 2кб выделяется за 2.124 микросекунды. Освобождение 250 наносек. Соответственно, можно говорить о том что включение heap_3 может добавить в отличии от heap_4 задержку выполнения высокоприоритетного задания на 2 микросекунды. Как по мне это не большая плата за потокобезопастность. Но тут уж по ситуации.

В параллельной реальности под названием С++ =)

Да. Все-равно. Но для большинства это секрет.

@@VladimirMedintsev Если генерировать код через КубМикс и поставить там статик , то файл хип вообще не генерится. А если сгенерировали сначала с динамическим выделением памяти а потом перегенерировали на статическое, то компилятор требует удалить файл heap

@@VasyaPupkinus И? Разве это не логично???

@@VladimirMedintsev Всё логично ) Ждём продолжения. Кстати, не подскажите что будет в следующей серии )

@@VasyaPupkinus В следующем видео будет управление очередями и оно гигантское по времени.