Распределение оперативной памяти в STM32

[ARV]

либо сидите на тинях и газируйте лужи

я б вас послал, да вижу вы оттуда.

у меня несколько иное мнение. не смотря на изобилие вариантов в данной теме речь идет об STM32, в которых, как я догадываюсь, великого разнообразия не наблюдается. стек и куча. логичным выглядит деление сплошного пространства ОЗУ между этими сущностями единственной границей. в этом случае положение границы задается одним размером - стека или кучи. наличие двух размеров позволяет создать 2 границы - ЗАЧЕМ? если есть возможность, должна быть и цель для её применения. хочу понять.

объяснение "так принято" не принимается, та как это 100% догма - истина, в которую можно только верить, но не понять и осознать.

аналогичный вопрос у меня возникал и ранее для "больших" ПК - там для чего ограничивать размер сегмента стека?! там давно уже нет никаких ограничений на объем ОЗУ. складывается впечатльение, что это делается исключительно для оправдания существования исключений по переполнению стека...

[Z_h_e]

VladislavS, ещё раз преплагаю перестать мерятся писюнами и переходить на личности. А то хочется сразу задать вопрос, как такой великий знаток ARM сообщил что sp , при выходе за пределы ОЗУ непременно загрузит адрес возврата 0xFFFFFFFF? Все и всегда делают и будут делать ошибки.Так что может просто будем продуктивно и нормально общаться?

ARV, Вы наверное пропустили. На этот вопрос уже есть ответ,dosikus дал ответ в ссылке. Я не очень внимательно про нее почитал, но вроде понятно зачем это сделано и сделано намеренно. Может было бы лучше, если бы сделали простой дефайн для быстрого перемещения стека перед сборкой. А может если подробно почитать, что то такое и есть.

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3445078#p3445078"]не смотря на изобилие вариантов в данной теме речь идет об STM32, в которых, как я догадываюсь, великого разнообразия не наблюдается. стек и куча.[/uquote]Да что вы говорите? CCM RAM уже отменили? Подключение внешней памяти уже отменили?

[ARV]

Вы наверное пропустили

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

CCM RAM уже отменили? Подключение внешней памяти уже отменили?

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

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

[VladislavS]

Ошибаетесь. Внутренняя ССМ RAM в разных банках памяти (по вашему с "дырами") это норма. Внешняя и подавно. Так что, без скрипта линкера вообще никак.

[Z_h_e]

. если можно, расскажите по-русски.

Не скажу что я точно и правильно понял, может как раз все и наоборот. Надо будет попробовать внимательно прочитать, по возможности. Вроде как стек размещается в основном ОЗУ, а затем идёт инициализация остального адресного пространства после стека вместе со внешней как неразрывное.
Но я бы тоже не расстроился, если бы кто-то, хотя бы на 6ой странице данного раздела по русски объяснил А то пока идёт некая абстрактная болтология в основном ни о чем.

[ARV]

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

[VladislavS]

Вот и получается, что один
[uquote="ARV",url="/forum/viewtopic.php?p=3445107#p3445107"]я, конечно, не владею ARM-ами так хорошо, чтобы с уверенстью отвечать на такие вопросы[/uquote]
другой
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3445126#p3445126"]Не скажу что я точно и правильно понял, может как раз все и наоборот.[/uquote]
Но зато учить разработчиков IDE как они должны были сделать это завсегда пожалуйста. Страна Советов, чё.

[Z_h_e]

Я никого не учил, опять какие-то домыслы. Думаю разговор этот и до 15стр дойдет, всё-таки может кто-то уже ответит на вопрос? Обычно люди или делятся знаниями или молчат. Хотя зачем, лучше флудить конечно, оскорблять и ни разу по делу ничего не сказать. Так ведут себя когда сказать нечего, а сказать что то хочется.

[jcxz]

[uquote="afz",url="/forum/viewtopic.php?p=3442157#p3442157"]Тут идут исторические размышления на тему...
...
статические и глобальные (в смысле, определенные вне функций и видимые во всех функциях) - перед кучей, да? Ну, и malloc() выдаст память из кучи, да?[/uquote]
Бред полный. В инете полно всякого вздора, зачем его читать?
Куда, в какие секции, положить переменные, кучу и прочие части программы - определяет компилятор. А куда, в какие регионы памяти, затем располагать эти секции - определяет компоновщик. Компоновщику необходимую инфу о регионах памяти и размещениях секций по ним задаёт программист в файле конфигурации.
Никакие PDP и прочее старьё тут не при чём. Так же как нет никаких догм насчёт расположения кучи, стеков и пр.

