Всем привет.

У меня есть набросок, который при составлении для Teensy 3.2 (Cortex M4) использует 38020 байтов (всего 256 тыс.) Программного магазина.
То же самое на STM32 «Синяя таблетка» использует 52676 (макс - 64K). Я использую опцию «быстрее» (-O2) для обоих.

Похоже, есть много неиспользованных (?) материал в двоичном файле на обоих устройствах, но у STM32 есть как минимум 100 записей в таблице символов.
Кроме того, по крайней мере один неиспользованный постоянный массив, который находится на GC-ED на Teensy, кажется, присутствует на синей таблетке.

Я знаю, что системы времени выполнения могут не совпадать для обоих устройств, но все же это довольно разница.

Были ли у вас похожие впечатления переносить подростки на синие таблетки?

Спасибо, Ральф

Какое ядро ​​вы сравнили?

Я предполагаю, что основные различия - это варианты компилятора.
Например, Teensy не включает "-g" для O2, в то время как для ядра Роджера вариант -g доступен для всех оптимизаций. Попробуйте удалить -g на платформе.текст

Спасибо за ваше предложение.

Удаление опции -G не помогло, и обновление до последнего Artuino_stm32 добавило еще 102 байта в двоичный

Я увидел обсуждение одной из FORA GCC о аналогичной ситуации: неиспользованная функция (как и должна), но данные, которые он использовал (ныне неиспользованные), остались позади. Они говорили о версии 4.9 или что -то из компилятора. Я вижу, что Arduino для STM32 использует версию 4.8.3 компилятора, тогда как Teensy, кажется, использует версию 5.4.1. Возможно, это объясняет (некоторые из) несоответствия.

В любом случае, мне придется обрезать код вручную. Препроцессор на помощь!

Еще раз спасибо, Ральф

Запоздалая мысль: я все еще думаю, что во время выполнения много вещей, которых не должно быть (Malloc/Free, Hardwareserial, ...), если программист явно не использует/не экземплят ни одного из них. У нас действительно нет никакой памяти, чтобы сэкономить на вещах, которые мы не используем (Teensy не намного лучше в этом отношении, имейте в виду. Я сравнил линию таблицы символов по линии).

Было несколько дискуссий по вопросу большого размера мусорного ведра.
Простым решением было бы добавить -specs=nosys.specs -specs=nano.specs -u _printf_float

[Стивестронг - Чт 26 апреля 2018 г. 9:23] - Было несколько дискуссий по вопросу большого размера мусорного ведра.

Я знаю. Те, которые я нашел, я прочитал

