Ja, das ist Open-Sans-Regular mit 14 und 20 Pixel.
Die ttf-Datei habe ich von https://www.fontsquirrel.com/fonts/list/popular heruntergeladen.
Der LVGL-Fontkonverter erzeugt dann ein c-File mit dem Namen des Fonts.
Die c-Datei kannst du dann ohne Probleme direkt einbinden.
Der Konverter benötigt einen gültigen lvgl-Font als Fallback?? z. Bsp: lv_font_montserrat_14.

LG
Werner

Hallo Werner,
hast du den Source dazu wo eingecheckt. Würd mich interessieren.
Arbeite gerade an der 24-bit CLUT. Damit sind dann 256 Graustufen darstellbar.

LG,
Andi

Hallo Andi,

hier sind die Sourcen.
in der lv_color_565_to_gdp.h ist die Konvertierungstabelle.
Beachte bitte: Das Programm arbeitet mit den 256 Standard-Farben der GDP.

lvgl_565.tgz

LG
Werner

Hallo,
vielen dank.
Ich hab hier ein FPGA-File mit 24-bit CLUT (allerdings aktuell nur mit der neuen CPU, sollte aber keinen Unterschied machen).
https://github.com/avg67/nkc/blob/main/tang_nano_20k/NKC_68k_FAST_PS2_KEYB_PCB.fs

CLUT-Routinen:
static uint32_t clut_backup[256];
static inline __attribute__((always_inline)) void GDP_backup_clut(void)
{
GDP_Clut.color_idx = 0;
for(uint16_t i=0;i<256;i++) {
uint32_t tmp = GDP_Clut.color_h<<24;
tmp|= (GDP_Clut.color_m << 16);
tmp|= (GDP_Clut.color_l);
clut_backup[i] = tmp;
}
}

static inline __attribute__((always_inline)) void GDP_set_clut_grey(void)
{
GDP_Clut.color_idx = 0;
for(uint16_t i=0;i<256;i++) {
GDP_Clut.color_h = i; // R
GDP_Clut.color_m = i; // G
GDP_Clut.color_l = i; // B
}
}

static inline __attribute__((always_inline)) void GDP_restore_clut(void )
{
GDP_Clut.color_idx = 0;
for(uint16_t i=0;i<256;i++) {
const uint32_t tmp = clut_backup[i];
GDP_Clut.color_h = (tmp>>24) & 0xff; // R
GDP_Clut.color_m = (tmp>>16) & 0xff; // G
GDP_Clut.color_l = tmp & 0xff; // B
}
}
Achtung folgendes File muss ebenfalls upgedatet werden: https://github.com/avg67/nkc/blob/main/SW/SysGCC-delta/m68k-elf/m68k-elf/include/sys/gdp9366.h



Hier ist ein Beispiel für die aktualisierte CLUT.

Um Euch mal kurz eine Rückmeldung zu geben: Ich bin echt begeistert.
Dann wird das ja doch noch was mit Farbe am NKC ... super!
Ich verfolge den Thread schon gern, verstehe aber meistens nur Bahnhof
Euch weiterhin ein gutes Gelingen
Schöne Grüße

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Hallo Werner,
ich hab das heute bei mir ausprobiert, aber leider bleibt bei mir der Bildschirm dunkel. Die LVGL-Library hab ich neu compiliert. Ich vermute mal es liegt an lv_conf.h.
Was muss ich denn dort umstellen? Oder hast einen Tipp für mich woran es liegen könnte?

Hallo Andi,

hast du in der lv_conf.h für LV_COLOR_DEPTH 16 eingetragen für RGB565?

Hallo Werner,
ja das hab ich und ich hab auch
#define LV_DRAW_SW_SUPPORT_RGB565 1
gesetzt.
Jetzt seh ich was aber die Farben sind sehr blaustichig (nicht so wie in deinem Bild)
Kannst du mir dein lv_conf.h zusenden?

Hallo Andi,

ok,
#define LV_DRAW_SW_SUPPORT_RGB565 1
muss auch gesetzt werden.

lv_conf_fin55.h

LG Werner

Hallo,

Danke. Nun schaut das Bild auch bei mir so aus wie bei dir.
Bei mir braucht er übrigens für den Bildaufbau ~3 sek, dank der schnellen CPU. Bei dieser werde ich nun alle weiteren Optionen aufdrehen (68020 Instruction set).
Und durch einen Instruction cache (an dem ich gerade arbeite) wird sie sicher noch mal mind. 50% schneller.
LG,
Andi

Hallo,

super, aber woran lag jetzt die Farbverfälschung? Ich habe gerade mal meine lv_conf.h mit der aktuellen von smed verglichen.
Bei smed ist noch ...SW_SUPPORT_RGB888 und ...SW_SUPPORT_ARGB8888
gesetzt. Lag es daran?

Hallo,
das weiss ich auch nicht genau. Als ich dein lv_conf.h rein kopiert und dann alles neu gebaut hatte hat es gepasst
Möglicherweise lag es an dem RGB888-Support der bei dir abgedreht ist. Ich werd das morgen mal testen und das testhalber mal wieder aufdrehen
LG,
Andi

