FT800 / FT810 Library

[Axel V. (axel-f)]

You can read out the width of a single character by:

adr_width= 0x201EE0+ (148* (font#- 16))+ character#;
char_width= FT8_memRead8(adr_width);

These are the table with the ROM font metrics. But you have to do it for 
each character. Maybe you can use it for one font and put it as const 
table into your source as Rudolph advised.

I had the same problem using a cursor. Fortunately my text are float 
numbers and all the numbers use the same width :-)

[Axel V. (axel-f)]

Die Sache mit der leichten Trübung hat sich geklärt: es war noch eine 
Schutzfolie drüber. Nun ist das Display so knackscharf, wie ich das von 
einem TFT erwarte.
Der Touch funktioniert tadellos, da bin ich zufrieden. Leider kann ich 
bestimmte Automatiken nicht nutzen, da ich dazu die Kalibrierfunktion 
aufrufen sollte, die aber durch mein Problem mit dem PCLK nichts bringt.
Es geht abe auch zu Fuß.

[Rudolph R. (rudolph)]

Kannst Du das Ergebnis nicht zum Beispiel seriell ausgeben?
Kalibrieren, ausgeben, eintragen, fertig.

FT8_cmd_dl(CMD_DLSTART);
FT8_cmd_dl(DL_CLEAR_RGB | BLACK);
FT8_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
FT8_cmd_text((FT8_HSIZE/2), (FT8_VSIZE/2), 27, FT8_OPT_CENTER, "Please tap on the dot.");
FT8_cmd_calibrate();
FT8_cmd_dl(DL_DISPLAY);
FT8_cmd_dl(CMD_SWAP);
FT8_cmd_execute();

uint32_t touch_a, touch_b, touch_c, touch_d, touch_e, touch_f;

touch_a = FT8_memRead32(REG_TOUCH_TRANSFORM_A);
touch_b = FT8_memRead32(REG_TOUCH_TRANSFORM_B);
touch_c = FT8_memRead32(REG_TOUCH_TRANSFORM_C);
touch_d = FT8_memRead32(REG_TOUCH_TRANSFORM_D);
touch_e = FT8_memRead32(REG_TOUCH_TRANSFORM_E);
touch_f = FT8_memRead32(REG_TOUCH_TRANSFORM_F);

-> serial_print

[Axel V. (axel-f)]

>FT8_cmd_calibrate();

...da bleibt bei mir der Bildschirm dunkel :-(
Und deswegen wird das nix. (Soweit ich gelesen habe, werden dabei Punkte 
auf dem Bildschirm ausgegeben, die man antatschen muß; daraus werden 
Koeffizienten berechnet.)
Macht nichts, ich arbeite drumherum...

[Rudolph R. (rudolph)]

Du könntest auch einfach meinen Code benutzen... :-)

[Johan S. (johan_s)]

Thank you Rudolph,
On the previous system I used STM32F103, now I am using STM32F407.
The compiler is Embitz, using GCC.
The problem was that this project is for a machine that moves over rough 
terrain, so I am not allowed to use the capacitive touch, also because 
of dirty hands and gloves.
Control comes from keypad and rotary encoder through canbus.
I simply had no idea how to start with this menu.
Thank you, rectangles is the answer, and then I can use contrasting 
colors to show what menu item is selected.
I was confused, because cursors are such a common need, but FT813 has no 
cursor.
It is a pity that FT813 does not return the width of written text, I 
will have to see if there is time to look up and calculate.
I cannot avoid dynamic text, it comes from the canbus, and the text 
cannot be stored and written totally later, some text comes much later.
I will use asprintf to add text for limited periods, but cannot use that 
only.
My home language is Afrikaans, I hope you can translate this.
Vielen Dank

Johan Smit

[Johan S. (johan_s)]

Thank you Axel.
I will use that code to get the width of the characters.
Best Regards
Johan Smit

[Axel V. (axel-f)]

Ja Rudolph, habe Deinen Code benutzt, aber wenn der Bildschirm dunkel 
bleibt ist nix zu wollen :-(

Irgendwas ist da wohl madig (nicht an Deinem Code- es ist mein 
PCLK-Problem). Ich werde mal am langen Wochenende mit schwerem Gerät (4 
Kanal Oszi, 500 MHz) beigehen und schauen, was das Display "zu sehen" 
kriegt. Vielleicht liegen da irgend welche Impulse 'auf Kante'.

[Axel V. (axel-f)]

Nach ein paar Messungen ist jetzt klar, daß bei mir nach der Ausgabe 
einer neuen Displaylist die R/G/B Leitungen nicht mehr angesteuert 
werden. Ironischerweise bleiben die VSYNC, HSYNC, DE und PCLK Signale 
weiter bestehen Das Timing ist exakt so, wie eingestellt und wie es zu 
dem Display paßt. Die RGB Leitungen kommen erst wieder, wenn PCLK kurz 
aus und dann wieder eingeschaltet wurde.
Das führt natürlich zu Synchronproblemen. Das konte ich dadurch lösen, 
daß ich ich vor dem Umschalten von PCLK das Interrupt Flag Register 
gelesen habe.
Irgendwas ist hier mit der State Machine der Displayansteuerung, scheint 
mir.
Die Bilder zeigen das bisherige Ergebnis. Das zweite Bild zeigt ein blau 
hinterlegtes Digit. Normalerweise blinkt das. Mit + und - kann ich die 
Stelle jetzt verstellen; mit E wird übernommen/rausgesprungen. Ich kann 
jedes Digit einzel auswählen, um schnell einen Wert zu verändern.
Damit ist es für mich jetzt auch nicht so wichtig, das die Abfrage von 
'Keys' für mich nicht nutzbar ist- dafür habe ich eine einfache 
Rechteckliste, die kurz abgefragt wird.

So, jetzt geht's erst mal mit der eigentlichen Frequenzausgabe per DDS 
weiter :-)

[Rudolph R. (rudolph)]

Johan S. schrieb:

Hello,

> On the previous system I used STM32F103, now I am using STM32F407.
> The compiler is Embitz, using GCC.

As always I would be interested in your modifications of FT8_config.h to 
add these to the repository.

> The problem was that this project is for a machine that moves over rough
> terrain, so I am not allowed to use the capacitive touch, also because
> of dirty hands and gloves.
> Control comes from keypad and rotary encoder through canbus.

Intesting.
I am working for an automotve engineering company. :-)
One of the very few things that we call products are terminals for 
harvesters and the latest have a 12" TFT with touch.
But I have nothing to do with that, these are not only developed by a 
different department but also in a different subsidary.

> It is a pity that FT813 does not return the width of written text, I
> will have to see if there is time to look up and calculate.
> I cannot avoid dynamic text, it comes from the canbus, and the text
> cannot be stored and written totally later, some text comes much later.

Well, you need to re-print every thing anyways, so you can strncat() the 
new text to the buffer.
Still you need to at least guess how long the printed line is, it won't 
wrap and start a new line.

> My home language is Afrikaans, I hope you can translate this.

As long as you do not write in Afrikaans - and that would be interesting 
to see. :-)


Axel V. schrieb:
> Das Timing ist exakt so, wie eingestellt und wie es zu
> dem Display paßt. Die RGB Leitungen kommen erst wieder, wenn PCLK kurz
> aus und dann wieder eingeschaltet wurde.
> Das führt natürlich zu Synchronproblemen. Das konte ich dadurch lösen,
> daß ich ich vor dem Umschalten von PCLK das Interrupt Flag Register
> gelesen habe.

Also sowas habe ich überhaupt noch nicht beobachtet.
Benutzt Du die Interrupts?
Ich polle das ja nur zyklisch.

[Axel V. (axel-f)]

Nein, die Interrupts benutze ich bis jetzt überhaupt nicht. Ich habe in 
meiner Verzweiflung nur etwas Mup (Methode des unbekümmerten probierens) 
gemacht; dadurch bin ich drauf gekommen.
Ansonsten schließe ich auch nicht aus, daß der FT8 mal einen Schuss 
gekriegt hat, wann auch immer. Ich habe auch schon überlegt, ins 
Bridgetek Forum zu schreiben; aber unter "Bridgtek Forum" steht nur 
"Coming soon...". Vielleicht schreibe ich Bridgetek mal direkt.
Apropos Bridgetek direkt: hast Du eventuell einen technischen 
Ansprechpartner dort?

[Rudolph R. (rudolph)]

Ist jetzt nicht so, als ob FTDI/Bridgetek irgendwie wüssten was ich 
mache, auch wenn ich denen das schon mitgeteilt habe. :-)

Ich habe mal wegen dem MediaFIFO verzweifelt ins CleoForum gepostet.
Das läuft immer noch unter cleostuff.com - ist aber quasi tot.
Und da sollte ich mich an das Support-Team unter "[e-mail]" 
wenden.
Das hat auch geklappt, lieft nur etwas zäh bis zur Lösung.

Und FTDI/Bridgetek hat bis heute nicht die Fehler im User-Manual 
beseitigt.
Hmm, Februar 2017? Das schaffen die noch.

Was man so hört steht es um FTDI gar nicht mal so gut seitdem Bridgetek 
gegründet wurde.
Also jetzt nicht geschäftlich, sondern vom Personal her in Glasgow.
Fred Dart ist wohl auch nach Singapur gegangen.
Hier gibt es zum Beispiel auch nichts zu sehen: 
http://www.ftdichip.com/Corporate/Employment.htm

Hmm, http://www.ftdicommunity.com/ ist aber da und "aktiv", gleich mal 
da anmelden. :-)

Aus meiner persönlichen ganz-weit-weg Perspektive passiert bei FTDI nix 
mehr und bei Bridgetek sieht man soweit auch praktisch keine Aktivität.

[Rudolph R. (rudolph)]

Rudolph R. schrieb:
> Hmm, http://www.ftdicommunity.com/ ist aber da und "aktiv", gleich mal
> da anmelden. :-)

Bald zwei Tage später: "Your account is still awaiting admin approval."
Als ob sich da so viele Leute anmelden würden das ein Admin damit 
überfordert wäre. Sieht eher so aus, als ob da 1/4 Admin dran sitzt, 
falls überhaupt.

[Rudolph R. (rudolph)]

Okay, I am a member of the ftdi community now.
Every single post has to be aproved by an admin though and this process 
is really slow.
That forum is mostly dead.


Something different brought me back here though.
I just checked DigiKey again and the EVE2-xxG displays from Matrix 
Oribital are finally on stock.
I am tempted to add an EVE2-70G-BLM-TPC, EVE2-50G-BLM-TPC or 
EVE2-43G-BLM-TPC to my collection. Or all of them. :-)

[Axel V. (axel-f)]

So, jetzt hab' ich es! (Heureka!)
Irgendwie hat es mir doch keine Ruhe gelassen. Und zwischendurch bin ich 
nochmal durch die Displaytimings gekrochen.
Mein Display meint hor. sichtbare und unsichtbare Pixel müßten typ. 525 
ergeben. Es dürfen aber auch bis zu 605 sein. Rechnerisch habe ich 
sichtbare 480 und unsichtbare 45 = 525. Nach dem Schema ist es auch bei 
den Vertikalen. Also habe ich das mal brav eingetragen.
Allerdings ist es richtig, MEHR bei FT8_HCYCLE und FT8_VCYCLE 
einzutragen. Und schon klappt's mit der Ausgabe. Das Display läuft jetzt 
ohne Zittern und ohne Zagen. Also falls mal jemand fragt...

[Rudolph R. (rudolph)]

Super! :-)
Allerdings ist das bei allen anderen Konfiguration auch so. :-)

Die beiden gehen ja noch, aber ich weiss noch was ich für Probleme hatte 
als ich mich mal komplett durch die Parameter wühlen musste und 
feststellen durfte, dass der Display-Hersteller und FTDI 
unterschiedliche Ansichten hatten wie was anzugeben ist...

[Rudolph (Gast)]

I bought a EVE2-50G from Matrix Digital at DigiKey.
DigiKey has the whole line of EVE2-xxG at stock right now.

And I just did a quick test with the "FT8xx_Test_90CAN_FT813_EVE2-35G" 
sample code by just changing the module to FT8_EVE2_50G in FT8_config.h.

And it just works - as expected.

It looks as nice as the EVE2-35G, only bigger with more pixels, it even 
has the exact same PCB on the back.

Now I only wish I had ordered the 4.3" as well to make my collection 
more complete. :-)

[lightcalamar (Gast)]

Hello all

Yesterday the MexSpa Team published new library for MCU's Teensy 3.5/6 
and STM32F1x, F4 and F7 boards Nucleo called GD23ZU with function 
playback videos with sound using FTDI FT81x screens.

Repository; https://github.com/FT81xMania/GD23ZU

Regards

[Rudolph R. (rudolph)]

Spammer. :-)

A little bit unfortunate but STM32 are strict no-go for me personally.
There are no automotive derivates.
And the only STM32 with CAN-FD are 400MHz/Cortex M7/100+ pin Monster 
that only have one single CAN-FD channel.

My time with 8-Bit AVR is running out fast though.

[Axel V. (axel-f)]

Aaalso, nochmal zu meinem gewesenen Problem (leider erst jetzt; mußte 
kurz in'n Urlaub):

Ja, ich hätte mir die ganzen Beispieltimings anschauen können, wenn ich 
denn eine Veranlassung dazu gehabt hätte. Dazu hätte ich noch alle 
Datenblätter gebraucht.
Irgendwie bin ich draufgekommen, als ich ein wenig in dem Datenblatt des 
kommenden FT... (BT815) geschmökert habe.
Ausgangspunkt war für mich das DS des FT812 und das DS meines Displays 
(siehe Anhänge). Fröhlich bin ich mit den typ. Timings ins Rennen 
gegangen. Prinzipiell schien das ja auch zu funktionieren. Nur das DS 
des neuen FT hat einen kleinen Zusatz: "Must be < T H - T HD". Das war 
der entscheidende Hinweis. Vielleicht ist ja der BT/FT von selbst drauf 
gekommen, das zu konkretisieren, vielleicht gab's auch ein paar 
Leserzuschriften.

[pawcuq (Gast)]

Hello hello!

I'm displaying JPEG captured by ArduCam-Mini 2 MPx on FT810 and from 
time to time LCD just hangs/freezes (sometimes it works just fine for 
2h). I think that my program on uC works fine because I also send JPEG 
to PC via UART->USB converter and after LCD hangs, images from ArduCam 
keep coming to PC application. Did anyone had simmilar problem?

Is there any way to "restart" FT810? When I use FT8_init() a second 
time, uC hangs on FT8_busy() function.

Best regards,
Paweł.

[Rudolph R. (rudolph)]

Hello,

I have to admit that I never tried to re-init before.

Just as a reference, I am using an EVE2-43G right now.
What display do you use?


I modified the main.c from my example code to call init every six 
seconds.
And it just works.

At first I let it call TFT_init() so that everything is rewritten.
The display wents dark for a fraction of a second and is back up.
Even the animation, that little pixel-star rotation, just continues as 
it should.
And touch is working as well.

Next I let it call FT8_init().
Basically the same thing, the display wents dark for a fraction of a 
second and is back up after that.
However, it does not display much anymore with my test-code, only a few 
numbers, the pictures are gone and the static part of the display-list.
Looks like memory gets wiped clean on power-down.

[Paweł P. (Firma: none) (pawcuq)]

Thanks Rudolph for your reply.

I think I found what caused problem. After looking around in Programmer 
Guide I found very interesting point - 5.6 Fault Scenarios (screenshot 
attached). After reading it I assumed that yet JPEG which I was trying 
to display on FT810 was somehow corrupted. So I wrote few lines of code 
which I call every time before displaying anything on FT810, set 
breakpoint inside condition and bingo!

uint16_t cmdBufferRead;
cmdBufferRead = FT8_memRead16(REG_CMD_READ);  /* read the graphics 
processor read pointer */

if(cmdBufferRead == 0xFFF)
{
FT8_memWrite8(REG_CPURESET, 1);        /* hold co-processor engine in 
the reset condition */
FT8_memWrite16(REG_CMD_READ, 0);      /* set REG_CMD_READ to 0 */
FT8_memWrite16(REG_CMD_WRITE, 0);      /* set REG_CMD_WRITE to 0 */
FT8_memWrite8(REG_CPURESET, 0);        /* set REG_CMD_WRITE to 0 to 
restart the co-processor engine*/
}

So if co-processor engine faults (e.g by providing FT810 with corrupted 
JPEG) code provided above restarts it without LCD going black.

Best regards,
Paweł.

[Rudolph (Gast)]

I have not put much thought into that so far, if I happen to crash the 
FT81x by feeding it corrupt data, I just stop doing that. :-)
Also that part with trying to put more than 2048 commands in the 
display-list is a bit tricky since we are using the command co-processor 
to do that with no direct relation to what we put into the command-list.

So, for overflowing the display-list, this will not help much since 
after recovery sending the same list will result in the next deadlock.

But yes, for corrupt data this should be helpfull.
The result should be that corrupt pictures are just displayed as such.
Looks like you already changed FT8_busy() for that.

I wonder about the required timing, the minimum time required to have 
coprocessor reset active and how long it takes after the reset.
And the offset into the co-processor fifo needs to be reset as well.

uint8_t FT8_busy(void)
{
  uint16_t cmdBufferRead;

  cmdBufferRead = FT8_memRead16(REG_CMD_READ);  /* read the graphics processor read pointer */

  if(cmdBufferRead == 0xFFF)
  {
    FT8_memWrite8(REG_CPURESET, 1);        /* hold co-processor engine in the reset condition */
    FT8_memWrite16(REG_CMD_READ, 0);      /* set REG_CMD_READ to 0 */
    FT8_memWrite16(REG_CMD_WRITE, 0);      /* set REG_CMD_WRITE to 0 */
    cmdOffset = 0;
    FT8_memWrite8(REG_CPURESET, 0);        /* set REG_CMD_WRITE to 0 to restart the co-processor engine*/
  }

  if(cmdOffset != cmdBufferRead)
  {
    return 1;
  }
  else
  {
    return 0;
  }
}

I have not found timing values so far but this could be missing two 
delay() calls.

[Paweł P. (Firma: none) (pawcuq)]

Good points Rudolph, thanks!

[Rudolph R. (rudolph)]

I just uploaded a new FT8_commands.c to my Github repository after 
conducting a little test.

I destroyed my test-png by commenting out a couple of lines.
And with the the fault-detection code in place it still comes up fine 
and displays and roates the corrupted image.
Without the additional lines the display stays black.

Thank you, that makes it a bit more robust!

[Rudolph R. (rudolph)]

https://github.com/RudolphRiedel/FT800-FT813

I just added several modules from Riverdi to the timings, that should be 
complete now.

[Guido G. (Firma: privat) (guigra)]

Ich spiele z.Zeit mit meinem FT811CB von Haoyu und meinem 86duino Zero 
herum.
Als Programmierumgebung benutze die ArduinoIDE welche vom Hersteller 
angepasst wurde.Bisher habe ich mit dem Screendesigner meine Anzeigen 
gebastelt und dann mühselig abgetippt.Bei der suche nach einer 
einfacheren
Lösung habe ich mir die Bibliothek von rudolph angesehen und 
getestet.Sie funktionierte ohne große Änderungen.Aktuell habe ich 
folgendes Problem :
Wenn in meinem Sketch z.B folgendes steht cmd_dl(BEGIN | POINTS); ist 
alles gut.
Jedoch bei z.B cmd_dl(VERTEX2F(10*16,100*16)); gibt es folgende 
Fehlermeldung error: expression can not be used as a function

Was genau hat den diese Meldung zu bedeuten?

Guido

[Rudolph R. (rudolph)]

Guido G. schrieb:
> Sie funktionierte ohne große Änderungen.

Was heisst das? Eigentlich funkioniert das ohne Änderungen. :-)
Ich habe gerade mal ein Arduino Projekt auf den aktuellsten Stand 
gebracht und das compiliert ohne Warnungen durch.

Versuch mal bitte ein minimales Projekt aufzustellen mit dem der Fehler 
auftritt, muss ja nicht mal was sinnvolles machen, und das poste dann 
mal.

[Guido G. (Firma: privat) (guigra)]

Rudolph R. schrieb:
> Was heisst das? Eigentlich funkioniert das ohne Änderungen. :-)

Mit kleinen Änderungen meinte ich die SPI Kommunikation in den Befehlen 
zwischen meinem 86duino Zero und meinem FT811CB Display.Da das 86duino 
Zero einen x86 SoC besitzt und ich SPI Bibliothek der angepasste Arduino 
IDE verwende war das nötig. Ansonsten konnte ich alles verwenden wie du 
es programmiert hast. Was ich noch gemacht habe ist das FT800_ von den 
Befehlen zu entfernen und alles in eve.cpp und eve.h zusammengefasst.Mir 
persönlich gefällt cmd_text(..) besser als FT800_cmd_text(..), aber das 
ist Ansichtssache. Als Anhang mal ein Bild das Board und Display mit 
einer einfachen Uhr zeigt.Ebenso den unsauberen Code und eve.cpp sowie 
eve.h Dateien.Wo ich etwas verwirrt bin ist das im Code von Anzeige_1 
nichts auf dem Display erscheint aber mit der alten Methode in Anzeige_2 
die Uhr angezeigt wird.Habe ich da was durcheinander gebracht oder etwas 
vergessen?
Wie man sieht ist Anzeige_2 sehr aufwendig und das möchte vermeiden.

Guido

[Rudolph R. (rudolph)]

Hust, das sind keine kleinen Änderungen.
Und wenn Du Dich ein wenig damit beschäftigt hättest wäre Dir auch 
aufgefallen, dass das mit der SPI Kommunikation komplett sinnfrei war.
Damit hast Du nur die Portierbarkeit gekillt ohne was zu gewinnen.

Steht Dir ja frei das komplett auf den Kopf zu stellen, kein Problem.
Nur ernsthaft supporten kann ich das so nicht.

Und dann fehlt da auch noch erheblich was.
Zum Beispiel die .ino die daraus ein Projekt macht mit dem der Fehler 
auftritt und in dem sich dann vielleicht auch die Initialisierung des 
Displays finden lässt.

Da Du den FT800_ Prefix angesprochen hast, mit dem nächsten Release den 
ich dann als 4.x markiere habe ich vor das auf EVE_ zu ändern.
Das ist auch nicht viel schöner, aber wenigstens wieder mit den 
BT815/BT816 kompatibel, zu denen es ja leider immer noch nicht mal ein 
Datenblatt gibt ("Available June 2018" ...), geschweige denn kaufbare 
Module.
Und wenn es dann in der fernen Zukunft kein EVE3 gibt, sondern äh, UTE 
als Nachfolger, tja. :-)

[Guido G. (Firma: privat) (guigra)]

Da ist was schief gelaufen.Ich hatte ja geschrieben das ich auch den 
unsauberen Code mit liefern wollte.Wird hiermit getan.Ich weise nochmal
darauf hin das ich nicht mit einem ATmega und der orginalen Arduino IDE
arbeite sondern mit einem 86duino Zero (x86 SoC) und einer durch den 
Boardhersteller veränderten Arduino IDE.Die SPI Kommunikation 
funktioniert nicht wie beim echten Arduino. zb spi_transmit oder 
spi_receive gibt es dort nicht.

Guido

[Rudolph (Gast)]

Also ich bin ja schon neugierig.
Also habe ich mir mal 86Duino_Coding_316_WIN.zip gezogen, die drei 
Dateien in ein Verzeichnis geworfen, das Include für eve.h von <eve.h> 
auf "eve.h" geändert als Board "86Duino One" eingestellt und 
"Überprüfen" gedrückt.

Das gibt zwar Null Ausgabe, keine Warnungen, keine Größe, gar nichts, 
das compiliert aber auch erstmal einfach so durch.


Fürchterlicher Sketch übrigens. :-)
Vor allem Anzeige_2().

>wr16(REG_VSIZE, 0xE001);

Hmm? Deine wr16 Funktion hat die Byte-Reihenfolge vertauscht.
wr32() ist aber richtig.
rd16() das gleiche Spiel, aber rd32() passt.

[Guido G. (Firma: privat) (guigra)]

Vielen dank für den Hinweis das in rd16 und wr16 die Daten vertauscht 
waren.
Das habe ich berichtigt.Nun lassen sich auch die Startwerte für das 
Display ordentlich lesen.Ich hatte ja die drei Metacommandos aus der 
eve.h und eve.cpp entfernt so das es durch kompiliert wird.Ich hänge mal 
die beiden Dateien mit den Meatcommandos an.Die Kompilieren nicht 
durch.Kannst du dir das bitte mal ansehen ich werde daraus nicht schlau.

Guido

[Rudolph (Gast)]

Also nachdem ich erst mal die ganzen offensichtlichen Fehler beseititg 
habe wie FT8_POINTS in POINTS geändert oder inc_cmdoffset() in 
inc_cmdOffset(), kompiliert das einfach so durch.

Wenn es nur um die Meta-Kommandos geht, die sind eh mit Vorsicht zu 
geniessen. Die Bequemlichkeit kostet wertvollen Platz in der 
Display-Liste.
Werden fünf Linien gezeichnet benötigt man das BEGIN/END Paar nur einmal 
und auch die Breite eher nur einmal.
Grob überschlagen kann man mit dem Meta-Kommando 400 Linien malen, ohne 
sind es 1000 gleicher Dicke und so 650 wenn alle unterschiedlich breit 
sind.

[Guido G. (Firma: privat) (guigra)]

Als Hobby befasse ich mich mit der Astronomie und habe 2 Teleskope mit 
elektronischer Nachführung.Da die Handsteuerungen nicht so das wahre 
sind, habe ich beschlossen die Steuerung selbst zu programmieren und mit 
einer besseren Grafikausgabe zu versehen. Ebenso soll durch ein Lifebild 
die Nachführung optisch überwacht werden.Dazu ist EVE genau das 
richtige. Die Metacommandos werde ich wieder entfernen und nun mit der 
Planung der Menüs beginnen um eine sinnvolle Steuerung zu erhalten.Das 
ein Haufen Arbeit aber es lohnt sich. Noch einmal vielen Dank für deine 
Hilfe.