Добавлено after 4 minutes 42 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=3445078#p3445078"]логичным выглядит деление сплошного пространства ОЗУ между этими сущностями единственной границей. в этом случае положение границы задается одним размером - стека или кучи.[/uquote]
Видимо Вы никогда не использовали РТОС. Там одним стеком дело не ограничивается.
Одна, две или три границы - нет никаких догм, как удобно для данного проекта так и следует память разделять. Тем более что в подавляющем большинстве embeded-проектов куча вообще не нужна.
Память полезно делить по её физическим особенностям: скорости, сохранению содержимого в sleep, доступности DMA, доступности bitband и пр.

Добавлено after 4 minutes 39 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=3445063#p3445063"]и все-таки, я так и не увидел ответа на теоретический вопрос: зачем вручную задавать размер и местоположение стека, если наиболее оптимальным выглядить отдавать под него все, что осталось после выделения кучи и статических переменных (ну и под код, исполняемый из ОЗУ - это я не в курсе, как правильно называется)?[/uquote]
Зачем под какой-то массив в программе отдавать не всю память, а вручную задавать размер? ответите на этот вопрос?
А чем стек отличается от любого другого массива в программе?

Добавлено after 2 minutes 18 seconds:
[uquote="dosikus",url="/forum/viewtopic.php?p=3443255#p3443255"]Мурик, нормальная практика использовать для этого кучу.[/uquote]
Нормальная практика в embedded - не использовать кучу. От слова "вообще".

Добавлено after 4 minutes 6 seconds:
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3442961#p3442961"]Конечно прогая на ассме легко посчитать нужный размер стэка, как это сделать на ЯВУ, кроме интуиции я не знаю. Можно попробовать конечно в каких-то глубоких подпрограммах считать SP[/uquote]
Начать нужно с изучения доки на компилятор. Ибо многие из оных вполне себе способны сообщать размер стека используемый функцией в листинге.
Другое дело, что использование косвенных вызовов функций создаёт трудности.

[dosikus]

[uquote="jcxz",url="/forum/viewtopic.php?p=3445194#p3445194"]Нормальная практика в embedded - не использовать кучу. От слова "вообще". [/uquote]

Да я то с этим согласен, вы переубедите любителей осей в эмбедде , FreeRtos к примеру...

[jcxz]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3442751#p3442751"]Если ошибочно мало выделил места под стек, то стек может залезть на неиспользуемую область памяти и ничего страшного не произойдет.[/uquote]
Баги в программе нужно искать и исправлять, а не закапывать поглубже. И нормальный разработчик старается всячески увеличить вероятность проявления ошибок, чтобы выявить их как можно больше. А не закапывает, чтобы потом в боевой системе заказчик наступил на грабли.
Так что любые переменные нужно располагать таким образом, чтобы ошибки работы с ними проявлялись сразу и однозначно. Если это возможно.

Добавлено after 2 minutes 21 second:
[uquote="dosikus",url="/forum/viewtopic.php?p=3445207#p3445207"]Да я то с этим согласен, вы переубедите любителей осей в эмбедде , FreeRtos к примеру...[/uquote]
Не использовал FreeRTOS, во многом и из-за этого (ну и по другим причинам). Но видел, что в последней версии FreeRTOS его разработчики всё-таки догадались добавить возможность статического размещения стеков.

[ARV]

jcxz, область стека от области массива отличается тем, что заранее практически невозможно предсказать необходимый и достаточный его размер. Это очевидно.

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3445213#p3445213"]jcxz, область стека от области массива отличается тем, что заранее практически невозможно предсказать необходимый и достаточный его размер. Это очевидно.[/uquote]
Во-первых: не "стека", а "стеков". Так как серьёзное ПО на ARM как правило не пишется в суперлупе.
Во-вторых: странно - а как тогда программы пишут и размеры этих самых стеков задают? вот уж не знал, что эта такая неразрешимая проблема...

ЗЫ: Почитайте что такое файлы листинга и что в них полезного.

[ARV]

Я замечаю, что очень многие нынче и не пытаются вникать в суть происходящего, т.к. их все и так устраивает. Поэтому на вопрос "как тогда пишут программы" отвечу "по привычке". Сказано задать размер, ну и задам, че такого. Не было б нужно, не требовали б.

Как-то так вот...

Кстати, листинг и map-файл не скажут вам, достаточно места под стек вы задали или нет.

