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.
Christoph M. schrieb:> Könnte Deine Library das CYD unterstützen?
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".
Die Software für den Pi-Pi-Co ist hier:
https://github.com/Bridgetek/pico-brteve
MPSSE wäre sowas:
https://riverdi.com/de/blog/hermes-board-spi-usb-brueckenboard (ist
meine ich eingestellt)
https://www.matrixorbital.com/interface-module/eve2-usb2spi-kit-ahttps://www.matrixorbital.com/interface-module/eve-usb2spi-kit-b
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?
Luky S. schrieb:> 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 */
Luky S. schrieb:> 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);
Siehe auch hier:
https://github.com/RudolphRiedel/FT800-FT813/discussions/116
So, in less than two weeks the BT822 is launched at the Embedded World
2024 North America.
What little information I have so far is what I gathered from published
pictures and this article:
https://brtchip.com/discover-bt822-next-evolution-bridgetek-5th-gen-eve/
- 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.
###############
Die Dummy-Datei bringt
###############
default-fl.blob : 0 : 4096
aptos-semibold_200_ASTC.glyph : 4096 : 91392
aptos-semibold_200_ASTC.xfont : 95488 : 264
aptos-semibold_200_ASTC.xfont.padding : 95752 : 56
DUMMY.txt : 95808 : 0
##############
Mein Code funktioniert nicht
##############
EVE_cmd_inflate(0, font_1, sizeof(font_1));
EVE_memWrite32(95488UL + 32UL, 4096UL);
EVE_cmd_inflate(95808UL, font_2, sizeof(font_2));
EVE_memWrite32(95808UL + 39040UL + 32UL, 95808UL);
##############
Ich bin am verzweifeln und wäre über einen Hinweis sehr dankbar.
Moin,
>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.
Paul schrieb:> 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.
Paul schrieb:> Mein Code funktioniert nicht>> ##############>> EVE_cmd_inflate(0, font_1, sizeof(font_1));> EVE_memWrite32(95488UL + 32UL, 4096UL);>> EVE_cmd_inflate(95808UL, font_2, sizeof(font_2));> EVE_memWrite32(95808UL + 39040UL + 32UL, 95808UL);
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.
Und das benutzt die Fonts doch aber noch nicht.
Hallo Rudolph,
ich konnte es jetzt lösen.
Man musste zum MEM_FONT_2 auch 95808UL addieren.
Vielen Dank für die Unterstützung - der Tip mit dem Offset brachte mich
auf die richtige Spur.
Hallo Rudolph,
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.
Rudolph R. schrieb:> Dann einfach in TFT_init() laden:>> EVE_cmd_loadimage(MEM_BIGPIC, EVE_OPT_NODL, bigpic, sizeof(bigpic));>> Das sind 2 Byte pro Pixel, bei 800x480 also mal eben 768000 Bytes.> MEM_BIGPIC sollte also nicht zu weit hinten im Speicher liegen.>> Und anzeigen mit:>> EVE_cmd_setbitmap(MEM_BIGPIC, EVE_RGB565, 800, 480);> EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);> EVE_cmd_dl(VERTEX2F(0, 0));> EVE_cmd_dl(DL_END);
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)
Hallo,
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...
Welche Version vom EAB benutzt Du?
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 habs jetzt hinbekommen....
EVE_cmd_setbitmap(MEM_WALL, EVE_RGB565, 320U, 180U);
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.
Moin,
Ufuk schrieb:> 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.
> static const unsigned char _acwallpaper_320_320x180_RGB565[43101UL + 1]
Und das wäre richtig gewesen.
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.
Puh, wo soll ich anfangen...
Auf jeden Fall vielen Dank für die Erleuchtung, hab mich wohl
tatsächlich im Kreis gedreht und die Ausfahrt nicht gefunden.
Jetzt wird mir so einiges klar.
Bin jetzt wieder auf die EAB 2.12.2 gewechselt, folgendes ist mir
aufgefallen, wenn ich unter
1. "image utilities" meine Bilder konvertiere (ohne compress) bekomme
ich nur Dateien wie: .raw, .rawh, .json etc.
diese lassen sich zwar mit dem
2. "asset compressor" in .zlib oder .zopfli "zippen" und anschließend
mit dem
3. "bin2c" in header Dateien umwandeln, aber die Bilder werden nicht
angezeigt.
Rudolph R. schrieb:> 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".
Nochmal kurz zusammengefasst:
1. "image utilities" (Command prompt)
2. "bin2c" >> Datei.h
Den Inhalt[und größe] in die tft_data.c kopieren..
1
const uint8_t <dateiname>[12942] PROGMEM =
2
{
3
120, 218, 1, 131, 50, 124,.....
4
};
..und in tft_data.h eintragen.
Eigentl. ganz einfach ;)
Rudolph R. schrieb:> Kann es sein, dass Dein .png einen transparenten Hintergrund hat?
Ich glaube nicht, ist ein .jpg gewesen. Soweit ich weiß können nur .png
transparente Hintergründe haben.
Rudolph R. schrieb:> 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.
Ufuk schrieb:> 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.
wallpaper3_320x180_320x180_RGB565.raw - 115200
wallpaper3_320x180_320x180_RGB565.zlib - 43091
wallpaper3_320x180_320x180_RGB565.zopfli - 40692
Das schlägt sie 12 Bytes knapp. :-)
Ufuk schrieb:> Ich glaube nicht, ist ein .jpg gewesen. Soweit ich weiß können nur .png> transparente Hintergründe haben.
Siehe Deinen ersten Post:
"Validating wallpaper3_320x180_RGB565_Converted.png..."
Rudolph R. schrieb:> Siehe Deinen ersten Post:> "Validating wallpaper3_320x180_RGB565_Converted.png..."
Ja, das ist etwas verwirrend. Das war die log von EAB. Hochgeladen habe
ich eine .jpg
Und wenn ich das richtig verstehe, jagst du die .raw durch den Asset
compressor?
Muss ich gleich mal testen.
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);
da steige ich nicht wirklich durch.
Hmm, sowas habe ich noch gar nicht probiert.
Aber ja, im Grunde genommen werden die einfach übereinander gelegt.
Das mit dem Bitmap-Handle ist dabei unnötig und man muss auch nicht alle
Kommandos wiederholen:
Also was ESE da treibt ist nicht optimal, der geht das einfach Zeile für
Zeile durch ohne die vorherigen Zeilen zu berücksichtigen.
Aber das hier:
2 0x01000000 BITMAP_SOURCE(0)
3 0x29000000 BITMAP_SIZE_H(0, 0)
4 0x0803e6e0 BITMAP_SIZE(NEAREST, BORDER, BORDER, 499, 224)
5 0x28000000 BITMAP_LAYOUT_H(0, 0)
6 0x0707cce0 BITMAP_LAYOUT(ARGB1555, 998, 224)
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.
Ufuk schrieb:> 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.
Ufuk schrieb:> Hab ich das eigl. richtig gemacht?/* memory-map defines */> #define MEM_SHLI 0x0001f488 /* sh_logo linie 499x224, ARGB1555, size => 265 bytes*/> #define MEM_SHSO 0x00020488 /* sh_logo soft 499x224, ARGB1555, size => 1643 bytes*/> #define MEM_SHZA 0x00021488 /* sh_logo zahnrad 499x224, ARGB1555, size => 2885 bytes*/> #define MEM_SHHO 0x00022488 /* sh_logo horizon 499x224, ARGB1555, size => 4425 bytes*/
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.
Ja, 85% laut ESE
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.
Thread beobachten
Seitenaufteilung abschalten