FreeRTOS 9.0 Static, Определение размера стека Опции

[Boriska]

В новой версии FreeRTOS 9.0 появилась возможность выделять память (под задачи/очереди и т.д.) статически.
Подскажите, как определить оптимальный размер памяти под стек задачи? Ну, кроме как ловить vApplicationStackOverflowHook?
Может есть какая-то методика?

[x893]

Точно так же как и раньше
1. Прописываем стек известным значением (мне нравится DEADBEEF) и потом смотрим
2. Отслеживать указатель стека при вызове функций.

[zltigo]

Точно так же как и раньше

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

1. Прописываем стек известным значением (мне нравится DEADBEEF) и потом смотрим

А мне CAFEBABE - оптимистичнее

2. Отслеживать указатель стека при вызове функций.

Отслеживать - да. При вызове каких-то неведомых функций - незачем. У меня всегда есть консолька в ней можно и посмотреть по директиве и распределение памяти (статическое не использую по причине нахренненужности и неудобства - см.выше) и использование стеков.

[jcxz]

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

Что же мешает делать то же самое при статически выделенных стеках?

Отслеживать - да. При вызове каких-то неведомых функций - незачем. У меня всегда есть консолька в ней можно и посмотреть по директиве и распределение памяти (статическое не использую по причине нахренненужности и неудобства - см.выше) и использование стеков.

Я динамическое не использую по той же самой причине - нафига оно? Зачем ещё какие-то функции вызывать чтобы распределить этот блок под стек в run-time, когда то же самое прекрасно сделает линкер в build-time?
Стеки задач в процессе работы firmware у меня не меняются (как и сами задачи).
И, например, если в устройстве есть разная память (по скорости/латентности/занятости другими bus-masters), то статически я могу раскидать стеки задач по разным типам памяти, как считаю нужным. А с динамическим выделением что - для каждой памяти свой манагер писать??

[zltigo]

Стеки задач в процессе работы firmware у меня не меняются (как и сами задачи).

Но меняются от релиза к релизу. В результате, в случае чего, возникают интересные вопросы, а как память была распределоена линкером на релизе XX.YY годовой давности стоящем где-то на объекте...

А с динамическим выделением что - для каждой памяти свой манагер писать??

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

[jcxz]

Но меняются от релиза к релизу. В результате, в случае чего, возникают интересные вопросы, а как память была распределоена линкером на релизе XX.YY годовой давности стоящем где-то на объекте...

Узнаём версию firmware "где-то на объекте", скачиваем её исходники из репозитария, компилим, открываем .map и смотрим. В чём проблема?

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

Для того, чтобы менеджер распределял память из разных блоков, ему надо как-то сообщить: какой блок мы хотим в очередном запросе? Т.е. - очевидно нужно передать какой-то доп. аргумент в функции malloc() или new (что там используется во FreeRTOS?). И как же из вызова xTaskCreate() передать в каком блоке памяти она должна выделить память? Да и наверняка в вызовах менеджера памяти внутре FreeRTOS она запрашивает у malloc()/new только объём памяти и не передаёт никаких доп. аргументов.
Так как же при создании задачи FreeRTOS задать блок памяти в каком она должна выделить стек?

Ага, если все это хозяйство есть в нужный момент под руками. По закону подлости приходится разбираться и находясь в самом неподходящем месте, в самое неподходящее время, за тысячи километров, чужими руками.

Это надуманная проблема.
Я участвовал в разработке многих изделий, которые потом стояли и работали "за тысячи километров" и при возникновении каких-то проблем у этих заказчиков, сам по ним не ездил, а только запрашивал номер версии firmware оттуда и разбирался уже на месте, указанным способом, воссоздавая обстановку у заказчика у себя в лаборатории.

2. В начале каждой функции делаем функцию которая сохраняет меньшее значение указателя стека из текущего и сохраненного. Конец стека мы и так знаем. В Watch их выбираем и смотрим.

