Как добавить память в кучу во время выполнения?

Question

Я использую Keil's ARM-MDK 4.11. У меня есть статически выделенный блок памяти, который используется только при запуске. Он используется до того, как планировщик инициализирован и из-за того, как RL-RTX получает контроль над управлением кучей, не может быть динамически распределен (иначе последующие распределения после запуска планировщика вызывают сбои).

Я хотел бы добавить этот статический блок в виде свободного блока в системную кучу после инициализации планировщика. Казалось бы, __Heap_ProvideMemory() может предоставить ответ, который вызывается во время инициализации для создания начальной кучи. Однако для этого потребуется знание адреса дескриптора кучи, и я не могу найти документального метода его получения.

Любые идеи?

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

Answer 1

Мы используем компилятор Rowley Crossworks, но с аналогичной проблемой - куча была настроена в код запуска компилятора CRT. К сожалению, SDRAM не был инициализирован до начала main(), и поэтому куча не была настроена должным образом. Я работал над этим, повторно инициализируя кучу в начале main() после инициализации SDRAM.

Я рассмотрел код ассемблера, который использует компилятор при запуске, чтобы выработать структуру - это было не сложно. Впоследствии я также получил malloc/бесплатный исходный код от Rowley - возможно, вы могли бы спросить Keil о своей версии?

Answer 2

Один из методов, который я использовал, состоит в том, чтобы включить мои собственные простые процедуры кучи и взять на себя функции из библиотеки malloc()/calloc()/free().

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

Недостатком этого (по крайней мере, в моем случае) было то, что пользовательские подпрограммы кучи были гораздо менее сложными, чем встроенные подпрограммы библиотеки, и, вероятно, были более склонны к фрагментации, чем встроенные подпрограммы. Это не было серьезной проблемой в этом конкретном приложении. Если вы хотите возможности встроенных подпрограмм библиотеки, возможно, у вас есть malloc() отложить до встроенных подпрограмм кучи, пока он не вернет сбой, а затем попытайтесь выделить из вашей пользовательской кучи.

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

Одно из преимуществ этой техники заключается в том, что она довольно портативна (пока ваши пользовательские подпрограммы переносимы) и не прерывается, если инструментальная цепочка изменяет ее внутренность. Единственной частью, которая требует портирования, является захват интерфейса malloc()/free() и убедитесь, что вы получили инициализацию достаточно рано.