Coocox настройка heap? Опции

[maxntf]

Не получается настроить кучу в coocox.
По тем пример что на форуме http://www.coocox.org/forum/viewtopic.php?f=2&t=917 у меня не получилось. Во первых потому, что они с ошибками, а во вторых там не указано куда именно в файле *.ld нужна сделать вставку.
В общем я сделал по другому:
1. В файле startup добавил

Код

/*----------Heap Configuration-----------------------------------------------*/
#define HEAP_SIZE       0x00001000
__attribute__ ((section(".heap")))
unsigned long pulHeap[HEAP_SIZE];

2. В файле ld перенес сектор .heap который там уже был, под сектор .co_stack

Код

    /* .stack_dummy section doesn't contains any symbols. It is only
    * used for linker to calculate size of stack sections, and assign
    * values to stack symbols later */
    .co_stack (NOLOAD):
    {
        . = ALIGN(8);
        *(.co_stack .co_stack.*)
    } > ram

    .heap (COPY):
    {
        __end__ = .;
        _end = __end__;
        end = __end__;
        *(.heap*)
        __HeapLimit = .;
    } > ram
    
    /* Set stack top to end of ram , and stack limit move down by
    * size of stack_dummy section */
    __StackTop = ORIGIN(ram ) + LENGTH(ram );
    __StackLimit = __StackTop - SIZEOF(.co_stack);
    PROVIDE(__stack = __StackTop);
    
    /* Check if data + heap + stack exceeds ram  limit */
    ASSERT(__StackLimit >= __HeapLimit, "region ram  overflowed with stack")

В файле syscalls.c вообще ничего не менял.
Вот map файл который получился, и как видно из скриншота, функция calloc возвращает указатель именно из области сектора .heap
Но только не пойму как работает ограничение, когда вылезаем за размеры кучи. Дело в том, что даже если я ставлю HEAP_SIZE 0x00000010. Программа работает но там явно память выделяется за границами кучи.

Сообщение отредактировал maxntf - Apr 16 2016, 15:02

Эскизы прикрепленных изображений

 

[maxntf]

Вроде пришло понимание части вопросов! Что привело к возникновению еще большей "куче" вопросов.
Из того что понятно:

- из этого понятно что верх стека по адресу 0x20000888 + 0x800(размер стека) = 0x20001088. Это значение записано и по адресу 0x08000000. За адресом 0x20001088 у нас больше ничего уже не будет хранится. то есть в данном случае я могу увеличить размер стека до значения 0x20020000 - 0x20000888(до этого адреса хранятся глобальные переменные).

Теоретически куча может не то что встретится со стеком, а стереть его полностью, добравшись до точки В. То же самое может сделать и стек с кучей, если он доберется до точки А. Так?
Стек растет сегментами, в которых хранятся локальные переменные функции и адрес возврата. Чем больше локальных переменных в функции, тем больше сегмент стека. Если нужна локальная переменная большого размера, а точнее мы не знаем какого размера она будет, но знаем что может быть большой - лучше ей память выделить динамически из кучи то-есть области ближе к точке А. И при этом стек у нас вырастет не значительно.
Про ограничения стека и кучи (как я это понял)!
По факту мы не имеем каких то конкретных размеров стека и кучи. Размер стека от заданной его вершины и до начала локальных данных. Размер кучи с начала памяти локальных данных и до конца памяти.
Превышение лимита стека контролируется вылетом в прерывание HardFault (если такое происходит, значит полная же.. и нужно делать переорганизацию памяти, увеличивать стек или выбирать проц с большей памятью.
Превышение лимита кучи контролируется через некое ограничивающее значение, наверное __HeapLimit, если вообще контролируется это. На сколько я понял этот контроль настраивается в функции _sbrk, ее специально оставили пользователю. То есть там нужно сделать проверку, если пытаемся выделить память за пределами HeapLimit, тогда не выделять память.

А теперь собственно вопросы:

• Это значение HeapLimit должно ведь быть динамическим. Ну типа до указателя стека, стек вырос и HeapLimit уменьшилось, стек уменьшился и HeapLimit увеличился? Иначе зачем тогда стек и кучу пихать в один сегмент памяти!
• Если у нас верх стека это конец памяти, а начало кучи начало локальных данных где тогда ОС(в частности freertos) размещает свои стек и кучу?

[zltigo]

[*] Это значение HeapLimit должно ведь быть динамическим.

Разумеется нет. Всегда есть явное или полуявное (типа вся свободная память) указание размера хипа. Менеджеры памяти никуда никакую память не растят, если запрошенное количество больше имеющейся. Явное указание есть тупейший вариант. С ним обычно для усугубления идет вариант, что все остальное стеку отдается - указывается минимально-отфонарное значение размера стека в рассчете на то, что свех этого будет еще какое то количество памяти нераспределенное линкером.

[*] Если у нас верх стека это конец памяти, а начало кучи начало локальных данных где тогда ОС(в частности freertos) размещает свои стек и кучу?

RTOS сама ничего и нигде не размещает. Размещает линкер я соответствии с указаниями данными Вами лично.

[maxntf]

Разумеется нет.

Тогда мне не понятно, зачем делать, чтоб куча шла на встречу стеку? Почему не выделить вначале кусок памяти под стек, а все что осталось под кучу? Но с таким-же успехом можно и в конце фиксированный под стек, а весь остаток под кучу. Главное. что ВЕСЬ а не какой-то опять-же фиксированный размер. Размер хипа следует указывать только минимальный, дабы уже линкер ругался, что совсем уж памяти не хватает.

RTOS сама ничего и нигде не размещает. Размещает линкер я соответствии с указаниями данными Вами лично.

Возможно я здесь чего то не понял. RTOS использует собственный стек и кучу, или те же что и компилятор (у меня GCC)? В настройках RTOS есть 2 параметра:

#define configMINIMAL_STACK_SIZE
#define configTOTAL_HEAP_SIZE

Получается что этими параметрами я задаю имеющуюся память в МК, потому что RTOS не имеет представления о том что у него на борту?