Видимо Вы никогда не включали оптимизацию. В общем случае, список функций в ПО может не совпадать со списком подпрограмм в скомпилированном коде, так как опитимизатор например сам может убирать или добавлять новые подпрограммы, например когда видит одинаковые участки кода. В таких местах вы не получите реальной вершины стека.
Да и алгоритм действий компилятора, при котором он на входе в функцию один раз делает PUSH/SUBS SP,... а потом больше не трогает SP, это имхо не есть догма.
Не исключаю, что в каких-то случаях или какие-то компиляторы могут в теле функции менять SP. Это во многих случаях было бы полезно.
Да и учтите, что стеков может быть много (при наличии RTOS да и не только).

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

[zltigo]

Узнаём версию firmware "где-то на объекте", скачиваем её исходники из репозитария, компилим, открываем .map и смотрим. В чём проблема?

В том, что без этих действий легко обойтись.

Для того, чтобы менеджер распределял память из разных блоков, ему надо как-то сообщить: какой блок мы хотим в очередном запросе?

Да.

Да и наверняка в вызовах менеджера памяти....

Там используется обертка над одним из нескольких "штатных" менеджеров памяти. Я использую свой менеджер, имеющий больше возможностей. Если, вдруг окажется нужным разным задачам выделять тот же стек в разных блоках, добавлю без проблем. Эти дополнения будут ничем не сложнее добавления статического выделения памяти руками в разных секциях и их описание в скриптах линкера. Даже проще.

Это надуманная проблема.

Это вообще НЕ проблема сделать, как я сделал. ОДИН раз много лет назад был создан инструмент идентификации и просмотра блоков памяти. Он работает с тех пор тупо автоматически всегда и вообще нет необходимости придумывать причины его не использовать. Причем, поскольку динамическое выделение памяти используется на только для стеков задач, то этот же инструмент позволяет просматривать и области памяти всяких буферов и очередей.

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

Одна из областей в которой работают мои изделия, это телекоммуникационное оборудование. На объектах оно связано с оборудованием десятков производителей. Причем окружение все время меняется, поскольку сети живут и развиваются. Протоколы взаимодействия весьма сложны и имеют массу реализация, например, SS7 https://ru.wikipedia.org/wiki/ОКС-7. Я очень рад, что "у себя в лаборатории" Вы можете "воссоздать обстановку заказчика" .

[jcxz]

Там используется обертка над одним из нескольких "штатных" менеджеров памяти. Я использую свой менеджер, имеющий больше возможностей. Если, вдруг окажется нужным разным задачам выделять тот же стек в разных блоках, добавлю без проблем. Эти дополнения будут ничем не сложнее добавления статического выделения памяти руками в разных секциях и их описание в скриптах линкера. Даже проще.

Без проблем? Для этого Вам придётся модифицировать код самой FreeRTOS. Например: добавив в список аругментов xTaskCreate() ещё и идентификатор нужной кучи где стек выделять. И пробросить этот идентификатор внутрь xTaskCreate() до вызова Вашего malloc().
Или например передавать этот идентификатор через глобальную переменную, завернув вызов xTaskCreate() вместе с установкой этой переменной внутрь критической секции.
Конечно можно и так сделать. Можно и трусы через голову надевать каждую переменную в куче выделять. Но только - ЗАЧЕМ???
Зачем все эти кучи, malloc()-и и пр. хлам когда задачи создаются однократно (при старте firmware) и, соответственно, стеки выделяются также однократно. И никогда не освобождаются.
Зачем все эти лишние сущности, которые тратят доп. память, увеличивают кол-во кода и время выполнения (хоть и не на много)?
Даже просто посмотреть состояние стека выделенного статически гораздо проще. Для этого не нужно писать никакие свои тулзы, достаточно эмулятора. С динамическим стеком всё много сложнее.

Это вообще НЕ проблема сделать, как я сделал.

