Welche Einstellungen braucht ein SSD1306-OLED?
Spalten je Page · LSB zuerst Spalten je Page, LSB zuerst, leuchtendes Pixel = 1 – wenn Sie die Bytes direkt in den Displayspeicher schreiben.
LCD- & OLED-Font-Generator (Bitmap in C-Array)
Text und Bilder in C-Arrays für SSD1306, SH1106, ST7920 und Adafruit GFX umwandeln. Scharfe 12×12- und 16×16-Pixelfonts, alle vier Scanmodi von PCtoLCD2002 und ein Decoder für unbekannte Arrays.
Kein Tracking Läuft im Browser Kostenlos
Alles läuft in Ihrem Browser – Text und Bilder verlassen dieses Gerät nie.
Systemschriften sind geglättete Konturen, unter etwa 20 px brechen Striche ab oder laufen zusammen. Für 12 und 16 px nehmen Sie die Pixelfonts oben.
Bild hierher ziehen oder klicken zum Auswählen
PNG, JPG, GIF, BMP, WebP oder SVG – ein Logo, Icon oder Screenshot
Dunkle Pixel des Bildes werden zu leuchtenden Pixeln auf dem Display. Transparente Flächen zählen als Hintergrund.
Ein Font-Array aus einem alten Projekt oder Tutorial, und Sie wissen nicht, wie es erzeugt wurde? Fügen Sie es hier ein: Jede Scanrichtung und Bitreihenfolge wird nebeneinander gezeichnet, und die lesbare verrät die Einstellungen.
Passt zum Page-Speicher von SSD1306 / SSD1309 / SH1106 / ST7565 und zu MicroPython framebuf.MONO_VLSB – die Bytes direkt ans Display schreiben.
Vorschau
Klicken Sie auf ein Pixel, um es umzuschalten. 5 Glyphe(n) · 80 Bytes
Referenz: das Zeichen 中 (16 × 16) in jeder Scanrichtung
Leuchtendes Pixel = 1, Glyphe aus GNU Unifont. Vergleichen Sie diese Bytes mit Ihrem eigenen Array, um zu erkennen, mit welchen Einstellungen es erzeugt wurde.
| Scanrichtung | Bitreihenfolge | Bytes (hex) |
|---|---|---|
| Zeilenweise (horizontale Bytes) | MSB zuerst — erstes Pixel in Bit 7 | 01 00 01 00 01 00 01 00 3F F8 21 08 21 08 21 08 21 08 21 08 3F F8 21 08 01 00 01 00 01 00 01 00 |
| Zeilenweise (horizontale Bytes) | LSB zuerst — erstes Pixel in Bit 0 | 80 00 80 00 80 00 80 00 FC 1F 84 10 84 10 84 10 84 10 84 10 FC 1F 84 10 80 00 80 00 80 00 80 00 |
| Spaltenweise (vertikale Bytes) | MSB zuerst — erstes Pixel in Bit 7 | 00 00 00 00 0F F0 08 20 08 20 08 20 08 20 FF FF 08 20 08 20 08 20 08 20 0F F0 00 00 00 00 00 00 |
| Spaltenweise (vertikale Bytes) | LSB zuerst — erstes Pixel in Bit 0 | 00 00 00 00 F0 0F 10 04 10 04 10 04 10 04 FF FF 10 04 10 04 10 04 10 04 F0 0F 00 00 00 00 00 00 |
| Spalten je Page (vertikale Bytes, SSD1306-Page-Reihenfolge) | MSB zuerst — erstes Pixel in Bit 7 | 00 00 0F 08 08 08 08 FF 08 08 08 08 0F 00 00 00 00 00 F0 20 20 20 20 FF 20 20 20 20 F0 00 00 00 |
| Spalten je Page (vertikale Bytes, SSD1306-Page-Reihenfolge) | LSB zuerst — erstes Pixel in Bit 0 | 00 00 F0 10 10 10 10 FF 10 10 10 10 F0 00 00 00 00 00 0F 04 04 04 04 FF 04 04 04 04 0F 00 00 00 |
| Zeilen je Streifen (horizontale Bytes, 8-Pixel-Streifen) | MSB zuerst — erstes Pixel in Bit 7 | 01 01 01 01 3F 21 21 21 21 21 3F 21 01 01 01 01 00 00 00 00 F8 08 08 08 08 08 F8 08 00 00 00 00 |
| Zeilen je Streifen (horizontale Bytes, 8-Pixel-Streifen) | LSB zuerst — erstes Pixel in Bit 0 | 80 80 80 80 FC 84 84 84 84 84 FC 84 80 80 80 80 00 00 00 00 1F 10 10 10 10 10 1F 10 00 00 00 00 |
Pixelfonts: GNU Unifont (16 px) und Fusion Pixel Font (12 px), beide unter der SIL Open Font License 1.1. Lizenztexte
Alle acht Kombinationen aus Scanrichtung und Bitreihenfolge werden Byte für Byte gegen eine unabhängige Referenzimplementierung geprüft, die Voreinstellungen gegen die Datenblätter von SSD1306, SH1106 und ST7565 sowie den Quellcode von Adafruit GFX, U8g2, LVGL und MicroPython. — Go Tools Team · Oct 3, 2026
Vom Engineering-Team von Go Tools gebaut und verifiziert.
Schnelle Antworten
Welche Einstellungen braucht Adafruit GFX drawBitmap()?
Zeilenweise · MSB zuerst Zeilenweise, MSB zuerst, leuchtendes Pixel = 1, jede Zeile auf ganze Bytes aufgefüllt.
Wie viele Bytes hat ein 16 × 16-Zeichen?
32 Bytes 32 Bytes in jeder Scanrichtung. 12 × 12 sind 24 Bytes, ein 8 × 16-ASCII-Zeichen 16.
Was bedeuten 顺向 und 逆向 in PCtoLCD2002?
逆向 = LSB zuerst 顺向 = MSB zuerst (erstes Pixel in Bit 7); 逆向 = LSB zuerst (erstes Pixel in Bit 0).
Was ist eine Font-Bitmap (取模)?
Die meisten grafischen OLED- und LCD-Controller – darunter SSD1306, SH1106 und ST7565 – haben keine eingebaute Schriftart. Um ein Zeichen anzuzeigen, kopiert die Firmware ein kleines Raster aus Pixeln (an/aus) in den Displayspeicher: ein Bit pro Pixel, acht Pixel pro Byte. Das Umwandeln einer Glyphe in diese Bytes heißt in chinesischen Embedded-Tutorials 取模 – genau die Aufgabe, die das Windows-Programm PCtoLCD2002 seit Jahren erledigt.
Die Bytes allein reichen aber nicht. Dasselbe 16 × 16-Zeichen lässt sich auf vier Arten packen (zeilenweise, spaltenweise, Spalten je Page, Zeilen je Streifen), und jede Art kann das erste Pixel in Bit 7 oder Bit 0 legen. Acht Bytefolgen beschreiben dieselbe Glyphe, und ein Display zeichnet nur eine davon korrekt. Deshalb erscheint ein aus einem Tutorial kopierter Font so oft gespiegelt, halbiert oder gedreht.
// 中 (16x16), pages of columns, LSB first, lit = 1 — SSD1306 page order
const unsigned char zhong[32] = {
0x00,0x00,0xF0,0x10,0x10,0x10,0x10,0xFF,0x10,0x10,0x10,0x10,0xF0,0x00,0x00,0x00,
0x00,0x00,0x0F,0x04,0x04,0x04,0x04,0xFF,0x04,0x04,0x04,0x04,0x0F,0x00,0x00,0x00
};
// First 16 bytes = page 0 (rows 0-7), one byte per column, bit 0 = top row Was dieser Generator leistet
Pixelgenaues Chinesisch in 12 × 12 und 16 × 16
Browserschriften sind geglättete Konturen; bei 12 px in einer Song-Schrift per Schwellwert binarisiert, verschwinden die waagerechten Striche von 中 einfach. Dieses Tool bringt deshalb echte Bitmap-Fonts mit: Der 16 × 16-Font deckt alle 6.763 GB2312-Zeichen ab, dem 12 × 12-Font fehlen 143 seltene Zeichen – sie werden mit einer Systemschrift gezeichnet und markiert.
Alle vier Scanmodi von PCtoLCD2002, beide Bitreihenfolgen
Zeilenweise, spaltenweise, Spalten je Page und Zeilen je Streifen, jeweils MSB zuerst oder LSB zuerst, leuchtendes Pixel = 1 oder 0. Die Optionsnamen folgen PCtoLCD2002, ihre Bedeutung ist am SSD1306-Datenblatt und an gängigen OLED-Beispielprojekten geprüft – so können Sie dieselben Einstellungen wählen, die ein bestehendes Projekt verwendet.
Voreinstellungen, die sagen, wozu sie passen
Wählen Sie SSD1306, Adafruit GFX oder XBM, und die Optionen werden für Sie gesetzt. Ändern Sie eine Option von Hand, zeigt das Tool an, welche Displays und Bibliotheken diese Bytereihenfolge lesen – oder dass es keine gibt.
Vorhandene Arrays entschlüsseln
Fügen Sie ein Font-Array unbekannter Herkunft ein, und alle acht Lesarten aus Scanrichtung und Bitreihenfolge werden nebeneinander gezeichnet. Die lesbare verrät die Einstellungen; ein Klick übernimmt sie.
Bild zu Bitmap mit echtem Dithering
Logos, Icons und Fotos werden auf Ihre Displaygröße skaliert und per Schwellwert, Floyd–Steinberg- oder Atkinson-Dithering umgewandelt. Transparente Flächen zählen als Hintergrund, und der Schwellwert wirkt in jedem Modus.
Ausgabe, die direkt ins Projekt passt
2-D-Arrays im C51-Stil mit /*"中",0*/-Kommentaren, Arduino PROGMEM mit Offsets, MicroPython-bytearray-Dictionaries, A51-DB-Zeilen oder reines Hex. Der erzeugte C-Code kompiliert sauber mit -Wall -Wextra -pedantic.
Durchgerechnete Beispiele
中 für ein SSD1306-OLED (16 × 16, Spalten je Page, LSB zuerst)
中
00 00 F0 10 10 10 10 FF 10 10 10 10 F0 00 00 00 00 00 0F 04 04 04 04 FF 04 04 04 04 0F 00 00 00
32 Bytes: 16 Spalten von Page 0 (Zeilen 0–7), dann 16 Spalten von Page 1 (Zeilen 8–15). Im 0xFF in Spalte 7 ist jedes Bit gesetzt: Der senkrechte Strich läuft durch alle acht Zeilen beider Pages.
Dasselbe 中 für Adafruit GFX drawBitmap (zeilenweise, MSB zuerst)
中
01 00 01 00 01 00 01 00 3F F8 21 08 21 08 21 08 21 08 21 08 3F F8 21 08 01 00 01 00 01 00 01 00
Zwei Bytes pro Zeile, 16 Zeilen. 0x01 0x00 ist nur der Mittelstrich: Das Pixel ganz links ist Bit 7 des ersten Bytes, also landet das Pixel in Spalte 7 in Bit 0. Schicken Sie diese Bytes per Page-Write an ein SSD1306, kommt Pixelmüll heraus – dieselbe Glyphe, anders gepackt.
Halbbreites A in einem 16-Pixel-Font (8 × 16)
A
00 00 00 00 18 24 24 42 42 7E 42 42 42 42 00 00
ASCII-Zeichen sind halb so breit: 8 × 16 sind 16 Bytes, zeilenweise ein Byte pro Zeile. Haken Sie „Halbbreiten Zeichen (A–Z, 0–9) die volle Zellbreite geben“ an, wenn Ihr Treiber für jede Glyphe 16 × 16 erwartet.
Warum 12 × 12 24 Bytes sind und nicht 18
中 (12 × 12, zeilenweise, MSB zuerst)
00 00 04 00 04 00 FF E0 84 20 84 20 84 20 FF E0 04 00 04 00 04 00 04 00
Jede 12-Pixel-Zeile braucht zwei Bytes; die letzten vier Bits des zweiten Bytes sind Auffüllung. 12 Zeilen × 2 Bytes = 24. Jede Display-Bibliothek adressiert Zeilen als (width + 7) / 8 Bytes, dichter gepackte Bits würden sie also alle aus dem Tritt bringen.
So erzeugen Sie Font-Daten für ein LCD oder OLED
- 1
Text eingeben oder Bild hineinziehen
Text wird mit einem echten Pixelfont gerendert: 12 × 12 (Fusion Pixel) oder 16 × 16 (GNU Unifont), ASCII in halber Breite. Für Logos und Icons wechseln Sie in den Tab „Bild“ und stellen die Zielgröße ein, etwa 128 × 64.
- 2
Zieldisplay oder Bibliothek wählen
SSD1306 / SH1106 / ST7565 brauchen vertikale Bytes in Page-Reihenfolge, das oberste Pixel in Bit 0. Adafruit GFX, TFT_eSPI, U8g2 drawBitmap und LVGL brauchen horizontale Bytes, das linke Pixel in Bit 7. XBM / U8g2 drawXBM ist genauso, nur mit dem linken Pixel in Bit 0.
- 3
Vorschau prüfen, Pixel bei Bedarf korrigieren
Die Vorschau zeigt genau die Bitmap, die kodiert wird. Ein Klick auf ein Pixel schaltet es um; mit den Verschiebefeldern rücken Sie die Glyphe zurecht.
- 4
Kopieren oder herunterladen
Zur Wahl stehen C (PCtoLCD2002-C51-Stil), Arduino PROGMEM, MicroPython bytearray, A51-Assembler oder reines Hex. Die erste Zeile der Ausgabe hält Scanrichtung, Bitreihenfolge und Glyphengröße fest, das Array dokumentiert sich also selbst.
Zeichensalat: Symptom → falsche Einstellung
Jede 8-Pixel-Gruppe ist links-rechts gespiegelt
Horizontale Bytes mit falscher Bitreihenfolge. Adafruit GFX drawBitmap() braucht MSB zuerst; XBM und U8g2 drawXBM() brauchen LSB zuerst.
✗ Falsch
U8g2 drawXBM() mit Bytes „MSB zuerst“ gefüttert
✓ Richtig
drawXBM() → XBM-Voreinstellung (zeilenweise, LSB zuerst)
Je 8 Zeilen stehen auf dem Kopf
Vertikale Bytes mit falscher Bitreihenfolge. Controller vom Typ SSD1306 legen D0 in die oberste Zeile und brauchen daher LSB zuerst.
✗ Falsch
Spalten je Page, MSB zuerst → SSD1306
✓ Richtig
Spalten je Page, LSB zuerst → SSD1306
Obere und untere Hälfte verschachtelt
Spaltenweise und Spalten je Page verwechselt. Beide liefern nur bei Glyphen bis 8 Pixel Höhe dieselben Bytes; bei 16 Pixeln unterscheidet sich die Bytereihenfolge.
✗ Falsch
Spaltenweise → SSD1306-Page-Writes
✓ Richtig
Spalten je Page → SSD1306-Page-Writes
Glyphe an der Diagonale gespiegelt oder invertiert
Eine Spiegelung an der Diagonale heißt: Horizontale Bytes wurden als vertikale gelesen (oder umgekehrt). Dunkle Schrift auf hellem Grund heißt: Leuchtend = 0 wurde gewählt, wo das Display leuchtend = 1 erwartet.
✗ Falsch
Zeilenweise Bytes in eine SSD1306-Page geschrieben
✓ Richtig
Array im Decoder-Tab einfügen und die lesbare Vorschau wählen
Wann Sie das brauchen
- Chinesischer Text auf einem 0,96"-SSD1306-OLED
- Ein Temperaturwert, ein Menü oder eine Statuszeile auf Chinesisch auf einem STM32- oder 51er-Board. Nehmen Sie den 16 × 16-Font mit der SSD1306-Voreinstellung und fügen Sie das Array in die oled_font.h ein, die Ihr Beispielprojekt bereits mitbringt.
- Boot-Logo auf einem Arduino- oder ESP32-Display
- PNG-Logo hineinziehen, 128 × 64 einstellen, die Voreinstellung Adafruit GFX wählen und display.drawBitmap(0, 0, logo, 128, 64, WHITE) aufrufen.
- Icons und Einheiten für eine LVGL- oder U8g2-Oberfläche
- Akku-, WLAN- und °C-Symbole als 1-Bit-Bilder. Für horizontale Bytes mit MSB zuerst die Voreinstellung Adafruit GFX / LVGL, für U8g2 drawXBM() die XBM-Voreinstellung.
- Arbeiten am Mac oder unter Linux
- PCtoLCD2002 und die klassischen 字模提取-Tools sind Windows-Programme. Dieses Tool läuft in jedem aktuellen Browser und braucht keine Installation.
- Ein geerbtes Projekt nachvollziehen
- Der Vorgänger hat ein Hzk[][32]-Array hinterlassen, aber keine Notizen. Fügen Sie es in den Decoder ein, um herauszufinden, wie es erzeugt wurde, bevor Sie neue Zeichen im selben Format ergänzen.
So funktionieren die vier Scanrichtungen
- Zeilenweise (horizontale Bytes)
- Die Zeilen werden von oben nach unten gelesen; innerhalb einer Zeile enthält jedes Byte acht benachbarte Pixel von links nach rechts. Eine 16-Pixel-Zeile sind zwei Bytes. Das ist das Layout von Adafruit GFX drawBitmap(), U8g2 drawBitmap(), XBM-Dateien, ST7920-GDRAM und LVGL-1-Bit-Bildern.
- Spalten je Page (vertikale Bytes) – die SSD1306-Reihenfolge
- Die Glyphe wird in Pages von acht Zeilen Höhe zerlegt. Pro Page werden die Spalten von links nach rechts gelesen, und jedes Byte enthält die acht Pixel dieser Spalte. Das entspricht dem GDDRAM von SSD1306, SH1106 und ST7565, wo laut Datenblatt das Datenbit D0 in die oberste Zeile geschrieben wird – die passende Bitreihenfolge ist also LSB zuerst.
- Spaltenweise und Zeilen je Streifen
- Spaltenweise liest jede Spalte von oben nach unten über alle Pages, bevor es nach rechts weitergeht; das entspricht dem vertikalen Adressierungsmodus des SSD1306. Zeilen je Streifen nimmt einen 8 Pixel breiten Streifen mit all seinen Zeilen, dann den nächsten Streifen; keine verbreitete Bibliothek nutzt das, ältere PCtoLCD2002-Projekte aber schon. Beide sehen ihrem Gegenstück nur dann gleich, wenn die Glyphe höchstens 8 Pixel hoch (bzw. breit) ist – deshalb fällt die Verwechslung bei 8 × 8-Tests nicht auf.
- Bitreihenfolge und Wert eines leuchtenden Pixels
- MSB zuerst legt das zuerst gelesene Pixel (ganz links bzw. ganz oben) in Bit 7, LSB zuerst legt es in Bit 0. PCtoLCD2002 nennt das 顺向 (MSB zuerst) und 逆向 (LSB zuerst). Leuchtend = 1 (阴码) erwarten OLEDs, TFT drawBitmap() und LVGL A1; leuchtend = 0 (阳码) nur Treiber, bei denen 0 „an“ bedeutet.
- Auffüllung, wenn die Größe kein Vielfaches von 8 ist
- Jede Zeile (horizontale Bytes) bzw. jede Page (vertikale Bytes) wird für sich auf ganze Bytes aufgefüllt, Füllbits sind 0. Bei Spalten je Page und einer 12-Pixel-Glyphe trägt die zweite Page 4 Füllzeilen; ein Treiber, der ganze Pages schreibt, löscht diese 4 Zeilen unter der Glyphe. Das Tool warnt, wenn das zutrifft.
Beim ersten Mal richtig
- Voreinstellung nach der Zeichenfunktion wählen, nicht nach dem Display
- Ein SSD1306 an Adafruit_SSD1306 läuft über drawBitmap(), braucht also horizontale Bytes mit MSB zuerst, obwohl der Speicher des Controllers vertikal organisiert ist. Nehmen Sie die Voreinstellung, die zu der Funktion passt, die Ihr Code aufruft.
- Für 12 und 16 px die Pixelfonts nehmen
- Konturschriften unter etwa 20 px verlieren beim Binarisieren Striche. Fusion Pixel 12 und Unifont 16 sind auf das Pixelraster gezeichnet, und die 2×-Optionen liefern saubere 24 × 24 und 32 × 32.
- Den Kopfkommentar behalten
- Die erste Ausgabezeile hält Scanrichtung, Bitreihenfolge und Größe fest. Ein halbes Jahr später ist sie der einzige Beleg dafür, wie das Array entstanden ist.
- Mit einem asymmetrischen Zeichen testen
- Symmetrische Glyphen wie 中, 田 oder H verbergen Spiegelfehler. Probieren Sie zuerst F, 7 oder 乙: Wenn das richtig lesbar ist, stimmt jede Option.
- Spiegelung des ganzen Bildschirms im Treiber beheben
- Ist alles auf dem Bildschirm gespiegelt oder steht auf dem Kopf, nicht nur Ihr Font, ändern Sie Segment-Remap (A0h/A1h) und COM-Scanrichtung (C0h/C8h) in der Init-Sequenz. Font-Einstellungen zu ändern, würde nur anderen Code kaputt machen.
Häufige Fragen
Welche Einstellungen nehme ich für ein SSD1306- oder SH1106-OLED?
Wenn Ihr Code die Font-Bytes direkt ans Display schreibt (die meisten 51er- und STM32-Beispiele): Spalten je Page, LSB zuerst, leuchtend = 1 – die SSD1306-Voreinstellung. Zeichnet er über Adafruit_SSD1306 oder U8g2 drawBitmap(), nehmen Sie stattdessen die Voreinstellung Adafruit GFX, denn diese Funktionen lesen horizontale Bytes mit MSB zuerst und rechnen sie selbst um.
Meine Zeichen erscheinen gespiegelt, kopfüber oder verwürfelt. Was ist falsch?
Jedes Symptom zeigt auf genau eine Einstellung. Je 8 Pixel links-rechts gespiegelt: falsche Bitreihenfolge bei horizontalen Bytes. Je 8 Zeilen kopfüber: falsche Bitreihenfolge bei vertikalen Bytes. Obere und untere Hälfte verschachtelt: spaltenweise und Spalten je Page verwechselt. An der Diagonale gespiegelt: horizontale und vertikale Bytes verwechselt. Invertierte Farben: leuchtend = 1 und leuchtend = 0 vertauscht. Ist der ganze Bildschirm gespiegelt und nicht nur Ihr Text, korrigieren Sie stattdessen die Init-Sequenz des Treibers.
Warum braucht 12 × 12 24 Bytes und nicht 18?
Jede Zeile (bzw. jede Page aus 8 Zeilen) wird für sich auf ganze Bytes aufgefüllt: 12 Pixel brauchen 2 Bytes, und 12 Zeilen × 2 = 24. Display-Bibliotheken adressieren Zeilen als (width + 7) / 8 Bytes, eine dicht gepackte 18-Byte-Glyphe würden also alle falsch lesen.
Warum löscht mein 12-Pixel-Text auf dem OLED die Zeile darunter?
Bei Spalten je Page füllt eine 12-Pixel-Glyphe eine ganze Page und die Hälfte der nächsten; die übrigen 4 Bits der zweiten Page sind Füllnullen. Ein Treiber, der ganze Pages schreibt, löscht diese 4 Zeilen. Zeichnen Sie über einen Framebuffer, der einzelne Pixel setzt, oder platzieren Sie 12-Pixel-Text so, dass die leeren Zeilen dort liegen, wo sonst nichts gezeichnet wird.
Kann ich das auf dem Mac statt PCtoLCD2002 nutzen?
Ja. Es läuft in jedem aktuellen Browser, bietet dieselben vier Scanmodi, beide Bitreihenfolgen und leuchtend = 1 / leuchtend = 0, und die C-Ausgabe folgt dem C51-Stil von PCtoLCD2002 mit /*"字",0*/-Kommentaren – sie lässt sich also in Projekte einfügen, die auf Arrays im Stil von Hzk[][32] aufbauen. Komplette Font-Bibliotheksdateien oder Indizes erzeugt es nicht. Die Glyphenformen stammen aus GNU Unifont und Fusion Pixel statt aus SimSun von Windows, daher stimmen die Bytes nicht Zeichen für Zeichen mit einem von PCtoLCD2002 erzeugten Array überein – erzeugen Sie die ganze Tabelle hier neu, statt beides zu mischen. Diese Website steht in keiner Verbindung zu PCtoLCD2002 oder seinem Autor, ist keine offizielle Webversion und bietet das Programm nicht zum Download an.
Warum ein Pixelfont statt meiner Systemschrift?
Systemschriften sind Konturen mit Kantenglättung, die ein Browser nicht abschalten kann. Bei 12 oder 16 Pixeln gehen beim Binarisieren dieser grauen Kanten dünne Striche verloren – die waagerechten Balken von 中 verschwinden in einer 12-Pixel-Song-Schrift komplett. GNU Unifont (16 px) und Fusion Pixel (12 px) sind auf dem Pixelraster entworfen, es geht also nichts verloren. Für größere Schriftgrößen stehen die Systemschriften weiterhin zur Verfügung: Eine serifenlose Schrift (Hei) hält ab etwa 24 px, während Song-Schriften dort noch Striche verlieren können.
Welche Zeichen decken die Pixelfonts ab?
Ganz GB2312 – 6.763 vereinfachte chinesische Schriftzeichen plus Interpunktion in voller Breite – sowie druckbares ASCII, lateinische Buchstaben mit diakritischen Zeichen (é, ß, ł, ş, ő), Griechisch, Kyrillisch, japanische Kana und gängige Symbole wie ℃, Pfeile und Rahmenzeichen. Fusion Pixel 12 px fehlen einige seltene Zeichen und Symbole. Koreanisches Hangul und chinesische Schriftzeichen außerhalb von GB2312 (Langzeichen, viele japanische Kanji) werden stattdessen mit einer Systemschrift gezeichnet und unter der Vorschau aufgelistet, damit Sie sehen, welche Glyphen Sie prüfen sollten.
Wie wandle ich ein Logo oder Icon in ein C-Array um?
Öffnen Sie den Tab „Bild“, ziehen Sie die Datei hinein, stellen Sie die Displaygröße ein (128 × 64 für ein 0,96"-OLED) und lassen Sie „Einpassen, Proportionen beibehalten“ aktiv. Dunkle Pixel werden zu leuchtenden Pixeln; für helle Motive auf dunklem Grund haken Sie Invertieren an. Für Logos und Text kein Dithering, für Fotos Floyd–Steinberg oder Atkinson.
Wie finde ich heraus, wie ein vorhandenes Font-Array erzeugt wurde?
Fügen Sie es im Tab „Vorhandenes Array ansehen“ ein. Kommentare werden ignoriert, C-, Arduino-, A51- und MicroPython-Syntax werden akzeptiert. Die Glyphengröße wird aus der Byteanzahl geschätzt, und alle acht Kombinationen aus Scanrichtung und Bitreihenfolge werden gezeichnet. Die richtig lesbare ist Ihre Einstellung, und „Diese Einstellungen übernehmen“ überträgt sie in den Generator.
Werden mein Text oder mein Bild hochgeladen?
Nein. Glyphen werden in Ihrem Browser gerendert und kodiert. Die Pixelfonts werden einmal von dieser Website geladen, und nichts, was Sie eingeben oder hineinziehen, wird irgendwohin gesendet.
Verwandte Werkzeuge
Alle Werkzeuge anzeigen →Zahlensystem-Konverter — Binär, Hex, Dezimal & Oktal
Konvertierungswerkzeuge
Zahlen zwischen Binär, Hexadezimal, Dezimal, Oktal und beliebigen Basen (2–36) sofort konvertieren. Kostenlos, privat, ohne Anmeldung — alles läuft in Ihrem Browser.
Rechner für Zweierkomplement und Vorzeichenzahlen
Konvertierungswerkzeuge
Ganzzahl mit Vorzeichen eingeben und Betrag-Vorzeichen, Einerkomplement, Zweierkomplement und Offset-Binär auf einmal erhalten, von 4 bis 64 Bit. Oder ein Bitmuster bzw. Hex-Byte einfügen und alle fünf Lesarten sehen.
chmod Rechner — Linux Dateiberechtigungen
Konvertierungswerkzeuge
Linux-Dateiberechtigungen zwischen Oktal (755, 644) und rwx-Symbolen umrechnen. chmod-Befehle kopieren, riskante Modi wie 777 erkennen — kostenlos, direkt im Browser.
Farbkonverter — HEX, RGB, HSL & OKLCH
Konvertierungswerkzeuge
Konvertieren Sie HEX zu RGB, HSL, OKLCH, OKLAB und CMYK direkt im Browser — jedes Format mit einem Klick kopieren. Kostenlos, ohne Anmeldung, Ihre Farben verlassen die Seite nie.
Koordinatenumrechner: Grad Minuten Sekunden, UTM, GCJ-02
Konvertierungswerkzeuge
Koordinaten in jedem Format umrechnen — Dezimalgrad, Grad Minuten Sekunden, Dezimalminuten — in UTM, Web Mercator, GCJ-02 (AMap) und BD-09 (Baidu). Erkennt lat,lng vs. lng,lat, Stapel als CSV. Läuft im Browser.
HEX-zu-CMYK-Konverter
Konvertierungswerkzeuge
Konvertieren Sie HEX-Farben direkt im Browser in CMYK. Naive sRGB-basierte Näherung für Druckvorschauen. Kostenlos, ohne Anmeldung, Ihre Farben bleiben lokal.