Hallo,

übrigens die 256 Farben der GDP sind NICHT im RGB332 mode, sondern die 256 Farben ANSI Palette, wobei die ersten 16 Farben davon abweichen um mit der GDP-FPGA (V1) kompatibel zu sein. Farben siehe https://github.com/avg67/nkc/blob/main/tang_nano_20k/gdp_256_color_clut.xlsm
Man kann allerdings die CLUT so umprogrammieren dass die Farben (0-255) den RGB332 Farben entspricht (Backup und Restore der CLUT nicht vergessen, sonst geht danach nichts mehr). CLUT-Routinen siehe https://nkcforum.de/forumdrc/index.php?mode=viewthread&forum_id=2&thread=159&z=3#post44

Man könnte ja in my_disp_flush() die direkte Umsetzung RGB565 -> RGB332 machen und beim Programmstart die CLUT für RGB332 konfigurieren. Könnt einfacher sein als die derzeitige Lösung (die ich nicht ganz verstehe welche Farben die in welche umsetzt).
Dafür könnt ich mir auch vorstellen einen DMA-Controller in den FPGA einzubauen der diese Umsetzung in HW kann. Das würde sicherlich 1000% schneller sein als die derzeitige SW-Lösung (Daumen mal Pi abgeschätzt ca. 30ms für 512*512 Pixels)

#include <stdint.h>

uint8_t rgb565_to_rgb332(uint16_t rgb565) {
// Extract components
uint8_t r = (rgb565 >> 11) & 0x1F; // 5 bits red
uint8_t g = (rgb565 >> 5) & 0x3F; // 6 bits green
uint8_t b = rgb565 & 0x1F; // 5 bits blue

// Downscale bits
uint8_t r3 = r >> 2; // 5 -> 3 bits
uint8_t g3 = g >> 3; // 6 -> 3 bits
uint8_t b2 = b >> 3; // 5 -> 2 bits

// Compose RGB332: (RRR GGG BB)
return (r3 << 5) | (g3 << 2) | b2;
}

Hallo smed

ich habe die lv_color_565_to_gdp.h überarbeitet und einige falsche Zuordnungen korrigiert.
Im Kopf der Datei befindet sich eine kurze Beschreibung, wie ich die Tabelle zusammengebaut habe.

Das Bild unten bildet die 256 GDP-Farben analog zur GDP 24Bit Farbtabelle ab.

Ich habe dir über GitHub einen Pull Request für die Datei von meinem Fork-Repository geschickt.



Gruss
Werner

Hallo Werner,
schaut ja toll aus.
Was meinst du übrigens zu meinem Vorschlag oben?

LG,
Andi

Hallo Andi,

ja mit RGB332 ist die Umsetzung einfacher zu machen, aber wir haben ja immer noch das Problem von 16 Bit auf 8 Bit umzusetzen.
Ich verstehe nicht ganz, wie du in der my_disp_flush() eine direkte Umsetzung machen willst.

Gruss
Werner

Hallo,
In SW wird das einfacher weil du dir eine Tabelle RGB565 -> RGB332 vorberechnen kannst (64kB, was kein Problem ist). Ok, das geht auch mit dem jetzigen Farbsystem.
Richtig schnell wird es erst wenn ich das via DMA oder Bitblit in HW mache. Z.b. die innere Schleife bei my_disp_flush() via DMA der die Umsetzung 16/8bit in HW kann.
Bei einem Bitblit könnte er beide Schleifen in HW. Das wäre dann 1000% schneller. Ich schätze ~30ms für 512x512

Hallo Werner,
probier mal aus dass du dir eine Tabelle zur Umsetzung RGB565 -> NKC 8bit vorberechnest, sodass in der inneren schleife von my_disp_flush nur noch ein Table-Lookup vorkommt. Aktuell ergibt die rgb565_to_nkc() Funktion doch noch erheblich viel code der zwar inline ist aber doch für jedes Pixel ausgeführt wird (shifts und maskierungen etc).
Diese Tabelle ist 65536 Bytes groß was kein Problem sein sollte und kann beim Startup gefüllt werden. Aber ich erwarte dadurch eine erhebliche Geschwindigkeitssteigerung beim Bildaufbau.
LG,
andi

Hallo Andi,

Ok, verstehe. Mit der 65kB Tabelle kann man die 16Bit direkt umsetzen.
Die Variante hatte ich wegen der für meine Begriffe extrem grossen Tabelle am Anfang verworfen.
Aber du hast recht, ist mal einen Versuch wert.
Ich werde das mal testen.
LG
Werner

Hallo,
64kB sind angesichts 1,5MB Speicher beim Tang-Nano SOC eine Kleinigkeit. Du musst die Tabelle zur Laufzeit berechnen. Zur Compilezeit wäre sie wahrscheinlich zu groß.
Ich erwarte dadurch eine signifikante reduzierung (~halbierung) der Zeit für den Bildaufbau.
LG Andi