Распределение оперативной памяти в STM32

[VladislavS]

Угарная тема. Такое ощущение, что на форуме кулинарного техникума, а не эмбеддерам про стеки рассказываешь

[dosikus]

[uquote="afz",url="/forum/viewtopic.php?p=3443168#p3443168"]То есть, бог с ней, с кучей. Но ведь в стеке располагаются автоматические переменные и массивы. Приспичит мне в какой-то программуле объявить массив килобайт на несколько, и лезь в startup_stm32f10x_md править размер стека. Какого хрена я вынужден делать правку сразу в двух местах? Чем думали кейловские программисты, когда делали такое? Головой? Ну, так пусть сядут на нее!..[/uquote]

F042, массив структур 1,5 кб , стек и куча по дефолту. Все арбайтен.
Keil, кстати, не даст сделать динамический массив- что есть гуд, меньше шансов рукожопым кодерам накосячить.

Да и чем толочь воду в ступе лучше читайте - https://community.arm.com/processors/b/ ... plications

[ozzy]

не понял , с этого места поподробней ))

на stm32f030f4 c размером памяти 4 кб стек по умолчанию 1 кб

если я объявлю три массива (в глобальной секции) по 512 байт , мне стек увеличивать ? до 2 кб ?

[Мурик]

Глобальные массивы находятся постоянно в ОЗУ, а не в стеке. Если объявить локальный не статический массив, то он будет в стеке и нужно обеспечить чтобы в нем было достаточно места. Он находится в стеке только во время выполнения функции включая и выполнение всех функций вызванных из нее.

[ozzy]

хм, я как то об этом даже и не задумывался, бум знать

на моем примере

Спойлер

есть три буфера Buffer , IN_Buffer_Data IN_Buffer_Comm

Код: Выделить всё

    SystemCoreClock                          0x20000000   Data           4  system_stm32f0xx.o(.data)
    Buffer                                   0x20000004   Data         256  main.o(.data)
    pwm_is_ready                             0x20000104   Data           1  main.o(.data)
    pwm_lock_write                           0x20000105   Data           1  main.o(.data)
    delay_TIM14                              0x20000106   Data           1  main.o(.data)
    idxIN                                    0x20000108   Data           2  main.o(.data)
    idxOUT                                   0x2000010a   Data           2  main.o(.data)
    IN_Buffer_Data                           0x20000134   Data         512  main.o(.bss)
    IN_Buffer_Comm                           0x20000334   Data         512  main.o(.bss)
    __initial_sp                             0x20000938   Data           0  startup_stm32f030x6.o(STACK)

где их найти здесь ?

Код: Выделить всё

    Execution Region RW_IRAM1 (Base: 0x20000000, Size: 0x00000938, Max: 0x00001000, ABSOLUTE, COMPRESSED[0x00000010])

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x00000004   Data   RW           16    .data               system_stm32f0xx.o
    0x20000004   0x00000100   Data   RW          517    .data               main.o
    0x20000104   0x0000002c   Data   RW          519    .data               main.o
    0x20000130   0x00000004   Data   RW          706    .data               delay.o
    0x20000134   0x00000400   Zero   RW          515    .bss                main.o
    0x20000534   0x00000004   PAD
    0x20000538   0x00000400   Zero   RW            1    STACK               startup_stm32f030x6.o

Код: Выделить всё

    Total RO  Size (Code + RO Data)                10172 (   9.93kB)
    Total RW  Size (RW Data + ZI Data)              2360 (   2.30kB)
    Total ROM Size (Code + RO Data + RW Data)      10188 (   9.95kB)

Добавлено after 2 minutes 28 seconds:
и например как изменить Scatter файл в кейле что бы стек был под всеми данными ???? Начиная с 0х20000000.
Тогда при выходе за стек получим hard fault, который легко отследить

[dosikus]

Мурик, нормальная практика использовать для этого кучу. Рекомендую начать исправлять свою пробелы в знаниях.
Начни с изучения malloc, free и как пример FreeRtos.

Так же рекомендую внимательнейше изучить ссылку что я привел ,
особливо Figure 2: Typical stack layouts
Даже Joseph Yiu не находит криминала что в одном варианте, что в другом , вы же узрели какую-то хрень, уверовав что эмобитс делает верно а кайло нет.

[Мурик]

dosikus, речь шла о том где размещаются локальные переменные/массивы/структуры и т. д. Не имеет смысла использовать malloc/free для небольших массивов и структур размер которых заранее известен.

[dosikus]

Читать, читать и еще раз читать. Дабы не возникало когнитивного диссонанса подобного тому, что ты здесь устроил, восхваляя недоделку что пользуешь... Довел afz до истерики...

[afz]

Да и чем толочь воду в ступе лучше читайте

особливо Figure 2: Typical stack layouts

Угу. Кейл пользует Typical arrangement 1, о чем я написал еще на 1-й странице. EmBitz - Typical arrangement 2, как выяснили на 2-й странице.

Внимание, вопрос: как по-быстрому объяснить Кейлу, что он неправ, и требуется Typical arrangement 2 ?

За то мы тут нашли способ контроля переполнения стека. В принципе он лежал на поверхности, но я лично даже не думал об этом до сей темы форума

