Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Распределение ОЗУ
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему
Atlantis-
Здравствуйте!
Подскажите пожалуйста как распределяется оперативная память в STM32F4. Допустим есть 256 килобайт внутренней SRAM. От нее откусывается немного под стек, немного под кучу (для динамического выделения) и оставшаяся часть - для программных переменных. Все правильно?
Если используется FreeRTOS, то для нужд системы резервируется память под стек и кучу. Эта память берется из оставшейся внутренней памяти (грубо говоря, чем больше памяти под нужды RTOS, тем меньше можно объявить переменных)? Или эта память выделяется из кучи процессора?
На всякий случай скажу, что у меня применяется схема heap_4.
jcxz
Всю память распределяете Вы сами посредством командного файла компоновщика. В IAR, например, это icf-файл.
При компиляции кода (хоть ОС хоть любого) создаётся набор сегментов данных, располжение которых в памяти и задаётся этим командным файлом компоновщика.
Сергей Борщ
QUOTE (Atlantis- @ Oct 6 2016, 15:52) *
Или эта память выделяется из кучи процессора?
Что такое в вашем понимании "куча процессора" и где, по вашему мнению, она находится?
Atlantis-
Цитата(Сергей Борщ @ Oct 7 2016, 08:28) *
Что такое в вашем понимании "куча процессора" и где, по вашему мнению, она находится?

В оперативной памяти выделяется некая область heap. Я программирую в Keil, поэтому для меня это значения в файле startup: Heap_Size - размер области и __heap_base - это видимо начальный адрес. То есть выделяется данная область в памяти, которая служит для динамического выделения памяти. Иными словами, объявляя переменную в программе я точно знаю, что в область heap она не попадет, а если я буду использовать malloc, то эта функция вернет мне адрес выделенной памяти из области heap (если конечно я не запрошу выделить памяти больше, чем эта область)
zltigo
QUOTE (Atlantis- @ Oct 7 2016, 11:10) *
В оперативной памяти выделяется некая область heap. Я программирую в Keil, поэтому для меня это значения в файле startup: Heap_Size - размер области и __heap_base - это видимо начальный адрес. То есть выделяется данная область в памяти, которая служит для динамического выделения памяти. Иными словами, объявляя переменную в программе я точно знаю, что в область heap она не попадет, а если я буду использовать malloc, то эта функция вернет мне адрес выделенной памяти из области heap (если конечно я не запрошу выделить памяти больше, чем эта область)

Пока Вы совершенно не понимаете, что творите, и произносите слова типа " из кучи процессора" и путать компиляторы с процессорами, возьмите просто обертку над тем malloc, который находтся в кейловских библиотеках. Обертки находятся в одном из вариантов heap_x из компелкта поставки FreeRTOS. Потом, когда нибудь, научитесь под heap просто отдавать ВСЮ свободную память.
Atlantis-
Цитата(zltigo @ Oct 7 2016, 12:06) *
Пока Вы совершенно не понимаете, что творите, и произносите слова типа " из кучи процессора" и путать компиляторы с процессорами

я просто хотел разделить две кучи, имея ввиду, что у RTOS она своя
zltigo
QUOTE (Atlantis- @ Oct 7 2016, 12:32) *
я просто хотел разделить две кучи, имея ввиду, что у RTOS она своя

С какого бодуна требуется иметь две кучи? Что бы потерять возможность гибко делить память и увеличить дефрагментацию? Хотя все даже хуже - та которая "не RTOS" не используется в принципе, раз работает RTOS. Посему выбор ОДНОГО из менеджеров кучи предлагаемых в комлекте RTOS, или какого либо из стронних, например, того-же кейловского. Я так-же на этом форуме выкладывал свой менеджер кучи и объяснял причины его появления.
HardEgor
Цитата(Atlantis- @ Oct 6 2016, 19:52) *
Подскажите пожалуйста как распределяется оперативная память в STM32F4. Допустим есть 256 килобайт внутренней SRAM. От нее откусывается немного под стек, немного под кучу (для динамического выделения) и оставшаяся часть - для программных переменных. Все правильно?

Вначале посмотрите создаваемый при сборке программы .map файл, там всё распределение памяти описано.
Atlantis-
Цитата(zltigo @ Oct 7 2016, 18:23) *
С какого бодуна требуется иметь две кучи? Что бы потерять возможность гибко делить память и увеличить дефрагментацию? Хотя все даже хуже - та которая "не RTOS" не используется в принципе, раз работает RTOS. Посему выбор ОДНОГО из менеджеров кучи предлагаемых в комлекте RTOS, или какого либо из стронних, например, того-же кейловского. Я так-же на этом форуме выкладывал свой менеджер кучи и объяснял причины его появления.

У меня "общая куча" выделена во внешней SDRAM, чтобы можно было использовать стандартные функции выделения памяти. И конечно я не хочу чтобы RTOS туда лезла.
zltigo
QUOTE (Atlantis- @ Oct 8 2016, 17:31) *
У меня "общая куча" выделена во внешней SDRAM, чтобы можно было использовать стандартные функции выделения памяти. И конечно я не хочу чтобы RTOS туда лезла.

Это совершенно неразумное и ничем не объяснимое хотение иметь несколько куч для неконкретного использования.
Atlantis-
Цитата(zltigo @ Oct 8 2016, 18:40) *
Это совершенно неразумное и ничем не объяснимое хотение иметь несколько куч для неконкретного использования.

Почему? Одна большая куча с внешней SDRAM для больших блоков данных. И маленькая куча для RTOS с более быстрым доступом к памяти, которая не лезет в большую кучу и не фрагментирует ее.
zltigo
QUOTE (Atlantis- @ Oct 8 2016, 21:46) *
Почему? Одна большая куча с внешней SDRAM для больших блоков данных. И маленькая куча для RTOS с более быстрым доступом к памяти, которая не лезет в большую кучу и не фрагментирует ее.

Если есть какие-то специфичные условия использования кучи, то тогда может быть и несколько куч - я специально сразу написал про неспецифичные. Про них Вы ранее не упоминали. Как Вы собираетесь использовать FreeRTOS что бы она угрожала фрагментацией? Если фрагментация действительно по объективным причинам не может быть минимизирована, или исключена, то последствия от дефрагментации тем меньше, чем больше куча и деление на несколько куч все только усугубляет.


Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.