Не используемые функции, Keil Опции

[Matic]

Установил Keil. Создал проект через STM Cube.

При компиляции в проект включаются все функции, даже те которые не используются!!!!!!!
Таким образом не написав ни строчки, только включив одну стандартную библиотеку в проект потраченно уже несколько кило памяти.
Раньше при работе с другими компиляторами( к примеру MPLAB ) такого никогда небыло, компилятор сам автоматом выбрасывал не используемые функции.
Это можно как-то поправить?

[KnightIgor]

При компиляции в проект включаются все функции, даже те которые не используются!!!!!!!
Раньше при работе с другими компиляторами( к примеру MPLAB ) такого никогда небыло, компилятор сам автоматом выбрасывал не используемые функции.

Смотрите внимательно файл карты памяти. Поищите слово remove. Не все так страшно. Но если хоть где в проекте есть printf, это тянет за собой сразу много чего.

Сообщение отредактировал KnightIgor - Nov 23 2015, 13:56

[Matic]

Смотрите внимательно файл карты памяти. Поищите слово remove. Не все так страшно. Но если хоть где в проекте есть printf, это тянет за собой сразу много чего.

В том то и дело что ничего нет. Только конфигурация GPIO из стандартной библиотеки которая подключается при создании проекта из STM куба

Сообщение отредактировал Matic - Nov 23 2015, 14:23

[KnightIgor]

В том то и дело что ничего нет. Только конфигурация GPIO из стандартной библиотеки которая подключается при создании проекта из STM куба

Киньте MAP файл.

P.S. Попробуйте установить птичку "One ELF Section per Function" в опциях проекта, закладка C/C++, и перекомпилировать.

Сообщение отредактировал KnightIgor - Nov 23 2015, 15:12

[Matic]

Киньте MAP файл.

 map.txt ( 47.99 килобайт ) Кол-во скачиваний: 405

Птичька уже стояла по умолчанию

да... конфигурация тактироания весит 1176. Походу дело не в компиляторе. Просто библиотека ФУНКЦИЙ ИНИЦИАЛИЗАЦИИ СЪЕДАЮТ 3000БАЙТ!!!!!
Чего они там инициализируют на столько флеши

Похоже эта CMSIS универсальная для всех ARM-ов от ST отсюда и такая раздутость. За переносимость кода платить флешью

Надо ручками инициализировать прям в регистры, всётаки не ПК память надо экономить, её не так много в STM32F030 всего 16К, если на инициализацию 3 тратить, то что дальше будет

Еще один вопрос: как быстро перейти на описание переменной/функции. Опять же привык что во всех современных компиляторах(по крайней мере с которыми мне приходилось работать) Ctrl + ЛМ и попадаешь на инициализацию.
В Keil пока нашёл только в контекстном меню, но это как то не очень удобно.
Можно ли настроить где-то?

Сообщение отредактировал Matic - Nov 23 2015, 15:55

[Alechek]

да... конфигурация тактироания весит 1176. Походу дело не в компиляторе. Просто библиотека ФУНКЦИЙ ИНИЦИАЛИЗАЦИИ СЪЕДАЮТ 3000БАЙТ!!!!!

Для интереса глянул на свое для STM32F103
Управление и универсальная функция инициализация (ноги) GPIO - 196/332* байта ПЗУ
Управление всем тактированием - 356/520*
Драйвер UART (без DMA, на все каналы) - 856/1132*
FreeRTOS - 4150/3318*

*(оптимизация вкл/выкл)


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

[Ruslan1]

Про размер кода: я тут проектик несложный с PIC на STM32 перевожу. Расчетная часть( много с плавающей точкой) и всякие конечные автоматы те же, просто периферия переписана под новое железо и взаимодействие частей переписано под многозадачность.

На PIC18 проект занимал в флеше 22 килобайт (без RTOS), со средней оптимизацией

На STM32F0 (с FreeRTOS) - 21 килобайт (с максимальной оптимизацией)
не реализовал несколько незатратных действий (вроде поддержки еще одного SPI и простой обработки), ну, может, на 1-2 килобайта кода наскребу еще.

То есть разницы вообще нет. При всей разнице компиляторов, архитектур и разрядности. А если вспомнить, что в STM32 я еще и RTOS добавил- то вообще получается что код сократился.

Так что не все так плохо. Нет причин паниковать.

[ataradov]

Так что не все так плохо. Нет причин паниковать.

Так паника не про PIC vs STM32. Паника про качество кода от ST и от всех остальных производителей железа.

Если писать все по-человечески, то понятно, что все нормально будет.

[Ruslan1]

Так паника не про PIC vs STM32. Паника про качество кода от ST и от всех остальных производителей железа.

Если писать все по-человечески, то понятно, что все нормально будет.

Я забыл сказать, что тоже SPL использую в STM32. Говорят, что это почти HAL по избыточности. Ну и ничего. Особых издержек по сравнению с PIC без сторонних библиотек не вижу, так как даже с этими наворотами код плотнее чем у PIC18, мне еще плотней пока не нужно. Будет нужно- начну паниковать и выкидывать SPL.

А качество кода- это понятие очень субъективное, у каждого оно свое.