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

[arkhnchul]

[uquote="ARV",url="/forum/viewtopic.php?p=3445078#p3445078"]аналогичный вопрос у меня возникал и ранее для "больших" ПК - там для чего ограничивать размер сегмента стека?![/uquote]
патамушта calling conventions и работа с "железным" стеком. Предполагается, что адресное пространство стека непрерывно, а для этого с достаточной очевидностью его надо как-то отделить от кучи, дабы туда не лазил динамический аллокатор.
gcc умеет делать разрозненный динамически увеличивающийся стек (-fstack-split), но для использования сего все, с чем линкуется собираемая софтина, должно быть собрано так же. В llvm тоже вроде такое запилили.

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

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=3445269#p3445269"]А кто знает, как внешние события будут поступать? Раскрутить потребный стек статически можно для весьма ограниченного круга программ.[/uquote]
Не понял. Какие такие внешние события?
Что сложного? Берёте функцию, смотрите сколько она стека ест, смотрите какие функции она вызывает, сколько они едят, суммируете и так далее...
С библиотечными: во-первых их не так уж много - можно посмотреть внутри отладчиком и запомнить размер для каждой, во-вторых - возможно в отладочной инфу библиотеки можно включить инфу о размере стека.

Добавлено after 5 minutes 8 seconds:
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3445282#p3445282"]Может, очень может быть стек не на вершине это самое мудрое решение. Ну так объясните почему, что это дает?[/uquote]
Чукча не читатель, чукча - писатель? Читать умеете?

[Z_h_e]

Чукча не читатель, чукча - писатель? Читать умеете?

Ну так объясните, я с удовольствием почитаю.

[arkhnchul]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3445282#p3445282"]Какое преимущество организация стека (1) имеет перед (2) ? [/uquote]
мне чот кажется, что тут под SRAM подразумевается адресное пространство, а не прям физически имеющаяся память. Иначе нет вообще никакого смысла иметь unused области.

[VladislavS]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3445282#p3445282"]Какое преимущество организация стека (1) имеет перед (2) ? [/uquote]Они не хуже и не лучше друг друга! Они просто разные! Прекращайте мыслить AVR-ми. Для разных задач разные распределения памяти.

Прям как в анекдоте "@рмянин лучше чем *рузин..."

[Z_h_e]

Иначе нет вообще никакого смысла иметь unused области.

Я тоже не вижу, половина тут говорит что он есть, но упорно молчат и не хотя объяснять.

[VladislavS]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3445310#p3445310"][Я тоже не вижу, половина тут говорит что он есть, но упорно молчат и не хотя объяснять.[/uquote]Вам никогда не приходилось разворачивать MMU с TLB за пределами задачи?

[Z_h_e]

Я не знаю что это.

Добавлено after 51 second:
Это имеет отношение к теме данного раздела по STM32?

[dosikus]

Z_h_e, давай я тебе книжку подгоню, с картинками...
The Designer’s Guide to the Cortex-M Processor Family

http://rgho.st/6kNQnLpPR

[Z_h_e]

Подгони мне гугл, там еще больше инфы

[dosikus]

Могу еще эту
ARM System Developer’s Guide
Designing and Optimizing System Software

[VladislavS]

dosikus, полегче, у них и так стек переполнен

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3445324#p3445324"]Могу еще эту[/uquote]
Я думаю - это слишком сложно будет. Тут с азов начинать надо.

[dosikus]

Молчу, молчу...

[afz]

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

И где все это на STM32F103C8T6 ? На таких, и меньших МК делается 90% (если не 99%) любительских конструкций с применением STM32. Более того, я не представляю себе встроенного приложения на STM32, которому могли бы понадобиться многие мегабайты и, тем более, гигабайты оперативной памяти. Ну, кроме устройств, работающих с изображениями или видео. Но, ИМХО, в такой аппаратуре должны применяться более специализированные решения, а не МК общего назначения. Да, в этих специализированных чипах тоже может быть ядро ARM, но причем здесь STM32 ?

[jcxz]

[uquote="afz",url="/forum/viewtopic.php?p=3447100#p3447100"]Более того, я не представляю себе встроенного приложения на STM32, которому могли бы понадобиться многие мегабайты и, тем более, гигабайты оперативной памяти. Ну, кроме устройств, работающих с изображениями или видео. Но, ИМХО, в такой аппаратуре должны применяться более специализированные решения, а не МК общего назначения. Да, в этих специализированных чипах тоже может быть ядро ARM, но причем здесь STM32 ?[/uquote]
Один из моих хоббийных проектов: радиоприёмник, с поддержкой онлайн-станций (через WiFi). Поддерживает MP3 и AAC потоки. Для нормальной работы ему нужно довольно много ОЗУ, как для декодирования так и для буферизации потока (так как поток со многих станций очень нестабилен), гораздо больше чем для видеопамяти (в нём же). Сделан на STM32F429.
И зачем тут "более специализированное решение"?

[VladislavS]

[uquote="afz",url="/forum/viewtopic.php?p=3447100#p3447100"]И где все это на STM32F103C8T6 ?[/uquote]Ну вот как это называется, когда по одному типу контроллера на все STM32 обобщил. Да даже не только на STM32, а на целую IDE, которая кроме STM ещё кучу всего другого умеет. Что-то вспомнилось
https://youtu.be/tMpkcpTSN_s

[pvit]

[uquote="afz",url="/forum/viewtopic.php?p=3447100#p3447100"]Более того, я не представляю себе встроенного приложения на STM32, которому могли бы понадобиться многие мегабайты и, тем более, гигабайты оперативной памяти. Ну, кроме устройств, работающих с изображениями или видео.[/uquote]
Для развесистого GUI очень желательно иметь двойной фреймбуфер. Посчитайте его размер для большого цветного дисплея,

[jcxz]

[uquote="afz",url="/forum/viewtopic.php?p=3447100#p3447100"]Более того, я не представляю себе встроенного приложения на STM32, которому могли бы понадобиться многие мегабайты и, тем более, гигабайты оперативной памяти.[/uquote]
Также могу вспомнить УСПД (устройства сбора и передачи данных) для систем АСКУЭ/АСТУЭ которые собирают и аккумулируют данные с сотен, а может и тысяч узлов учёта, резервируют и передают эту инфу в центры сбора. Тоже могут строиться на базе Cortex-M МК с многими мегабайтами внешней памяти. Так как вычислительных ресурсов особых не требуют, а только памяти и каналов связи.
Когда то давно также был проект (правда на DSP) модема и планировалась функция расчёта SNR по принятому кадру (для определения необходимости сервисного обслуживания "на лету" без вывода канала связи из эксплуатации). По теории один из методов расчёта SNR принятых данных - захватить массив сэмплов сигнала, демодулировать/декодировать, обратно кодировать/модулировать принятые данные в массив сэмплов и затем вычислить разницу энергий принятого массива сэмплов и эталонного (сгенерённого локально). На размерах кадров хотя-бы в несколько кБ получались очень неслабые размеры массивов сэмплов.

[a5021]

[uquote="pvit",url="/forum/viewtopic.php?p=3447322#p3447322"]Для развесистого GUI очень желательно иметь двойной фреймбуфер. Посчитайте его размер для большого цветного дисплея,[/uquote]
И к попу встроенный баян надо тоже обязательно присобачить. Вы видимо просто не в курсе, как сам АРМ позиционирует линейки. Ну так картинки смотрите, раз почитать никак:



Видно, куда экраны с фреймбуферами относятся?