Добавлено after 6 minutes 1 second:
Да, ещё в догонку: я, наверное, отстал от жизни, и теперь уже компилятор с линкером ответственны за организацию "стеков"... И, возможно, уже несколько аппаратных указателей стека давно норма...
И по этому я продолжаю думать, что с точки зрения ядра стек один (не считая хитростей старших армов с " быстрым стеком прерываний" и т.п.), и с точки зрения любой ОС стек тоже один - её собственный, тот, который аппаратно управляется ядром. А множественные стеки задач - это уже совсем иная тема.

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3445248#p3445248"]Кстати, листинг и map-файл не скажут вам, достаточно места под стек вы задали или нет.[/uquote]
Да ладно? Откройте .lst и найдите в нём раздел "Maximum stack usage in bytes". Это если нужно надёжно.
Ну можно и проще, народным методом: заполнением стеков шаблоном и прогоном во всех режимах работы. Хотя в зависимости от алгоритма работы это может быть и не проще чем по листингу.

[uquote="ARV",url="/forum/viewtopic.php?p=3445248#p3445248"]Да, ещё в догонку: я, наверное, отстал от жизни, и теперь уже компилятор с линкером ответственны за организацию "стеков"... И, возможно, уже несколько аппаратных указателей стека давно норма...[/uquote]
Видимо отстали. Так как даже в Cortex-M аппаратных SP == 2 шт. А в классических ARM7/9/Cortex-A - ещё больше.
Но разговор вообще был не про указатели стека, а про стеки.

[uquote="ARV",url="/forum/viewtopic.php?p=3445248#p3445248"]с точки зрения любой ОС стек тоже один - её собственный, тот, который аппаратно управляется ядром. А стенки задач это уже совсем иная тема.[/uquote]Вообще изначально разговор был о распределении памяти, а значит - о всех стеках как областей памяти программы. А никак не о указателях стека.
Так что говорить о стеках нужно с точки зрения компоновки памяти программы. И стеков тогда обычно == по количеству задач + стек прерываний + ну может ещё какие-нить надобности (это для Cortex-M, для классических ARM стеков обычно ещё больше).

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3445258#p3445258"]Да ладно? Откройте .lst и найдите в нём раздел "Maximum stack usage in bytes". Это если нужно надёжно.[/uquote]
Не знаю как для других компиляторов, но с gcc такое не сработает, он не знает как стек используют библиотечные функции.

[ARV]

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

[VladislavS]

[uquote="jcxz",url="/forum/viewtopic.php?p=3445258#p3445258"]Так как даже в Cortex-M аппаратных SP == 2 шт.[/uquote]Во-Во! Только что хотел то же самое написать. Даже с сайта ARM документ дёрнул.

DUI0553A_cortex_m4_dgug.pdf

(604.55 КБ) 297 скачиваний

[Z_h_e]

Все-таки хотелось бы услышать ответ отличный от читайте НТД. Я так тоже умею отвечать, вообще на любой вопрос так можно ответить, поставить в форум бота и пускай шпарит в каждой теме .

Вот картинка, для наглядности.

Спойлер

Слева такая организация стека, по которой возник вопрос (1). Справа - условно классическая (2).
Какое преимущество организация стека (1) имеет перед (2) ? Столько текста, но ни одного даже похожего на ответ заявления или предположения.

Есть мнение, которого я пока придерживаюсь, что организация стека (2) предпочтительнее (по крайней мере без внешней ОЗУ), доводы приводились (может они и неверные, но они доводы годные для обсуждения, а не типа "читайте НТД бездари").

Допустим ты заявил 100h слов стека и это было ошибкой. В обоих случаях стек иногда переполняется. В случае (1) сбой гарантирован, но не факт что ты его вовремя отследишь. В (2) почти наверняка сбоя не будет, но и наверняка ты и не заметишь что вылетел за стек.
Т.е. при ошибке
при (1) Большая вероятность сбоя и не факт что вовремя определишь
(2) Вероятность сбоя низка и крайне низка вероятность обнаружения.
Что тут лучше?

Говорите читайте листинг? Сто раз будешь читать , а в самый ответственный момент пропустишь. Будь ты хоть семи пядей во лбу. И у тебя сбойное устройство и глючит оно только когда Венера в Марсе при полной Луне, при 50% свободной памяти потому что "так надо".

Может компилятор подскажет? Объявил стек размером 1. Сборка успешна, ни одного предупреждения (GCC).

Может, очень может быть стек не на вершине это самое мудрое решение. Ну так объясните почему, что это дает?