Оптимизация размера скетча

Logik
Offline
Зарегистрирован: 05.08.2014

qwone пишет:

 А рациональные и иррациональные числа не страшны.

особенно иррациональные не страшны. Их просто не бывает в ИТ ;)

cyberman
Offline
Зарегистрирован: 30.10.2018

b707 пишет:

negavoid пишет:

Ну окей, хоть и не думаю, что это очень страшно.

int iTemp = Sensor.getFloatTemp() * 100;
// ...
Serial.println( (float) iTemp / 100 );

 

код, который Вы привели - показывает, что Вы совершенно не понимаете сути проблемы. Приведение к типу float внутри Serial.print() - это уже использование вычислений с плавающей точкой, и соответвующее увеличение размера кода

Сравните:

void setup() {
  // put your setup code here, to run once:
Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
byte x = Serial.read();
Serial.println( (float) x/100  );
}

Скетч использует 3212 байт (9%)
Глобальные переменные используют 200 байт

а теперь заменим вывод на целочисленный


Serial.print(  x/100  );
Serial.print(  "."  );
Serial.println(  x%100  );

Скетч использует 1834 байт (5%)
Глобальные переменные используют 190 байт

примечание - операция чтения х из сериал добавлена, чтобы компилятор не заменил значение х/100 заранее рассчитанной константой

Спасибо за подсказку. Поясните, если не сложно - куда делись 10 байт ОЗУ? Хочу понять сам принцип, потому что аналогично автору темы испытываю дикий дефицит памяти, причем в основном динамической. 

negavoid
Offline
Зарегистрирован: 09.07.2016

Да куда-нибудь их съела работа с запятой, дизассемблировал оба примера, там очень много чего добавляется при работе с float.

Повторюсь, сейчас идёт 2019 год и проблем с дефицитом памяти практически никогда быть не должно. Не хватает UNO - бери Мегу, stm32, esp8266, esp32, raspberry, x86, x64.

cyberman
Offline
Зарегистрирован: 30.10.2018

Спасибо, понял

Logik
Offline
Зарегистрирован: 05.08.2014

negavoid пишет:

 проблем с дефицитом памяти практически никогда быть не должно. Не хватает UNO - бери Мегу, stm32, esp8266, esp32, raspberry, x86, x64.

гладко было на бумаге, да забыли про овраги. Дефицит памяти проявляется не в начале разработки, а ближе к концу. Представляете себе процесс миграции с уно на х64, когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

Logik пишет:

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

negavoid
Offline
Зарегистрирован: 09.07.2016

Конечно представляю, и даже заложил на это целый 1% случаев. Только конкретный текущий случай к ним не относится, ибо вряд ли люди, у которых серийно разработанное их же устройство работает годами, придут на форум ардуино поинтересоваться, как убрать из кода плавающую точку для оптимизации.

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

скорее, сначала убьют бутлодыря. 

Logik
Offline
Зарегистрирован: 05.08.2014

negavoid пишет:

Конечно представляю, и даже заложил на это целый 1% случаев. 

Ты не заложил, ты положил на опыт других. Именные грабли тебя подправят ;)

negavoid пишет:

 Только конкретный текущий случай к ним не относится, 

А почитать стартовое?

Ictic_Step пишет:

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

 

negavoid пишет:

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

Нет. Не придут. Но от этого проблема оптимизировать древний софт на древнем железе или похерить все и переходить на новое не исчезнет.

 

Logik
Offline
Зарегистрирован: 05.08.2014

DetSimen пишет:

Logik пишет:

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

Или еще. Про фиаско. Приезжает VL53LOX, цепляеш "Adafruit_VL53L0X.h" и в пошти голом проекте, токо в сириал результат пихает.

Скетч использует 17234 байт (56%) памяти устройства. Всего доступно 30720 байт.
Глобальные переменные используют 1220 байт (59%) динамической памяти, оставляя 828 байт для локальных переменных. Максимум: 2048 байт.
 

