U8g2 drawXBMP: napraw problemy z bitmapami SSD1306

Przekonwertowana bitmapa może kompilować się bez błędów, a mimo to pojawiać się błędnie na SSD1306: pusta, odbita wewnątrz każdej grupy ośmiu pikseli, przesunięta nieco dalej w każdym wierszu albo powtarzająca się na ekranie. Zwykłą reakcją jest ponowne przepuszczenie obrazu przez konwerter z innymi ustawieniami. Rzadko to pomaga, ponieważ bajty rzadko są jedynym problemem.

Sama tablica bajtów nie mówi, jak szeroki jest obraz, który bit jest pikselem najbardziej z lewej, jak każdy wiersz jest dopełniany ani jak konstruktor twojego wyświetlacza oczekuje narysowania obrazu. Pomyl jedną z tych rzeczy, a te same wyglądające poprawnie dane zamienią się w pochylony lub pomieszany obraz. Poniższe sprawdzenia rozdzielają te przyczyny w kolejności: najpierw udowodnij ścieżkę rysowania firmware za pomocą bitmapy, której poprawny wynik znasz na pamięć, a następnie porównaj z nią własny obraz.

W przypadku bitmapy XBM w pamięci programu użyj u8g2.drawXBMP(x, y, width, height, bits). Szerokość i wysokość to wymiary w pikselach. Jeśli przekonwertowany obraz SSD1306 jest pusty, odbity lub przesunięty, sprawdź jego format i pętlę rysowania przed ponowną konwersją.

Bitmapa akceptowana przez U8g2 niekoniecznie ma układ natywnego bufora kontrolera SSD1306. Kopiowanie bajtów między tymi reprezentacjami bez konwersji może dać wzór, który wygląda prawie dobrze.

Przetestuj małą asymetryczną bitmapą

Ten przykład 8 × 8 jest celowo nierówny. Pomaga odróżnić poprawnie zorientowany obraz od odbitego:

static const unsigned char corner_bits[] U8X8_PROGMEM = {
    0x01, 0x03, 0x07, 0x0F,
    0x01, 0x01, 0x01, 0x00
};

void drawBitmapTest() {
    u8g2.setDrawColor(1);
    u8g2.drawXBMP(0, 0, 8, 8, corner_bits);
}

Dodaj go do szkicu z działającym obiektem wyświetlacza u8g2. W danych wierszy XBM niski bit reprezentuje piksel najbardziej z lewej w każdym bajcie. Pierwszy wiersz powyżej zapala swój piksel najbardziej z lewej; czwarty zapala cztery piksele od lewej. Implementacja bitmap U8g2 pokazuje, jak te bity są odczytywane.

Wzór testowy, 8 × 8: schody rosnące od lewego górnego rogu, a następnie pojedyncza kolumna. Jeśli twoje rosną od prawej, kolejność bitów nie pasuje. Pobierz pasujący plik XBM.

Jeśli ten test działa, ale twoje logo nie, zachowaj konfigurację wyświetlacza i sprawdź dane logo.

Użyj pętli rysowania pasującej do twojego konstruktora

Konstruktor z pełnym buforem zawiera _F_. Rysuj do tego bufora, a następnie go wyślij:

u8g2.clearBuffer();
drawBitmapTest();
u8g2.sendBuffer();

W przypadku konstruktora z buforem stron, na przykład zawierającego _1_, powtarzaj funkcję rysowania wewnątrz pętli obrazu:

u8g2.firstPage();
do {
    drawBitmapTest();
} while (u8g2.nextPage());

Użyj trybu wybranego przez twój istniejący konstruktor. Dokumentacja konfiguracji U8g2 wyjaśnia nazewnictwo i wybór bufora. Jeśli konfigurujesz wyświetlacz po raz pierwszy, skorzystaj z przewodnika po integracji U8g2 w Lopaka i zachowaj konstruktor specyficzny dla kontrolera z działającego przykładu.

Dopasuj szerokość, wysokość i dopełnienie wierszy

Wiersz XBM zajmuje całkowitą liczbę bajtów. Przy szerokości 13 pikseli każdy wiersz używa dwóch bajtów, z trzema nieużywanymi bitami na końcu. Obraz o ośmiu wierszach potrzebuje więc 16 bajtów.

bytes per row = (width + 7) / 8, using integer division
total bytes = bytes per row * height

Jeśli podasz 16 jako szerokość, ponieważ wiersz ma dwa bajty, API narysuje 16 pikseli. Zamiast tego podaj oryginalną szerokość w pikselach. Jeśli zmienisz szerokość bez ponownego upakowania danych, wiersze mogą zaczynać się w niewłaściwych miejscach.

Starszy interfejs drawBitmap() używa liczby bajtów jako rozmiaru poziomego, podczas gdy drawXBM() i drawXBMP() używają pikseli. Dokumentacja rysowania U8g2 opisuje tę różnicę i zaleca funkcje XBM.

Odczytaj objaw przed zmianą ustawień

Objaw	Sprawdzenie
Tekst i obraz testowy są puste	Konstruktor, inicjalizacja, okablowanie i adres wyświetlacza
Obraz testowy działa; niestandardowy obraz jest pusty	Zawartość tablicy, wymiary, kolor rysowania i współrzędne
Piksele odwracają się wewnątrz każdej grupy ośmiu	Kolejność bitów źródła a kolejność bitów XBM
Wiersze przesuwają się lub powtarzają	Dopełnienie wierszy i szerokość przekazana do funkcji
Poprawny obraz, błędne zachowanie pierwszego planu i tła	Tryb bitmapy, kolor rysowania i sposób czyszczenia tła

Przenosząc ikonę, narysuj ponownie także objęte tło. W przeciwnym razie zapalone piksele z poprzedniej pozycji mogą pozostać. Zdecyduj, czy aplikacja czyści cały bufor, czy przemalowuje tylko region, który się zmienił.

Eksportuj bitmapę wraz z wywołaniem rysowania

W przypadku nowego logo przewodnik po konwerterze obrazów U8g2 opisuje przygotowanie w Lopaka. Przenosząc wynik do firmware, trzymaj razem wygenerowaną szerokość, wysokość, tablicę i wywołanie rysowania.

Projekt ekranu nadal pozostawia konstruktor wyświetlacza i konfigurację magistrali twojemu projektowi. Moduły SSD1306 i SH1106 mogą mieć tę samą rozdzielczość, a mimo to potrzebować innej konfiguracji kontrolera. Podgląd wizualny nie może zweryfikować okablowania ani adresu I2C.

Częste pytania

Czy drawXBMP rysuje automatycznie cały ekran?

Rysuje wymiary przekazane do niego w wybranych współrzędnych. Małe logo pozostaje małym logo; umieść je jawnie albo przygotuj bitmapę na cały ekran.

Czy mogę wkleić bajty pliku PNG do tablicy?

Nie. Funkcja oczekuje upakowanych pikseli monochromatycznych, a nie skompresowanego pliku PNG. Najpierw przekonwertuj obraz.

Jak sprawdzić układ przed ponownym wgrywaniem?

Użyj małej asymetrycznej bitmapy, aby zweryfikować ścieżkę firmware, a następnie sprawdź prawdziwy zasób w Lopaka. Daje ci to znaną działającą referencję podczas dopasowywania logo.