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

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


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

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

Сначала вот вам картинка распределения ОЗУ:

• начало ОЗУ
• переменные
• переменные
• переменные
• сюда вы зачем-то засунули секцию co_stack
• начало кучи
• ↓куча растёт в сторону конца ОЗУ
• ↓куча растёт в сторону конца ОЗУ
• тут пусто
• тут пусто
• тут могут встретиться стек и ОЗУ
• тут пусто
• тут пусто
• ↑сюда растёт стек
• ↑сюда растёт стек
• начало стека (конец ОЗУ)

Теперь пояснения.
секция co_stack, вероятно, фальшивая. То есть, для дела важен только её размер. Вкупе со значением HEAP_SIZE это позволяет линкеру выдать ошибку, если суммарный размер стек+куча+переменные превысит размер ОЗУ. То, что вы поместили эту секцию после секции text и перед секцией .heap, просто оставило неиспользуемый кусок ОЗУ между переменными и кучей.
Размер использованной кучи, скорее всего, не проверяется (можете посмотреть на функцию _sbrk() в syscalls.c. Максимум, что обычно делается - контролируется встреча кучи и стека. (И то далеко не всегда).

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

Из вашего ответа, у меня напрашивается законный вопрос, почему на всех встречающихся примерах всегда указывается размер стека, и кучи?
Честно говоря я думал что стек и куча ограничиваются размером.

P.S.

Это coocox делает по умолчанию в new_project. и GCC предлагает свой ld с таким расположением.


Только вспомнил! По адресу 0х08000000 указан адрес 0х200055А8. То есть начало стека, так что получается что стек двигается с этого адреса в конец памяти?

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

Ну, чтобы можно было проверить, что сумма стека и кучи поместится в ОЗУ.

Я вот про это:

Судя по всему, в исходном скрипте линкера было всё в соответствии с картой памяти, которую я нарисовал. А вы поменяли местами хип и стек.

Стек двигается в начало памяти. Поэтому начало стека обычно устанавливают в самый конец памяти.

..главное похвалить, а саму схему можно не читать.

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

Я думал что co_stack это начало стека, и адрес кучи находится там же где и начало стека. По этому и начал пытаться перенести кучу. Точнее вообще понять где она расположена, и как задать ей размер.

P.S.
Я подключил библиотеку декодера speex, и при его инициализации у меня программа улетала в Default_Handler. Скорее всего из за того, что происходило прерывание, обработчик которого я не включил (наверное прерывание по переполнению стека). Программа улетала, когда выполнялась calloc 3-й раз. Я увеличил значение STACK_SIZE и все пошло. Получается что calloc выделяло память из адресного пространства стека (возвращало 0x200055a8), а адрес начала стека все таки 0x200055a0?
Или я все не так понял?

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

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

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

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

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

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

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

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

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

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

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

Такое мне больше всего нравится, так и делаю.

FreeRTOS использует какую-то кучу, какую, зависит то того, какой менеджер памяти в проект закинули. В том числе может использовать "свою". Для этого случая есть параметр размера в конфигурации.
А стек в конфигурации FreeRTOS, это СОВСЕМ из другой оперы! Стек, это уже стек КАЖДОЙ из задач, ибо у каждой он свой.

Нет, требуемую Вам память в пределах имеющейся.

А как, простите, она может иметь представление? Конечно не имеет.

Непонятно, как это у вас получилось. Судя по отрывку из заглавного поста этой темы:

У вас по адресу 0x08000000 должен быть записан адрес конца ОЗУ (0x20020000).


Да поймите же, что "размер стека" и "размер кучи" - это просто для контроля достаточности свободного места. Если у вас сумма "размер стека + размер кучи" меньше свободного ОЗУ, то всё в порядке.

Неважно, как это назвать. Если у вас пересеклись куча и стек хотя бы на байт, значит, памяти не хватило.

Какая разница, откуда выделить место для большой переменной? Всё равно это будет кусок вашего свободного ОЗУ. Либо вы откусите кусок сверху, либо снизу

Да.

Нет, превышение лимита стека не контролируется.

Да, так можно сделать. Сделано ли это - посмотрите в _sbrk().


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

А это зависит от того, что за RTOS. Куча может быть общая и для RTOS и без RTOS, а стеки процессов выделяются из области переменных.

С этим вроде понял. Все дело в файле starup который coocox включает при выборе в репозитории компонента CMSIS BOOT. Не понятно зачем так?

В общем я поменял кусок, и теперь и стек начинается с __StackTop что в линкере указан, и проверка сохраняется ASSERT(__StackLimit >= __HeapLimit, "region ram overflowed with stack")


Вот теперь после изменения startup и понял.

Вот что у меня в этой функции.

На сколько я понял _end это та что в линкере
Не пойму как устанавливается значение __HeapLimit? И что в _sbrk нужно добавить, чтоб запретить выделять память после этого HeapLimit?
FreeRTOS.
Глобальных переменных, области data и bss?

Да кто ж их знает Может, была какая-то причина, а может, сделали как сумели.

Отлично.

У вас же там объявлена переменная специальная, и помещена в секцию .heap:

Соответственно, этот кусок скрипта линкера

ставит засечку "_end", а через HEAP_SIZE слов после неё - засечку __HeapLimit.

Как-то так:



Тут я точно не знаю, сочинять не буду. Спросите у zltigo, он спец по FreeRTOS.

Вух!!!, вроде все понял. Много вопросов отпало, когда собралась общая картинка. Просто начал я не с того боку и все из за того базового линк. Нужно было начинать с его ковыряния, а не кода Си.
Вот линк:

В startup файле устанавливаем только координаты начала стека, больше в нем нет ничего про стек и кучу!

Для проверки переполнения кучи в файле syscalls.c

По map файлу (просто для наглядности):
В итоге мы получили стек размером 0x200 который идет с адреса 0x20000a88 к 0x20000888.
Куча которая начинается с адреса 0x2001ff00 и идет до конца памяти с ограничением переполнения.


Остался один вопрос:
Эти самые секции объявляются для того, чтоб в эти места памяти никто ничего левого не подсунул?
Типа ка в линке MCC18 под ПИК когда нужна секция, в которую линкер ничего не суют?

Или то-же только для наглядности?
И здесь и так никто ничего не подсунет. Все глобальные переменные по порядочку по секциям data и bss (в PIC они были разбросаны по банкам памяти). Стек от А до В, куча от С до D. Все локальные переменные в стеке.
Тогда может вообще лишнее объявлять эти секции?
Сделать себе

И Все?!

Вы опять поменяли местами стек и кучу
Ну что же, если вам так нравится, то пусть будет так. Хотя мне больше по душе вариант, когда стек начинается в конце ОЗУ.

Если размер этих секций превысит свободное ОЗУ, то вы получите ошибку линковки. А так - да, можно и без этих секций, просто объявить _stack, _heap_begin и _heap_limit.