raw Bitmap im EVE / FT800 laden

[Philipp K. (pk_hweng)]

Hi,

ich versuche nun seit geraumer Zeit mehrere RAW Dateien in den GRAM des 
FT800 zu laden.
Ich nutze den alten C-Treiber von FTDI der soweit auch funktioniert, das 
Display kann ich ansteuern, Buttons erstellen etc. Auch das laden von 
nur einem JPEG funktioniert, da ich aber zum einen mehrere Grafiken 
benötige und JPEG Artefakte verhindern möchte wollte ich nun auf raw 
RGB565 umschwenken.

Jedoch mache ich mit ziemlicher Sicherheit mache ich hier einen 
Denkfehler...

Wenn ich ein JEPEG laden möchte gibt es den load_image Befehl nach dem 
dann die Grafik in den CMD Speicher geschrieben wird.
Für bitmaps habe ich kein entsprechendes Kommando gefunden :(

Das Vorgehen, sobald das Bild im Speicher liegt, geht aus den 
zahlreichen AN's von Bridgetek gut hervor:

Ft_App_WrCoCmd_Buffer(disp_host, BEGIN(BITMAPS));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_HANDLE(id));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SOURCE(RAM_G + Offset));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_LAYOUT(RGB565, 100, 50));
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SIZE(NEAREST, BORDER, BORDER, 100, 50));
Ft_App_WrCoCmd_Buffer(disp_host, VERTEX2II(0, 0, id, 0));

Aber wie bekomme ich die Daten an die Stelle (RAM_G + Offset) im VRAM?

Mit Ft_Gpu_Hal_WrMem(phost, (RAM_G + Offset), ....) funktioniert es 
nicht (Datenmüll an de Stelle im RAM beim laden des Bildes).

Für JPEGS nutze ich Ft_Gpu_Hal_WrCmdBuf(...) jedoch fehlt mir hier die 
Möglichkeit den Adressoffest anzugeben und beim RAW Format ohne 
vorhergehenden load_image Befehl bleibt das Display hängen.

Über einen kleinen Tip wäre ich sehr dankbar.

VG,
Philipp

[Rudolph R. (rudolph)]

Schau mal hier:
https://github.com/RudolphRiedel/FT800-FT813
Beitrag "FT800 / FT810 Library"

Da finden sich auch einige Beispile.

Bilder in den EVE eigenen Formaten werden am besten mit dem EVE image 
converter oder EVE asset builder komprimiert und dann mit cmd_inflate() 
in das RAM_G entpackt.

Mit dem FT809 bist Du allerdings sehr spät dran, die erste Generation 
EVE zu benutzen lohnt sich nicht mehr so wirklich.

[Philipp K. (pk_hweng)]

Hallo Rudolph,

danke für den Hinweis.

Ich habe die Lösung gefunden, wenn man weiß wie ist es ganz einfach :)

Ft_Gpu_CoCmd_MemWrite(disp_host, RAM_G+Offset, fileSize); // EVE Upload mit der Filesize starten

while()
{
...
Ft_Gpu_Hal_WrCmdBuf(phost, imageBuffer, blockLen);
...
}

// END COPY FILE TO EVE
    Ft_App_WrCoCmd_Buffer(disp_host, BEGIN(BITMAPS));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_HANDLE(0));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SOURCE(RAM_G+Offset));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_LAYOUT(RGB565, 100*2, 50));
    Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_SIZE(NEAREST, BORDER, BORDER, 100, 50));
    Ft_App_WrCoCmd_Buffer(disp_host, VERTEX2II(0, 0, 0, 0));
    Ft_App_WrCoCmd_Buffer(disp_host, END());

[Rudolph R. (rudolph)]

Philipp K. schrieb:
> Ich habe die Lösung gefunden, wenn man weiß wie ist es ganz einfach :)
> Ft_Gpu_CoCmd_MemWrite(disp_host, RAM_G+Offset, fileSize); // EVE Upload
> mit der Filesize starten

Naja, klar funktioniert das auch, nur sind die Daten dann eben nicht 
komprimiert.
Und dabei ist nicht nur interessant, wie die Daten gespeichert werden, 
sondern auch wie sie übertragen werden.
Für ein 64x64 Pixel Icon braucht man eben mal 8kB Speicher.
Packt man das in den Controller belegt das unnötigt Platz, schiebt man 
das per SPI in den FT800 dauert das unnötig lange.

Das cmd_inflate() ist eben die Funktion für Bilder die nicht von 
cmd_loadimage() geladen werden können.

Wobei ich das gerade mal ausprobiert habe, mit einem Vollfarb-Icon komme 
ich spontan nur von 8192 Bytes auf 7357 Bytes runter, kommt halt auf den 
Bildinhalt an.
Für ein einzelnes Piktogramm lohnt sich das nicht so.

Aber ich benutze das eigentlich auch nur für monochrome Bilder, jpeg ist 
schon ganz okay und noch mal deutlich kleiner.
Wie stark man das .jpg beim Speichern komprimiert kann man ja einstellen 
und so zwischen Speicherbedarf und Artefakten abwägen.

Die FT81x könnten auch direkt .png laden, so richtig schickt ist das 
aber nicht.
Erstmal sind die Bilder tendenziell größer, zum anderen benötigen die 
FT81x sehr viel mehr Zeit um ein .png zu entpacken als sie für .jpg 
brauchen.

Der größte Vorteil der FT81x ist der auf 1MB vergrößerte Speicher.

Die dritte Generation, BT81x, kann ASTC komprimierte Bilder direkt aus 
einem zusätzlichen SPI-Flash laden.
Darunter fallen auch die Glyphen für Unicode Fonts.


Edit:

Das
Ft_App_WrCoCmd_Buffer(disp_host, BITMAP_HANDLE(0));
ist in dem Beispiel überflüssig, das wird in einem anderen Zusammenhang 
erst interessant.