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

Oxford

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

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

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

Реклама

VladislavS

horoc писал(а):

На пустом проекте реально занято 1632 байт озу?

Про стек и кучу не забываем.

horoc писал(а):

Может я, по не знанию, что то не то подключил? Или это не ОЗУ?

Ответы на все вопросы есть в .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 битными.

Реклама

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

VladislavS

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

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

Реклама

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

ARV

VladislavS писал(а):

Солить?

бинго!!!

Реклама

Реклама

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

horoc писал(а):

переделал так, что бы функции возвращали 32 битные значения, все локальные переменные тоже 32 бита.

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

Добавлено after 10 minutes 26 seconds:

horoc писал(а):

Я большей части спрашивал, в каких переменных работать в STM32.

В тех, которые нужны для логики работы программы.

horoc писал(а):

Понизит ли скорость работы с 8битными переменными, например в цикле for(uint8_t j=0;j<50;++j) или же здесь предпочтительно писать uint32_t j.

В данном случае на тип переменной счётчика фиолетово, это будет регистр процессора.

Код:

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

horoc писал(а):

в текущем проекте RO-data=17610 RW-data=424 ZI-data=3816 И я засуетился :)))

Надо смотреть что больше всего жрёт память, там и ужиматься. Каких-нибудь буферов наделали, вот память и уходит. Или строковые константы без const определены и в ОЗУ копируются. Вот где надо искать, а на переменных экономить - последнее дело.

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

Реклама

СКАЗОЧНИК

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

Реклама

ПростоНуб

VladislavS писал(а):

Преждевременная оптимизация

Наступили мне на больной мозоль. Очень оригинально некоторые программеры эту фразу воспринимают. Да, оптимизировать программу на этапе проектирования преждевременно, так же, как в БД создавать к таблице индексы до того, как стало известно, как и сколь часто из нее будут извлекаться данные. Но уже при написании SQL запроса, выбирающего данные из этой таблицы для отчета, есть прямой смысл озаботиться созданием индекса, если подходящего нет. Потому что, как обычно, отчет замечательно работает на нескольких тысячах записей в таблице и умирает на нескольких миллионах.
А заниматься оптимизацией уже за свой счет, после рекламации заказчика - удовольствие ниже среднего.

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

Реклама

WiseLord

СКАЗОЧНИК писал(а):

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

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

СКАЗОЧНИК

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

WiseLord

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

afz

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

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

a5021

horoc писал(а):

Я большей части спрашивал, в каких переменных работать в STM32. Понизит ли скорость работы с 8битными переменными, например в цикле for(uint8_t j=0;j<50;++j) или же здесь предпочтительно писать uint32_t j.

Я обычно

Код:

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

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

ПростоНуб

afz писал(а):

Оно-то, конечно, так, только вот аппаратуры контроля переполнения стека у STM32 нет

Вот, человек пишет, что ему удалось получить прерывание при доступе к ячейке памяти: 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, драйверы изучайте и пишите хорошо. Книжки почитайте.

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

Кто сейчас на форуме