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 годовой давности стоящем где-то на объекте...

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

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

[dxp]

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

Система управления версиями решает эту проблему за пару секунд. Если я правильно понял контекст вашего ответа. Кстати, как тут поможет динамическое выделение?

[zltigo]

Система управления версиями решает эту проблему за пару секунд.

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

Если я правильно понял контекст вашего ответа. Кстати, как тут поможет динамическое выделение?

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

[dxp]

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

Слабо представляю себе ситуацию, чтобы выехать на объект с пустыми руками, т.е. без инструментария и проекта. А если есть проект, так там и репозиторий (.git), где вся история в подробностях.

Кроме того, как правило имеется удалённый репозиторий, с которым регулярно делается синхронизация. Есть бесплатные и хорошо развитые и бесплатные сервисы как для открытых (github.com), так и закрытых (bitbucket.com) проектов. Т.ч. всегда можно вытянуть проект, был бы интернет.

[zltigo]

Слабо представляю себе ситуацию, чтобы выехать на объект с пустыми руками, т.е. без инструментария и проекта. А если есть проект, так там и репозиторий (.git), где вся история в подробностях.

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