[zltigo 0]

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

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

А пока, если по существу моего вопроса ответить нечего - проходи мимо и не флуди. Я доходчиво обозначил позицию?

После чего имеете еще наглость "обозначать позиции".

[Tahoe 0]

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

"Да уймись, дура!"(с)

 

По моему вопросу, о плагине, есть что сказать?

[slavka012 0]

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

 

 

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

 

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

 

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

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

 

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

 

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

....

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

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

[Raven 8]

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

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

Использовали оба варианта. А недавно человек со свежим незамутненным взглядом предложил 0xDEDABABA :-)

 

Извините, не мог мимо пройти.