ATmega8 + OLED SSD1306

[COKPOWEHEU]

[uquote="shonty",url="/forum/viewtopic.php?p=4674162#p4674162"]Для "растворения"/"проявления" в идеале подошёл бы генератор случайных чисел, но это затратно для меги [/uquote]
Да не особо. Вот, например демо-код для ПК и "экранчиком" 64х8 (в консоли, разумеется):

Код: Выделить всё

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <stdlib.h>

char disp[64][8]; //512

void disp_show(){
  printf("\033[1H\n");
  for(int j=0; j<8; j++){
    for(int i=0; i<64; i++)printf("%c", disp[i][j]);
    printf("\n");
  }
}

void disp_init(){
  for(int i=0; i<64; i++)
    for(int j=0; j<8; j++)disp[i][j] = '#';
}

void disp_anim(){
  static uint64_t cur = 0;
  cur = (cur * 34781 + 33937) % 512;
  ((char*)disp)[cur % 512] = ' ';
}

int main(){
  disp_init();
  disp_show();
  for(int i=0; i<512; i++){
    usleep(1000);
    disp_anim();
    disp_show();
  }
}

Получился эффект рандомного закрашивания (взято отсюда: https://habr.com/ru/articles/549554/#comment_22862364)

[Just_Fluffy]

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

Я, наверное, как то непонятно обьясняю.
Что бы изменить один пиксель в блоке из восьми - нужно знать состояние остальных семи.
Тут есть два варианта - если алгоритм позволяет - то заново формировать по исходным данным все 8 пикселей, потом один менять, потом отправлять этот байт в дисплей.
И второй вариант - держать отдельно в памяти значение этих 8 пикселей. что б потом один поменять и вывести заново на дисплей.
Простой пример.
У вас есть нарисованный отрезок (черный на изображении).
И вам нужно нарисовать второй отрезок (на изображении показан красным).

И в определенной области (подкрашена цветом) вам нужно скомбинировать две линии.
И вот для того, что бы скомбинировать две линии, нужно либо читать из дисплея значение 8 пикселей, либо где то помнить состояние этих пикселей.
Либо при рисовании второй линии путем математики вычислять, а нет ли тут еще и первой линии - и если есть, то комбинировать их.

Опять же, если у вас простой вывод на дисплей, привязанный к 8-пиксельным областям, да нет задачи вывода производьной графики, то можно оптимизировать. А если стоит задача произвольной графики - то тут уже без хоть какого то буфера сложно будет.

Попиксельно это вроде caset/raset/ramwrite + цвет пикселя.

raset - байт, начальная координата - 2 байта, конечную можно не отправлять, сaset - байт, начальная координата - 2 байта, конечную можно не отправлять, ramwrite - байт, цвет пикселя - 2 байта. Итого 1+2+1+2+1+2 = 9 байт. 72 бита. Если вы сможете 1 пиксель зажечь быстрее - покажите.
Для ILI9341-подобных дисплеев raset/caset позволяют не задавать вторую координату. Но некоторые контроллеры требуют обе. Тогда еще +32 бита.

Теперь мне понятно, почему вам с этими дисплеями работать грустно, а мне весело

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