Guido

[Axel V. (axel-f)]

Hat jemand einen guten Plan, wie man Icons auf einfache Weise in den 
Code bringt?
Rudolph, in Deinen Beispielprogrammen hast Du die tausende Bilddaten 
sicher auch nicht abgetippselt, oder?

Axel

[Rudolph R. (rudolph)]

Icons sind ja eher monochrom und man will die ohne Verluste komprimmiert 
haben, da nehme ich das Imageconvert Tool von FTDI/BRT.
Für .jpg nehme ich dann zum Beispiel Hex-Edit, Binär laden und als 
Source-Code exportieren.

Das stelle ich mir mit den kommenden BT815/BT816 echt entspannt vor.
Per USB/SPI Adapter an den Rechner anschliessen und das externe Flash 
auf dem Display voll machen. :-)
Wird sich dann noch zeigen, wie die Software dazu am Rechner aussieht 
und wie man da die Informationen raus bekommt, was jetzt wo liegt im 
Speicher.
Aber so 8 MegByte bis 128 oder so extern per QSPI transparent am 
Grafik-Chip angebunden zu haben klingt echt praktisch. :-)

[Axel V. (axel-f)]

Ah, gut, habe jetzt mal auf der Tool Seite von FTDI nachgeschaut.
Gibt's da was verwertbares auch für Linux?

Kann ich die Daten einmal in RAM_G spielen und dann immer wieder drauf 
zugreifen? Oder müssen die in jedem Zyklus neu übergeben werden?

Rudolph, hast Du mal was mit eigenen Fonts gemacht? Also TTF konvertiert 
und eingespielt?

Gruß
Axel

[Rudolph R. (rudolph)]

Für Linux sieht das vermutlich dünn aus, aber da das alles nur 
Shell-Tools sind, lässt sich bestimmt was mit Wine oder wie auch immer 
drehen.

Das wird alles nur einmal geladen und nur noch benutzt.
Mit den BT815/BT816 wird sogar das Laden entfallen, also durch den 
Controller beim Starten des Programms.

Fonts habe ich bisher noch nicht probiert, die FT8xx sind da ja sehr 
üppig ausgestattet ab Werk.
Einzig die Beschränkung auf 128 Zeichen pro Font finde ich etwas 
schwach, da kommt man aber mit einem eigenen Font auch nicht drum herum.
Oder zumindest glaube ich, dass es so ist, angesehen habe ich mir das 
noch nicht so genau.
Gelegentlich fehlen mir mal die Umlaute.

[Axel V. (axel-f)]

Über die Kommandozeile funktioniert es aus dem Stand.
Was mich jetzt wundert: das angehängte Icon wird so umgewandelt, daß der 
weiße Aussenrand schwarz wird und der schwarze Innenteil transparent. 
Das kommt mir prinzipiell entgegen, aber woher weiß das Progrämmchen, 
was für  mich gut ist? So schlaue Programme machen mir Angst!

[Rudolph R. (rudolph)]

Eventuell weil das .png ist? So mit Alpha-Channel?

[Axel V. (axel-f)]

Naja, das angehängte png scheint kein Alpha zu haben, weil es mit L2 
Parameter funktioniert hat. Später habe ich dann mit meinen 
selbstgebauten Icons Probleme bekommen. Wegen Alpha. Da bin ich bei der 
Konvertierung auf ARGB2 gewechselt, sonst kam nur Müll raus. Aber ich 
glaube, jetzt hab ich's :-)

[Guido G. (Firma: privat) (guigra)]

Hi rudolph,

bevor ich mit der Programmierung meiner Steuerung beginnen wollte, habe 
ich ein paar Test mit dem Display gemacht.Leider hat mir die eve.h und 
eve.cpp einen Strich durch die Rechnung gemacht.Im Sketch sind 3 
Anzeigen eingehackt welche den extrem langen Weg zur Uhr zeigen, der 
zweite sollte das Logo anzeigen und der dritte zeigt einfach Beispiel 
primitiver Grafik aus dem Datenblatt. Wenn Anzeige2 dargestellt werden 
soll bleibt der Schirm schwarz.Wie kann ich das Display überreden auch 
Anzeige2 zu präsentieren?

Guido

[Rudolph (Gast)]

Tja, wenn Du meine Library verwenden würdest anstatt das alles noch mal 
zu verändern, dann könnte ich das mit minimalen Anpassungen einfach mal 
testen.

So bekomme ich das nicht mal compiliert:


EVE_one.ino: In function 'void eve_init()':

EVE_one:38: error: 'CLKEXT' was not declared in this scope

EVE_one:39: error: 'ACTIVE' was not declared in this scope

EVE_one.ino: In function 'void Anzeige_2()':

EVE_one:131: error: 'dl' was not declared in this scope

EVE_one:135: error: 'cmd_show' was not declared in this scope

EVE_one.ino: In function 'void Anzeige_3()':

EVE_one:142: error: 'dl' was not declared in this scope

EVE_one:155: error: 'cmd_show' was not declared in this scope

exit status 1
'CLKEXT' was not declared in this scope


Wer bitteschön soll sich die Arbeit machen um das hier zu dekodieren?

void Anzeige_1()
{
   wr32(RAM_DL +  0, 0x26000007);
  wr32(RAM_DL +  4, 0x02000000);
  wr32(RAM_DL +  8, 0x1f000002);
  wr32(RAM_DL + 12, 0x22000000);
  wr32(RAM_DL + 16, 0x27000002);
  wr32(RAM_DL + 20, 0x0d000320);
  wr32(RAM_DL + 24, 0x04002040);

Anzeige 2:

void Anzeige_2()
{
   dli = 0;
   dl(CMD_DLSTART);
   dl(CLEAR(1,1,1));
   cmd_logo();
   dl(DISPLAY()); // display the image
   cmd_show();
   cmd_execute();
}

Mit cmd_logo() spielt man das animierte Logo von FTDI ab, wer ausser 
FTDI will sowas sehen? :-)
Die Funktion cmd_show() ist nicht in der eve.cpp enthalten, soll das 
vielleicht cmd_swap() sein?

[Guido G. (Firma: privat) (guigra)]

Hi rudolph,

leider habe ich die falschen Projektdateien hochgeladen.Ich möchte mich 
dafür entschuldigen.Nun folgen die richtigen denen es auch durch 
kompiliert.
Bitte wieder dran denken kein ATmega.

Rudolph schrieb:
> Mit cmd_logo() spielt man das animierte Logo von FTDI ab, wer ausser
> FTDI will sowas sehen? :-)

Ich als Test. :-)

Rudolph schrieb:
> Die Funktion cmd_show() ist nicht in der eve.cpp enthalten, soll das
> vielleicht cmd_swap() sein?

Kannst du auch nicht, weil du leider die falschen Dateien bekommen hast. 
:-(

Guido

[Rudolph (Gast)]

Ich habe das mit der 86Duino IDE compiliert, und jetzt läuft das auch 
durch.

Dann habe ich die Sequenz mal eben in meine Test-Software übertragen:

FT8_cmd_dl(CMD_DLSTART); /* start the display list */
FT8_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
FT8_cmd_dl(CMD_LOGO);
FT8_cmd_dl(DL_DISPLAY);
FT8_cmd_dl(CMD_SWAP); /* make this list active */
FT8_cmd_execute();

while(1);

Und läuft.

Schau mal, was Dein cmd_show() anders macht als mein 
FT8_cmd_dl(CMD_SWAP).
Fällt Dir da irgendwas dran auf? :-)

[Guido G. (Firma: privat) (guigra)]

Rudolph schrieb:
> Schau mal, was Dein cmd_show() anders macht als mein
> FT8_cmd_dl(CMD_SWAP).
> Fällt Dir da irgendwas dran auf? :-)

hi rudolph,


ja, du rufst das Kommando auf und ich habe direkt in das Register 
REG_DLSWAP geschrieben. Das Kommando ist einfacher zu lesen als mein 
Registerzugriff, beide tun aber dennoch das selbe.Meine Methode ist 
nicht ganz ungefährlich denn die Werte 0 und 3 dürfen nicht ins Register 
geschrieben werden.

Ich konnte das LOGO jetzt anzeigen.

Guido

[Rudolph R. (rudolph)]

Der Unterschied ist, dadurch das Deine Funktion direkt in das Register 
schreibt, wechselst Du die Display-Liste, bevor überhaupt eine neue 
erzeugt wird.
In meiner Version als Co-Prozessor Kommando landet das im Co-Pro FIFO 
und wird mit dem cmd_execute() erst ausgeführt wenn alles andere bereits 
ausgeführt ist.
Machen tun die beiden das gleiche, wenn auch einmal direkt und einmal 
mit dem Co-Pro.

Also sowas wie:

   dl(DISPLAY()); // display the image
   cmd_execute();
busy()...
  cmd_show();

Wäre mit Deiner Funktion korrekt.

[Guido G. (Firma: privat) (guigra)]

hi rudolph,

Rudolph schrieb:
> Dann habe ich die Sequenz mal eben in meine Test-Software übertragen:

hast du dir extra ein Testprogramm entwickelt um solche Probleme, wie 
z.B. meine, mit den FT8xx Bausteinen zu testen?

guido

[Rudolph R. (rudolph)]

Guido G. schrieb:
> hast du dir extra ein Testprogramm entwickelt um solche Probleme, wie
> z.B. meine, mit den FT8xx Bausteinen zu testen?

Na, in das hier zum Beispiel:
https://github.com/RudolphRiedel/FT800-FT813/tree/master/example_projects/FT8xx_Test_90CAN_FT813_EVE2-35G

Da kann ich doch nach Belieben einbauen was mir gerade in den Kram 
passt.
Wo konkret, ist dann immer eine Frage des Problems.
In dem Fall habe ich das am Ende der TFT_init() Funktion eingebaut.

Der Witz für mich ist nur, dass ich mich darauf verlassen kann, dass die 
Software grundsätzlich funktioniert und auch mit allen Displays aus 
meiner Sammlung.
Für den Test habe ich jetzt kurz mal ein EVE2-43G angeschlossen.

[Guido G. (Firma: privat) (guigra)]

Ich habe mir mal deinen Link und die Dateien angesehen und kann sagen 
Respekt.Du hast mit diesem Code eine Universalität erreicht wie ich es 
selten gesehen habe.Das ist übersichtlich und leicht verständlich 
programmiert und  es ist eine beachtliche Anzahl von Daten für Displays 
zusammen gekommen, wie eine Datenbank.

Guido

[Rudolph R. (rudolph)]

Danke, das hat etwas Aufwand und ein paar Schleifen gekostet, das so 
einfach hinzubekommen. :-)
Aber ein paar hässliche Ecken gibt es noch.

DMA wird auch noch lustig.

[Nico N. (occino)]

Hallo zusammen,

ich hätte mal eine grundlegende Frage zum G-Ram. Meiner Einschätzug nach 
ist dieser mit 1 MB ( = 1024 * 1024 kByte = 1048576 Byte) sehr schmal 
dimensioniert.

Ein Jpeg mit 800x480 würde nach dem Dekodieren 768000 Byte (800x480 * 2 
Byte) belegen (73,2%).
Möchte man nun ein weiteres Bild anzeigen (z.B. in einer Diashow), wäre 
Double Buffering nicht möglich und man müsste den Speicherbereich des 
ersten Bildes überschreiben.
Da der FT8xx kontinuierlich refresht, würde sich kurzzeitig die 
Situation ergeben, dass ein Teil des ersten Bildes zusehen ist und an 
einem Pixel x vom zweiten Bild vorgefürt wird (tearing Effekt).
Bei einer schnellen SPI Übertragung wäre der Effekt zwar weniger doll 
sichtbar, aber immer noch da.

Habe ich vielleicht etwas falsch verstanden oder gibt es geschicktere 
Strategien beim Speichermanagement? Eine Synchronisation mit dem 
automatischen refresh könnte auch helfen, aber dazu steht in den 
Datenblättern nichts.

Viele Grüße und danke im Voraus für jeden Hinweis,
Nico

[Rudolph R. (rudolph)]

Du hast völlig Recht, der Speicher reicht nicht aus um mehr als ein 
Vollbild anzuzeigen bei 800x480 oder gar 800x600.
Ich kann nur spekulieren, dass die FT8xx schlicht weg nicht für so eine 
Anwendung gedacht sind.
Die Stärke von den Dinger liegt ziemlich eindeutig im Bereich 
Mensch-Maschine-Interface mit wenig notwendigen Resourcen beim 
Host-Controller.
Viele kleine Objekte dynamisch kombinieren.

Ein Weg da raus für eine Diashow wäre kleinere Bilder darzustellen, 
entweder mit Rahmen drum herum, oder aber hoch-skaliert.

Wenn es die BT815/BT816 mal irgendwann geben sollte, FTDI meint gegen 
des Jahres, dann könnte deren Unterstützung für ASTC (Adaptive Scalable 
Texture Compression) zum einen und vor allem die Anbindung eines 
externen NOR FLASH mit Leichtigkeit Diashows erlauben.
Bilder können wohl direkt on-the-fly im ASTC Format aus dem FLASH 
geladen werden, das geht dann so in die Richtung xx Mega-Byte, je 
nachdem was wirklich bestück wird.
Ich hoffe nur, dass es auch ein Programm von FTDI dazu geben wird um den 
FLASH per Rechner zu betanken und zu verwalten, also mit Ausgabe einer 
Memory-Map und automatischer ASTC Konvertierung von Bildern.
So per USB<->SPI Interface.
Etliche Mega-Byte durch einen Controller mit einigen kB FLASH zu tunneln 
dürfte sonst etwas sehr nervig sein.

[Paweł P. (Firma: none) (pawcuq)]

BT815/BT816 are now available - 
https://pl.mouser.com/new/bridgetek/ftdi-bt815-bt816/!

Datasheet - 
https://pl.mouser.com/catalog/specsheets/Bridgetek_09252018_BT815Q-R.pdf

Programming guide - 
https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/BRT_AN_033_BT81X_Series_Programming_Guide.pdf

:)

[Rudolph R. (rudolph)]

Paweł P. schrieb:
> BT815/BT816 are now available

Thanks, I somehow missed the release.

There also is a new FT81x Series Programmers Guide:
http://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/FT81X_Series_Programmer_Guide.pdf

[Rudolph R. (rudolph)]

And they have a new tool for all the files as well:
https://brtchip.com/utilities/#EVEAssetManager

[Rudolph R. (rudolph)]

I had a peek at the user-manual for the BT815/BT816 now and from what I 
have seen I will most definately support these in a future release.

But I have to get my hands on a display with BT81x first, preferably 
BT815.

[Rudolph R. (rudolph)]

While still waiting for a BT815 module I started to move towards 4.x.
I changed all the prefixes from FT8_ to EVE_.
I only hope that this sticks now. :-)

I also uploaded a quick and rough conversion of my example code to the 
ATSAMC21E18A.
For now still with software-spi und untested since the board I am 
working with died earlier this evening and needs the controller 
replaced.
But at least it compiles just fine.

https://github.com/RudolphRiedel/FT800-FT813/tree/4.x

Have fun.

[Johann S. (Gast)]

Hi Rudolph,

erstmal Lob für deine Arbeit hier, ich wünschte ich hätte diesen Beitrag 
viel früher wahrgenommen. Das hätte mir viel rumärgere mit den 
originalen Datenblättern/Samples erspart.

Ich hätte eine Frage, bzw. Problem dass vielleicht jemand hier bereits 
einmal beobachtet haben könnte:
Aktuell habe ich einen FT811 mit einem Riverdi 3.5" mit kapazitiven 
Touch im Betrieb. Der Ablauf meiner SW ist grundsätzlich gleich mit 
deiner (loop: -getTag-10ms-Bildaufbau(falls nötig)-10ms-) mit den selben 
Kommandos am FTDI.
mein Problem ist, dass vereinzelt(grob geschätzt 1x bei 50 Touch, jedoch 
nicht gezielt reproduzierbar) ein TAG weiterhin erkannt wird, obwohl ich 
den Finger bereits wegnahm.
D.h. nach neuem Displayabdeckung wird der TAG welcher sich an der 
Position weiterhin erkannt(auch bei neuen Screen/TAG-Nummern )

Ist das Phänomen zufällig auch schon mal aufgetreten, bzw. gibt es dafür 
vielleicht eine simple Ursache, wie sich das beheben lässt?

[Rudolph R. (rudolph)]

Okay, das Riverdi 3.5" habe ich nicht, bisher habe ich von Riverdi 
eigentlich nur die RVT70 benutzt, dafür aber schon ein paar mehr davon.
Die sind auch mit kapazitiv Touch und bisher ist da weder mir noch den 
Kollegen sowas in der Art aufgefallen.

Ich finde bei Riverdi aber auch gar kein 3.5" mit FT811, da werden nur 
RVT3.5B320240CFWC81 und RVT3.5B320240CNWC81 gelistet und die haben beide 
nur einen FT801 drauf.
Alle Module unter 5" haben nur FT80x, sonst hätte ich so eines 
vielleicht auch. :-)

Kannst Du das vielleicht auf einen Test-Code reduzieren mit dem das 
reproduzierbar ist?
Ich hätte ein EVE2-35G zum Testen.

[Paweł P. (Firma: none) (pawcuq)]

Hello,

is there a way to resize (using FT8 commands) 1600x1200 JPEG and display 
it on 800x600 LCD driven by FT810?

Best regards,
Paweł.

[Rudolph R. (rudolph)]

While you can scale images up and down with transformations they still 
need to fit into the memory first.
So, no, I do not see a way to scale .jpg images larger than 800x600 down 
inside a FT8xx to fit the screen.
And the BT81x do not change that either since you can not display .jpg 
directly without unpacking these first.

[Paweł P. (Firma: none) (pawcuq)]

I thought that there's maybe some trick to do that ;/
Thanks for answer Rudolph!

[Joern DK7JB .. (moin)]

Hallo Rufolf,
ich hätte einige Fragen zu deinen Erfahrungen mit unterschiedlichen 
Displays mit dem FT8xx

Welches 5'' oder 7'' Display/Modul mit einem kapazitiven FT8xx
Touch-Controller würdest du empfehlen? Wie gut ist die Ablesbarkeit?
Gibt es sonstige Unterschiede?
Ich schwanke momentan zwischen:
- RVT70UQFNWC00
- RVT70AQFFWC00
Wie baut man am besten den RVT70UQFNWC00 in eine Frontplatte? Muss man 
sich dann eine Frontplatte fräsen lassen, bei der der sichtbare Bereich 
des Displays ausgefräst ist und dann das Display irgendwie von hinten 
befestigen?
Beim RVT70AQFFWC00 gefällt mir die äußere Abdeckung mit dem kapazitivem 
Touch. Kann man bei Platzmangel diese äußere Abdeckung kleiner fräsen 
oder besteht sie aus Glas?

Dann habe ich bei Mouser/DigiKey noch folgende Display gefunden:
EVE2-70G-TPC   Matrix Orbital
NHD-7.0-800480FT-CSXV-CTP (mit einem angeblich sehr gutem Display)
Vielleicht ist dieses Display doch meine erste Wahl.
Bei watterott habe ich noch ein günstiges 5‘‘ Display gefunden, kann 
aber nicht abschätzen ob es was taugt:
https://www.watterott.com/de/5-800x480-Display-mit-kapazitivem-Touchscreen-FT811CB-HY50HD


Ich habe mir vor gut drei Jahren das FT800 Display mit einem resistiven 
Touch-Controller VM800B50A-PL  gekauft um eine grafische Bedieneinheit 
für einen selbstgebauten Amateurfunkempfänger zu ertstellen. Mit der 
Displayqualität und dem Bedienkomfort war ich eigentlich noch nie
zufrieden gewesen. Viel zu blass und der resistive Touch hat mich auch 
nie zufrieden gestellt.

Damit du mich etwas besser einschätzen kannst. Ich habe von rund 15 
Jahren die ATMegas kennengelernt. Zu Anfang mit Assembler und dann mit 
Bascom. Dann bin ich zu LunaAVR gewechselt. Am PC programmiere ich in 
VB.net. Über die Jahre habe ich für unterschiedliche Projekte mich mit 
den einzelnen Bereichen der ATMegas beschäftigt und meine die Hardware
gut zu kennen. Die Sprache C kann ich leidlich lesen aber programmiert 
habe ich in ihr noch nie.
Für das genannte Empfängerprojekt werde ich in der nächsten Zeit die 
Bedieneinheit neu programmieren. Auch überlege ich mich nun mit C oder 
C++ zu beschäftigen und sie endlich zu lernen und such gerade nach dem 
richtigen Weg. Da ich schon in vb.net programmiert habe sollte der 
Umstieg hoffentlich nicht allzu schwer sein. Hierzu sollte ich 
vielleicht besser meine Fragen wohl besser in einem eigenem Thead hier 
im Forum stellen.

Grüße Jörn

[Rudolph R. (rudolph)]

>Welches 5'' oder 7'' Display/Modul mit einem kapazitiven FT8xx
>Touch-Controller würdest du empfehlen?

Im Moment sind meine Favoriten die EVE2 Serie von Matrix Orbital, vor 
allem die EVE2-xxG.

>Wie gut ist die Ablesbarkeit?

Schon sehr gut, aber das sind alles "nur" TFTs und keine AMOLED: :-)

>Gibt es sonstige Unterschiede?

Ja, zwischen allen Herstellern sind ein ein paar Details 
unterschiedlich.

>Ich schwanke momentan zwischen:
>- RVT70UQFNWC00
>- RVT70AQFFWC00
>Wie baut man am besten den RVT70UQFNWC00 in eine Frontplatte?
>Muss man sich dann eine Frontplatte fräsen lassen, bei der der sichtbare Bereich
>des Displays ausgefräst ist und dann das Display irgendwie von hinten befestigen?
>Beim RVT70AQFFWC00 gefällt mir die äußere Abdeckung mit dem kapazitivem
>Touch. Kann man bei Platzmangel diese äußere Abdeckung kleiner fräsen oder 
besteht sie aus Glas?

Ah, Du hast sie verdreht, das UQ ist das mit der Glasfront.
Für das RVT70AQFFWC00 braucht man ein Gehäuse wie von einem Monitor,
also einen Rahmen der kleiner ist als das Display und ein Teil welches 
das Display von hinten gegen den Rahmen presst.
Beim UQ und bei den EVE2-xxG ist die komplette Front eine Glasscheibe 
und das Display wird von vorne in das Gehäuse eingesetzt, genau wie bei 
einem Tablett oder Smartphone.
Sowohl die von Riverdi als auch die von Matrix Orbital kommen 
vorbereitet mit doppelseitigem Klebeband.

Ein 3D-Drucker ist für beide Varianten hilfreich, wenn man Gehäuse von 
der Stange nimmt sind die Typen mit der Glasscheibe aber auf jeden Fall 
leichter sauber zu verarbeiten.
Für das EVE2-.70G designe ich gerade so eine Art Tablett-Gehäuse, wenn 
man das in der Hand hält ist der breite Rand dann auch nicht wirklich 
störend, weil man Platz hat für den Daumen ohne was zu touchen.

>Dann habe ich bei Mouser/DigiKey noch folgende Display gefunden:
>EVE2-70G-TPC   Matrix Orbital

So eines liegt hier auch schon für mein nächstes Projekt auf der Arbeit 
im Frühjahr.

>NHD-7.0-800480FT-CSXV-CTP (mit einem angeblich sehr gutem Display)

So eines habe ich noch nicht ausprobiert.
Ich habe ein NHD-3.5-320240FT-CSXV-CTP  und während das Panel schon 
schick ist, Premium und so,
die haben da einen 1.0 mm Folien-Leiter dran gemacht und das passt mir 
gar nicht in den Kram.

>Bei watterott habe ich noch ein günstiges 5‘‘ Display gefunden, kann aber nicht 
abschätzen ob es was taugt:
>https://www.watterott.com/de/5-800x480-Display-mit-kapazitivem-Touchscreen-FT811CB-HY50HD

Das ist nicht so prall, die Oberfläche ist eher so "milchig" wie bei 
einem resistiven Display.
Es ist wirklich preiswert, der Rahmen drum herum ist ganz witzig gemacht 
und im Gegensatz zu den Displays
von Matrix Orbital, Riverdi und Newhaven hat das einen Level-Shifter 
drauf, funktioniert also direkt auch mit 5V.

>Ich habe mir vor gut drei Jahren das FT800 Display mit einem resistiven 
Touch-Controller VM800B50A-PL  gekauft um
>eine grafische Bedieneinheit für einen selbstgebauten Amateurfunkempfänger zu 
ertstellen.
>Mit der Displayqualität und dem Bedienkomfort war ich eigentlich noch nie 
zufrieden.
>Viel zu blass und der resistive Touch hat mich auch nie zufrieden gestellt.

Ja, mein erstes VM800B35A liegt auch nur noch rum.
Bedienen muss man die Dinger im Grunde genommen mit einem Stift.

Die Parameter müsste man mal in eine Tabelle kippen um das zu 
vergleichen.

Betrachtungswinkel zum Beispiel, das NHD ist mit 70/70/70/70 angegeben,
das Riverdi mit 50/70/70/70 und das Matrix Orbital mit 70/60/70/70.

Also beim NHD macht es keinen Unterschied wie herum man das hält, beim 
Riverdi macht es schon Sinn
das Ding je nach Einbau-Ort verschieden herum zu montieren.

Wobei man sagen muss, die sind auch ausserhalb der Winkel ablesbar, das 
sind die Winkel ab denen die Farben kräftig leiden.

Dann die elektrische Schnittstelle.
Das Haoyu ist das einzige das mit Single-Supply 5V auskommt, so ziemlich 
wie die Module von FTDI.
Beim Riverdi und NHD kann man die Hintergrund-Beleuchtung mit 5V 
speisen, Logik-Supply und Pegel sind 3,3V.
Die Matrix Orbital haben die Logik-Versorgung und 
Hintergrund-Beleuchtung intern zusammen, wenn auch aussen auf zwei Pins, 
da kann man nur 3,3V benutzen, Logik-Pegel ebenfalls 3,3V.
Haoyu hat einen 12Pin FFC.
Riverdi, Matrix-Orbital und NHD nutzen 20Pin mit fast identischer 
Belegung.
Nur haben Riverdi und Matrix-Orbital 0,5mm Leitungen und NHD 1.0 mm.
Wobei NHD auch einen fetten Pfosten-Stecker spendiert.

Strom für die 3,3V Logik sind so bis 150mA, das gilt wenn alle Pixel 
schwarz sind, ein weisser Hintergrund ist also günstiger für die 
Versorgung.
Das RVT70UQ benötigt bis 540mA bei 5V für das Backlight.
Das EVE2-70G müsste so bei 470mA bei 3,3V liegen.
Und das NHD ist mit 760mA/3,3V und 440mA/5V angegeben.
Ich fahre die aber nicht bei voller Helligkeit, bei 80% ist das schon 
ziemlich grell.

Also den Strom zur Verfügung zu stellen ist schon nicht ganz lustig.
Ich habe zum Beispiel gerade bemerkt das mir mein Step-Down Wandler die 
Eingangs-Spannung so sehr verseucht das ich die nicht mehr per ADC und 
Spannungsteiler messen kann.
Da ich beruflich im Automotive Bereich unterwegs bin müssen meine 
Schaltungen mit 12...14V nominell klar kommen, der Unterschied zu 3,3V 
ist schon ganz ordentlich und der Strom ist schon ziemlich heftig.

Abschliessend ist noch zu sagen das gerade die BT815 Displays überall in 
Vorbereitung sind, EVE3.
Die Dinger werden den Vorteil haben das da ein SPI-FLASH von mindestens 
64MBit mit an Board sein wird.
Also die nächste Generation steht schon in den Startlöchern.

[Joern DK7JB .. (moin)]

Nun sind eigentlich nur doch diese beiden Displays für mein 
Selbstbau-Empfänger im Rennen:

RVT70AQFFWC00
Vorteil: Die Glasabdeckung scheint wirklich gut auszusehen und lässt 
sich komfortabel einbauen.
Nachteil: Die Außenmaße sind bei meinem aktuellen Projekt 3 mm zu groß 
(Höhe). Da muss entweder der äußere Rahmen der Frontplatte abgefräst 
werden oder ich muss doch zu dem anderen Display greifen.
Kann man dieses Display überhaupt wieder entfernen, wenn man die 
Frontplatte austauschen möchte?

NHD-7.0-800480FT-CSXV-CTP
Vorteil: Die Abbildungsqualität scheint wohl wirklich gut zu sein. Das 
Display kann leichter getauscht werden, wenn die Frontplatte des Gerätes 
gewechselt wird (Entwicklungsphase)
Nachteil: Hier muss die Frontplatte gefräst werden, damit nur der aktive 
Displaybereich zu sehen ist. Die Befestigung ist dann auch nicht so 
einfach. Vermutlich muss dann von hinten mit Metallkleber eine 
selbstgebaute Halterung auf die gefräste Frontplatte aufgeklebt werden. 
(Das mit dem Metallkleber muss ich mal ausprobieren)
Gut gefällt mir der Wannenstecker für ein Adapterboard und die 3,3V 
Versorgung (normaler Festspannungsregler).



Spannungsversorgung
Die Frage mit der Spannungsversorgung ist für mich noch eine offene 
Baustelle. Ich brauche sowieso eine kräftige 5V und 12V störungsfreie 
Versorgung. In meinem Empfänger kann ich mir keine Störquellen erlauben. 
Für lineare Netzteil sind aber die Ströme zu hoch. Das würde dann eine 
Heizung werden...  Dieser Teil wird noch eine eigene Baustelle. Momentan 
behelfe ich mir noch mit externen kräftigen Netzteilen.

Welchen Step-Down Wandler hast du verwendet? Produziert er bei dir 
Störungen am Eingang oder am Ausgang oder streut der Dreck irgendwie 
anders ein?

Du scheinst auch beruflich mit den Dingern zu arbeiten. Hast du 
irgendwelche Informationen ab wann mit dem BT815/6 bei Mouser & Co zu 
rechnen ist.

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Nun sind eigentlich nur doch diese beiden Displays für mein
> Selbstbau-Empfänger im Rennen:
>
> RVT70AQFFWC00
> Vorteil: Die Glasabdeckung scheint wirklich gut auszusehen und lässt
> sich komfortabel einbauen.

Noch mal. :-) Das hat keine Glasabdeckung, das ist das "UQ".

Was ist mit dem EVE2-70G?
Das ist soweit baugleich zum RVT70UQ, dabei 10° mehr in die eine 
Richtung und ein wenig günstiger.

> Nachteil: Die Außenmaße sind bei meinem aktuellen Projekt 3 mm zu groß
> (Höhe). Da muss entweder der äußere Rahmen der Frontplatte abgefräst
> werden oder ich muss doch zu dem anderen Display greifen.

Sowas ist natürlich lästig.

> Kann man dieses Display überhaupt wieder entfernen, wenn man die
> Frontplatte austauschen möchte?

Habe ich noch nicht probiert, das war bisher bei keinem Display 
notwendig, tendenziell eher nicht.

> NHD-7.0-800480FT-CSXV-CTP
> Vorteil: Die Abbildungsqualität scheint wohl wirklich gut zu sein.

Ich weiss nicht so recht, im wesentlichen ist es heller als die anderen, 
benötigt aber auch entsprechend noch mehr Strom.

> Das Display kann leichter getauscht werden, wenn die Frontplatte des Gerätes
> gewechselt wird (Entwicklungsphase)
> Nachteil: Hier muss die Frontplatte gefräst werden, damit nur der aktive
> Displaybereich zu sehen ist. Die Befestigung ist dann auch nicht so
> einfach. Vermutlich muss dann von hinten mit Metallkleber eine
> selbstgebaute Halterung auf die gefräste Frontplatte aufgeklebt werden.
> (Das mit dem Metallkleber muss ich mal ausprobieren)

Wenn man die Frontplatte schon fräst, oder auch 3D-Druckt in Plastik, 
dann kann man das auch gleich entsprechend dicker auslegen und eine 
Platte dahinter schrauben.

Etwa so: https://www.thingiverse.com/thing:2941870

Der Rahmen drum herum fällt da aber auch sehr fett aus.

Ich würde ja gerne fertige Gehäuse kaufen die für 7" vorbereitet sind, 
bisher habe ich da aber noch nichts bezahlbares und/oder ansprechendes 
gefunden.

> Gut gefällt mir der Wannenstecker für ein Adapterboard und die 3,3V
> Versorgung (normaler Festspannungsregler).

Mit 5V da drauf mag das noch gehen, sind aber Verluste um 1-2 Watt.

> Spannungsversorgung
> Die Frage mit der Spannungsversorgung ist für mich noch eine offene
> Baustelle. Ich brauche sowieso eine kräftige 5V und 12V störungsfreie
> Versorgung. In meinem Empfänger kann ich mir keine Störquellen erlauben.
> Für lineare Netzteil sind aber die Ströme zu hoch. Das würde dann eine
> Heizung werden...  Dieser Teil wird noch eine eigene Baustelle. Momentan
> behelfe ich mir noch mit externen kräftigen Netzteilen.

Ein kleineres Display braucht auch weniger Strom und die volle 
Helligkeit braucht man eher auch nicht so.
Da hilft nur ausprobieren.

> Welchen Step-Down Wandler hast du verwendet? Produziert er bei dir
> Störungen am Eingang oder am Ausgang oder streut der Dreck irgendwie
> anders ein?

Den Ausgang habe ich jetzt ziemlich sauber, jetzt strahlt das Ding am 
Eingang und ich habe dafür noch keine Lösung gefunden.
Das ist wohl bei Buck Reglern systematisch, meine Versuche das am 
Eingang zu filtern haben bisher nur leider überhaupt keinen Effekt 
gehabt.

Aktuell verbaue ich ADP2301AUJZ-R7, das sind 2,1MHz/1,4A Regler.
Einen RT8259GE könnte ich da noch testen, ich fürchte nur das macht 
keinen Unterschied.
Davor habe ich schon eine Drossel und mehrere Keramik-Cs parallel, aber 
alles was ich ausprobiert habe hatte so gar keinen Effekt bisher.

> Du scheinst auch beruflich mit den Dingern zu arbeiten.

Leider nur im Homöopathischen Stückzahlen für einzelne Sonder-Lösungen, 
nicht als Produkte.

> Hast du irgendwelche Informationen ab wann mit dem BT815/6 bei
> Mouser & Co zu rechnen ist.

Ich weiss nur sicher, das Matrix Orbital da dran ist:
https://www.matrixorbital.com/ftdi-eve/eve-bt815

Von denen habe ich auch schon Unterlagen zur Hardware gesehen.

Ich meine von Riverdi auch was gelesen zu haben, finde das aber gerade 
nicht.

Glyn hat wohl das ADAM50-LCP-WVGA-NEW-BT815 am Start, da ran zu kommen 
mache ich mir aber gerade keine Hoffnungen und die Kommunikation mit 
Glyn fand ich insgesamt etwas zäh.

Im wesentlichen hängt es wohl an BridgeTek, wenn die den Release 
wirklich im Juni gemacht hätten, dann gäbe es die Displays schon zu 
kaufen.

Ich habe immer noch die Hoffnung vor Weihnachten was in der Post zu 
haben, das muss jetzt langsam mal Fahrt aufnehmen.

[Joern DK7JB .. (moin)]

Wenn du an das Problem mit dem Schaltregler wirklich ran willst, 
solltest du vielleicht hier das Forum nutzen. Im Bereich "HF, Funk & 
Felder" findest du genügend erfahrene User. Das IC alleine hilft nicht 
wirklich. Notwendig wäre dann auch ein Schaltplan in dem auch deine 
Entstörmaßnahmen eingezeichnet sind und ein Foto von deinem Aufbau. Was 
hast du für Meßmöglichkeiten und welche Erfahrung hast du auf diesem 
Gebiet?

[Rudolph R. (rudolph)]

Na, alles gut, im Moment habe ich interessantere "Probleme" als den 
Regler. :-)

[Christian W. (Gast)]

Hallo,

erstmal Vielen Dank an Rudolph R. für die geniale Library.

Ich beschäftige mich jetzt seit ca. 2 Wochen damit, folgende hardware 
zum laufen zu kriegen (ist mein erstes MCU Projekt):


NHD-4.3-480272FT-CSXN-CTP (FT813)
ESP32 im "referenz" design


Als IDE nutze ich Eclipse mit Sloeber Arduino plugin. Aktuell siehts so 
aus, dass ich das Beispiel 
"FT8xx_Test_Arduino_ESP8266_FT813_RVT70UQFNWC0x"
einwandfrei am laufen habe.

Nun möchte habe ich versucht die "tft.cpp" soweit auszudünnen als das 
ich alle notwendigen Funktionen erhalte, jedoch einen blanken Bildschirm 
erhalte und darauf meine GUI aufbauen kann.

Das hat soweit auch gut funktioniert, Bildschirm ist jetzt geräumt. Habe 
dann mal testweise einen Button sowie ein paar Zeilen Text anzeigen 
lassen, auch kein problem.

Problematisch ist bei mir lediglich das laden/öffnen von Bildern. Dabei 
ist es egal ob es sich um die im Beispiel mitgelieferten handelt, oder 
um selbst umgewandelte.

In der aktuell angehängten Konfiguration ist es mir auch nicht möglich, 
"nur" die beiden (oder auch nur eins) der Bilder anzeigen zu lassen

[Rudolph R. (rudolph)]

Moin,

das Beispiel ist etwas älter, nicht nur das die "Library" inzwischen 
weiter ist, das aktuelle Beispiel ist auch viel einfacher gehalten.
Zum Beispiel brauchen cmd_inflate() und cmd_loadimage() schon länger 
kein cmd_execute() mehr.

Das neueste auf Github wäre das hier:
https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/example_projects/EVE_Test_SAMC21_FT813_EVE2-35G.zip

Im grossen ganzen sind die Dateien ja austauschbar, nur weil Arduino das 
nicht anders mag wird aus der tft.c eben tft.cpp und so weiter.

Die angehängte Datei ist ja auch alles andere als ausgedünnt.

Oder wirf doch mal bitte ein komplettes Archiv rüber bei dem es hakt,

Schauen wir mal.
EVE_Test_SAMC21_FT813_EVE2-35G kopieren und umbenennen in 
EVE_Test_Arduino_FT813_EVE2-35G
sketch_esp8266.ino aus dem Beispiel rüber kopieren und in
EVE_Test_Arduino_FT813_EVE2-35G.ino umbenennen
EVE_commands.c in EVE_commands.cpp umbenennen
tft.c in tft.cpp umbenennen
Unter-Ordner, main.c, EVE_Test.atsln, EVE_Test.componentinfo.xml und 
EVE_Test.cproj löschen
Arduino starten, auf ESP8266 stellen weil ich ESP32 nicht mal 
installiert habe
In der .ino alle "FT8_" auf "EVE_" ändern
Überprüfen läuft ohne zu Murren durch
Archiv anhängen :-)

Ob das aber tut was das soll kann ich spontan nicht sagen. :-)

[Joern DK7JB .. (moin)]

Ich versuche auch gerade mit der FT8xx-Library von Rudolf meine ersten 
Gehversuche zu meistern. Ich scheitere gerade an der Anpassung eines der 
Beispiel auf den Arduino UNO (ATMega328P) weil dessen Timer nicht 
ausreichen.

Welche Timer werden in den Beispielen für welche Aufgaben verwendet und 
welche Mindestanfordrungen (Timer etc.) werden an die ATMegas gestellt?

Gibt es auch Beispiele für den ATmega 644P/PA?

Würde ein ATMega328PB mit seinen vielen Registern reichen? Den gibt es 
nur als SMD-Version. (China-Nachbau mit SMD-ATMega328P der dann gegen 
einen ATMega328PB ausgetauscht wird)

[Rudolph R. (rudolph)]

Also Timer verwendet mein Arduino Beispiel gar nicht, nur millis.
Keine Interrupts, nur SPI und zwei I/O Pins.
Aber dafür ganz gut FLASH.

Wenn ich für das Archiv da oben in der Arduino IDE auf UNO umstelle dann 
läuft es fast anstandlos durch.
Komischerweise gibt es mit Arduino 1.8.7 eine Warnung wegen PROGMEM.

Mit dem Mega328P kann man das zwar benutzen, aber gerade mit Bildern für 
das Display geht dem sehr Schnell der Speicher aus.
Das einfache Beispiel von da oben kommt auf 11290 Bytes Programmspeicher 
und benötigt 77 Bytes SRAM.

Ein aktueller "Arduino" dem der Speicher nicht so schnell ausgeht wäre 
der Metro M4, wenn ich auf den umstelle bekomme ich spontan allerdings 
einige Warnungen.
Bei einem STM32 als Arduino-Target das gleiche Spiel, wirft Warnungen, 
läuft aber grundsätzlich durch.

Nur hätte ich gerade weder einen STM32 mit dem ich das ausprobieren 
könnte, und auch keinen UNO oder ein Board mit ESP8266 oder ESP32.
Hmm, und keine Jumper-Kabel um mein Display mit dem Metro M4 zu 
verbinden.
Also meine Möglichkeiten in Richtung Arduino sind gerade etwas 
eingeschränkt. :-)

Edit: Sanguino habe ich noch vergessen, also die M644/M1284 Targets.
Läuft auch soweit durch, die gleiche Warnung wie beim UNO.
Mit dem Board von meinem 3D-Drucker habe ich das schon mal ausprobiert. 
:-)

[Joern DK7JB .. (moin)]

Hallo Rudolf,
ich habe gerade den Eindruck, dass ich mit dem Atmel Studio7 noch nicht 
so richtig umgehen kann, da ich gerade von einer anderen 
Programmiersprache am Umsteigen bin. Ich plane in C/C++ mit ATMegas 
heimisch zu werden und eher weniger in der reinen Arduino-Umgebung.

Das mit den Timern habe ich noch nicht richtig verstanden. Wenn du es 
für die Arduino-Umgebung durchlaufen lässt werden keine Timer verwendet 
und wenn du es ohne Arduino-Umgebung wählt mit Timern? Wie funktioniert 
dann das Erkennen der Touch-Rückmeldung wenn z.B. ein Button gedrückt 
wird. Machst du es dann mit einem Interrupt?
Irgendwie bin ich gerade verwirrt.

Wird in einem deiner Beispiele auch gezeigt wie auf die 
Touch-Rückmeldung von mehreren Buttons reagiert wird?

Könntest du mir bitte für den ersten Einstieg ein Beispiel für den 
ATmega644 zusammenstellen? Ich arbeite noch mit dem VM800B50A bis ich 
endlich auf die FT81xer umsteigen kann.

[Rudolph R. (rudolph)]

Ich passe mal eben was an.
Der Timer oder eben die Millis werden nur verwendet um die Zeit zu 
messen die der Controller benötigt um die Liste per SPI zu verschicken.

Oh, doch, ein zweiter Timer wird für den "Scheduler" benutzt. :-)
Beim SAMC21 benutze ich dafür den SysTick Timer, daher ist mir das 
gerade durchgerutscht. :-)

[Rudolph R. (rudolph)]

So viele Details. :-)

Die main.c nutzt nur noch den Timer 2 für den 10ms Takt.
Die tft.c ist noch etwas einfacher da der FT800 auf dem VM800B das 
zweite Bild sowieso nicht laden kann - das ist nämlich ein .png.

Der statische Teil der Liste in dem das Bild angezeigt wird hat noch 
eine Anpassung für die FT80x mit drin, da gab es so schöne Kommandos wie 
SetBitmap einfach noch nicht...

Anzupassen wären noch die verwendetem I/O Pins für CS und PD, zum einen 
in der main.c, zum anderen in der EVE_config.h für den AVR Zweig.

Compilieren tut das soweit.

Mit meinem aktuellen SAMC21 Projekt und einem EVE2-35G funktioniert die 
tft.c.
Selbst dann wenn ich das ein wenig umeditiere und die FT80x Kommandos in 
der initStaticBackground() ausgeführt werden.

[Joern DK7JB .. (moin)]

Danke, ich versuche gerade den für mich noch ungewohnten Aufbau der 
gesamten Solution zu verstehen und melde mich, wenn ich alles zum Laufen 
bekommen habe.

[Joern DK7JB .. (moin)]

So das Display hat sich nun das erste mal mit deiner Lib gemeldet, wenn 
auch nicht vollständig korrekt.
Die Ports/Pins wurden eingestellt auf

EVE_config.h
#define EVE_CS_PORT  PORTB
      #define EVE_CS     (1<<PB2)
      #define EVE_PDN_PORT  PORTB
      #define EVE_PDN    (1<<PB3)

main.c
  DDRA = 0x00;  /* all pins set to input */
  PORTA = 0xff;  /* pullup-resistors activated */

    // PB2 CS           Output, high
    // PB3 Power Down   Output, low
    // PB4 SS des ATMega Output, high   nicht benutzt
    // PB5 MOSI         Output
    // PB7 SCK          Output

    // PB0  Input mit Pullup
    // PB1  Input mit Pullup
    // PB6  Input mit Pullup
  DDRB = (1<<PB2) | (1<<PB3) | (1<<PB4) | (1<<PB5) | (1<<PB7) ;  /* 
SS=PB4 (not used), SCK=PB7, MOSI=PB5, CS=PB2, PowerDown=PB3 set to 
Output, others to set to input */
  PORTB = (1<<PB2) | (1<<PB4);                                  /* SS 
(not used) set to high, CS set to high, PowerDown set to low, 
pullup-resistors for unused pins activated */


  DDRC = 0x00;
  PORTC = 0xff;

  DDRD = 0x00;
  PORTD = 0xff;

Der Bildschirm meldet sich nur mit einem mittelhellen Bildschirm. (grau)
Wenn ich (in TFT_init(void))das Kalibrieren des Bildschirms einschalte 
läuft die Kalibrierung durch und die Werte werden angezeigt. Wenn ich 
die Kalibrierung wieder deaktiviere habe ich wieder den grauen 
Bildschirm. Wenigstens kann ich mir nun sicher sein, dass alles richtig 
verkabelt worden ist.
Kann es sein, dass noch ein Fehler in initStaticBackground() vorhanden 
ist?

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Kann es sein, dass noch ein Fehler in initStaticBackground() vorhanden
> ist?

Spontane Antwort: nimm doch einfach mal das EVE_cmd_append() raus in der 
tft_loop().

Bessere Antwort: ändere mal das Define für die Start-Adresse von dem 
statischen Part in:
#define MEM_DL_STATIC (EVE_RAM_G_SIZE - 4096)

Die FT80x haben doch nur 256k Speicher, da wird das nix mit 0x00ff000...

[Christian W. (Gast)]

Vielen Dank für die schnelle Hilfe, jetzt konnte ich ohne probleme ein 
.jpeg laden.

[Joern DK7JB .. (moin)]

Mit der Hilfe von Rudolf klappt es nun.

Ich werde jetzt mit meinem alten Display auf der FT800er-Basis weiter 
üben. Die Steuerplatine für das neue FT813er Display kommt nächste Woche

Welchen Vorteil in der Programmierung haben die FT813er Display 
gegenüber dem alten FT800 mit resistivem Display (außer besserem Touch 
und besserem Display)?
Mir geht es weniger im JPG-Bilder die gezeigt werden sollen sondern viel 
mehr um Bedienpannels mit Diagrammen und Schaltflächen und andern 
Anzeigen.


Wie designt ihr eure Bildschirme? Nehmt ihr das Programm "EVE Screen 
Editor v3.1.2" oder für die FT81x die Programme "EVE Screen Designer 
3.0" oder "EVE Screen Designer 4.5 Beta 2"? Was ist von den 
Code-Generatoren der beiden letzten Programme zu halten?

Wie erstellt man Button nach eigener Vorstellung? Zeichnet man dann den 
Button als Bild und erstellt das Touch-Feld nach eigenen Maßen? Wenn ja 
mit welchem Befehlt? Bisher habe ich nur die vorhandenen Widges 
verwendet.

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Welchen Vorteil in der Programmierung haben die FT813er Display
> gegenüber dem alten FT800 mit resistivem Display (außer besserem Touch
> und besserem Display)?

Neben einigen zusätzlichen Optionen wie dem cmd_setbitmap() ist ja vor 
allem der sehr viel größere Speicher nett.

> Wie designt ihr eure Bildschirme?

Praktisch von Hand, ich überlege mir wie das aussehen soll und werfe
die Koordinaten dazu in den Code.
Bisschen anpassen, fertig.
Oft benutze ich dabei Defines.
Sowas wie "X1", "Y2" um ganze Gruppen von Buttons oder Texten 
auszurichten und die Gruppe komplett verschiebbar zu haben.

> Nehmt ihr das Programm "EVE Screen Editor v3.1.2" oder für die FT81x
> die Programme "EVE Screen Designer 3.0" oder
> "EVE Screen Designer 4.5 Beta 2"?

Seit einiger Zeit nicht mehr wirklich.

> Was ist von den Code-Generatoren der beiden letzten Programme zu halten?

Die muss ich mir noch mal ansehen, ich bin nie dazu gekommen mal eine 
angepasste Python Datei zu erstellen, vor allem weil ich von Python 
wenig bis keine Ahnung habe.

> Wie erstellt man Button nach eigener Vorstellung? Zeichnet man dann den
> Button als Bild und erstellt das Touch-Feld nach eigenen Maßen?

Ja, ich würde erstmal zwei Bilder dafür malen, die Bilder selber sind 
dann auch die Touch-Flächen.

> Wenn ja mit welchem Befehlt? Bisher habe ich nur die vorhandenen Widges
> verwendet.

Einfach einen Tag zuweisen und anzeigen.
Alles was man auf dem Bildschirm sieht kann für Touch verwendet werden.

Hier mal ein kleines, spontanes und ungetestetes Beispiel ohne Bilder.
Ein "Button" bestehend aus einem blauen Rechteck das in zwei 
verschiedenen Blau-Tönen dargestellt wird und den Text ändert:

EVE_cmd_dl(TAG(12));
EVE_cmd_dl(DL_BEGIN | EVE_RECTS);
EVE_cmd_dl(LINE_WIDTH(10*16)); /* corner curvature in 1/16 pixel */
EVE_cmd_dl(DL_COLOR_RGB | (mybutton ? BLUE_1 : BLUE_2));
EVE_cmd_dl(VERTEX2F(40*16,10*16));
EVE_cmd_dl(VERTEX2F(60*16,100*16));
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_text(50, 20, 26, 0, mybutton ? "On" : "Off");
EVE_cmd_dl(TAG(0));

Also wirklich alles was hinter dem cmd_dl(TAG(xx)) folgt gehört zu einer 
Touch-Gruppe.
Man könnte da noch zuerst ein etwas größeres Rechteck in zum Beispiel 
schwarz zeichnen damit sich der "Button" besser abhebt.

...
EVE_cmd_dl(DL_COLOR_RGB | BLACK);
EVE_cmd_dl(VERTEX2F(38*16,8*16));
EVE_cmd_dl(VERTEX2F(62*16,102*16));
EVE_cmd_dl(DL_COLOR_RGB | (mybutton ? BLUE_1 : BLUE_2));
...

Dazu kommt in der Touch-Auswertung dieser Code:

case 12: /* use mybutton as on/off radio-switch */
  if(toggle_lock == 0)
  {
  toggle_lock = 42;
  if(mybutton == 0)
  {
    mybutton = 42;
  }
  else
  {
    mybutton = 0;
  }
  }
  break;

Nicht sehr elegant, zugegeben, dafür anschaulich.

