QUOTE (jcxz @ Nov 28 2016, 18:22)

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

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

QUOTE (jcxz @ Nov 28 2016, 20:20)

Можно конечно все такие переменные выделять на куче (и я видел что многие ламеры так и делают на PC). Но зачем??? Никаких плюсов это не даёт, одни минусы.
Отдельные переменные выделять в куче - это, на мой взгляд, ибыточно. Обычно в куче выделяются массивы данных. Зачем это делать динамически во встраиваемой системе? Но ведь сама FreeRTOS изначально диктует динамическое выделение структур: стек, TCB... Статически всё это выделять можно только с 9 версии, если я не ошибаюсь.
Также удобно по ходу программы писать что-то в стиле
CODE
type_t * ptr = new type_t[ WANT_SIZE]
,
использовать массив, а затем удалить его, нежели заранее создавать его статически.
Выбор.