Функциональные блоки и размер занимаемой ими памяти?

[DWD]

Кто нибудь заморачивался вопросом, сколько байт в памяти занимает тот или иной функциональный блок рисуемой программы?

Пример.
Есть приличный уже по размеру проектик (22,96КБ) на UNO.
В одном месте получилось так, что стоят два блока дисплея но на каждый выводится часть общей информации. Решил объединить всё в одном блоке дисплея, а выводимую информацию скомпоновал блоком сложения строк, который и так уже был. Добавил только ему ещё один вход. После компиляции размер проги получился 22,838КБ. То есть, на 122 байта меньше!

Если грубо, то получается, что блок дисплея занимает в памяти примерно 122 байта.
А у меня в создаваемом проекте аж 15 таких блоков дисплея. Почти 1,8КБ памяти занимает только дисплей...
Теперь вот думаю, может перекомпоновать проект так, что бы дисплей был один, а выводимая на него информация формировалась блоками сложения и переключателями?
Глядишь - и места на 1КБ станет больше.
А то уже 70% памяти занято, а есть ещё куча задумок по расширению функционала создаваемого проектика и боюсь, что места не хватит...

Предлагаю делиться опытом в этом плане. А имея что-то типа базы по размерам занимаемой блоками памяти можно будет создавать более оптимальные по размеру проекты.

[Max]

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

[DWD]

А выводы какие-то были сделаны и почему кануло?
Ссылочку не помните? Или ключевые слова для поиска...

[support]

Пока это сделать не возможно. Единственная возможность, в свойствах проекта поставить галочку "Компилировать при  проверке". Тогда нажав кнопку "Проверить" Вы получите отчёт по занимаемой памяти.

[DWD]

Я имел в виду совсем другое. И не просил сделать такой подсчёт в самой программе.
Чисто опытным путём определить, в каком случае размер программы меньше.

Вот, наприер, нужно будет попробовать сравнить занимаемый объём при соединении между собой двух блоков линией и посредством переменной...

[Kocтик]

Пока это сделать не возможно

Я, почему то думал что каждый определённый блок занимает определённый объём памяти.

[support]

Я, почему то думал что каждый определённый блок занимает определённый объём памяти.

Не совсем так.  Дело в том что FLprog компилирует свой проект в код на С. Причем все блоки настраиваемые, соответственно код на С при разных настройках получается разный. Затем код на С компилируется в hex файл при помощи компилятора от ArduinoIDE. Там есть свой оптимизатор и т.д. И только после получения hex файла можно понять сколько проект займёт памяти в контроллере.

[Chaynik]

Предлагаю делиться опытом в этом плане. А имея что-то типа базы по размерам занимаемой блоками памяти можно будет создавать более оптимальные по размеру проекты.

Вот значит что заметил я

К примеру, создаём простой проект из кнопки и светодиода.
В настройках кнопки включаем "подтягивающий резистор" и защиту от дребезга.

Компилируем проект:

Получаем скетч размером 1116 байт.

Создаём ещё один проект, но в настройках кнопки отключаем "защиту от дребезга",
а будем использовать блок "Bounce" - что по сути одно и тоже.

Компилируем проект:

Получаем скетч размером 1096 байт.
Т.е. с блоком, размер скетча на 20 байт меньше.
Конечно это не так много, но вдруг кому-нибудь, этих 20 байт не будет хватать

[Kocтик]

FLprog компилирует свой проект в код на С

Значит, если взять сторонний компилятор то можно без труда программировать любой МК? Единственное неудобство программатор.

[krom23]

Да, ещё не стоит забывать, что компилятор трассирует блоки исходя из наличия ближайших свободных вентилей и их более рационального размещения, а отсюда следует, что один и тот-же блок в разных программах будет хоть немного, но отличаться по "массе" от аналогичных. Может я не прав?

[alverzilin]

Я вообще заметил, что скетч по своему "составу", после флпрог, сильно отличается от рукописных, но это понятно. программа... автоматизация.. и всё такое... но моим не опытным глазом, кажется что там много "лишнего"... Подскажите, это я лузер и это норма или только я на это обратил внимание?)

[Boroda]

alverzilin, это особенность алгоритма FLProg. Если стоит длинная цепочка логики и в конце инее висят две переменные, то для каждой переменной эта цепочка просчитывается отдельно. Но думаю, что Ардуино ИДЕ потом все оптимизирует. Уже пару раз сталкивался с оптимизацией IDE:
1.
if ((X)and(Y)) {Z;}
if (X) {W;}

2.
if (X)
{
  if (Y) {Z;}
  W;
}
Первый вариант занимал меньше памяти.

[alverzilin]

ИДЕ потом все оптимизирует

Это пример оптимизации? В первом варианте она?

[Boroda]

alverzilin, это строчки из пользовательского блока.
Попросили оптимизировать.

Первый вариант - то, что было у автора блока.
Второй вериант переписал я.

В итоге объем кода вырос. Хотя в 1 случае три сравнения, а во втором только 2. Как компилятор работает - хз.

[alverzilin]

Как компилятор работает - хз.

Магия...)) Короче, можно не парится, что между флпрогом и закачкой в ардуино имеется аброкадабра?)