Hallo Werner,
Übrigens Wenn du auch die schnellere CPU auf deinem Tang-Nano willst brauchst nur das folgende FPGA-File rein laden: https://github.com/avg67/nkc/blob/main/tang_nano_20k/NKC_68k_FAST_PS2_KEYB_PCB.fs
Da ist alles genau gleich wie bisher, nur die CPU ist neu (4x schneller). Ich verwende schon seit längerer Zeit nur noch diese auf dem Tang-Nano
LG,
Andi

Hallo Andi,

danke für die Info. Ich habe auch schon überlegt, auf die schnellere Variante umzusteigen, habe mich aber nicht getraut ohne Rückfrage das FPGA-File zu laden.
Ich war bisher mit der Leistung zufrieden - mit LVGL hat sich das nun geändert. Ich werde am Wochenende auf die schnellere CPU umsteigen.

LG
Werner

Hallo,
man kann bei der schnellen CPU übrigens noch ~10% Performance rausholen wenn die GDP-Darstellung abgeschaltet wird (GDP-CTRL1 bit2=1) weil sich da die CPU die Speicherbandbreite nicht mit der GDP teilen muss -> wär ev. Interessant für das kopieren LVGL Framebuffer -> GDP Memory.
Bei der langsameren CPU ist das sicher auch der Fall, aber der Faktor ist dort sicherlich weit geringer weil die CPU viel weniger Speicherbandbreite braucht.
Die alte (langsame) CPU entspricht zu 100% einem 68000 mit 10MHz (Ausführungszeiten der Befehle, Bustiming, ...). Die neue ist da optimiert. Der Bus ist viel schneller und läuft mit 20MHz (1 Zyklus pro zugriff). Die meissten Befehle werden ebenfalls in einem 20MHz Taktzyklus ausgeführt. Die größte Bremse (bisher) ist die verfügbare Speicherbandbreite vom SDRAM, welche die CPU doch erheblich ausbremst. Aber trotzdem ist sie ~4x so schnell wie die alte.

Hallo Smed,
haben sich deine Probleme erledigt?
Hab jedenfalls das FPGA file, für alle Fälle, neu erstellt.
Bei mir hat aber auch das alte funktioniert.

LG,
Andi

Alles klar, ging dann doch noch. Nun geht der NKC aber ab, ziemlicher Geschwindigkeits boost !

-----------------------
NKC'ler seit 1984 (Pause zw. 1988-2017)
CPU68k,CPU68000,4xROA64,6xIOE,6xGDP,GDPHS,8xSBC2/3,HEXIO,6xKEY,UHR3,PROMER,CENT,SER,SOUND,CAS,6xBUS2,4xBUS3,3xPOW5V,2xTAST..und einen ArduinoMEGA mit auf dem BUS, und eine selbstgebastelte MEM960k und eine FPGA-GDP.

NKC - OpenSource since 1983

Hallo Smed,
freut mich dass das nun auch bei dir läuft
Die schnelle CPU ist in der Tat ein gewaltiger Geschwindigkeits-boost. Hab da auch einiges im GP patchen müssen weil die CPU zu schnell war und die HW überfahren hat.
Beim SDRAM wird die CPU doch noch erheblich ausgebremst weil ein Zugriff doch im Duchschnitt ~3-5 Taktzyklen dauert. Beim GP-ROM ist das nicht der Fall da kann die CPU die volle Geschwindigkeit erreichen weil da jeder Zugriff nur einen Takt dauert (und die CPU fast alle Befehle in einem Takt ausführen kann). Da geht so richtig die Post ab. Bin schon gepannt wie das dann mit Cache für den SDRam wird.
Komplexere Programme wie TFTP und LVGL profitieren gewaltig davon. Ich verwende schon seit langem nur noch die schnelle CPU am Tang-Nano.
LG,
Andi

Hallo,

bei mir läuft jetzt auch der Turbo, super.

@smed: Für die Fonts hast du einen super Platz gefunden. Willst du mit RGB565 weitermachen?

LG
Werner

Hi,
habe deine fonts nach ../lvgl/scr/font geschoben. Dank deiner rgb565_to_nkc_256lut() läuft jetzt der LVGL 16 color depth Modus mit der FPGA-GDP. Müsste man mal mit einem Farbverlauf testen.

Als nächstes ist der Slider 'dran - der lässt sich noch nicht schieben und beschwert sich über einen Nullpointer.

Habe LV_DEF_REFR_PERIOD auf 5 [ms] gestellt, ist auch für 'input device read' zuständig - nun ist die Maus flüssiger.

Ich habe die letzten Code-Beitrage auf Github ge-updated.

Gruss
smed

PS Leider zZT NULL Zeit für NKC

-----------------------
NKC'ler seit 1984 (Pause zw. 1988-2017)
CPU68k,CPU68000,4xROA64,6xIOE,6xGDP,GDPHS,8xSBC2/3,HEXIO,6xKEY,UHR3,PROMER,CENT,SER,SOUND,CAS,6xBUS2,4xBUS3,3xPOW5V,2xTAST..und einen ArduinoMEGA mit auf dem BUS, und eine selbstgebastelte MEM960k und eine FPGA-GDP.

NKC - OpenSource since 1983