[Joern DK7JB .. (moin)]

Das habe ich gleich ausprobiert und es gefällt mir sehr gut.

Ich hätte noch einige Fragen die vielleicht auch für andere interessant 
sind:
- Wie kann man kleine Grafiken/Bilder einbinden und aufrufen? Könnte ich 
dich um ein kleines Beispiel bitten?
- Wie erzeugt man einen eigenen Font und bindet ihn ein damit auch 
Umlaute möglich sind? Fügt man kleine Piktogramm besser als Bild ein 
oder missbraucht man die Fonts?
- Ist das richtig, dass man mit der Soundfunktion nicht besonders viel 
machen kann außer so etwas wie Tastenklicks? Hier fehlt mir die 
Phantasie...
- Fallen dir sonst noch interessante Möglichkeiten ein über die wir noch 
nicht gesprochen haben?

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> - Wie kann man kleine Grafiken/Bilder einbinden und aufrufen? Könnte ich
> dich um ein kleines Beispiel bitten?

Na, in meinem Beispiel-Code wird doch ein Bild angezeigt.

> - Wie erzeugt man einen eigenen Font und bindet ihn ein damit auch
> Umlaute möglich sind?

Das habe ich noch nicht wirklich ergründet und Teil des Problems ist das 
die FT8xx nur 127 Zeichen lange Fonts verwenden können, Umlaute gehören 
aber zu den extended-ASCII Zeichen ab 128+.
Also wenn man Umlaut in den ersten 127 Zeichen unterbringt muss man sich 
noch was überlegen wie man die in den Text packt da man die ja nicht 
direkt tippen kann.
Mit den BT81x wird das anders, die unterstützen Unicode Fonts.

> Fügt man kleine Piktogramm besser als Bild ein
> oder missbraucht man die Fonts?

Das ist quasi anders herum, Fonts sind kleine Bilder. :-)

Schau mal am den Anfang des Threads, meine Spielplatz-Anwendung hat die 
Bilder noch etwas anders angezeigt.
Wenn man VERTEX2II(x,y,0,0) benutzt statt VERTEX2F dann ist der letzte 
Parameter ein Index für eine Reihe gleicher Bilder direkt hintereinander 
weg im Speicher.

"Cell number is the index of the bitmap with same bitmap layout and 
format.
For example, for handle 31, the cell 65 means the character "A" in built 
in font 31."

Man kann also kurze Animationen abspielen indem man nur diesen Parameter 
ändert.

VERTEX2II kann allerdings nur positive Koordinaten von 0...511.
Mit VERTEX_TRANSLATE_X kommt man zwar höher in X-Richtung, aber nicht 
ins Minus.

Man könnte auch einen Extended ASCII Font in zwei Fonts zerlegen
und per VERTEX2II anzeigen, man kommt damit nur nicht allzu weit da man 
ja 32 Bit pro Zeichen verschicken müsste und darüber hinaus bei 
proportional-fonts auch noch die Koordinaten ausrechnen müsste.

Für rein statischen Text sollte man besser Bilder einbauen.

> - Ist das richtig, dass man mit der Soundfunktion nicht besonders viel
> machen kann außer so etwas wie Tastenklicks? Hier fehlt mir die
> Phantasie...

Neben den Klicks ist doch ein komplettes MIDI Set abgelegt, man kann ein 
Keyboard damit bauen mit diversen Tönen.
Man kann auch ganze Melodien damit abspielen.
Oder Samples.

Viel damit gemacht habe ich bisher auch nicht da die wenigstens Module 
bisher überhaupt einen Verstärker und Lautsprecher hatten.

> - Fallen dir sonst noch interessante Möglichkeiten ein über die wir noch
> nicht gesprochen haben?

Bild Transformationen sind interessant.
Nicht das ich die ganzen Optionen überhaupt richtig verstehen würde,
da davon kaum was erklärt wird in den EVE Unterlagen,
aber das soll sich schwer an OpenGL orientieren.
Ich habe schon Bilder rotiert, gespiegelt, in der Größe verändert.

Zusätzlich wäre da noch der Alpha-Channel.

Och und noch viel mehr, die Dinger sind so voll gestopft.
Bargraph Bitmaps habe ich zum Beispiel noch nicht ausprobiert.

Die Arduino Beispiele von FTDI sind auch ganz witzig, die finde ich 
jetzt nicht so sehr lehrreich, aber imposant.
Und dann natürlich was mit dem Gameduino so gezaubert wird.

[Joern DK7JB .. (moin)]

Ich habe immer noch Probleme mit der initStaticBackground(). Wenn ich 
sie aufrufe und danach das Programm mit while(1) in eine Schleife setze 
bleibt der Bildschirm schwarz. Wenn ich das while(1) weglasse wird 
initStaticBackground()ohne sichtbares Ergebnis durchlaufen und dann der 
Bildschirm mit den Buttons aufgerufen und angezeigt.

[Rudolph R. (rudolph)]

Hmmm, hast Du auch berücksichtigt, dass tft_loop() nicht zu oft 
aufgerufen werden darf?
So wie ich das strukturiert habe ist ja jeder zweite Aufruf ein 
Bild-Aufbau.
Und je nach Display und Einstellung dazu verträgt das unterschiedlich 
hohe Bildfrequenzen, maximal um die 60, also weniger als 120 Mal pro 
Sekunde sollte die tft_loop() schon aufgerufen werden.

Die initStaticBackground() macht für sich auch nichts am Bildschirm.
Damit wird eine oder auch mehrere Display-Listen erzeugt und zur 
Wiederverwendung in den Speicher kopiert.
So für den ganzen statischen Kram der sich von einem Bild zum nächsten 
nicht ändert wie in meinem Beispiel eben das Logo oben in der Ecke, das 
blaue Rechteck und die Trenn-Linie.

Mit dem EVE_cmd_append() wird das dann in die aktuelle Liste eingebaut.

Der Witz daran ist, dass der statische Teil der Anzeige so nicht immer 
wieder über den SPI geschickt wird, sondern eben nur einmal.

[Joern DK7JB .. (moin)]

Oh, jetzt habe ich es endlich verstanden - hatte eine lange Leitung...
Kann man auch mehrere Hintergründe hinterlegen und dann je nach Bedarf 
aufrufen oder nur einen einzigen statischen Hintergrund?

Jetzt muss ich erst einmal mit deiner Lib spielen und meine 
C-Fähigkeiten verbessern. Danke für die Zeit du dir für mich genommen 
hast.

Meine anderen Anfängerfragen zur C-Programmierung werde ich irgendwo an 
andere Stelle sinnvoller stellen - wo wird sich noch finden.

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Kann man auch mehrere Hintergründe hinterlegen und dann je nach Bedarf
> aufrufen oder nur einen einzigen statischen Hintergrund?

Klar, soweit der Speicher reicht.
Ein Praktikant bei mir in der Firma hat mal eine Oberfläche für ein 
Azubi-Projekt auf einem 7" programmiert das diverse Seiten im Speicher 
gehalten hat  - inklusive dynamischer Verwatung des Speichers.
Das fand ich schon ein wenig übertrieben was er da veranstaltet hat, 
lief aber soweit. :-)

Die 4k die ich Reserviert habe sind schon sehr üppig, wenn der Speicher 
knapper wird muss man sich eben mal ansehen wie gross die Abschnitte so 
werden.
Und am Ende darf man auch nicht mehr als 8kB in die Display-Liste 
schreiben.

[Joern DK7JB .. (moin)]

Hmmm, wie können dann die Seiten im Speicher voneinander unterschieden 
werden.

Was muss ich eigentlich umstellen wenn mein FT813 Display mit Controller 
läuffähig ist? Nur das Display und FT81x einstellen?
Kann dann ein seitenfüllendes Bild als Hintergrund angezeigt werden?

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Hmmm, wie können dann die Seiten im Speicher voneinander unterschieden
> werden.

Na, wie Bilder auch, von aussen erstmal gar nicht, was wo liegt legst Du 
selber fest.

> Was muss ich eigentlich umstellen wenn mein FT813 Display mit Controller
> läuffähig ist? Nur das Display und FT81x einstellen?

Davon ausgehend, dass das gleich verdrahtet ist musst Du noch das Define 
für die Display-Parameter ändern.

Also in EVE_config.h das

#define EVE_VM800B50A

durch

#define EVE_NHD_50

Oder was auch immer Du noch benutzen möchtest.
Das #define FT81X_ENABLE und in Zukunft auch #define BT81X_ENABLE
wird mit den Display-Parametern gesetzt.

Also da müsste man nur was dran ändern wenn man zum Beispiel ein VM800B 
auf einen FT810 umlötet.

> Kann dann ein seitenfüllendes Bild als Hintergrund angezeigt werden?

Begrenzt, ein Farb-Bild benötigt bei 800x480 mal eben 768000 Bytes von 
den maximal nutzbaren 1MB.
Mit den BT81x wird das anders durch das externe SPI-Flash.
Aber da fehlt mir noch jede Hands-On Erfahrung zu.

[Christian W. (Gast)]

Wurde die Library schon in Verbindung mit einem Arduino DUE getestet?

Da gibts ja ggü. den AVR modellen einige Unterschiede in Bezug auf die 
SPI Kommunikation.

Konnte die Library problemlos kompilieren, CS wurde auf 10 und PDN auf 8 
gesetzt, jedoch bleibt der Bildschirm schwarz.

Aufgrunddessen das mein Labornetzteil vorgestern den Geist aufgegeben 
hat und dabei direkt den ESP32 mitgenommen hat, kann ich leider nicht 
ausschließen das es auch an meinem TFT liegt, das war nämlich auch 
angeschlossen (Die Hintergrundbeleuchtung funktioniert immerhin noch...)


Mfg
Christian

[Rudolph R. (rudolph)]

Christian W. schrieb:
> Wurde die Library schon in Verbindung mit einem Arduino DUE getestet?

Ich kann mich gerade nicht erinnern.
Ich hatte zwar mal ein Projekt in dem ich einen Due verwenden musste 
weil der Projektleiter den ausgesucht hatte, da kam aber ein 
Pixel-Display zum Einsatz.

> Da gibts ja ggü. den AVR modellen einige Unterschiede in Bezug auf die
> SPI Kommunikation.
> Konnte die Library problemlos kompilieren, CS wurde auf 10 und PDN auf 8
> gesetzt, jedoch bleibt der Bildschirm schwarz.

Wie initialisierst Du den SPI?

Das hier wäre ganz schlecht: SPI.begin(10);

Damit ist zwar das Chip-Select auf Pin 10, aber das ist kein I/O Pin 
mehr.
Der kann somit auch nicht mehr durch digital.write() bedient werden.

Und da auch noch der Takt beim Init unter 11 MHz liegen muss wäre wohl 
das hier vorzuziehen:
SPI.beginTransaction(SPISettings(8000000, MSBFIRST, SPI_MODE0));

Aber Arduino und so, das musste ich auch erst raus suchen...

> Aufgrunddessen das mein Labornetzteil vorgestern den Geist aufgegeben
> hat und dabei direkt den ESP32 mitgenommen hat, kann ich leider nicht
> ausschließen das es auch an meinem TFT liegt, das war nämlich auch
> angeschlossen (Die Hintergrundbeleuchtung funktioniert immerhin noch...)

Wie sah denn die Versorgung dazu aus? Wo kamen denn die 3,3V für das 
Display her und welche Spannung kam woher für die 
Hintergrund-Beleuchtung?

Wie hast Du überhaupt festgestellt, dass die Beleuchtung noch geht?
Das ist zwar erstmal ein anderer Schaltungsteil, wird aber durch den 
FT8xx eingeschaltet, insofern besteht ja Hoffnung.

Eine Sache ist mir beim drüber schauen in der EVE_config.h noch 
aufgefallen, kommentier mal das Laden der Bilder aus, es könnte sein das 
es da hängt weil der Teil nur AVR spezifisch ist.

static inline uint8_t fetch_flash_byte(const uint8_t *data)
{
  #if defined(RAMPZ)
    return(pgm_read_byte_far(data));
  #else
    return(pgm_read_byte_near(data));
  #endif
}

Beide Varianten sind eigentlich blöd auf nicht-AVR Controllern.
Auf dem ESP8266 lief das aber wohl aber.
Schon blöd wenn man das als Trocken-Übung macht. :-)

Wenn das andere passt und das Laden von Bildern hängt, das hier könnte 
helfen:

static inline uint8_t fetch_flash_byte(const uint8_t *data)
{
  #if  defined (__AVR__)
    #if defined(RAMPZ)
      return(pgm_read_byte_far(data));
    #else
      return(pgm_read_byte_near(data));
    #endif
  #else
    return *data;
  #endif
}

[Christian W. (Gast)]

Ganz schlecht trifft dann in meinem Fall zu.

Sieht aktuell folgendermaßen aus:


//digitalWrite(EVE_CS, HIGH);
//pinMode(EVE_CS, OUTPUT);
  digitalWrite(EVE_PDN, HIGH);
  pinMode(EVE_PDN, OUTPUT);

//pinMode(16, OUTPUT);

SPI.begin(10);
SPI.setClockDivider(SPI_CLOCK_DIV16); // equals 1 Mhz

  TFT_init();

Das mit dem SPI.beginTransaction werde ich später sofort mal testen...

Die Spannungsversorgung wurde bisher von einem "Elektro-Automatik 
EA-PS2326A" Labornetzteil zur Verfügung gestellt. Dort waren der ESP32, 
die +3.3V fürs Display sowie 2x 3.3V für die Hintergrundbeleuchtung (Ist 
ein Newhaven Sunlight Readable).

Im Betrieb fing jedoch das Netzteil plötzlich an zu brummen und die 
Spannung ging plötzlich hoch, habe noch schnell ausgeschaltet aber da 
war es für den ESP schon zu spät.

Beim Display bin ich mir wie gesagt noch nicht sicher, die 
Hintergrundbeleuchtung ist nach Ausfall des ESP32 auch noch solange 
angeblieben bis ich ausgeschaltet habe.. Auch jetzt funktioniert sie.

Im Gegensatz zum µC roch das Display auch nicht verschmort und war auch 
nicht heiß - daher habe ich da noch Hoffnung.

Bis auf die oben aufgeführte Änderung und die bereits erwähnte in der 
EVE_Config.h ist deine Bibliothek unverändert.

[Rudolph R. (rudolph)]

Christian W. schrieb:
> SPI.begin(10);

Ein einfaches SPI.begin(); sollte aber klappen.

Mit dem CS unter Hardware-Kontrolle wird das bei jedem einzelnen Byte 
auf Null gesetzt und danach wieder auf High gebracht.
Der mit den FT8xx häufigste Zugriff ist aber 32 Bit am Stück.
Wenn man Bilder überträgt sind das dann auch mal bis zu 4k am Stück.

> SPI.setClockDivider(SPI_CLOCK_DIV16); // equals 1 Mhz

Das sollte aber eher so 5,25MHz mit dem DUE ergeben da der SAM3S auf
dem Ding ja mit 84MHz getaktet wird.

Christian W. schrieb:
> Dort waren der ESP32,
> die +3.3V fürs Display sowie 2x 3.3V für die Hintergrundbeleuchtung (Ist
> ein Newhaven Sunlight Readable).

Ich drück mal die Daumen, aber die 3,3V gehen direkt auf den FT81x bei 
den NHD und dieser verträgt laut FTDI nur bis 4V.
Der LED-Treiber verträgt aber bis 6V.

Einen FT813 kann man schon tauschen, das ist aber eher unlustig.
Das erste Problem ist schon mal das man dafür die Platine vom Display 
lösen muss da beim Löten mit Heissluft ansonsten das Panel selber 
gegrillt wird.
Den Fehler habe ich schon gemacht und bei dem Display habe ich nur die 
Level-Shifter Gatter getauscht, das hat jetzt einen dunkleren Fleck.
Nur gerade bei den NHD dürfte das unlustig sein die Platine vom Panel zu 
trennen.
Aber selbst wenn man die runter bekommt, ein VQFN-56 lötet man trotzdem 
nicht mal eben so um.

[Frank L. (dl3ad)]

Hallo,

ich habe ein ME813A-WH50C Displaymodul und möchte es mit Bascom 
ansprechen.
In der Hilfe von Bsacom steht zwar das der FT813 unsterstützt wird
aber ich bekomme es nicht ans laufen.

Ich versuche das Display an einem ATMega 128A zum laufen zu bringen.
Folgendes ist realisiert:

-Bascom 2.0.8.1
-Display und ATMega128 laufen mit 3,3V
-SPI ist wie folgt verdrahtet Display => ATMEGA
SCK => PB1
MOSI => PB2
MISO => PB3
CS => PB4
PD => PB5

Ich möchte das Demo "Gauges" ausprobieren - habe schon viel 
herumprobiert - aber es läuft nicht => Display dunkel
Wie kann ich das Display zum leben erwecken ?
Ein "Hallo World" würde mir schon ausreichen.

Gruß Frank

[Rudolph R. (rudolph)]

Frank L. schrieb:
> ich habe ein ME813A-WH50C Displaymodul und möchte es mit Bascom
> ansprechen.

Ich fürchte, dann bist Du hier leider falsch, weil BASCOM ja nun einmal 
was komplett anderes ist und ich habe das auch noch nie benutzt.
Aber drüben bei https://www.mcselec.com/ gibt es ein Forum.

Ich wüsste spontan nicht mal wie man da ran kommt, also insbesondere die 
FT8xx Library dazu.
Und ob und wie man sich dann den Code davon ansehen könnte und in 
welcher Sprache der geschrieben ist.
Edit: die Demo die man runterladen kann ist etwas älter, damit wird 
FT81x nicht unterstützt - falls die FT80x Library da überhaupt bei ist.

[Joern DK7JB .. (moin)]

Hallo Frank
in der Hilfedatei von Bascom steht, dass auch die FT810 unterstützt 
werden:
https://avrhelp.mcselec.com/index.html?config_ft800.htm
Vielleicht solltest du im Bascom Forum mal anfragen oder dich direkt an 
den Hersteller von Bascom wenden. Da wirst du mehr Nutzer mit 
Bascom-FT8xx Erfahrung treffen oder dir helfen können, selbst wenn sie 
mit deinem FT813 noch nicht selbst gearbeitet haben.
Folge doch deinem eigenen Tread weiter: 
https://bascomforum.de/index.php?thread/1365-me813a-wh50c-display-mit-ft813-chip-am-atmega-128a/&postID=21976#post21976

Wenn du dein Problem richtig beschreibst mit Fotos, unfertigem Programm, 
Schaltplan usw. können vielleicht schon deine Probleme gelöst werden. Du 
schreist aber die anderen Helfer mehrfach an, obwohl sie dir helfen 
wollen und vergraulst sie damit. Das kommt nicht gut an. Vielleicht 
solltest du dort auch berichten ob du schon Erfahrung mit dem FT800 
hast.

[Joern DK7JB .. (moin)]

Nun hätte ich noch ein Frage zu eigenen Bitmaps die angezeigt werden 
sollen.

Als ersten Test habe ich einfach mal am Computer mir von der Zahl 6 ein 
Bild gemacht und als PNG abgespeichert. Dann habe ich mit dem Tool 
"Image Convert Tool V0.9.1" mir das PNG übersetzen lassen mit:
img_Cvt.exe -i test1.png -f 3

Was muss ich alles machen um mir das Bild anzeigne lassen?

Den Inhalt der Datei test1.binh habe ich nach tft_data.c kopiert und als 
Länge die Anzahl der Zahlen genommen (Mit MS Word zählen lassen)

/* 61x103 pixel test-logo der Zahl 6 in compressed L8 format, length is 
????? when uncompressed, converted with image-convert 0.9.1 from FTDI */
const /*__flash*/ uint8_t sechs[273] PROGMEM = {
120, 156, 229, 216, 203, 22, 130, 48, 12, 4, 208, 252, 255, 79, 215, 
133, 11, 33, 207, 153, 52, 30, 80, 178, 44, 115, 109, 176, 173, 112, 92, 
139, 45, 121, 87, 215, 53, 180, 232, 234, 75, 28, 123, 20, 196, 62, 133, 
112, 68, 1, 28, 211, 175, 218, 141, 155, 29, 94, 30, 80, 122, 22, 166, 
198, 226, 114, 212, 50, 116, 109, 208, 123, 88, 142, 94, 102, 215, 211, 
236, 26, 178, 63, 217, 52, 109, 239, 48, 241, 142, 125, 202, 196, 67, 
93, 63, 101, 226, 33, 124, 217, 196, 163, 93, 35, 155, 214, 75, 136, 83, 
88, 215, 158, 12, 184, 190, 22, 210, 252, 206, 74, 106, 57, 103, 149, 
62, 140, 2, 84, 241, 207, 24, 104, 143, 26, 38, 142, 238, 77, 80, 224, 
120, 81, 74, 108, 183, 131, 251, 178, 131, 82, 157, 13, 112, 68, 151, 
61, 42, 140, 53, 154, 178, 197, 102, 46, 172, 210, 164, 77, 112, 109, 
207, 154, 181, 123, 56, 56, 134, 152, 29, 194, 210, 192, 238, 47, 0, 
106, 111, 129, 27, 207, 200, 63, 194, 141, 117, 222, 195, 116, 223, 167, 
252, 12, 230, 143, 36, 141, 85, 156, 211, 42, 76, 97, 19, 102, 116, 130, 
137, 127, 170, 178, 161, 202, 122, 152, 122, 84, 217, 209, 132, 7, 41, 
1, 116, 156, 145, 138, 167, 1, 209, 5, 94, 11, 18, 73, 85, 141, 81, 20, 
215, 200, 247, 73, 90, 68, 135, 20, 224, 169, 77, 121, 37, 19, 14, 81, 
231, 19, 162, 204, 11, 202, 217, 236, 230,
};


Wie bekomme ich heraus wie groß mein Test-Logo in unkompromierter Form 
ist?
Welche Speicheradresse muss in in der tft.c eintragen?

In der Datei tft.c steht bisher nur dein Logo mit
/* memory-map defines */
#define MEM_LOGO 0x00000000 /* start-address of logo, needs 2242 bytes 
of memory */


In der Datei test1.rawh steht: (siehe Anhang)
/*('file properties: ', 'resolution ', 61, 'x', 103, 'format ', 'L8', 
'stride ', 61, ' total size ', 6283)*/
Sind die 6283 die umkomprimierte Größe?

Legt man solche Bilder besser im Programmspeicher ab oder im EEprom?


Im tft.c müssten dann noch die Zeilen für die Anzeige des kleinen Bildes 
eingefügt werden.

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:

> Den Inhalt der Datei test1.binh habe ich nach tft_data.c kopiert und als
> Länge die Anzahl der Zahlen genommen (Mit MS Word zählen lassen)

Ich lasse mir einfach die Eigenschaften der xxx.bin anzeigen und nehme 
die Größe in Bytes.

> /* 61x103 pixel test-logo der Zahl 6 in compressed L8 format, length is
> ????? when uncompressed, converted with image-convert 0.9.1 from FTDI */
> const /*__flash*/ uint8_t sechs[273] PROGMEM = {
> 120, 156, 229, 216, 203, 22, 130, 48, 12, 4, 208, 252, 255, 79, 215,

> Wie bekomme ich heraus wie groß mein Test-Logo in unkompromierter Form
> ist?

Mit dem Format, L8 bedeutet in dem Fall ein Byte pro Pixel:
61 * 103 = 6283

> Welche Speicheradresse muss in in der tft.c eintragen?

Wo auch immer Platz dafür ist, die Memory-Map muss man sich einfach 
überlegen.
Wenn es komplexer werden würde, würde ich eine Excel-Tabelle dafür 
benutzen, so schlimm hatte ich das aber noch nicht. :-)

> In der Datei test1.rawh steht: (siehe Anhang)
> /*('file properties: ', 'resolution ', 61, 'x', 103, 'format ', 'L8',
> 'stride ', 61, ' total size ', 6283)*/
> Sind die 6283 die umkomprimierte Größe?

Ah okay, ja, man kann auch einfach da nachsehen. :-)

> Legt man solche Bilder besser im Programmspeicher ab oder im EEprom?

Das ist beides Sub-Optimal, aber das EEPROM ist noch viel kleiner,
von daher bevorzuge ich das FLASH.

> Im tft.c müssten dann noch die Zeilen für die Anzeige des kleinen Bildes
> eingefügt werden.

Ja, analog zu dem was für das Logo schon drin ist.

#define MEM_SECHS 0x00002000 // willkürlich im freien Speicher gewählt

TFT_init():

EVE_cmd_inflate(MEM_SECHS, sechs, sizeof(sechs));

initStaticBackground():

#if defined(FT81X_ENABLE)
  EVE_cmd_setbitmap(MEM_SECHS, EVE_L8, 61, 103);
  EVE_cmd_dl(VERTEX2F(50, 100));
#else
  EVE_cmd_dl(BITMAP_SOURCE(MEM_SECHS));
  EVE_cmd_dl(BITMAP_LAYOUT(EVE_L8,61, 103));
  EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,61,103));
  EVE_cmd_dl(VERTEX2F(50*16, 100*16));
#endif

Nur sieht man dann erstmal nichts, weil zum einen der Hintergrund weiss 
ist per EVE_cmd_dl(DL_CLEAR_RGB | WHITE); und zum anderen in der 
initStaticBackground() vor dem Logo erstmal auf Weiss gestellt wird.

Packt man noch ein EVE_cmd_dl(DL_COLOR_RGB | BLACK); vor die Zeilen in 
initStaticBackground() dann wird das Bild zwar dargestellt, aber 
invertiert.
Mit EVE_cmd_dl(DL_CLEAR_RGB | BLACK); wird das auch nicht besser.
So richtig gut kann ich das auch nicht erklären, das einfachste ist aber 
das Bild in dem Fall zu invertieren, nicht gesetzte Pixel sind schwarz, 
Pixel die nachher zu sehen sein sollen sind weiss.

[Joern DK7JB .. (moin)]

