Стеку лучше. Какой же вы, однако, телепат )

Лень конечно зачем делать лишнюю работу и разбираться в дебрях чужой программы, если можно договориться об общих правилах. Если мы делаем сейчас опытную версию и мне выдают постоянно новые версии файлов, то я просто не успею еще чем-то заниматься, кроме постоянной переработки чужой программы. И все вопросы после такой переработки уже будут ко мне. Делаем так, потому что VisualDSP денег стоит и рабочих мест с ней у нас 2. У меня, другого программиста, который пишет измерительную часть и вот еще одно WIN-рабочее место для того, чтобы оболочку писать, UI. В общем вся работа отлажена, но вот есть некоторые нестыковки про которые я и спрашиваю, потому что опыта не так много. Также эти файлы используются для эмуляции работы прибора на ПК.

jcxz
Как-то работали с профессиональным программистом: много серийных изделий (в том числе и для европейских заказчиков).
Так он для DSP (TMS320C55x), где внутренняя память - ценный ресурс, выделял под стек половину внутренней памяти и размещал там просто огромные массивы и структуры.
Меня это удивило и поинтересовался зачем так делают?
Оказалось, что стек используется как куча с автоматическим освобождением. Типа стековой машины. Для данных, которым нужен быстрый доступ, оказалось очень удобно - нет лишнего копирования из внешней памяти во внутреннюю.
Правда, структуры были достаточно "хитрые" - с выравниванием по границе массивов.

Так на C55xx нету флешь, соответственно оставшейся половины хватало на код и всё прочее??? Очевидно программа была достаточно простая.
"Европейскость" программиста не говорит о его профессионализме Повидал и попеределывал достаточно кода после в том числе и "европейских" программистов...


А зачем в ембеддед устройствах куча? Зачем в автономном устройстве, в котором нет ОС, запускающей различные чужие, заранее неизвестные задачи выделять и освобождать память???
За более чем десяток лет работы в этой сфере и множество разработанных устройств, я ни разу не сталкивался с необходимостью кучи (под линух не писал). Большинство моих проектов содержат десятки тысяч строк кода.
Что мешало этому самому программисту объявить все эти "хитрые" структуры static?
Если на разных этапах работы ПО эта память используется для разных структур, то что мешает для каждого этапа объявить свою структуру и объединить их в union???

А для C55xx такой подход тем более ущербный, если вспомнить, что память в этих ядрах разбита на смежные блоки, каждый из которых имеет отдельную шину данных.
Соответственно - если например необходима обработка двух массивов одновременно (проход КИХ-фильтра например), то расположив их в разных блоках памяти, можно было добиться большей скорости работы кода, убирания stall-ов доступа к памяти.
Если например у Вас в один массив DMA пишет сэмплы принимаемые с SPI, в другом массиве - коэффициенты фильтра, в третьем - выходные данные фильтра и Вам надо обработать это КИХ-фильтром высокого порядка как можно быстрее (желательно по два порядка фильтра за такт CPU или по два сэмпла за такт), то Вам нужно все эти три массива расположить желательно в 3-х разных блоках ОЗУ. А код чтоб был в 4-м блоке.
Как Вы это сделаете зафигачив стек на полпамяти??? Как Вы в стеке будете определять где закончился один блок памяти и начался другой?
А вот разложить эти массивы определив их в static и назначив каждому свой блок посредством компоновщика - всё красиво и аккуратно и работать будет на максимальной скорости и без stall-ов.

На C55xx у меня практически весь тяжёлый код сигнальной обработки использовал все шины CPU по максимуму, за счёт раскидывания рабочих массивов по разным блокам ОЗУ.
И я немало повидал говнокода из DSPLIB C55xx, который на простых алгоритмах использовал ядро C55xx всего процентов на 30 его возможностей. И попереписывал его.

Кажется такие вопросы решаются выработкой спецификации взаимодействия ПК с устройством, после чего каждый может заниматься своим делом.
На лицо проблема проектирования. ИМХО, с таким подходом как сейчас, вы намучаетесь гораздо больше, чем если бы сделали все "правильно" и отделили мух от котлет(эмбеддед от вин32).
Для симуляции работы девайса на ПК делается наоборот - в эмбеддед код в нужных местах ставятся заглушки и все это весело запускается на ПК и начинает делать ввод/вывод в файлы и т.д. Нужно визулизировать какую-нибудь панель с тумблерами или датчиками - не вопрос, пишется для этого морда и опять же данные через файлы(/пайпы/бог знает как еще), поступают в эмбеддед код и результаты выводятся аналогично. Для того чтобы подмена нужных частей происходила без мучений - нужна продуманная архитектура. Тут мы приходим к основам основ... Для начала гуглить less coupling more cohesion.