2. Data RO - это константы. Общий объем RAM память = Data RW + Data ZI Общий размер FLASH память = Code + Data RO + Data RW
3. Некоторые константы (Data RO) генерируются компилятором / компоновщиком и также могут быть добавлены из библиотек. Таким образом, они будут существовать независимо от того, что ваша программа явно не определяет какие-либо константы.
_________________ Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
Спасибо! Разобрался, оказывается на стек и кучу ушло.
Код:
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 битными.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Я большей части спрашивал, в каких переменных работать в 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 И я засуетился
переделал так, что бы функции возвращали 32 битные значения, все локальные переменные тоже 32 бита.
В этом нет необходимости. Определяйте типы данных так, чтобы они соответствовали тому что описывают. За разрядностью процессора пусть компилятор следит. Тогда и не будет "мук переноса".
в текущем проекте RO-data=17610 RW-data=424 ZI-data=3816 И я засуетился
Надо смотреть что больше всего жрёт память, там и ужиматься. Каких-нибудь буферов наделали, вот память и уходит. Или строковые константы без const определены и в ОЗУ копируются. Вот где надо искать, а на переменных экономить - последнее дело.
PS: 512 байт под кучу и 1024 байт под стек тоже кучеряво так.
Наступили мне на больной мозоль. Очень оригинально некоторые программеры эту фразу воспринимают. Да, оптимизировать программу на этапе проектирования преждевременно, так же, как в БД создавать к таблице индексы до того, как стало известно, как и сколь часто из нее будут извлекаться данные. Но уже при написании SQL запроса, выбирающего данные из этой таблицы для отчета, есть прямой смысл озаботиться созданием индекса, если подходящего нет. Потому что, как обычно, отчет замечательно работает на нескольких тысячах записей в таблице и умирает на нескольких миллионах. А заниматься оптимизацией уже за свой счет, после рекламации заказчика - удовольствие ниже среднего.
Так что запоздалая оптимизация не меньше зло, чем преждевременная.
Разве не можно сделать часть ОЗУ под стек, а остальное ОЗУ уже куча и есть?
Нельзя. Ну вот, представьте, стек растёт от одного конца ОЗУ к другому. А всё остальное - куча. И тут в куче выделяется один байт, где-то близко к стеку. Всё - стек больше расти не может, упрётся в этот байт. Хотя памяти, казалось бы, свободной ещё много.
Где-то видел картинку, на ней была обозначена область ОЗУ, в конце самом стек, а куча лишь часть памяти, которая располагалось перед стеком. Так же тоже стеку некуда расти...
Да, но в этом случае хотя бы понятно, до каких пор позволено расти стеку. А в случае динамической отдачи под кучу той же памяти, что и стеку, перекрытие их может произойти в любой случайный момент.
Заголовок сообщения: Re: STM32 новичку в ARM что к чему
Добавлено: Ср апр 10, 2019 14:14:34
Опытный кот
Карма: 13
Рейтинг сообщений: 163
Зарегистрирован: Сб дек 22, 2012 08:17:42 Сообщений: 744 Откуда: Караганда, Казахстан
Рейтинг сообщения:0
Оно-то, конечно, так, только вот аппаратуры контроля переполнения стека у STM32 нет, о переполнении стека мы можем узнать только тогда, когда его кто-то испортит. И то не всегда сразу, иногда такие чудеса творятся, что ой! Обсуждалось уже не один раз.
Теоретически, конечно, если стек расположить в самом начале ОЗУ, то его переполнение вызовет однозначно идентифицируемый Hard Fault, но ни одна из систем программирования STM32 так не делает.
_________________ Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
Я большей части спрашивал, в каких переменных работать в STM32. Понизит ли скорость работы с 8битными переменными, например в цикле for(uint8_t j=0;j<50;++j) или же здесь предпочтительно писать uint32_t j.
Я обычно
Код:
for(int i = 0; i < 50; i++)
пишу. На результирующем коде это никак не сказывается, а писанины меньше.
Как то меня всю дорогу немного раздражало, что конфигурацию пинов у F1 нужно задавать в двух регистрах (GPIOx->CRL и GPIOx->CRH) -- младшие восемь в одном регистре, а старшие в другом. Намедни подумалось, что хорошо бы обращаться к GPIOx-CRy, как к 64-битной переменной и читать или писать ее за один раз, благо Cortex-M3 такое умеет. В даташите разглядел, что эти регистры расположены по соседним адресам в порядке от младшего к старшему, значит, все подходит. С учетом, что регистры находятся в самом начале структуры GPIO, достаточно привести указатель GPIOx к типу "указатель на uint64_t", чтобы задуманное заработало. Концептуально инициализация всего порта за один присест может выглядеть следующим образом:
Всего четыре команды, что весьма компактно. Здесь я пока не очень понимаю, получается ли запись в регистр атомарной, но выглядит похоже.
Единственный момент, который немного ухудшает стройность подхода -- это включение PULL-UP на входах, если такое требуется. В этом случае придется дополнить инициализацию порта чем-то наподобие
Добрый день! Использую в STM32 часовой кварц. Для калибровки вывел импульсы на RTC - в итоге насчитал 505 Гц, вместо 512. Сможет ли скомпенсировать такой разбег калибровка? Если можно, объясните пожалуйста правила калибровки (какие регистры как влияют на результат), а то с даташитом у меня не особо получилось разобраться. Благодарю
Оптимизация здесь не требуется вообще. Флеша и скорости процессора хватает и позволяет не думать об этом. Лишняя трата времени, не тем занимаетесь. Запоминать не надо ничего есть мануал, на любой чип открываешь и конфигурируешь. Через некоторое время забудете свой код и будете вспоминать как же вы там придумали конфигурировать, и в сети вас не поймут. А CMSIS все понимают. Вы лучше аппаратуру, OS, драйверы изучайте и пишите хорошо. Книжки почитайте.
_________________ Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
Последний раз редактировалось Oxford Пт апр 26, 2019 12:40:37, всего редактировалось 8 раз(а).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 22
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения