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-a https://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.
Was machen in deinem Code eigentlich
1 | SPI.endTransaction(); |
2 | SPI.beginTransaction(SPISettings(8UL * 1000000UL, MSBFIRST, SPI_MODE0)); |
3 | SPI.endTransaction(); |
4 | SPI.beginTransaction(SPISettings(16UL * 1000000UL, MSBFIRST, SPI_MODE0)); |
nach TFT_init(); ?
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 | > #define MEM_FONT 0x000f7e00 /* the .xfont file for the UTF-8 font is |
3 | > copied here */
|
4 | > #define MEM_LOGO 0x000f8000 /* start-address of logo, needs 6272 bytes |
5 | > of memory */
|
6 | > #define MEM_PIC1 0x000fa000 /* 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.
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.