Also so schwierig ist das nicht mit PlatformIO, im Gegenteil hat das eigentlich nur Vorteile, zum Beispiel kann man in der Arduino IDE keine Projekt-Defines setzen.
Wie auch immer, man kann meine Library auch mit der Arduino IDE verwenden, ich habe mal was ich im Laufwerk liegen hatte auf den aktuellen Stand der Dateien gebracht und angehängt.
Die größte Herausforderung das mit der Arduino IDE zu kompilieren bestand darin das ich die 2.x installiert und eine Weile nicht verwendet habe, das hat einen Moment gebraucht um sich zu aktualisieren.
In der EVE_config.h ist das Display eingestellt, normalerweise mache ich das über die platformio.ini und es gibt eben keine Projekt-Datei für Arduino.
Ich kann nicht sagen ob das wirklich läuft da ich das nicht extra nochmal ausprobiert habe, aber es kompiliert auf jeden Fall für UNO R3, UNO R4, ESP32 und "Generic STM32F4 series".
Die Pins für die Targets sind in den Dateien im EVE_target Verzeichnis definiert, die zeigt die Arduino IDE nicht direkt mit an, für den Editor gibt es die nicht, beim Kompilieren werden die aber benutzt.
Da muss man dann eventuell noch mal mit einem extra Editor die Einstellungen für das gewünschte Target prüfen.
Der eigentliche Code ist in der tft.c, wenn das so grundsätzlich läuft kann man das ja nach Belieben anpassen.
Nein, das ist von der Technik her was völlig anderes, so ziemlich die einzige Gemeinsamkeit zwischen einem ILI9341 und einem FT81x / BT81x ist das die SPI verwenden.
Danke @Rudolph, werde ich am Abend gleich mal ausprobieren!
Noch eine Frage: wenn ich jetzt doch größere Bilder oder als Gag gar ein Filmchen aus dem eingebauten Flash abspielen will, wie bekomme ich die am einfachsten dort hinein? Riverdi beschreibt zwar den extra Programmüberanschluss fur den Speicher (ein TagConnect TC2050-IDC-NL) aber ohne weitere Infos. Hat das schon mal jemand verwendet?
Der EVE Asset Builder kann per USB/SPI Adapter durch den EVE Chip den externen Flash beschreiben.
Unterstützt werden dabei "FT4222", "MPSSE" und "Raspberry Pi Pico".
Das Hermes und das EVE2-USB2SPI-KIT-A habe ich hier, das EVE-USB2SPI-KIT-B habe ich noch nirgendwo konkret zu kaufen gefunden.
Was ich aber auch gerne mache ist das Flash über mein Programm zu beschreiben, das hat vor allem den Vorteil das ich dafür nicht umstecken muss, die FFC Kabel sind nicht gerade auf Steckzyklen ausgelegt.
Der Nachteil ist, erstmal muss der Controller das Flash-Image speichern, da bietet sich aber zum Beispiel ein ESP32 an, und dann benutze ich CMD_FLASHUPDATE was über RAM_G läuft, das Flash-Image darf also entpackt nicht größer sein als 1MB.
Schau mal nach "TEST_UTF8" in der TFT.c, das Image dazu ist in der tft_data.c.
Ich bin ja aktuell leider auf den UNO beschränkt. Da bringt es mir dann eh keinen Vorteil, das Bild zuerst in den Flash vom EVE zu laden, oder? Also wenn ich mit dem Speicher vom AVR auskommen muss/will?
Anscheinend kann das STM32 Evalboard von Riverdi auch als Bridge konfiguriert werden, das könnte ich mir aus ausborgen.
Nun ja, kommt erstmal darauf an wie groß das Bild ist, ich empfehle für die BT81x auf jeden Fall ASTC und 8x8 liefert dabei eine gute Qualität bei nur 2 Bits pro Pixel.
Der nächste Schritt ist das mit EAB zu komprimieren, bzw. wenn das nur ein Bild ist kann man das gleich im Bild-Konverter machen.
Wenn dabei nur ein paar kiB raus und das Programm noch lange nicht die 30kiB überschreitet, klar, kann man einfach im Programm lassen und jedesmal beim Start ins RAM_G laden.
Wenn das Bild oder die Bilder den Platz im Controller sprengen, dann kann man ein eigenes Programm dafür machen, das einmal ins Flash abkippen und dann mit dem eigentlichen Programm von da nutzen.
An dem Beispiel hängt zwar ein 7kiB Flash-Image für einen Font in tft_data.c, solange das nicht verwendet wird taucht das im eigentlichen Programm aber nicht auf.
In meinem aktuellen Projekt spiele ich gerade mit Icons aus Googles Material Icons Set, bei 64x64 Pixel und ASTC 8x8 sind das 1024 Bytes pro Bild.
Mein _iconlibrary.astc für den Test hat gerade 29kiB und als _iconlibrary.zopfli sind das 7262 Bytes.
Das könnte ich jetzt in das Flash-Image werfen, der ATSAME51 Controller den ich verwende hat aber ohnehin 512kiB Flash und ich weiß gerade weder welche Icons ich dann am Ende benutzen werde, noch stört mich gerade das die Start-Zeit ein paar ms länger ist als sie sein könnte.
Oh ja, aus Erfahrung kann ich nur dazu raten das Anzeigen von irgendwas direkt aus dem Flash nur sehr sparsam zu benutzen, sei es Zeichensätze oder Bilder.
Bei Auflösungen von 800x480 oder höher, also wenn die Pixel-Engine recht wenig Zeit hat die Bildzeilen zusammen zu basteln, wirkt sich zunehmend die zwar recht hohe aber am Ende doch begrenzte Bandbreite vom externen Flash aus, gerade größere Fonts sind ein Problem, zum einen sind das ja auch nur Bilder, zum anderen ist der wahlfreie Zugriff auf das Flash ganz gut mit Overhead behaftet.
Also Best Practice ist das RAM_G möglichst voll auszureizen, man kann ja auch beim Programmstart vom externen Flash ins RAM_G kopieren lassen.
Mit ASTC 8x8 bekommt man das RAM_G auch lange nicht so schnell voll.
Whow! Danke!
Eine Frage stellt sich mir aber noch: Wie gehe ich mit den "extended" Bitmapformaten EVE_ASTC_8X8 etc. um? Muss man da was besonderes beachten?
Ich habe hier ein Bild, das im ASTC_8X8 Format 32640 Bytes groß ist
Und noch zwei damit zusammenhängende Fragen: Der Eve Asset Builder wirft für die umgewandelten Bilder ja leider eine recht unübersichtliche Datei .binh aus (alles Deimalzahlen, keine Zeilenumbrüch etc.). Gibt es noch eine andere Ausgabe oder einen Trick, um die Zahlenkolonne einfach in eine ansprechendere Form zu bringen?
Und gibt es einen speziellen grund wieso im Beispiel die memory-map defines an diesen Stellen liegen? Bzw. genauer gesagt warum wird nicht bei 0x000000 gestartet?
Eine Frage stellt sich mir aber noch: Wie gehe ich mit den "extended"
Bitmapformaten EVE_ASTC_8X8 etc. um? Muss man da was besonderes
beachten?
Ich habe hier ein Bild, das im ASTC_8X8 Format 32640 Bytes groß ist
Nö, da gibt es nicht wirklich was besonderes, anzeigen wie andere Bilder auch, z.B. EVE_cmd_setbitmap(ICON_ACCESS_ALARM, EVE_ASTC_8X8, 64U, 64U);
Und was man sonst noch so braucht aber nicht anders ist. :-)
Das sind eine ganze Menge Pixel und in den alten Formaten wären das so 260kiB.
Also ich würde das auf jedem Fall in das RAM_G legen.
Für wie das da landet gibt es ein paar Optionen:
a) Einfach so aus dem Controller heraus: EVE_memWrite_flash_buffer()
b) Erst in EAB durch den "Asset Compressor" schicken, das in den Controller legen und dann EVE_cmd_inflate() benutzen
c) Das ins Flash schreiben und EVE_cmd_flashread() benutzen
d) Das packen, ins Flash schreiben und EVE_cmd_inflate2() benutzen
Die .rawh vom Bilder-Umwandeln werfe ich immer weg, keine Ahnung für was die gut sein soll, die .astc, die .json und und _converted.png lösche ich auch immer.
Das "BIN2C" Modul im EAB erzeugt ordentliche Arrays und lässt sich auch noch konfigurieren.
Ich gebe es zu, diese Makro Wüste ist etwas hässlich geworden, aber das Beispiel baut für und läuft auf einer ganzen Liste unterschiedlicher Arduinos.
Das SPI.endTransaction(); gibt den SPI frei und SPI.beginTransaction(SPISettings(8UL * 1000000UL, MSBFIRST, SPI_MODE0)); konfiguriert den dann wieder neu.
Das TFT_init(); läuft in dem Beispiel mit dem SPI auf 1MHz.
Und dann wird der Takt hoch gedreht.
Der Hintergrund ist das der SPI Takt für das Init der EVE Chips unter 11MHz sein muss.
Nochmal so drüber nachgedacht ist das vermutlich albern komplex für den Beispiel Code, ist etwas gewachsen mit den verschiedenen Optionen.
Auf 8MHz einstellen und fertig wäre auch eine Option.
Das zeigt aber auch, dass die Kontrolle über den SPI Takt nicht in meiner Library vergraben ist, wenn man mehr als ein Device am SPI muss man ja vielleicht sogar zwischen den Transfers den Takt und/oder den Mode umschalten.
War nur etwas verwirrt, weil die SPI zuerst auf 8MHz gestellt wird, dann nochmal auf 8Mhz und sofort auf dann 16MHz.
Darf ich fragen wie die Memory Map aussehen soll? Wie viel Speicher (von - bis) kann man da jetzt wirklich verwenden und was ist der Startpunkt? Im Programming Manual ist auch erwähnt, das es gewisse Einschränkungen beim Alignment geben soll?
Warum wird nicht bei 0x00000000 gestartet?
1
/* memory-map defines */
2
#define MEM_FONT 0x000f7e00 /* the .xfont file for the UTF-8 font is copied here */
3
#define MEM_LOGO 0x000f8000 /* start-address of logo, needs 6272 bytes of memory */
4
#define MEM_PIC1 0x000fa000 /* start of 100x100 pixel test image, ARGB565, needs 20000 bytes of memory */
War nur etwas verwirrt, weil die SPI zuerst auf 8MHz gestellt wird, dann
nochmal auf 8Mhz und sofort auf dann 16MHz.
Nee, das wird erst auf 1MHz und dann entweder auf 8, 16, 20 oder 16 MHz eingestellt.
Wie ich schrieb, für das Beispiel-Programm ist das inzwischen übertrieben kompliziert.
Darf ich fragen wie die Memory Map aussehen soll?
Wie Du meinst.
Wie viel Speicher (von
bis) kann man da jetzt wirklich verwenden und was ist der Startpunkt?
Das RAM_G geht von 0 bis 0xfffff.
Im Programming Manual ist auch erwähnt, das es gewisse Einschränkungen
beim Alignment geben soll?
Ja, je nachdem was man macht, z.B. wenn man Bilder aus dem Flash anzeigen möchte, dann müssen die 32 Byte aligned abgelegt sein.
Warum wird nicht bei 0x00000000 gestartet?
Kein besonderer Grund, ich habe in dem Beispiel nur von oben angefangen um zusätzliche Dinge wie Zeichensätze spontan auf 0x0000 werfen zu können.
1
>/* memory-map defines */
2
>#defineMEM_FONT0x000f7e00/* the .xfont file for the UTF-8 font is
3
> copied here */
4
>#defineMEM_LOGO0x000f8000/* start-address of logo, needs 6272 bytes
5
> of memory */
6
>#defineMEM_PIC10x000fa000/* start of 100x100 pixel test image,
7
> ARGB565, needs 20000 bytes of memory */
8
>
Da folgt auch noch MEM_DL_STATIC.
In meinem aktuellen Projekt habe ich:
#define MEM_ICON_BASE 0x000f0000UL
Für 55 Icons in ASTC 8x8 mit 64x64 Pixel.
Aber ich habe noch keine Idee ob ich überhaupt 55 Icons brauche.
Das ist gefolgt von sechs Bereichen für .xfont Daten.
Aktuell sieht es aber danach aus das ich die .glyph Daten der Zeichensätze auch noch nach RAM_G verschieben muss.
Danke nochmals für deine Library und deine Hilfe Rudolph!
Der Speicher im Arduino ist mir leider zu knapp geworden - aber ich bekomme heute vielleicht noch das Riverdi STM32 Evaluation Board von einem Arbeitskollegen und kann dann am Abend weiterspielen. Das Board hat ja u.A. eine USB FT232H Bridge und damit sollte man ja den Flash auf dem Display direkt bespielen können. Das scheint mir für meine einzellösung die einfachste Variante zu sein, 1x umstecken wird das Kabel schon noch aushalten.
Was mir aber noch nicht klar ist: Wenn ich die Bilder (und eventuell auch 2 Fonts) in den Flash gespielt habe, wie genau kann ich sie dann anzeigen bzw die Fonts verwenden lassen? Irgendwelche Empfehlungen für die zu verwendenden Formate?
Wie man einen Zeichensatz aus dem Flash benutzt ist in meinem Beispiel drin.
Erstmal muss alles was aus dem Flash angezeigt werden soll im ASTC Format sein.
Also für den Font eben "Extended Format" und da am besten auf 8x8 umstellen.
Die .glyph enthält die ganzen Bilder, die .xfont die Verwaltungsinformationen.
Die Adresse im Font-Converter ist quasi egal, wenn man in den "Flash Utilities" die .glyph und die .xfont für einen Font verwendet, dann wird die Adresse in der .xfont darauf angepasst wo die .glyph landet.
Um das Alignement kümmert sich das auch.
Um einen Font zu benutzen muss man die .font nach RAM_G kopieren:
EVE_cmd_flashread(MEM_FONT_28, 38464, 320);
Dann noch mit CMD_SETFONT2 benutzen:
EVE_cmd_setfont2(18,MEM_FONT_28,32);
Wenn man einen Font ins Flash gelegt hat und aus dem RAM_G benutzen will, dann wird es minimal komplizierter.
Dann muss man nämlich die Adresse der .glyph Daten in .xfont im RAM_G schreiben.
Bei Bildern braucht man die .raw Dateien die aus dem Converter fallen, nicht etwa die .astc.
Der Unterschied ist, die .astc hat noch einen 16 Byte Header.
Da kümmert EAB auch um das Alignment, das muss 32 Byte sein.
Beim Anzeigen von Bildern aus dem Flash wird es etwas seltsam,
die Adresse ist nämlich in Blöcken von 32 anzugeben mit dem obersten Bit der 24 Bit Adresse gesetzt:
EVE_cmd_setbitmap_burst(0x800000 | (4096/32), EVE_ASTC_8x8, 64, 64);
two channel LVDS TX for displays with up to 1920 x 1200
two channel LVDS RX for Video input up to 1920 x 1200
"Embedded 1Gbit DDR3L SDRAM" - so 128MB of RAM
"Advanced EVE with Frame Buffer support for High Resolution HMI"
16kiB display list
SD card support
Audio is stereo now and output is by I2S
integrated Watchdog timer
enhanced touch engine
live video feed
both resistive and capacive touch support in one chip
clock source is a 38.4MHz crystal
And yet Bridgetek wrote: "Despite the frame buffer inside, we've retained the same features that made EVE so good and the screens are still created using the command/display lists etc. The frame buffer combined with the 16K RAM_DL will help with the more complex user interfaces without underrun etc. but from the application side it will still feel very familiar."
What I take away from this:
The changes to EVE5 are probably even bigger than between EVE1 and EVE2, so I probably will support BT822 with a new library instead of trying to fit EVE5 support into my current library.
I expect the API will move away from 22 bit adressing to 29 or 30 bit adressing and of course the memory map will be completely different.
I also wouldn't be surprised if RAM_CMD is doubled as well.
And I wonder what all the SDRAM is supposed to be used for.
A frame buffer for 1920x1200 would take 9MiB and there are likeley two to switch between display lists, another 9MiB for the video input.
That still leaves 100MiB, wow.
Anyways, I will keep an eye out for the release of the datasheet and the programming manual as well as for BT822 hardware to buy.
Hallo Rudolph,
ich brauche mal etwas Unterstützung. Im Forum finde ich leider nichts.
Ich will zwei benutzerdefinierte Fonts auf einen BT817 schreiben. der erste Font funktioniert ohne Probleme. Den zweiten Font habe ich wie im Forum beschrieben erstellt.
###############
Will man zwei Fonts benutzen muss man also erstmal ein FLASH Image
generieren, so etwa mit Font1.glyph, Font1.xfont und irgendeiner anderen
Datei.
Dann die Adresse an der die andere Datei landet aufschreiben, mit dieser
Adresse den nächsten Font konvertieren und wieder von vorne.
Will man zwei Fonts benutzen muss man also erstmal ein FLASH Image
generieren,
Jain, kann man machen, aber das FLASH Image ist ja eigenlich für das externe Flash am BT817 gedacht und ich schreibe das in meinem Beispiel ja auch per EVE_cmd_flashupdate() erstmal ins Flash.
Und EVE_cmd_inflate() benutze ich da nur weil sich Fonts zum einen so gut komprimieren lassen, zum anderen kommt CMD_INFLATE nicht damit klar wenn die Daten nicht ganz korrekt sind.
Der Asset Compressor in EAB kann auch archive erzeugen in denen wie bei den Flash-Utilities mehrere Dateien hinternander gehängt sind.
Die Flash Utilities machen dann eben noch mehr, die "default-fl.blob" Datei ist der Flash-Treiber für den BT817.
Und dann kümmert sich das auch noch um das korrekte Alignment im Flash.
Wobei der Asset Compressor die Offsets zu den Datein nicht so komfortabel auswirft wie die Flash Utilities.
so etwa mit Font1.glyph, Font1.xfont und irgendeiner anderen Datei.
Das können auch mehrere .glyph und .xfont sein und die seltsame .padding ist nur für das Alignment im Flash.
Dann die Adresse an der die andere Datei landet aufschreiben, mit dieser
Adresse den nächsten Font konvertieren und wieder von vorne.
Nicht unbedingt, wenn man eine .glyph und eine .xfont zusammen in ein Flash-Image wirft, dann wird die .xfont automatisch angepasst.
Wenn man den Font allerdings aus dem RAM_G verwenden möchte, dann muss man den Offset in der .xfont selber anpassen - was Du ja auch machst.
Also das anpassen der Adressen beim Konvertieren ist nur notwendig, wenn man das wirklich direkt wie es ist in das RAM_G schreiben und so verwenden will ohne noch anzupassen.
Ok, was funktioniert denn da nicht?
Das entpackt zwei Images in das RAM_G, das eine an Adresse Null, das andere dahinter.
Dann werden noch die Offsets in den .xfont Dateien angepasst.
Das sieht soweit fast richtig aus, der Offset der zweiten .xfont wird aber auf den Anfang des zweiten Images gesetzt, wenn das auch ein Flash-Image ist sind doch die ersten 4096 Bytes wieder belegt.
ich habe deinen Hinweis mit dem Offset angepasst.
EVE_cmd_inflate(95808UL, font_2, sizeof(font_2));
EVE_memWrite32(95808UL + 39040UL + 32UL, 4096UL + 95808UL);
bekomme aber noch immer keine Ausgabe für font_2. Beide Fonts funktionieren - ich habe das Ausprobiert indem ich font_2 testweise an Adresse 0 beginnen lasse.
ich habe gerade mit EVE und Co. angefangen. Zum spielen habe ich mir die "VM810C EVE2 CREDIT CARD MODULE" besorgt. Eine ESP32 Wroom 32D (China Shop) verorgt das Display mit Daten. Ich habe diesen Beitrag von Anfang bis fast zum Ende durchgelesen und teilweise einige Beiträge sogar mehrmals.
Die Datenblätter FT81x, Programmer guide und noch andere. EVE Asset Builder und EVE Screen Editor installiert und versucht einige Sachen parallel nachzuvollziehen. Ich bekomme auch einige Beispiel-Projekte zum laufen, soll heißen, die ESP und das Display verstehen sich und ich habe entsprechn eine Anzeige. Leider scheitere ich an den einfachsten Dingen wie z.B. ein etwas größeres Bild zu laden/anzuzeigen (statisch) ohne jeden schnick schnack.
Ich versteh ehrlich gesagt nicht wo das Bild in deinem Beispiel geladen wird. RAM_G (Speicher 1024*1024 Byte), alle anderen Speicher wären ja zu klein. Ich habe aus dem Datenblatt und in ESE nachvollziehen können das der RAM_G bei 0x00000000 anfängt und bis 0x000FFFFF (1.048.575). Wenn ich aus deinem Beispiel Projekt "EVE_Test_Arduino_PlatformIO" tft.c
1
/* memory-map defines */
2
#define MEM_FONT 0x000f7e00 /* the .xfont file for the UTF-8 font is copied here */
3
#define MEM_LOGO 0x000f8000 /* start-address of logo, needs 6272 bytes of memory */
4
#define MEM_PIC1 0x000fa000 /* start of 100x100 pixel test image, ARGB565, needs 20000 bytes of memory */
5
6
#define MEM_DL_STATIC (EVE_RAM_G_SIZE - 4096) /* 0xff000 - start-address of the static part of the display-list, upper 4k of gfx-mem */
anschaue, dachte ich mir ok MEM_PIC1 fängt bei 0x000fa000 (1.024.000) an und braucht 20000 bytes, also ist der Speicher am Ende (1.044.000) Rest (4.575) da passt kein Bild mehr rein.
Also setzte ich
1
#define MEM_BIGPIC 0x00000000
an den Anfang.
Trotzdem kein Bild. Ich habe mit EAB unterschiedliche Bilder in der Größenordnung von 50x50 bis ca. 400x200 convertiert. Laut ESE z.B. sieht es wie folgt aus. Size: 165888 Compressed: 67902 w:384 h:216 Line Stride:768
1
CLEAR(1,1,1)
2
BITMAP_HANDLE(0)
3
CMD_SETBITMAP(0,ARGB1555,384,216)
4
BEGIN(BITMAPS)
5
VERTEX2F(3504,2064)
6
END()
BITMAP_HANDLE: 6% RAM_DL: 0% RAM_G: 15%
Übrigens, ich verändere nichts an dem Code. Ergänze lediglich im (tft_data files werden natürlich entsprechend angepasst)
spontan würde ich sagen, Du versuchst konvertierte Daten mit CMD_LOADIMAGE zu laden.
Das CMD_LOADIMAGE ist aber für Rohdaten in .jpg oder .png Format.
Wenn Du in RGB565 konvertierst kannst Du in EAB den AssetCompressor benutzen um die resultieren binär Daten etwas zu packen.
Diese Daten werden dann mit CMD_INFLATE verschickt und in RAM_G entpackt.
The image wallpaper3_320x180_320x180_RGB565_Converted.png is compatible with cmd_loadimage and BT81X series.
10
DONE!
OK hab mich da beirren lassen.
Also den compress kann man nur über die console anwenden.
Output File: wallpaper3_320x180_RGB565.bin (58.2 KB)
Format : RGB565
Width : 320
Height : 180
Compressed : yes
mit CMD_INFLATE bekomme ich etwas wie ein Bild aufs Display. Hänge an wie es aussehen sollte und wie es tatsächlich aussieht.
wallpaper, Bild aus dem Internet runtergeladen und einfach nur auf 320x180px gespeichert
wallpaper2, ohne EXIF(Irfanview)
wallpaper3, ohne EXIF und 8Bit-Farbtiefe(Irfanview)
Bei allen das gleiche Ergebnis.
1
void TFT_init(void)
2
{
3
.
4
.
5
.
6
EVE_cmd_inflate(MEM_LOGO, logo, sizeof(logo)); /* load logo into gfx-memory and de-compress it */
Außerdem verstehe ich nicht warum nurt etwas auf dem Display erscheint , wenn ich bei setbitmap(...,EVE_ARG1555,...) eintrage, obwohl das Bild mit RGB565 convertiert/erzeugt wird. Stehe aufm Schlauch...
Edit: ich habe mir einfach mal das wallpaper3_320x180.jpg da oben gegriffen, in EAB umgewandelt in RGB565, Dithering ausgeschaltet, das macht nur Rauschen.
Dann in EAB mit dem Asset Compressor gezipped und mit dem BIN2C Tool im EAB in eine .c gewandelt.
Das Array hat 43091 Byte.
Das habe ich mein aktuelles Spielprojekt eingebaut.
Da ich da noch ein anderes Bild dran habe an Adress Null
musste ich das woanders hin entpacken:
EVE_cmd_inflate(0x16f00, wallpaper, sizeof(wallpaper));
Und dann habe ich das zusätzlich zu dem anderen Bild angezeigt:
Guten morgen,
ich benutze die neueste EAB v2.12.2 hier gibt es keine Option für compress. Aber über die console kann man die Option mit -z ausführen.
Zum testen habe ich mir eine ältere Version runtergeladen v2.8.0
EVE Chip: FT81X Output Format: RGB565 Compressed=1 Dithering=0
Anschließend die erzeugte .bin mit bin2c convertiert und in die tft_data.c kopiert. Ergebnis ist genau so wie vorher...
Also mal ein/zwei Verständnisfragen:
EAB 2.8.0 & 2.12.2 erzeugen mehrere Dateien bei Compress=1
.bin
.binh --> die hab ich direkt mit CMD_INFLATE probiert
bei Compress=0 gibt es
.raw
.rawh --> die hatte ich auch mit CMD_LOADIMAGE probiert (kein Bild)
Mit der .binh hatte ich zumindest auch das verzerte(Bild ähnl.) Gebilde.
Warum muss ich die .bin nochmal mit bin2c jagen, obwohl doch anscheinend EAB die Aufgabe auch durchführt. Oder hab ich ein Denkfehler?
Welche Dateilänge gibt man an? 320x180 -> 2 Byte/px 640x180=115200
Bin2c gibt die comprimierte größe an oder?
Ich hatte gestern bereits mit EVE_RGB565 probiert und es ging nicht, heute geht es (naja zugegeben hatte ich die Bilder nicht mit bin2c konvertiert sondern die .binc genommen).
Also EVE_ARGB1555 funktioniert nicht, eigl. auch klar, weil das Bild mit RGB565 konvertiert wird. OMG
Manchmal hat man einfach Tomaten auf den Augen.
Naja, vielleicht hilft es dem oder den anderen die auch solche Probleme haben.
ich benutze die neueste EAB v2.12.2 hier gibt es keine Option für
compress.
Stimmt, die Option habe ich auch nicht mehr.
Anschließend die erzeugte .bin mit bin2c convertiert und in die
tft_data.c kopiert. Ergebnis ist genau so wie vorher...
Also das sollte eigentlich funktionieren.
Also mal ein/zwei Verständnisfragen:
EAB 2.8.0 & 2.12.2 erzeugen mehrere Dateien bei Compress=1
.bin
.binh --> die hab ich direkt mit CMD_INFLATE probiert
Mal davon ab, dass die .xxxh keine Header File sind, die Zahlenwüste sollte sich eigentlich in ein Array packen lassen.
Aber diese Dateien benutze ich nie.
.raw
.rawh --> die hatte ich auch mit CMD_LOADIMAGE probiert (kein Bild)
Das sind unkomprimierte Rohdaten als Text, damit kann weder CMD_LOADIMAGE was anfangen, noch CMD_INFLATE.
Die müsste man direkt in den Speicher schreiben und dafür habe ich EVE_memWrite_flash_buffer().
Als .jpg / .png oder auch konvertiert und komprimiert sind es eben nur weniger Daten, das spart Platz im Controller und kostet weniger Zeit beim Übertragen per SPI.
Der Unterschied zwischen selber konvertieren und CMD_LOADIMAGE ist vor allem die Kontrolle über das Format das dabei heraus kommt.
Ich habe die Daten für das wallpaper array ersetzt, probier das mal mit CMD_INFLATE.
Mit der .binh hatte ich zumindest auch das verzerte(Bild ähnl.) Gebilde.
Warum muss ich die .bin nochmal mit bin2c jagen, obwohl doch anscheinend
EAB die Aufgabe auch durchführt. Oder hab ich ein Denkfehler?
Ich benutze den in EAB eingebauten "ASSET COMPRESSOR", der erzeugt keine .xxxh Datei, da kommt eine .zlib oder .zopfli Datei raus und die sind Binär.
Wobei die zopfli Lib normalerweise besser komprimiert.
Welche Dateilänge gibt man an? 320x180 -> 2 Byte/px 640x180=115200
Da hätte ich weiterlesen sollen bevor ich die tft_data.c verändert habe. :-)
Das Array muss natürlich die Länge der Daten haben.
Bin2c gibt die comprimierte größe an oder?/*
Jain, die Länge der konvertierten Binär-Daten, ob nun komprimiert oder nicht.
C-file generated by Bin2C
Compiled: Oct 11 2024 at 10:28:35
Copyright (C) 2018
Segger Microcontroller GmbH
In EAB ist ein BIN2C Tool mit eingebaut.
Nicht, das andere Tools nicht funktionieren, das ist einfach komfortabler zu nutzen direkt aus EAB heraus, statt erst eine Shell öffnen zu müssen.
Die leicht abweichenden Daten die ich habe mit anderer Länge kommen wohl daher das ich die angehängte .jpg verwendet habe und Du ein .png benutzt hast.
Kann es sein, dass Dein .png einen transparenten Hintergrund hat?
Ein .png hier anzuhängen war allerdings zumindest als ich das zuletzt probiert habe nicht so hilfreich, aus irgendeinem Grund hat die Forens-Software die Datei verändert.
In EAB ist ein BIN2C Tool mit eingebaut.
Nicht, das andere Tools nicht funktionieren, das ist einfach
komfortabler zu nutzen direkt aus EAB heraus, statt erst eine Shell
öffnen zu müssen.
Ist mir vorher garnicht aufgefallen, wie gesagt, Tomaten auf den Augen :)
Also im Schritt 1 mit compress option (nur console) konvertieren. So erhält man .bin, .binh etc. Diese wiederum müssen praktisch gar nicht mehr den Schritt 2 durchlaufen, weil die bereits komprimiert sind. Wenn ich die "gezippten" Dateien nun mit bin2c konvertiere wird auch kein Bild dargestellt. Noch ein kleiner Nebeneffekt, in dem Fall wurde die Datei sogar ca. 12 bytes größer als ohne "zippen".
Ein .png hier anzuhängen war allerdings zumindest als ich das zuletzt
probiert habe nicht so hilfreich, aus irgendeinem Grund hat die
Forens-Software die Datei verändert.
Ja, das stimmt. Heute habe ich es auch runtergeladen und die Datei war nur noch halb so groß.
Ich hänge mal die wallpaper nochmal an (so wie aus dem Netz ohne Manipulation) es sollte 640x360 und 28,6KB groß sein.
Also im Schritt 1 mit compress option (nur console) konvertieren. So
erhält man .bin, .binh etc. Diese wiederum müssen praktisch gar nicht
mehr den Schritt 2 durchlaufen, weil die bereits komprimiert sind. Wenn
ich die "gezippten" Dateien nun mit bin2c konvertiere wird auch kein
Bild dargestellt. Noch ein kleiner Nebeneffekt, in dem Fall wurde die
Datei sogar ca. 12 bytes größer als ohne "zippen".
Man kann sich so zwar den zweiten Schritt sparen, aber dafür hat man auch erheblich mehr Getippe. :-)
Und ich sehe da keine Zopfli Option.
Ja, du hast natürlich Recht. Ich muss mich mit dem Konvertieren näher beschäftigen. Die .raw Dateien lassen sich mit asset compressor "zippen" und diese kann man mit bin2c umwandeln und mit CMD_INFLATE in den RAM_G laden. War diese Zusammenfassung korrekt?
Ich habe noch ein bischen mehr gespielt, und zwar habe ich ein Bild mit paint.net in vier Ebenen getrennt (Hintergrund Transparent) und vier einzelne .png Bilder gespeichert.
Diesmal mit ARGB1555 konvertiert (wegen transparens). Ich wollte die vier einzelbilder auf dem Display wieder als ein Bild darstellen lassen. Mit dem ESE funktioniert das:
Ich dachte ich könnte die vier Einzelbilder einfach übereinander legen.
Verstehe auch noch nicht ganz wie ich die ESE Anweisungen mit deiner Lib umsetzen kann. Ich habe auch schon versucht mit BITMAP_HANDLE(0..3)
EVE_cmd_dl(BITMAP_HANDLE(0));
oder
BITMAP_HANDLE(0);
oder
EVE_cmd_dl(DL_BITMAP_HANDLE);
Wird vom Kommando co-processor generiert aus CMD_SETBITMAP.
Also man könnte in dem Fall die resultierende Display-Liste optimieren indem man nicht CMD_SETBITMAP verwendet, sondern die resultierenden Kommandos, dabei aber den Satz nur einmal und für das zweite und folgende Bild nur noch BITMAP_SOURCE mit der jeweils passenden Adresse.
Das ändert nur alles nichts am Ergebnis, der Unterschied ist nur wie viel in der Display Liste landet um das Gleiche zu machen.
Einzeln werden die Bilder auf dem Display korrekt dargestellt, sobald
eins dazu kommt gibt es eine "Suppe"
Pack die .png doch bitte mal in ein .zip und häng die an, damit ich das ausprobieren kann.
Es ist durchaus möglich, dass das Überlagern von Bildern in ESE anders funktioniert als auf dem Display, das würde ich dann aber als Fehler in ESE deklarieren.
Ich habe pro #define 4kB reserviert, ich bin mir nicht mehr ganz sicher, aber in den letzten Tagen/Wochen habe ich soviel Zeug gelesen. Ich meine mich errinnern zu können das die Adresse durch vier teilbar sein muss. Vielleicht verwechsele ich auch gerade was.
Also wenn die Bilder 499x224 haben and ARGB1555 sind, dann werden die im RAM_G ja 499 x 244 x 2 Bytes haben -> 223552 / 0x36940 jeweils.
Die machen zusammen ja schon fast den Speicher komplett voll.
Die Adressen in ESE sind ja auch so, entsprechend müsste auch die RAM_G Auslastungsanzeige in ESE aussehen.
Der FT810 kann Farb-Bilder leider nur mit 16 Bit pro Pixel anzeigen.
CMD_LOADIMAGE konvertiert und CMD_INFLATE entpackt, der resultierende Speicherverbrauch im RAM_G ist bei gleicher Auflösung identisch.
Danke für die Ausführung. Kaum macht man es richtig und schon funktioniert es. Verständnisproblem meinerseits.
Ich habe die komprimierten Werte eingetragen, war natürlich falsch.
