Arduino.ru

Почти все библиотеки могут выводить в нужное место, и чем затирка пробелом гемморойна вообще не понятно. И как часто меняется информация? Если чаще 50 или 20 раз в секунду - это бред - смысл какой? Все равно человек не успеет увидеть и понять эти изменения.

Вопрос у меня был сначала чисто эргономический - не комфортно наблюдать изменения при кручении энкодера. Может это задержка отработки энкодера, или быстродействия кода и т.п. Это ясно.

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

Программировать сложно, пойду поплачусь на форум.

Согласен. https://www.youtube.com/watch?v=3zP1th08tWg  

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

Для тех кто не пошел методом ТС.  Хотите но экран надо перерисовывать полностью, но 1 не чаще 2 раз в секунду и надо всегда увеличить скорость обмена камень-экран. Это есть основная причина перехода на быстрые камни.  А все потому что тогда код будет проще и не надо искать на форуме бесплатных перебирателей спичек.

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

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

Почему?

скорее "зачем?"

Нет, почему. Меня интересует, как из одного обязательно следует другое.

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

Потому что, если есть функции установки курсора, то несложно и обновлять и только эту область. Предсавьте себе цветной дисплей, с кучей граф картинок и т.п.  Зачем все это трогать? И вообще - тогда давайте забудем про курсор и будем все позиционировать в массиве, а затем зараз его переписывать по пикселям. Я за логику Чебурашки - если это кому то нужно, то это кто-то сделал. 

dim3740 - вы похоже чего-то глобально не понимаете.

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

Что вам еще надо то?

Есть Чебурашки-программисты. Им нужна логика Чебурашки.Всякие курсоры массивы и прочее. Есть логика железа. Вот в железе нет ни массивов и курсоров вообще. И наконец есть современные Чебурашки-программисты с графическим интерфейсом и прочей лабудой. Вот для современных Чебурашек и пишут современные библиотеки и делают железо. Так что не напрягайте остальным мозг и учите логику современных Чебурашек программистов.

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

Вообще теоретический ответ - потому, что Вы всегда очищаете ВЕСЬ дисплей.

Нормальные люди забивают пробелом. Если Вам это геморройно, то пользуйтесь проктозолом.

--------------

Скорее кому должны?

dim3740, если считаете, что должны - напишите. Мир Вам будет благодарен.

Так не получается. Пришлось забивать пробелом, при этом менять цвет шрифта, инвертировать цвет и отслеживать нужное мне "мигание". Геморойно, но решено.

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

Вроде бы спрайты, как таковые, проблему мерцания не решали. А вот две страницы в видеобуфере помогали.

Но, откуда у ардуиновских видеоподсистем такая роскошь...

Вполне себе решали проблему при правильной реализации, а в ардуино два видео буфера конечно роскошь

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

Решали. Спрайты накладывались XOR-ом на фон, потом так же XOR-ом стирались без следа и накладывались в другом месте. Мерцания видно не было, по крайней мере, на Спектруме. 

Тогда пусть живут. Я уже детали реализации за ненадобностью позабыл вовсе.

Та прям таки и нету. У меня - есть. Любую прямоугольную, ну почти любую с учетом того что для этих олед 8 вертикальных пикселей в один байт сунули.

Вызывается дето так.

         uint8_t* buf; 

    //SSD1306::FONT_SIZE_1

    SetScale(64);   

    buf = malloc((128-X)*Pages);
    
    myOLED.InitFrame(X,Page,128-X,Pages, myOLED.FRAME_MODE_BUFER, buf);
    memset(buf, 0, (128-X)*Pages);

    OutStr(0,0,c);
    myOLED.update();
   
    free(buf);

Это правда с точки Х до правой границы экрана, т.к. длинна строки бог весть какая выйдет, шрифт векторный с переменной шириной символа.

Но то моя либа ;) 

Так что принципиальная аппаратная возможность перерисовать область есть. И она очень полезна т.к. позволяет сократить размер буфера и время перерисовки.

 

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

 

Да. Гдето так оно и есть. Это вечный компромиссный вопрос - иметь N специализированных либ для N устройств или одну универсальную для их всех, но не обеспечивающую полный учёт специфики каждого. Я сразу делал только для ssd1306. Даже прилично потестировал ее. Но появился sh1106. С своим неповторимым акцентом. Добавился сразу под условной компиляцией, затем перерос в свою отдельную либу. Тестить доработки для двух железяк стало уже влом, не всегда под рукой оба железа. Но сделал векторные шрифты, которые от экрана в общем мало зависят что лед им, что олед, лишь бы линию умел выводить. Им бы универсальную либу для всех экранов хороше бы, а ее нет. А теперь на подходе уже цветные олед, и крутись как хочеш :)

Специально для этого придумали такие функции как millis() и micros().

Неправда Ваша.

Моя библиотека, например, ( http://arduino.ru/forum/proekty/asoled-kompaktnaya-biblioteka-dlya-oled-displeya-128kh64-s-kirillitsei-utf-8 ) НИКОГДА не требует очистки буфера. Хотя бы потому, что буфер в ней не используется. От слова "совсем".

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

Пока ТС не поменяет OLED_I2C на OLED_SPI , то будет жевать эту ботву долго. I2C очень медленный канал и годится для статичной картинки.  https://ru.aliexpress.com/item/32964854513.html

Как показывает практика, OLED I2C дисплеи могут работать на тех же 2 МГц, что и SPI. Хотя и на стандартизованных 400 кГц вполне можно добиться 20 fps.

Ой qwone, писал бы лучше дальше ООП со своим виденьем без ООП. Ну причем здесь шина. Все это относится как к одной так и к другой, за исключением момента что SPI иногда позволит вычитать из экрана. Таким образом аппаратный буфер контролера можно задействовать для наложения новой инфы поверх старой. i2c позволяет задать весь экран за десятки миллисек, а часть, так вобще быстро;) 

Ну я сталквался с тем что у олед порог где то в 1МГц. А 20фпс разумеется без проблем.

Ну, вообще-то это для I2C на AVR порог как раз около 1 МГц, а на Due у меня экранчик I2C стабильно работал на 2 МГц. Хотя, статистики по экранам у меня, конечно, нет.

На lgt8f328p пробова экран sh1106. Шина i2c ногодрыгом напрямую через регистры, пока контроллер на 16МГц - работает ( на шине это гдето 800-900КГц будет), переключаю на 32МГц перестаёт. А через digitalWrite работает полюбому но шина там понятно в пару раз медленее.

Ну для AVR те самые 800-900 МГц - предел даже на аппаратном I2C: при попытке выставить 1 МГц уже на осциллографе видно, что выдает что-то не то. А вот на Due я подключал к I2C-1 (т.е. ко второму), там устойчиво работало на разных частотах до 2 МГц включительно, но намертво висло (т.е. помогало только отключение питания) при 2.1 МГц.