Mit deiner Hilfe habe ich es geschaft das Bild mit der Sechs mir 
anzeigen zu lassen. Dass mit der Invertierung habe ich auch festgestellt 
(siehe Anhang).

Letztlich will ich mir eine Frequenzanzeige mit großen Ziffern basteln 
(z.B. 10 000 000 Hz). Entweder bekomme ich das mit mehreren Bildern hin 
oder ich muss das mit dem Erstellen eines eigenen Fonts hinbekommen. 
Noch habe ich keine Ahnung ob man da von der Größe beschränkt ist. Das 
mit einem eigenem Font habe ich auch noch nie gemacht. Hast du oder habt 
ihr damit Erfahrung?

[Rudolph R. (rudolph)]

Fonts habe ich auch noch nicht konvertiert, die eingebauten haben für 
meine Anwendung soweit immer ausgreicht, vor allem sind mit den FT81x ja 
noch ein paar dazu gekommen.
Das ist ja mal die Gelegenheit das richtig auszuprobieren und ich spiele 
gerade etwas mit den Tools rum.
Aber bisher stellen sich sowohl der neue Assest-Manager als auch das 
Font-Convert-Tool etwas sehr zickig an...

[Joern DK7JB .. (moin)]

Hier findet du ein Video über die Konvertierung von Audio, Bildern und 
Schriftarten:
https://www.youtube.com/watch?v=IdCCanzY0Nc
Ab ca. der 9ten Minute wird etwas zu den Fonts gesagt, wenn auch nicht 
ausführlich.

Was ist ein Assest-Manager?

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Hier findet du ein Video über die Konvertierung von Audio, Bildern und
> Schriftarten:

Ha, das habe ich auch gerade gesehen, hilft irgendwie nicht. :-)

Ich habe auch gerade AN_227_FT800_Custom_Font_Implement.pdf offen, ist 
auch nicht so toll.

Inzwischen habe ich auch was konvertiert bekommen.

fnt_cvt -i Tuffy.ttf -s 100 -c setfont2 -u Numbers.txt -d 8192

Der Witz ist, das -t funktioniert überhaupt nicht, aus irgendeinem Grund 
kann die Datei dann nicht geöffnet werden.
Und ich habe das erst in ASCII und dann in UTF-8 probiert.
Mit -u ging es dann.
Nur bin ich gar nicht mal sicher, ob das auch funktioniert.

Das Resultat finde ich allerdings weitgehend unbrauchbar.

In dem erzeugten Tuffy.ttf_100_L8.PNG sieht man, dass die erzeugten 
Zeichen 56 Pixel breit und 120 Pixel hoch sind. Wobei etwa 1/4 der Höhe 
leer ist.
Wobei ich ja mit "-s 100" eine Breite von 100 Pixeln angegeben habe.
Das war auch nicht der erste Versuch, aber damit ist die tatsächliche 
Größe langsam mal im Ziel-Bereich.

Wenn man dann mal in den Unter-Ordner L8 wechselt stellt man fest, dass 
der Font unkomprimiert ist - komplett unlustig.
Also mindestens sollte man noch das Tuffy.ttf_100_L8.PNG durch das 
Image-Convert-Tool jagen.

Aber geschickter ist vermutlich wenn man sich da mal durchbeisst und 
ansieht wie das mit den Font-Metrik Daten gemeint ist und dann die 
Bilder dazu in gepackter Form anhängt.

Wobei ich nicht mal sicher bin, ob sich der Aufwand überhaupt lohnt, so 
zumindest wenn man nur Zahlen von Null bis Neun benötigt.

Zur Not, und okay, hübsch ist das nicht unbedingt, kann man auch den 
vorhandenen Font noch etwas vergrößern:

EVE_cmd_dl(CMD_LOADIDENTITY);
EVE_cmd_translate(65536 * 32, 65536 * 32);
EVE_cmd_scale(80000,80000);
EVE_cmd_translate(65536 * -32, 65536 * -32);
EVE_cmd_dl(CMD_SETMATRIX);

EVE_cmd_romfont(1,34);
EVE_cmd_text(110,90, 1, 0, "0184");
        EVE_cmd_getmatrix(BITMAP_TRANSFORM_A(256),BITMAP_TRANSFORM_B(0),BITMAP_TRANSFORM_C(0),BITMAP_TRANSFORM_D(0),BITMAP_TRANSFORM_E(256),BITMAP_TRANSFORM_F(0));

Die 80000 sind ein Faktor von ungefähr 1,2, 65536 wäre Faktor 1.
Und ja, unter 65536 wird es kleiner als 1.

Sowas geht auch:
EVE_cmd_scale(65536,90000);

Damit werden die Zahlen einfach nur höher.

EVE_cmd_scale(72000,90000);

Das funktioniert, weil cmd_text und cmd_number letztlich auch nur 
Grafiken aneinander reihen und die "Zeichen" zwar unterschiedliche 
Breiten, aber eine feste Höhe haben.
Im Fall vom Font 34 sind das 108 Pixel Höhe und die Zahlen von Null bis 
Neun haben alle 52 Pixel Breite.

Da die Fonts "nur" in L4 gespeichert sind wird das schon etwas pixelig.
Aber dafür, dass das praktisch nichts kostet ist das nicht so schlecht. 
:-)


Joern DK7JB .. schrieb:
> Was ist ein Assest-Manager?

Ein Tippfehler :-)

Das ist das neue All-in-one Konvertierungs-Tool von Bridgetek.

https://brtchip.com/eve-toolchains/
https://brtchip.com/wp-content/uploads/Utilities/EVE-Asset-Builder-setup-v0.4.2.zip

Nur frage ich mich nach allen Erfahrungen damit, wann ein Update 
kommt...

[Joern DK7JB .. (moin)]

Dein Ansatz hört sich gut hat.
Noch arbeite ich mit dem FT800, da mein Board für den FT810 nicht vor 
dem Wochenende angekommen ist.

Bis zum Font 34 kann ich beim FT800 nicht gehen, der geht doch nur bis 
31 (wenn ich das richtig gesehen habe)

Ich habe dich so verstanden, dass die Schriftvergrößerung auch mit 
EVE_cmd_scale(65536,90000);    gehen müsste. Hier mache ich dann 
irgendetwas falsch.

Zu dem bestehenden "Hello World" füge ich an andere Stelle einen zweiten 
Text ein. Es ist keine Änderung in der Schriftgröße zu erkennen.

Hier meine Eingabe:
EVE_cmd_text(10, LAYOUT_Y1 + 10, 31, 0, "Hello World!");
EVE_cmd_scale(65536,90000);
EVE_cmd_text(10, LAYOUT_Y1 + 140, 31, 0, "Hello World!");
EVE_cmd_execute();

Wende ich das EVE_cmd_scale an der falschen Stelle an?

Könntest du bitte deine Codezeilen etwas ausführlicher erklären.

[Rudolph R. (rudolph)]

Das cmd_scale() alleine reicht nicht, die anderen Zeilen gehören schon 
dazu. :-)

[Willi (Gast)]

Ohne den Befehl EVE_cmd_romfont komme ich beim FT800 dann wohl nicht 
weiter und sollte einfach warten bis der FT813 läuft.

[Rudolph R. (rudolph)]

Die FT80x gehen nur bis Font 31 und die haben "nur" eine Höhe von 49 
Pixel mit den Zahlen 24 Pixel breit.
Damit kommt man eben nicht ganz so weit, richtig.

Fonts gehen schon, nur ist das eben etwas aufwändiger.
So auf L4 mit 33k macht das keine Freude, komprimiert sind das so 
vielleicht noch 5k.
Immerhin kommt ja auch noch ein Bild aus dem Font-Konverter raus.
Und immerhin ist das schon mal nur so breit wie notwendig.

Man kann das direkt als Bild konvertieren und mit
VERTEX2II(x,y,0,Nummer) benutzen.

Aus dem einen Bild werden also mehrere Bilder direkt hintereinander.

EVE_cmd_dl(BITMAP_SOURCE(MEM_ZAHLEN));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_L8,56, 120));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,56,120));
EVE_cmd_dl(VERTEX2II((10+56*0)*16,60*16,0,0));
EVE_cmd_dl(VERTEX2II((10+56*1)*16,60*16,0,1));
EVE_cmd_dl(VERTEX2II((10+56*2)*16,60*16,0,2));

Ich hoffe, das macht so halbwegs Sinn. :-)
Man nimmt einfach die Breite und Teilt die Gesamt-Höhe des Font-Bildes 
durch die Anzahl an Bildern.

Auf die Art kann man auch einfach Animation abspielen.

EVE_cmd_dl(VERTEX2II((x,y,0,frame_number));

[Joern DK7JB .. (moin)]

Danke für deine Mühe. Ich habe jetzt die Geduld verloren und verknüpfe 
übergangsweise ein ATMega328P Board mit dem FT813-Display um es 
auszuprobieren.

[Joern DK7JB .. (moin)]

So jetzt läuft das NHD-7.0-800480FT-CSXV-CTP (Touch-Panel) mit den 
NHD-FT81x-SHIELD an einem ATMega328P. Die Qualität ist deutlich besser 
als bei meinem alten Display mit resistiven Touch.

Das Bild zeigt aber leichte Schwächen. Die weiße Hintergrundbeleuchtung 
ist leicht gelblich. Mit einem sehr leicht blauen Hintergrund 
(0x00F0F0FF) kann dies ausgeglichen werden.
Etwas störend ist, dass die gelben Pixel leicht gegenüber den anderen 
Farben verschoben sind. Dadurch ergibt sich an der linken Kante eine 
Blaufärbung und an der rechten Kante eine Gelbfärbung. Im Anhang findet 
ihr ein Bild davon.
Ist dir hierzu eine Lösungsmöglichkeit bekannt? Kann man da mit den 
Displayparametern etwas machen?


Deine Idee zur Vergrößerung der Zahlen hat gut funktioniert. Durch 
Anpassung von EVE_cmd_translate habe ich die Schriftvergrößerung 
ausgereizt. Das ist mehr als ausreichend.
Woher ist bekannt, dass die vergrößerte Schrift im Bitmap-Speicher 1 
liegt?


Welchen Vorteil bringt der eigentlich der Media_FIFO beim FT813? Kann 
man jetzt leichter PNG-Bilddateien laden und anzeigen?


In der nächsten Zeit werde ich versuchen eine Art Pulldown-Auswahlmenü 
aufzubauen.

[Joern DK7JB .. (moin)]

Ich habe das mit dem Farbsaum/Bildfehler jetzt weiter untersucht.
Da gibt es entweder einen Fehler beim Bildschirm oder beim FT813.
Das Bild im Anhang zeigt die folgenden drei Linien, die mit folgendem 
Code erzeugt worden sind:

    EVE_cmd_dl(VERTEX_FORMAT(0));
    EVE_cmd_dl(LINE_WIDTH(8));
    EVE_cmd_dl(DL_COLOR_RGB | 0x00FF0000);
    EVE_cmd_dl(DL_BEGIN | EVE_LINES);
    EVE_cmd_dl(VERTEX2F(100,153));
    EVE_cmd_dl(VERTEX2F(150,153));
    EVE_cmd_dl(DL_END);

    EVE_cmd_dl(DL_COLOR_RGB | 0x0000FF00);
    EVE_cmd_dl(DL_BEGIN | EVE_LINES);
    EVE_cmd_dl(VERTEX2F(100,156));
    EVE_cmd_dl(VERTEX2F(150,156));
    EVE_cmd_dl(DL_END);

    EVE_cmd_dl(DL_COLOR_RGB | 0x000000FF);
    EVE_cmd_dl(DL_BEGIN | EVE_LINES);
    EVE_cmd_dl(VERTEX2F(100,159));
    EVE_cmd_dl(VERTEX2F(150,159));
    EVE_cmd_dl(DL_END);

    EVE_cmd_dl(DL_COLOR_RGB | 0x000000FF);
    EVE_cmd_dl(DL_BEGIN | EVE_LINES);
    EVE_cmd_dl(VERTEX2F(99,162));
    EVE_cmd_dl(VERTEX2F(149,162));
    EVE_cmd_dl(DL_END);

Die dritte Linie ist um einen Pixel nach rechts verschoben.
Die vierte Linie wäre eigentlich richtig, hat aber andere Koordinaten.

Ich würde interessant finden ob auch bei deinem Display ein solcher 
Fehler zu beobachten ist.

Das Foto wurde mit einem Handy durch eine Lupe hindurch aufgenommen. Das 
geht recht gut.

[Rudolph R. (rudolph)]

Also das mit den Farben ist mir noch nie so krass aufgefallen, das NHD 
3,5 was ich hier habe kann ich aber noch nicht mal mehr anschliessen.
Ein EVE2-36G habe ich noch hier, das kann ich mal probieren.

Hast Du die Hintergrund-Beleuchtung mal ein klein wenig verstellt?

> Woher ist bekannt, dass die vergrößerte Schrift im Bitmap-Speicher 1
> liegt?

Das "EVE_cmd_romfont(1,34);" macht das.

> Welchen Vorteil bringt der eigentlich der Media_FIFO beim FT813?

Mann kann größere Datenmengen besser am Stück übertragen, etwa Videos.
In der Demo von FTDI richten die glaube ich einen 64k FIFO ein.

> Kann man jetzt leichter PNG-Bilddateien laden und anzeigen?

Nein, überhaupt nicht, bestenfalls ist die Übertragung geringfügig 
schneller bei grossen Bildern da das in weniger Häppchen zerlegt werden 
muss bei entsprechend weniger Overhead für die Adressierung.
Das die FT81x locker 10 Mal so lange brauchen um .png zu entpacken und 
zickig beim Format sind bleibt aber.

[Joern DK7JB .. (moin)]

Es wäre schön, wenn du dir es mal bei deinem EVE2-36G ansehen könntest.
Bei schwarzem Hintergrund kann man es am besten mit der Lupe sehen.
Sehr deutlich fällt derEffekt bei senkrechten hellgrünen und schwarzen 
Strichen auf wenn der Hintergrund weiß ist. Der Fehler ist halber und 
bei vollter Helligkleit zu sehen.
Wenn der Fehler bei dir nicht auftritt werde ich mich erst beim 
Displayhersteller und dann beim Distributor Mouser melden.

Gibt es die Möglichkeit vor jeder Anzeige mit einer 
Transformationsmatrix nur den blauen Kanal für den gesammten Bildschirm 
um ein Pixel nach links zu schieben?

[Rudolph R. (rudolph)]

Ich habe weder eine Lupe da, noch eine Kamera die tauglich wäre, nur 
dieses hässliche und billige USB-"Mikroscope" und die Win10 Kamera-App 
dazu.
Ich kann zum Beispiel die Beleuchtung weder verstellen noch gar 
abschalten.

Das Bild zeigt drei vertikale Linien mit etwas Abstand zueinander auf 
schwarzem Hintergrund:

EVE_cmd_dl(VERTEX_FORMAT(0));
EVE_cmd_dl(LINE_WIDTH(1*16));
EVE_cmd_dl(DL_BEGIN | EVE_LINES);
EVE_cmd_dl(DL_COLOR_RGB | 0x00FF0000);
EVE_cmd_dl(VERTEX2F(120, 70));
EVE_cmd_dl(VERTEX2F(120,90));
EVE_cmd_dl(DL_COLOR_RGB | 0x0000FF00);
EVE_cmd_dl(VERTEX2F(124, 70));
EVE_cmd_dl(VERTEX2F(124,90));
EVE_cmd_dl(DL_COLOR_RGB | 0x000000FF);
EVE_cmd_dl(VERTEX2F(128, 70));
EVE_cmd_dl(VERTEX2F(128,90));
EVE_cmd_dl(DL_END);

Was man sieht ist, dass die Linien quasi noch etwas verstärkt werden, 
indem die benachbarten Pixel auch mit eingeschaltet werden, aber 
dunkler.
Wenn man die Linien dichter zusammen schiebt wird es etwas seltsam, aber 
deutlich getrennt sieht man was der FT813 da so treibt.

Ich denke mal, dass da ein globales Dithering am Werk ist das zum Ziel 
hat die Bildqualität zu verbessern und ich denke mal nicht, dass man das 
abschalten oder wirklich beeinflussen kann.

[Joern DK7JB .. (moin)]

Könntest du dir bitte auch drei waagerechte Linien anzeigen lassen.
Vermutlich hat dann wohl mein Display ein Macke und muss getauscht 
werden.

[Rudolph R. (rudolph)]

Okay, die Linien-Breite geht da mit ein.
Mit EVE_cmd_dl(LINE_WIDTH(8)); sieht das ganz anders aus als mit 
EVE_cmd_dl(LINE_WIDTH(16));

Die Beeinflussung der benachbarten Pixel ist dann fast weg.

Ich bin aber nicht sicher, ob das so wirklich besser aussieht.

[Joern DK7JB .. (moin)]

Wenn bei dir generell keine Farbsäume zu sehen sind, muss es an meinem 
Display liegen. Nach den Feiertagen werde ich mich dann beim Distributor 
melden.

[Rudolph R. (rudolph)]

Doch, das ist genau das gleiche wie bei Dir.
Aber was wirklich einen Unterschied macht ist die Linien-Breite.

Mit einer Breite von 8 wird das Dithering wohl weitgehend ausgehebelt in 
dem Sinne das die benachbarten Pixel nicht mehr mit eingeschaltet 
werden.

Also ich denke das ist Absicht und das soll das Bild verbessern.

Wenn das Ergebnis bei Bildern ein Schatten ist - eher uncool.
Aber in der Regel sollte das nicht so sehr auffallen.

[Joern DK7JB .. (moin)]

Danke für deine Mühe. Bei mir ist der Effekt bei einer Farbe nur 
deutlich  stärker.

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> Bei mir ist der Effekt bei einer Farbe nur deutlich  stärker.

Meinst Du wirklich? Ich finde das sieht gleich aus.
Und was passiert denn bei Dir wenn Du die Breite von 16 auf 8 runter 
setzt?

[Joern DK7JB .. (moin)]

Hallo Rudolf
hast du vielleicht ein Beispiel um ein größeres JPEG-Bild von einem der 
größeren ATMegas in voller Farbe in einen FT813 zu laden und dann 
anzuzeigen? Irgendetwas was noch so gerade mit dem begrenzen Speicher 
harmoniert?

[Rudolph R. (rudolph)]

Na, da gibt es eigentlich nichts besonders zu, hauptsache das Bild passt 
halt noch in den Speicher.

Ich habe mir gerade ein freies Bild vom Mars bei der NASA runtergeladen, 
das auf 800xirgendwas skaliert, auf 800x480 geschnitten und wieder 
gespeichert.

PIA01924~orig.jpg - 256KB, 1408x1107 Pixel.
In 800x480 hat das .jpg bei 80% 80,1KB, bei 70% 70,7KB und bei 50% 
42,1KB.

Als 50% JPEG müsste das also in den M644 passen.

Je nach Bild wird das eben kleiner oder größer.

Zum Bearbeiten und Speichern nutze ich Irfan-View.
Ach ja, die Meta-Daten (EXIF) kann man beim Speichern auch gleich 
verlieren, die kosten in dem Zusammenhang nur Platz.

Als nächstes muss das in Quellcode gekippt werden.
Etwa indem man das mit Hex Workshop in eine C Quelldatei exportiert.
Das geht bestimmt auch einfacher, hab länger nicht nach einem Tool dafür 
gesucht und keinen Bock gehabt selber was zu schreiben.

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);

Also nichts besonderes, soweit.

Was man auch machen könnte ist Bilder von SD-Karte zu laden.
Das ist aber eine ganz andere Baustelle, dabei kann ich wenig bis gar 
nicht helfen.
Was funktionieren sollte ist einen Media-FIFO einzurichten, das 
cmd_loadimage() mit EVE_OPT_MEDIAFIFO zu benutzen und die Daten Block 
für Block von SD zu lesen und in den Media-FIFO schreiben.
Nicht, dass ich sowas schon mal probiert hätte.

[Christian W. (Gast)]

Kurze Rückmeldung bezüglich dem Arduino DUE:

Auch hier funktioniert der von dir gelieferte Code ohne weitere 
Änderungen tadellos !

SPI dann "herkömmlich" und nicht unter Hardware-Kontrolle.


Lag also wirklich daran, das der FT813 von meinem Display defekt ist.
Habe gestern mein neues geliefert bekommen, kurz alles angeschlossen und 
den bisherigen Sketch hochgeladen (CS darf natürlich nicht auf Pin 10 
oder einem der anderen beiden "Hardware-SPI" Pins liegen beim DUE...) 
und es läuft sofort tadellos.

Ich hätte noch eine Frage/Bitte:

Für mein Projekt würde ich die TFT.cpp gerne soweit wie möglich 
ausdünnen.

Die Fallunterscheidung würde ich gerne so weiter behalten, allerdings 
bin ich mir recht unsicher, welche Teile in deiner Fallunterscheidung 
wegfallen können.

Steige nicht ganz durch welche Variablen und Funktionen für das 
Beispielbild gebraucht werden, und welche grundlegend zu erhalten sind.

Wäre es vielleicht möglich das du eine "rohe" TFT.cpp hochlädst?

So das alle Funktionen erhalten bleiben, aber nichts angezeigt wird?

[Rudolph R. (rudolph)]

Noch weniger? Aber das Ding macht doch schon praktisch nichts mehr. :-)
Zerleg das Ding doch einfach erstmal nach Belieben. :-)

[Juergen (Gast)]

Hallo Rudolf,
Wir benutzen schon seit einiger Zeit den FT81x und wollen nun auf den 
BT815 umsatteln. Nun hatte ich gesehen dass bereits die erstem Dinge für 
den BT in deiner Library beinhaltet sind. Hast Du schon Erfahrungem mit 
dem BT oder schon was am laufen damit?Oder Erfahrung mit kompatibilität 
zum FT81  bzw handhabung des Flashes des BT?
Jueegen

[Rudolph R. (rudolph)]

Ich habe leider noch kein Display mit dem BT81x in die Finger bekommen.
Die Module von Bridgetek selber finde ich jetzt nicht so interessant, 
resistiv touch will ich nicht mehr haben.
Und von den wenigen Herstellern hat wohl bisher nur Riverdi Module am 
Start, deren Datenblätter habe ich am Wochenende runter geladen.
Bei Riverdi hätte ich auch schon fast ein Modul bestellt, aber die 
Versandkosten haben mich etwas abgeschreckt und woanders als direkt bei 
Riverdi habe ich die noch nicht gefunden.

Matrix Orbital müsste eigentlich demnächst mal was am Start haben.

Von Newhaven habe ich auch noch nichts gefunden.

Eigentlich hatte ich gehofft schon letztes Jahr an ein Display zu 
kommen, ich war da auch im Kontakt, nur habe ich bisher nichts erhalten.


Das gesagt, ich bin schon durch das Datenblatt und das User-Manual 
gegangen und grundsätzlich sollte Code für den FT81x direkt auf dem 
BT81x laufeb.
Die sind so ähnlich das ich den BT81x nur als Erweiterung in den 
Includes behandel, im ersten Ansatz kommt "nur" ein bisschen was dazu.
Und zumindest die Includes meiner "Library" in 4.x sollten soweit 
vollständig sein.

Neue Kommandos müsste ich noch implementieren.
Und das neue cmd_text() braucht eine varargs Funktion, sowas würde ich 
aber lieber auch testen können als das nur als Trocken-Übung zu machen.

Mit dem externen Flash wird es auch noch interessant.
Bridgetek darf gerne mal den Asset-Manager pflegen, das wäre hilfreich.

[Rudolph (Gast)]

So, und woher bekomme ich jetzt ein RVT70UQBNWC00? :-)
Google kann mit der Bezeichnung bis jetzt nicht mal was anfangen, das 
zieht sich dann wohl noch ein wenig hin.

Oder mit anderen Worten, wo bekommt man die Dinger schon?

[flux (Gast)]

Lieber Rudolph, ich bin zwar noch kein Nutzer deiner Library, würde dich 
aber gern mit einem BT816 (inkl. externen Flash) Display Modul 
unterstützten.
Gibt es eine Möglichkeit dich privat (per Mail ?) zu kontaktieren ?

[Rudolph R. (rudolph)]

Hallo,

das ist nett, danke, aber sooo lange kann das jetzt auch nicht mehr hin 
sein bis ich ein Modul in die Finger bekomme. :-)

Auf der anderen Seite habe ich auch gerade viel um die Ohren, unter 
anderem auch damit ein Display mal so richtig zu benutzen, so in einem 
Kunden-Projekt. :-)
Irgendwann zwischendurch müsste ich auch mal herausfinden wie man mit 
dem ATSAMC21 SPI per DMA macht...
Die Doku in den Datenblättern war auch mal umfangreicher...

Stichwort Mail, wenn ich hier direkt eine Adresse rein schreibe komme 
ich doch mit dem Löschen vom Spam wieder nicht hinterher. :-)
Da ich hier aber (meistens) angemeldet schreibe ist eine 
Benutzer-Nachricht über das Forum auf jeden Fall eine Alternative.
Wenn da eine Mail-Adresse bei ist kann dann auch meine Antwort direkt an 
diese Adresse schicken.

[Rudolph R. (rudolph)]

Nächste Woche ist die Embedded World in Nürnberg, mal schauen wie es 
dann weiter geht.

Ich rechne zum Beispiel damit das FTDI/BRT eine HD Demo am Stand haben 
werden.
https://brtchip.com/Brochures/BT815_6%20Demosheet.pdf
Das arbeitet mit einem zusätzlichen RGB->LVDS Chip und das lässt doch 
hoffen, dass es irgendwann BT8xx mit LVDS Interface geben wird.


Riverdi hat ja schon länger diverse Module auf Ihrer Webseite gelistet.
Nur einen Lieferanten habe ich dafür noch nicht gefunden.
TME hofft darauf Ende März welche zu bekommen.
Riverdi ist nicht auf der Embedded World.


