khusamov, судя по маркировке, Ваш дисплей имеет разрешение 128*64 пикселя. А, судя по занимаемому библиотекой объему, используется экранный буфер (ничем другим объяснить расход более 1000 байт нельзя). Так вот, OLED дисплей, который здесь упоминается, имеет такой же по разрешению экран и такую же (или очень сходную) организацию видеопамяти. Но гораздо более распространен, чем Ваш. Поэтому Вам и посоветовали воспользоваться наработками именно для него.
Я понял. Но это пока не реально сделать. О чем собственно и написал выше.
По поводу половины буфера спасибо! Сейчас посмотрю что можно сделать в этом направлении.
По поводу половины буфера спасибо! Сейчас посмотрю что можно сделать в этом направлении.
Там можно сделать даже не "половину буфера", а подвижный буфер на фигура+одна_ячейка. Т.к. самая длинная фигура занимает 4 ячейки, то буфер можно сделать на 5 ячеек в высоту и отображать на экран только его, т.к. в остальных местах экрана будет сохраняться неизменное изображение.
PS. Заказал себе сегодня такой дисплей - попробую с ним немного поковыряться.
Там можно сделать даже не "половину буфера", а подвижный буфер на фигура+одна_ячейка. Т.к. самая длинная фигура занимает 4 ячейки, то буфер можно сделать на 5 ячеек в высоту и отображать на экран только его, т.к. в остальных местах экрана будет сохраняться неизменное изображение.
Опять вы за свое. Понятное дело, если свою библиотеку писать, то можно хоть черта в ступе сделать. Вот дайте ссылку на библиотеку с подвижным буфером? ))))
Если хотите научиться программировать, то написание своей библиотеки - один из лучших вариантов.
А если Вам просто нужно готовое устройство - проще всего заказать прошивку в разделе Ищу исполнителя.
Я уже несколько раз написал что мне нужно (в двух постах ранее описывал что конкретно нужно). Из того что вы перечислили ни то, ни другое не нужно.
Я когда помогаю по реакту новичкам, то не заставляю сразу сходу писать низкоуровневые библиотеки. А предлагаю конкретные решения. Не хватает ОЗУ, вот пожалуйста, можно выкрутиться так и сяк. Покажу конкретную страницу документации в библиотеке где описано то что требуется. Ведь многое для новичков не очевидно. Предлагаю краткие куски кода, как я ранее решал эти проблемы.
А вы сразу - пишите свою библиотеку и точка. Шаг влево, шаг вправо - сразу расстрел.
Я уже несколько раз написал что мне нужно (в двух постах ранее описывал что конкретно нужно). Из того что вы перечислили ни то, ни другое не нужно.
Вот специально просмотрел всю тему, начиная с первого поста, но из того, что Вам нужно, нашел только один конкретный вопрос в сообщении №31 - как включить подсветку? И, вроде, этот вопрос был решен (судя по сообщению №33).
Далее идут туманные рассуждения, якобы маловато остается памяти. Но эти рассуждения не подкреплены никакими аргументами. В самом деле, почему Вы решили, что 250 байтов для Тетриса это мало? Я, вроде, привел оценки (в сообщении №39), что этого более чем достаточно. Никакого вразумительного возражения с Вашей стороны не последовало, были отмечены лишь Ваши сомнения (немотивированные) и замечания, что нужно еще хранить счет (это максимум 2 байта) и обрабатывать джойстик (еще 1-2 байта). Куда Вы собираетесь потратить еще целых 250 байтов?
Цитата:
Я когда помогаю по реакту новичкам, то не заставляю сразу сходу писать низкоуровневые библиотеки. А предлагаю конкретные решения. Не хватает ОЗУ, вот пожалуйста, можно выкрутиться так и сяк.
Так ведь Вам и было предложено конкретное решение - начать проектирование с оценки объема требуемой памяти и ее распределения (сообщения №42 и №46). И это единственный разумный совет в данном случае.
Цитата:
А вы сразу - пишите свою библиотеку и точка. Шаг влево, шаг вправо - сразу расстрел.
Отнюдь.
Насчет "писать свою библиотеку", вероятно, такой подход и просвечивает в моих сообщениях, но лишь потому, что я опираюсь на собственный опыт: как правило, когда я начинаю ковырять какую-либо библиотеку, оказывается, что мне не нравится, как она написана и появляется желание переписать все с нуля. Но вообще речь шла о том, что в любой существующей библиотеке надо добавить одну переменную и внести изменения в 2-3 функции, чтобы обеспечить ее работу с "подвижным" буфером.
Но в любом случсе:
- работа с любым проектом начинается с проектирования,
- один из первых этапов проектирования - оценка требуемого объема памяти,
- а для этого нужно заранее расписать, сколько памяти на какие переменные необходимо выделить.
Без этого - никак.
Я ведь спрашивал Вас, куда уходит память. Вы мне не ответили.
А на мой взгляд, память в тех примерах, о которых Вы говорите, распределена примерно так:
- около 1040 байт использует библиотека,
- около 700 байт использует скетч,
- около 300 байт остается свободными.
Т.е. если Вы вибросите те 700 байтов, что использует скетч, и вместо них разместите свой тетрис, то памяти Вам будет вполне достаточно.
А на мой взгляд, память в тех примерах, о которых Вы говорите, распределена примерно так:
- около 1040 байт использует библиотека,
- около 700 байт использует скетч,
- около 300 байт остается свободными.
Т.е. если Вы вибросите те 700 байтов, что использует скетч, и вместо них разместите свой тетрис, то памяти Вам будет вполне достаточно.
Нет, скетч не использует 700 байт. Речь шла о примерах их библиотеки. Например вот пример
void setup(void) {
u8g2.begin();
}
void loop(void) {
u8g2.clearBuffer(); // clear the internal memory
u8g2.setFont(u8g2_font_ncenB08_tr); // choose a suitable font
u8g2.drawStr(0,10,"Hello World!"); // write something to the internal memory
u8g2.sendBuffer(); // transfer internal memory to the display
delay(1000);
}
Нет, скетч не использует 700 байт. Речь шла о примерах их библиотеки. Например вот пример
void setup(void) {
u8g2.begin();
}
void loop(void) {
u8g2.clearBuffer(); // clear the internal memory
u8g2.setFont(u8g2_font_ncenB08_tr); // choose a suitable font
u8g2.drawStr(0,10,"Hello World!"); // write something to the internal memory
u8g2.sendBuffer(); // transfer internal memory to the display
delay(1000);
}
Видите ли, это не скетч, это - огрызок от него, по которому невозможно сказать, сколько байтов использует сам скетч. (проверить просто - то, что Вы привели, не компилируется). Можно лишь сказать, что он использует не меньше 13 байт. Но 13 байт - это мелочь.
Видите ли, это не скетч, это - огрызок от него, по которому невозможно сказать, сколько байтов использует сам скетч. (проверить просто - то, что Вы привели, не компилируется).
Мне кажется, эти два утверждения противоречат друг другу.
И еще: для оценки того, сколько памяти нужно скетчу, самое главное - это раздел описания переменных, а именно его-то Вы и выбросили.
Ссылку я на код отправил. В том, что я убрал нет никаких переменных, кроме объекта самого дисплея. То что он занимает это и есть - то что занимает сама библиотека. Потому я и убрал его из огрызка.
U8x8lib is the direct write, zero RAM, text only library part of U8g2lib.
Такой строки в документации по ссылке я не нашел. Но зато, благодаря вашему замечанию, нашел вот это.
Если мой конструктор U8G2_IST3020_ERC19264_F_4W_SW_SPI заменить на
U8G2_IST3020_ERC19264_1_4W_SW_SPI или U8G2_IST3020_ERC19264_2_4W_SW_SPI
То память для ОЗУ резко увеличивается!
Ура, то что и нужно.
Итого для U8G2_IST3020_ERC19264_F_4W_SW_SPI получаем такую раскладку:
Скетч использует 8274 байт (26%) памяти устройства. Всего доступно 30720 байт.
Глобальные переменные используют 1951 байт (95%) динамической памяти, оставляя 97 байт для локальных переменных.
Максимум: 2048 байт.
Недостаточно памяти, программа может работать нестабильно.
А вот для U8G2_IST3020_ERC19264_1_4W_SW_SPI такую:
Скетч использует 8270 байт (26%) памяти устройства. Всего доступно 30720 байт.
Глобальные переменные используют 607 байт (29%) динамической памяти, оставляя 1441 байт для локальных переменных.
Максимум: 2048 байт.
Тетрис и подобные ей программы требуют графический дисплей)))
нахрена для кубиков графический режим? Ты вапще как с логикой там, с программированием? 1 кубик - одно условное знакоместо. Я тетрис свой первый написал на терминале Мера, зеленом таком, с 25х80 символов текста, графики там отродясь не водилось.
Тетрис и подобные ей программы требуют графический дисплей)))
нахрена для кубиков графический режим? Ты вапще как с логикой там, с программированием? 1 кубик - одно условное знакоместо. Я тетрис свой первый написал на терминале Мера, зеленом таком, с 25х80 символов текста, графики там отродясь не водилось.
У вас брутальный текстовый тетрис, а у меня красивый графический тетрис. Там можно сделать красивое оформление. Чтобы было приятнее глазу.
А вообще это оффтопик. Я тетрис привел для примера. Можно было привести любую другую программу, где используется графика. Не стоит цепляться к таким мелочам.
Тетрис и подобные ей программы требуют графический дисплей)))
нахрена для кубиков графический режим? Ты вапще как с логикой там, с программированием? 1 кубик - одно условное знакоместо. Я тетрис свой первый написал на терминале Мера, зеленом таком, с 25х80 символов текста, графики там отродясь не водилось.
Там немного хуже.
на экране 128*64 надо разместить стакан 20*10. С учетом стенок стакана как раз получается, что один кубик 6*6 пикселей. Вот если бы было 8*8 (ну либо фонт 8*8 или даже 6*8), проблем бы не было. А при фрагменте 6*6 появляются некоторые сложности с выводом (которые, конечно, можно преодолеть, и способ преодоления уже в этой ветке указывался, но спрашивающему это, видимо, не по зубам).
Так что спрашивающий в какой-то степени прав: текстовый либо псевдотекстовый (это когда на графическом экране примитивы только кратного 8 размера) для реализации тетриса на конкретном экране не подходит.
Я же написал выше. У меня ТОЧНО ТАКОЙ ЖЕ дисплей, только версия ver.2.0
Что не так-то?
Разницы в плане пожирания ОЗУ не будет. И там и сям используется ОДНА библиотека.
Еще раз: сколько пикселей у Вас по длинной стороне экрана?
ОДНА и та же библиотека может использоваться для РАЗНЫХ экранов, и, соответственно, в зависимости от конкретного экрана будет жрать различное количество ОЗУ.
Ну там же не просто так нужно выбрать единственную строку из двух с половиной сотен.
... при фрагменте 6*6 появляются некоторые сложности с выводом (которые, конечно, можно преодолеть, и способ преодоления уже в этой ветке указывался, но спрашивающему это, видимо, не по зубам).
Еще раз. Тетрис был взят как пример графической программы. Можно вместо тетриса подставить любой программу для которой требуется графика и для которой ОЗУ 250 байт мало будет.
В следующий раз я вместо тетриса буду запрашивать дум.
А почему в исходнике тогда подключаете U8G2_IST3020_ERC19264_F_4W_SW_SPI?
Еще _ALT не хватает в этом конструкторе. Без него на экране черный квадрат малевичей.
Почему? Потому что так сказал человек, который ведет обзор этого дисплея на своем канале. Он прямо и указал на этот конструктор. Дисплей такой же как у меня, версия 2.00
Почему? Потому что так сказал человек, который ведет обзор этого дисплея на своем канале. Он прямо и указал на этот конструктор. Дисплей такой же как у меня, версия 2.00
Если я Вас правильно понял, Вы указываете библиотеке 192 пикселя вместо 128 только потому, что "один человек сказал"?
С Вашей строчкой тоже компилируется и даже демонстрирует некоторую работоспособность, только текст немного сдвинут и отзеркален по горизонтальной оси. Объем прошивки тот же.
А вот это не такой (только дешевле)? Получается много внешне одинаковых, а чипы разные? Пиксель имеет не квадратную форму? По картинке явно пропорции не 2:1. Графика будет искажаться? Просто тоже за кампанию захотелось :-)
Коллеги! Я, как обычно, интересуюсь выбором платформы: а почему Уно, а не Мега или Дуе илиСТМ32?
Воображение рисует постапокалиптическую картину: Ковид доедает остатки цивилизации, в борьбе за последнюю коробку Спутника 5 применено ЯО. Под мрачными тучами ядерной зимы, в окружении зомби (осложнения от прививок ;)) ) замерзают последние люди. Осталась одна Ардуина Уно, и только она справится с задачей управления реактором!!! Дисплей тоже только ....вот этот вот... остался.
Как страшно жить!
----------------
Смысл моего юмористического выступления в том, что на форуме моден странный спорт: "а давайте засунем слона в холодильник" ...в переносной. Либо и правда спорт, либо ложные представления об экономии средств и/или места.
К стыду хочу признать, что вынашиваю планы на про мини 168 :-(
А так в поделках игрушечных проще мне экран смартфона с картинками использовать - "иньтерфейс управления и мониторинга". Хочешь кнопки, хочешь шкалы...
Коллеги! Я, как обычно, интересуюсь выбором платформы: а почему Уно, а не Мега или Дуе илиСТМ32?
А в чем проблема то?
IMHO: Uno + монохром_128*64 + Тетрис - вполне себе сбалансированная конструкция.
Да. Не спорю.
Я не против спорта, но не для достижения реального результата. Если это не тиражируемое, а единичное изделие, то на фоне времени разработки стоимость контроллера равна нолю, так почему не взять побольше.
Если можно 3 вольта - СТМ32, если нужна связь - ЕСП32, если нужны 5В - Мега. А Уно/нано - для совсем мелочей. Ну а Тиньки - это святое, это уже только для души! ;))) (ну или если нужно 8 ног)
Да, буфер на половину экрана, а не половина буфера на экран.
khusamov, судя по маркировке, Ваш дисплей имеет разрешение 128*64 пикселя. А, судя по занимаемому библиотекой объему, используется экранный буфер (ничем другим объяснить расход более 1000 байт нельзя). Так вот, OLED дисплей, который здесь упоминается, имеет такой же по разрешению экран и такую же (или очень сходную) организацию видеопамяти. Но гораздо более распространен, чем Ваш. Поэтому Вам и посоветовали воспользоваться наработками именно для него.
Я понял. Но это пока не реально сделать. О чем собственно и написал выше.
По поводу половины буфера спасибо! Сейчас посмотрю что можно сделать в этом направлении.
По поводу половины буфера спасибо! Сейчас посмотрю что можно сделать в этом направлении.
Там можно сделать даже не "половину буфера", а подвижный буфер на фигура+одна_ячейка. Т.к. самая длинная фигура занимает 4 ячейки, то буфер можно сделать на 5 ячеек в высоту и отображать на экран только его, т.к. в остальных местах экрана будет сохраняться неизменное изображение.
PS. Заказал себе сегодня такой дисплей - попробую с ним немного поковыряться.
Там можно сделать даже не "половину буфера", а подвижный буфер на фигура+одна_ячейка. Т.к. самая длинная фигура занимает 4 ячейки, то буфер можно сделать на 5 ячеек в высоту и отображать на экран только его, т.к. в остальных местах экрана будет сохраняться неизменное изображение.
Опять вы за свое. Понятное дело, если свою библиотеку писать, то можно хоть черта в ступе сделать. Вот дайте ссылку на библиотеку с подвижным буфером? ))))
Я, честно говоря, не понимаю Вашей мотивации.
Если хотите научиться программировать, то написание своей библиотеки - один из лучших вариантов.
А если Вам просто нужно готовое устройство - проще всего заказать прошивку в разделе Ищу исполнителя.
Я, честно говоря, не понимаю Вашей мотивации.
Если хотите научиться программировать, то написание своей библиотеки - один из лучших вариантов.
А если Вам просто нужно готовое устройство - проще всего заказать прошивку в разделе Ищу исполнителя.
Я уже несколько раз написал что мне нужно (в двух постах ранее описывал что конкретно нужно). Из того что вы перечислили ни то, ни другое не нужно.
Я когда помогаю по реакту новичкам, то не заставляю сразу сходу писать низкоуровневые библиотеки. А предлагаю конкретные решения. Не хватает ОЗУ, вот пожалуйста, можно выкрутиться так и сяк. Покажу конкретную страницу документации в библиотеке где описано то что требуется. Ведь многое для новичков не очевидно. Предлагаю краткие куски кода, как я ранее решал эти проблемы.
А вы сразу - пишите свою библиотеку и точка. Шаг влево, шаг вправо - сразу расстрел.
В общем по поводу половины буфера спасибо! Кое-что на эту тему в документации нашел. Завтра опробирую.
Остальное мимо ((
Я уже несколько раз написал что мне нужно (в двух постах ранее описывал что конкретно нужно). Из того что вы перечислили ни то, ни другое не нужно.
Вот специально просмотрел всю тему, начиная с первого поста, но из того, что Вам нужно, нашел только один конкретный вопрос в сообщении №31 - как включить подсветку? И, вроде, этот вопрос был решен (судя по сообщению №33).
Далее идут туманные рассуждения, якобы маловато остается памяти. Но эти рассуждения не подкреплены никакими аргументами. В самом деле, почему Вы решили, что 250 байтов для Тетриса это мало? Я, вроде, привел оценки (в сообщении №39), что этого более чем достаточно. Никакого вразумительного возражения с Вашей стороны не последовало, были отмечены лишь Ваши сомнения (немотивированные) и замечания, что нужно еще хранить счет (это максимум 2 байта) и обрабатывать джойстик (еще 1-2 байта). Куда Вы собираетесь потратить еще целых 250 байтов?
Я когда помогаю по реакту новичкам, то не заставляю сразу сходу писать низкоуровневые библиотеки. А предлагаю конкретные решения. Не хватает ОЗУ, вот пожалуйста, можно выкрутиться так и сяк.
Так ведь Вам и было предложено конкретное решение - начать проектирование с оценки объема требуемой памяти и ее распределения (сообщения №42 и №46). И это единственный разумный совет в данном случае.
А вы сразу - пишите свою библиотеку и точка. Шаг влево, шаг вправо - сразу расстрел.
Отнюдь.
Насчет "писать свою библиотеку", вероятно, такой подход и просвечивает в моих сообщениях, но лишь потому, что я опираюсь на собственный опыт: как правило, когда я начинаю ковырять какую-либо библиотеку, оказывается, что мне не нравится, как она написана и появляется желание переписать все с нуля. Но вообще речь шла о том, что в любой существующей библиотеке надо добавить одну переменную и внести изменения в 2-3 функции, чтобы обеспечить ее работу с "подвижным" буфером.
Но в любом случсе:
- работа с любым проектом начинается с проектирования,
- один из первых этапов проектирования - оценка требуемого объема памяти,
- а для этого нужно заранее расписать, сколько памяти на какие переменные необходимо выделить.
Без этого - никак.
Я ведь спрашивал Вас, куда уходит память. Вы мне не ответили.
А на мой взгляд, память в тех примерах, о которых Вы говорите, распределена примерно так:
- около 1040 байт использует библиотека,
- около 700 байт использует скетч,
- около 300 байт остается свободными.
Т.е. если Вы вибросите те 700 байтов, что использует скетч, и вместо них разместите свой тетрис, то памяти Вам будет вполне достаточно.
А на мой взгляд, память в тех примерах, о которых Вы говорите, распределена примерно так:
- около 1040 байт использует библиотека,
- около 700 байт использует скетч,
- около 300 байт остается свободными.
Т.е. если Вы вибросите те 700 байтов, что использует скетч, и вместо них разместите свой тетрис, то памяти Вам будет вполне достаточно.
Нет, скетч не использует 700 байт. Речь шла о примерах их библиотеки. Например вот пример
void setup(void) { u8g2.begin(); } void loop(void) { u8g2.clearBuffer(); // clear the internal memory u8g2.setFont(u8g2_font_ncenB08_tr); // choose a suitable font u8g2.drawStr(0,10,"Hello World!"); // write something to the internal memory u8g2.sendBuffer(); // transfer internal memory to the display delay(1000); }C u8g2 вне "текстового" режима Вы можете выиграть только применив конфигурацию с уменьшенным буфером за счет потери производительности: https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#buffer-size
C u8g2 вне "текстового" режима Вы можете выиграть только применив конфигурацию с уменьшенным буфером за счет потери производительности: https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#buffer-size
Спасибо! Мне уже ранее предложили половинный буфер.
Тебе тетрис штоли надо сделать?
Тебе тетрис штоли надо сделать?
Мне уже предложили вариант увеличения доступного ОЗУ. Опробирую - позже отпишусь о результатах.
Нет, скетч не использует 700 байт. Речь шла о примерах их библиотеки. Например вот пример
void setup(void) { u8g2.begin(); } void loop(void) { u8g2.clearBuffer(); // clear the internal memory u8g2.setFont(u8g2_font_ncenB08_tr); // choose a suitable font u8g2.drawStr(0,10,"Hello World!"); // write something to the internal memory u8g2.sendBuffer(); // transfer internal memory to the display delay(1000); }Видите ли, это не скетч, это - огрызок от него, по которому невозможно сказать, сколько байтов использует сам скетч. (проверить просто - то, что Вы привели, не компилируется). Можно лишь сказать, что он использует не меньше 13 байт. Но 13 байт - это мелочь.
Видите ли, это не скетч, это - огрызок от него, по которому невозможно сказать, сколько байтов использует сам скетч. (проверить просто - то, что Вы привели, не компилируется).
Полный текст находится по адресу:
https://github.com/olikraus/U8g2_Arduino/tree/master/examples/full_buffe...
Там текст большой, потому и не стал тут выкладывать. Кроме конструктора я ничего не удалил, так что этот огрызок по сути и есть весь скетч.
У этой библиотеки есть версия без буфера же, в чем проблемы-то?
Там текст большой...
этот огрызок по сути и есть весь скетч.
Мне кажется, эти два утверждения противоречат друг другу.
И еще: для оценки того, сколько памяти нужно скетчу, самое главное - это раздел описания переменных, а именно его-то Вы и выбросили.
Мне кажется, эти два утверждения противоречат друг другу.
И еще: для оценки того, сколько памяти нужно скетчу, самое главное - это раздел описания переменных, а именно его-то Вы и выбросили.
Ссылку я на код отправил. В том, что я убрал нет никаких переменных, кроме объекта самого дисплея. То что он занимает это и есть - то что занимает сама библиотека. Потому я и убрал его из огрызка.
У этой библиотеки есть версия без буфера же, в чем проблемы-то?
Пришлите, пожалуйста, ссылку на документацию, где описано как воспользоваться режимом БЕЗ буфера.
U8x8lib is the direct write, zero RAM, text only library part of U8g2lib.
U8x8lib is the direct write, zero RAM, text only library part of U8g2lib.
Такой строки в документации по ссылке я не нашел. Но зато, благодаря вашему замечанию, нашел вот это.
Если мой конструктор U8G2_IST3020_ERC19264_F_4W_SW_SPI заменить на
U8G2_IST3020_ERC19264_1_4W_SW_SPI или U8G2_IST3020_ERC19264_2_4W_SW_SPI
То память для ОЗУ резко увеличивается!
Ура, то что и нужно.
Итого для U8G2_IST3020_ERC19264_F_4W_SW_SPI получаем такую раскладку:
А вот для U8G2_IST3020_ERC19264_1_4W_SW_SPI такую:
Спасибо!!!
Всем спасибо! Вопрос решен!
Я уж было чуть не поставил крест на этой библиотеке.
А вы под мой дисплей скомпилируйте. Вот этот конструктор U8G2_IST3020_ERC19264_F_4W_SW_SPI
Я выше написал, что при компиляции остается 92 байта.
https://github.com/olikraus/u8g2/wiki/u8x8reference
библиотека только текстового режима
https://github.com/olikraus/u8g2/wiki/u8x8reference
библиотека только текстового режима
Зачем она мне? Тетрис и подобные ей программы требуют графический дисплей)))
Этот режим хорош конечно. Но смысла нет. Лучше тогда дисплей поменять на текстовый. Там еще меньше ОЗУ тратится.
А в общем вопрос решен. Я выше описался о результатах. Так что спасибо!
Если мой конструктор U8G2_IST3020_ERC19264_F_4W_SW_SPI заменить на
U8G2_IST3020_ERC19264_1_4W_SW_SPI или U8G2_IST3020_ERC19264_2_4W_SW_SPI
Так какой у Вас контроллер?
Судя по приведенной строке, совсем не такой, который обсуждается в этой теме с начала. Там был U8G2_ST7565_ZOLEN_128X64_1_4W_SW_SPI
У Вас, судя по всему, разрешение не 128*64, а 192*64, т.е. экранный буфер не 1к, а 1.5к, что при объеме памяти 2к критически важно.
Приведите в точности название своего контроллера.
Тетрис и подобные ей программы требуют графический дисплей)))
нахрена для кубиков графический режим? Ты вапще как с логикой там, с программированием? 1 кубик - одно условное знакоместо. Я тетрис свой первый написал на терминале Мера, зеленом таком, с 25х80 символов текста, графики там отродясь не водилось.
Ну, выходит, снова облом: я заказал на Али дисплей по ссылке из исходного сообщения темы.
Получается, у Вас другой. И какой смысл тогда было писать в этой теме, даже не упомянув, что речь теперь уже идет о совсем другом дисплее?
Тетрис и подобные ей программы требуют графический дисплей)))
нахрена для кубиков графический режим? Ты вапще как с логикой там, с программированием? 1 кубик - одно условное знакоместо. Я тетрис свой первый написал на терминале Мера, зеленом таком, с 25х80 символов текста, графики там отродясь не водилось.
У вас брутальный текстовый тетрис, а у меня красивый графический тетрис. Там можно сделать красивое оформление. Чтобы было приятнее глазу.
А вообще это оффтопик. Я тетрис привел для примера. Можно было привести любую другую программу, где используется графика. Не стоит цепляться к таким мелочам.
Ну, выходит, снова облом: я заказал на Али дисплей по ссылке из исходного сообщения темы.
Получается, у Вас другой. И какой смысл тогда было писать в этой теме, даже не упомянув, что речь теперь уже идет о совсем другом дисплее?
Я же написал выше. У меня ТОЧНО ТАКОЙ ЖЕ дисплей, только версия ver.2.0
Что не так-то?
Разницы в плане пожирания ОЗУ не будет. И там и сям используется ОДНА библиотека.
Так какой у Вас контроллер?
Судя по приведенной строке, совсем не такой, который обсуждается в этой теме с начала. Там был U8G2_ST7565_ZOLEN_128X64_1_4W_SW_SPI
У Вас, судя по всему, разрешение не 128*64, а 192*64, т.е. экранный буфер не 1к, а 1.5к, что при объеме памяти 2к критически важно.
Приведите в точности название своего контроллера.
Это вы меня заставили задуматься... Сейчас посмотрю характеристики дисплея. Чуть позже выложу инфу.
Тетрис и подобные ей программы требуют графический дисплей)))
нахрена для кубиков графический режим? Ты вапще как с логикой там, с программированием? 1 кубик - одно условное знакоместо. Я тетрис свой первый написал на терминале Мера, зеленом таком, с 25х80 символов текста, графики там отродясь не водилось.
Там немного хуже.
на экране 128*64 надо разместить стакан 20*10. С учетом стенок стакана как раз получается, что один кубик 6*6 пикселей. Вот если бы было 8*8 (ну либо фонт 8*8 или даже 6*8), проблем бы не было. А при фрагменте 6*6 появляются некоторые сложности с выводом (которые, конечно, можно преодолеть, и способ преодоления уже в этой ветке указывался, но спрашивающему это, видимо, не по зубам).
Так что спрашивающий в какой-то степени прав: текстовый либо псевдотекстовый (это когда на графическом экране примитивы только кратного 8 размера) для реализации тетриса на конкретном экране не подходит.
Я же написал выше. У меня ТОЧНО ТАКОЙ ЖЕ дисплей, только версия ver.2.0
Что не так-то?
Разницы в плане пожирания ОЗУ не будет. И там и сям используется ОДНА библиотека.
Еще раз: сколько пикселей у Вас по длинной стороне экрана?
ОДНА и та же библиотека может использоваться для РАЗНЫХ экранов, и, соответственно, в зависимости от конкретного экрана будет жрать различное количество ОЗУ.
Ну там же не просто так нужно выбрать единственную строку из двух с половиной сотен.
Так какой у Вас контроллер?
Судя по приведенной строке, совсем не такой, который обсуждается в этой теме с начала. Там был U8G2_ST7565_ZOLEN_128X64_1_4W_SW_SPI
У Вас, судя по всему, разрешение не 128*64, а 192*64, т.е. экранный буфер не 1к, а 1.5к, что при объеме памяти 2к критически важно.
Приведите в точности название своего контроллера.
У меня два дисплея. Каждый на 128х64 пиксела. Вот ссылки на каждый дисплей.
https://aliexpress.ru/item/1005001621784395.html
https://aliexpress.ru/item/32800995659.html
... при фрагменте 6*6 появляются некоторые сложности с выводом (которые, конечно, можно преодолеть, и способ преодоления уже в этой ветке указывался, но спрашивающему это, видимо, не по зубам).
Еще раз. Тетрис был взят как пример графической программы. Можно вместо тетриса подставить любой программу для которой требуется графика и для которой ОЗУ 250 байт мало будет.
В следующий раз я вместо тетриса буду запрашивать дум.
У меня два дисплея. Каждый на 128х64 пиксела. Вот ссылки на каждый дисплей.
https://aliexpress.ru/item/1005001621784395.html
https://aliexpress.ru/item/32800995659.html
Ну и я такой заказал.
А почему в исходнике тогда подключаете U8G2_IST3020_ERC19264_F_4W_SW_SPI?
Кстати, откомпилировал с Вашими установками, у меня вообще 63 байта остается.
Ну и я такой заказал.
А почему в исходнике тогда подключаете U8G2_IST3020_ERC19264_F_4W_SW_SPI?
Еще _ALT не хватает в этом конструкторе. Без него на экране черный квадрат малевичей.
Почему? Потому что так сказал человек, который ведет обзор этого дисплея на своем канале. Он прямо и указал на этот конструктор. Дисплей такой же как у меня, версия 2.00
В следующий раз я вместо тетриса буду запрашивать дум.
Тогда Вам скажут, что с Uno там однозначно делать нечего.
Тогда Вам скажут, что с Uno там однозначно делать нечего.
Это был сарказм!
Почему? Потому что так сказал человек, который ведет обзор этого дисплея на своем канале. Он прямо и указал на этот конструктор. Дисплей такой же как у меня, версия 2.00
Если я Вас правильно понял, Вы указываете библиотеке 192 пикселя вместо 128 только потому, что "один человек сказал"?
Если я Вас правильно понял, Вы указываете библиотеке 192 пикселя вместо 128 только потому, что "один человек сказал"?
Вот этот конструктор
U8G2_ST7565_ERC12864_ALT_F_4W_SW_SPI
Выше я ошибся.
Но это не меняет результаты 1500 против 600.
Сейчас взял U8G2_ST7565_JLX12864_F_4W_HW_SPI (самое близкое к тому, что в теме), подключил - Hello World! работает.
И еще: для своего дисплея я в свое время (сразу после покупки) нашел следующий скетч:
/* JLX12864G-086 (Graphic LCD 128x64) Pin Connect : CS : 10 RST: 8 RS : 9 SDA: 12 SCK : 13 LEDA : 5 VDD : 5 VSS: GND */ const int csPIN = 10; // CS const int rstPIN = 8; // RST const int rsPIN = 9; // RS const int sckPIN = 13; // SCK const int sdaPIN = 11; // SDA unsigned char graphic1[]={ 0xf0, 0xf8, 0x6c, 0x6c, 0x6c, 0x78, 0x70, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, 0xf0, 0xf8, 0x6c, 0x6c, 0x6c, 0x78, 0x70, 0x00, 0x00, 0xf0, 0xf8, 0x0c, 0x0c, 0x9c, 0x98, 0x00, 0x0c, 0xfe, 0xff, 0x0c, 0x0c, 0x00, 0xf0, 0xf8, 0x9c, 0x0c, 0x9c, 0xf8, 0xf0, 0x00, 0x00, 0xf0, 0xf8, 0x9c, 0x0c, 0x98, 0xff, 0xff, 0x00, 0x00, 0x88, 0xcc, 0x6c, 0x2c, 0xfc, 0xf8, 0x00, 0x0c, 0xfc, 0xf0, 0x00, 0xf0, 0xfc, 0x0c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xe0, 0x30, 0x10, 0x08, 0x0c, 0x04, 0x04, 0x02, 0x06, 0x03, 0x11, 0x41, 0x01, 0x01, 0x01, 0x07, 0x11, 0x21, 0x41, 0x41, 0x81, 0x81, 0x01, 0x02, 0x82, 0x80, 0x44, 0x1c, 0x08, 0x90, 0x60, 0x20, 0x40, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x03, 0x03, 0x03, 0x03, 0x01, 0x00, 0x00, 0x03, 0x03, 0x00, 0x00, 0x00, 0x01, 0x03, 0x03, 0x03, 0x03, 0x01, 0x00, 0x00, 0x00, 0x01, 0x03, 0x03, 0x03, 0x01, 0x00, 0x00, 0x01, 0x03, 0x03, 0x03, 0x00, 0x00, 0x01, 0x03, 0x03, 0x03, 0x01, 0x80, 0x00, 0x00, 0x00, 0x01, 0x03, 0x03, 0x01, 0x03, 0x03, 0x00, 0x00, 0x01, 0x03, 0x03, 0x03, 0x01, 0x03, 0x02, 0x00, 0x10, 0x1f, 0x1f, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xb8, 0x8c, 0x83, 0x00, 0x00, 0x03, 0x04, 0x00, 0x88, 0x48, 0x08, 0x28, 0x28, 0x08, 0x04, 0x42, 0x41, 0x80, 0x00, 0x00, 0xf8, 0x04, 0x02, 0x02, 0x02, 0x02, 0x04, 0x10, 0x20, 0xc0, 0x00, 0x00, 0x00, 0x81, 0x86, 0x88, 0x88, 0x90, 0x13, 0x14, 0x18, 0x30, 0x60, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfc, 0x04, 0x04, 0x04, 0x04, 0x04, 0xfc, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x10, 0x20, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1f, 0x00, 0x00, 0x00, 0x00, 0x40, 0x20, 0x10, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x9f, 0x01, 0x00, 0x00, 0x00, 0x81, 0x22, 0x20, 0x80, 0x8f, 0x70, 0x20, 0x20, 0x20, 0xe0, 0x10, 0x10, 0x10, 0x10, 0x79, 0x92, 0x00, 0x08, 0x11, 0x13, 0xd2, 0x12, 0x10, 0x12, 0xe2, 0x21, 0x00, 0x1e, 0x11, 0xe0, 0x20, 0x10, 0x10, 0x10, 0x00, 0x00, 0x8a, 0x98, 0x70, 0x10, 0x01, 0xe5, 0x06, 0x0c, 0xf0, 0x00, 0x00, 0x00, 0x00, 0xff, 0xf0, 0xf0, 0xf0, 0xf0, 0xf0, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x00, 0x00, 0x00, 0x38, 0x44, 0x82, 0x01, 0xf1, 0x11, 0x01, 0x82, 0x44, 0x38, 0x00, 0x00, 0x00, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3f, 0xd0, 0x21, 0xe1, 0xf1, 0x0c, 0x86, 0x83, 0x09, 0x10, 0x21, 0x22, 0x44, 0x48, 0x08, 0xf0, 0x91, 0x0c, 0x04, 0x04, 0x04, 0x03, 0x02, 0x02, 0x02, 0x83, 0xc3, 0x82, 0x82, 0x03, 0x02, 0x00, 0x04, 0x02, 0x19, 0x78, 0x48, 0x44, 0x44, 0xd2, 0x32, 0x71, 0x71, 0x38, 0x38, 0x1c, 0x12, 0x09, 0x04, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x02, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3f, 0x7f, 0x7f, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x03, 0x44, 0xc4, 0xc5, 0x05, 0x9e, 0x3e, 0xee, 0x27, 0x46, 0xf7, 0xff, 0xf6, 0xf3, 0x08, 0x00, 0x04, 0x7e, 0xff, 0xe7, 0xfe, 0xfd, 0x97, 0x83, 0x83, 0xfe, 0xfc, 0xff, 0xfb, 0xff, 0x03, 0x01, 0x01, 0x07, 0x1f, 0x32, 0x8c, 0x06, 0xfe, 0x27, 0x03, 0x68, 0x1c, 0xcc, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x84, 0xfe, 0x80, 0x00, 0x84, 0xc2, 0xa2, 0x92, 0x8c, 0x00, 0x6c, 0x92, 0x92, 0x92, 0x6c, 0x00, 0x88, 0x50, 0x20, 0x50, 0x88, 0x00, 0x78, 0x94, 0x92, 0x92, 0x60, 0x00, 0x30, 0x28, 0x24, 0xfe, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x47, 0x5e, 0x24, 0xc8, 0x89, 0x9e, 0x38, 0x01, 0xc7, 0x2e, 0x60, 0xe1, 0xe7, 0x3c, 0x07, 0x00, 0xc0, 0xf0, 0xb8, 0xfc, 0xfc, 0x0c, 0x0d, 0xfd, 0xf9, 0xe1, 0x81, 0x81, 0x7c, 0x2c, 0x46, 0x46, 0x76, 0x7c, 0x78, 0x80, 0x80, 0x00, 0x0f, 0xe0, 0x40, 0xdf, 0x0e, 0x00, 0x33, 0x1c, 0xc4, 0x74, 0x3a, 0x0e, 0x86, 0xc2, 0xc2, 0x80, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x60, 0xf0, 0xf8, 0x60, 0x60, 0x00, 0x80, 0xc0, 0x60, 0x60, 0x60, 0xc0, 0x80, 0x00, 0x00, 0x80, 0xc0, 0x60, 0x60, 0xe0, 0xc0, 0x00, 0x00, 0xf8, 0xf8, 0xc0, 0x60, 0x60, 0xe0, 0xc0, 0x00, 0x00, 0xc0, 0xe0, 0x60, 0x60, 0x60, 0x40, 0x00, 0x60, 0xf0, 0xf8, 0x60, 0x60, 0x00, 0x80, 0xc0, 0x60, 0x60, 0x60, 0xc0, 0x80, 0x00, 0x00, 0xe0, 0xe0, 0xc0, 0x60, 0xe0, 0xc0, 0x80, 0x00, 0x02, 0x03, 0x01, 0x01, 0x7f, 0xdd, 0xed, 0x6d, 0x67, 0xe7, 0x67, 0x93, 0x0e, 0x7f, 0x80, 0x00, 0x00, 0x80, 0x9f, 0xff, 0xcd, 0xc3, 0xff, 0x60, 0xf0, 0xff, 0xd7, 0xff, 0xf8, 0x81, 0xc3, 0x61, 0x64, 0x65, 0xad, 0x2d, 0x6f, 0xc5, 0x80, 0x60, 0x18, 0x8f, 0xbe, 0x7d, 0x4c, 0x4e, 0x4f, 0x4f, 0xd9, 0xf1, 0x3e, 0x01, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x1f, 0x18, 0x18, 0x00, 0x07, 0x0f, 0x1b, 0x1b, 0x1b, 0x1b, 0x0b, 0x00, 0x00, 0x07, 0x0f, 0x18, 0x18, 0x1c, 0x0c, 0x00, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x09, 0x1b, 0x1b, 0x1b, 0x1f, 0x0e, 0x00, 0x00, 0x0f, 0x1f, 0x18, 0x18, 0x00, 0x07, 0x0f, 0x1b, 0x1b, 0x1b, 0x1b, 0x0b, 0x00, 0x00, 0xff, 0xff, 0x0c, 0x18, 0x1c, 0x0f, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x16, 0x22, 0x22, 0x02, 0x41, 0x61, 0x61, 0x24, 0x85, 0xf3, 0x9b, 0xa0, 0x81, 0x82, 0x9b, 0x8d, 0x84, 0xb4, 0xd4, 0x80, 0x88, 0xb0, 0xb3, 0xb2, 0x88, 0x1d, 0x0c, 0x4c, 0x54, 0x44, 0x45, 0x47, 0x40, 0x42, 0x42, 0x03, 0x22, 0x24, 0x24, 0x13, 0x16, 0x0e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; #define LCD_C LOW #define LCD_D HIGH #define LCD_X 128 #define LCD_Y 64 #define LCD_CMD 0 int a = 0; void DisplayGraphic1(); void Initial_Lcd(); void clear_screen(); void LcdWrite(byte dc, byte data); void setup() { Initial_Lcd(); clear_screen(); } void loop() { delay(10); DisplayGraphic1(); //display a picture of 128*64 dots while(1){;} } void Initial_Lcd() { pinMode(csPIN, OUTPUT); pinMode(rstPIN, OUTPUT); pinMode(rsPIN, OUTPUT); pinMode(sdaPIN, OUTPUT); pinMode(sckPIN, OUTPUT); digitalWrite(rstPIN, LOW); delay(50); digitalWrite(rstPIN, HIGH); delay(50); LcdWrite(LCD_CMD, 0xe2); // Soft Reset LcdWrite(LCD_CMD, 0x2c); // Boost 1 LcdWrite(LCD_CMD, 0x2e); // Boost 2 LcdWrite(LCD_CMD, 0x2f); // Boost 3 LcdWrite(LCD_CMD, 0x23); // Coarse Contrast, setting range is from 20 to 27 LcdWrite(LCD_CMD, 0x81); // Trim Contrast LcdWrite(LCD_CMD, 0x28); // Trim Contrast value range can be set from 0 to 63 LcdWrite(LCD_CMD, 0xa2); // 1/9 bias ratio LcdWrite(LCD_CMD, 0xc8); // Line scan sequence : from top to bottom LcdWrite(LCD_CMD, 0xa0); // Column scanning order : from left to right LcdWrite(LCD_CMD, 0xaf); // Open the display } //===============clear matrix============= void clear_screen() { unsigned int i,j; for(i=0;i<8;i++) { digitalWrite(csPIN, LOW); LcdWrite(LCD_CMD, 0xb0+i); LcdWrite(LCD_CMD, 0x10); LcdWrite(LCD_CMD, 0x00); for(j=0;j<132;j++) { LcdWrite(LCD_D, 0x00); } } } //==================display 128*64 picture================ void DisplayGraphic1() { unsigned char *address; //pointer int i,j; address=graphic1; //data pointer:point to "graphic[]",one-dimension array for(i=0;i<8;i++) { digitalWrite(csPIN, LOW); LcdWrite(LCD_CMD, 0xb0+i); LcdWrite(LCD_CMD, 0x10); LcdWrite(LCD_CMD, 0x00); for(j=0;j<128;j++) { LcdWrite(LCD_D, *address); address++; } } } void LcdWrite(byte dc, byte data) { digitalWrite(rsPIN, dc); digitalWrite(csPIN, LOW); shiftOut(sdaPIN, sckPIN, MSBFIRST, data); digitalWrite(csPIN, HIGH); }Правда, здесь понятие верха и низа противоположно библиотеке u8g, но зато достаточно экономично по памяти:
А вот это не такой (только дешевле)? Получается много внешне одинаковых, а чипы разные? Пиксель имеет не квадратную форму? По картинке явно пропорции не 2:1. Графика будет искажаться? Просто тоже за кампанию захотелось :-)
https://aliexpress.ru/item/32828243113.html?spm=a2g0o.detail.1000060.1.4...
Коллеги! Я, как обычно, интересуюсь выбором платформы: а почему Уно, а не Мега или Дуе илиСТМ32?
Воображение рисует постапокалиптическую картину: Ковид доедает остатки цивилизации, в борьбе за последнюю коробку Спутника 5 применено ЯО. Под мрачными тучами ядерной зимы, в окружении зомби (осложнения от прививок ;)) ) замерзают последние люди. Осталась одна Ардуина Уно, и только она справится с задачей управления реактором!!! Дисплей тоже только ....вот этот вот... остался.
Как страшно жить!
----------------
Смысл моего юмористического выступления в том, что на форуме моден странный спорт: "а давайте засунем слона в холодильник" ...в переносной. Либо и правда спорт, либо ложные представления об экономии средств и/или места.
К стыду хочу признать, что вынашиваю планы на про мини 168 :-(
А так в поделках игрушечных проще мне экран смартфона с картинками использовать - "иньтерфейс управления и мониторинга". Хочешь кнопки, хочешь шкалы...
Коллеги! Я, как обычно, интересуюсь выбором платформы: а почему Уно, а не Мега или Дуе илиСТМ32?
А в чем проблема то?
IMHO: Uno + монохром_128*64 + Тетрис - вполне себе сбалансированная конструкция.
Коллеги! Я, как обычно, интересуюсь выбором платформы: а почему Уно, а не Мега или Дуе илиСТМ32?
А в чем проблема то?
IMHO: Uno + монохром_128*64 + Тетрис - вполне себе сбалансированная конструкция.
Да. Не спорю.
Я не против спорта, но не для достижения реального результата. Если это не тиражируемое, а единичное изделие, то на фоне времени разработки стоимость контроллера равна нолю, так почему не взять побольше.
Если можно 3 вольта - СТМ32, если нужна связь - ЕСП32, если нужны 5В - Мега. А Уно/нано - для совсем мелочей. Ну а Тиньки - это святое, это уже только для души! ;))) (ну или если нужно 8 ног)
Сейчас взял U8G2_ST7565_JLX12864_F_4W_HW_SPI (самое близкое к тому, что в теме), подключил - Hello World! работает.
У меня все-таки другой конструктор. А дисплей-то мой дешевле. И покрасивше на вид.
Тоже из ОЗУ осталось 600 байт.