Сделать можно всё что угодно, вопрос - зачем?
В программе всегда есть переменные/массивы, время жизни которых - всё время работы ПО. Такие переменные нужно распределять статически (сюда относятся и стеки статических задач).
Можно конечно все такие переменные выделять на куче (и я видел что многие ламеры так и делают на PC). Но зачем??? Никаких плюсов это не даёт, одни минусы.
Всё, что может быть распределено build-time и должно распределяться build-time.

[zltigo]

Без проблем? Для этого Вам придётся модифицировать код самой FreeRTOS.

Она и так модифицирована в том числе и под другой менеджер памяти. Многое в ней не устраивало , или было недостаточно функционально с самого начала. На уровне 6 версии я вообще перестал следить за основной веткой. Только относительно недавно просмотрел 9 версию и с удовлетворением обнаружил, что подавляющая часть изменений, которая есть у меня и предлагалась Автору, таки появилась в 9 версии. Так что я добавил в 9 версию некоторые изменения (свой менеджер памяти, несколько дополниельных системных вызовов, другой порядок создания idle задачи,...) и у меня теперь большую часть проектов можно собирать с двумя вариантами операционки - "моим" и "почти 9".

Зачем все эти кучи, malloc()-и и пр. хлам когда задачи создаются однократно (при старте firmware) и, соответственно, стеки выделяются также однократно. И никогда не освобождаются.

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

Зачем все эти лишние сущности, которые тратят доп. память, увеличивают кол-во кода и время выполнения (хоть и не на много)?

"Лишняя сущность" в виде динамического выделения памяти под задачи, конечно, "тратят память" на MCB, но эти затраты сразу с лихвой компенсируются даже уничтожением одной ставшей ненужной задачи типа начальной инициализации.

Даже просто посмотреть состояние стека выделенного статически гораздо проще. Для этого не нужно писать никакие свои тулзы, достаточно эмулятора.

Вы легко "забыли", что смотреть нужно не только в Вас на столе.

С динамическим стеком всё много сложнее.

Много проще, поскольку так или иначе в устройстве есть встроенные отладочные средства для отладки не "на столе" c эмуляторами, симуляторами, отладчиками... Такова моя реальность.

Сделать можно всё что угодно, вопрос - зачем?

Уже многократно объяснял.

В программе всегда есть переменные/массивы, время жизни которых - всё время работы ПО. Такие переменные нужно распределять статически (сюда относятся и стеки статических задач).

О! Появилась мысль, что задачи могут быть не статическими . Так что, будете, как Вы тут выражались - "лишние сущности" и тоже менять операционку для создания статических и динамических задач? Вот уж точно лишние сущности, если есть создание динамических задач.

Можно конечно все такие переменные выделять на куче (и я видел что многие ламеры так и делают на PC).

Какие "такие"? Многие буфера и очереди выделяю и динамической памяти. Причины называл выше. Кроме того, MCB создают своеобразные защитные зоны между блоками и нарушение их сигнатур так же является индикацией ошибок переполнения.

Но зачем??? Никаких плюсов это не даёт, одни минусы.

Все уже говорилось неоднократно. То, что Вы ХОТИТЕ что-то не видеть, это не означает, что этого нет.

Всё, что может быть распределено build-time и должно распределяться build-time.

Вот тут уж мне остается только Вам задать вопрос - Почему?

[jcxz]

"Лишняя сущность" в виде динамического выделения памяти под задачи, конечно, "тратят память" на MCB, но эти затраты сразу с лихвой компенсируются даже уничтожением одной ставшей ненужной задачи типа начальной инициализации.

И в чём выигрыш от её уничтожения? Или хотите сказать, что освобождаете память занятую под её стек? Т.е. - что такое union и как с его помощью можно эффективно распределять память, используемую на разных этапах работы ПО разными процессами, Вы не в курсе?

Много проще, поскольку так или иначе в устройстве есть встроенные отладочные средства для отладки не "на столе" c эмуляторами, симуляторами, отладчиками... Такова моя реальность.

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

О! Появилась мысль, что задачи могут быть не статическими . Так что, будете, как Вы тут выражались - "лишние сущности" и тоже менять операционку для создания статических и динамических задач? Вот уж точно лишние сущности, если есть создание динамических задач.