В одной из этих тем, кто упомянул кто -то (и, кажется, здесь является консенсусом, что большинство синих таблеток на самом деле имеют 128 тыс. Флэш -мем.
Поэтому я решил перестать беспокоиться-на время ... и посмотреть, взрывается ли мои синие таблетки.

Спасибо, Ральф

Вопрос в том, удалось ли вам уменьшить размер кода или нет, чтобы этот размер стал сопоставимым с подростком или нет.

[Стивестронг - Чт 26 апреля 2018 г. 11:38] - Вопрос в том, удалось ли вам с этим дополнительным компилятором сократить размер кода, чтобы размер стал сопоставимым с размером Teensy или нет.

...И это очень хороший вопрос!

Это не так. Это уменьшило ОЗУ, но повышенное использование вспышки:
compiler.c.elf.extra_flags="-L{build.variant.path}/ld" -specs=nosys.specs -specs=nano.specs -u _printf_float

Вы можете сделать еще одну попытку, если вам не нужно сприннтф переменных поплавок, то вы можете уйти от выключателя -u _printf_float

Вы пробовали с ядром STM32? Он использует гораздо более новый набор инструментов. Разница, вероятно, вызвана операцией компилятора/линкера, я не могу увидеть другую причину такой большой разницы (обратите внимание, что USB-серийный код, если включен, составляет около 6-7 КБ кода на BluePill)

И Libmaple может составить с той же версией GCC, я бы проверил, что на случай, если он работает, таким образом будет более похожим сравнением.
Также хорошая идея - использовать анализатор файла карты от Danieleff. Он связан с постом в этой теме:
ViewTopic.PHP?F = 28&t = 1596&начало = 10

Это поможет увидеть, где будут самые большие куски Flash.

[Sompost - Чт 26 апреля 2018 12:48] - На самом деле это был просто эксперимент, чтобы увидеть, будет ли тот же код, работающий на подростке за 20 долларов. Будучи таким близким к 64K «пределу», был облом, так как я даже не начал добавлять код для MIDI, SD Card, Display, внешний DAC....

Перестань думать, что у тебя есть только 64K. Я еще не нашел чертеж, в котором нет полной 128 тыс., Наверное, там. Просто переверните меню, чтобы использовать 128 и перестаньте беспокоиться о размере кода.

[Рик Кимбалл - Чт 26 апреля 2018 г. 15:51] - Перестань думать, что у тебя есть только 64K. Я еще не нашел чертеж, в котором нет полной 128 тыс., Наверное, там. Просто переверните меню, чтобы использовать 128 и перестаньте беспокоиться о размере кода.

Я знаю, но я не могу перестать беспокоиться. Я был, в конце концов, учеником профессора. Вирт (из славы Паскаля) и как таковой я научился подсчитать байты.

В любом случае, кажется, что «подростковый компилятор» способен сделать вывод, что переопределенный метод больше не называется, в то время как «STM32-компилятор», по-видимому, не может и поэтому оставляет его (вместе со всем, что он использует).

Я добавил новый базовый класс, а соответствующая функция является чистой виртуальной (поэтому пустая функция переопределена). И для хорошей меры я также добавил -Spects = nano.спецификации флаг.

Вот что я получил. Возьми это, подростка!

Sketch использует 39012 байтов (59%) пространства для хранения программ. Максимум составляет 65536 байтов.
Глобальные переменные используют 12888 байтов (62%) динамической памяти, оставляя 7592 байта для локальных переменных. Максимум - 20480 байт.

Это круто или это круто?

Спасибо всем, Ральф

Просто хочу подчеркнуть, что у меня были проблемы с использованием автоматического серийного USB -перезапуска, используя Nano.Спецификации: http: // stm32duino.com/viewtopic.PHP?f = 3 ... 885#P27885

[Sompost - Солнце 29 апреля 2018 г., 9:20 утра] - Я добавил новый базовый класс, а соответствующая функция является чистой виртуальной (поэтому пустая функция переопределена). И для хорошей меры я также добавил -Spects = nano.спецификации флаг.

Если вы опубликуете код, я уверен, что мы могли бы выяснить, что вы делаете неправильно. Не видя кода, мы можем только догадываться, что расстраивает компилятор. Кстати, компилятор для Teensy (при условии, что это ARM MCU), а компилятор для STM32 - это то же самое. Разница в коде C/C ++ и компиляторах, которые используются для каждого ядра. Кроме того, я предполагаю, что вы используете Arduino IDE, а не какую -то другую IDE, такие как Slaeber, Platformio или VSCODE, которые влияют на размер кода.

Как мы уже обнаружили, может быть любое количество причин, по которым размер кода взрывается. Статические переменные класса являются общей проблемой. Я предложил решение в этой теме ViewTopic.PHP?f = 3&T = 1904#P25257 Используя -фно-threadsafe-statics, однако это решение было отклонено теми, кто использует Freertos. https: // github.com/rogerclarkmelbourne/ ... -319511181 . Не видя вашего кода, я могу только догадываться, если вы используете это то, что вы используете.

Всегда есть причина, по которой ваш код получает раздувание. Решить, как его решить и сделать остальную часть сообщества STM32Duino Happy - это другая история.

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

Это связано как с кодом в ядре, так и с компиляторами.

Но, как говорит Рик, это’в основном невозможно иметь оптимальное решение для всех’S индивидуальные требования, а также это’S с открытым исходным кодом, каждый может вносить любые отдельные изменения, они чувствуют себя подходящими

Я предполагаю, что все это сводится к тому, что если вы хотите оптимальный размер кода, то становится необходимым исследовать и понять некоторые компиляторы и их вероятные эффекты.

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

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

Если вы ищете самый маленький код, посмотрите на следующие флаги GCC:

-Ффункциональные сечения
-FDATA-сечения
-ОС

И этот флаг LD:

-Wl,-GC-сечения

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

Это синтезатор VSTI-Software, который я перенес в Teensy, потому что почему бы и нет? После того, как я узнал о «синей таблетке» (которая стоила одну десятую от подростка), я хотел посмотреть, будет ли она запустить тот же код. В конце концов, это было то же самое ядро.

Я видел, что в синтезаторе были большие волновые таблицы, которые использовали много оперативной памяти, несмотря на то, что он был по существу постоянным (рассчитано во время загрузки). Таким образом, я предварительно вычислил эти таблицы и #NCLUD их как const int, чтобы поместить в вспышку компилятором. Но потом я заметил, что использование вспышки не увеличивать на то же количество, что и использование RAM уменьшен. При анализе разборки я обнаружил, что компилятор, по -видимому, полностью отказался от таблицы, потому что больше ничего не использовалось (вычисление таблицы было его единственным использованием). Единственными другими «использованиями» были (1) функция члена класса, которая была переопределена, и (2) функция, которую я не называл.

Просто чтобы быть ясным: я не ожидал и не требовал, чтобы таблица исчезнула. У подростки достаточно вспышки/ОЗУ. Сохранение этих 8kbytes было просто долгожданным побочным эффектом - в дополнение к дьявольской умной оптимизации. Однако на синей таблетках, спасение этих 8K было бы очень желанным.

Итак, подводя итог, единственное, что меня беспокоило, было то, что компилятор для STM32 не также Отбросьте таблицу. Я не думаю, что есть различия в флагах компилятора, которые могут объяснить это другое поведение. Я не проверял каждый флаг, но те, которые устранят неиспользованный код/данные, находятся в обоих. Тем не менее, Teensy и STM используют другой компилятор версии Это может объяснить это (Teensy использует версию 5.4.1 компилятора).

В любом случае, несмотря на мое нежелание менять код, который я не писал, я думаю, что моя модификация (добавление абстрактного базового типа к объекту) была приемлемой. Отделение типа объекта от его реализации всегда хорошо. Так они говорят. Где-то. Я думаю.

Спасибо всем, и я надеюсь, что вы меня не ненавидите

Ура, Ральф

[Sompost - Пн 30 апреля 2018 г. 14:55] - На самом деле, мне нужно быстрый Код больше, чем мне нужен небольшой код, по крайней мере для ядра алгоритма.

Оберните это вокруг функций, которые, по вашему мнению, должны быть быстрее:

#pragma gcc push_options
#pragma gcc optimize ("O3")

Код, нуждающийся в оптимизации скорости

#pragma gcc pop_options

В меню доступно множество оптимизаций, в том числе -O3 и линкер (но я не сделал’Найти параметры линкера очень полезны или даже что они всегда привели к коду, который будет работать)

По умолчанию -OS, для наименьшего двоичного, однако, когда я читаю документы GCC, они, казалось, подразумевали, что -OS похож на -O2, но с несколькими предпочтениями, смещенными в сторону небольшого размера кода.

Итак, я не дону’Не думаю -O2 намного быстрее, но это будет много зависеть от того, что делает ваш код.

я’ve использовал -O3 довольно много и у него не было проблем с ним.


Кстати. Поместить массивы Const в Flash будет медленнее, чем их в RAM из -за необходимых состояний ожидания, когда ядро ​​ARM считывается из Flash.

версия ARM GCC также важна.
Если вы действительно хотите сравнить, используйте ту же версию. По крайней мере, основное число V5.х.х