О том, что эти несчастные 128 байт надо добавить к стеку заранее, хотя задействованы они будут "раз в пятилетку".


Хотя бы тем, что не будет такого маразма при каждом вызове iap_ExecCmd:
- выделили 128 байт на стеке
- скопировали туда 128 байт с начала iap_FlashCmdFunc, не разбираясь, надо ли так много

Я так понимаю вы сейчас пишите в контексте, как бы это сказать, некоего ОСа, в котором используются отдельные маленькие стеки для каждой задачи. Верно? Если я прав, то конечно вам нельзя себе позволить разместить автоматическую 128-ми байтовую переменную в стеке. Но это сугубо ваша проблема, а не проблема предложенного подхода.

Я же пользую общий стек для всех задач, поэтому никогда не испытываю проблем с его объемом. Я могу себе позволить выделить в стеке буфер под например 1.5KB Ethernet пакет, без задней мысли. Поэтому выделить 128 байт в стеке это для меня не проблема, настолько же насколько объявиление переменной типа int.

к слову в оригинальном коде, память я выделяю из пакетного пула:


А специально для форума подготовил код использующий стек-фрейм, т.к. он получается отвязанным от конкретной реализации.

Большой стек у меня получается вчастности за счет того, что в программе практически нет лишнего статически распределенного мусора. Как например функций записи страницы флеш.


С другой стороны не будет и такого маразма как в вашей реализации:
- Откусили ~n-байт от RAM (которого и так не много) навсегда;
- мало того еще надо лезть и править скрипт линкера;
- при переносе программы между компиляторами код работать не будет, т.к. надо еще и учитывать особенности компилятора.

Насчет скопировали неразбираясь надо ли так много, а стоит ли оно того это разбирательство? По скорости никто не жмет, т.к. непосредственно запись страницы флеш длится на порядки дольше чем это избыточное копирование.

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


n в районе <50, неужели в ваших проектах настолько плохо с RAM?
Владение инструментарием - это норма, а не маразм.

128 байт это не огромный объем, это сравнимо с контекстом регистров процессора (16x4), поэтому не делайте из мухи слона на ровном месте.


Как говорится, с мира по нитке, глядиш и набежит KB, а это уже существенно.


Выделили и скопировали - это тоже норма, а не маразм, при динамическом распределении памяти.

И кто теперь делает из мухи слона?


Только скопировали то, что:
1. Сгенерировано компилятором
2. Для вырезания и копирования не предназначено

Т.е. теоретически имеет право не работать.

Если бы мы обсуждали некий гипотетический способ достижения цели, можно было бы порассуждать теоретически.
А так имеется конкретный __рабочий__ код, стоит ли вспоминать о его теоретическом праве? ;>

Этот "рабочий" код с легкостью может реализовать свое право и стать __нерабочим__ при смене компилятора или опций оптимизации.

Ключевое слово "может" реализовать, и также слегкостью может и не реализовать.
Для успокоения, можно отключить оптимизацию одной функции (той что копируется), но думаю и этого делать не потребуется.

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

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


При переходе дороги на красный свет вас может сбить машина. Так что, будем ломиться на красный?

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


некоторые компиляторы требуют атрибут __ram, и т.п. так, что ничего я не путаю.


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

Никто не мешает, если это не противоречит правилам. Ваш пример противоречит.
Хотите использовать какой-нибудь simple memory map и визарды - да флаг в руки, только далеко не всегда это возможно.


Работоспособность кода и возможность собрать его компиляторами X и Y - абсолютно разные вещи.


Это не подземный переход, а канализационный коллектор.

Вашим правилам он противоречит что ли? Ну так не делайте так, если он противоречит вашим правилам.


Невозможность собрать приводит к неработоспособности кода. очевидно.

И моим в том числе. Делать не буду, и другим не советую.


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

А я советую делать так. По крайней мере для сохранения конфигурации способ идеален по следующим причинам:

1. Накладные постоянные расходы RAM - 0.
2. Код всегда лежит во флеш, т.о. он не может быть случайно перетерт.
3. Можно забыть, что такое скрипты линкера.
4. Вопреки опасениям уважаемого aaarrr, никаких проблем с переносом между компиляторами и установленным уровнем оптимизации нет. Специально попробовал в трех компиляторах IAR 4.40, RVDS 3.1 и Keil CA последний, все с максимальным уровнем оптимизации (т.е. один раз написав код, перенос между компиляторами не требует никаких правок, ни сам код ни скрипты ничего менять не надо). Ну а если вдруг при использовании какого-то компилятора (допускаю) случится худшее и код откажется работать, нужно будет отключить оптимизацию одной функции (iap_FlashCmdFunc() в примере) и все.

Даже с этим можно поспорить, если нет кучи или другого подобного источника памяти.


В нормальной программе ничего не может быть случайно перетерто.


Но лучше все же помнить.


Для данного конкретного случая вполне очевидный результат. Но сам принцип глубоко порочен - нельзя в общем случае копировать кота в мешке.

Можно написать эту процедуру на асме, тем самым гарантировав ее переносимость, и спокойно копировать в ОЗУ. Но нельзя переносить результат работы компилятора. Даже когда все кажется очевидным и безопасным.