Matrix Orbital ist auf der Embedded World und wird sicher was 
vorstellen.
https://www.matrixorbital.com/ftdi-eve/eve-bt815/eve3-70a
Da sind unter anderem Arduino UNO und NANO Pin-Reihen in den Zeichnungen 
zu sehen, mir geht gerade durch den Kopf dafür ein Board mit einem 
ATSAMC21 zu entwerfen um das dann direkt da anzulöten.


Glyn ist auch auf der Embedded World, ich rechne aber irgendwie nicht 
damit das ADAM50-LCP-WVGA-NEW-BT815 am Stand zu finden.
Und selbst wenn, privat kaufen könnte ich das vermutlich eh nicht und 
bis auf den Namen ist mir praktisch nichts dazu bekannt.


Von Newhaven Display ist soweit noch gar nichts zu sehen, die sind 
dieses Jahr auch nicht auf der Embedded World.


4D Systems ist dieses Jahr auch nicht auf der Embedded World, aber die 
sind ziemlich sicher raus und werden unter "EVE Solutions" auf der FTDI 
Homepage nicht mal mehr aufgeführt.


Die 4.0 meiner Code-Library ist weiter in Arbeit, da fehlt aber immer 
noch einiges spezifisch für die BT8xx.
Für mein aktuelles Projekt habe ich einen ATSAMC21E18A verwendet und 
sogar DMA implementiert.
Leider halbiert das bis jetzt nur in etwa die Zeit die der Controller 
damit beschäftigt ist eine Display-Liste zu erstellen.

[Joern DK7JB .. (moin)]

Hallo Rudolf,
hast du dir auf der Embedded World Displays mit dem BT815 ansehen oder 
sogar kaufen können?

[Rudolph R. (rudolph)]

Es gab schon was zu sehen auf der Embedded World, angehängt ein Foto das 
ich am FTDI/BRT Stand von deren HD-Demo gemacht habe, nur meinen Spruch 
die sollen mir so ein Ding schicken habe nicht mal ich Ernst genommen. 
:-)


Matrix Orbital sind leider noch nicht ganz fertig mit ihrer neuen 
Display-Reihe.
Das war zwar der Plan, aber nun ja, das braucht noch ein wenig mehr 
Zeit.
Jetzt im Moment lädt nicht mal die Webseite, dürfte aber nur für eine 
Wartung down sein, am Samstag haben die sich auf den Heimweg nach Kanada 
gemacht.

Ich konnte allerdings am Stand von Matrix Orbital zum einen zwei neue 
Module begutachten und die sind ganz gut mit Funktionen bestückt.
Das eine war das EVE3-70A das man praktisch wie ein fettes Arduino 
Shield benutzen kann.
Das zweite war ein kleineres für das ich noch keine Ankündigung gesehen 
habe.

Matrix Orbital hätte mir vermutlich auch ein fertiges Modul zur 
Verfügung gestellt, obwohl (oder vielleicht auch weil) ich vorab drum 
gebeten habe, dass sie mir eines verkaufen.
Nur hatten sie noch keines soweit das dem angestrebten 
Auslieferungsstand entspricht.

Aber, Matrix Orbital hat mir eine ältere Version der Platine zur 
Verfügung gestellt die an dem EVE3-70A Verwendung finden wird, eine 
0.0.1 während die eine die sah mit 1.0.0 markiert war.
Da ist dran rumgelötet, da sind Bugs drin, da ist ein BT816 bestückt, 
egal, jetzt habe ich was zum Testen. :-)
Am Samstag habe ich einen ersten Test gemacht und das Panel von einem 
EVE2-43G da angeschlossen.
Und es lief soweit auf Anhieb, wenn auch ohne Touch weil das Panel eben 
kapazitiv ist.
Gestern habe ich mich mit dem USB Treiber für das USB<>SPI Interface 
rumgeschlagen um mit dem EVE Asset Manager da drauf zu kommen.
Ich habe es dann geschafft per USB das FLASH mit dem notwendigen 
Binär-Blob zu beschreiben und danach konnte ich per Software das FLASH 
in den Fast-Modus bringen.
Aus irgendeinem Grund bekomme ich auf das FLASH nur über die ersten 4k 
hinaus aber nichts drauf, ich werde die Platine selber wohl noch etwas 
patchen müssen.
Nur wollte ich nicht sofort nach Unterlagen fragen und die erstmal 
wieder richtig zu Hause ankommen lassen.
Ich werde die Platine erstmal richtig begutachten und vielleicht tausche 
ich auch das FLASH.

Ein Anfang ist aber definitiv gemacht, grundsätzlich kann man was 
anzeigen und zumindest der Support für das FLASH ist da, fehlen "nur" 
noch die Funktionen damit man mit dem FLASH auch richtig was anfangen 
kann.

[Rudolph R. (rudolph)]

Inzwischen hat sich herausgestellt, dass FLASH läuft einwandfrei auf der 
BT816 Platine und lässt sich auch mit dem EVE Asset Builder beschreiben.
Es kommt zwar jedes einzelne Mal eine Fehlermeldung, dass das FLASH 
nicht richtig beschrieben werden konnte.
Wenn ich den Inhalt aber zurück lese und mit der Datei vergleiche die 
rein geschrieben werden sollte - 100% identisch.
Also der EVE Assent Builder bzw. das progflash.exe das da aufgerufen 
wird erzeugt eine Fehlermeldung obwohl scheinbar gar kein Fehler 
vorliegt...

Meine Initialisierungsfunktion EVE_init_flash(); funktioniert auch 
einwandfrei.

Ein Bild aus dem FLASH anzeigen lassen:

EVE_cmd_setbitmap(0x800000 | (4736/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 64, 64);
        
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(VERTEX2F(100, 100));
EVE_cmd_dl(DL_END);

Das 0x800000 gibt an, dass die Adresse im FLASH liegt und "(4736/32)" 
ist die Adresse im Flash, angegeben als Block von 32 Bytes Länge.

Der EVE Asset Builder gibt eine output.map Datei mit aus.
Da stehen die Datei-Namen der Daten drin, die Anfangs-Adresse und die 
Länge.

Die .map mit in das FLASH zu bringen und zu parsen geht auch, das ist 
mir persönlich aber zu lästig, Matrix Orbital haben das in Ihrem 
Beispiel aber wohl so gemacht:
https://github.com/MatrixOrbital/EVE-BT81x-Flash

[Rudolph R. (rudolph)]

Anyone else already playing with a BT81x?
I am currently adding more new BT81x functions.

[Rudolph R. (rudolph)]

Die ersten BT81x Displays sind jetzt verfügbar, ich habe gerade ein 
RVT43ULBNWC00 von Riverdi bei TME bestellt.

Und Matrix Orbital hat inzwischen eine komplette EVE3 Serie angekündigt.

Bei Newhaven Display kann ich immer noch nichts zu BT81x finden.

[Joern DK7JB .. (moin)]

Das sind doch schonmal super Nachrichten. Ich werde mein aktuelles 
Projekt nun schnell beenden, damit ich mich in ca. zwei Wochen auch mit 
dem Display beschäftigen kann.
Wie sieht eigentlich dein Experimentierboard aus? Um alles einfacher zu 
machen könnten wir uns vielleicht auf eine Experimentierplatine mit 
einem ATmega einigen, z.B. einem ATmega644PA. Was meinst du? Die Platine 
könnte ich dann layouten (mit Eagle) und für sehr kleines Geld 
anfertigen lassen. Als Schaltregler würde ich dann den LT8708 nehmen. 
Ich habe mir gerade zu diesem IC ein Board machen lassen und werde 
hiermit experimentieren.
... oder wäre der ATmega644PA für deine Experimente schon zu langsam?

[Rudolph R. (rudolph)]

Ich benutze jetzt gar keine AVR mehr, ich bin umgestiegen auf 
ATSAMC21E18A-AU und ATSAME51J19A-AU.
Und gar nicht mal weil die AVR zu langsam wären, ich brauche CAN-FD für 
den Job und vorzugsweise Automotive Bauteile.

Mein gerade so noch aktuelles Projekt habe ich mit der Platine 
D5019-03-01 bearbeitet, das ist ein C21, ein ADP2301, ein TLE4266-2G. 
ein TJA1043, ein 74LC125 und ein 74LVC1G125GV.
Also Controller, LDO, Schaltregler, CAN-Transceiver und Level-Shifter.
Das Teil habe ich extra so geformt das es auf die Rückseite von einem 
Matrix Orbital EVE2-70G passt.
Ach ja, oben Links ist noch ein Lautsprecher, den habe ich aber noch 
nicht ausprobiert.

Wobei das quasi ein Fehler war den Controller auf 5V laufen zu lassen, 
das ist in der Anwendung überhaupt nicht notwendig und somit auch der 
Level-Shifter überflüssig.


Davor ist die Platine D5019-01-02 entstanden, die sollte eigentlich mal 
in meinem 3D-Drucker verbaut werden.
Das ist einfach nur Schaltregler und Level-Shifter.
Der kleine weiße Stecker ist ein BM07B-SRSS-TB.

Diese Platine hängt hier gerade an meinem zusammen geschustertem 4.3" 
TFT mit der BT816 Platine von Matrix Orbital.

Es gibt noch eine D5019-02-02, die ist sehr kompakt, nur Schaltregler, 
Level-Shifter, Folien-Anschluss und der weiße Stecker.
Der wird jetzt noch eine D5019-02-03 folgen, ohne Level-Shifter.


Die Platine SAMC21_one war mein erster Versuch sowas wie ein Steuergerät 
zu bauen, wenig mehr als Versorgung und CAN, aber auch mit dem weißen 
Stecker für das Display.

Und aktuell habe ich die D5025-01-01 auf dem Tisch, ebenso ein eher 
experimentelles Steuergerät, der zweite Schuss mit dem ATSAME51 ohne 
wirklich Anforderungen gehabt zu haben.
Das hat 2x CAN, 2x LIN, 2x APA-102, 4x ADC und den Display-Anschluss.

Mit diesem Board habe ich die letzen Änderungen für den BT81x 
implementiert und getestet.
Auf dem C21 läuft das Display per DMA, für den E51 habe ich mir DMA 
bisher noch nicht mal angesehen.

Also die Strategie die ich da gerade verfolge ist den Schaltregler und 
den Folien-Anschluss von der Steuerplatine zu nehmen und nur einen 
BM07B-SRSS-TB ohne weitere Komponenten vorzuhalten.
Die Versorgung erfolgt dabei über 12V Bordnetz-Spannung.
Das erlaubt Geräte für praktisch beliebige Anwendungen zu bauen und 
nebenbei auch noch Display-fähig zu machen.

Die D5019-03-01 war da eine Ausnahme, da war im Projekt von vornherein 
geplant das Display über CAN an eine größere Steuer-Einheit anzubinden.


Das kann ich alles recht freizügig zeigen, weil ich das in meiner 
Freizeit entwickelt habe und ohne Auftrag durch meinen Arbeitgeber, auch 
wenn das zum Teil schon für den Job ist.
Nur veröffentlichen kann ich das so nicht, da sind einfach zu viele 
Referenzen auf meinen Arbeitgeber drin, Zeichnungsrahmen, 
Projekt-Vorlage, möglicherweise Bauteil-Referenzen.
Aber veröffentlichen wäre sowieso nur begrenzt hilfreich, weil das alles 
in Altium Designer entstanden ist.


Also die Text-Wand soll nicht überzeugen was anderes zu nehmen, nur mal 
aufzeigen wo ich gerade so stehe. :-)
Speziell mit den BT81x wird man auch den ganzen Speicher nicht mehr 
benötigen, zumindest nicht für die Anzeige.


Joern DK7JB .. schrieb:
> Als Schaltregler würde ich dann den LT8708 nehmen.

Wuff, ist das nicht ein klein wenig überkomplex, vor allem für ein 
Experimentierboard? :-)
Ich meine ja, ich müsste mir noch mal einen anderen Regler ansehen, aber 
so weit würde ich da dann auch nicht gehen wollen. :-)

[Joern DK7JB .. (moin)]

Hallo Rudolf,
ich habe mir nun ein 7" Display von Riverdi RVT70UQBNWC00 bestellt. 
Morgen kann ich den ersten Test durchführen. Betreiben möchte ich das 
Display mit einem ATmega644PA über das Riverdi-ARDUINO-TFT-SHIELD. Das 
Shield hat für mich den Vorteil, dass ich dann eine funktionierende 
Hardware habe. Die Arduino-Programmierumgebung interessiert mich nicht. 
Wie bisher möchte ich mit dem AtmelStudio unter C programmieren.
Mein altes 7"-FT813-Display mit dem Grafikfehler konnte ich zurückgeben.
Wo muss ich Anpassungen an den Dateien vornehmen, die ich von deiner 
GitHub-Seite geladen habe? Oder sollte ich noch einige Zeit warten, bis 
du mit der Bibliothek fertig bist? PLanst du auch ein Beispie mit einem 
ATmega?

[Rudolph (Gast)]

Ich muss noch die Display-Konfigurationen nachtragen, für die neuen 
Riverdi gibt es bis jetzt noch nichts.
Das sollte aber recht flink gehen und das 4.3" müsste ich jetzt zu Hause 
haben, so kann ich das dann auch noch testen.

Dann fehlt zwar immer noch ein bisschen was, aber grundsätzlich 
benutzbar wären die BT81x ja schon länger.
Ich habe auch den Eindruck das da mal ein bisschen was optimiert werden 
muss.

Neue AVR Beispiele habe ich erstmal nicht geplant, aber das bisschen das 
Target spezifisch ist hat sich sowieso nicht geändert.
Was auf dem FT813 läuft sollte 1:1 auf dem BT815 laufen.

[Rudolph R. (rudolph)]

Ich habe das RVT43ULBNWC00 erhalten, das läuft hier gerade so vor sich 
hin.
Vorher habe ich noch kurz mein EVE2-USB2SPI-KIT-A benutzt um das 
Flash-File das ich zum testen benutze per EVE Asset Builder in das 
64MBit Flash zu brennen das Riverdi da drauf gepackt hat.

Auf Github liegt eine neue EVE_config.h.

Es gibt neue Config-Einträge:

EVE_RiTFT43
EVE_RiTFT50
EVE_RiTFT70

Ich glaube ich muss das langsam mal alles in Excel werfen um die Datei 
mal etwas kompakter zu bekommen. :-)

Interessant ist, die neuen Module von Riverdi haben einen Quarz.

Wobei mir gerade so auffällt, ich setze den Takt von dem BT81x noch gar 
nicht hoch auf die 72MHz.
Per Default ist der auf 60MHz wie der FT81x und damit passen auch 
erstmal die Einstellungen für die Panels.

[Dennis D. (the_ease)]

Moinsen,

hab hier ein Riverdi RVT70UQBNWC00 und hab den SPI Teil auf meinen 
MSP430F5510 angepasst. Hab schonmal ein Bild bekommen.

Danke für die tolle library!

Jetzt gehts dann ins Detail...

[Rudolph R. (rudolph)]

Für den MSP430F5510 wird doch inzwischen bestimmt auch GCC benutzt?
Die MSP habe ich mir nie näher angesehen, als ich vor der Entscheidung 
stand ob nun AVR, MSP oder PIC fiel meine Wahl auf den AVR, weil es zu 
der Zeit nur kommerzielle Compiler für MSP und PIC gab, für den AVR aber 
schon GCC.

Wenn Du für den eine Konfiguration in der EVE_config.h geschrieben hast, 
gerne posten, das baue ich dann mit ein.

Für den STM32 habe ich zum Beispiel auch noch nichts.
So mal in den Raum geworfen. :-)

[Rudolph R. (rudolph)]

Sieht so aus als ob ein ganzer Satz von den Matrix Orbital EVE3-xxx 
Modulen jetzt verfügbar ist: 
https://www.matrixorbital.com/ftdi-eve/eve-bt815-bt816

Die kommen ohne, mit 32MBit oder 128MBit Flash.

Die finde ich nur noch nicht bei DigiKey oder Mouser.
Wenn jemand einen Lieferanten dafür hat der an privat liefert und sich 
auch noch wie Mouser und DigiKey um den Zoll kümmert - raus damit. :-)

Ich würde spontan mindestens ein EVE3-35G und ein EVE3-70G mit jeweils 
128MBit Flash ordern wollen.
Das EVE3-35G vielleicht auch ohne Flash um da ein größeres drauf zu 
bestücken. :-)

Laut der Doku ist da jetzt auch ein 12MHz Resonator bestückt.

[Joern DK7JB .. (moin)]

Hallo Rudolf,
hat du schon TTF-Schrift mit dem EVE-Asset-Builder umgewandelt und dann 
eingebunden?

Für mich ergeben sich folgende Fragen:
- Sind alle Einstellungen im EVE-Asset-Builder richtig gewählt? 
(angehängtes Bild) Ist dir bekannt warum an dieser Stelle eine 
Speicheradresse angegeben werden muss? Was macht man, wenn zwei 
Schriften oder zwei Schriftgrößen verwendet werden sollen?
- Wie wird die neue Schrift richtig eingebunden und verwendet?


Für meine Experimente habe ich mir eine Schrift unter der CC-0 Lizenz 
herausgesucht um sie verarbeiten und nutzen zu können (Ist das die 
passende Lizenz?)
Link: https://fontlibrary.org/de/font/vegur

[Rudolph R. (rudolph)]

Joern DK7JB .. schrieb:
> hat du schon TTF-Schrift mit dem EVE-Asset-Builder umgewandelt und dann
> eingebunden?

Nein, habe ich nicht, irgendwie habe ich mich da noch nicht wirklich 
heran getraut, bzw. ich hatte dafür auch noch keine richtige Verwendung.

Das erste Problem damit ist schon mal das ich gar keine Vorstellung 
habe, wie man die Zeichen überhaupt eingegeben und übertragen bekommt.
Also wie Tippe UTF-8 überhaupt richtig in den Quellcode und was passiert 
damit wenn man das als Byte Array behandelt?

Das zweite Problem das ich jetzt auch aktuell in einem Projekt hatte, 
cmd_text() frisst ordentlich von den 8kB der Display-Liste.
Letztlich wird für jedes Zeichen das Bild dazu angezeigt und das landet 
als Liste von VERTEX2II() oder CELL()/VERTEX2F() Calls im Speicher.

Ich habe bisher nicht mal eine Vorstellung davon wie sowas mit UTF-8 
funktionieren können soll.
CELL() hat überhaupt nur 7 Bits.
Da nichts anderes im Manual steht müsste der BT8xx eigentlich anfangen 
mit den Bitmap-Handles zu tricksen.

Ich habe es kurz probiert, aber ich bekomme spontan keinen Font in den 
Screen Editor eingebunden.

Das dritte Problem ist, es könnte gut sein, dass das noch gar nicht 
alles so funktioniert mit den BT8xx wie es sollte und der EVE Asset 
Builder steht leider auch immer noch auf 0.4.2 von Anfang Oktober.


Das letzte was in der Richtung unternommen habe war mir mit Excel eine 
Tabelle von Button-Beschriftungen zu erstellen, so mit Sonder-Zeichen, 
einen Screenshot davon zu machen und das als Multi-Image zu benutzen, 
quasi wie einen Font mit Bitmap-Handle und Cell, nur von Hand und mit 
Zeichenketten pro Bild.
Das ist so flexibel wie ein Meter Bahnschiene, aber dafür ohne Stress 
mit allem was man in Excell so eintippen kann.
Inklusive '°' ohne komische Tricks wie ein 'o' in kleiner verschoben 
anzuzeigen.


Und Lizenz für den Font, richtig, das muss ich auch noch erkunden, 
schliesslich will ich das Produkt auch weiter geben dürfen.

[Rudolph R. (rudolph)]

Okay, ich schaue mir das gerade an und so richtig klar ist mir nicht was 
man tun muss um einen Font zu konvertieren.

Der EVE Asset Builder funktioniert leider nicht so wie im UserGuide.pdf 
dazu beschrieben ist, man kann zum Beispiel bei "User Defined Character 
Set" praktisch nichts einstellen.

Konvertiert man das einfach so ohne "User Defined Character Set" werden 
vier Dateien generiert:

Fontname.c
Fontname.glyph
Fontname.json
Fontname.xfont

Wenn ich das in dem .c richtig verstehe dann wird die .glyph in das 
FLASH geschrieben und die .xfont muss im RAM_G stehen, okay.
Okay, die .xfont kann man ja auch aus dem FLASH nach RAM_G kopieren, das 
muss nur auf einer Adresse mit 32 Bit Alignment landen.
Das Beispiel im Programming Guide verwendet Adresse 100000 -> 0x186a0

Die FLASH Adresse die per Default auf 4096 eingestellt wird ist wohl 
wichtig, ich vermute stark, dass in der .xfont die Adressen für die 
einzelnen Glyphen stehen.

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.

Das könnte eine Weile dauern bis man ein Set hat das einem gefällt.

Passt der erste Font nicht so ganz, muss man alle anderen noch mal 
konvertieren.

Und wahlfrei Dateien im FLASH anordnen kann man auch nicht, auf welchen 
Adressen was landet optimiert der Asset Builder selber.


Was der EVE Screen Editor in dem "unicode_font" Beispiel macht wenn man 
das etwas editiert ist interessant.

Aus:
CLEAR(1, 1, 1)
CMD_FLASHFAST()

CMD_SETFONT2(0,0,32)
CMD_TEXT(338, 159, 0, 0, "Tür")

Wird:
  Raw  Text
1  0x05000000  BITMAP_HANDLE(0)
2  0x28000000  BITMAP_LAYOUT_H(0, 0)
3  0x07f86004  BITMAP_LAYOUT(GLFORMAT, 48, 4)
4  0x2e0093b6  BITMAP_EXT_FORMAT(COMPRESSED_RGBA_ASTC_8x6_KHR)
5  0x2f00024a  BITMAP_SWIZZLE(ONE, ONE, ONE, RED)
6  0x29000000  BITMAP_SIZE_H(0, 0)
7  0x08003018  BITMAP_SIZE(NEAREST, BORDER, BORDER, 24, 24)
8  0x22000000  SAVE_CONTEXT()
9  0x27000002  VERTEX_FORMAT(2)
10  0x06000000  CELL(0)
11  0x05000000  BITMAP_HANDLE(0)
12  0x1f000001  BEGIN(BITMAPS)
13  0x01826ca4  BITMAP_SOURCE(0x800000 | 158884)
14  0x42a4027c  VERTEX2F(1352, 636)
15  0x0181b4d4  BITMAP_SOURCE(0x800000 | 111828)
16  0x42b6027c  VERTEX2F(1388, 636)
17  0x01826d58  BITMAP_SOURCE(0x800000 | 159064)
18  0x42c6027c  VERTEX2F(1420, 636)
19  0x23000000  RESTORE_CONTEXT()

Das Problem das Cell() nur 7 Bit breit ist wird also umgangen indem die 
Bitmap-Adresse der Glyphen angegeben wird.

Was mir nicht klar ist, welche Glyphen sind nach dem Konvertieren 
überhaupt in dem Set?
Ein Font den ich konvertiert habe hat als Größe 12 nur 91kB, ein anderer 
in der gleichen Größe hat 332kB.
Was da überhaupt drin ist und warum eigentlich - keine Idee.

[Rudolph R. (rudolph)]

So, ich habe das mal ausprobiert und zum Laufen gebracht.

Das angehängte Test-Projekt gibt hier gerade auf meinem RiTFT43 mit 
BT815 den dussligen Text "Hänsel macht bei 0° die Tür zu." aus. :-)
Edit: da sind bestimmt auch noch exotischere Glyphen in dem Font...


Im Untervezeichnis FLASH liegen alle Daten die ich mit dem EVE Asset 
Builder gepackt, in das Font-Test.bin geschoben und per USB/SPI 
Interface in das externe FLASH gebrannt habe.

Der Font GlacialIndifference ist ein freier .otf unter SIL Open Font 
Licence.
Die Vokale sind auf dem Display aber komischerweise nach oben verschoben 
gegenüber den Konsonanten, das gefällt mir noch nicht so.

Der letzte Stein des Puzzles war die Datei tft.c aus AS7 heraus mit 
UTF-8 Encoding zu speichern.

File->Save as-> auf "Save with Encoding" umstellen und "Unicode (UTF-8 
with signature) - Codepage 65001" auswählen.

Der Part ist schon etwas fies, man sieht dem Text ja nicht an wie der 
gespeichert ist.

[Rudolph R. (rudolph)]

Mal was zur Belustigung und zum teilweise nachmachen.

Ich habe ein RVT43ULBNWC00 von Riverdi, gekauft bei TME.
Die EVE3 sind inzwischen zwar bei DigiKey und Mouser gelistet, aber 
nicht verfügbar.

Ich habe für was anderes ein paar W25Q128JVSIQ gekauft, das sind 128MBit 
NOR FLASH.
Die sind ein wenig breiter als normale SO-8, das 64MBit auf dem 
RVT43ULBNWC00 hat aber genau das gleiche Package.

Der Tausch des Chips war an sich erfolgreich, das Footprint ist aber 
eklig schmal auf der Platine, ich habe letztlich die Beine von dem 
W25Q128JVSIQ etwas nach innen gebogen damit ich den sauber einlöten 
konnte.
Der Chip wird erkannt und ist benutzbar, soweit kein Problem.

Jetzt kommt der Teil den niemand nachmachen sollte.
Zum Löten hatte ich Flussmittel-Gel verwendet und das mit 
Platinen-Reiniger wieder runter gespült.
Der Reiniger hat sich dabei in einen Spalt zwischen dem Deckglas und dem 
Display gezogen von dem ich nicht mal gedacht hätte, das er existiert.
Zuerst sah das nur so aus als ob eine kleine Ecke davon betroffen wäre.
Als ich das Display aber etwas später in Betrieb genommen habe musste 
ich leider feststellen, dass da ein wolkiger Schatten auf praktisch der 
ganzen Display Fläche zu sehen ist.

