Overfow dynamic memory
- Войдите на сайт для отправки комментариев
Втр, 06/10/2015 - 14:33
Добрый день.
Думаю не я первый, кто сталкнулся с данной проблемой.
Я сделал скетч, он работает. Спасибо форумчанам. Провел тестирование, все гуд. Но как обычно возникло желание немного приукрасить. К тому же у меня есть OLED дисплей.
И того:
Ардуино нано + TLC5940 + DALLAS-DS18B20 и + OLED дисплей 0.96''
И вот, только вставил в начале:
#include <OLED_I2C.h> // Подключение библиотеки для дисплея
OLED myOLED(SDA, SCL, 8);
Сразу при компилляции получил:
Sketch uses 12 680 bytes (41%) of program storage space. Maximum is 30 720 bytes.
Global variables use 2 227 bytes (108%) of dynamic memory, leaving -179 bytes for local variables. Maximum is 2 048 bytes.
Попытки урезать количество переменных, которые я использую особо не помогли. Поэтому видимо все динамическую память занимают переменные в библиотеке.
Есть какой-либо не сильно сложный все же уместиться в выделенную память?
Уместиться-то можно, но это потребует некоторого программирования. Вы готовы? Если готовы - дерзайте. Если нужны советы, так хоть скетч покажите.
Вот скетч с внесенными стоками
Да что за вирус такой? Зачем лепить RTC на A0 и A1?
Мало аппаратного TWI на A5 и A4?
Все строки в FLASH!
И да, для OLED надо много памяти, если тебе не надо рисовать на экране, то замени его на текстовый дисплей 20x4 например.
Не вникал в программу, но заметил, что сплошь и рядом используется тип данных unsigned long да еще и в двумерных массивах. А это по 4 байта на каждое значение. Уверены, что unsigned int никак не обойтись?
В том то и дело, что хочу нарисовать уровни с их значениями.
Не вникал в программу, но заметил, что сплошь и рядом используется тип данных unsigned long да еще и в двумерных массивах. А это по 4 байта на каждое значение. Уверены, что unsigned int никак не обойтись?
К сожалению не обойтись. В скетче считается все в миллисекундах. Значения очень большие.
Да, и все попытки как то ужать мои переменные не очень сильно влияют на общий объем.
К сожалению не обойтись
Ну это как еще посмотреть. Даже переменная ventpin определена как int, а там типа byte хватит с огромным запасом. А еще лучше в #define ее закатать. Она же в программе не вычисляется.
Ну и о строках уже говорили. Одна только фраза " Chanal : Sanrise : Day : Sanset : Night : Led chanal: Inverse" занимает почти половину недостающей памяти.
И его в лонг???
К сожалению не обойтись
Ну это как еще посмотреть. Даже переменная ventpin определена как int, а там типа byte хватит с огромным запасом. А еще лучше в #define ее закатать. Она же в программе не вычисляется.
Ну и о строках уже говорили. Одна только фраза " Chanal : Sanrise : Day : Sanset : Night : Led chanal: Inverse" занимает почти половину недостающей памяти.
Эта строка " Chanal : Sanrise : Day : Sanset : Night : Led chanal: Inverse" занимает не динамическую память, а память скетча, а тут проблем нет...
В военное время cos(0) может достигать 4, а булевые переменные хранить вообще никакой памяти не хватит.
Эта строка " Chanal : Sanrise : Day : Sanset : Night : Led chanal: Inverse" занимает не динамическую память, а память скетча, а тут проблем нет...
Да ладно...
Sketch uses 1 810 bytes (5%) of program storage space. Maximum is 30 720 bytes.
Global variables use 264 bytes (12%) of dynamic memory, leaving 1 784 bytes for local variables. Maximum is 2 048 bytes.
Sketch uses 1 836 bytes (5%) of program storage space. Maximum is 30 720 bytes.
Global variables use 182 bytes (8%) of dynamic memory, leaving 1 866 bytes for local variables. Maximum is 2 048 bytes.
Array, Value просятся во флеш, поскольку не меняются. Возможно еще что то. Пусть не так уж и много, но всё таки.
Про сообщения во флеш уже сказали.
Уже этого будет немало. В смысле освободится немало.
sinnpriest,
главный отжиратель памяти у Вас массив scrbuf[1024], объявленный в классе OLED. Он кушает ровно половину всего, что у Вас есть.
От него можно избавиться, хотя для этого потребуется немного переделать библиотеку. Такая переделка потребует навыков программиста среднего уровня. Не выше, но и не ниже - не ахти какая сложность, но и не для "чайников".
Как избавиться:
Библиотека устроена так: все изменения пишутся не напрямую на экран а в этот самый массив-буфер. Затем, когда Вы вызываете функцию update, она тупо копирует весь буфер в эран.
Можно переписать так, чтобы необходимые Вам изменения не накапливались в буфере, а писались на экран напрямую. Тогда надобность в буфере (как и в функции update) отпадёт вовсе и Вы спокойно освободите этот килобайт.
Т.е. я бы на Вашем емсте, переписал бы эту библиотеку на новое место как "свою" и правил бы. В итоге получилась бы новая бибилиотека, которая этот огромный буфер не использует.
Ну и мелочёвкой (типа "константы в progmem") о которой Вам тут уже многие писали пренебрагать тоже не стоит.
В моменты, когда недостающей памяти счет идет на байты, эти байты и надо ловить на всем. А тут поле непаханное для оптимизации. Про ventpin я уже говорил, туда же tmin и tmax. Вобщем, есть где развернуться.
Эта строка " Chanal : Sanrise : Day : Sanset : Night : Led chanal: Inverse" занимает не динамическую память, а память скетча, а тут проблем нет...
Да ладно...
Sketch uses 1 810 bytes (5%) of program storage space. Maximum is 30 720 bytes.
Global variables use 264 bytes (12%) of dynamic memory, leaving 1 784 bytes for local variables. Maximum is 2 048 bytes.
Sketch uses 1 836 bytes (5%) of program storage space. Maximum is 30 720 bytes.
Global variables use 182 bytes (8%) of dynamic memory, leaving 1 866 bytes for local variables. Maximum is 2 048 bytes.
Афигеть!!! Спасибо!!! ))) Да, я плохо в этом разбираюсь (
Я только этим Serial.print(F(".... освободил себе память до 85%...
ЕвгенийП верно поставил диагноз, но предложил слишком радикальный метод лечения.
Не обязательно самому переписывать библиотеку, достаточно найти такую, которая не использует буфер. Например, мою, которая выложена в теме "Кириллица на дисплее или что я делаю не так".
Правда, отказ от буфера накладывает довольно жесткие ограничения на то, что можно нарисовать, а что - нет. Но тут уж либо-либо. Библиотеки дисплея, не имеющие буфера, как правило, рассчитаны на то, что дисплей занимает далеко не центральное место в конструкции, а играет лишь вспомогательную роль.
PS. Кстати, переписал основные функции библиотеки, после чего она стала работать в 2-3 раза быстрее. На днях выложу новую версию.