STM32F103 Keil StdPeriph.

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

Насколько я понимаю, размер стека задается в файле startup_stm32f10x_md.s таким образом:
При этом в одном проекте SP инициализируется значением 0x200004D0, в другом 0x200008F0

Вопросы:
- Как образуются эти числа? Я ожидал видеть там 0x20000400
- Что находится под стеком?

Смотрите линкер файл. В IAR это .icf файл

А если Кейл - куда смотреть?

Стек растет вниз, в сторону уменьшения адресов. А навстречу ему движется "куча", из которой выделяется память. И все это находится выше переменных.
А посмотреть можно в файле *.map.

.scat

Вам нужно найти начало секции STACK. __initial_sp будет равен <начало STACK> + Stack_Size.

В 'startup_stm32f10x_md.s' вы задаёте размер стека, а не адрес его начала.


Для Keil-a посмотрите map-файл

1. Именно что начало.
2. Мап это не тот файл, это результат.

Вот такие наблюдения. В проекте в стартапе задано размер стека 0x400, размер кучи 0x200. В map файле вижу:

В отладчике вижу, что стек инициализируется значением 0x20000668.

MAP файл нашел. Стало понятно, что за цифры я получал и почему они разные. Стек объявляется НАД всеми данными.

Мне это не нравится. Ведь это означает, что если я выйду за пределы стека - то я потру свои переменные. И ловить такую ошибку очень трудно. Я бы хотел разместить стек ПОД всеми данными. Начиная с 0х20000000. Тогда при выходе за стек я получу hard fault.

Вопрос - могу ли я в Кейле сказать, где должен начинаться стек?


Я не нашел такого файла. Есть <target>.sct. Но он тоже автогенерится. Там есть такая секция

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

конечно возможно)
нужно снять галку - Use Memory Layout from Target Dialog - и правим скаттер руками
обзываем область стека как нужно и в скаттере даем указание где расположить
скорее всего, там обозначен один регион для .ANY (+RW +ZI), так вот нужно просто создать свой регион и обозначить его точку вхождения и размер
LOAD REGION определяет то, как будет располагаться образ, записываемый программатором (ну или бутлоадером)
А вот уже в нем расписываются все секции - где код, где данные, где оставить окно и т.д.

<Спустя полчаса>
Все, спасибо всем. Дошло. Я могу отменить "Use Memory Layout..." на закладке Linker в свойствах проекта, и задать свой скаттер файл. Уже видно, что это не тривиальная задача - написать скаттер файл, но понятно куда грести.
Еще раз всем спасибо.

http://infocenter.arm.com/help/topic/com.a...51a/DUI0151.pdf

в помощь

2toweroff - Спасибо. Жаль что вы написали предыдущее сообщение одновременно со мною Теперь никто не поверит, что я сам сообразил, и написал одновремнно с вами

И за линк спасибо. Документу уже 12 лет, а не потерял актуальности. Я сам не нашел такого хорошего руководства по линковщику.

а оно кому-нибудь надо?



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

Раз уж речь пошла об инициализации, спрошу здесь (хоть и не совсем в тему, да простят меня автор топика и Модераторы).
Можно ли в KEIL узнать остаток кучи (HEAP) штатными средствами?
Или только через контроль указателя, который вернулся при запросе (через new) и несложную математику?

А что такое "остаток"? Память ведь может быть фрагментирована. Сумма всех кусочков?

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

да, я тоже видел подобные примеры в тырнете. While для malloc с инкрементом размера и освобождением, пока не вернет NULL

тут ведь какая штука... черт ее знает, как там менеджер кучи работает. Может он умеет "собирать крупу"

Keil это компилятор. Вы хотите узнать сколько осталось после компиляции?
мап файл.
Если в процессе работы программы, то Keil тут никаким боком.
Зависит от операционки, если она есть.

Спасибо всем за ответы.

Ну примерно так. Если подробнее, то до вызова main() происходит инициализация статических переменных и классов. При инициализации классов часть памяти "захватыватся" через new. Вот и хотелось бы узнать хоть приблизительный остаток кучи (к этому моменту она еще не будет дефрагментирована, надеюсь) или размер максимального блока, который может быть выделен.
Использовать статическое выделение памяти можно, но это уже другая тема (мое наследство), поэтому не обсуждаю.


Тогда уж после линковки (но это я к словам докапываюсь, извините). Это я в курсе.
Но тем неменее KEIL предоставляет несколько функций для работы с кучей, не относящихся к стандартным. Например __heapstats(); ее недостатком является то, что информацию выдает через printf в текстовом виде, да и информация по каждому блоку отдельно - не совсем то, что надо.
Думал, может кто с другими функциями контроля знаком.

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

Хочется автоматизации - аллоцируйте и осбобождайте блок памяти в цикле, добавляя по одному байту. Когда будет достигнут предел - напечатайте, или зайдите в брекпоинт. Я так понимаю, речь идет не о рабочем коде, а об отладочном - чтобы оценить достаточность кучи?

Спасибо за совет. В данный момент речь идет именно об отладочном коде.
Но использование в реалтайме тоже могло бы пригодиться.
Есть мысль, что в начале main достаточно запросить один байт и по указателю рассчитать остаток.
HEAP_MEM + HEAP_SIZE - PTR
точность составит наверное 8-16 байт (округление запрошенной памяти до 8 байт + параметры под атрибуты блока) но для первоначальной оценки вполне достаточно.
Еще раз всем спасибо.