Причём тут операционка??? Опять передёргиваете и подменяете понятия....
Например есть функция создания задачи (uCOS):
INT8U OSTaskCreate (void (*task)(void *p_arg), void *p_arg, OS_STK *ptos, INT8U prio)
где: ptos - указатель на вершину стека;
Передаю туда указатель на статически распределённый стек.
Теперь, пожалуйста, поясните почему я не могу туда точно так же передать указатель на динамически выделенный стек, коли мне уж так приспичит?
Зачем менять ОС, которая принимает указатель на стек, а не только его размер???

Какие "такие"? Многие буфера и очереди выделяю и динамической памяти. Причины называл выше. Кроме того, MCB создают своеобразные защитные зоны между блоками и нарушение их сигнатур так же является индикацией ошибок переполнения.

Ну понятно - Вам проще, так как у Вас всё работает на столе и нет жёстких требований по экономии памяти, быстродействия и т.п. Можно хоть каждый байт в куче выделять...
Поди и связные интерфейсы реализуете ногодрыгом?

Вот тут уж мне остается только Вам задать вопрос - Почему?

Ладно - воля Ваша - делайте хоть malloc(1) для каждого байта, хозяин - барин.

[zltigo]

И в чём выигрыш от её уничтожения? Или хотите сказать, что освобождаете память занятую под её стек? Т.е. - что такое union и как с его помощью можно эффективно распределять память, используемую на разных этапах работы ПО разными процессами, Вы не в курсе?

Как правило существует больше одного способа сделать дело. Но поскольку есть система, то логично решать поставленные задачи однотипно и понятно. Создать задачу и прибить ее это в духе операционной системы и соответственно понятно. Выделять двум задачам одну область памяти, следить что бы этой памяти хватало обеим задачам и ее объем в идеале не был избыточен ни для одной из задач, а потом одну задачу остановить навсегда, это уже криво и непонятно.

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

Ага, для каждого случая каждый раз вписывать. Некрасиво, если все может быть ОДИН раз написано и использоваться и для задач и для любых блоков памяти.

Причём тут операционка??? Опять передёргиваете и подменяете понятия....
Например есть функция создания задачи (uCOS):
INT8U OSTaskCreate (void (*task)(void *p_arg), void *p_arg, OS_STK *ptos, INT8U prio)
где: ptos - указатель на вершину стека;
Передаю туда указатель на статически распределённый стек.
Теперь, пожалуйста, поясните почему я не могу туда точно так же передать указатель на динамически выделенный стек, коли мне уж так приспичит?
Зачем менять ОС, которая принимает указатель на стек, а не только его размер???

Передавайте. Речь идет НЕ о том, как выглядит системный вызов конкретной операционной системы, а об самом факте использования динамически выделяемой памяти.
В случае FreeRTOS, которая здесь обсуждается, надо дописывать раздельные функции. Это не хорошо и не плохо. Это просто реализация которую можно обсуждать. В реализации FreeRTOS, напрмер, изначально была возможность стек и TCB размещать в разных областях памяти, что тоже может иметь свои преимущества в некоторых случаях.

Ну понятно - Вам проще, так как у Вас всё работает на столе и нет жёстких требований по экономии памяти, быстродействия и т.п. Можно хоть каждый байт в куче выделять...
Поди и связные интерфейсы реализуете ногодрыгом?

Изверетелись, как я вижу весь в попытках объснить "ненужность" и начали просто хамить . Напомню, что все началось с того, что я написал, что как раз "наcтольные" приемы отладки недоступны ввиду абсолютно ненастольных условий. Теперь Вы вдруг взялись рассказывать, что у меня, а не у Вас настольные системы. Что для "ногодрыга", который почему-то на голубом глазу мне тоже приписали, не требуется быстродействия. Ну и на сладкое вообще глупость, про экономию памяти - динамическое выделение памяти как раз и позволяет ЭКОНОМИТЬ память в системах с ограниченными ресурсами. А, например, те же телекомуникационные системы они все такие - делят ограниченные ресурсы каналов, пропускной способности каналов,... И соответственно и микроконтролеры имеют ресурсы в том числе и по памяти требуемой для процессов и соединений на расчетную нагрузочную способность.