А я вот на него надеялся.. Вот шо они, сука, накрутили в той либе чтоб по i2c так опросить датчик?

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

Там, наерно, Пуховы лямбды с шоблонами.  

negavoid
Offline
Зарегистрирован: 09.07.2016

Logik пишет:
Ты не заложил, ты положил на опыт других. Именные грабли тебя подправят ;)

И правильно сделал, все прыгнут с крыши - и мне что, за ними? А именные грабли... Опыт у меня поменьше вашего, но не то, чтобы особо намного, не испытываю подобных затруднений, значит что-то, видимо, делаю по-другому.

Logik пишет:

А почитать стартовое?

Ictic_step уже два месяца не посещает тему, диалог ведётся с cyberman, которому нужно оптимизировать флоаты и который явно делает не серийное, а домашнее хоббийное изделие, где благодаря ардуино допустима лёгкая замена контроллера на более современный.

Logik пишет:

Нет. Не придут. Но от этого проблема оптимизировать древний софт на древнем железе или похерить все и переходить на новое не исчезнет.

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

Logik
Offline
Зарегистрирован: 05.08.2014

Нефиг за гуманизм прятаться. В любом случае, что оптимизация, что переход на новое железо - людям работать. Мантры про  "2019 год и проблем с дефицитом памяти практически никогда быть не должно. " им ничем не помогут. А cyberman всего лишь интересовался подробностями ухода от плавающей точки, очевидно мысль про смену платформы ему ни к черту.  И если уж проблемы других вас не интересуют - то какого с своими взглядами лезть. Не интересуют - свалил по своим граблям танцевать, тут тусуются не безразличные и готовые обмениваться опытом.

negavoid
Offline
Зарегистрирован: 09.07.2016

Личные мнения других меня не интересуют даже более, чем их проблемы :)

cyberman
Offline
Зарегистрирован: 30.10.2018

Logik пишет:

 А cyberman всего лишь интересовался подробностями ухода от плавающей точки, очевидно мысль про смену платформы ему ни к черту.  

Да, платформу я менять не собираюсь (пока). Потому что ради хобийного девайса покупать мегу или еще что-то из перечисленного - это как-то не очень рационально. Поэтому буду оптимизировать, байтики выкраивать! negavoid - спасибо за идею. 

 

negavoid
Offline
Зарегистрирован: 09.07.2016

Хобби - это то, что как раз съедает деньги и/или время, но приносит удовольствие, поэтому в вашем случае это вполне нормально и допустимо (хотя мега всего на пару баксов дороже уны). А вот если бы у вас была цель побыстрее доделать и запустить девайс, и стоимость разницы между мегой и уной не превышала бы стоимость часа вашей работы с выкраиванием байтиков, то имел бы смысл мой подход.

На наш флейм не смотрите, на форуме считается признаком хорошего тона придираться к каждой запятой. Все по-своему правы, но признавать, что не ошибочное может быть и не только твоё мнение, никто не будет. :)

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

Атнють. Тут разные люди. 

negavoid
Offline
Зарегистрирован: 09.07.2016

Ну ладно, дида будет, но многие "аффтаритеты" - ни-ни :)

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

Logik пишет:

гладко было на бумаге, да забыли про овраги. Дефицит памяти проявляется не в начале разработки, а ближе к концу. Представляете себе процесс миграции с уно на х64, когда почти все готово, платы запаяны код написан или даже годами устройство работает, иногда выпущено и серией, а надо еще добавить коду но некуда?

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

Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

Logik пишет:

Мантры про  "2019 год и проблем с дефицитом памяти практически никогда быть не должно. " им ничем не помогут.

Дело не в мантрах.

Пока на Ардуино не будет 640 кбайт памяти, последней всегда будет не хватать.

Green
Offline
Зарегистрирован: 01.10.2015