Warum auch immer da überhaupt Luft zwischen den Scheiben ist, die 
Display-Güte verbessert das nicht.
Aber passt blos auf das da nichts reinlaufen kann wenn Ihr die Platine 
reinigen möchtet.

[Rudolph R. (rudolph)]

Mir geht gerade das Löschen des FLASH ein wenig auf den Keks.
Der W25Q128JVSIQ braucht 40...200s für ein Chip-Erase.
Ja, Sekunden, und das ist kein unüblicher Wert.
Vergleichbare Chips von Micron und Cypress liegen da nicht drunter.

Wenn man häufiger das FLASH umprogrammieren will nervt das doch schon 
schwer.

Microchip hat da was, aber leider nur bis 64MBit.
Die SST26VF064BA sollen ein Chip-Erase in maximal 50ms schaffen.
Zumindest für das Prototyping sollte sich das lohnen.

Mouser hat die, allerdings liegen die jetzt noch recht einsam im 
Warenkorb... :-)

https://www.microchip.com/wwwproducts/en/SST26VF064BA

[Rudolph R. (rudolph)]

Das mit den SST26VF064BA funktioniert übrigens prächtig.
So eines habe ich meinem RVT43ULBNWC00 verpasst und der EVE Asset 
Builder löscht das FLASH jetzt in <5s.

Apropos EVE Asset Builder, die 0.4.2 vertut sich beim Konvertieren mit 
Fonts und das Resultat ist mal mehr oder weniger kaputt.
Wovon das abhängig ist weiss ich leider nicht, eventuell hat das was mit 
der Größe der Zeichen zu tun.
Bridgetek hat das Problem schon beseitigt, aber noch keine neue Version 
veröffentlicht.

Und Digikey hat jetzt 100 Stück EVE3-35A-BLM-TPR-F32 herum liegen.
Das finde ich jetzt nicht so interessant weil die resistiv touch haben, 
ein EVE3-70G hätte ich sofort in den Warenkorb gezogen und bestellt.

Was ich auch nicht nachvollziehen kann ist, warum sowohl Mouser als auch 
DigiKey nur die Varianten mit 32MBit FLASH listen.
Da würde ich sogar eher die Variante ohne FLASH nehmen, oder ebem die 
mit 128MBit.

[Rudolph (Gast)]

DigiKey hat jetzt ein paar von den Matrix Orbital EVE3-50G und EVE3-70G 
Displays auf Lager.

Ich habe heute ein EVE3-50G erhalten und das eben mit einem SST26VF064BA 
versehen.

[Mohammad (Gast)]

Dear Rudolph
recently I use your Library to run FT810 with STM32F103 , I added it to 
my project and config it for my display that is a 3.5" 320x240px 
display.
FT810 config correctly , Backlight come up but I just see the black 
screen! , my display have no DISP pin and XRES pin is float now , when I 
change timing values to an unnormal value , display become partly white 
and black. but I have no drawing or color in the screen.

Please guide me
Thanks

[Rudolph R. (rudolph)]

Is this a module with an FT810 or did you really combine a FT810 with a 
STM32F1ß3 on your own PCB?

Anyways, what display is that exactly, how is it connected to the FT810 
and how does your configuration look like?

[Mohammad (Gast)]

Hi
I design my own PCB board that can support several displays with 
different FPC connectors from 40 to 60 pin.
at first, I start with TST035QVIH-28D display with these configurations:


/* EVE_TST035QVIH28D  320x240px 3.5" TSD LCD , no touch , Transmissive , 
Normally White -*/

#if defined (EVE_TST035QVIH28D)
#define EVE_HSIZE  (320L)
#define EVE_VSIZE  (240L)

#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (2L)
#define EVE_VOFFSET  (18L)
#define EVE_VCYCLE  (262L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (2L)
#define EVE_HOFFSET  (68L)
#define EVE_HCYCLE   (408L)
#define EVE_PCLKPOL  (0L)
#define EVE_SWIZZLE  (0L)
#define EVE_PCLK  (6L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (2000L)
#define EVE_HAS_CRYSTAL
#define FT81X_ENABLE
#endif

[Mohammad (Gast)]

This is My PCB when I change HSYNC timing values with VSYNCE timing 
values, I see this screen, in the normal state, It shows a black screen 
that I think it's fine, but it just can not render drawings.

[Rudolph R. (rudolph)]

Wow, so many questions.
I am afraid that there are way too many reasons that this could fail.
It could be incorrect wiring or signal integraty or wrong parameters - 
or something else or everything at once.
Or Software.

And Google has no clue what a TST035QVIH-28D is.

The FT810 is on the far left, hidden by the JTAG cable?
That is quite a distance for all the signals then.

Maybe strip down the design to a bare minimum for one display first?

And it may be a good idea to start with one of the displays that already 
have a FT8xx integrated to verify that the software works.

The lowest cost one that I am aware of with a FT810 would be this one: 
https://www.hotmcu.com/43-graphical-ips-lcd-touchscreen-800x480-spi-ft810-p-333.html
It uses 5V though.
An EVE2-35A or EVE3-35A might be a better choice though with the STM32 
since these use 3.3V signals and supply.
https://www.digikey.de/product-detail/de/matrix-orbital/EVE2-35A-BLM-TPR/635-1143-ND/7650294
https://www.digikey.de/product-detail/de/matrix-orbital/EVE3-35A-BLM-TPR-F32/635-EVE3-35A-BLM-TPR-F32-ND/10187397

There may be other inexpensive modules since I heard rumours of more 
chinese manufacturers producing these.
But I have not found a source for these yet.
For example PANASYS has a series of EVE displays but they ignored my 
inquiry.

I am also designing my own pcbs but I order them.
The latest one in this context would be the one in the attached picture.
This an ATSAMC21E18A with a 3.3V stepdown, a CAN-transceiver, a 5V LDO 
for the transceiver and a speaker with driver.
The 20pin FFC is compatible with the modules from Matrix Orbital and 
Riverdi.
This board is 45mm x 36mm.

[Mohammad Ali N. (mohammadali_n)]

Hi, I think the hardware and voltages are good, I checked all the 
signals with an oscilloscope, I can not buy that LCD you told, I think 
the problem is in software configuration. SPI communication seems OK, 
It's my test board, I must test 5 TFT display for my project. this is my 
development test board and in my final pcb, I just have one TFT display.
What do you think is a problem؟

[Rudolph R. (rudolph)]

I am not even sure if this display can be used with EVE.
The additional SPI at the HX8238D may mean that you need to configure it 
- or perhaps not and it just works on the RGB interface alone.

And the TST035QVIH-28D datasheet is a little unclear on the 
configuration, for example the CM pin is not available on the interface.
But DEN on the other hand is and this should be DISP.

Maybe someone else can have a look, I have not tried something like this 
yet.

The parameters seem to be plausible.

[Mohammad Ali N. (mohammadali_n)]

is my timing config value correct?
what do you mean that TFT can not work with EVE? in FT810 LCD selection 
guide, I didn't see any tips about it!

[Rudolph R. (rudolph)]

The timing values seem to be correct.

And no, I am not saying that this TFT can not work with EVE.
I have no idea, but I find the additional SPI interface from the HX8238D 
a little odd.

Hmm, please provide a schematic snippet that shows the connections 
between the FT810 and the display connector you are using.

[Mohammad Ali N. (mohammadali_n)]

check this

[Rudolph R. (rudolph)]

I am looking over it but this is far from easy.

One thing that I spotted is that pin 11 of the TFT probably should not 
be connected to GND, at least not directly.

[Mohammad Ali N. (mohammadali_n)]

Thanks for your help and spending your time on my problem.

SPDA is a data pin of the Serial communication bus. it must be GND when 
not use

[Mohammad Ali N. (mohammadali_n)]

maybe everything is fine and I just have a problem in drawing after 
FT810 init process. may I ask you to give me a simple drawing function 
like drawing a rectangle?

[Rudolph R. (rudolph)]

Try something simple, like calibration:

EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_RGB | BLACK);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_calibrate();
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);
EVE_cmd_execute();
while(1);

Or use EVE_cmd_dl(CMD_LOGO);

But that is what I meant when I suggested using annother display.
Make sure your software is working.

Annother thing you could try is to use a logic-analyzer to check the SPI 
traddic.
Plus you could post the STM32 specific code you added.

Annother thought, how fast is your SPI going?
Did you make sure it is below 11MHz during init?

[Mohammad Ali N. (mohammadali_n)]

my displays have no touch, is this cause any problem?

my SPI clock is about 1.5Mhz at testing, I know the SPI communication is 
fine because I can write and read form FT810 memory correctly.

Is there any way to change DEN signal polarity?

[Rudolph R. (rudolph)]

Mohammad Ali N. schrieb:
> my displays have no touch, is this cause any problem?

No, this should not be an issue, you just can not tap on the red dot 
then.

> my SPI clock is about 1.5Mhz at testing, I know the SPI communication is
> fine because I can write and read form FT810 memory correctly.

Excellent.

> Is there any way to change DEN signal polarity?

None that I could find on the spot.

[Mohammad Ali N. (mohammadali_n)]

Rudolph R. schrieb:
> Try something simple, like calibration:
>
> EVE_cmd_dl(CMD_DLSTART);
> EVE_cmd_dl(DL_CLEAR_RGB | BLACK);
> EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
> EVE_cmd_calibrate();
> EVE_cmd_dl(DL_DISPLAY);
> EVE_cmd_dl(CMD_SWAP);
> EVE_cmd_execute();
> while(1);
>
> Or use EVE_cmd_dl(CMD_LOGO);
>
> But that is what I meant when I suggested using annother display.
> Make sure your software is working.
>
> Annother thing you could try is to use a logic-analyzer to check the SPI
> traddic.
> Plus you could post the STM32 specific code you added.
>
> Annother thought, how fast is your SPI going?
> Did you make sure it is below 11MHz during init?



at first, I have nothing on the screen after executing your code, I 
tried
to check the effect of each signal by connecting them to VCC or GND 
manually, when I connect TFT DEN pin To VCC or GND directly, I had this 
animated blinking point on the screen.

What is the problem here? DEN is DISP pin in this TFT??? then where is 
the DEN?

[Rudolph (Gast)]

If this is the same DEN than in the HX8238-D datasheet then this is 
indeed part of the "Display Timing Signals".

According to the HX8238-D datasheet this can be left floating if not 
used or connected to VDDIO.
The pin has an internal pullup.

Things would be clearer if the "datasheet" for the TFT had a table to 
show how the HX8238-D actually is connected.

Bottom line, it works now. :-)
And I said it before but did not receive anything yet from anyone else.

I would be interested in your modified EVE_target.h in order to add 
STM32 functions to the repository.

[Mohammad Ali N. (mohammadali_n)]

Hi, I just try to disable BT8XX command because of some issue in the 
KEIL, I did not many change in your libs and config files yet , when 
it'll be ready, I'll glad to share it with you.

another question:

why you define new function names for EVE functions? I want to design 
the screen with EVE SCREEN EDITOR software but the final code and 
functions are not compatible with yours. is there any way to design it 
with such softwares?

[Rudolph R. (rudolph)]

Mohammad Ali N. schrieb:
> I just try to disable BT8XX command because of some issue in the KEIL,

I have never even tried Keil and therefore have no idea if and what it 
does differently on source-level that needs porting from GCC.
But if the define is not set there should be nothing to disable.
And as you are using a FT810 you should not have set the define for 
BT81x.

Mohammad Ali N. schrieb:
> why you define new function names for EVE functions?

I guess it more or less worked out this way.
When I started this a couple of years ago I more or less only had the 
code from FTDI to look at and I found it quite difficult to see what 
really was going on there.

I am just looking at a more current example code and I have to admit it 
got cleaner.
But I am doing things different than FTDI/BRT.
For example I am not throwing around "Ft_Gpu_Hal_Context_t *phost" with 
every command, I see no need to do so.

ft_void_t Ft_Gpu_CoCmd_Toggle(Ft_Gpu_Hal_Context_t *phost,ft_int16_t x, 
ft_int16_t y, ft_int16_t w, ft_int16_t font, ft_uint16_t options, 
ft_uint16_t state, const ft_char8_t* s)

void EVE_cmd_toggle(int16_t x0, int16_t y0, int16_t w0, int16_t font, 
uint16_t options, uint16_t state, const char* text)

Still I am trying to use the same parameters in the same order.

The Screen Editor uses Python scripts to export the projects.
I guess one could somehow add a new target to this and change the format 
a little to export code suitable for my library.

But not me, I tried to modify a couple of scripts a while back but got 
nowhere, I do not speak Python and had more pressing issues to be 
solved.

[Mohammad Ali N. (mohammadali_n)]

Hi,
oK, I'll try to change some python code later!
but for now, Do you work with this TFTs?

KD035VGFPA094
KD035HVFMD057
KD035VGRPA083

I got a Black screen at any timing value!

[Mohammad Ali N. (mohammadali_n)]

Mohammad Ali N. schrieb:
> Hi,
> oK, I'll try to change some python code later!
> but for now, Do you work with this TFTs?
>
> KD035VGFPA094
> KD035HVFMD057
> KD035VGRPA083
>
> I got a Black screen at any timing value!

--------------------------------------------------------

I found that they need a serial command for selecting DPI and boot up, 
do you have any sample code for this? I'll try to connect these serial 
pins to my MCU.

[Rudolph R. (rudolph)]

I have given up on the idea to put a FT8xx or even BT81x on my own 
board.
Given the huge variety of connectors and that most of what is available 
as a privat person is just crap, I decided to rather pay extra for the 
conveniance of not having to match ny hardware to the TFT every time I 
get a new one.

[Bob (Gast)]

Somehow my USB-SPI interface stopped working, sort of, it has gotten 
completely unstable like the SPI is running too fast.

I can not use the external flash of my BT81x modules anymore since I can 
not put anything in these anymore.
Ersasing still works, sometimes at least.
But writing to it fails every time.

Even when using the EVE Screen Editor writing a simple display list with 
only a cmd_text("Text") in it fails most of the time.

I have no problem at all with my controller board, only the USB-SPI 
interface stopped working.
Anyone else experiencing this?

[Mohammad Ali N. (mohammadali_n)]

Hi

Does anyone have a simple Blinking or movement animation sample code?

[Rudolph R. (rudolph)]

Hmm, simple? :-)

EVE_cmd_dl(DL_COLOR_RGB | ((127 > blink_u8) ?  RED : GREEN));
blink_u8++;
...any object...

Creating a spinning fan is fairly easy as well,
and with the BT81x even a bit simpler.
Just use cmd_rotatearound() and change the angle from frame to frame.


What I can not recommend at all though are the new animation features in 
the BT81x, at least not if you need to keep things simple.
I played with it a couple of days ago using the EVE Screen Editor as a 
playground and animations turned out to be the most resource unfriendly 
operaion I have seen so far on EVE.
I took two .gif animations, one with 6 frames and one with 14 frames.
The first thing I noticed is that number of frames get increased, the 6 
frames came out 12 and the 14 frames came out 28.
I tried it again and now the EVE Asset Builder even converts the 6 
frames animation to 24 frames.
Okay, not necessarily an issue.
Then I fed this into EVE Screen Editor and my display-list exploded.
The frames get split up into tiles which memory wise sounds like a good 
idea since there is a good chance that there are overlapping tiles from 
frame to frame.
However, for EVE this is kind of crazy since we have at the very least 
4MB of external memory but still only 8kB for the display-list.
The smaller animation I have is 124x300 pixel.
But since the tiles are rather small this fills up the display list by 
28% already.
And the amount of tiles can even change from frame to frame.

When playing with it I also noticed that every odd frame does look 
exactly like the one before that, 0==1, 2==3, 4==5 and so on.

I still want to do an animation but I just cycle thru the frames with a 
couple more lines of code on my controller.

[Rudolph R. (rudolph)]

Hello,

I just pushed a small update to Github to make use of the vararg 
string-formating functionality of the BT8xx:

- changed EVE_cmd_text_var() to a varargs function with the number of 
arguments as additional argument
- added EVE_cmd_button_var() and EVE_cmd_toggle_var() functions

These are used like this:

EVE_cmd_text_var(20, 300, 27, EVE_OPT_FORMAT, "Hello %0+8d %08x %06d",3,23,-654389,0x1000);
EVE_cmd_button_var(20,240,100,40, 27, EVE_OPT_FORMAT,"Bang %d",1,666);
EVE_cmd_toggle_var(150,260,100,28, EVE_OPT_FORMAT, 0, "Off %d" "\xff" "On",1,323);

These are additional functions since I ran into a few problems.
First of all the C API does not provide information on how many 
arguments were paased to the function and you can not just loop thru the 
arguments like thru a list untill you hit a NULL pointer.
Instead you only have a macro va_arg(list, type) which returns the next 
argument of the given type on each call.
Fortunately the type is not a problem for EVE, the allowable conversion 
specifiers all use integer arguments.

This left me with two options, either parse the string to find out the 
number of arguments required, or put the numer as additional argument.
The first is a bit silly, if the function would be parsing the string 
you could as well use sprintf() to build a string, at least for most 
options.
Adding annother parameter breaks existing code.

So I opted for adding additional functions.

Take care though to get the number right and also to provide the correct 
amount of arguments.
If your number is not high enough EVE interprets the next 32 bit 
value(s) after the command as parameter(s).
If your number is too high additional 32 bit values are filled with 
random numbers and EVE trys to use these as commands.

Have fu,
Rudolph

[stxl (Gast)]

Hallo,
Danke erstmal für die großartige Library!
Habe diese auf einem ATSAMD21G17D mit einem BT816 + 720x720 TFT in 
Verwendung.

Jedoch habe ich folgendes Problem:

Initialisierung des BT816 funktioniert soweit, die Kommunikation via SPI 
(6MHz) sieht sauber aus (siehe Anhang). Jedoch kann ich nach der 
Initialisierung des BT816 (EVE_Init()) keinerlei Display-Kommandos 
ausführen, bzw nichtmal den Bildschirm clearen.


Ein bisschen konnte ich das eingrenzen: Sobald ich das REG_PCLK am Ende 
der EVE_Init() setze (PCLK=2), kann ich danach keine weiteren 
Display-Kommandos ausführen (bzw werden diese vom BT816 nicht 
ausgeführt).

Der besagte Code in der EVE_Init() sieht im Original so aus:

  /* write a basic display-list to get things started */
  EVE_memWrite32(EVE_RAM_DL, DL_CLEAR_RGB|CLEAR_COLOR_RGB(0x00, 0x00, 0xFF));
  EVE_memWrite32(EVE_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
  EVE_memWrite32(EVE_RAM_DL + 8, DL_DISPLAY);  /* end of display list */
  EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

  /* nothing is being displayed yet... the pixel clock is still 0x00 */
  EVE_memWrite16(REG_GPIOX_DIR, 0xFFFF);
  EVE_memWrite16(REG_GPIOX, 0xFFFF); GPIO3 /* enable the DISP signal to the LCD panel, it is set to output in REG_GPIO_DIR by default */
  
  EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD panel */

Dieser funktioniert auch soweit, am Ende der Funktion ist das Display 
blau.

Wenn ich jetzt das REG_PCLK setze, BEVOR ich die Initiale Display-List 
geschrieben habe, bekomme ich nur einen schwarzen Bildschirm, das 
löschen mit Blau funktioniert nicht:

  /* nothing is being displayed yet... the pixel clock is still 0x00 */
  EVE_memWrite16(REG_GPIOX_DIR, 0xFFFF);
  EVE_memWrite16(REG_GPIOX, 0xFFFF); GPIO3 /* enable the DISP signal to the LCD panel, it is set to output in REG_GPIO_DIR by default */
  
  EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD panel */

  /* write a basic display-list to get things started */
  EVE_memWrite32(EVE_RAM_DL, DL_CLEAR_RGB|CLEAR_COLOR_RGB(0x00, 0x00, 0xFF));
  EVE_memWrite32(EVE_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
  EVE_memWrite32(EVE_RAM_DL + 8, DL_DISPLAY);  /* end of display list */
  EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

Für mich erweckt das den Anschein, als kann ich bei laufender PCLK keine 
Display-Lists schreiben. Auch die Logo-Testfunktion vom BT816 kann ich 
nicht ausführen:

int main (void)
{
  system_init();
  
  delay_ms(10);
  
  EVE_init();
  delay_ms(100);

  // Hintergrund löschen auf rot
  EVE_cmd_dl(CMD_DLSTART); /* Start the display list */
  EVE_cmd_dl(DL_CLEAR_RGB | COLOR_RGB(0xFF, 0x00, 0x00));
  EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
  EVE_cmd_dl(DL_DISPLAY);
  EVE_cmd_dl(CMD_SWAP);
  EVE_cmd_execute();

  delay_ms(100);

  // Logo Anzeigen
  EVE_cmd_dl(CMD_LOGO);

  while(1){}
}

Hat jemand hier schon mal ein ähnliches Problem gehabt? Oder mache ich 
irgendwas grundsätzliches falsch?

Gruß Stefan

[Rudolph R. (rudolph)]

Hallo,

das .logicdata ist für Saleae? Ich schaue gleich mal rein.

Der ATSAMD21G17D ist jetzt ja erstmal nicht so weit weg dem dem 
ATSAMC21E18A den ich gerade noch benutze, aber wie immer an der Stelle, 
wenn Du die EVE_target.c und/oder EVE_target.h dafür angepasst hast -> 
ich nehme gerne eine Kopie davon und baue das dann entsprechend ein.

Die Beschreibung klingt erstmal nach einem Problem mit der Hardware.
Dein Display ist schon mal exotisch, gib mal bitte die Timing-Parameter 
die Du in der EVE_config.h dafür erstellt hast und entweder den genauen 
Typ des Displays, idealerweise gleich das Datenblatt oder aber wenn das 
zu sensibel ist mindestens mal einen Screenshot mit den 
Timing-Parametern aus dem Datenblatt ohne weitere Details.
Dann wüsste ich gerne mal wie das verdrahtet ist, also von welchen 
Controller-Pins genau auf welchem Weg mit allen Teilen dazwischen zum 
BT816 und praktisch alles um den BT816 herum.
Wenn das Board proprietär ist, so Details wie der Part für die 
Hintergrundbeleuchtung sind ja nicht wichtig, nur welche Pins da für 
welche Funktion hingehen und ein vorhandener Audio-Amp interessiert ja 
auch nicht.
Zumindest alles um den BT81x herum gibt es ja schon direkt von 
Bridgetek, und somit ist das eher nicht als vertraulich einzustufen. :-)

Das hier ist aber schon mal nicht Original:

stxl schrieb:
> /* nothing is being displayed yet... the pixel clock is still 0x00 */
>   EVE_memWrite16(REG_GPIOX_DIR, 0xFFFF);
>   EVE_memWrite16(REG_GPIOX, 0xFFFF); GPIO3 /* enable the DISP signal to
> the LCD panel, it is set to output in REG_GPIO_DIR by default */

/* nothing is being displayed yet... the pixel clock is still 0x00 */
EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD 
panel, it is set to output in REG_GPIO_DIR by default */
EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD 
panel */

In Abhängigkeit der Hardware kann das schon anders aussehen, aber alle 
Pins auf Ausgang zu stellen und High sieht seltsam aus.

Edit:
Okay, der Trace sieht so für sich erstmal okay aus.
Nur läuft der SPI auf 4MHz, nicht auf 6MHz.
Nachdem der BT816 endlich mal antwortet ist der Touch-Controller noch 
eine Weile im Reset, ganz normal.

Die kurze Display-List im Trace zu sehen ist auch mal ganz witzig, 
REG_CMD_WRITE wird geschrieben und bei der folgenden Abfrage von 
REG_CMD_READ wird schon der gleiche Wert zurück geliefert, also hat der 
BT816 das in den <10µs schon abgearbeitet.

Das einsame EVE_cmd_dl(CMD_LOGO); taucht im Trace zwar auch auf, so für 
sich macht das aber gar nichts.
Das muss ja auch als Display-Liste gebaut werden und dann muss auf diese 
Liste gewechselt werden:

EVE_cmd_dl(CMD_DLSTART); /* Start the display list */
EVE_cmd_dl(DL_CLEAR_RGB | COLOR_RGB(0xFF, 0x00, 0x00));
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_dl(CMD_LOGO);
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);
EVE_cmd_execute();

Wobei man die zweite und dritte Zeile vermutlich auch weg lassen kann.

[stxl (Gast)]

Hallo Rudolph,
Danke erstmal für deine ausführliche Antwort!

Natürlich schicke ich dir gerne meine Anpassungen für den ATSAMD21G17D, 
muss aber vorher noch ein bisschen aufräumen...


Datenblatt für das Display habe ich tatsächlich keins, lediglich die 
Specs über Pinout, Spannungen, etc... Auf Nachfrage beim Verkäufer habe 
ich ein ein Bild mit den Timings (siehe Anhang) bekommen.

Die Config-Section für das Display sieht folgendermaßen aus:

/* Custom Board 720x720 BT816 */
#if defined (EVE_720x720)
#define EVE_HSIZE  (720L)  /* Thd Length of visible part of line (in PCLKs) - display width */
#define EVE_VSIZE  (720L)  /* Tvd Number of visible lines (in lines) - display height */

#define EVE_VSYNC0  (10L)  /* Tvf Vertical Front Porch */
#define EVE_VSYNC1  (20L)  /* Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
#define EVE_VOFFSET  (29L)  /* Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
#define EVE_VCYCLE  (749L)  /* Tv Total number of lines (visible and non-visible) (in lines) */
#define EVE_HSYNC0  (10L)  /* Thf Horizontal Front Porch */
#define EVE_HSYNC1  (30L)  /* Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
#define EVE_HOFFSET  (50L)  /* Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
#define EVE_HCYCLE   (770L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */
#define EVE_PCLKPOL  (0L)  /* PCLK polarity (0 = rising edge, 1 = falling edge) */
#define EVE_SWIZZLE  (1L)  /* Defines the arrangement of the RGB pins of the FT800 */
#define EVE_PCLK  (2L)  /* 60MHz / REG_PCLK = PCLK frequency  30 MHz */
#define EVE_CSPREAD  (1L)  /* helps with noise, when set to 1 fewer signals are changed simultaneously, reset-default: 1 */
#define EVE_TOUCH_RZTHRESH (1200L)  /* touch-sensitivity */
#define EVE_HAS_CRYSTAL
#define FT81X_ENABLE
#define BT81X_ENABLE
#endif