Ладно - воля Ваша - делайте хоть malloc(1) для каждого байта, хозяин - барин.

Спасибо, но про выделение памяти под байт, это Вы придумали. Я всегда писал только о функционально законченных блоках памяти, причем в основном хранящих однотипную информацию (очереди, буфера,....). Что в качестве ДОПОЛНИТЕЛЬНОГО эффекта позволяет при динамическом выделении под них памяти использовать встроенные унифицированные средства отладки и для их просмотра и анализа.

[jcxz]

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

"Смешались в кучу кони, люди...."
Создание задач и управление ими не имеет никакого отношения к менеджеру памяти. ОС может быть, а менеджер - отсутствовать, как и наоборот.
Менеджер не имеет никакого прямого отношения к ОС, она вообще может его не использовать (посмотрите например на uCOS).
Соответственно - говорить о каком-то "духе операционной системы" - по меньшей мере странно.

Изверетелись, как я вижу весь в попытках объснить "ненужность" и начали просто хамить .

Смотримся в зеркало:

Это у Вас в Ваших настольных системах однократно.

Ну и на сладкое вообще глупость, про экономию памяти - динамическое выделение памяти как раз и позволяет ЭКОНОМИТЬ память в системах с ограниченными ресурсами.

Вот это как раз и есть ГЛУПОСТЬ.
Каким образом экономят объясните пожалуйста??? Количество бит в байтах увеличивает?
Именно обычное дин. выделение, а не выделение блоков одинакового размера по Вашему экономит?
Т.е. - что такое фрагментация дин. памяти Вы как бы не задумывались никогда?

Воссоздать всю эту "мерзкую" обстановку из электромагнитных полей у себя сможет далеко не каждая сертифицированная лаборатория. А симитировать какой-нить транс на 250 МВа вообще невозможно, не имея такой же у себя (или дорого в десятой степени)

Ну естественно воссоздание насколько это возможно.

Обычно в куче выделяются массивы данных. Зачем это делать динамически во встраиваемой системе? Но ведь сама FreeRTOS изначально диктует динамическое выделение структур: стек, TCB... Статически всё это выделять можно только с 9 версии, если я не ошибаюсь.

На FreeRTOS свет клином не сошёлся. Есть и другие ОС, где разработчики постарались отделить мух от котлет и не валить всё в одну кучу, а предоставить возможность разработчику самому решать как ему оптимальнее распределить память. Та же uCOS например. Во FreeRTOS до этого додумались почему-то только к 9-й версии.

Также удобно по ходу программы писать что-то в стиле

Код

type_t * ptr = new type_t[ WANT_SIZE]

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

А теперь представьте, что это работает не в игрушке у Вас на столе, с которой Вы поигрались и потом выключили, ну а если что зависло - нажали кнопочку RESET. А что это система, работает за много тыс. км где-нить на месторождении в тайге у заказчика, куда и дороги-то нету. И что таких устройств не одно, а их тысячи работают. И работают они в режиме 24/7. И что задача под ОС крутится не одна, а с десяток или больше. И что задачи эти обрабатывают события асинхронные друг относительно друга. И что требования к памяти у этих задач разные: одна выделяет большими блоками редко, другая часто и мелкими, третья - вообще разные размеры запрашивает.
И тогда после продолжительной работы, у Вас окажется что вроде и памяти-то свободной ещё много, но она вся оказалась так фрагментирована, что задача которой нужны мелкие блоки их получить может, а вот задаче требующей большие блоки будет отказ, так как хоть памяти вагон ещё свободной, но сплошного блока требуемого размера нет.
Вот тут и идёт лесом всё удобство....
Конечно если памяти в устройстве с избытком, то здесь другое дело. Но мне всё время приходилось работать над системами, где ресурсов в обрез.