Прожорливая библиотека adafruit_ssd1306.h

Простейший код

Спойлер

#include <Adafruit_SSD1306.h>

#define SERbaud 9600

Adafruit_SSD1306 display(OLED_RESET);

int DELAY = 1000;

//========================================
void setup() {

Serial.begin(SERbaud);

// by default, we'll generate the high voltage from the 3.3v line internally! (neat!)
display.begin(SSD1306_SWITCHCAPVCC, 0x3D); // initialize with the I2C addr 0x3D (for the 128x64)
// init done

// Вывод заводской заставки из буфера
// Since the buffer is intialized with an Adafruit splashscreen
// internally, this will display the splashscreen.
display.display();
delay(3000);

// Clear the buffer.
display.clearDisplay();

//----------------------------------------

}
//========================================
void loop() {

Serial.println(memoryFree()); // печать количества свободной оперативной памяти

delay(DELAY);
//========================================
} // End loop
//========================================
// Переменные, создаваемые процессом сборки,

extern int __bss_end;
extern void *__brkval;

//-------------------------------------------------
// Функция, возвращающая количество свободного ОЗУ (RAM)
int memoryFree() {

int freeValue;
if((int)__brkval == 0)
freeValue = ((int)&freeValue) - ((int)&__bss_end);
else
freeValue = ((int)&freeValue) - ((int)__brkval);
return freeValue;
}
//-------------------------------------------------

Вопрос к знатокам.
Остаётся мало памяти. Практически ничего не возможно сделать. Это реально всё сжирает библиотека ? Можно ли победить ? С уважением.

ПС. Почему именно на этой библе свет клином сошелся ? Люблю Протеус, но ни с одной другой библой не могу получить картинку от Протеусного LCD SSD1306.
ППС. Самое заподлянское - что компилятор показывает более 1300 байт свободной оперативной памяти, а функция проверки памяти в реальном времени - показывает меньше 200-т байт. Если еще чуть добавить кода - программа вылетает в рестарт.

 

Я окончательно слез с 8-ми биток, если речь не идёт об экстремальном энергопотреблении.
Любой процессор из серии ESP32 + ESP-IDF + VSCode рвёт всё остальное, как тузик грелку.
Для SSD1306 я попросил cluad sonnet нагенерить вывод и скрипты для перевода шрифтов и картинок. Никаких лишних функций и проблем с памятью. КРА-СО-ТА!

 

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

Однако как изменились времена. Заметил что ИИ, отвечающий на вопросы в Гугле, оказывается не совсем глуп, и порой даёт дельные советы. Именно он посоветовал установить библиотеку
OLED_I2C.h с сайта web: http://www.RinkyDinkElectronics.com/
И в Протеусе показывает и места мало кушает. НО - и в ней пришлось переправить адрес дисплея с 3C на 3D. SLA = 0x3D !!! Те что я покупал 128х64, и тот который модель в Протеусе - имеют адрес 0x3D. На первый взгляд похожа на Гайверовскую.

ПС. Сколько ни пробовал в библе U8glib.h поменять адрес 3C на 3D - Заставить в Протеусе работать LCD на SSD1306 - не удаётся.(((

 

Блох ковали, ковали, да не выковывали... Не бегают подкованные блохи по земле, хотя Левша наш соотечественник.
Конечно, хобби у всех разные, и это вполне достойное, но и разбираться с новым - тоже вполне ничего. Как и @parovoZZ перешел на ESP32, особенно на S3 Zero.

 

Не спорю - охота пуще неволи. Работал инженером при хим-лаборатории. Импортные приборы на МК, и все на разных. Осваивать очередные - а смысл ? Везде одинаково. Если кто придумает реальный ИИ - то он от конкретной модели МК не будет зависеть.)))

 

если сравнивать бесплатный гугл ИИ и платный claud sonnet - лично мне бесплатный гугл больше по душе. Cluad пишет на любой мало-мальски простой вопрос огромные простыни кода, гугл выдаёт ровно то, что нужно. Хотя за обоими надо подчищать и оба не способны на масштабные проекты.

Опять-таки - просишь ИИ сгенерить "низ". Он это сделает в самом лучшем виде. Да: придётся потребовать от него всё перепроверить, сверится с исходниками именно той версии тулчейна, на котором сидишь, но зато итог будет на порядок быстрее, чем это будешь делать сам.
Ну и самое главное - чтобы реализовать идею, надо реализовывать идею, а не инструменты для её реализации. Потом, когда будет всё готово, можно будет заняться рефактрингом (опять-таки: ИИ на капельные запросы выдаст тучу вариантов, как это сделать или красиво и элегантно, или грамотно и быстро. Если речь про микропроцессор ESP32, то расскажет, как расположить вызов функций, чтобы кеш отработал в самом лучшем виде. Честно, до общения с ИИ даже не подозревал, что в ESP32 столько много тонкостей).

 

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

 

Тип дисплея ? - алфавитно-цифровой или графический. Принципиальная разница. Для первых библы намного легче. Если для графического - надо имя контроллера. Их - не один. Короче конкретизируйте вопрос. Для алфавитного ----- #include <LCD_1602_RUS_ALL.h> - будет самое то.
В посте 3 упомянута библа для графического ОЛЕД дисплея на чипе SSD1306. Там конкретно есть команда - с буфером работать или без. Она графику и без буфера выводит, но помедленнее. Места мало занимает. А, да - и в Протеусе всё показывает )))))

 

В гуголе тысячи их...

 

с точки зрения дисплея - без разницы, что выводить. Цифры, буквы, символы - это всё графические примитивы из какого-то шрифта.

 

Зато с точки зрения МК - разница большая. В АЦ дисплее фонты - в его знакогенераторе (ПЗУ) и МК о них не парится. А в графическом - фонты все в памяти МК. Аэробусу видимо нужно то, что меньше ест памяти МК.

 

Речь шла про библиотеку под обсуждаемый дисплей.

 

Дык еще - какой МК. Если Уна - вышеназванная библа прекрасна. А если Диджиспарк, или голый ATtiny85 - Tiny4kOLED. Видел название Tiny8kOLED - но скачать не нашёл.