В старые добрые времена в приличных системах контроль стека делался аппаратно. В принципе, ничего сложного, регистр предельного адреса стека, куда система или программа заносят нижний адрес области стека, и цифровой компаратор, который потихоньку, не занимая времени основной части ЦП, мониторит указатель стека и, как произошло переполнение - выдает какое-то "жесткое" прерывание. И все. У PDP-11 было даже два уровня контроля переполнения стека - "желтая" и "красная" зоны. Правда у нее не было регистра предельного адреса стека, поскольку стек всегда располагался в начале памяти, сразу после векторов. Адреса переполнения стека, соответственно, были фиксированными.

В "больших" системах это дело, обычно, возлагается на страничный механизм виртуальной памяти, поэтому, похоже, про простой аппаратный контроль переполнения стека подзабыли. ARM ведь пытаются конкурировать с x86/x64, они, типа, "большие", а про то, что это ядро применяется и в МК, в которых памяти десятки, а то и единицы КИЛОбайт и такая фенечка могла бы быть весьма полезой - не подумали...

[VladislavS]

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

Касательно вашего вопроса - изучаем scatter file.

[Z_h_e]

Я пробовал чуть-чуть править scatter у Кейла. Правда совсем для другой задачи, не для перемещения стека. Не совсем понял как, но получилось сделать что хотел. Больше пока к Кейлу не возвращался. Скрипт линкера Кейла, имхо, какой-то не интуитивный, хотя возможно это дело привычки.

[dosikus]

Хаятели кайла - мануал читать не пробовали?

Внимание, вопрос: как по-быстрому объяснить Кейлу, что он неправ, и требуется Typical arrangement 2 ?

На хрена оно надо? И с какого хрена кайл не прав?
Что в первом варианте , что во втором, остаются участки памяти Unused и что бы их юзать надо править размер.
С какого бодуна вам взбрендилось, что во втором варианте вы можете их беспроблемно юзать ?

[VladislavS]

[uquote="dosikus",url="/forum/viewtopic.php?p=3443755#p3443755"]На хрена оно надо?[/uquote]Чтобы стек с кучей по нежданчику встречались

[dosikus]

За этим им все равно следить самим придется.
А как выше и писал кайло не даст создать массив с переменным размером.

[Z_h_e]

afz, если не хотца со скаттером разбираться, то можно в стартапе зарезервировать огромное место под стек. В конец точно не попадешь, но будешь близко. И с увеличением скомпилленого кода придется его каждый раз уменьшать .

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

[afz]

С какого бодуна вам взбрендилось, что во втором варианте вы можете их беспроблемно юзать ?

С того, что, по крайней мере, стек кейловское творение (в смысле собранная программа) не проверяет. Куча, скорее всего, проверяется - оговорено же, что если malloc() не может выделить требуемый объем памяти, возвращается NULL. А стек никто не проверяет, иначе не вылетали бы программы с недостаточным размером стека в Hard Fault.

Чтобы стек с кучей по нежданчику встречались

Угу. В смысле пореже встречались. Ибо при неправильно назначенных Stack_Size и Heap_Size они встречаются точно так же. Иначе не было бы регулярных жалобных вопросов от новичков, типа "Почему у меня FatFS вылетает в Hard Fault?" и ответов от наступивших на эти грабли: "Стек увеличь!"

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

afz, бросайте вы этот Keil пока не подсели.

Мне у Кейла нравится работа с CMSIS. Написал в начале программы

Код: Выделить всё

#include "stm32f10x.h"
#include "RTE_Components.h"

расставил должным образом галочки в Manage Run-Time Enviroment, и вперед!

А вообще, конечно, я не настоящий сварщик. Программистом я был во времена расцвета наших клонов Системы 360 и PDP-11. Встроенным программированием я занимался именно на клонах PDP-11 (Э-60, ДВК). Потом несколько лет программировал под MS-DOS. Увы всеобщего перехода под винды я не сдюжил, ввиду слабости своего английского. Пришлось сменить род деятельности. А сейчас, на пенсии, пытаюсь эмбеддить по-мелочи...

[VladislavS]

Классическое ИМХО - имею мнение хрен оспоришь. А оно нам надо?

[dosikus]

[uquote="afz",url="/forum/viewtopic.php?p=3445002#p3445002"]С того, что, по крайней мере, стек кейловское творение (в смысле собранная программа) не проверяет. Куча, скорее всего, проверяется - оговорено же, что если malloc() не может выделить требуемый объем памяти, возвращается NULL. А стек никто не проверяет, иначе не вылетали бы программы с недостаточным размером стека в Hard Fault.[/uquote]

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

[ARV]

и все-таки, я так и не увидел ответа на теоретический вопрос: зачем вручную задавать размер и местоположение стека, если наиболее оптимальным выглядить отдавать под него все, что осталось после выделения кучи и статических переменных (ну и под код, исполняемый из ОЗУ - это я не в курсе, как правильно называется)?
я даже согласен переформулировать вопрос иначе: зачем ОДНОВРЕМЕННО задавать размер и кучи и стека, если вполне логичным выглядит задавать что-то одно, а остатки оставлять под другое?
экзотические варианты с "дырами" в адресном пространстве не рассматриваем, т.к. это не общий случай.

[VladislavS]

Нет никакого ОБЩЕГО СЛУЧАЯ. Для STM32 мы пользуемся средствами разработки под ядра ARM. На ARM сделано несметное количество разных чипов, архитектура которых сильно отличается. И во всех средах разработки есть механизм настройки под каждый из этих чипов. Либо пользуйтесь этими механизмами, либо сидите на тинях и газируйте лужи.