Ага, "640 КБайт хватит для всех!". Памяти ВСЕГДА будет не хватать!) Особенно, если писать в стиле Win приложений.
Считаю что дисциплина должна быть всегда. Но и без фанатизма, если на то нет необходимости.)

negavoid
Offline
Зарегистрирован: 09.07.2016

Стиль win-приложений - это while(getmessage) { translatemessage, dispatchmessage } ? Если в таком стиле писать, то хватало бы и 640 кб, очень много чему :) Но катастрофически увеличилось бы время разработки и требуемая квалификация, поэтому сейчас тащат кучу библиотек, а над ними ещё куча, вот и получается бинарник (и это без секций ресурсов) на несколько мегабайт. Обсуждаем же память, обычно [в среднем] требуемую для работы [средней 2019 года] win-программы?, а то можно быстренько сделать allocmem(64Gb) под текстурки и аллес. А вот ещё есть прожка, массивы флоатов перемножает, ей требуется 94 Гб под эти массивы с данными, своп на ссд пердит и стонет, но софтина таки едет. Сделают через 10 лет по терабайту памяти в средней машине - ну дык к тому времени и алгоритмы понапишут, утилизирующие по 50 терабайт ))

ua6em
ua6em аватар
Offline
Зарегистрирован: 17.08.2016

DetSimen пишет:

скорее, сначала убьют бутлодыря. 

зачем убивать, можно перейти на miniCore, включить опцию LTO и глядишь сэкономленной памяти как раз и хватит

Logik
Offline
Зарегистрирован: 05.08.2014

andriano пишет:

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

Звероид, вылезь с ПК. Мы здесь эмбадедом занимаемся, а в этом деле дефицит памяти - постоянная составляющая на любом этапе. От ТЗ и до металолома. Потому как память - деньги заказчика и даже при составлении ТЗ заказчик всегда жмется (Из реального "А чего эта добавили 1МБ памяти аж 10$ цена выросла?! Да я за такие деньги гиг в комп поставлю! Наеб..аете?!"). Это в ПК системные требования определил и хот трава не кури, хочеш играть (рендерить, серфить и т.д.) - докупай память. Но здесь вам не там.

andriano пишет:

Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.

Даже думал не коментить, ты не от мира сего видно. Или дальше ПК нос не совал по работе. Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют. Расширенная (чувствуешь разницу с  измененной) функциональность всегда добавляется в старое железо до тех пор пока оно хоть как-то тянет. И это вопрос денег, причем очень больших, не те что в разделе "Проекты" (вот уже нашел на что ссылатся!!).  И если  группа товарищей может добавить новые хотелки в старое железо без его замены/апгрейда то их труд оплачивается c оглядкой на цены нового железа, так, чтоб не голословить https://tehpos.ru/katalog/pos-terminaly/ . Вот и прикинь в уме, если у паршивенького банка тысячи постерминалов по магазинам розтыкано. Не сложно понять что держать пару програмеров для "вковыривания" новых идей безумных менеджеров в старое железо оказывается взаимовыгодным. А новое железо докупается на расширение сети и замену неремонтопригодного. И вот когда масса нового станет существенной, вот тогда... тогда это новое уже устареет порядком )))) 

ПС. Один из первых проектов по работе делал на pic16c84. Сделал, но шеф решил потом перейти на 12f508. А там ассемблер урезаный и стек на два вызова (памяти как раз хватало в обрез). Ниче, месячишку ковыряний моих оплатили. Зато он почти на бакс дешевле, и площадь платы можна урезать.  А продавали их штук 500 в месяц. Вот и считай. Просто хобийные проекты, - не серийные. Потому и отношение бабок на железо и на разработку специфичное, отсюда и мировозрение свое. А на ПК - тоже свое, писал уже.

Ictic_Step
Offline
Зарегистрирован: 15.07.2019

Logik пишет:

andriano пишет:

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

