STM32 новичку в ARM что к чему

[Oxford]

1. Data ZI: нулевые инициализированные данные

2. Data RO - это константы.
Общий объем RAM память = Data RW + Data ZI
Общий размер FLASH память = Code + Data RO + Data RW

3. Некоторые константы (Data RO) генерируются компилятором / компоновщиком и также могут быть добавлены из библиотек. Таким образом, они будут существовать независимо от того, что ваша программа явно не определяет какие-либо константы.

[VladislavS]

[uquote="horoc",url="/forum/viewtopic.php?p=3612406#p3612406"]На пустом проекте реально занято 1632 байт озу?[/uquote]Про стек и кучу не забываем.

[uquote="horoc",url="/forum/viewtopic.php?p=3612406#p3612406"]Может я, по не знанию, что то не то подключил? Или это не ОЗУ?[/uquote]Ответы на все вопросы есть в .map файле. Не ленитесь в него заглядывать.

[horoc]

Спасибо! Разобрался, оказывается на стек и кучу ушло.

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

      Code (inc. data)   RO Data    RW Data    ZI Data      Debug   Object Name
        64         26        236          0       1536        804   startup_stm32f10x_ld.o
Stack_Size      EQU     0x00000400
Heap_Size       EQU     0x00000200

Еще один вопрос, на stm32 предпочтительно надо использовать 32 битные переменные? Это увеличит скорость по сравнению с переменными 8 и 16 бит? Хочу перенести проект с меги на стм, переделал так, что бы функции возвращали 32 битные значения, все локальные переменные тоже 32 бита. Но вот глобальные переменные, отъедающие ОЗУ, жаба душит объявлять 32 битными.

[VladislavS]

Что вы потом будете делать с сэкономленной памятью? Солить?

Преждевременная оптимизация — корень всех (или большинства) проблем в программировании. (с) Дональд Кнут.

[ARV]

Солить?

бинго!!!

[horoc]

Я большей части спрашивал, в каких переменных работать в STM32. Понизит ли скорость работы с 8битными переменными, например в цикле for(uint8_t j=0;j<50;++j) или же здесь предпочтительно писать uint32_t j. Просто по коду, иногда с uint8_t компилируются меньше по размеру, отсюда сомнения что uint32_t всегда правильно. Сейчас у меня 4к оперативы, в текущем проекте RO-data=17610 RW-data=424 ZI-data=3816 И я засуетился

[VladislavS]

[uquote="horoc",url="/forum/viewtopic.php?p=3612599#p3612599"]переделал так, что бы функции возвращали 32 битные значения, все локальные переменные тоже 32 бита.[/uquote]В этом нет необходимости. Определяйте типы данных так, чтобы они соответствовали тому что описывают. За разрядностью процессора пусть компилятор следит. Тогда и не будет "мук переноса".

Добавлено after 10 minutes 26 seconds:
[uquote="horoc",url="/forum/viewtopic.php?p=3612837#p3612837"]Я большей части спрашивал, в каких переменных работать в STM32.[/uquote]В тех, которые нужны для логики работы программы.

[uquote="horoc",url="/forum/viewtopic.php?p=3612837#p3612837"]Понизит ли скорость работы с 8битными переменными, например в цикле for(uint8_t j=0;j<50;++j) или же здесь предпочтительно писать uint32_t j.[/uquote]В данном случае на тип переменной счётчика фиолетово, это будет регистр процессора.

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

//  for(uint8_t j=0;j<50;++j) __no_operation();
        MOVS     R0,#+50
??main_1:
        Nop      
        SUBS     R0,R0,#+1
        BNE      ??main_1

[uquote="horoc",url="/forum/viewtopic.php?p=3612837#p3612837"]в текущем проекте RO-data=17610 RW-data=424 ZI-data=3816 И я засуетился [/uquote]Надо смотреть что больше всего жрёт память, там и ужиматься. Каких-нибудь буферов наделали, вот память и уходит. Или строковые константы без const определены и в ОЗУ копируются. Вот где надо искать, а на переменных экономить - последнее дело.

PS: 512 байт под кучу и 1024 байт под стек тоже кучеряво так.

[СКАЗОЧНИК]

А кто и где выделяет место под стек и кучу? Почему вообще куча? Разве не можно сделать часть ОЗУ под стек, а остальное ОЗУ уже куча и есть?

