Arduino.ru

Вы бы ссылку дали на библиотеку !

В той что я нашел поиском есть:

printNumI(long num, int x, int y, int length=0, char filler=' ');
printNumF(double num, byte dec, int x, int y, char divider='.', int length=0, char filler=' ')

То есть до 83 вырос размер скомпилированного кода? А сколько стали требовать переменные? 

Библиотека эта
http://www.rinkydinkelectronics.com/library.php?id=79

Предел для неё 0х7FFFFFFF - ст. бит для знака, т.е. при выводе 0хFFFFFFFF получаю -1.

Размер ОЗУ не обратил внимания, но там не было предупреждения, пробовал несколько раз , максимум 38%.

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

Их линкер сам повырежет

Библиотеку очень легко поправить. Найдите в файле .cpp фунцию

void OLED::printNumI(long num, int x, int y, int length, char filler)
 

скопируйте еще раз под другим именем, например

OLED::printNumUL

и поменяйте тип первого параметра с long на unsigned long

Еще не забудьте внести новую фунцию в хидер

Да, графика не используется.

Благодарен за советы.

И за науку, как править библиотеку!

Спасибо.

А Ваш код - тайна за семью печатями ? Размер программы не так критичен как размер ОЗУ.

Да не тайна конечно, но  разбирать  листинг на несколько страниц не в тему. Конструкция (не моя) выводит число по-байтно в шестнадцатеричной форме. Мне это не удобно, привычнее десятиразрядное десятичное число.Лазить каждый раз в калькулятор, когда уже всё есть и нужно только сдвинуть и вывести?  Расход ОЗУ в данном случае  не виноват. Основной код -тоже, я проверял. Неважно чем занято более 83 % флеши после компиляции, - страдает вывод на экран. Конструкция работает, насколько можно проверить с неполной индикацией. На одной мини даже сдувал мегу. Паял другую, думал китайцы чего нибудь наэкономили.

После правки библиотеки перестал запускаться IDE. Обновление не помогло. Так что пока нет результата.

Работаю.

Если в коде нет проблем, то не понимаю как он может зависеть от размера !

Так и я не понимаю, для чего и спрашиваю. Есть подозрение, что при компиляции чего-то пишется в верхние адреса флеши.Между "моим" кодом и загрузчиком. Поскольку частенько все "тексты" программы компилятор помещает "вверх" ( как в ардуино не могу на 100% утверждать), то  распухшая программа это цепляет. Пока это бредовое предположение подтвердить нечем.

Всё запаяно и подцепить программатор нет возможности. Если решение "малой кровью" не поможет, будем сдувать.

всё что компилятор пихает в память программ уже учтено в 83%

в оставшиеся 17% писать можно только через область загрузчика

Нет, загрузчик не считается. 100% - это без загрузчика.

Я про допуск на запись !

Так ТС же не из программы пишет во флешь, а всё грузит загрузчиком.) 

Он думает что строковые константы затираются и по этому вывод на экран ломается ...

Код надо анализировать, возможно всё, вплоть до распахивания памяти неправильным кодом, так то.

DIYMan распахивания ОЗУ и копий строковых переменных в ОЗУ, но не памяти программ.

IDE установил. Библиотеку дополнил. Пока могу сказать что компиляция без проблем.

27058 байт или 83% памяти устройства. Всего доступно 32256 байт.

Глобальные переменные 646 байт или 31% динамической памяти, оставляя 1402 байт для локальных переменных.

На железе смогу только завтра.

Почему возникла гипотеза про пересечение текста и кода во флеши? - используется макрос F() .

Или компилятор всё сам разруливает корректно?

Читаю тему, вижу, что не знаю - как в Arduino IDE задается размер загрузчика. Предположим я переписал в своей плате загрузчик на максимальный размер 4КБ. Как сообщить это IDE? Редактированием board.txt?

От размера загрузчика зависит только upload.maximum_size.

Т.е. в boards.txt создать дополнительно свой вариант платы?

Или исправить существующую запись. На ваше усмотрение.

Хорошая новость- исправленная библиотека работает и вывод корректный.

Плохая- видимо предположение о пресечении во флеши текстов имеет основание.

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

"Оптимизирую" дальше.