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

[Boriska]

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

[ar__systems]

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

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

Спрашивается, зачем "задача начальной инициализации и диагностики системы" запускается как задача OS? Вызовите ее как обычную функцию до передачи управления OS и будет вам счастье.

Есть места на планете, куда если и можно отправить "квалифицированного" сервисного инженера, то не быстро (например, заполярье оно, блин, даже дальше МКАД), и компьютерами с отладчиками его обвешать тоже нельзя, например, по причине взрывоопасных условий в шахте с оборудованием размазанным на сотни километров под землей. И вообще там очень грязно, темно, столов, стульев и даже розеток для компьютеров нет совсем, зато есть каска с фонарем, резиновые сапоги, роба, самоспасатель на шее и возможность ползать на четвереньках. А стоимость простоя комплекса в ожидании сервисинженера (а что, сервисинженер должен уметь собой заменять и программиста, и вообще всех?) со свежим лицензионным IAR EWARM и плагинами к нему , это не много, а очень очень много.

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

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

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

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