Звероид, вылезь с ПК. Мы здесь эмбадедом занимаемся, а в этом деле дефицит памяти - постоянная составляющая на любом этапе. От ТЗ и до металолома. Потому как память - деньги заказчика и даже при составлении ТЗ заказчик всегда жмется (Из реального "А чего эта добавили 1МБ памяти аж 10$ цена выросла?! Да я за такие деньги гиг в комп поставлю! Наеб..аете?!"). Это в ПК системные требования определил и хот трава не кури, хочеш играть (рендерить, серфить и т.д.) - докупай память. Но здесь вам не там.

andriano пишет:

Второй случай, - когда код уже годами работает, еще менее правдоподобен: обычно первой мыслью при проектировании следующей версии проекта с существенно измененной функциональностью - а не перейти ли на другую элементную базу. Кстати, подтверждения этому можно найти и в разделе "Проекты" настоящего форума.

Даже думал не коментить, ты не от мира сего видно. Или дальше ПК нос не совал по работе. Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют. Расширенная (чувствуешь разницу с  измененной) функциональность всегда добавляется в старое железо до тех пор пока оно хоть как-то тянет. И это вопрос денег, причем очень больших, не те что в разделе "Проекты" (вот уже нашел на что ссылатся!!).  И если  группа товарищей может добавить новые хотелки в старое железо без его замены/апгрейда то их труд оплачивается c оглядкой на цены нового железа, так, чтоб не голословить https://tehpos.ru/katalog/pos-terminaly/ . Вот и прикинь в уме, если у паршивенького банка тысячи постерминалов по магазинам розтыкано. Не сложно понять что держать пару програмеров для "вковыривания" новых идей безумных менеджеров в старое железо оказывается взаимовыгодным. А новое железо докупается на расширение сети и замену неремонтопригодного. И вот когда масса нового станет существенной, вот тогда... тогда это новое уже устареет порядком )))) 

ПС. Один из первых проектов по работе делал на pic16c84. Сделал, но шеф решил потом перейти на 12f508. А там ассемблер урезаный и стек на два вызова (памяти как раз хватало в обрез). Ниче, месячишку ковыряний моих оплатили. Зато он почти на бакс дешевле, и площадь платы можна урезать.  А продавали их штук 500 в месяц. Вот и считай. Просто хобийные проекты, - не серийные. Потому и отношение бабок на железо и на разработку специфичное, отсюда и мировозрение свое. А на ПК - тоже свое, писал уже.


Я жду еще историй от вас)) Интересно читать

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

Logik пишет:

...Банкоматы видел? А терминалы в магазинах? Сколько лет они там стоят? Раскажи их владельцам про "проектировании следующей версии проекта с существенно измененной функциональностью" и сразу иди, не жди иначе они пошлют.

Лоджик, Вы всерьез собираетесь устанавливать в каждый из эксплуатируемых банкоматов по SD-ридеру? Причем так, чтобы поддержка этого ридера обязательно уместилась в установленный в нем контроллер?

Перечитайте исходный пост темы.

Ну и вообще, - не нужно путать DIY с серийно выпускаемыми устройствами. Это - практически не пересекающиеся ниши.

Logik
Offline
Зарегистрирован: 05.08.2014

Ну Вы же начали обобщать, про процесс разработки.

//DIY с серийно выпускаемыми устройствами. Это - практически не пересекающиеся ниши.

Об том и речь. 

У меня нет своего банкомата для опытов. Но на сколько я знаю туда любую переферию от ПК запросто поцепить,  был бы софт.

 

Logik
Offline
Зарегистрирован: 05.08.2014

// Я жду еще историй от вас)) Интересно читать

Так спрашуйте, если че интересует.))

Ictic_Step
Offline
Зарегистрирован: 15.07.2019

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

Logik
Offline
Зарегистрирован: 05.08.2014

Присоединяюсь! Спасибо Ictic_Step, что напомнили!