[ПростоНуб]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3612794#p3612794"]Преждевременная оптимизация[/uquote]
Наступили мне на больной мозоль. Очень оригинально некоторые программеры эту фразу воспринимают. Да, оптимизировать программу на этапе проектирования преждевременно, так же, как в БД создавать к таблице индексы до того, как стало известно, как и сколь часто из нее будут извлекаться данные. Но уже при написании SQL запроса, выбирающего данные из этой таблицы для отчета, есть прямой смысл озаботиться созданием индекса, если подходящего нет. Потому что, как обычно, отчет замечательно работает на нескольких тысячах записей в таблице и умирает на нескольких миллионах.
А заниматься оптимизацией уже за свой счет, после рекламации заказчика - удовольствие ниже среднего.

Так что запоздалая оптимизация не меньше зло, чем преждевременная.

[WiseLord]

Разве не можно сделать часть ОЗУ под стек, а остальное ОЗУ уже куча и есть?

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

[СКАЗОЧНИК]

Где-то видел картинку, на ней была обозначена область ОЗУ, в конце самом стек, а куча лишь часть памяти, которая располагалось перед стеком. Так же тоже стеку некуда расти...

[WiseLord]

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

[afz]

Оно-то, конечно, так, только вот аппаратуры контроля переполнения стека у STM32 нет, о переполнении стека мы можем узнать только тогда, когда его кто-то испортит. И то не всегда сразу, иногда такие чудеса творятся, что ой! Обсуждалось уже не один раз.

Теоретически, конечно, если стек расположить в самом начале ОЗУ, то его переполнение вызовет однозначно идентифицируемый Hard Fault, но ни одна из систем программирования STM32 так не делает.

[a5021]

[uquote="horoc",url="/forum/viewtopic.php?p=3612837#p3612837"]Я большей части спрашивал, в каких переменных работать в STM32. Понизит ли скорость работы с 8битными переменными, например в цикле for(uint8_t j=0;j<50;++j) или же здесь предпочтительно писать uint32_t j.[/uquote]
Я обычно

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

for(int i = 0; i < 50; i++)

пишу. На результирующем коде это никак не сказывается, а писанины меньше.

[ПростоНуб]

[uquote="afz",url="/forum/viewtopic.php?p=3612972#p3612972"]Оно-то, конечно, так, только вот аппаратуры контроля переполнения стека у STM32 нет[/uquote]
Вот, человек пишет, что ему удалось получить прерывание при доступе к ячейке памяти: https://electronics.stackexchange.com/q ... a-debugger
Нет времени, чтобы проверить самому. Но мысль интересная.

[a5021]

Как то меня всю дорогу немного раздражало, что конфигурацию пинов у F1 нужно задавать в двух регистрах (GPIOx->CRL и GPIOx->CRH) -- младшие восемь в одном регистре, а старшие в другом. Намедни подумалось, что хорошо бы обращаться к GPIOx-CRy, как к 64-битной переменной и читать или писать ее за один раз, благо Cortex-M3 такое умеет. В даташите разглядел, что эти регистры расположены по соседним адресам в порядке от младшего к старшему, значит, все подходит. С учетом, что регистры находятся в самом начале структуры GPIO, достаточно привести указатель GPIOx к типу "указатель на uint64_t", чтобы задуманное заработало. Концептуально инициализация всего порта за один присест может выглядеть следующим образом:

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

#define PIN_CFG(PIN, MODE)  ((uint64_t)(MODE) << ((PIN) * 4))

#define I_ANALOG            (0ULL << 2)
#define I_FLOAT             (1ULL << 2)
#define I_PULL              (2ULL << 2)

#define O_PP                (0ULL << 2)
#define O_OD                (1ULL << 2)
#define O_AF                (2ULL << 2)