Wenn ich die Timings so mit den anderen Displays vergleiche, klingen die 
ganz plausibel. Oder wie kritisch ist das, wenn die komplett nicht 
stimmen? Irgendwas müsste ja auf dem Display trotzdem zu sehen sein, 
oder?

Da das vom Layout besser gepasst hat, sind die Datenleitungen in 
umgekehrter Reihenfolge angeschlossen, was ja vom BT81x ja auch über das 
REG_SWIZZLE unterstützt wird. Schaltbild ist im Anhang.

Da das Display ein 18-bit Display (6bit/Farbe) ist, setze ich zudem in 
der Init noch das Register REG_OUTBITS:

EVE_memWrite16(REG_OUTBITS, 0x01B6);

Die 0x1B6 entsprechen für jede Farbkomponente 0b110 = 6. Bin mir aber 
nicht sicher, ob ich das so im Datenblatt richtig interpretiere...


Die Stelle mit dem REG_GPIOX_DIR habe ich so aus einer FTDI/BRT Appnote 
übernommen, da beim BT81x das GPIOX_ Register anstelle des GPIO_ 
verwendet werden soll.

Rudolph R. schrieb:
> In Abhängigkeit der Hardware kann das schon anders aussehen, aber alle
> Pins auf Ausgang zu stellen und High sieht seltsam aus.

Werde ich mal testen, nur den DISP Pin zu setzen. Auf meiner Hardware 
hängt allerdings prinzipiell eh nix an den restlichen GPIOs dran.

Das Interessante ist allerdings, dass ich direkt in der Init, also wenn 
ich die initiale Display-List baue, mit dem CLEAR_COLOR_RGB jede 
beliebige Farbe und Mischfarben darstellen kann. Das Display, bzw die 
Kommunikation scheint also iwie schon zu funktionieren.

EVE_memWrite32(EVE_RAM_DL, DL_CLEAR_RGB|CLEAR_COLOR_RGB(0x00, 0x00, 0xFF));
EVE_memWrite32(EVE_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
EVE_memWrite32(EVE_RAM_DL + 8, DL_DISPLAY);  /* end of display list */
EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

Das Problem beginnt (meiner Meinung) nachdem diee PCLK dann nach der 
initialen Display-List gestartet wird, danach verarbeitet der BT81x 
keine Kommandos mehr:

EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD panel */

RGB-Signale sehen am Oszi auch plausibel aus, PCLK läuft auf 36MHz 
(72MHz/2), VSYNC und HSYNC kommen auch passend. Irgendwas macht der 
BT81x also...


Rudolph R. schrieb:
> EVE_cmd_dl(CMD_DLSTART); /* Start the display list */
> EVE_cmd_dl(DL_CLEAR_RGB | COLOR_RGB(0xFF, 0x00, 0x00));
> EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
> EVE_cmd_dl(CMD_LOGO);
> EVE_cmd_dl(DL_DISPLAY);
> EVE_cmd_dl(CMD_SWAP);
> EVE_cmd_execute();

Teste ich mal so, vielleicht läuft es ja.

Danke dir schonmal!

Gruß Stefan

[Stefan O. (stxl)]

Edit: kann meinen Beitrag oben leider nicht mehr bearbeiten.

Habe gerade den BT816 nochmal gegen einen frischen ausgetauscht, nur um 
einen Hardwaredefekt auszuschließen. Hat aber leider keinen Unterschied 
gebracht.

Das setzen der GPIOs habe ich wieder auf den Originalcode zurückgesetzt, 
damit läuft es auch. Bewirkt aber leider auch keine Verbesserung.

EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD panel, it is set to output in REG_GPIO_DIR by default */

Die von dir gepostete Display-List funktioniert leider auch nicht, das 
Display bleibt immer noch auf dem Zustand der initialen Display-List.

Gruß Stefan

[Rudolph R. (rudolph)]

Ich habe so leider gar keinen Vergleich für die Display Timings und was 
plausibel angeht, das meiste davon ist mir immer noch nicht ganz klar.
Zum einen sind die Begriffe in den Datenblätter zum Teil 
unterschiedlich, es gibt nicht immer die gleichen Angaben und dann 
passen die Register in den EVE auch nicht wirklich dazu.

Und in dem Bild zu Deinem Display fehlt praktisch die Hälfte.
Die zulässige Frequenz wäre ja mal nett zu wissen und ebenfalls die 
Werte für komplette Zeilen und Spalten.

Übrigens läuft der BT81x auf 72MHz, nicht 60MHz.
Du könntest auch mal schauen was passiert, wenn Du PCLK auf 3 oder höher 
stellst.

Ich würde das aber ein wenig anders einstellen:
HSIZE  720
VSIZE  720
VSYNC0  0
VSYNC1  10
VOFFSET  10
VCYCLE  749
HSYNC0  0
HSYNC1  20
HOFFSET  10
HCYCLE  770

Für praktisch alle Display Timings die ich gesammelt habe sind VSYNC0 
und HDYNC0 auf Null.
Eine Ausnahme bilden nur die 3.8" und die sind aus 4.3" geschnitten.

Dennoch hast Du schon recht, wenn sich mit der initialen Liste alle 
gewünschten Farben einstellen lassen sieht das eigentlich gut aus.

Bau doch in die initiale Liste mal das CMD_LOGO mit ein.


Jetzt schaue ich gerade auf den Schaltplan und der sieht erstmal seltsam 
aus.
Das Schaltplan-Symbol zeigt ja gar nicht explizit alle Pins, mit dem 
links oben als "2*2" für VCC1V2 sowie dem "23*4" für GND mag ja das 
richtige gemeint sein, das ist nur so nicht nachvollziehbar.
Sind Pin 33, Pin 48 und das Pad auf der Rückseite wirklich auf GND?

Ein einzelner 100nF für 5 VCC Pins ist auch etwas sehr dünn.
Bridgetek hat zumindest 4 vorgesehen und auch jeweils einen für die 
beiden VCC1V2 Pins.


Bau mal bitte das hier am Ende in das Programm ein:

while(1)
{
EVE_memRead8(REG_CPURESET);
EVE_memRead16(REG_CMD_READ);
delay_ms(1);
}

Der Trace müsste dann eigentlich immer noch zeigen, dass der BT816 so 
weiter vor sich hin läuft.

[Stefan O. (stxl)]

So, jetzt bin ich ein bisschen schlauer...

Nach gut zureden habe ich tatsächlich ein "Datenblatt" vom Verkäufer 
bekommen, wo tatsächlich ein paar verwertbare Infos drinstehen (siehe 
Anhang). Das Timing im Datenblatt stimmt allerdings soweit mit den 
bestehenden Timings überein. Über die maximale Frequenz steht leider 
nichts drin.
Bin mittlerweile auch der Meinung, dass es nicht unbedingt daran liegt, 
dass der BT816 meine Befehle ignoriert. Habe mittlerweile zum Testen 
einfach anstelle des Displays das Oszi an den R5 / B5 Signalen 
angeschlossen. Wenn also der Display-Clear auf Rot tatsächlich 
ausgeführt wird, sehe ich das auch da.

Zu den fehlenden 100nF im Schaltplan: Die gibts doch ;-) Waren 
allerdings auf dem Ausschnitt vom Schaltplan abgeschnitten. Habe mich da 
weitestgehend an die Empfehlungen von FTDI/Bridgetek gehalten, und 
insges 4x 100nF + 1u auf dem 3.3V Rail und 2x 100nF + 1u auf den 1.8V 
direkt am Chip.

Die Bezeichnung der GND / Supply-Pins im Schaltplan ist leider etwas 
missverständlich, so zeigt es EAGLE an, wenn an einen Pin mehrere Pads 
verbunden sind. P23, P33, P48, und das Thermal liegen auf GND. P2 und 
P57 auf VCC1V2.

Anbei noch der Trace mit dem zyklischen Status-Check am Ende des 
Programms.

EVE_init();
delay_ms(100);

// Hintergrund löschen auf rot
EVE_cmd_dl(CMD_DLSTART); /* Start the display list */
EVE_cmd_dl(DL_CLEAR_RGB | COLOR_RGB(0xFF, 0x00, 0x00));
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);
EVE_cmd_execute();
delay_ms(100);

while(1)
{
  EVE_memRead8(REG_CPURESET);
  EVE_memRead16(REG_CMD_READ);
  delay_ms(1);
}

Wenn ich das richtig interpretiere, liegen am Ende 20 Bytes im FIFO vom 
Coprozessor, also das was ich mit meiner Displaylist reingeschrieben 
habe. Müsste das aber nicht eigentlich nach dem  cmd_execute() wieder 
auf 0 sein? Für mich sieht das so aus, als bekomme der Coprozessor alle 
Befehle, aber ignoriert das Command zum ausführen. Oder verstehe ich das 
falsch?

Danke für deine Hilfe!
Gruß Stefan

[Rudolph R. (rudolph)]

Der Trace sieht gut aus, der BT816 antwortet ganz normal.
Keine Fehler, nichts auffälliges.

Das mit den 20 Bytes ist auch normal, der FIFO wird fortlaufend 
beschrieben und ausgeführt wird dann immer nur von dem Offset auf den 
REG_CMD_READ zeigt bis zu dem Offset auf den REG_CMD_WRITE zeigt.
Das ist RAM_CMD mit 4kB.
Es werden 5 Kommandos geschrieben mit je 4 Bytes.

Im Gegensatz dazu wird die allererste Liste direkt in RAM_DL geschrieben 
und da geht es immer bei Null los.
RAM_DL besteht auch aus zwei 8kB Bänken die umgeschaltet werden.

Okay, das Timing haut nicht hin, die 6MHz auf dem SPI sind 4MHz und das 
delay_ms(1) sind 1,5ms.
Das hat aber mit dem Problem nichts zu tun, als SPI-Slave ist dem BT816 
ziemlich egal wie schnell der Takt nun genau ist.

Ich tippe auf ein Hardware-Problem zwischen dem BT816 und dem Display.
Nur ist das die Seite mit der ich mich bisher am wenigstens beschäftigt 
habe, und sowas bestätigt mal wieder, dass fertige Module zu nutzen gar 
nicht mal so verkehrt ist. :-)

Ich werfe gleich noch mal einen Blick auf das "Datenblatt" von dem 
Display.
Das erste was mich allerdings wundert, das Teil hat kapazitiv-touch, 
warum hängst Du da einen BT816 dran?

[Rudolph R. (rudolph)]

Also irgendwie ist das ja frustrierend, für Displays belastbare 
Informationen zu suchen.

Das TL040HDS01CT-T1161A könnte vielleicht, oder auch nicht, einen YY1821 
Display-Controller nutzen.
Wenn ich nach dem Suche finde ich aber nur Displays die den haben sollen 
und vor allem welche mit MIPI Interface.
Der kommt vielleicht von der Firma AXS, aber die Seite ist tot.

Das MDT0420AISC-RGB ist dem sehr ähnlich.
https://www.midasdisplays.com/product-explorer/tfts/2-8-to-4-6-inch-tfts/mdt0420a/mdt0420aisc-rgb
Die Pin-Belegung ist identisch, allerdings lassen die Pin 7 und Pin 8 
offen.
Der dort erwähnte MD3052C ist eigentlich ein NV3052C.
Ich finde aber auch zu denen kein Datenblatt.

Ein anderes ähnliches Display nutzt einen ST7789V.
Dort finden sich dann die IM0 und IM1 Pins und nach dem ist das 
plausibel, dass die Pins High sind.

Was mir aber gerade so auffällt, DISP mit RESET zu koppeln könnte das 
Problem sein.

Pack mal die Zeile
EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD 
panel, it is set to output in REG_GPIO_DIR by default */
zwischen das Auslesen der Chip-ID und REG_CPURESET.
Also Zeile 1147.
Am besten noch mit DELAY_MS(150);

while(chipid != 0x7C)  /* if chipid is not 0x7c, continue to read it until it is, EVE needs a moment for it's power on self-test and configuration */
{
  DELAY_MS(1);
  chipid = EVE_memRead8(REG_ID);
  timeout++;
  if(timeout > 400)
  {
    return 0;
  }
}

EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD panel, it is set to output in REG_GPIO_DIR by default */
DELAY_MS(150);

timeout = 0;
while (0x00 != (EVE_memRead8(REG_CPURESET) & 0x03)) /* check if EVE is in working status */
{
  DELAY_MS(1);
  timeout++;
  if(timeout > 50) /* experimental, 10 was the lowest value to get the BT815 started with, the touch-controller was the last to get out of reset */
  {
    return 0;
  }
}

[Stefan O. (stxl)]

Heureka, ich habs gefunden!

Kurzfassung für alle, die auch mal darüber stolpern sollten: Die 
Timing-Settings für das Display sind doch relevant für den BT816. In 
meinem Fall habe ich (aus purer Verzweiflung) die VCYCLE von 
(berechneten) 750 auf 800 erhöht.

Durch herumprobieren habe ich dann herausgefunden, dass VCYCLE immer 
größer als VSIZE + VOFFSET sein muss.

In meinem Fall reicht es schon, den VCYCLE von 750 auf 751 zu erhöhen. 
Schon funktioniert alles, als wär nichts gewesen!
Unterschreite ich diesen Wert, verweigert der kleine Mistkerl jedoch 
jegliche Kooperation.

#if defined (EVE_720x720)
#define EVE_HSIZE  (720L)  /* Thd Length of visible part of line (in PCLKs) - display width */
#define EVE_VSIZE  (720L)  /* Tvd Number of visible lines (in lines) - display height */

#define EVE_VSYNC0  (10L)  /* Tvf Vertical Front Porch */
#define EVE_VSYNC1  (20L)  /* Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
#define EVE_VOFFSET  (30L)  /* Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
#define EVE_VCYCLE  (751L)  /* Tv Total number of lines (visible and non-visible) (in lines) */
#define EVE_HSYNC0  (10L)  /* Thf Horizontal Front Porch */
#define EVE_HSYNC1  (30L)  /* Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
#define EVE_HOFFSET  (50L)  /* Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
#define EVE_HCYCLE   (770L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */
#define EVE_PCLKPOL  (0L)  /* PCLK polarity (0 = rising edge, 1 = falling edge) */
#define EVE_SWIZZLE  (1L)  /* Defines the arrangement of the RGB pins of the FT800 */
#define EVE_PCLK  (2L)  /* 60MHz / REG_PCLK = PCLK frequency  30 MHz */
#define EVE_CSPREAD  (1L)  /* helps with noise, when set to 1 fewer signals are changed simultaneously, reset-default: 1 */
#define EVE_TOUCH_RZTHRESH (1200L)  /* touch-sensitivity */
#define EVE_HAS_CRYSTAL
#define FT81X_ENABLE
#define BT81X_ENABLE
#endif

Meine Vermutung ist, dass der Chip währen diesen "unsichtbaren" 
Zeitabschnitten irgendwas berechnet, da das intern ja alles on-the-fly 
ohne Framebuffer erzeugt wird. Sind diese zu kurz, also VOFFSET > 
(VCYCLE - VSIZE)  hängt sich wohl irgendwas auf.

Interessanterweise tritt dieses Problem bei HCYCLE nicht auf. Kann ich 
sogar bis runter auf HCYCLE=HSIZE setzen, bis auf einen abgeschnittenen 
Darstellungsbereich juckt das den Chip überhaupt nicht.


Ich bekomm zu viel...

[Rudolph R. (rudolph)]

Super das es jetzt funktioniert. :-)

Aber meine Timings von oben hast Du auch nicht ausprobiert, sonst wären 
VSYNC0 und HSYNC0 nicht immer noch >0 und VOFFSET habe ich auch kleiner 
gewählt. :-)

Aber sowas kommt halt dabei heraus wenn man raten muss anstatt mit 
vernünftigen Angaben aus dem Datenblatt arbeiten zu können.

[Stefan O. (stxl)]

Rudolph R. schrieb:
> Aber meine Timings von oben hast Du auch nicht ausprobiert, sonst wären
> VSYNC0 und HSYNC0 nicht immer noch >0 und VOFFSET habe ich auch kleiner
> gewählt. :-)

Hätte ich das mal früher gemacht... :-x

Jetzt gibt es aber ein neues Problem: An dem BT816 hängt noch ein FLASH 
vom Typ AT25QF128A 
(https://www.adestotech.com/wp-content/uploads/AT25QF128A_Data_Sheet_RevA_03-19-2019-1.pdf).

Diesen habe ich auch vorschriftsmäßig mit einer aus dem EVE Asset 
Builder erstellten BIN programmiert. Am Anfang steht auch die korrekte 
BLOB (unified.blob).
Wenn ich jetzt jedoch mit EVE_init_flash() in den Fullspeed-Modus 
schalten will, bekomme ich als Antwort 0xE004, was laut Datenblatt BLOB 
mismatch bedeutet.

Wenn ich mit EVE_flash_read(...) mir manuell den Speicherinhalt auslese, 
ist dieser absolut korrekt.
Habe testweise auch eine Routine geschrieben, um den FLASH über den 
BT816 mit dem korrekten BLOB zu beschreiben, leider auch kein Erfolg.

uint8_t EVE_fixblob(){
  // Write Blob
  for(uint32_t i=0; i<1024; i++){
    uint32_t val = 0;
    val = eve_blob[i*4] | (eve_blob[(i*4)+1] << 8) | (eve_blob[(i*4)+2] << 16) | (eve_blob[(i*4)+3] << 24);
    EVE_memWrite32(EVE_RAM_G+(i*4), val);
  }
  EVE_cmd_flashupdate(0x00000000, EVE_RAM_G, 4096);
  
  DELAY_MS(1000);
  
  // Verify
  EVE_cmd_flashread(EVE_RAM_G, 0x00000000, 4096);
  DELAY_MS(100);
  for(uint32_t i=0; i<1024; i++){
    uint32_t ram =  EVE_memRead32(EVE_RAM_G+(4*i));
    uint32_t rom = eve_blob[i*4] | (eve_blob[(i*4)+1] << 8) | (eve_blob[(i*4)+2] << 16) | (eve_blob[(i*4)+3] << 24);
    if(ram != rom){    
      return 0;
    }
  }
  return 1;
}

Hattest du sowas schon mal? Woran kann das sonst noch liegen? Bin 
mittlerweile recht überzeugt, dass der Flash-Inhalt korrekt ist.

Der SPI Flash ist laut Datenblatt standardmäßig im QSPI Mode. Aber da 
der BT problemlos Daten lesen/schreiben kann, gehe ich mal davon aus, 
dass das kein Problem darstellen sollte...

[Rudolph R. (rudolph)]

Mir scheint, das ist mit dem FLASH so eine Sache bei der man Glück haben 
muss, denn bisher gibt es da praktisch keine Doku und zumindest im 
Bridgetek Forum keinen Support zu - entsprechende Fragen werden einfach 
ignoriert.

Das mit dem Bridgtek-Forum ist auch so eine Sache, durch die zwangsweise 
Moderation ist der Austausch da doch extrem zäh.

Was das mit dem .blob überhaupt soll bleibt rätselhaft, das ist zum 
einen nirgendwo dokumentiert, zum anderen können die BT81x verschiedene 
FLASH Bausteine auch ohne .blob richtig erkennen und zumindest im 
normal-Modus auch beschreiben.

Ich habe SST26VF064BA-104I/SM ausprobiert, die schaffen das Chip-Erase 
nämlich in 50ms statt der sonst üblichen >90s.
Nur am Ende hat mir das gar nichts genützt, die werden zwar erkannt, 
lassen sich aber nicht mal im Normal-Modus beschreiben.

Mehr Glück hatte ich allerdings mit W25Q128JVSIQ, die kann ich ohne 
Probleme mit dem EVE Asset Builder Löschen, Lesen und Beschreiben, das 
funktioniert dann auch im QSPI-Modus.
Und ich kann die auch per EAB löschen, per Software ein Test-Image drauf 
schreiben inklusive unified.blob und dann ich das FLASH auch in den QSPI 
Modus versetzen und die zuvor gebrannten Bilder direkt aus dem FLASH 
anzeigen.
Dafür dauert dann nur das Löschen eine Ewigkeit.

So spontan sieht Dein Code oben für mich auch okay aus.

[Stefan O. (stxl)]

So, heute ist endlich der W25Q128JVSIQ gekommen.
Eingelötet, und funktioniert einwandfrei.
Der Fehlercode, dass der BLOB nicht übereinstimmt, ist da ziemlich 
irreführend. Merke: Verschiedene Flash-Bausteine ausprobieren.

[Rudolph R. (rudolph)]

Super, das bestätigt dass das unified.blob mit dem AT25QF128A nicht klar 
kommt.
Wobei es ja leichter wäre, wenn die dokumentiert hätten, was diese .blob 
überhaupt macht.

Ich habe gerade einen neuen Beitrag in der BRT Community erstellt mit 
einer Liste von Chips die funktionieren oder auch nicht.
Mit drei Einträgen ist das allerdings noch seeeeehr dünn.
Mal schauen, ob da noch was dazu kommt wenn der Beitrag nächste Woche zu 
sehen ist.

[Cosimo Micelli (Gast)]

Rudolph R. schrieb:
> Hello,
>
> I just pushed a small update to Github to make use of the vararg
> string-formating functionality of the BT8xx:
>
> - changed EVE_cmd_text_var() to a varargs function with the number of
> arguments as additional argument
> - added EVE_cmd_button_var() and EVE_cmd_toggle_var() functions
> ...
> ...

Hi Rudolph,

thank you very much for your valuable library! I'm profitably using it 
with STM32 MCU's with just a few adaptations.

I just wanted to suggest a very simple method to add string-formatting 
functionality also to the FT8xx.
I've used your EVE_cmd_text function and vsprintf available in stdarg.h 
(which takes care of handling the argument list) to define a new 
EVE_cmd_textf function:

#include <stdarg.h>

void EVE_cmd_textf (int16_t x0, int16_t y0, int16_t font, uint16_t options, const char* text, ...)
{
  va_list args;
  char buff[256];

  va_start(args, text);
  vsprintf (buff, text, args);
  va_end(args);

  EVE_cmd_text (x0, y0, font, options, buff);
}

[Rudolph R. (rudolph)]

Cosimo Micelli schrieb:
> thank you very much for your valuable library! I'm profitably using it
> with STM32 MCU's with just a few adaptations.

Thank you for your kind words!
And as usual I would like to see your additions to EVE_target.c and 
EVE_target.h in order to integrate it for everyone else. :-)

Cosimo Micelli schrieb:
> I just wanted to suggest a very simple method to add string-formatting
> functionality also to the FT8xx.
> I've used your EVE_cmd_text function and vsprintf available in stdarg.h

This is indeed interesting, I was not aware of the v**printf() 
functions, thank you!

I am a bit reluctant to integrate this into the library though.
These functions are normally rather chunky so I tend to avoid them.
This is totally fine in user space but one might use vsprintf() and the 
next prefers vsnprinf(), the next prefers to use sprintf() and so forth 
with a whole lot of variations in between up to strictly not using such 
a function.
And when it comes to library functions I am always concerned about 
portability.

[Axel V. (axel-f)]

Hallo Rudolph,
ich habe vor einiger Zeit begonnen, Deine Bibliothek in mein Gerät 
aufzunehmen und Du meintest, ich solle es mal zeigen, wenn es fertig 
ist. Eigentlich wollte ich eine PM schreiben, aber es ist wohl von 
allgemeinem Interesse zu sehen, was Deine Bibliothek kann (und es ist 
sicher nur ein Teil zu sehen).

Viel Spaß damit!

Gruß Axel

[Rudolph R. (rudolph)]

Das sieht interessant aus, so richtig als Anwendung hatte ich sowas noch 
nicht.

Leider kann ich von dem was ich mit den EVE so mache wenig bis keine 
Bilder posten, für mich selber habe ich noch gar nichts mit TFT gebaut 
das eine echte Funktion gehabt hätte. :-)

Ein Kunde wollte eine Art Datenlogger-Funktion haben, so als 
Nebenaufgaube im Projekt.
Leider ist zum einen die Funktion dann weggefallen und dann hat die 
Physik nicht bei dem mitgespielt was sich der Kunde ausgedacht hatte.


Und danke für das Lob, aber eigentlich kann meine Library ja selber 
nichts, so im Bezug auf Grafik-Funktionen. :-)
Das ist ja erstmal "nur" Wrapper-Code, wenn auch hoffentlich ein wenig 
besser verständlich als das was FTDI/Bridgetek hat (und Bridgetek hat 
nachgelegt), schneller und mit Focus auf Portierbarkeit und 
Unterstützung von möglichst allen Modulen die es so gibt.

[Rudolph R. (rudolph)]

As I just noticed, DigiKey finally has the EVE3-35G on stock as well as 
EVE3-43G, so I just ordered both:

https://www.digikey.de/product-detail/de/matrix-orbital/EVE3-35G-BLM-TPC-F32/635-EVE3-35G-BLM-TPC-F32-ND/10187390
https://www.digikey.de/product-detail/de/matrix-orbital/EVE3-43G-BLM-TPC-F32/635-EVE3-43G-BLM-TPC-F32-ND/10187394

Unfortunately these offer "only" 32MBit of external FLASH but it is easy 
enough to replace the chip with a W25Q128JVSIQ if 4MByte of FLASH are 
not enough.

So apart from the more exotic EVE3-38 types the lineup of Matrix Orbital 
modules on stock at DigiKey is now complete with 12 types to choose 
from.

No, I am neither sponsored by DigiKey or Matrix Orbital, I just happen 
to like these modules and so far DigiKey is the only source for them 
that I know of.
The modules from Riverdi can be bought from Mouser or TME for example.