#define O_10MHZ             (1ULL)
#define O_2MHZ              (2ULL)
#define O_50MHZ             (3ULL)

  *(uint64_t *) GPIOA = (
    PIN_CFG(0,  O_AF + O_OD + O_10MHZ) | /*  TIM2_CH1 PWM (OUTPUT, OPEN DRAIN, MEDIUM SPEEED)  */
    PIN_CFG(1,  I_PULL)                | /*  EXTI1 (INPUT, PULL-DOWN)                          */
    PIN_CFG(2,  I_PULL)                | /*  USART2 RX (INPUT, PULL-UP)                        */
    PIN_CFG(3,  O_AF + O_2MHZ)         | /*  USART2 TX (OUTPUT, PUSH-PULL, LOW SPEED)          */
    PIN_CFG(4,  I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(5,  I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(6,  I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(7,  I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(8,  O_2MHZ)                | /*  GPIO (OUTPUT, PUSH-PULL, LOW SPEEED)              */
    PIN_CFG(9,  I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(10, I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(11, I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(12, I_ANALOG)              | /*                                      - unused -    */
    PIN_CFG(13, I_PULL)                | /*  SWDIO (INPUT, PULL-UP)                            */
    PIN_CFG(14, I_PULL)                | /*  SWCLK (INPUT, PULL-DOWN)                          */
    PIN_CFG(15, I_ANALOG)                /*                                      - unused -    */   
  );

Даже с выключенной оптимизацией компилятор GCC приводит этот пример к виду:

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

    4A0A        ldr r2, =0x40010800
    F64A038D    movw r3, #0xA88D
    4C09        ldr r4, =0x08800002
    E9C23400    strd r3, r4, [r2, #0]

Всего четыре команды, что весьма компактно. Здесь я пока не очень понимаю, получается ли запись в регистр атомарной, но выглядит похоже.

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

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

  GPIOA->BSRR = (                        /* Configure pulled-up pins                           */
    GPIO_BSRR_BS2                      | /* Set PA2(USART2 RX) pull-up mode                    */
    GPIO_BSRR_BS13                       /* Set PA13 (SWDIO) pull-up mode                      */
  );

Желаю слышать критику, чем вышеозначенный подход плох, если он действительно плох.

[Мурик]

Вот, человек пишет, что ему удалось получить прерывание при доступе к ячейке памяти

На F1 работает.

[isx]

Добрый день!
Использую в STM32 часовой кварц. Для калибровки вывел импульсы на RTC - в итоге насчитал 505 Гц, вместо 512. Сможет ли скомпенсировать такой разбег калибровка?
Если можно, объясните пожалуйста правила калибровки (какие регистры как влияют на результат), а то с даташитом у меня не особо получилось разобраться.
Благодарю

[СКАЗОЧНИК]

https://spec-project.ucoz.ru/index/kali ... m32f1/0-14

Тут что-то по этому поводу было

[Oxford]

Даже с выключенной оптимизацией компилятор GCC приводит этот пример к виду:

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

    4A0A        ldr r2, =0x40010800
    F64A038D    movw r3, #0xA88D
    4C09        ldr r4, =0x08800002
    E9C23400    strd r3, r4, [r2, #0]

Желаю слышать критику, чем вышеозначенный подход плох, если он действительно плох.

В KEIL так 5 компилятор:

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

-0
0x08002A0A F64A008D  MOVW     r0,#0xA88D
0x08002A0E 49FE      LDR      r1,[pc,#1016]  ; @0x08002E08
0x08002A10 4AFE      LDR      r2,[pc,#1016]  ; @0x08002E0C
0x08002A12 C203      STM      r2!,{r0-r1}

-3
0x08001FC6 4AAF      LDR      r2,[pc,#700]  ; @0x08002284
0x08001FC8 49AD      LDR      r1,[pc,#692]  ; @0x08002280
0x08001FCA F64A008D  MOVW     r0,#0xA88D
0x08001FCE E9C20100  STRD     r0,r1,[r2,#0]

Сам конфиг выглядит так на CMSIS, это то что вы напридумывали:

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

GPIOA->CRL = GPIO_CRL_MODE0_0 | GPIO_CRL_CNF0 | GPIO_CRL_CNF1_1 | GPIO_CRL_CNF2_1 | GPIO_CRL_MODE3_1 | GPIO_CRL_CNF3_1;
GPIOA->CRH = GPIO_CRH_MODE8_1 | GPIO_CRH_CNF13_1 | GPIO_CRH_CNF14_1;

Оптимизация здесь не требуется вообще. Флеша и скорости процессора хватает и позволяет не думать об этом. Лишняя трата времени, не тем занимаетесь.
Запоминать не надо ничего есть мануал, на любой чип открываешь и конфигурируешь. Через некоторое время забудете свой код и будете вспоминать как же вы там придумали конфигурировать, и в сети вас не поймут. А CMSIS все понимают.
Вы лучше аппаратуру, OS, драйверы изучайте и пишите хорошо. Книжки почитайте.