FT800 / FT810 Library

[Rudolph R. (rudolph)]

Ich bin dabei, eine eigene Library für FT800 und FT810 zu schreiben.
Warum? Weil ich wissen wollte, wie man die Chips benutzt.
Und weil ich gerne in Zukunft mehr mit denen machen würde.

Ich habe als Hardware derzeit zum testen:

VM800B35A-PL 3,5" 320x240 FT800 von FTDI
FT810CB_HY50HD 5" 800x480 FT810 von HAOYU

Bestellt habe ich auch noch ein FT800CB-HY50B von HAOYU, aber das wird 
sich wohl noch vier Wochen hin ziehen, China eben...

An beide TFTs habe ich eine kleine Platine von mir dran gebastelt mit 
einem AT90CAN128 von Atmel, dazu noch jeweils ein Netzteil-Platinchen.
Versorgung und Signal-Pegel ist für beide TFT jeweils 5V.

Der SPI ist auf 8 MHz eingestellt, mehr geht mit den AVR nicht.
Wenn man das an einem schnelleren Controller verwendet ist zu beachten, 
dass der SPI beim Aufruf der ft800_init() noch langsamer als 11 MHz 
eingestellt sein muss, danach darf der dann bis 30MHz laufen.

Ja, das sind Test-Aufbauten.
Und ja, das grüne Ding ist eine Brot-Dose, mies aber preiswert.
Und ebenfalls ja, die GUI hat keinen Sinn, das ist nur zum Spielen.

Die "Library" besteht im Moment aus diesen Teilen:
FT800.h Contains FT80x/FT81x API definitions
FT800_commands.c Contains Functions for using the FT8xx
FT800_commands.h Contains FT800 Function Prototypes
FT800_config.h  configuration information for some TFTs and some 
pre-defined colors

Die FT800_commands.c aus den beiden angehängten Projekten unterscheiden 
sich nur dadurch, dass in dem FT810CB_HY50HD Projekt die Zeile 
auskommentiert ist mit der in der ft800_init() die Anzeige um 90° 
gedreht wird.

In der FT800_config.h wird das TFT das man benutzen möchte eingestellt, 
sowie zwischen FT800 und FT810 umgestellt.

Das Projekt für den FT810 funktioniert zwar, von dem was der FT810 
zusätzlich kann ist bisher aber nur ft800_cmd_setbase() implementiert.

Eine wichtige Einschränkung ist, dass ft800_cmd_inflate() und 
ft800_cmd_loadimage() nicht mit Bilder über 4080 Bytes Länge klar 
kommen.
Das liegt daran, dass die Bilder über den FIFO vom Kommando Co-Prozessor 
in den FT8xx geschoben werden und dieser hat eben nur 4k.
Das kann man auch weniger stumpf programmmieren und den FIFO mehrmals 
füllen, für den FT800 war mir das nur nicht wichtig genug und mit dem 
FT810 entfällt das unter Verwendung von cmd_mediafifo().

Es war jetzt aber kein Problem Icons mit 100x100 Pixel als .jpg in unter 
4k zu packen.


Über die ersten 60 Zeilen der FT800_commands.c wird die Hardware vom 
Rest gelöst, darüber müsste sich das an so ziemlich alles anpassen 
lassen, mehr oder weniger sinnvoll. :-)

Mein beiden Test-Projekte implementieren einen einfachen Scheduler mit 4 
"Tasks" die 250µs laufen dürfen und einmal pro ms aufgerufen werden.

Die Funktion ft800_loop() setzt da jetzt drauf auf, dass sie mit einem 
Abstand von 1ms aufgerufen wird.
Mit der Zähler-Variablen "delay" hangelt die sich von einem Aufruf zum 
nächsten.
Zuerst werden Touch-Events ausgewertet.
Dann in Folge Schritt für Schritt die Display-Liste zusammen gebaut und 
schliesslich abgeschlossen und ausgeführt - 40 Mal pro Sekunde.

Der Ansatz soll dafür sorgen, dass der Controller beim Übertragen der 
Kommandos für die Liste weiter ansprechbar bleibt.
Das funktioniert soweit ganz gut, nur haben die Controller nicht 
wirklich was anderes zu tun in den Test-Aufbauten.
Und ehrlich gesagt habe ich auch nicht mehr nachgemessen, ob sich alle 
Teile von ft800_loop() an das 250µs Limit halten.

Das wars was mir "spontan" dazu einfällt, ansonsten möchte ich nur 
anmerken, dass ich das nicht als abgeschlossen betrachte.

[Rudolph R. (rudolph)]

Ein winziges Update für FT800_commands.c und FT800_commands.h:

2.1
- removed the REG_ROTATE line from ft800_init()
- simplified ft800_busy() slightly
- implemented ft800_cmd_mediafifo(), ft800_cmd_setrotate(), 
ft800_cmd_setbitmap() (FT81x)

Damit benutze ich jetzt für beide Projekte exakt die gleichen Dateien.
Die REG_ROTATE Zeile habe ich im FT800 Spielplatz in die main() 
geworfen.

Und yeah, das FT800CB-HY50B ist verschickt, nur noch 3 1/2 Wochen... :-)

[Holger S. (223rem)]

Hallo Rudolph,

besten Dank für Deine Vorarbeit.
Mein FT810CB-HY50HD ist auch seit gestern auf dem Weg ;-)
Werde demnächst mal ein Platinchen für FT812/FT813 stricken.

Gruß Holger...

[Rudolph R. (rudolph)]

Ich habe noch den Plan im Hinterkopf, ein Board für den FT811 zu bauen.
Nur ist das nicht ganz so witzig, da überhaupt TFTs für zu finden.
Bringt ja irgendwie nichts, wenn man das an nichts anschliessen kann.

Ich habe zum Beispiel neidisch auf das neue 7" RaspberryPi TFT geschielt 
bis ich dann in einem Forens-Beitrag gelesen habe, dass das Ding keine 
quadratischen Pixel hat.
Da habe ich dann die Suche nach weiteren Infos dazu aufgegeben.
Dafür finde ich das Teil dann auch zu teuer.

VM800B50 werde ich dann auch noch in die Finger bekommen.

Das FT810CB_HY50HD hat mir auf jeden Fall zu viele Pixel für die Fläche.
Mein Plan ist das FT800CB-HY50B mit der FT810 Platine aufzurüsten, ich 
könnte dann auch mal versuchen den FT800 durch einen FT810 zu ersetzen.

Mal schauen, wäre ja nett, wenn sich langsam noch mehr Anbieter finden 
würden.

[Rudolph R. (rudolph)]

Noch ein kleines Update.
Ich stand am Donnerstag spontan vor der Aufgabe, das auf einem Arduino 
mini pro zum Laufen zu bringen, also als Arduino-Code und nicht direkt.

Das lief dann doch nicht ganz so, wie ich mir das überlegt hatte.
In der FT800_commands.c was ändern zu müssen kann eigentlich nicht das 
Ziel sein.
Ausserdem hatte ich die Bedienung des PowerDown Pins nicht abstrahiert 
und musste das entsprechend in der ft800_init() direkt ändern.

Also gibt es jetzt noch eine FT800_config.c in welche die Funktionen zur 
Abstrahierung der Hardware ausgelagert sind.

Es sollte jetzt nur noch notwendig sein, die FT800_config.h und/oder 
FT800_config.c an die Ziel-Hardware anzupassen.

Jetzt muss ich mal schauen, dass ich das wieder in Richtung Arduino 
geschubst bekomme, dann werfe ich die erweiterte FT800_config.c und 
FT800_config.h noch mal hier als Beispiel ab.

[Rudolph R. (rudolph)]

Arbeit, wie schnell die Zeit vergeht, wenn man Spass hat. :-)

Vor ein paar Tagen ist das FT800CB-HY50B aus China angekommen.

Das habe ich an den Controller der Brotdose angeschlossen, das 
Spielplatz_90CAN_FT800 Projekt aufgemacht, in der FT800_config.h das 
FT_VM800B50A als Display ausgewählt weil dieses ja auch 5" 480x272 hat, 
compiliert, eingespielt, läuft. :-)

Dann habe ich die komplett identische Platine von dem FT810CB_HY50HD mit 
dem FT810 auf das TFT gebaut, in der FT800_config.h das #define 
FT_81X_ENABLE aktiviert, compiliert, eingespielt, läuft.

Nächste Woche oder so will ich mal versuchen den FT800 von der anderen 
Platine auszulöten und durch einen FT810 zu ersetzen.
Probiert habe ich sowas allerdings noch nicht, QFN vermeide ich eher.

Dann habe ich mir gestern mal etwas mehr Mühe gebeben mit dem Gehäuse.
Und die Brotdose weg geworfen.

Was mir ja gut gefällt ist die niedrigere Auflösung bei 5", weniger 
prickelnd ist allerdings der schwache Betrachtungswinkel und resistiv 
ist es ja auch immer noch.
Beim Fotografieren fiel auch auf, dass das kräftig reflektiert.
Die Schutzfolie ist auch noch drauf, viel Effekt hatte die beim 5" 
800x480 aber nicht.

Weil mir aber vor allem die Lieferzeiten aus China auf den Keks gehen 
und die TFTs die FTDI verwendet etwas hochwertiger wirken, habe ich mich 
dran gemacht eine Erweiterungs-Platine für die VM800B zu bauen.
Die Doppel-Reihige Buchsenleiste dient dazu, auf die richtige Bauhöhe zu 
kommen damit die Platine auf der anderen Seite mit einem Dom verschraubt 
werden kann, das soll dann für das VM800B35 und das VM800B50 passen.
Auf der Platine habe ich einen 90CAN mit CAN und LIN, einen 600mA 
Schaltregler für das TFT und einen LDO für den µC.
Das Ziel ist eine Prototypische Anzeige-Einheit für Fahrzeuge.

[e-d (Gast)]

FT800 aus deutschen Landen:
http://www.watterott.com/de/Gameduino-2

(basiert auf FT800 Display+Audio+Touch Controller von FTDI);

[Rudolph R. (rudolph)]

e-d schrieb:
> FT800 aus deutschen Landen:

Naja, OpenSource von SeedStudio in USA produziert und von Watterott 
importiert.
Das hätte sicher auch eine andere Qualität wenn das ein Produkt von 
Watterott wäre.

Edit, ach ja, das Gameduino2 hat ja auch "nur" 4,3", damit ist die 
Pixel-Dichte auch höher als bei dem 3,5" oder 5" -> möchte ich nicht.

> http://www.watterott.com/de/Gameduino-2

Da nehme ich lieber das hier:
http://de.farnell.com/ftdi/vm800b50a-pl/entw-modul-ft800-eve-mit-5-anzeige/dp/2355184

Das kann man wenigstens direkt in ein Gehäuse einbauen.

Unter dem Aspekt sind die von Haoyu eben auch schick, die sind inklusive 
Einbau-Rahmen:
http://www.hotmcu.com/5-graphical-lcd-touchscreen-480x272-spi-ft800-p-124.html?cPath=6_16&zenid=j1ejj530jj088epnvoratp0843

Man muss die nur leider bisher direkt in China ordern, wenn es die zum 
Beispiel bei Watterott geben würde, das hätte was.

Leider ist die Auswahl an Modulen mit FT811 sehr dünn, Haoyu hat zwar 
eines, aber 5" mit 800x480 will ich inzwischen nicht mehr haben.
Ich würde das ja gerne mal mit Kapazitiv-Touch sehen.

[Rudolph R. (rudolph)]

Ein kleines Update, diesmal mit den Support-Funktionen für Arduino.
Zu viel Arbeit, zu wenig Zeit zum Spielen...

Ein Beispiel-Projekt für den Arduino muss ich auch gerade schuldig 
bleiben, ich mache zwar was mit einem miniPro, das kann ich hier aber 
nicht veröffentlichen.

Spielplatz_90CAN_FT810_HY50B.zip - wie weiter oben auch, ein komplettes 
Beispiel-Projekt für den AT90CAN128

Test_M644_FT810.zip - das ganze mal schnell und ungestet für den 
ATMega644 umgesetzt weil ich per Mail gefragt wurde, wie man das macht.
Die für das Beispiel relevanten Unterschiede zwischen 90CAN128 und M644 
sind allerdings so klein, dass das quasi das gleiche Projekt ist.
In der FT800_config.c musste ich noch das pgm_read_byte_far() durch 
pgm_read_byte() ersetzen, der M644 hat ja "nur" 64k Flash.

Und dann erlaube ich mir mal, die Dateien die in der 90CAN...zip drin 
sind mal direkt mit anzuhängen, zum schnelleren durchklicken.
Das ist ja auch alles nicht so gross.

FT800.h FT800_commands.c FT800_commands.h FT800_config.c FT800_config.h

Was macht man jetzt damit?

Also erstmal einfach ein neues Projekt erstellen und die Dateien ins 
Verzeichnis werfen, dann im Projekt hinzufügen.

In der FT800_config.h stellt man ein, ob man einen FT80x oder FT81x 
benutzen möchte, wählt aus welchen Satz TFT-Einstellungen man benutzen 
möchte (oder erstellt einen neuen Satz), wählt die Plattform aus, im 
Moment AVR8 oder Arduino.

Für die jeweilige Plattform gibt es dann noch spezifische Includes für 
den Zugriff auf den SPI und Delay, sowie Defines für Chip-Select und 
Power-Down des FT800.

In der FT800_config.c stehen die Plattform-spezifischen Funktionen drin 
zum Setzen/Löschen von Chip-Select und Power-Down, zum Übertragen von 8 
Bit per SPI und zum Auslesen von Daten aus dem FLASH.

In der eigenen main.c braucht man jetzt:
#include "FT800.h"
#include "FT800_commands.h"

Mit ersterem bekommt man Definitionen für die ganzen Register und 
Optionen im FT8xx - siehe auch die User-Manuals.
Mit der FT800_commands.h bekommt man Zugriff auf die Funktionen mit 
denen die FT8xx angesprochen werden.

In der main() braucht man dann einen Aufruf von ft800_init(), damit wird 
der Chip erstmal grundsätzlich auf das angeschlossene TFT eingestellt.
Die ft800_init() ist auch der Teil der das Delay() benötigt, und zwar 
für den Power-Down-Reset.
Mit 6 und 21 ms, dazu noch schlapp 5 ms für den AVR Reset, dazu noch 
einige ms um die Bildaten an das TFT zu schicken - das Teil liefert in 
unter 50 ms nach dem Einschalten ein Bild und ist voll funktional, 
darüber staunen meine Kollegen auch immer, Einschalten, läuft.

Als nächstes kann man dann noch ausserhalb der Hauptschleife Bild-Daten 
in den FT8xx schreiben und kann entweder die Touch-Kalibrierung 
ausführen oder aber die REG_TOUCH_TRANSFORM_n Register mit vorher 
aufgezeichneten Werten beschreiben.

Meine Hauptschleife ist ein einfacher "Scheduler" mit vier "Tasks" die 
jeweils 250µs laufen dürfen und einmal pro ms aufgerufen werden.
Im Beispiel habe ich im ersten "Task" meine ft800_loop() eingehängt.

Die ft800_loop() schreibt nun die Anweisungs-Listen für den 
Kommando-Co-Prozessor über dessen 4k FIFO.
Da ich den SPI mit 8 MHz laufen lassen dauert es mindestens 1µs ein 
einzelnes Byte zu übertragen.
Mit Chip-Select und Bits-schubsen sind das vielleicht 200 Bytes die der 
Task innerhalb der zulässigen 250µs schafft.
Da andererseits die Daten gar nicht so schnell im FT8xx landen dürfen 
wie die über den SPI verschickt werden könnten, wird das schicken der 
Liste über das switch(delay) in insgesamt 25 Häppchen unterteilt.
Die Display-Liste wird also alle 25 ms einmal komplettiert, 40 Mal pro 
Sekunde.
Slot 0 nutze ich dabei noch für die Auswertung des Touch-Screens, Slot 
1...3 sind frei um dem FT8xx noch mehr Zeit für die Abarbeitung der 
vorherigen Liste zu geben.
In Slot 4...16 werden die verschiedenen Objekte die zu sehen sind 
definiert und mit Slot 24 wird schliesslich die Liste abgeschlossen und 
der FT8xx zur Abarbeitung aufgefordert.

Ich "reserviere" somit zwar quasi 25% der Rechenzeit eines AVR, die 
werden in den allermeisten Slots aber nicht mal genutzt und einige Slots 
sind auch noch komplett frei. Da geht noch einiges mehr und das für die 
Anzeige auf einem TFT bis zu 800x600 mit 40 Bildern pro Sekunde.
Wenn ich auf dem TFT ein Objekt anklicke, dann gibt es quasi sofort eine 
Reaktion, die Verzögerung sind ja nur maximal 25 ms.
Und für alles drum herum sind 75% Rechenzeit frei.

Ein anderer Ansatz wäre jetzt noch die Daten in einem Puffer zu sammeln 
und diesen alle 25 ms per DMA an den FT8xx zu schicken.
Aber weder hat der 90CAN128 DMA, noch würde ich das SRAM dafür opfern 
wollen.

Mit dem Arduino habe ich das praktisch genau so umgesetzt, nur ist dort 
meine Hauptschleife die loop() und braucht in dem Projekt länger als 1 
ms für einen Umlauf, damit konnte ich die ft800_loop() aber quasi 
identisch übernehmen.

Wichtig für den Arduino ist nur, die FT800_commands.c in 
FT800_commands.cpp und die FT800_config.c in FT800_config.cpp 
umzubenennen.
Sonst stellt sich die SPI-Lib, bzw. deren Include zickig an.
Die FT800_commands.c benutzt dabei nicht mal SPI, includiert aber 
FT800_config.h welche SPI.h includiert...

[Rudolph (Gast)]

Ein winziges Update resultierend aus meinem aktuellen Projekt für das 
ich einen Arduino benutzen soll.

In der FT800.h ist nur was auskommentiert was mit der Arduino IDE 
kollidiert, so aber auch nicht wirklich benutzt wird.
Da ist noch zu viel zu dicht an den Definitionen von FTDI.

In der FT800_config.h muss die Plattform nicht länger eingestellt 
werden, es gibt grundsätzlich eine automatische Unterscheidung von 
Arduino und nicht Arduino.
Und wenn es nicht Arduino ist wird noch auf GNUC/AVR getestet.

Entsprechend ist das in der FT800_config.c auch umgestellt.

Also nichts bewegendes, das ganze ist zumindest für mich auch schon sehr 
gut benutzbar, aber ich dachte mir gerade so, dass ich nach drei Wochen 
auch mal wieder was posten könnte. :-)

[Werner (Gast)]

Hallo Rudolph,
ich habe deine SW mal auf einem MEGA64 getestet, läuft problemlos - 
Kompliment!
Eine Frage: Wie hast du die Bilder generiert? Welches Format ist das?

Werner

[Rudolph R. (rudolph)]

Schön wenn noch jemand Spass an der Geschichte hat, auch wenn ich das 
gerade etwas schleifen lassen muss.
Mein erstes richtiges Projekt war jetzt mit einem VM800B50A, also FTDIs 
5" mit FT800.
Gebraucht habe ich für das Projekt irgendwie nur ein kleines Sub-Set an 
Features, der Kollege wollte mehr oder weniger nur ein Text-Display 
haben, so in richtig nett gemacht. :-)

Wenn man als einfach-so-benutzbar nur 2x16 oder gar mal 4x20 LCDs kennt, 
ist so ein TFT schon sehr fett.
Vor allem kostet das mit dem FT8xx wirklich wenig Resourcen.

Die Bilder in der Daddeldu-Spielplatz Anwendung sind einfach nur .jpg, 
irgendwoher aus dem Netz gezogen, bearbeitet auf die gewünschte 
Auflösung, auf unter 4k gespeichert weil die Library ja nur maximal 4k 
laden kann (noch) und anschliessend mit Hex Workshop geladen und als 
C-Source exportiert. Geladen in den Speicher vom FT800 mit 
ft800_cmd_loadimage().
Ich habe das mal eben mit einem Foto durchgezogen das ich gemacht habe.

Für monochrome Symbole hat sich herausgestellt, dass das mit 
ft800_cmd_inflate() bessere Ergebnisse gibt.
Schön sauber in .png bearbeitet und am Ende dann mit dem Image-Convert 
Tool von FTDI auf "L8" konvertiert hat ein Symbol dann zum Beispiel mit 
100x80 Pixeln 1077 Bytes als .png und 936 Bytes im komprimierten FT800 
Format.
Wenn ich das gleiche Bild als .jpg mit 80% speichere bläht sich die 
Datei auf 1933 Bytes auf und bekommt Kompressions-Artefakte.

[Werner (Gast)]

Hallo Rudolph,

danke für die Info, das mit dem Hex Workshop war der richtige Hinweis!
Ich möchte jpg verwenden, da es später auch für andere möglich sein soll 
die Bilder zu ersetzen. Gespeichert werden die Bilder dann auf einer 
SD-Karte.

Werner

[Rudolph (Gast)]

Ich habe vor ein paar Tagen was neues zum Spielen bekommen.
Und zwar ein RVT70UQFNWC00 von Riverdi.

Dieses TFT hat 7" mit 800x480 Pixel Auflösung und einen FT813 verbaut.
Endlich mal eines mit kapazitiv touch.
Die Pixel sind auch annähernd quadratisch.

Ein wichtiger Unterschied zu den FTDI TFTs ist, dass Riverdi keinen 
Quarz verbaut hat, damit blieb dann spontan die Software in den ersten 
Zeilen der Initialisierung hängen.

Das TFT kommt auch "nackt", zum Lieferumfang gehört weder ein 
Folienkabel, noch ein Breakout-Board dazu mit Gegenstecker.
Riverdi hat passende Breakout-Boards, oder man schnitzt sich was. :-)

Einen ersten schnellen Test-Aufbau habe ich in ein Pult-Gehäuse von 
Hammond gemacht, das ich zusätzlich dafür beschafft hatte.


Das TFT hat keine Pegel-Wandler oder Spannungsregler für die Logik und 
benötigt eine 3,3V Versorgung sowie die Signale mit 3,3V.

Zusätzlich wird noch eine Spannung bis 7V benötigt für die 
Hintergrund-Beleuchtung, die 21 LEDs werden über einen verbauten Regler 
angesteuert.

Das blaue Platinchen im Bild ist ein 5V/600mA StepDown Wandler, die 
größere Platine daneben eigentlich eine 8-Kanal AD-Wandler Platine die 
ich für die Pegel-Wandler umgebastelt habe, zusätzlich sitzt da auch 
noch ein 3,3V LDO drauf.
Und unten dran hängt noch die Platine mit dem 90CAN128 die im ersten 
Post schon mal zu sehen ist.

Ist zwar hässlich und das Folien-Kabel etwas sehr lang, dennoch gehen da 
anstandslos die Daten mit 8 MHz über den SPI.

Das sieht so echt schick aus, die Oberfläche ist eine glatte 
Glas-Scheibe.
Zum Einbau wird das Teil mit doppelseitigem Klebeband ins Gehäuse 
geklebt, so richtig überzeugt mich das nicht, so mechanisch, sieht aber 
erstmal gut aus.
Für einen ordentlichen Einbau würde ich einen Absatz in das Gehäuse 
fräsen damit die ca. 1,5 mm dicke Scheibe bündig abschliesst.

Das reflektiert auch ziemlich stark, wenn das aus ist kann man das 
problemlos als Spiegel benutzen.
Stand der Technik und so.

Wichtig ist auch der Betrachtungswinkel.
Schräg von oben ist der Winkel bei dem man noch was erkennen kann größer 
als von unten, links/rechts soll der nach Datenblatt gleich sein.
Wenn man das etwa an einem Prüfstand verbaut ist es von Vorteil, wenn 
man da von schräg oben drauf schaut oder es eben mechanisch umdreht und 
die Anzeige dreht wenn man normalerweise von schräg unten drauf sieht.

[Rade P. (rade_p)]

Great work,works like a charm using Winavr and atmega328p.Thank you 
Rudolph.But I encounter one small problem that I could not resolve on 
Connect Eve 4,3 bought from Mikroe.com.When printing more then 237 
points
ft800_cmd_point(1, 110, 1);
display freeze,do not start.Any solution or information about this 
problem?

[Rudolph R. (rudolph)]

Well, short answer, every ft800_cmd_point() uses 16 bytes on the 
co-prozessor FIFO, that are 3792 bytes for 237 ft800_cmd_point().
With the start/end sequence and probably some colors this is more than 
the 4k the FIFO is in size.

It is possible though to squeeze in some more since ft800_cmd_point() is 
not a direct command for the FT8xx, more like a meta-command that I put 
together to make things simpler.

void ft800_cmd_point(int16_t x0, int16_t y0, uint16_t size)
{
  uint32_t calc;

  ft800_start_cmd((DL_BEGIN | FT_POINTS));

  calc = POINT_SIZE(size*16);
  spi_transmit((uint8_t)(calc));
  spi_transmit((uint8_t)(calc >> 8));
  spi_transmit((uint8_t)(calc >> 16));
  spi_transmit((uint8_t)(calc >> 24));

  calc = VERTEX2F(x0 * 16, y0 * 16);
  spi_transmit((uint8_t)(calc));
  spi_transmit((uint8_t)(calc >> 8));
  spi_transmit((uint8_t)(calc >> 16));
  spi_transmit((uint8_t)(calc >> 24));

  spi_transmit((uint8_t)(DL_END));    // Send data low byte
  spi_transmit((uint8_t)(DL_END >> 8));
  spi_transmit((uint8_t)(DL_END >> 16));
  spi_transmit((uint8_t)(DL_END >> 24));    // Send data high byte

  ft800_cs_clear();
  ft800_inc_cmdoffset(12);  // update the command-ram pointer
}

Apart from the luxury of the all-in-one-go "command" it is however not 
necessary to use the graphics primitves like this.

There is no need to always issue begin/end and there is no need to alwas 
send the point_size(), well except when every point is supposed to be a 
different size. :-)

I can't test this right now because I have no TFT here, but this should 
result in four points with only 28 bytes of the FIFO used instead of 64.

      ft800_cmd_dl(DL_BEGIN | FT_POINTS);
      ft800_cmd_dl(POINT_SIZE(20*16); // size is in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(50*16,100*16); // x/y are in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(80*16,100*16); // x/y are in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(110*16,100*16); // x/y are in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(140*16,100*16); // x/y are in 1/16 pixel
      ft800_cmd_dl(DL_END);

I tried this in the screen-designer as well and this displays six 
points:

CLEAR(1, 1, 1)
BEGIN(POINTS)
POINT_SIZE(256)
VERTEX2II(96, 78, 0, 0)
VERTEX2II(164, 136, 0, 0)
VERTEX2II(80, 140, 0, 0)
POINT_SIZE(125)
VERTEX2II(189, 67, 0, 0)
VERTEX2II(135, 218, 0, 0)
VERTEX2II(266, 154, 0, 0)
END()

Notice that the screen-designer always put this in the list for
every point you drag into the screen:

BEGIN(POINTS)
VERTEX2II(300, 95, 0, 0)
END()

So the meta-commands ft800_cmd_point(), ft800_cmd_rect() and 
ft800_cmd_line() come with the price of some overhead.

[Rade P. (rade_p)]

Thank you,this solved my problem.
      ft800_cmd_dl(DL_BEGIN | FT_POINTS);
      ft800_cmd_dl(POINT_SIZE(20*16)); // size is in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(50*16,100*16)); // x/y are in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(80*16,100*16)); // x/y are in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(110*16,100*16)); // x/y are in 1/16 pixel
      ft800_cmd_dl(VERTEX2F(140*16,100*16)); // x/y are in 1/16 pixel
      ft800_cmd_dl(DL_END);
Now I can print 940 points maximum and it just work for me.
Thanks again

[peter (Gast)]

Ich habe eine Frage über die Verbindung
wie zur Verfügung haben FT810CB HY50D
und M644, wenn Sie das Programm versuchen, bekomme ich nur einen weißen 
Bildschirm
was ist falsch?>

[Rudolph R. (rudolph)]

Also ein weisser Bildschirm ist ziemlich ungewöhnlich.
Damit scheint zumindest die Initialsierung schon mal soweit 
durchzulaufen, dass die Hintergrund-Beleuchtung eingeschaltet wird.

Ist das mit meinem Test_M644_FT810.zip von weiter oben?
Ein weisses Bild deutet auf Anpassungen hin, welche?
Oder ist das ganz neuer Code?

Wie ist der M644 genau verschaltet bei Dir?

Ist die FT800_config.h richtig eingestellt?

Ohne Informationen wird das hier nichts.
Und ein Support-Forum ist das hier auch nicht, etwas Mühe musst Du Dir 
schon geben - und das gilt auch für das abgelieferte Geschreibsel.

[peter (Gast)]

Hallo
In der Tat, äußerte ein paar präzise
TEST M644 ist so im Voraus eingestellt FT800_config zu HY50D und AVR8

Verbindung zum LCD

GND - GND
5V - 5V
MISO - PB6
SCK - PB7
CS - PB4
MOSI - PB5
PD - PB3
INT - PB2

F_CPU 16MHz
ATmega 644

Ich habe auf verschiedene Weise versucht, leider, erreicht nur einen 
weißen Bildschirm
Nichts anderes zeigt
auf dem Bildschirm ... manchmal ist dieser Effekt, dass das trübe Licht 
nach einer Weile und grau ist,

Ich habe auch versucht die FT811 auch mit 5 "LCD dachte ich, dass etwas 
nicht in Ordnung ist und vielleicht beschädigt sind, aber die mbed zu 
betreiben beide Nucleo

[Rudolph R. (rudolph)]

Okay, German is not your native language, no problem.
But please refrain from sending text thru a translator, thank you.

And please also provide some source-code that can be checked for erros.
Preferably in a project that can be build.

In the meantime I modified my example from above a little, please check 
if that works.

In addition, check if your controller really is running at 16 MHz.
Is the crystal really activated? Is the CKDIV8 fuse off?

[peter (Gast)]

Hi

I'm sorry for the google translator, I do not speak German
Annex setting fusebits. I use AS7.790 Atmel Tolchain

I downloaded the program and I have uploaded to the microcontroller
the effect on the screen

ATmega 644 is working properly at 16Mhz CKdiv8 Off

Thank you for your help.

[peter (Gast)]

Compilation proceeds without errors

[peter (Gast)]

Thank you very much for help

it turned out that my ATmega is defective
I mentioned the new and everything works properly

Thanks again for your help
Excellent work with the library

[Rudolph (Gast)]

I am still perplexed about the white screen, that shouldn't even be 
possible.

A few observations though.

You have the M644 running at 3,3V.
-> 16MHz is out of spec then
-> the HY50D expects 5V as supply and on the SPI

You are using ISP with the M644 so there might be a conflict
with the attached programmer.

If you already use 5V as supply for the FT810CB-HY50HD, is this supply 
stable and does it deliver enough current?
The specifications for the FT810CB-HY50HD can be called weak at best but 
the 5V supply should be at least able to supply 200mA.

And if you are using 5V for the FT810CB-HY50HD, there should be an 
additional level-shifter in place.

So at first I would supply 5V to the M644 as well, given that the
rest of the board is fine with it.

[Rudolph (Gast)]

peter schrieb:
> it turned out that my ATmega is defective
> I mentioned the new and everything works properly

Oh, that went a bit in parallel. :-)

If this new M644 is still running at 3.3V it might not live that long. 
:-)

[peter (Gast)]

Hi

ATmega 644 runs on 5V
I am available to 2000mA so enough power
Disconnect the LCD for programming.

For some reason, it is damaged and PB2 PB7 in the microcontroller, 
strange because
He is giving the program and LCD Nokia 3310 worked, but Analaizator 
Logical showed, however, that the SPI is not working properly ...

Fortunately, a new working properly and mute any problems :)
So once again thank you for your help.

[Torsten C. (torsten_c)]

Hallo Rudolph,

wie Du im anderen Thread schon gelesen hast, arbeite ich aktuell mit 
einem A137 TouchTFT 320x240[1]. Ich finde aber Deine Lib sehr 
interessant, obwohl ich noch nicht ganz verstanden habe, wie sich diese 
von den anderen Libs, z.B. [2], [3] oder [4] abgrenzt.

Magst Du Deine Lib auf ein GIT Oder SVN einstellen?

Ich würde mein Display [5] gern über die gleiche API (daher der 
Interface-Lolli im Bild) ansprechen, über die ich auch eine Lib für das 
A137 anspreche.

BTW: Um zu vergleichen, ob sich beide Displays über das SW-Interface 
wirklich gleich verhalten, hatte ich mir überhaupt nur das [5] gekauft.

[1]
https://github.com/TorstenC/A137_TouchTFT_320x240
[2]
http://www.ftdichip.com/Support/Documents/AppNotes/AN_318_Arduino_Library_For_FT800_Series.pdf
[3]
http://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm
[4]
https://github.com/guillaumesmo/FT800
[5]
ebay 172251933809

[Rudolph R. (rudolph)]

Torsten C. schrieb:
> obwohl ich noch nicht ganz verstanden habe, wie sich diese
> von den anderen Libs, z.B. [2], [3] oder [4] abgrenzt.

Naja, sie ist von mir. :-)
Ich wollte einfach tiefer einsteigen in die Dinger und nicht einfach 
eine fertige Library benutzen.

Meine Library hat zum Beispiel weniger Overhead als die von FTDI.

Es gibt auch noch mehr da draussen, etwa von Glyn oder für das 
Gameduino2.

> Magst Du Deine Lib auf ein GIT Oder SVN einstellen?

Zu diesem Zeitpunkt, nein, ich habe zwar versucht das vorzubereiten 
indem ich die Header entsprechend gestaltet habe, rein praktisch würde 
mir das im Moment aber nichts bringen.

Ich habe da auch gerade einen Studenten dran sitzen der sich damit 
austoben darf in der Firma, ich muss mal schauen was ich davon noch 
alles hier einstellen kann.
Zumindest ein schickeres Beispiel könnte dabei abfallen. :-)

> BTW: Um zu vergleichen, ob sich beide Displays über das SW-Interface
> wirklich gleich verhalten, hatte ich mir überhaupt nur das [5] gekauft.

Ich weiss nicht, was ein "A137" Display ist.
Aber ich habe gerade mal das Datenblatt von dem SSD1325 überflogen und 
der spielt nicht nur in der Kreisliga dagegen, der spielt auch ein 
anderes Spiel.
Das Ding kann gerade mal 128x80 Pixel mit 16 Graustufen und hat kaum 
Hilfsfunktionen.
Der kann auch kein Touch.

Der FT800 ist aus der ersten Generation und kann bis 512x512 Pixel mit 
18 Bit Farben.
Die FT81x können bis 800x600 bei 24 Bit Farben.
Inklusive Touch.

Die FT8xx werden in aller Regel auch nicht mit Pixeln beschrieben, es 
gibt sogar nicht mal die direkte Möglichkeit einzelne Pixel zu setzen.
Es gibt keinen Framebuffer in den man direkt schreiben könnte um etwa 
ein Pixel an Position 155/62 direkt zu manipulieren.

Wenn man ein "Hallo" schreiben will muss man denen nur mitteilen wohin 
und mit welchem der eingebauten Zeichensätze.
Passt einem der Zeichensatz nicht gibt man dem FT8xx einen eigenen.
Danach baut sich der FT8xx das Bild für "Hallo" selber aus den Daten vom 
Zeichensatz zusammen.

Bilder werden in den Speicher des FT8xx geladen und nur referenziert.
In diversen Formaten.

Der Bildaufbau beim FT8xx passiert über eine Liste mit Anweisungen
die der sogenannte Kommando Co-Prozessor abarbeitet.
Eine Einschränkung dabei ist, dass die Liste nur 4096 Bytes lang sein 
kann, eine andere dass man die Liste nicht schneller schicken sollte als 
der Bild-Refresh ist, also typisch 60 Hz.

Also wenn man eine Anwendungs-Schicht schafft für beide Display-Chips, 
dann müsste da drunter der SSD1325 Treiber erheblich mehr tun.
Das ist wie Äpfel mit Toastern zu vergleichen. :-)

Mein bescheuertes Spielplatz-Beispiel kommt übrigens auf 108 Bytes RAM 
Nutzung, mindestens 37 Bytes sind für nichts anderes benutzt als die 
dynamische Interaktion per Touch mit dem TFT.
Natürlich war mir das in dem Beispiel völlig egal, das sind 2,6% von den 
4k die der 90CAN128 an SRAM hat.

[Markus (Gast)]

Hallo Rudolph,

könntest Du ein Bild hier rein stellen, welches die Fähigkeiten Deiner 
Lib. zeigt? Ich habe kein FT800, aber es wäre vielleicht interessant.

Gruß,
Markus

[Rudolph R. (rudolph)]

Ein Bild das die Fähigkeiten der Library zeigt macht wenig Sinn.
Das hier ist keine Grafik-Library für dumme Pixel-Displays die Funktion 
ft800_cmd_line() zum Beispiel berechnet nicht Punkt für Punkt jeden 
Pixel zwischen zwei Punkten.

Die FT8xx sind quasi Grafik-Karten für MikroController, gibt man denen 
den Auftrag zwischen zwei Punkten eine Linie zu ziehen, dann machen die 
das selbstständig - mit Anti-Aliasing.

Diese Library hier macht "nur" die vorhandenen Funktionen der FT8xx 
leichter zugänglich, statt sowas hier "von Hand" über den SPI zu 
schicken:

0x0c 0xff 0xff 0xff
0xc8 0x00 0xc8 0x00
0x1a 0x00 0x00 0x00
0x48 0x61 0x6c 0x6c
0x6f 0x00 0x00 0x00

Kann man das hier schreiben:
ft800_cmd_text(200, 200, 26, 0, "Hallo");

Eine Übersicht was die FT8xx können findet sich in den Datenblättern 
sowie auf der Homepage von FTDI.

Ein Anhaltspunkt ist vielleicht noch meine FT800_commands.h.
Neben den Wrapper-Funktionen für die FT8xx Kommandos gibt es auch noch 
Support-Funktionen wie ft800_init(), ft800_busy() und 
ft800_get_touch_tag().

[Torsten C. (torsten_c)]

Rudolph R. schrieb:
> Also wenn man eine Anwendungs-Schicht schafft für beide Display-Chips,
> dann müsste da drunter der SSD1325 Treiber erheblich mehr tun.

Ja. Meine Projektidee ist, die FT800-Funktionalität in SW auf einem 
STM32 zu realisieren (FT8xxx.png: Rechts in der Mitte) und über eine 
identische API (FT8xx.h) wahlweise den FT800 oder die Lib für den STM32 
anzusprechen.

Ziel ist:
Im Ergebnis verhalten sich beide Systeme gleich, hinter der API.

Rudolph R. schrieb:
> Ich weiss nicht, was ein "A137" Display ist.

Das war auch nur ein Beispiel, da billig und mit Touch, siehe
Beitrag "A137 Touch TFT 320 x 240 für 3€"

> Aber ich habe gerade mal das Datenblatt von dem SSD1325 überflogen …
Das wäre OLED, kein TFT und hat - wie Du selbst schreibst - kein Touch.

Rudolph R. schrieb:
>> Magst Du Deine Lib auf ein GIT Oder SVN einstellen?
> Zu diesem Zeitpunkt, nein …

Deine API sieht recht 'angenehm programmierbar' aus, daher liegt es 
nahe, sie für so ein Projekt zu branchen. Irgendwann laufen sie dann 
natürlich auseinander.

[Rudolph R. (rudolph)]

Torsten C. schrieb:
> Ziel ist:
> Im Ergebnis verhalten sich beide Systeme gleich, hinter der API.

Der Sinn der Übung erschliesst sich mir nicht wirklich.
Eine Grafik-Lib zu erweitern das die auch den FT8xx untersüttzt würde 
irgendwie mehr Sinn ergeben.

> Das war auch nur ein Beispiel, da billig und mit Touch, siehe
> Beitrag "A137 Touch TFT 320 x 240 für 3€"

Ah, okay, FD5408 Display-Controller mit Parallel-Interface.
Der kann soweit auch nichts, ebenfalls kein Touch.
Das Display hat eine 4-Draht Resistiv Touch Folie drauf die man selber 
auswerten muss.

> Deine API sieht recht 'angenehm programmierbar' aus,

Nochmal, das sind mehr Wrapper-Funktionen für die Funktionalität vom 
Chip.
Das ist einerseits ziemlich dicht am Datenblatt, zum anderen bin ich 
auch noch nicht wirklich mit dem Ergebnis zufrieden.

[Torsten C. (torsten_c)]

Rudolph R. schrieb:
> … zum anderen bin ich
> auch noch nicht wirklich mit dem Ergebnis zufrieden.

Womit zum Beispiel?

> Der Sinn der Übung erschliesst sich mir nicht wirklich.

Ich erwarte nicht, dass das jemand die Übung toll findet.
Es ist ein Vorschlag bzw. die Idee zur Wiederverwendung,
also Deinen 'wrapper' als Quasi-Standard-API zu nutzen.

Trotzdem zum besseren Verständnis ein Beispiel:
Nimm eine Schüler-Arbeitsgemeinschaft, bei der Du die Kinder von 'nicht 
reichen' Eltern nicht benachteiligen willst. Mit wenigen Original 
30€-FT800CB-HY43B können einige Schüler ihre GUI-Programme gegen die API 
programmieren und testen, wärend die anderen Schüler dafür sorgen, dass 
später alle ein Billig-LCD nehmen können.

> Das Display hat eine 4-Draht Resistiv Touch Folie drauf die man selber
> auswerten muss.
Richtig, ein STM32 hat aber A/D-Umsetzer eingebaut.

[Rudolph R. (rudolph)]

Torsten C. schrieb:
>> auch noch nicht wirklich mit dem Ergebnis zufrieden.
>
> Womit zum Beispiel?

Mir gefällt zum Beispiel der "FT800_" Präfix noch nicht so richtig.
Zum einen bin ich aktuell mit einem FT813 unterwegs, zum anderen wird 
das nicht mal durchgängig verwendet, weil ich einen Teil der Includes 
von FTDI übernommen habe.

"FT8_" wäre eine Idee das zu lösen, dann würde das auch zu einem 
potentiellen FT821 passen den es noch nicht gibt. :-)

>> Der Sinn der Übung erschliesst sich mir nicht wirklich.
>
> Ich erwarte nicht, dass das jemand die Übung toll findet.
> Es ist ein Vorschlag zur Wiederverwendung,
> also Deinen 'wrapper' als Quasi-Standard-API zu nutzen.
>
> Trotzdem zum besseren Verständnis ein Beispiel:
> Nimm eine Schüler-Arbeitsgemeinschaft, bei der Du die Kinder von 'nicht
> reichen' Eltern nicht benachteiligen willst. Mit wenigen Original
> 30€-FT800CB-HY43B können einige Schüler ihre GUI-Programme gegen die API
> programmieren und testen, wärend die anderen Schüler dafür sorgen, dass
> später alle ein Billig-LCD nehmen können.

Auch für den Fall würde ich das anders herum machen.
Eine Funktion mit den Namen FT800_cmd_text() macht doch weniger Sinn als 
eine Funktion tft_text() die wahlweise das eine der das andere macht.

Was ist mit so Libraries wie u8lib oder ucglib?
Ist die API da so hässlich, dass man das neu machen muss?
Ich weiss es nicht, bisher habe ich sowas nicht benötigt.

Grundsätzlich liegen da auch Welten zwischen den Dingern in der 
Performance.
Wie ist das, man braucht drei Transfers bei dem billig Display für einen 
Pixel? Das sind dann 256 Transfers für einen 16x16 Pixel Buchstaben.
Dazu noch die notwendige Adressierung.

https://www.mikrocontroller.net/attachment/291101/VM800B35_FT800_1.JPG

Das ist auf einem 3,5" 320x240 TFT mit resistiv Touch.
-40 Bilder pro Sekunde
-das "12345" ist eine Tastatur, bei Betätigung wird ein zusätzlicher 
grüner Kreis gemalt in unterschiedlichen Größen
-die großen Bilder werden bei Touch-Events sofort getauscht
-das Ding unter der "TAG: 0" Ausgabe ist ein Fortschrittsbalken der 
durchläuft
-mit dem Slider ganz unten kann man den kompletten restlichen 
Bild-Inhalt links/rechts verschieben (VM800B35_FT800_4.JPG)
-betätigt man den Toggle-Button der im Bild auf "aus" steht werden 
sofort die grossen Bilder gegen einen Rotary-Dial und eine Gauge 
getauscht
-das Bild mit den kleinen Quadraten fängt an sich zu drehen - gefiltert

Und so weiter, die Bilder werden dem nicht mal ansatzweise gerecht, 
dabei "reserviere" ich 25% Rechenleistung eines 8-Bit AVR auf 16 MHz, 
genuzt wird nur ein kleiner Teil davon.
Der SPI läuft dabei auch "nur" auf 8 MHz - der AVR kann eben nicht mehr 
als 1/2 Takt.

Damit dürfte auch ein STM32 ins Schwitzen kommen mit dem billig TFT, das 
ganze notwenige Gefummel mit den Portpins ist ja sowieso schon keine 
Stärke der ARMs, in Summe dürfte das tödlich sein.

Die "Spirale" die gedreht wird hat 64x64 Pixel.
Das sind >12k Schreibzugriffe für das $3 Display.
Gedreht wird in 1,4° Schritten mit einfachem Anti-Aliasing.
Die Auflösung wäre 1/65536 Teile eines Kreises aber ich addiere 40 Mal 
pro Sekunde 256.

Die größeren Bilder haben 96x96 Pixel.

Also "nicht benachteiligen" ist ja richtig, man kann für die 3$ aber 
nicht mal ansatzweise zum gleichen Ergebnis kommen.

Ein Grund für mich das hier öffentlich zu machen ist die FT8xx damit zu 
supporten.
In der Hoffnung, dass die irgendwann billiger zu haben sind.

Das günstigste mir bekannte ist das FT800CB-HY43B mit FT800, 4,3" mit 
480x272 Pixeln für $25.
Dem vorziehen würde ich aber das FT800CB-HY50B mit 5" für $28.

Und so richtig gut sind die auch nicht, der Blickwinkel ist etwas klein.

Also nicht benachteiligen wäre eher, jedem das gleiche zu geben.
Und zwischen dem $3 und einem TFT mit FT800 muss es auch noch was geben 
das zwar immer noch einfach und preiswert aber deutlich performanter 
ist. :-)

>> Das Display hat eine 4-Draht Resistiv Touch Folie drauf die man selber
>> auswerten muss.
> Richtig, ein STM32 hat aber A/D-Umsetzer eingebaut.

Die AD-Werte sind eine Sache, das bekommt man auch mit einem AVR hin.
Dann muss man daraus noch Koordinaten berechnen und heraus finden, 
welches Objekt überhaupt an den Koordinaten liegt.
Man müsste für jedes Objekt das touchbar sein soll zwei Kordinaten 
speichern die ein Rechteck aufspannen.

Der FT8xx könnte sogar per Interrupt melden wenn getoucht wird - und 
zwar was genau.
Da ich die Abfrage per pollen 40 Mal pro Sekunde einfach nebenbei machen 
kann, ist mir das mit dem Interrupt aber zu albern.

[Torsten C. (torsten_c)]

Danke, Rudolph, für Deine ausführlichen Antworten. Ich will Deinen 
Thread auch nicht weiter mit diesem "Exkurs" verwässern.

Präfix "FT800_" oder "FT8_" ist ja schon "jammern auf hohem Niveau". Ich 
dachte, Du siehst essentielle Probleme. Gut. Die ucglib schaue ich mir 
an, nochmal danke.

Rudolph R. schrieb:
> … man braucht drei Transfers bei dem billig Display für einen Pixel? …
Ja, es sind drei Transfers á 8 Bits.
> Damit dürfte auch ein STM32 ins Schwitzen kommen mit dem billig TFT, das
> ganze notwenige Gefummel mit den Portpins ist ja sowieso schon keine
> Stärke der ARMs, …
Mit nWR und nRD über Timer und Daten über PB0..7 und DMA läuft der 
Transfer im Hintergrund, ohne die CPU zu belasten.

> Also "nicht benachteiligen" wäre eher, jedem das gleiche zu geben.
Das FT800CB-HY43B ist nur für die "Design-Time",
nicht für die "Run-Time".

Um bei dem oben genannten Beispiel zu bleiben: Das bzw. die 
FT800CB-HY43B werden anschließend natürlich wieder eingesammelt.

> … man kann für die 3$ aber nicht mal ansatzweise zum gleichen Ergebnis
> kommen.
Das wird sich zeigen. Vielleicht wirst Du Recht haben.
Ich würde aber trotzdem gern ein proof-of-concept umsetzen.

Ich sehe gerade:
Den Sound Synthesizer hatte ich noch gar nicht auf dem Schirm. :-(

> … 40 Bilder pro Sekunde …
> Die "Spirale" die gedreht wird hat 64x64 Pixel. …
Gute Beispiele, die man für einen Performance-Vergleich nutzen sollte.
40 Bilder pro Sekunde wird der STM32 mit 3€-TFT nicht schaffen, aber 15 
Bilder pro Sekunde wären auch noch halbwegs ruckelfrei.

Rudolph R. schrieb:
> Dem vorziehen würde ich aber das FT800CB-HY50B mit 5" für $28.

Habe ich weder in der Bucht noch bei Ali für den Preis gefunden.
Hast Du einen Link?

[Markus (Gast)]

>Das ist auf einem 3,5" 320x240 TFT mit resistiv Touch.
Das hier hat die gleich Auflösung, ist aber ein wenig klein:

Beitrag "Re: 2.2'TFT ILI9340 und Arduino"

 Torsten C. (torsten_c) Benutzerseite
>Ich erwarte nicht, dass das jemand die Übung toll findet.
>Es ist ein Vorschlag bzw. die Idee zur Wiederverwendung,
>also Deinen 'wrapper' als Quasi-Standard-API zu nutzen.

Ich finde Deine Übung gut. Es macht ziemlich viel Sinn, einen Wrapper 
für verschiedene TFTs zu schreiben. Dann kann man das TFT einfach 
austauschen.
Ich würde aber den Prefix für die Funktionen nicht FT800 nennen, sondern 
eher was allgemeines wie z.B. TFT_drawLine(..) o.ä.

[Werner (Gast)]

Hallo Rudolph,

hast du schon mal mit den Schriftgrößen 32-34 gearbeitet?
Ich komme irgendwie nicht daruf, wie ich die Ansteuerun muß.
Werner

[Rudolph R. (rudolph)]

Ich habe die noch nicht benutzt, in meinem aktuellen Projekt mit dem 
RVT70UQFNWC00 hätte ich eher noch einen kleineren unter 26 gebraucht. 
:-)

Aber nach FT81X_Series_Programmer_Guide.pdf ist das eigentlich ganz 
einfach.
Man benutzt CMD_ROMFONT um ein Bitmap-Handle auf einen der Fonts zu 
setzen und gibt das dann bei CMD_Text mit an:

cmd_romfont(1, 31);
cmd_text( 0, 0, 1, 0, "31");
cmd_romfont(1, 32);
cmd_text( 0, 60, 1, 0, "32");
cmd_romfont(1, 33);
cmd_text(80,-14, 1, 0, "33");
cmd_romfont(1, 34);
cmd_text(60, 32, 1, 0, "34");


Ich muss auch mal wieder ein Update machen, auch wenn das jetzt keine 
gravierenden Änderungen gab bisher.

Das Beispiel kann ich auch mal überarbeiten, ich teile mein Layout jetzt 
in einen statischen und einen dynamischen Teil auf,
der statische Teil wird nur einmal übertragen und dann mit CMD_APPEND 
immer wieder in die aktuelle Liste gehängt - das spart je nach Layout 
ordentlich was an Übertragungen auf dem SPI.
Mein aktuelles Projekt ist ein Stand-alone Test-System, da werden 
diverse Messwerte ausgegeben, drei Slider und ein Toggle-Button als 
Bedien-Elemente.
Der ganze sonstige Text, einige Linien, ein Logo, farbige Flächen, das 
ist alles statisch, machen aber mehr als 2/3 der Daten aus die ohne 
CMD_Append immer mit über den SPI geschickt werden müssten.

[Werner (Gast)]

Hallo Rudolph,
danke für deine schnelle Antwort. Ich bin inzwischen auch dahinter 
gekommen und habe folgende Funktion in deine Lib eingefügt:

void ft800_cmd_romfont(uint32_t font, uint32_t romslot)
{
  ft800_start_cmd(CMD_ROMFONT);

  spi_transmit((uint8_t)(font));    // Send data low byte
  spi_transmit((uint8_t)(font >> 8));
  spi_transmit((uint8_t)(font >> 16));
  spi_transmit(0x00);
  spi_transmit((uint8_t)(romslot));  // Send data low byte
  spi_transmit((uint8_t)(romslot >> 8));
  spi_transmit((uint8_t)(romslot >> 16));
  spi_transmit((uint8_t)(romslot >> 24));

  ft800_inc_cmdoffset(8);  // update the command-ram pointer
  ft800_cs_clear();

}

Benutzt du eigentlich den ScreeDesigner von FTDI?
Ich mach momentan Macros, damit die Ausgaben vom ScreenDesigner 
möglichst 1zu1 übernommen werden können.

Werner

[Rudolph (Gast)]

Ups, stimmt, es gibt in der veröffentlichten Version noch gar kein 
ft800_cmd_romfont() :-)

#ifdef FT_81X_ENABLE
void ft800_cmd_romfont(uint32_t font, uint32_t romslot)
{
  ft800_start_cmd(CMD_ROMFONT);
  
  spi_transmit((uint8_t)(font));
  spi_transmit((uint8_t)(font >> 8));
  spi_transmit(0x00);
  spi_transmit(0x00);
  
  spi_transmit((uint8_t)(romslot));
  spi_transmit((uint8_t)(romslot >> 8));
  spi_transmit(0x00);
  spi_transmit(0x00);  
  
  ft800_inc_cmdoffset(8);
  ft800_cs_clear();
}
#endif

Also kein wesentlicher Unterschied. :-)

Den Screen-Editor benutze ich im Moment nicht, ich hatte mal angefangen 
das Python-Script von Glyn umzuschreiben.
Nur habe ich bisher weder was mit Python gemacht, noch war der 
Leidensdruck das zu tun hoch genug. :-)

[Thomas (Gast)]

Hallo zusammen,
in der Hoffnung, dass mir jemand weiter helfen kann poste ich unten 
folgenden (kleinen) code der im Prinzip von Rudolf übernommen wurde.
Das Problem was ich habe ist, dass ich einfach nicht die chipid 0x7C 
zurück bekomme. Der Wert den ich am Anfang zurück bekomme ist immer 0, 
nach einigen Millisekunden 255.

Was mache ich falsch? ich bin langsam am Verzweifeln.
Ich verwende Arduino Teensy 3.6 180MHz und das HAOYU FT811CB Display.
(Vielleicht klappt der code ja bei Eurem Display)

Vielen Dank für eure Hilfe im Voraus.

LG

Thomas


#include <SPI.h>

#define ACTIVE  0x00  // Place FT800 in active state
#define CLKEXT  0x44  // Select external clock source
#define CLK48M  0x62  // Select 48MHz PLL output

#define REG_ID        0x102400UL
#define REG_PWM_DUTY  0x1024c4UL

#define MEM_WRITE 0x80  // FT800 Host Memory Write
#define MEM_READ  0x00  // FT800 Host Memory Read

#define intPin 6
#define pdnPin 7
#define csPin 10

void ft800_cmdWrite(uint8_t data)
{
  digitalWrite(csPin,LOW);
  SPI.transfer(data);
  SPI.transfer(0x00);
  SPI.transfer(0x00);
  digitalWrite(csPin,HIGH);
}

uint8_t ft800_memRead8(uint32_t ftAddress)
{
  uint8_t ftData8 = 0;
  digitalWrite(csPin,LOW);
  SPI.transfer((uint8_t)(ftAddress >> 16) | MEM_READ);
  SPI.transfer((uint8_t)(ftAddress >> 8));
  SPI.transfer((uint8_t)(ftAddress));
  SPI.transfer(0x00);
  ftData8 = SPI.transfer(ftData8);
  digitalWrite(csPin,HIGH);
  return ftData8;
}

void setup() {

  pinMode(intPin,INPUT);
  pinMode(csPin,OUTPUT);
  pinMode(pdnPin,OUTPUT);
  digitalWrite(csPin,HIGH);
  digitalWrite(pdnPin,HIGH);

  Serial.begin(9600);
  delay(500);
  SPI.begin();
  delay(500);
  SPI.beginTransaction(SPISettings(5000000, MSBFIRST, SPI_MODE0));
  delay(500);

  digitalWrite(pdnPin,LOW);
  delay(6);
  digitalWrite(pdnPin,HIGH);
  delay(21);

  ft800_cmdWrite(CLKEXT);
//  ft800_cmdWrite(FT_CLK48M);
  ft800_cmdWrite(ACTIVE);

  byte chipid = ft800_memRead8(REG_ID);
  while(chipid != 0x7C)
  {
    Serial.println(chipid);
    chipid = ft800_memRead8(REG_ID);
  }
  Serial.println("chipID is 0x7C");
}

void loop() {
}

[Rudolph R. (rudolph)]

Thomas schrieb:
> #define REG_ID        0x102400UL

Für den FT811 wäre das aber:
#define REG_ID 3153920UL

Warum übernimmst Du nicht einfach den kompletten Code?

Das ist ja nicht ganz grundlos im wesentlichen portierbar gehalten und 
läuft auch ohne Probleme mit Arduino. :-)

Ja, ich muss mal wieder ein Update posten, ist in Arbeit. :-)

[here (Gast)]

Rudolph R. schrieb:
> Der SPI ist auf 8 MHz eingestellt, mehr geht mit den AVR nicht.
> Wenn man das an einem schnelleren Controller verwendet ist zu beachten,
> dass der SPI beim Aufruf der ft800_init() noch langsamer als 11 MHz
> eingestellt sein muss, danach darf der dann bis 30MHz laufen.

@Thomas:
Wie ist Deine SPI-Frequenz? 5 MHz?
Hast Du mal mit dem Scope nachgemessen?

[Rudolph R. (rudolph)]

Okay, hier mal das Update.

Das Archiv enthält ein Atmel-Studio 7 Projekt für einen 90CAN64.
Das benutzte TFT ist ein RVT70UQFNWC0x von Riverdi mit einem FT813 
drauf.

FT800.h version 2.2
FT800_commands.c version 2.4
FT800_commands.h version 2.3
FT800_config.c version 2.5
FT800_config.h version 2.5

Die "Spielplatz" Anwendung habe ich durch ein etwas ernster gemeintes 
Beispiel ersetzt. :-)

main.c - AVR spezifisch, macht aber kaum was

tft.c / tft.h - Plattform unabhängig, hier wird das TFT bedient
tft_data.c / tft_data.h - nur ein einfaches Logo als Beispiel-Bild

Im Moment läuft in der Mitte einfach nur eine Uhr durch, da wollte ich 
eigentlich eine Stoppuhr mit Start/Stop und Reset Button draus machen.
Und Rechts sind nur einmal die eingebauten Zeichensätze dargestellt, 
Nummer 17 und 19 sind übrigens spezielle Fonts mit Symbolen.

Für ernst gemeinte Vorschläge was man in der Mitte und Rechts 
demonstrieren könnte bin ich aber durchaus offen. :-)

Ach ja, das Beispiel demonstriert auch die Verwendung von 
ft800_cmd_append().
Die Anzeige ist jetzt aufgeteilt in einen statischen Teil der in der 
Funktion initStaticBackground() nur ein einziges Mal im Speicher des 
FT81x erzeugt wird und einen deutlich kleineren dynamischen Teil der in 
der Funktion FTF_loop() erzeugt wird.
Auf die Art müssen erheblich weniger Daten über den SPI geschickt 
werden.

[Thomas (Gast)]

Hallo Rudolph,

danke das hat das Problem gelöst. Vielen vielen Dank!!!

Schöne Weihnachten!

LG

Thomas

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

Hello Rudolph,

many thanks for your library, it's great! Do you happen to know how to 
display JPEG image which size is greater than 4kB FIFO (is it even 
possible)?

Best regards,
Paweł.

[Rudolph R. (rudolph)]

Yes, loading images larger than the size of the FIFO is possible, and I 
already have code for it that a colleague of mine provided.
I only did not have much use for it so I did not evaluate it properly so 
far.

What is needed is to extend ft800_cmd_loadimage() to handle buffers that 
are larger than 4k in chunks of a little less than 4k.
It's like this:
start-command
send 4k data
execute
wait
send 4k data
execute
wait
send remaining data
execute
done

On FT810/FT811/FT812/FT813 however ft800_cmd_mediafifo should be the 
better option, you reserve for example the upper 64k of gfx-mem, put 
your data there and then tell loadimage to load its data from there.

Although I very much prefer FT81x, I did not test this either so far.

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

Thanks Rudolph for your reply. I tried to implement your suggestions on 
FT800 using project which you provided. When I load only one JPG file to 
FTDI main RAM memory:

  ft800_cmd_loadimage(0, FT_OPT_NODL, sam, 3708);
  ft800_cmd_execute();
  while(ft800_busy() == 1);

then I can display that image multiple times on my screen and everything 
works just fine as I want (that's how I do it - correct me please if I'm 
doing something wrong):

  ft800_cmd_dl(CMD_DLSTART);
  ft800_cmd_dl(DL_CLEAR_RGB | GREEN);
  ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

  ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
  ft800_cmd_dl(BITMAP_SOURCE(0));
  ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
  ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
  ft800_cmd_dl(VERTEX2II(0,0,0,0));

  ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
  ft800_cmd_dl(BITMAP_SOURCE(0));
  ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
  ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
  ft800_cmd_dl(VERTEX2II(96,0,0,0));

        ft800_cmd_execute();
  while(ft800_busy() == 1);

        ft800_cmd_dl(DL_DISPLAY);
        ft800_cmd_dl(CMD_SWAP);
  ft800_cmd_execute();

But when I try to load another JPG:

  ft800_cmd_loadimage(0, FT_OPT_NODL, sam, 3708);
  ft800_cmd_execute();
  while(ft800_busy() == 1);

  ft800_cmd_loadimage(3709, FT_OPT_NODL, jpg3, 2488);
  ft800_cmd_execute();
  while(ft800_busy() == 1);

and then when I try to display it:

  ft800_cmd_dl(CMD_DLSTART);
  ft800_cmd_dl(DL_CLEAR_RGB | GREEN);
  ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

  ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
  ft800_cmd_dl(BITMAP_SOURCE(0));
  ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
  ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
  ft800_cmd_dl(VERTEX2II(0,0,0,0));

  ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
  ft800_cmd_dl(BITMAP_SOURCE(3709));
  ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
  ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
  ft800_cmd_dl(VERTEX2II(96,0,0,0));

        ft800_cmd_execute();
  while(ft800_busy() == 1);

        ft800_cmd_dl(DL_DISPLAY);
        ft800_cmd_dl(CMD_SWAP);
  ft800_cmd_execute();

It displays second image just fine but the first image is a mixed 
combination of first and second JPG (here's photo - 
https://s24.postimg.org/v2ngd1cw5/FT800.jpg). I noticed that in your 
project you load JPGs to certain memory locations and if I change jpg4 
address from 18432 to another e.g 4000 - I get same mixed JPGs result. 
Is there any rule at which locations I should load different JPGs? I'm 
using project which you uploaded on 18.08.2016 23:40.

[Rudolph R. (rudolph)]

The problem is that cmd_loadimage() is unpacking the JPG to the given 
memory location, not storing the data you feed it.
With FT_RGB565 format the space necessary is 2 byte per pixel.

That is why my "Spielplatz" = playground example is using lines like 
these:
[code]
ft800_cmd_loadimage(74000 + (8192 * 0), FT_OPT_NODL, blitz, 1638);
...
ft800_cmd_loadimage(74000 + (8192 * 1), FT_OPT_NODL, figure, 2314);
...
ft800_cmd_loadimage(74000 + (8192 * 2), FT_OPT_NODL, frog, 1639);
...
ft800_cmd_loadimage(74000 + (8192 * 3), FT_OPT_NODL, map1, 2476);
[code]

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

Thanks Rudolph for your explanation, now I get it :)

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

Hi Rudolph,

have you managed to get PNG-8 files displayed right? With JPG there's no 
problem but when I load PNG-8 (using the same method as described 
before) on my FT810, I just get black screen with some artifacts. Here's 
my image - https://s29.postimg.org/fwdd8wcyv/7_8.png/.

[Rudolph R. (rudolph)]

I believe that I tried it before and that it worked but now I am not so 
sure anymore.
I just used paint to pixel the attached image and it's not working.

#define MEM_PIC1 0x00000900 /* start of 100x100 pixel test image, needs 20000 bytes of memory */

ft800_cmd_loadimage(MEM_PIC1, FT_OPT_NODL, pngpic, 1572);
ft800_cmd_execute();
while(ft800_busy() == 1);

ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_setbitmap(MEM_PIC1, FT_RGB565, 100, 100);
ft800_cmd_dl(VERTEX2F((LAYOUT_X2 + ((LAYOUT_W - 100) / 2)) *16, 380*16));
ft800_cmd_dl(DL_END);

The result is odd, the colors are completely wrong and there are two
stars next to each other with half the resolution.

Right now I have no idea what the problem is.

[Rudolph R. (rudolph)]

Okay, the picture itself was the problem.
The FT81x only supports bit-depth 8 for .png.
I knew that and setup the image to use 256 colors although the palette 
only had six entries.
Still, somehow this does not work and interestingly the first file I 
uploaded even automatically got converted thru µc.net. :-)

To increase the amount of colors in use I used a blur filter which also 
more than doubled the size of the binary.

I guess it highly depends on the images.
But so far I found .jpg to be far better in terms of binary size for 
small pictures.

[Rudolph R. (rudolph)]

Hmm, the picture above also does not work, at least not after whatever 
µc.net automatically did to it.

Attached is the modified project with the picture added to it.

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

Hi Rudolph, I've solved my PNG problem (they were Palleted not RGB) and 
with PNG files less than 4kB there is no problem. Did you try to display 
image which is >4kB using mediafifo and load whole image at once? I've 
got problem with that. Thanks for your help!

[Rudolph (Gast)]

I did not really check that so far, but now I did. :-)

First thing I noticed is that cmd_loadimage() needed to be improved to 
not send any daten in case FT_OPT_MEDIAFIFO is given.

Next I had to add a function to copy directly to the memory of the 
FT8xx.

And using it within my last test-example from above:

...
/* memory-map defines */
...
#define MEM_FIFO 0x000ef000 /* start of buffer for MEDIA-FIFO, total of 64k with the following list-buffer */
#define MEM_DL_STATIC 0x000ff000 /* start-address of the static part of the display-list, upper 4k of gfx-mem */
...

/*
    ft800_cmd_loadimage(MEM_PIC1, FT_OPT_NODL, pngpic, 3867);
    ft800_cmd_execute();
    while(ft800_busy() == 1);
*/
    
    ft800_cmd_mediafifo(MEM_FIFO, 0x10000); /* setup media-fifo */
    ft800_memWrite_flash_buffer(MEM_FIFO, pngpic, 3867); /* write data directly to memory */
    ft800_cmd_loadimage(MEM_PIC1, FT_OPT_NODL+FT_OPT_MEDIAFIFO, 0, 0); /* tell the co-pro to fetch the data from the media-fifo */
    ft800_cmd_execute();
    while(ft800_busy() == 1);

This is completely untested though.
It compiles fine but I do not have my display right now.

[Rudolph (Gast)]

Aaand I just noticed it is not exactly correct.
Since ft800_cmd_mediafifo() is a co-prozessor command it needs to be 
executed first to have an effekt.

This should work anyways but it may be wise to use

ft800_cmd_mediafifo(MEM_FIFO, 0x10000); /* setup media-fifo */
ft800_cmd_execute();
while(ft800_busy() == 1);

separately.

[Rudolph R. (rudolph)]

It's not working at all.
We see it hang after ft800_cmd_loadimage() with FT810 and FT813.
Upon further investigation ft800_cmd_mediafifo() does not seem to do 
anything at all apart from resetting the REG_MEDIAFIFO_READ and 
REG_MEDIAFIFO_WRITE registers to default null.

At least ft800_memWrite_flash_buffer() looks good, we read parts of the 
data back and found it correct.

[Rudolph R. (rudolph)]

I just implemented a cmd_loadimage() which sends the data in chunks of 
4000 bytes thru the command-fifo. Tested on my FT810 equipped HY50B with 
a 15kb 200x200 pixel .jpg.

Still no idea why CMD_MEDIAFIFO completely fails to work.

[Rudolph R. (rudolph)]

Oh yes, I had some help with finally getting it done, thx Stefan and 
Cass!

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

Hi Rudolph! Thanks again for your help and effort, just tested your new 
version of cmd_loadimage and it works flawlessly - tested with 800x480 
40kB PNG ;) If you solve problem with CMD_MEDIAFIFO please let know!

[Rudolph (Gast)]

This CMD_MEDIAFIFO, well...

Next up would be CMD_INFLATE and the manual does not even mention 
OPT_MEDIAFIFO for it.

And it's overdue to check out SVN and WIKI options here...

[Werner (Gast)]

Hallo Rudolph,
ich wollte mal deine neuste Version testen, bekomme aber immer einen 
Fehler (implicit declaration of function 'pgm_read_byte_far').
Vielleicht liegt es daran, daß ich mit AVR Studio 6.2 arbeite. Kannst du 
das Projekt mal für das 6.2 Studio reinstellen?
Danke, Werner

[Werner (Gast)]

Hallo Rudolph,
ich habe den Fehler gefunden, es lag am device, da ich einen ATMega64 
verwende.

[Rudolph R. (rudolph)]

Annother test-version, again for my 7" Riverdi with 800x480.
I reworked the middle section and replaced the clock with an 
oszilloscope like display utilising a line-strip with 64 points that is 
scrolling when the toggle-button on top is set to "on".

Below that is a bar-display with 16 bars that are 16 pixels wide.

The displays share the same static and limited data for this little 
demonstration.

[Rudolph R. (rudolph)]

Ich habe mal mit dem Wiki-Artikel dazu angefangen:
https://www.mikrocontroller.net/articles/FT8xx_Library

[Rudolph R. (rudolph)]

As it turned out, CMD_MEDIAFIFO works, if used correctly.

#define MEM_MEDIAFIFO_START 0x000f0000
#define MEM_MEDIAFIFO_LEN 0x000f000

ft800_cmd_mediafifo(MEM_MEDIAFIFO_START,MEM_MEDIAFIFO_LEN);/* init MEDIAFIFO */
ft800_cmd_execute();
while(ft800_busy()==1);
               
                ft800_memWrite_flash_buffer(MEM_MEDIAFIFO_START,pngpic,pngpic_size);
                ft800_memWrite32(REG_MEDIAFIFO_WRITE,pngpic_size);

                ft800_cmd_loadimage(MEM_PIC1,FT_OPT_NODL|FT_OPT_MEDIAFIFO,0,0);
                ft800_cmd_execute();
while(ft800_busy()==1);

First of all, REG_MEDIAFIFO_READ and REG_MEDIAFIFO_WRITE do not contain 
absolute addresses as it is documented in the programmers guide.
These hold offsets.

Then, these work exactly like REG_CMD_READ and REG_CMD_WRITE, so when 
you write data to the FIFO you need to write to REG_MEDIAFIFO_WRITE to 
tell the co-prozessor where your data ends.
And after the co-prozessor is done with the data it updates 
REG_MEDIAFIFO_READ.
Difference is that when writing to that FIFO you have to wrap-around the 
end of it in your own code, this is not done automatically.
With the command-FIFO you only have to take care of your pointer 
eventually.

After init of MEDIAFIFO both REG_MEDIAFIFO_READ and REG_MEDIAFIFO_WRITE 
are set to 0x0000.
And cmd_loadimage() reads that data from MEM_MEDIAFIFO_START + 
REG_MEDIAFIFO_READ to MEM_MEDIAFIFO_START + REG_MEDIAFIFO_WRITE.

This needs a bit of support-code to make things easier, but within a few 
boundaries it works as it is.

[Rafal D. (drzewko)]

Hallo all,
  I have problem with load jpg file but PNG working. When i try load jpg 
file i give empty ( white ) picture. Any ideas?

[Rudolph R. (rudolph)]

I am a bit out of words here.

- fotos of a monitor instead of screenshots while posting these lines 
would be the obvious thing to do
- manipulated code, no way to know what else is different other then the 
prefix
- no information at all about the system this is running on or the TFT
- no information at all about the images
- no information how the images are displayed
- some rather strange file-sizes

And you still expect someone to guess what is going on in your code?


Is that a FT811CB-HY50HD? Running on what?
Is that JPEG corect? "Regular baseline JPEG (JFIF)" - please attach
Is the geometry of the .jpeg really the same as the .png?

[Rafal D. (drzewko)]

Hallo Rudolph R.

   Yes, my mistake sorry of my photos.

   I use tft FT811CB-HY50HD with ATXmega128a3u. Your code but I changed 
to shorter names like ft800_cmd_dl -> FT_cmd_dl.

- "some rather strange file-sizes"  good but I made a typo kb <-> b. The 
given values are obviously in bytes.

- File is regular baseline JPEG.

  When i load small jpg 100x100px all work but with bigger file not 
work. How to load images with a size of over 4 kb?

Thank you

[Rudolph R. (rudolph)]

Rafal D. schrieb:
> Your code but I changed to shorter names like ft800_cmd_dl -> FT_cmd_dl.

While I have no objection against you doing that and I am also planning 
on changing the prefix to FT8_ myself, it's still not the same code and 
you have to modify it each time I put out a new version you deem worth 
upgrading to.


Okay, I just converted the two images to .hex and added them to my 
tft_data.c.

Then I modified my tft.c to load these:

#define MEM_PIC2 0x00006000 /* start of 100x100 pixel test image, needs 20000 bytes of memory */
#define MEM_PIC3 0x0000AF00 /* start of 200x200 pixel test image, needs 80000 bytes of memory */

...

ft800_cmd_loadimage(MEM_PIC2, FT_OPT_NODL, work100x100, work100x100_size);
ft800_cmd_execute();
while(ft800_busy() == 1);

ft800_cmd_loadimage(MEM_PIC3, FT_OPT_NODL, image2, image2_size);
ft800_cmd_execute();
while(ft800_busy() == 1);

And then I added them to be displayed:

ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_setbitmap(MEM_PIC1, FT_RGB565, 100, 100);
ft800_cmd_dl(VERTEX2F(20*16, 40*16));

ft800_cmd_setbitmap(MEM_PIC2, FT_RGB565, 100, 100);
ft800_cmd_dl(VERTEX2F(20*16, 160*16));

ft800_cmd_setbitmap(MEM_PIC3, FT_RGB565, 200, 200);
ft800_cmd_dl(VERTEX2F(140*16, 40*16));

ft800_cmd_dl(DL_END);

So maybe you are just not using the latest FT800_commands.c which would 
be 2.7 from 2017-02-19?

[Rafal D. (drzewko)]

I did not know how it happened but the header was described 2.7 
2017-02-19 and the old loadimage function.

I updated it and now work it. Thank you for pointing to the problem.

BTW. Have you met for FT811 to blink and freeze?

[Rudolph R. (rudolph)]

Rafal D. schrieb:
> I did not know how it happened but the header was described 2.7
> 2017-02-19 and the old loadimage function.

Yes, I know I need to move the project to some repository...

> BTW. Have you met for FT811 to blink and freeze?

Not for some time now. :-)
I may happen when you update the list faster than 60hz.



And I am in the process of updating the whole thing to use FT8_ all over 
it instead of FT800_ or FT_.

As a first preview I attached the reworked FT8.h.
I have to admit that it feels inconsistent though, all the CMD_, REG_ 
and macro defines do not have a FT8_ prefix.
Most general defines like the bitmap formats have the FT8_ prefix but 
not all.
I feel it should be FT8_DL_END as well and not just DL_END.
The CMD_ and REG_ defines should be fairly unique already.
Which leaves the macros, these also should have the FT8_ prefix.

Thoughts?

[Rudolph R. (rudolph)]

Okay, this is 3.0, again as complete project.

I just tested modifying the project myself, I changed all files in a 
different project, then renamed the FT800?.? files to FT8?.?, copied the 
new ones from the other project over them.

And at last I modified tft.c with replacing all ft800_ prefixes with 
FT8_ and most FT_ prefixes with FT8_.

I do not have my RVT70UQFNWC0x based TFT here right now but the project 
compiles fine without warnings.
And my other project works with my FT810 based HY50B.
I am going to test this tomorow morning.

[Rafal D. (drzewko)]

Add this procedures to custom fonts

void FT_cmd_setfont(uint32_t font, uint32_t ptr)
{
  FT_start_cmd(CMD_SETFONT);

  spi_transmit((uint8_t)(font));
  spi_transmit((uint8_t)(font >> 8));
  spi_transmit((uint8_t)(font >> 16));
  spi_transmit((uint8_t)(font >> 24));

  spi_transmit((uint8_t)(ptr));
  spi_transmit((uint8_t)(ptr >> 8));
  spi_transmit((uint8_t)(ptr >> 16));
  spi_transmit((uint8_t)(ptr >> 24));

  FT8_cs_clear();
  FT_inc_cmdoffset(8);
}

void FT_cmd_setfont2(uint32_t font, uint32_t ptr, uint32_t firstchar)
{
  FT_start_cmd(CMD_SETFONT2);

  spi_transmit((uint8_t)(font));
  spi_transmit((uint8_t)(font >> 8));
  spi_transmit((uint8_t)(font >> 16));
  spi_transmit((uint8_t)(font >> 24));

  spi_transmit((uint8_t)(ptr));
  spi_transmit((uint8_t)(ptr >> 8));
  spi_transmit((uint8_t)(ptr >> 16));
  spi_transmit((uint8_t)(ptr >> 24));

  spi_transmit((uint8_t)(firstchar));
  spi_transmit((uint8_t)(firstchar >> 8));
  spi_transmit((uint8_t)(firstchar >> 16));
  spi_transmit((uint8_t)(firstchar >> 24));

  FT8_cs_clear();
  FT_inc_cmdoffset(12);
}

[Rudolph (Gast)]

Done, thanks for pointing that out, I obviously did not try to add 
custom fonts so far. :-)

The attached archive just proved to be working.

[Rudolph R. (rudolph)]

Okay, annother update.
I went over all commands now and cross-checked them with both the 
datasheets as well as the programmers guide.

I found several commands that are undocumented but still somehow made it 
into the includes from FTDI from which I generated my FT8.h
I moved this to "#if 0" blocks.

FT8_cmd_interrupt() was using CMD_SNAPSHOT, copy-paste in action...

I removed several commands that have no arguments and therefore can be 
used with FT8_cmd_dl().
FT8_cmd_logo() -> FT8_cmd_dl(CMD_LOGO)

I added FT8_cmd_snapshot2() and FT8_cmd_setscratch()


There are still several commands "missing" like CMD_CRC but most of 
these return some "result" and the documentation from FTDI leaves it 
unclear how.

It looks like the values are written to the FIFO location just after the 
command which I find rather strange.

So you have to wait for the command to execute and then read (fifo_ptr - 
4) to fetch the result.

If that really is the case this hints that these commands are not meant 
to be used while building a display list.
So I should make them auto-execute like cmd_loadimage() already is, that 
makes it easier to save the pointer and read back the data.

[Rudolph R. (rudolph)]

This update implements some more of the "missing" commands, namely those 
that return values by writing to the command-fifo:

FT8_cmd_memcrc()
FT8_cmd_getptr()
FT8_cmd_regread()
FT8_cmd_getprops()

example of using FT8_cmd_memcrc:

 offset = FT8_cmd_memcrc(my_ptr_to_some_memory_region, 
some_amount_of_bytes);
 FT8_cmd_execute();
 crc32 = FT8_memRead32(FT8_RAM_CMD + offset);

FTDI handles that a bit different and I am not sure why:

uint16_t x = rd16(REG_CMD_WRITE);
cmd_crc(0, 1024, 0);
...
printf("%08x\n", rd32(RAM_CMD + x + 12));

I have no idea why they insist on passing "result" as an argument to the 
function when this only marks the offset the command-prozessor is 
writing to, it may even be okay to not transfer anything at all.

But then FTDI is taking a different aproach on some bits and pieces.
Like actually reading REG_CMD_WRITE for their 
Ft_Gpu_Hal_WaitCmdfifo_empty() function over and over again instead of 
relying on the value written to it by their Ft_Gpu_Hal_Updatecmdfifo() 
function.
And then after REG_CMD_WRITE and REG_CMD_READ found to be the same, 
REG_CMD_WRITE is read annother time to update the offset in their 
structure.

My offset to the command-fifo is a global var that is updated by all 
functions and relied upon.
This makes my FT8_busy() function somewhat more efficient as it only 
reads REG_CMD_READ and compares that to the value that is supposed to be 
held in REG_CMD_WRITE.


And I took it even a step further and had the functions return offsets, 
at least this is what return-values are good for.


This is untested so far as I have no use right now for these functions.

[x20011 (Gast)]

Hallo Rudolph R.
ich habe ein paar Verstandnisfragen zu dem Media Fifo....
Bei meiner eigenen Lib hängt sich cmd_loadimage nämlich bei der 
Verwendung des Media Fifos auch auf. :( (Achtung benutze eine andere 
Bibliothek, die vorgehsnweise sollte aber die gleiche sein.)

Zu meiner groben Vorgehensweise:

1. Ich ermittel die JPG Bildgröße in Byte:

do
        {
            status = fx_file_read(&g_file, imbuff, 1, &actual_bytes);
            file_size_in_byte++;
        }while(status != FX_END_OF_FILE);

2. Erstelle den MediaFifo

cmd_mediafifo(0x100000-(file_size_in_byte+4), file_size_in_byte+4); //Sets up a streaming media FIFO in RAM_G (+4Byte als Sicherheit falls ich noch ein paar byte für 4Byte alignment anhängen muss.) 
flush(); //Flush Coprocessor FIFO
copro_idle(); //Wartet bis Coprozessor alle Befehle abgearbeitet hat

3. Immer 1 Byte aus der JPG Datei lesen und auf addresse 
mem_mediafifo_start schreiben.

 do{
            status = fx_file_read(&g_file, &imbuff_test, 1, &actual_bytes);
            wr8(mem_mediafifo_start, imbuff_test); //Function to write 8 bits to intended address location
            mem_mediafifo_start++;
        }while(status != FX_END_OF_FILE);

4. Für 4Bit alignment sorgen

        while((mem_mediafifo_start % 4) != 0)
        {
            wr8(ram_g_address, 0x00);
            mem_mediafifo_start++;
        }

5. Neuen Offset für den Schreibzeiger des Media Fifo schreiben

wr32(REG_MEDIAFIFO_WRITE,mem_mediafifo_start);

6. Bild laden

cmd_loadimage(64*64*4, OPT_MEDIAFIFO | OPT_NODL); 
        flush();

Ab diesem Punkt hängt sich das Programm aus. (Prinzipiell funktioniert 
die Funktion loadimage ohne mediafifo ohne Probleme.)

Vielleicht habe ich auch einfach nur einen Denkfehler im Code ;)

[Rudolph (Gast)]

x20011 schrieb:
> 5. Neuen Offset für den Schreibzeiger des Media Fifo
> schreibenwr32(REG_MEDIAFIFO_WRITE,mem_mediafifo_start);

REG_MEDIAFIFO_WRITE muss auf das Ende der Daten zeigen, nicht auf den 
Anfang.
Der CoPro liest von REG_MEDIAFIFO_READ bis REG_MEDIAFIFO_WRITE und 
aktualisiert dann REG_MEDIAFIFO_READ.

Ich würde den MEDIAFIFO auch nicht mit der Größe des Bildes erstellen, 
sondern schon eher etwas üppiger.

[x20011 (Gast)]

Vielen Dank Rudolph R. für die Hilfe! Es funktioniert :)
Jetzt kann es weiter Richtung Videos von USB gehen...

[Bernd I. (Gast)]

Gibt es Jemanden, der noch wirklich weiß, was an Bytes' (konkret) dem 
FT800 per SPI zugeschoben werden muss, damit er macht, was er soll?
Ich wende mich völlig verzweifelt an Euch, da ich seit ca. 3 ganzen 
Tagen probiere und probiere. Mehr als Streifen oder ein blaues Display 
geht nicht.
Habe das Demo_board VM800C50 mit 5'Display.
Habe bei der Initialisierung das Beispiel im Programmer-Guide benutzt.
Ich möchte den FT800 mit meinem PIC (PIC18F4620) einfach nur ansteuern. 
Definiere dazu die SPI-Schnittstelle meines PIC und sende ...
EIGENTLICH ganz einfach, wenn Datenblätter nicht immer so kompliziert 
formuliert wären. Ganz am Ende liest man dann vielleicht, was man ganz 
am Anfang hätte zuerst tun müssen.
ALSO, mir nützen keine C-Codes oder gar Arduino-Software und und und.
Ich möchte (und muss) es verstehen, was per SPI konkret gesendet werden 
muss.
ACKTIVE z.B.sende ich 3 x Byte $00 (Dummy-Read) und für CLKEXT dann also 
$44, $00, $00
Dass der FT800 mich versteht (SPI ist also richtig) beweißt, dass ich 
per Taster den Register REG_PWM_DUTY beschreiben und somit auf- und 
abdimmen konnte.
D.h. Register beschreiben sollte alles richtig sein, also auch die 
Timing-Register (H-/VSYNC usw.)
Die DL-Liste (DL-RAM) verstehe ich einfach nicht? Muss man zuerst die 
DL-Adresse und dann die Display-Befehle oder NUR die Display-Befehle 
senden. Woher weiß FT800 dann, dass jetzt eine Display-Liste beginnt? 
Enden soll sie ja mit "DISPLAY". Und dann muss man in den REG_DLSWAP 
stets eine 2 schreiben??? Na ich habe jedenfalls alles durchprobiert. 
Jedes mal ein anderes Chaos-Bild. Einfach nur einen Farbbildschirm mit 
Rot oder Grün .. am Anfang mit CLEAR_COLOR_RGB würde mir genügen, um das 
UR-Prinzip zu verstehen. Das andere ist dann probieren und EIGENTLICH 
gut beschrieben.
HELP !!!

[Rudolph R. (rudolph)]

Boah, wie soll man den Chip erklären mit wenigen Worten aber ohne 
Programmcode und noch dazu besser als das Datenblatt/Handbuch? :-)

Programmierst Du den PIC18F4620 in C?
Wie wäre es denn, wenn wir meinen Code ein wenig erweitern damit das 
auch auf dem PIC läuft? Klingt für mich irgendwie schlauer als 
durchzukauen was man alles machen muss um das noch mal komplett neu 
aufzusetzen.

Es gibt von FTDI zum Beispiel aber auch das hier:
http://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm#FT81x_Simple_PIC_Application

Das ist für einen PIC18F46K22 und das Dokument dazu erklärt auch noch 
mal:
http://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/BRT-AN-006-FT81x-Simple-PIC-Example.pdf

Den Code dazu habe ich mir aber nur kurz angesehen.


Aber grundsätzlich, was haben wir da eigentlich.
Von aussen ist ein FT8xx erstmal ein großer Speicher der mit einer 23 
Bit Adresse bedient wird, das 24. Bit dient der Unterscheidung ob 
geschrieben oder gelesen werden soll.
Es gibt grundsätzlich vier Speicher-Bereiche:
RAM_G  graphics-memory  Objekt-Speicher: 256k / 1MB ab Adresse Null
RAM_DL: 8k ab 0x100000 für FT80x und 0x300000 für FT81x
RAM_CMD: 4k ab 0x108000 für FT80x und 0x308000 für FT81x
Register: ab 0x102400 für FT80x und 0x302000 für FT81x

RAM_G dürfte soweit klar sein.
RAM_DL ist wo die eigentlich Aktion passiert, da steht die Liste drin 
die abgearbeitet wird um die Anzeige zu erstellen, jeder Eintrag hat 32 
Bit.
Besonders an RAM_DL ist noch, das gibt es doppelt, es sind zwei Mal 8k 
im gleichen Speicher-Bereich und der Zugriff erfolgt immer auf die 
Version die nicht für die Anzeige benutzt wird.
RAM_CMD wird benutzt um dem Co-Prozessor eine Anweisungsliste zu geben 
nach der dieser RAM_DL füllen soll, das besondere dabei ist, das ist ein 
Ringpuffer mit automatischem Überlauf. Und der wird immer 32 Bit breit 
beschrieben, ein "Hallo" muss entsprechend als "Hall" + "o" + 0x000000 
geschrieben werden.
Die Register sind soweit auch klar.

Man schreibt also zuerst einen Satz Daten passend zum angeschlossenen 
TFT in die Register.
Und eine quasi leere Liste in RAM_DL damit der Chip sauber los laufen 
kann.
Danach kann man in Ruhe die Daten in RAM_G packen und den Touch-Screen 
initialisieren.

Dann benutzt man RAM_CMD um den Co-Prozessor zyklisch RAM_DL neu 
schreiben zu lassen.

FT8_cmd_dl(CMD_DLSTART);
 0x00FFFFFF
FT8_cmd_dl(DL_CLEAR_RGB | WHITE);
 0xffffff02
FT8_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
 0x07000026
FT8_cmd_text(50, 50, 28, 0, "Hallo");
 0x0cFFFFFF
 0x32003200
 0x00001c00
 "Hall"
 "o" 0x000000
FT8_cmd_dl(DL_DISPLAY);
 0x00000000
FT8_cmd_dl(CMD_SWAP);
 0x01FFFFFF

Und schliesslich muss man noch dem Co-Prozessor mitteilen, dass er das 
ausführen soll, dafür schreibt man den neuen Offset in REG_CMD_WRITE.
In dem Fall und wenn man bei Null gestartet ist wäre der Offset 36.

Edit, ich habe unterschlagen, dass man natürlich auch adressieren muss.
0x908000 wäre die Sequenz um dem FT81x mitzuteilen, dass an Adresse 
0x108000 geschrieben werden soll, ja, das sind nur drei Bytes.
Danach dann die Daten.
Also Chip-Select Low, 0x9080, 0x00FFFFFF, ... , Chip-Select High.
Lustig ist auch, dass die Adresse High-Byte -> Low-Byte gesendet wird, 
die ganzen Kommandos aber Low-Byte -> High-Byte.

Meine Library adressiert im Moment mit jedem Kommando neu.

[Bernd I. (Gast)]

Hallo Rudolph. Vielen Dank erstmal. Bin zwar.Zt. im Auto unterwegs. 
Alles gut - Meine liebe Frau fährt. Werde mir deine Ausführungen morgen 
tiefer verinnerlichen. Nur schon mal soviel: Ich arbeite mit Basic 
(Proton-Compiler). Und da sehe ich förmlich, was "hinten" raus kommt. 
Hab auch mit dem Osszi SPI Daten und Clock kontrolliert. Aber im 
Endeffekt, sagt mir das Datenblatt bzw. Der Programmierung Guide manche 
entscheidende Sachen nicht. Ich benötige stets eine TECHNISCHE 
Beschreibung und setze danach meinen Code um. Nicht umgekehrt: C-Code 
und dann sieh zu. Was hinten raus kommt, brauchst Du nicht zu wissen. 
Das kann ich nicht. OK, melde mich wieder. Schönes Wochenende bis dahin. 
Gruß Bernd.

[Rudolph R. (rudolph)]

BASIC? Schauder. :-)
Auf jeden Fall könnten da BRT_AN_006 und BRT_AN_007 hilfreich sein.
Das zielt zwar auch auf C ab, aber da werden auch Grundlagen erklärt und 
die ganzen Funktionen erläutert.
Der Code dazu ist auch noch eine Stufe stumpfer.

[Bernd I. (Gast)]

Meinen Dank, siehe Foto!!!
Woran hat's gelegen?
Dank Deiner "lustigen" Bemerkung, dass MSB-LSB bei Adressierung und 
umgekehrt bei Daten gesendet werden muss!!!
Wo steht das denn??? Eine gaaaaanz böse Falle. Danke für den 
Doku-Hinweis (BRT_AN..). Dort hat sich nur noch mal alles bestätigt, was 
mir bis dahin eigentlich schon alles klar war. Und wie schön 
beschrieben! Bit für Bit. Super. Deshalb meine aller erste Frage: Gibt 
es hier jemanden ...
Die liebe Mühe, mir den Chip-Aufbau zu erklären, hättest Du wirklich 
nicht machen brauchen. Das habe ich ja auch gelesen. Danke für Deine 
Zeit!
So, nun kannst Du das Lesen beenden, oder Dir die Zeit nehmen, weiter zu 
lesen:
BASIC? Schauder...
So wie Dein angefügtes Smilie, darfst Du auch meine Ausführungen 
keinesfalls irgentwie als böse werten!!!
Warum Schauder? Ich bin seit 17 Jahren professioneller Entwickler und 
Fertiger. Wir liefern im Jahr ca. 20.000 Platinen an Industrie- und 
Fachhandelskunden aus. Alle ca. 50 (Serien-)Projekte selbst entwickelt - 
mit BASIC.
Auch Du bist sicher meinen Platinen schon begegnet, steht nur nicht 
daruf, was drin ist. Gehe durch eine Glas-Schiebtür eines Super-Marktes 
mit der Aufschrift "Assa Abloy" und/oder "Besam" und denke an mich. 
Benutze die Parkplatzschranke eins bestimmten Herstellers... Womöglich 
heizt Du mit einer Junkers-/Buderus-Therme und nutzt das 
Netcom10/50/100. Ist von mir. Bosch-Thermotechnik hatte auch kein 
Problem mit BASIC.
Bei Europas größtem Lieferant für Fluchtwegartikel steckt in JEDEM 
elektronischen Artikel meine Platine. Schweizer Schlosstechnik wird mit 
einer intelligenten Motorschloss-Steuerung betätigt, die kann auch mit 
einem Fingerscanner direkt kommunizieren, können vernetzt werden und 
mehr.
Viele meiner Geräte können ein Update per RS485 erhalten mit meinem 
Bootloader...
Vernetzung ist ein riesen Thema, dazu gehört immer die Zentrale. Viele 
Einzelstücke habe ich schon gefertigt, aber dann zur Anzeige entweder 
mit diskreten LED oder Text-Display z.B. 2 x 20. Habe ein eigenes 
BUS-System entwickelt, was kurz vor der Serienreife für alle möglichen 
Anwendungen steht (Smart-Home). Als reine vernetzte Türüberwachungen hat 
es sich schon seit über 10 Jahren bewährt. So z.B. Flughafen Lübeck wird 
"durch mich" überwacht.
Für dieses BUS-System brauchte ich ein Grafik-Display und habe dafür das 
DEM480272TMH-PW-N (mit Touch) genutzt. Das hat "nur" ein 
8-Bit-Interface, also nur 256 Farben, was für diese technischen Zwecke 
völlig ausreicht und es läßt sich einfach ansteuern, aber ganz direkt: 
Also Steuerpin auf Befehl: X-Y-Koordinaten mitteilen, Steurpin auf 
Daten, RGB-Byte (je 3 Bit für R und G, 2 für B)anlegen, ein Takt und 
fertig ist der Pixel. Dass der FT8xx nun schon so viel Grafik enthält, 
ist natürlich super. Ich habe mir aber MIT BASIC eine Art Betriebssystem 
auf dem PIC geschaffen(inzwischen schon der 18F67K22, weil die Zentrale 
immer mehr kann) sowie 2 Fonts-Größen für alle Zeichen selbst erstellt, 
Push-Buttoms-Grafik ("Erhaben" und "Versenkt") und und und.
Die Zentrale kann alle BUS-Teilnehmer im vernetzten Zustand Updaten und 
natürlich auch sich selbst. Dazu hat sie einen USB-Stick integriert, den 
ich über FTI-Chip (VNC1L) anspreche. Und alles mit BASIC!!!
Abgesehen vom Preis des eben genannten Display (recht teuer, da mit 
integrierter Platine mit Controller drauf), ist die Größe 4,3' 
ausgereizt, auch wenn es diesen noch in 5' gibt, dann ist Schluss. Ich 
möchte aber große Paneels (10 - 12') bedienen oder auch noch kleinere 
für Glas-Paneels an der Wand, statt Licht-/Jalousieschalter usw. mit 
weiteren Info's drauf...
OK. Soll reichen. Also ich weiß genau, was mein PIC macht. Den Eindruck 
habe ich eben bei Euch "C-lern" nicht. Ich schreibe z.B. RCSTA = 
b10101010, TXSTA = xxx... Mein Compiler kennt ALLE Register des 
jeweiligen PIC's mit dem Namen, wie sie im Datenblatt stehen und hier 
übrigens auch so was von genial Bit für Bit jedes Registers beschrieben. 
SO kann man arbeiten!
Wenn ich Dir mal irgentwie helfen kann...
Liebe BASIC-Grüße, Bernd
Kommt noch ein Foto mit meiner Zentrale. Warum auch immer ich hier nicht 
2 gleichzeitig anhängen kann ?

[Bernd I. (Gast)]

Und hier noch das versprochene Foto.

[Rudolph R. (rudolph)]

Natürlich kann man auch in BASIC programmieren.
Das einzige was C besser macht als alle anderen Sprachen ist das man 
sagen kann, dass das weltweit der Standard schlechthin ist.

Muss jetzt >20 Jahre her sein das ich gefragt habe, welche richtige 
Sprache ich nach ein wenig BASIC, viel 6502 und etwas 68k Assembler 
anfangen sollte.
Und auch damals gab es zwar genug Auswahl, aber C war schon Standard.
Ob es was besseres gibt ist gar nicht die Frage, C ist überall, BASIC 
nicht. :-)
Das was mein Arbeitsgeber so macht findet sich im Auto und ich bin als 
Hardware-Entwickler einer Software-Entwicklungsabteilung zugeordnet.
Da kann ich zwar nicht so aus dem Nähkästchen plaudern da wir wenige bis 
keine eigenen Produkte haben auf denen unser Firmenname zu finden wäre, 
aber wir stecken da sehr breit und tief drin. :-)

Bernd I. schrieb:
> OK. Soll reichen. Also ich weiß genau, was mein PIC macht. Den Eindruck
> habe ich eben bei Euch "C-lern" nicht. Ich schreibe z.B. RCSTA =
> b10101010, TXSTA = xxx... Mein Compiler kennt ALLE Register des
> jeweiligen PIC's mit dem Namen, wie sie im Datenblatt stehen

Den Absatz verstehe ich nicht, bei so einfachen Sachen wie Zuweisungen 
gibt es doch gerade mal gar keinen Unterschied zwischen BASIC und C.

RCSTA = 0b10101010;
TXSTA = xxx;

Und natürlich kennt der Compiler die Register beim Namen.

Ich will auch wissen, was mein Controller so treibt. Daher der Code 
hier. :-)
Aber man muss irgendwann einsehen, dass man nicht alles selber machen 
und alles verstehen kann. Einen TCP/IP Stack oder ein FAT Dateisystem 
würde ich dann eher versuchen fertig zu benutzen.

Die FT8xx sind toll bezüglich der benötigten Resourcen.
Die 50 Bilder pro Sekunde in 800x480 die mein Test-Code 
überflüssigerweise gerade macht kosten weniger als 25% Rechenzeit auf 
einem 16 MHz AVR.

Bei 7" ist für mich allerdings leider auch gerade Schluss, da die FT81x 
"nur" bis 800x600 können und es mir noch nicht gelungen ist ein 10" TFT 
in der Auflösung zu finden das auch noch kapazitiv Touch bietet.
Alle aktuellen Displays haben bei der Größe eine höhere Auflösung.

Teuer ist der Spass auch noch, aber im Grunde genommen nur weil TFTs 
keine Commodity Items sind die überall eingebastelt werden.
Wenn man da auf vier-stellige Stückzahlen kommen könnte, das wäre 
zumindest ein Anfang. :-)
Aber einzeln, tja, dann kostet das halt 110 Euro.

[Bernd I. (Gast)]

https://www.schukat.com/schukat/schukat_cms_de.nsf/index/CMSDF15D356B046D53BC1256D550038A9E0?OpenDocument&wg=W6837&refDoc=CMSBCD816749EB85BF2C125707C004F3A35

Sieh mal dort nach. Hier gibt es wenigstens 10 Zoll mit 800x600 und mit 
Touch. Ich glaube aber nur resistiv. Für kapazitiv gehe bei Schukat auf 
Warengruppe W6835, hier das selbe aber OHNE Touch. Dann gehst Du zu RS 
und kaufst das kapazitive Touch separat dazu:

http://de.rs-online.com/web/c/displays-und-optoelektronik/displays-und-industriemonitore/touchscreen-sensoren/?sra=p

Aber was machen wir beide nun, wenn wir das 12-zöller z.B. mit 1024 x 
768 benutzen möchten/müssen ??? Hast Du schon eine Idee?

Du hast so Recht: C ist die Weltsprache. In meinen Anfangs PIC-Jahren 
war das schon bitter, sich mit niemanden austauschen zu können. Nun geht 
es ja. Und bei solchen Problemen, wie eben mit dem FT800, spielt die 
Sprache keine Rolle. Und alles wissen muss und kann ich natürlich auch 
nicht. Sonst würde ich ein Display selbst ansteuern - ohne FT800 (Oje 
!!! Fahrrad neu erfinden).

Text und ein "Springball" läuft schon. 1. Problem beim Rechteck 
BEGIN[RECTS].
Muss ich hier die Koordinaten für links-oben und rechts unten im Bereich 
480 - 272 oder das Ganze mal 16 oder sogar noch + 16384 (X/Y * 16 + 
16384) in VERTEX2F eingeben, um in den sichtbaren Bereich zu kommen? 
Also egal, was ich mache, es kommt stets nur ein kleiner Strich, sowohl 
bei x-y z.B. 100 x 100, als auch bei 1600 x 1600 als auch mal 16384 
beides. Nur stets mal hier und mal da. Habe X/Y auch wandern lassen von 
null bis 32300. Kleine Striche, meißt 3, wandern über den Schrim.
Sicher wieder etwas grundsätzliches falsch bei mir.

Und gelesen habe ich, dass der RamDL allein um 4 erhöht wird, wenn ich 
nach der Ram-Adresse dann Daten im vielfachen von 4 sende. Wenn ich 
"Hallo" sende im ganzen: low Enable, RamDl; VERTEXII,H; VERTEXII,o; ... 
usw, High Enable, erscheint nur das "H". Sende ich jeden Buchstaben mit 
selbst erhöhtem RamDL und komplett mit Startadresse, erscheint "Hallo".

Ist noch ein steiniger Weg...

[Rudolph R. (rudolph)]

Das klappt so leider nicht.
Erstmal bekommt man das Touch-Interface niemals so angebracht als wenn 
das so vom Band fallen würde, das verbessert auf gar keinen Fall die 
ohnehin nicht so tollen optischen Eigenschaften von dem TFT.
Und bei den TFTs von Riverdi habe ich jetzt eine Glas-Oberfläche.

Dann ist bei den freundlichen 169 Euro für das Touch-Interface eine 
Platine dabei die Anfang 2011 designed wurde und einen nur mit sehr viel 
Glück zu den FT8xx kompatiblen Touch-Chip enthält.
Mich würde nicht mal wundern, wenn die Dinger seit Jahren bei RS im 
Regal liegen, wer braucht sowas auch und vor allem zu dem Preis?

Über 800x600 geht im Moment gar nicht mit den FT8xx.
Sicher geht das anders, das interessiert mich hier in dem Kontext aber 
nicht. :-)

FTDI habe ich die Frage nach größeren Displays auch schon gestellt, da 
haben die im Moment auch keine Lösung für.
Ich finde ja, es wird langsam Zeit für die FT82x. :-)

Von Riverdi habe ich die Andeutung, dass da eventuell bis Ende des 
Jahres was in 10" kommen könnte.
Für konkretere Ansagen bin ich als Kunde einfach nicht ernst zu nehmen.

Oh, dabei fällt mir ein, die könnten die TFTs auch optisch deutlich 
verbessert liefern durch den Einsatz einer zusätzlichen Folie, die 
Mindest-Menge die mir dafür genannt wurde sehe ich nicht mal in 10 
Jahren als Bedarf...


Rechtecke habe ich im Beispiel-Programm mit 1 Pixel Auflösung angegeben 
für VERTEX2F, per Default ist die Auflösung aber 1/16 Pixel.
Links-Oben / Rechts-Unten ist dabei richtig.

Das sollte dann so aussehen:

FT8_cmd_dl(LINE_WIDTH(1*16));
FT8_cmd_dl(DL_COLOR_RGB | RED);
FT8_cmd_dl(DL_BEGIN | FT8_RECTS);
FT8_cmd_dl(VERTEX2F(0,0));
FT8_cmd_dl(VERTEX2F(100*16,50*16));
FT8_cmd_dl(DL_END);

Wobei in dem Context mit BASIC jetzt ganz praktisch ist, dass 
FT8_cmd_dl() nichts weiter macht als die vier Byte an RAM_CMD+Offset zu 
schreiben die sich aus den Argumenten ergeben.

Okay, das ist mit den Macros nicht unbedingt sofort durchschaubar, das 
macht im Handbuch irgendwie mehr Sinn. :-)

LINE_WIDTH(width) ((14UL<<24)|(((width)&4095UL)<<0))
VERTEX2F(x,y) ((1UL<<30)|(((x)&32767UL)<<15)|(((y)&32767UL)<<0))

Die Konstanten sind da einfach:
DL_COLOR_RGB  0x04000000UL
RED      0xff0000UL
DL_BEGIN  0x1F000000UL
FT8_RECTS                9UL
DL_END    0x21000000UL

Hmm, da gäbe es noch einiges Optmierungs-Potential. :-)
Das ganze Geschubse mit 32 Bit Werten ist dann sicher eher nicht so 
effizient auf einem 8-Bit Controller.

Mein Beispiel-Programm benötigt inzwischen auch schon knapp 4ms von den 
10ms Umlauf insgesamt.
Okay, fairerweise nur die Hälfte davon weil nur jeder 2. Aufruf ein Bild 
baut und sich das ohne Probleme auf zwei Hälften verteilen lässt, damit 
sind das dann so 20% Rechenzeit für die 50 Bilder pro Sekunde.

Bernd I. schrieb:
> Und gelesen habe ich, dass der RamDL allein um 4 erhöht wird, wenn ich
> nach der Ram-Adresse dann Daten im vielfachen von 4 sende. Wenn ich
> "Hallo" sende im ganzen: low Enable, RamDl; VERTEXII,H; VERTEXII,o; ...
> usw, High Enable, erscheint nur das "H". Sende ich jeden Buchstaben mit
> selbst erhöhtem RamDL und komplett mit Startadresse, erscheint "Hallo".

Ich schreibe gar nicht direkt in RAM_DL, das überlasse ich komplett dem 
Co-Prozessor weil man auch nur über diesen die eingebauten Objekte wie 
Scroller und Buttons bekommt.

Aber auf Seite 14 im FT81X_Series_Programmer_Guide.pdf  ist eine Sequenz 
zu sehen bei der direkt in RAM_DL ein Text geschrieben wird.
Geschickterweise braucht das da vier Bytes pro Zeichen per VERTEX2II.
Ich kann nur hoffen, dass das per CMD_TEXT platzsparender in der RAM_DL 
landet. :-)
Auf jeden Fall benutze ich so oder so VERTEX2II nicht mehr, die 
Beschränkung auf 0...511 für X und Y ist einfach zu lästig, VERTEX2F 
kommt bei der Default-Auflösung von 1/16 Pixel auf -1024...1023.

[Rudolph R. (rudolph)]

Some time ago I promised an example for Arduino.
However I am not really using Arduino and did not have new request on 
building something with an Arduino board.

Last week a co-worker came up to with a NodeMCU Devkit board which has a 
ESP8266 12E module on it.
I remembered that there is an Arduino core for it so I started playing 
with the board to help my co-worker getting started.
While I currently have no use for WLAN I figured it would be nice to use 
my 7" Riverdi with the ESP8266.

So here it is as example project.
I have not tried to open this with the Arduino IDE, I am using Atmel 
Studio with a plugin for Arduino, it should be fine though.

There are close to no changes, I only had to rename the .c files to .cpp 
and a add a few lines to FT8_config.h.

[Rudolph R. (rudolph)]

And a new display to play with, well, sort of, I bought a FT811CB-HY50HD 
from HAOYU which is practically the same than the FT810CB-HY50HD which I 
had for some time now - but it has capacitve touch instead of 
resisitive.

I ordered it here two days ago:
http://www.watterott.com/de/5-800x480-Display-mit-kapazitivem-Touchscreen-FT811CB-HY50HD

I would not had ordered it in China directly as I am rather annoyed by 
how long it takes.

Compared to the RVT70UQFNWC0x the FT811CB-HY50HD has several advantages 
for me.
The first and most obvious is the price.
The FT811CB-HY50HD costs less than a third of what I pay for the 
RVT70UQFNWC0x when buying a single unit.
And secondly I am not even sure if I could buy a RVT70UQFNWC0x 
privately.
Yes, I know, apples and oranges 7" TFT with good quality against 5" with 
okay quality, the RVT70UQFNWC0x does not just cost more, you get more!

Third is something I did not expect to be a problem: current 
consumption.
The RVT70UQFNWC0x draws around 450...540mA from its 5V supply for the 
backlight and annother 70...130mA from its 3,3V supply for the logic.
The FT811CB-HY50HD however draws around 250mA from a single 5V supply.
And in comparision I found a 9" 800x480 TFT which is specified to draw 
1200...1600mA from its 5V supply for the backlight.
I am pretty sure this comparision is not fair either as it may be very 
well the case that the three TFTs offer different levels of brightness.

Regarding features I have to admit that the FT811CB-HY50HD wins over the 
RVT70UQFNWC0x.
- single 5V supply with 3.3V regulator on board
- 5V tolerant input buffer on board
- 12pin FPC sockel instead of 20 pin and comes with a FPC cable
- additional 10pin 2,54mm header
- crystal for the FT811 populated

Yes, the RVT70UQFNWC0x has more pins because it supports QSPI but I am 
not using that.
And yes the RVT70UQFNWC0x has a FT813 which can display more colors but 
this is hardly a limitation for HMI applications.

[Bernd I. (Gast)]

Danke für den Link zu Watterott. Dort war ich auch des Öfteren wegen 
anderer Dinge, ist aber schon ne Weile her. Bei meinen Recherchen der 
letzten 4 Wochen hatte ich die schon vergessen. Interessant!!!

Bin die letzten Tage nicht dazu gekommen, weiter am FT800 zu arbeiten - 
liegt so viel anders herum.
Setze mich aber schon mit dem Gedanken auseinander, Dir ein Geschäft 
vorzuschlagen. Dann aber nicht über dieses Portal. Hast Du 
grundsätzliches Interesse?

Ein schönes lange Wochenende, Gruß Bernd

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Setze mich aber schon mit dem Gedanken auseinander, Dir ein Geschäft
> vorzuschlagen. Dann aber nicht über dieses Portal. Hast Du
> grundsätzliches Interesse?

Jain. :-)
Da ich nicht selbständig angestellt bin müsste ich sowas ja mit meinem 
Arbeitgeber abstimmen und mich zudem auch noch mit dem Finanzamt 
rumärgern.
Dazu habe ich eh schon zu viele "Projekte" offen die nicht vorwärts 
kommen, wie das so ist. :-)
Also ich nehme grundsätzlich kein Geld für irgendwas, nicht mal die "5 
Euro für die Kaffeekasse" die mir schon öfter angeboten wurden.
Und Langeweile habe ich ganz sicher nicht.

Die Geschichte mit dem EPS8266 und dem FT811CB ist auch schon wieder so 
eine Sache die nicht für mich ist. :-)

Also ich helfe ja gerne, das darf nur nicht in Arbeit ausarten. ;-)

[Rudolph R. (rudolph)]

Just to be fair I should also mention this:

https://riverdi.com/product/rvt50uqfnwc0x/
http://www.tme.eu/de/details/rvt50uqfnwc00/intelligente-displays/riverdi/

I do not have one of these and no connection whatsoever to Riverdi.
But in a project for my company I would always choose this one or the 
RVT70UQFNWC0x instead of the FT811CB-HY50HD just for the look and feel.

The current consumption of the RVT50UQFNWC0x is higher than what the 
FT811CB-HY50HD needs but close enough to be considered similar.


Unfortunately that seem to be all options on the market for FT811/FT813 
based TFTs.

[Bernd I. (Gast)]

Hallo Rudolph,
mir ist schon klar, dass Du keine lange Weile hast. Deshalb ja meine 
"Kopfschmerzen", immer nur einseitig zu Fragen. Wie könnte ich Dir 
helfen?
Na gut, dann frage ich noch mal.
Bin so weit ganz gut vorangekommen und benötige deshalb doch wesentlich 
weniger Hilfe, als gedacht. Habe eigentlich (fast) alles, was ich 
benötige: Push-Buttoms (durch ineinander verschachtelte RECTS), Text, 
ein paar Linien, mehr brauche ich nicht. Alles ohne Co-Prozessor (Extra 
Thema, vielleicht später).
Nun ist der Touch dran. Warum gibt es hier gefühlte 27 verschiedene 
Register????????????
Habe mir mal die Register REG_TOUCH_DIRECT_XY  REG_TOUCH_DIRECT_Z1Z2  
REG_TOUCH_SCREEN_XY ausgelesen. Kann hier zwar die Koordinaten jeweils 
erkennen, ABER alle diese Register spucken die Koordinaten NUR aus, so 
lange ich mit dem Finger auf dem Screen bin. 100ms später auslesen, dann 
kommen schon die Reset-Werte. Zwar kann ich durch Interrupt-Definitionen 
einen Touch melden, aber ehe mein Prozessor eventuell dazu kommt, den 
Register auszulesen, kann der Touch schon wieder vorbei sein (je nach 
Situation). Es muss doch irgentwo einen Register geben, der sich die 
Koordinaten merkt (und mit jedem Touch überschreibt)... Oder?
Wozu sind die 5 Register REG_TOUCH_TRANSFORM_A - F und die ganze 
Geschichte mit den TAG-Registern (TAG  Touch_TAG  nur X/Y / TAG_XY ... 
??????) begreife ich auch nicht so richtig. Offenbar kann man mit deren 
Hilfe Koordinaten definieren, die berührt werden sollen und mir dann 
irgentwo als "berührt" angezeigt werden. Da mir das aber alles so extrem 
kompliziert erscheint, würden mir die Screen-Koordinaten genügen, wenn 
sie dann gespeichert bleiben!!! Den Rest (Vergleichen usw.) kann ich 
selbst, ohne erst einen halb-jährigen Programmier-Lehrgang zu 
absolvieren... :-)

[Rudolph (Gast)]

Meine Software pollt den Touch, dafür lese ich nur immer wieder 
REG_TOUCH_TAG aus, mehr nicht.
Das Register wird bei jedem Bild-Aufbau aktualisiert, also bei jedem 
internen Bild-Aufbau auf dem TFT.

Für Live-Werte bei einem Slider benutze ich noch REG_TRACKER.

Meine Software sieht im Moment so aus, dass meine Funktion zur Anzeige 
alle 10ms aufgerufen wird.
Beim ersten Aufruf wird REG_TOUCH_TAG ausgewertet und bei Events 
entsprechend reagiert, beim zweiten Aufruf wird die Display-Liste über 
den Co-Prozessor gebaut.
Ich gönne mir also 50 Abfragen pro Sekunde und 50 Bilder pro Sekunde.

Man kann das auch per Interrupt machen irgendwie, das habe ich nur nicht 
mal ausprobiert, weil das Polling zum einen quasi keine Rechnenzeit 
kostet, zum anderen per Default mit dem Bildaufbau synchron läuft.

Ich benutze den Touch auch nur im Single-Point Modus, die fünf Punkte 
die mit kapzitiv Touch möglich sind habe ich noch nicht gebraucht.


In REG_TOUCH_TAG steht direkt drin welches Objekt oder welche 
Objekt-Gruppe als getouched erkannt wurde.
Man weist einfach einen Wert allem zu was man zusammen erkannt haben 
will.

TAG(0) // ignorieren
bild1
bild2
text1
TAG(10)
rechteck1
rechteck2
punkt
text2
TAG(20)
bild3
TAG(0)
text3

foo = REG_TOUCH_TAG
if(foo == 10)
{
 rechteck1.farbe = rot
 text2 = "an"
}
else
{
 rechteck1.farbe = grün
 text2 = "aus"
}


Naja, so in etwa, was spontaner Pseude-Code so hergibt. :-)

[Rudolph (Gast)]

Bernd I. schrieb:
> Wozu sind die 5 Register REG_TOUCH_TRANSFORM_A - F

Ach so, ja, das sind die Kalibrier-Werte.
Die Werte ermittel ich im Moment für jedes Display nur einmal mit der 
Kalibrier-Funktion und schreibe die nach erfolgreichem init in die 
Register.

[Bernd I. (Gast)]

Im REG_TOUCH_MODE kann man den Sampling-Modus festlegen. Da dachte ich 
schon: Ich hab's!!! Habe den Wert auf 01 (Single mode) gesetzt. Nun 
sollten doch eigentlich die Koordinaten EINMAL bestimmt werden ("01: 
Single mode. Cause one single sample to occur.") und somit erhalten 
bleiben. Leider auch nicht.
So lange ich gezielt auf eine Eingabe warte, ist das ständige Pollen 
kein Problem. Aber oft laufen beim BUS-System Zeit-relevante Abläufe ab, 
die ich nicht unterbrechen kann, was teilweise schon mal bis zu 250ms 
dauert. Dann ist ein kurzer Touch weg!

Und woher weiß ich hinterher, welches der im REG_TOUCH_TAG 
zusammengefassten Objekte (Push-Bottom 1 oder 2 oder ...) berührt wurde?
Dieses Zusammenfassen in diesem Register habe ich auch nicht verstanden. 
Dieser Register hat 255 Werte (8 Bit), wenn man mal die Null als "Aus" 
ausklammert. Wenn ich da eine "15" z.B. reinschreibe, was passiert dann?

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> So lange ich gezielt auf eine Eingabe warte, ist das ständige Pollen
> kein Problem. Aber oft laufen beim BUS-System Zeit-relevante Abläufe ab,
> die ich nicht unterbrechen kann, was teilweise schon mal bis zu 250ms
> dauert. Dann ist ein kurzer Touch weg!

Äh, ja, warum das so ist und ob das wirklich so sein muss ist von aussen 
nicht zu bewerten und wenn ich das in BASIC sehen würde, wäre das 
vermutlich nicht hilfreich. :-)

Einen richtigen Taster kann man so dann auch nicht einlesen.
Ebenso wäre ein Interrupt da wenig hilfreich, der dauert nämlich länger 
als das bloße Pollen.

Auf jeden Fall wäre speichern von Ereignissen auch nicht unbedingt 
hilfreich, schliesslich ist das wie bei einem Taster nicht nur ein 
Event, sondern zwei, drücken und los lassen.

> Und woher weiß ich hinterher, welches der im REG_TOUCH_TAG
> zusammengefassten Objekte (Push-Bottom 1 oder 2 oder ...) berührt wurde?

Es werden unterschiedliche Tag-Werte geliefert.

> Dieses Zusammenfassen in diesem Register habe ich auch nicht verstanden.
> Dieser Register hat 255 Werte (8 Bit), wenn man mal die Null als "Aus"
> ausklammert. Wenn ich da eine "15" z.B. reinschreibe, was passiert dann?

Hoffentlich nichts da dort nicht rein geschrieben wird. :-)

Beim Bau den Anzeigen Liste weist man die Werte zu, siehe oben.

TAG(0) - mache nix
strich
text
TAG(14)
Push-Button 1
TAG(15)
Push-Button 2
TAG(0)
noch was

Man kann jedem Objekt einen TAG-Wert zuweisen und wenn ein Touch-Event 
erkannt wird, steht diese Nummer dann in REG_TOUCH_Tag drin.

Mit zusammen fassen meinte ich, dass man nicht nur einzelne Objekte, 
sondern auch ganze Gruppen einen TAG-Wert zuweisen kann.

TAG(0) - mache nix
strich
text1
TAG(14)
kleines rechteck
grosses rechteck
Push-Button 1
text2
TAG(15)
Push-Button 2
TAG(0)
noch was

Also wenn man "kleines rechteck", "grosses rechteck", "Push-Button 1" 
oder "text2" berührt, dann steht in REG_TOUCH_TAG eine 14 drin.

Von daher ist die Verwendung von TAG(0) auch wichtig, damit wird 
verhindert, dass nach einem Button nicht etwa auch der ganze Rest des 
Displays als zu dem Button gehörig erkannt wird.

[Bernd I. (Gast)]

OK, dass mit dem Speichern eines Touch war wohl Wunschdenken. Bei meinem 
separaten Touchcontroller AR1021 ist das ja auch nicht so. Ich weiß, was 
ich zu tun habe. Habe zwischen den Zeitrelevanten Routinen doch noch 
immer wieder Zeit zum Pollen ...
Das mit den TAG-Registern werde ich mir noch mal genauer ansehen...
Bleibt aber dennoch die Frage, was macht der REG_TOUCH_MODE ? Habe ich 
das falsch verstanden??? Sollte der nicht im Single-Modus nur einmal bei 
Berührung den Wert lesen?

Ich habe nun noch ein (vorläufig) letztes Problem:
Wenn ich eine Display-List z.B. mit BEGIN_RECTS schreibe, mit END_LIST, 
DISPLAY und REG_DLSWAP.. beende - soweit alles gut. Beginne ich eine 
neue, also den RAMDL von vorn beginne z.B. BEGIN_BITMAP werden die ASCI 
als senkrechte Striche gesetzt (Bildschirm-Hintergrundfarbe ist 
plötzlich auch anders). Hat das was mit dem REG_DLSWAP zu tun? Hier 
schreibe ich stets eine "2" als Zeichen für den FT800, dass der RAM neu 
beschrieben wurde. Kommt hier jetzt eine "1" (im wechsel mit "2" nach 
jeder neuen List)?
Da werde ich morgen noch ein bisschen testen, falls ich nicht weiter 
komme ... :-)

[Rudolph (Gast)]

Bernd I. schrieb:
> Bleibt aber dennoch die Frage, was macht der REG_TOUCH_MODE ? Habe ich
> das falsch verstanden??? Sollte der nicht im Single-Modus nur einmal bei
> Berührung den Wert lesen?

Der liest einmal den Wert sobald man in REG_TOUCH_MODE eine '1' rein 
schreibt.
Wofür auch immer das gut ist, vielleicht EMV, ich lasse das einfach auf 
Default stehen.

Bernd I. schrieb:
> Ich habe nun noch ein (vorläufig) letztes Problem:

Äh, ja, das mache ich ja so gar nicht und vor allem nicht so direkt.
Ich wurde von der Beschreibung zu REG_DLSWAP allerdings vermuten, dass 
man da immer nur eine '2' rein schreiben sollte, auf gar keinen Fall 
abwechselnd mit '1'.

"Bit 1 - 0: These bits can be set by the host to validate the display 
list buffer
. The graphics engine will determine when to render the screen , 
depending
on what values of these bits are set:
01: Graphics engine will render the screen immediately after current 
line is scanned
out. It may cause tearing effect.
10: Graphics engine will render the screen immediately after current 
frame is
scanned out. This is recommended in most of cases.
00: Do not write this value into this register.
11: Do not write this value into this register"

Also "2" ist der Wechsel nach dem Frame, "1" nach der aktuellen Zeile.

Keine Ahnung, wofür es da überhaupt eine Option gibt, das einzig 
sinnvolle ist ja der Wechsel nach dem Frame.

[Bernd I. (Gast)]

Hallo Rudolf,
im Prinzip bin ich mit der ganze Probiererei soweit, dass ich mit dem 
eigentlichen Projekt beginnen kann.
Da gibt es zwar 2-3 Phänomene, die ich zwar austricksen kann, aber 
vielleicht geben sie ja auch Einsicht in irgendwelche prinzipiellen 
Fehler.

Da wäre Phänomen-Nr.1, wie schon am 3.5. geschildert. Die senkrechten 
Strich von Oben bis Unten, dort wo eigentlich Buchstaben stehen. Das 
selbe hatte ich auch schon mit RECTS. Ein RECT definieren, RamDL 
abschließen, einen neuen beginnen, RECTS setzen - das RECT ist zwar 
breit, wie definiert, aber geht von Oben bis Unten des Bildschirms, auch 
wenn ich die Höhe nur auf 2 Pixel z.B. definiere.
Hingegen 2 - 3 ... RECTS innerhalb einer List setzen - geht!

2. Phänomen:
Ich konstruiere Push-Buttoms (PB), indem ich mehrere RECTS mit je einen 
Pixel kleiner und je sich ändernder Farbe ineinander setze. Siehe Bild 
"PB_Erhaben". Bei Touch hier mal zur Demo, "versenken" sich alle (später 
natürlich nur der berührte) PB, indem die Farbeveränderung an den 
Rändern getauscht wird ("PB_Senk").
Ebenso kannst Du sehen, dass ich den Hintergrund nicht mit 
CLEAR_COLOR_RGB einfach nur z.B. auf Grün setze, sondern hier ebenso ein 
PB setze mit der Größe 480 x 272 und damit diesen effektvollen 
Bildschirmrand habe.
Nun das Problem: Es wird eine Schleife durchlaufen, um diese 10 RECTS 
ineinander zu setzen. Sobald ich diese Schleife auf 11 (im Bild z.B. 12 
mal "PB_12mal") setze, um den Rand des PB noch breiter zu machen, oder 
sogar auf 16 Durchläufe erhöhe, sieht es so aus ("PB_16mal").
Genau 10 mal macht er alle richtig, was passiert ab dem 11. mal??? Es 
gibt definitiv keine falsche Koordinaten-Berechnung ab dem 11. mal, habe 
auch um ganz sicher zu gehen, alles schon mit Konstanten getestet. 
Dachte auch, ob der RamDL wohl voll ist. Quatsch, zumal dieser Effekt 
auch dann auftritt, wenn ich nur einen einzigen PB mit 12 Rändern setze 
!! Was soll das???

3. Phänomen:
Habe ich jetzt nicht noch mal fotografiert. Der erste von den hier im 
Beispiel 14 PB's sieht grundsätzlich anders aus, als alle übrigen. Der 
hat keinen Schatten. Um das aus zu tricksen, setze ich diesen ersten 
außerhalb des sichtbaren Bereichs. Aber ist doch unlogisch!!!

In dem Zusammenhang würde mich auch interessieren, ob man diesen 
automatischen Schatten "abschalten" kann. Ich staune auch nur, wie gut 
eigentlich die PB's aussehen. Eigentlich müssten die Schatten eines 
jeden "inneren RECTS sich widerspiegeln. Statt dessen ist der saubere 
Farbverlauf, wie definiert. Wo hingeben das ERSTE RECT eines jeden PB 
(das Äußere also) einen Schattenrand hat. Im Bild "PB_Erhaben" gut zu 
sehen: Der hellblaue Rand um den "meinen" schwarz-grau verlaufenden Rand 
stammt nicht von mir. Ist wohl der automatische Schatten.

Sind alles "Probleme" mit denen ich leben kann, aber ... schön ist 
anders.

Guten Abend!!!

[Rudolph (Gast)]

Das lässt sich so etwas schwer nachvollziehen, so ohne Quellcode und 
sowieso als Problem das nichts mit dem hier veröffentlichten Code zu tun 
hat. :-)

Du lässt 10...16 Rechtecke aufeinander malen für einen einzelnen Button?
Sowas fällt ja quasi schon unter Missbrauch der Engine. :-)
Mal schauen, 14 Buttons, 140 Rechtecke, 280 VERTEX2 -> 1120 Bytes nur 
für die Rechtecke, dazu noch die Farben.
Und das nur, weil die vorhandenen Buttons optisch nicht gefallen?

Nimm doch einfach zwei Bilder dafür.
Mit VERTEX2II kann man die Cell-Nummer angeben, dazu hängt man Bilder 
mit gleicher Größte direkt hintereinander in den Speicher, die Nummer 
gibt dann an, welches Bild man will.

cmd_dl(BITMAP_SOURCE(74000));
cmd_dl(BITMAP_LAYOUT(FT_RGB565,64*2,64));
cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,64,64));

cmd_dl(DL_BEGIN | FT_BITMAPS);
cmd_dl(VERTEX2II(10+64*0,10,0,0));
cmd_dl(VERTEX2II(10+64*1,10,0,1));
cmd_dl(VERTEX2II(10+64*2,10,0,0));
cmd_dl(VERTEX2II(10+64*3,10,0,0));
cmd_dl(DL_END);

-> 14 Buttons = 14x VERTEX2II -> 56 Bytes

Übrigens, der FTDI EVE Screen Editor ist da richtig praktisch zum 
Rumspielen, nicht zu verwechseln mit dem Screen Designer.

Der zeigt sogar die aus den Kommandos resultierenden Rohwerte an.

[Bernd I. (Gast)]

Gut gerechnet "Löwe" :-) UND??? Was stören mich 1100 Bytes? Und das 
"NUR" weil ich mir nicht von einer (Grafik-) Maschine aufdiktieren 
lasse, wie mein Design auszusehen hat.
Der Quellcode ist soooo was von einfach und kostet dem PIC vielleicht 
lumpige 50 Bytes, wenn man mal die einmalig erstellten Unterroutinen 
ausklammert.


RamDL = $00900000                   //Start RamDL bei Hx100000 | 
Hx800000
Gruen = 255 : Rot = 100 : Blau = 60   //Hintergrundfarbe (Grün)
DDis0 = Blau
DDis1 = Gruen
DDis2 = Rot                       //definierte Var. Untermenü übergeben
Befehl = bCOLOR_RGB
    GoSub Bef32                   //SPI senden

Befehl = bBEGIN : DDis0 = RECTS     //Start Treiber Rechteck
GoSub Ram4                         // Untermeü: RamDL = RamDL + 4
GoSub Bef32                        //SPI senden

RECTS mit 480 x 272 nach selben Schema setzen, wie folgt beschrieben:

Befehl = bLINE_WIDTH
DatW = 80                        // Linienstärke (5*16) für die 14 PB's
DDis0 = DatW.Byte0
DDis1 = DatW.Byte1
GoSub Ram4                         // Untermeü: RamDL = RamDL + 4
GoSub Bef32                        //SPI senden

Befehl = bCOLOR_RGB : Rot = 0 : Gruen = 0 : Blau = 0   // Farbe schwarz
DDis0 = Blau
DDis1 = Gruen
DDis2 = Rot
GoSub Ram4                         // Untermeü: RamDL = RamDL + 4
GoSub Bef32                        //SPI senden

'===== Ende Vorgeplänkel =======
'===== Push-Button setzen ======
Hoehe = 50 : Breite = 50                // Höhe und Breite der PB 
(50x50)
Zeile = 2047 - 200 : Spalte = 2047 - 200    'Koordinaten der RECTS
    GoSub VersPB
// Das erste RECTS ausserhalb des sichtbaren Bereichs (wegen Phönomen1)

Zeile = 2047 + 30 : Spalte = 2047 + 30   // Koord. der RECTS Oben-Links
    GoSub VersPB                         //1.versenkten PB setzen
Spalte = 2047 + 90
    GoSub VersPB                         //2.versenkten PB setzen
Spalte = 2047 + 150
    GoSub VersPB                         //3. usw..
....
// Nächste Zeile, die 14 PB von vorn:
Zeile = 2047 + 100 : Spalte = 2047 + 30
    GoSub VersPB                         //1.versenkten PB setzen
Spalte = 2047 + 90
    GoSub VersPB                         //2.versenkten PB setzen
Spalte = 2047 + 150
    GoSub VersPB                         //3. usw..

    GoSub EndList                   //RamDL + 4, END Senden

// es folgt die Beschriftung der PB, ist aber unwichtig, da der Effekt 
auch ohne auftritt:
Farbe auf weiß, BEGINN[BITMAPS] ...

    GoSub EndList                   'RamDL + 4, END Senden
Befehl = bDISPLAY
    GoSub Ram4 : GoSub Bef32
Regi = REG_DLSWAP : DatW = 2 : GoSub Reg8       'Reg_DLSWAP 2 setzen

==== Warten auf Touch === .... Reaktion, zurück zu "Schleife"


=== DAS Unterprogramm "VersPB": ====

VersPB:                               //Sprungmarke
For HpB = 0 To 9           // Schleife 10 mal durchlaufen
XKo = (Spalte + HpB) * 16 : YKo = (Zeile + HpB) * 16  //X/Y Oben-Links
GoSub Vertex2F              //X/Y gemäß VERTEX2F an Bit-Pos. schieben,
                            //RamDl+4, SPI übergeben
XKo = (Spalte + Breite - HpB) * 16
YKo = (Zeile + Hoehe - HpB) * 16       // X/Y Unten-Rechts
GoSub Vertex2F

Befehl = bCOLOR_RGB
DDis0 = Rot + (HpB * 16)     //Farbe schwarz mit jedem Durchlauf um 16 
inc.
DDis1 = Gruen + (HpB * 16)
DDis2 = Rot + (HpB * 16)
GoSub Ram4 : GoSub Bef32
Next                         // Schleife von vorn
Return                      // Zurück zum Hauptprogramm


======================================================================== 
===
Ich durchlaufe also EIN und DIE SELBE Schleife (X/Y berechnen, Vertex2F 
ausführen) immer wieder nur. Mache ich das mehr als 10 mal innerhalb der 
Schleife = Chaos, springe ich mit Return zurück und beginne mit einer 
anderen Spalte von vorn, geht es ???

Du schreibst es einfach so: "Dann nimm doch 2 Bilder, füge an ..."
Wir reden seit Wochen glaube ich aneinander vorbei. Bisher (und so soll 
es bleiben) programmiere ich PIC's, rede per I2C/SPI/UART mit 
ON-Board-Controllern bzw. externen Geräten mit klaren Befehlen gemäß 
Datenblatt. Dieser FT8xx jedoch ist ja eine kleine Maschine, die eine 
Anwendersoftware haben möchte, also so, als ob ich auf Windows ein 
Programm schreibe. Und das kann ich nicht, also wühle ich mich durch 
dieses "wischi-waschi" Datenblatt mit seinen vielen Druckfehlern und 
schlammigen Formulierungen.
Nur mal 2 Beispiele:
Befehl END, sinngemäß: Es st empfohlen, nach jedem BEGINN ein END zu 
setzen. Der erfahrene User kann es aber auch weglassen ??????????
Was soll ich damit anfangen?
COLOR_RGB: Hier stehen die Farben im Register R B G, richtig muss aber R 
G B sein...
Oder allein diese Unklarheit mit dem REG_DLSWAP...

Wie soll ich nur mal rein physikalisch gesehen eine Datei (Bild) vom PC 
mit USB als Schnittstelle in den Speicher des FT mit Schnittstelle SPI 
begommen? Klar habe ich das schon x-mal registriert und wie man es 
herausholt mit Source und so, ist ja auch noch relativ leicht 
durchschaubar. Aber wie kommt es da erst einmal rein????????????????????
Das geht doch wohl nur wieder mit entspr. Adapterplatine und Software 
???

[Bernd I. (Gast)]

Nachtrag:
Ich habe einfach keine Zeit, einen Computer-Lehrgang zu absolvieren. Es 
ist schon extrem sündhaft, was ich bisher mit diesem FT an Zeit 
verdaddelt habe.
Deshalb werden mir auch die sicherlich vielen interessanten 
Möglichkeiten der Grafik-Maschine verborgen bleiben, zumindest vorerst.
Verschwende bitte auch deine kostbare Zeit nicht so sehr wegen der 
Phänomenen. Klar wurmt es mich, aber kann damit leben. Es ist nur, dass 
vielleicht daraus erkennbar ist, dass ich nach wie vor einen generellen 
(Denk-) Fehler habe und sich später daraus noch weitere Fehler 
ergeben...

Wie ich ein JPG aber in den FT bekomme (rein physikalisch!!!) würde mich 
schon interessieren!

[Rudolph (Gast)]

Bernd I. schrieb:
> Gut gerechnet "Löwe" :-) UND??? Was stören mich 1100 Bytes?

Das muss über den SPI geschoben werden und das kostet Zeit, und zwar 
immer und immer wieder, obwohl man das ganze in dem Fall eben auch 
"vorher berechnen" kann im Form von zwei Bildern.
Mit Farben zu jedem "Rechteck" sind das auch gar >1680 Bytes.

Bernd I. schrieb:
> Du schreibst es einfach so: "Dann nimm doch 2 Bilder, füge an ..."
> Wir reden seit Wochen glaube ich aneinander vorbei.
> Bisher (und so soll es bleiben) programmiere ich PIC's,
> rede per I2C/SPI/UART mit ON-Board-Controllern bzw. externen Geräten
> mit klaren Befehlen gemäß Datenblatt.

Da reden wir nicht aneinander vorbei, das ist mir soweit schon klar.
Letzlich mache ich ja auch nichts weiter als den Chip per SPI zu 
bedienen, das ich das in C und aktuell mit einem AVR mache ist da nur 
ein Detail. :-)

Über den SPI purzeln bei mir am Ende die gleichen Daten.

Nur habe ich mir Funktionen geschaffen die mir das Gefummel mit den 
Rohdaten abnehmen, das geht ganz sicher auch in BASIC.
Die Namen meiner Funktion sind ganz stark an das angelehnt was FTDI so 
dokumentiert hat, die Funktionen haben weitgehend die gleichen Parameter 
mit den gleichen Typen und in der gleichen Reihenfolge wie die 
Kommandos.

In C wäre das wahrscheinlich für jemanden der sich damit auskennt ein 
Witz das auf einen PIC anzupassen.


Und ja, das Datenblatt und das Programmier-Handbuch sind nicht so der 
Bringer.
Und gemeldete Fehler werden zwar gerne entgegen genommen, aber nicht 
eingepflegt.

Bernd I. schrieb:
> Wie ich ein JPG aber in den FT bekomme (rein physikalisch!!!) würde mich
> schon interessieren!

Da gibt es verschiedene Wege.
Grundsätzlich konvertiere ich die Binär-Daten erstmal in Code der 
mitcompiliert wird und als Array im FLASH-Speicher landet, das wird 
BASIC sicher auch können.

Das einfachste für Dich wird sein, ein Bild mit dem "Image Convert Tool" 
von FTDI zu konvertieren, vorzugsweise mit V0.7 davon.
Das ist ein Kommandozeilen Tool und das schreibt immer vier Dateien:
xxx.bin - gepackt, binär
xxx.binh - gepackt, text
xxx.raw - ungepackt, binär
xxx.rawh - ungepackt, text

img_cvt -i xxx.png -f 7 -d

Das xxx.rawh kann man nehmen, entsprechend der Sprache in ein Array 
packen, das Array per SPI an die gewünschte Adresse schicken.
Nur kostet ein Farb-Bild in RGB565 2 Byte pro Pixel, also mal eben 8kb 
für 64x64 Pixel, da geht schnell der Platz im Controller aus.

Die gepackten Daten lädt man mit cmd_inflate über den Co-Prozessor, da 
werden die Daten in den CMD-FIFO geschrieben, direkt nach dem Kommando.

Und zuletzt gibt es noch cmd_loadimage mit dem man beim FT80x .jpg vom 
Co-Prozessor entpacken lassen kann.

Hier sind ja auch genug Fotos im Thread.
Die ganzen Bilder die man da auf den diversen Displays sehen kann sind 
alle in meinem Controller gespeichert und werden beim Programmstart in 
den FT8xx geschoben.

[Rudolph R. (rudolph)]

Ich habe gerade mal versucht das Programm nachzuvollziehen, so mit Excel 
und im Screen-Editor.

Das Ergebnis sieht auf den ersten Schritt nicht so ganz korrekt aus, vor 
allem die Farben.

Im Screen Editor sieht das so aus:

CLEAR(1, 1, 1)

LINE_WIDTH(80)

BEGIN(RECTS)
COLOR_RGB(100, 255, 100)
VERTEX2F(480, 480)
VERTEX2F(1280, 1280)

COLOR_RGB(116, 16, 116)
VERTEX2F(496, 496)
VERTEX2F(1264, 1264)

COLOR_RGB(132, 32, 132)
VERTEX2F(512, 512)
VERTEX2F(1248, 1248)

COLOR_RGB(148, 48, 148)
VERTEX2F(528, 528)
VERTEX2F(1232, 1232)

COLOR_RGB(164, 64, 164)
VERTEX2F(544, 544)
VERTEX2F(1216, 1216)

END()

Die RAM_DL Ausgabe konnte ich leider nicht im Text raus kopieren.

Ausserdem habe ich zwei spontane Versuche mit Paint angehängt für 
fürchterliche hässliche Knopf-Bilder. :-)

[Flo (Gast)]

Also ich habe große Probleme mit dem Chip warm zu werden.
Man wird mit Doku und Notes gerade zu erschlagen und ich habe 
Schwierigkeiten die für mich relevanten Dinge zu filtern.

Ich habe mir die Spielplatz_90CAN_FT800.zip Routinen mal angeschaut. Der 
Code ist wirklich verständlich und einfach gehalten.

Ich frage mich allerdngs woher die defines für die Display 
Initialiserung herkommen. Im Code z.B.
// VM800B35A: FT800 320x240 3.5" FTDI
Gelten die nun für jedes 320x240 Punkte LCD, bzw würde jedes 320x240 
Punkte LCD mit diesen defines out of the box was anzeigen ?

Nach der ft800_init() Routine hört es dann auch mit meinem Verständnis 
auf.
Folgende Befehle sollen wohl ein Bild darstellen. An welchem Pixel 
Offset wird das Bild angezeigt, ab 0 bzw. 18432 ?

while(ft800_busy() == 1);
ft800_get_cmdoffset();
ft800_cmd_memset(0, 0xff,1L*96*96*2);  // Clear the memory at location 0 - any previous junk or bitmap data
ft800_cmd_execute();

while(ft800_busy() == 1);
ft800_cmd_loadimage(0, FT_OPT_NODL, jpg3, 3708);
ft800_cmd_execute();

while(ft800_busy() == 1);
ft800_cmd_loadimage(18432, FT_OPT_NODL, jpg4, 3708);
ft800_cmd_execute();

Ab wann wird das Bild angezeigt, soabld die Daten in der Funktion 
ft800_cmd_loadimage übertragen werden oder nach dem Befehl 
ft800_cmd_execute() ?

Was hat es mit diesen Listen auf sich, das verstehe ich überhaupt nicht 
:-(

Gruß
Flo

[Bernd I. (Gast)]

Flo schrieb:
> Also ich habe große Probleme mit dem Chip warm zu werden.
> Man wird mit Doku und Notes gerade zu erschlagen und ich habe
> Schwierigkeiten die für mich relevanten Dinge zu filtern.

Willkommen im Klub...
Ein bloßes Kopieren vorhandener Codes, trägt - Meiner Meinung nach - 
nicht gerade zum Verständnis bei, jedenfalls nicht für den Anfang.
Zuerst müssen alle Register für das Display gesetzt werden (REG_HCYCLE, 
REG_HOFFSET, usw...). Die Register sind eigentlich gut beschrieben, 
incl. einem Taktdiagramm, was enorm zum Verständnis beiträgt, was mit 
diesem Register gemeint ist (Vergleiche mit dem Taktdiagramm im 
Datenblatt des Display).
Dann muss grundsätzlich eine List geschrieben werden, so ist das 
Grundprinzip. Die Beschreibungen "mittendrin" lassen viele Details als 
Selbstverständlich einfach weg. Wenn im Betriebshandbuch eines Autos 
steht, dass das Auto sich nach links bewegt, wenn man das Lenkrad nach 
links dreht, dann ist es selbstverständlich, dass man zunächst das Auto 
starten muss, Kupplung treten, Gang einlegen ... Das steht aber an einer 
ganz anderen Stelle im Handbuch. Und beim FT8xx steht das "am besten" 
ganz hinten, obwohl mich das zuerst interessiert ...
Mit den Codes im "Spielplatz" kann ich dir nun absolut nicht weiter 
helfen, da ich mit "C" nichts am Hut habe. Frag Rudi :-)
Es gibt aber sicher C-Befehle, die dafür sorgen, dass der FT8xx gesagt 
bekommt: "Setze Register REG_HCYCLE auf den Wert 43" ... Vielleicht ist 
das ZUNÄCHST etwas umständlicher, aber du verstehst, was du da machst.

[Rudolph R. (rudolph)]

Naja, der "Spielplatz" ist schon länger nicht mehr aktuell.

Flo schrieb:
> Ich frage mich allerdngs woher die defines für die Display
> Initialiserung herkommen.

Teilweise aus Beispiel-Programmen, teilweise direkt aus den 
Datenblättern der TFTs.

Flo schrieb:
> // VM800B35A: FT800 320x240 3.5" FTDI
> Gelten die nun für jedes 320x240 Punkte LCD, bzw würde jedes 320x240
> Punkte LCD mit diesen defines out of the box was anzeigen ?

Ist einen Versuch wert, aber nein, nicht unbedingt.
Die Timing-Parameter sollten eigentlich ähnlich sein, im Zweifel muss 
man das aber mit dem Datenblatt vergleichen.
Da das nicht ganz so einfach ist habe ich eben einige Konfigurationen 
mit zur Verfügung gestellt.

Flo schrieb:
> Folgende Befehle sollen wohl ein Bild darstellen. An welchem Pixel
> Offset wird das Bild angezeigt, ab 0 bzw. 18432 ?

Das zeigt noch gar nicht an, das dient lediglich dazu die Bild-Daten in 
den Objekt-Speicher des FT8xx zu bekommen.

Hier steht noch etwas mehr Erläuterung zu dem Ding:
https://www.mikrocontroller.net/articles/FT8xx_Library

Das Anzeigen von Bildern erfolgt in der Display-Liste, zum Beispiel so:

FT8_cmd_dl(DL_BEGIN | FT8_BITMAPS);
FT8_cmd_setbitmap(MEM_LOGO, FT8_L8, 38, 59);
FT8_cmd_dl(VERTEX2F(100, 20));
FT8_cmd_dl(VERTEX2F(150, 20));
FT8_cmd_dl(VERTEX2F(200, 20));
FT8_cmd_dl(DL_END);

Damit wird das gleiche Bild aus Adresse MEM_LOGO des Objekt-Speichers 
mit 38x59 Pixel drei Mal angezeigt.

Was hast Du denn für ein Display, mit welchem FT8xx und mit welchem 
Controller möchtest Du das benutzen?

[Flo (Gast)]

Rudolph R. schrieb:
> Hier steht noch etwas mehr Erläuterung zu dem Ding:
> https://www.mikrocontroller.net/articles/FT8xx_Library
Vielen Dank dafür das hatte ich noch nicht gefunden, werde ich mal 
durchgehen

Rudolph R. schrieb:
> Was hast Du denn für ein Display, mit welchem FT8xx und mit welchem
> Controller möchtest Du das benutzen?
https://www.glynshop.com/erp/owweb/Daten/DSS/EDT/Products/Specifications/Active%20Displays/ET035009DM6.pdf
FT800
LPC1768

Ich habe Deinen "Spielplatz" als Grundlage genommen weil ich ihn für den 
Anfang als sehr übersichtlich empfand. Ich brauchte lediglich den SPI 
Treiber auf den LPC umschreiben und sofort hatte ich Verbindung zum 
Chip.
Die Init läuft komplett durch, auch die ChipID wird korrekt gelesen.

Nach der Init bin ich dann etwas verunsichert was ich machen muss, Touch 
oder Audio brauche ich nicht. Möchte erst einmal Bilder und Text 
darstellen.

[Flo (Gast)]

Nach der Init Routine rufe ich aktuell folgenden Code auf
Ergebnis bleibt ein weißes Display

ft800_memWrite8(REG_ROTATE, 1);  // rotate display by 180°

while(ft800_busy() == 1);
ft800_get_cmdoffset();

ft800_cmd_memset(0, 0xff,1L*96*96*2);  // Clear the memory at location 0 - any previous junk or bitmap data
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(0, FT_OPT_NODL, jpg3, 3708);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(18432, FT_OPT_NODL, jpg4, 2640);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(40000, FT_OPT_NODL, leopard, 3741);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(56800, FT_OPT_NODL, schneehase, 1833);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(74000 + (8192 * 0), FT_OPT_NODL, blitz, 1638);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(74000 + (8192 * 1), FT_OPT_NODL, figure, 2314);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(74000 + (8192 * 2), FT_OPT_NODL, frog, 1639);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(74000 + (8192 * 3), FT_OPT_NODL, map1, 2476);
ft800_cmd_execute();

while(ft800_busy() == 1);

ft800_cmd_loadimage(106768, FT_OPT_NODL, spiral, 2618);
ft800_cmd_execute();

while(ft800_busy() == 1);


ft800_cmd_dl(CMD_DLSTART); // Start the display list
ft800_cmd_dl(DL_CLEAR_RGB | BLACK); // Set the default clear color to black
ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); // Clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers
ft800_cmd_dl(TAG(0));

#define FT8_BITMAPS              1UL
#define FT8_L8                   3UL

ft800_cmd_dl(DL_BEGIN | FT8_BITMAPS);
ft800_cmd_setbitmap(0, FT8_L8, 38, 59);
ft800_cmd_dl(VERTEX2F(100, 20));
ft800_cmd_dl(VERTEX2F(150, 20));
ft800_cmd_dl(VERTEX2F(200, 20));
ft800_cmd_dl(DL_END);

[Rudolph R. (rudolph)]

Flo schrieb:
>> Was hast Du denn für ein Display, mit welchem FT8xx und mit welchem
>> Controller möchtest Du das benutzen?
> 
https://www.glynshop.com/erp/owweb/Daten/DSS/EDT/Products/Specifications/Active%20Displays/ET035009DM6.pdf

Hmm, spontan komme ich mit dem Datenblatt nicht klar, ist einfach zu 
lange her, dass ich die Timing-Parameter durchgeschüttelt habe.
Das Problem ist, dass die Angaben zwischen FT8xx und Datenblatt vom 
Display unterschiedlich angegeben werden.

Zumindest kann ich sagen, dass der Takt passt. :-)

Wobei mir gerade einfällt, dass Glyn auch eine Library hat, das würde 
ich aber so in Richtung tot einordnen, aber vielleicht ist da was zum 
Init zu finden. Ein Display von Glyn habe ich auch in meinen Daten, nur 
habe ich von denen nie was in die Finger bekommen.

> FT800

Auf was für einem Board sitzt der? Hat das Ding einen Quarz?

> LPC1768

Auch interessant.
Benutzt Du GCC als Compiler? Was setzt der Compiler denn so automatisch 
an Symbolen für den Controller?
Und poste mal bitte den modifizierten Code aus FT800_config.c

Flo schrieb:
> Ich habe Deinen "Spielplatz" als Grundlage genommen weil ich ihn für den
> Anfang als sehr übersichtlich empfand.

Ist nur eben alt, der Code ist inzwischen etwas weiter gekommen.

Flo schrieb:
> Nach der Init Routine rufe ich aktuell folgenden Code auf
> Ergebnis bleibt ein weißes Display

Na, zum einen ist die Liste nicht abgeschlossen, wird also gar nicht 
angezeigt, zum anderen kennt der FT800 gar kein cmd_setbitmap().

ft800_init();

while(ft800_busy() == 1);
ft800_get_cmdoffset();

ft800_cmd_loadimage(0, FT_OPT_NODL, jpg3, 3708);
ft800_cmd_execute();
while(ft800_busy() == 1);


ft800_cmd_dl(CMD_DLSTART); // Start the display list
ft800_cmd_dl(DL_CLEAR_RGB | BLACK); // Set the default clear color to black
ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); // Clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers
ft800_cmd_dl(TAG(0));

ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_dl(BITMAP_SOURCE(0));
ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96)); // jpg3
ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96)); // jpg3
ft800_cmd_dl(VERTEX2F(50*16,50*16));
ft800_cmd_dl(DL_END);

ft800_cmd_dl(DL_DISPLAY);  // Instruct the graphics processor to show the list
ft800_cmd_dl(CMD_SWAP); // Make this list active
ft800_cmd_execute();

[Flo (Gast)]

Rudolph R. schrieb:
> Auf was für einem Board sitzt der? Hat das Ding einen Quarz?
Der FT800 und der lpc sitzen je auf einem breakoutboard und sind mit 
kurzen leitungen verbunden.
Ich habe wie im Beispiel Design ein 12MHz externen Quarz angeschlossen.

Rudolph R. schrieb:
> Benutzt Du GCC als Compiler? Was setzt der Compiler denn so automatisch
> an Symbolen für den Controller?
> Und poste mal bitte den modifizierten Code aus FT800_config.c
Benutze Eclipse mit GNU ARM Embedded toolchain
Benutze ein Makefile, also keine Standard Symbole
Ich habe Deinen Code der config.c kopiert und lediglich die SPI Lese- 
und Schreibe Routinen auf die Register des LPC abgeändert. Also so gut 
wie keine Änderung.

Rudolph R. schrieb:
> Na, zum einen ist die Liste nicht abgeschlossen, wird also gar nicht
> angezeigt, zum anderen kennt der FT800 gar kein cmd_setbitmap().
Ok das ist ein Argument :-)
Habe es mit Deinem Code oben versucht aber es tut sich nach wie vor 
nichts.
Kann man hier systematisch Fehlersuche betreiben ?
Der Init Code ist ja absolut identisch zu Deinem. Ich behaupte der SPI 
funktioniert auch gleich.
Was wäre der kleinste Aufwand nach der Init was auf dem Display zu sehen 
?
Z.B. ein Pixel oder sowas ?

[Rudolph R. (rudolph)]

Flo schrieb:
>> Auf was für einem Board sitzt der? Hat das Ding einen Quarz?
> Der FT800 und der lpc sitzen je auf einem breakoutboard und sind mit
> kurzen leitungen verbunden.
> Ich habe wie im Beispiel Design ein 12MHz externen Quarz angeschlossen.

Hmm, interessant, was ist denn das für ein Breakoutboard auf dem der 
FT800 sitzt? Sowas könnte ich auch noch gebrauchen.

> Rudolph R. schrieb:
>> Benutzt Du GCC als Compiler? Was setzt der Compiler denn so automatisch
>> an Symbolen für den Controller?
>> Und poste mal bitte den modifizierten Code aus FT800_config.c
> Benutze Eclipse mit GNU ARM Embedded toolchain
> Benutze ein Makefile, also keine Standard Symbole

Oh doch, klar, es wird immer ein Satz Symbole per Default generiert.
Zum Beispiel eben "__GNUC__" für GCC, sowas wie "__ARM__" oder noch 
besser noch "__LPC1768__" muss auch da sein.

Was bräuchte ich denn im besonderen so um das hier bauen zu können?

> Ich habe Deinen Code der config.c kopiert und lediglich die SPI Lese-
> und Schreibe Routinen auf die Register des LPC abgeändert. Also so gut
> wie keine Änderung.

Mich interessieren ja gerade die Controller-spezifischen Änderungen um 
das in meinen Code mit einbauen zu können.

Wie schnell hast Du den SPI laufen?
Zum Init darf das nicht schneller als 11MHz sein, danach 30MHz.

Das ganze SPI Setup ist ja bewusst nicht Teil von meinem Code.

> Rudolph R. schrieb:
>> Na, zum einen ist die Liste nicht abgeschlossen, wird also gar nicht
>> angezeigt, zum anderen kennt der FT800 gar kein cmd_setbitmap().
> Ok das ist ein Argument :-)
> Habe es mit Deinem Code oben versucht aber es tut sich nach wie vor
> nichts.
> Kann man hier systematisch Fehlersuche betreiben ?
> Der Init Code ist ja absolut identisch zu Deinem. Ich behaupte der SPI
> funktioniert auch gleich.
> Was wäre der kleinste Aufwand nach der Init was auf dem Display zu sehen
> ?
> Z.B. ein Pixel oder sowas ?

Pixel gibt es nicht in dem Sinne, jedenfalls nicht so einfach.

Das einfachste wäre die Farbe zu ändern.

ft800_init();

while(ft800_busy() == 1);
ft800_get_cmdoffset();

ft800_cmd_dl(CMD_DLSTART); // Start the display list
ft800_cmd_dl(DL_CLEAR_RGB | 0xff0000); // rot
ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

ft800_cmd_dl(DL_DISPLAY);
ft800_cmd_dl(CMD_SWAP);
ft800_cmd_execute();

Aber da bei Dir der Bildschirm weiss bleibt und in der Liste schwarz 
steht ist davon auszugehen, dass schon das ft800_init() nicht richtig 
durch läuft.

Wobei in der ft800_init() auch schon eine aller erste Liste geschrieben 
wird:

ft800_memWrite32(FT_RAM_DL, DL_CLEAR_RGB);
ft800_memWrite32(FT_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
ft800_memWrite32(FT_RAM_DL + 8, DL_DISPLAY);  // end of display list
ft800_memWrite32(REG_DLSWAP, FT_DLSWAP_FRAME);

Das sieht anders aus weil das direkt in den Listen-Speicher geschrieben 
wird, oben geht das über den Command-co-prozessor.
Wie auch immer, auch diese Display-Liste macht einen schwarzen 
Hintergrund mit der ersten Zeile. Das BLACK ist ja nur 0x000000.

Also noch einfacher wäre, nur das ft800_init() zu machen und dort die 
Farbe zu ändern um zu schauen ob sich das manipulieren lässt.

[Rudolph (Gast)]

Ich habe gerade im Code von Glyn nachgesehen und es gibt eine Config für 
das ET0350, probier mal das hier:

// ET0350 Glyn, untested: 320x240 3.5"
#ifdef FT_ET0350
#define FT_VSYNC0  (0L)  // Tvf Vertical Front Porch
#define FT_VSYNC1  (3L)  // Tvf + Tvp Vertical Front Porch plus Vsync Pulse width
#define FT_VOFFSET  (4L)  // Tvf + Tvp + Tvb Number of non-visible lines (in lines)
#define FT_VCYCLE  (263L)  // Tv Total number of lines (visible and non-visible) (in lines)
#define FT_VSIZE  (240L)  // Tvd Number of visible lines (in lines) - display height
#define FT_HSYNC0  (0L)  // Thf Horizontal Front Porch
#define FT_HSYNC1  (30L)  // Thf + Thp Horizontal Front Porch plus Hsync Pulse width
#define FT_HOFFSET   (33L)  // Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles)
#define FT_HCYCLE   (408L)  // Th Total length of line (visible and non-visible) (in PCLKs)
#define FT_HSIZE  (320L)  // Thd Length of visible part of line (in PCLKs) - display width
#define FT_PCLKPOL   (0L)  // PCLK polarity (0 = rising edge, 1 = falling edge)
#define FT_SWIZZLE   (0L)  // Defines the arrangement of the RGB pins of the FT800
#define FT_PCLK    (8L)  // 48MHz / REG_PCLK = PCLK frequency
#define FT_TOUCH_RZTHRESH (1200L)  // touch-sensitivity
#endif

[Flo (Gast)]

Hallo Rudolph,

vielen dank für Deine Mühe. Ich habe das Display nun mehr oder weniger 
zufällig zum Laufen gebracht. Sobald das DISP Signal deaktiviert ist 
läuft alles wie gewünscht.
ft800_memWrite8(REG_GPIO, 0);
Verstehe ich zwar nicht aber ok

Lasse mir nun Dein jpg3 am Display anzeigen. Das funktioniert soweit.
Nun möchte ich das gegen ein 320x240 Bild austauschen. Ich habe mir nun 
ein Bild auf die Größe konvertiert und es durch den Image Converter von 
FTDI durchlaufen lassen. Der schmeißt nun einige Ausgabedateien.

Das PNG aus dem Converter habe ich wieder in jpg gewandelt und will die 
ersten 4k am Display anzeigen. Das funktioniert nicht. es bleibt der 
schwarze Hintergrund.
Ich hätte erwartet dass die ersten 4k Bildmaterial im 320x240 Frame 
angezeigt werden.

Wenn ich den Pointer meines Bildes auf den des jpg3 ändere dann erkennt 
man in der oberen Hälfte die Farben des jpg3 und der Rest ist Pixel 
Random.

Gehe davon aus dass es an meinem Bild liegt. Vieleicht gibt es ja 
320x240 Bild was funktioiert so dass ich das besser Testen kann.

[Rudolph R. (rudolph)]

Äh okay, das liegt dann an dem immer noch nicht näher beschriebenen 
Breakout-Board. :-)

Ein Bild mit 320x240 wird mit dem alten Code nicht klappen, das 
cmd_loadimage kann nämlich nur 4k Daten laden bzw. knapp unter 4k.
Was aus dem Bilder-Converter von FTDI purzelt wird mit cmd_inflate 
geladen, das kann aber ebenfalls nur 4k so wie das programmiert ist.

In der aktuellen Version kann cmd_loadimage() bis 64k laden.
Aber cmd_inflate() habe ich noch nicht weiter aufgebohrt, weil das eher 
für sowas wie Icons und Logos Sinn macht und dabei die 4k nicht so 
einschränkend sind.

[Flo (Gast)]

Rudolph R. schrieb:
> Ein Bild mit 320x240 wird mit dem alten Code nicht klappen, das
> cmd_loadimage kann nämlich nur 4k Daten laden bzw. knapp unter 4k.
Das hatte ich schon gelesen aber wenn ich die ersten 4k des Bildes lade 
müsste man ja schon den oberen Teil des Bildes sehen oder habe ich da 
einen Denkfehler ?

Rudolph R. schrieb:
> What is needed is to extend ft800_cmd_loadimage() to handle buffers that
> are larger than 4k in chunks of a little less than 4k.
> It's like this:
> start-command
> send 4k data
> execute
> wait
> send 4k data
> execute
> wait
> send remaining data
> execute
> done
Funktioniert das so nicht ?

[Flo (Gast)]

Rudolph R. schrieb:
> Äh okay, das liegt dann an dem immer noch nicht näher beschriebenen
> Breakout-Board. :-)
Das ist ein ganz normales breakout board für das qfn48 gehäuse wobei 
jeder pin auf eine Steckleiste geführt ist und dann auf einem steckbrett 
weiter verbunden werden kann
ähnlich wie dieses
https://electronic-things.co.uk/wp-content/uploads/2014/08/PCB-ADP-QFN48-01A.jpg

Achso eine Sache interessiert mich noch
FT8_cmd_loadimage(0, FT_OPT_NODL, jpg3 , jpg3_size);
stellt mir ja Dein jpg3 am Bildschir dar.

Übertrage ich 100 Bytes weniger dann bleibt der ganze Bildschirm schwarz
FT8_cmd_loadimage(0, FT_OPT_NODL, jpg3 , jpg3_size-100);
Warum muss das ganze Bild übertragen werden, woher weiß der Chip das ?
Wenn ich 100 Bytes weniger übertrage müsste das Bild doch fast komplett 
dargestellt werden und die letzten 100 Bytes Pixel eben Random Farben. 
Der Header ist doch ganz am Anfang ?

[Rudolph R. (rudolph)]

Flo schrieb:
> Das hatte ich schon gelesen aber wenn ich die ersten 4k des Bildes lade
> müsste man ja schon den oberen Teil des Bildes sehen oder habe ich da
> einen Denkfehler ?

Das funktioniert nicht mit der Kompression, die Daten sind dann einfach 
nicht vollständig.

> Rudolph R. schrieb:
>> What is needed is to extend ft800_cmd_loadimage() to handle buffers that
>> are larger than 4k in chunks of a little less than 4k.
>> It's like this:
>> start-command
>> send 4k data
>> execute
>> wait
>> send 4k data
>> execute
>> wait
>> send remaining data
>> execute
>> done
> Funktioniert das so nicht ?

Doch, im Grunde genommen ja, das ist nur im der "Spielplatz" Version 
noch nicht implementiert, in der aktuellen Version aber schon.
Mit der "Spielplatz" Version bekommt man das nur hin indem man die 
Funktion umschreibt, mit den Funktionen die da sind geht es nicht.

Flo schrieb:
> Das ist ein ganz normales breakout board für das qfn48 gehäuse wobei
> jeder pin auf eine Steckleiste geführt ist und dann auf einem steckbrett
> weiter verbunden werden kann

Ach so, dann ist eben die Frage wie das konkret verdrahtet ist.

[Rudolph R. (rudolph)]

Ich habe mal ein Github Repository dafür angelegt:
https://github.com/RudolphRiedel/FT810-FT813

Ist ein Anfang und noch nicht ganz auf dem aktuellen Stand, da ich die 
neuesten Dateien gar nicht hier habe im Moment.

Was noch pro-forma gefehlt hat war eine Lizenz dafür, ich habe mich für 
die MIT-Lizenz entschieden.

[Rudolph R. (rudolph)]

Kann nicht mehr editieren, hab das nochmal umbenannt:

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

[Peter (Gast)]

Hallo,

Super Lib! Vielen Dank dafür!
Bin gerade mich dabei einzuarbeiten, bringe schon manchmal auch Text 
aufs Display, habe aber seltsames Verhalten welches ich mir nicht 
erklären kann:

Zum Beispiel ich gebe sowas aus:

const Long_t items1[] = {
  CLEAR_COLOR_RGB(0,0,0),
  CLEAR(1,1,1),
  COLOR_RGB(255,255,255),
  BEGIN(FT8_BITMAPS),
    VERTEX2II(220,110,31,'F'),
    VERTEX2II(244,110,31,'T'),
    VERTEX2II(270,110,31,'D'),
    VERTEX2II(299,110,31,'I'),
  END(),

  COLOR_RGB(160,22,22),
  POINT_SIZE(320),
  BEGIN(FT8_POINTS),
    VERTEX2II(192,133,0,0),
  END(),
};
#define LIST_ELEMENTS(x) (sizeof(x)/sizeof(Long_t))

  FT8_start_cmd_burst();
  FT8_cmd_dl(CMD_DLSTART);
  for (i=0; i<LIST_ELEMENTS(items1); i++) {
    FT8_cmd_dl(items1[i]);
  }
  FT8_cmd_dl(COLOR_RGB(255,255,0));
  FT8_cmd_text(5, 30, 28, 1, "TEST!");
  FT8_cmd_dl(DISPLAY());
  FT8_cmd_dl(CMD_SWAP);
  FT8_end_cmd_burst();
  FT8_cmd_execute();

Das funktioniert soweit.
So, weiter im Code wenn ich jetzt wieder etwas ausgeben will mit:

  FT8_cmd_dl(CMD_DLSTART);
// FT8_cmd_dl(CLEAR(1,1,1));
  FT8_cmd_dl(COLOR_RGB(255,255,255));
  FT8_cmd_text(55, 30, 28, 31, "TEXT!");
  FT8_cmd_dl(DISPLAY());
  FT8_cmd_dl(CMD_SWAP);
  FT8_cmd_execute();

bekomme ich nur weisse vertikale Linien von oben bis unten angezeigt, 
und zwar an der Stelle wo der Text zu erwarten wäre.
Wenn ich nach dem CMD_DLSTART den Bildschirm lösche (dh: CLEAR(1,1,1)) 
kommt der Text. Der Punkt ist: ich will nicht den Bildschirm löschen. 
Irgendwie ergibt das keinen Sinn.
Was mache ich falsch?

Viele Grüße
Peter

[Rudolph R. (rudolph)]

Hmm, keine Mail dazu erhalten...

Peter schrieb:
> Wenn ich nach dem CMD_DLSTART den Bildschirm lösche (dh: CLEAR(1,1,1))
> kommt der Text. Der Punkt ist: ich will nicht den Bildschirm löschen.
> Irgendwie ergibt das keinen Sinn.

Das CLEAR hat im Handbuch die Beschreibung "Clear buffers to preset 
values" und macht wohl noch mehr als beschrieben wird.
Aber ein clear-screen macht es im eigentlich Sinne nicht da es ja gar 
kein Bildschirm-RAM gibt das gelöscht werden könnte, das Bild wird ja 
immer wieder neu zusammen gebaut.
Natürlich hat es den Effekt von clear-screen wenn sowieso nichts anderes 
in der Liste steht, das bereitet aber offenbar eher das neu-zeichnen vor 
indem irgendwelche Werte zurück gesetzt werden, also zusätzlich zu den 
Parametern.

Die Display-Liste wird mit der Wiederhol-Rate die sich aus den 
Display-Parametern ergibt abgearbeitet, typischerweise mit 60Hz.
Gibt man dem eine neue Liste wird am Ende der vorher benutzen auf die 
neue umgeschaltet und dann diese mit 60Hz abgearbeitet.
Das ist auch eines der Limits, man darf nicht versuchen die Liste öfter 
zu schreiben als sie abgearbeitet wird.

An den Dingern ergibt vieles wenig Sinn wenn man tiefer rein schaut.
Zum einen ist die Dokumentation an ein paar Stellen schlicht falsch oder 
einfach nur schwach und FTDI/Bridgetek bekommt es nicht gebacken 
gemeldete Fehler auch mal in ein Update zu giessen.
Andere Dinge wie zum Beispiel die VERTEX2II und VERTEX2F Kommandos die 
man ja zur Positionierung von Objekten benötigt sind ziemlich blöd 
angelegt.
Statisch ist das noch okay, da kümmert sich der Prä-Prozessor um die 
Berechnung der Konstanten, dynamisch kostet der Murks aber plötzlich 
richtig Rechenzeit auf den als Ziel-Gruppe auserkorenen 8-Bit 
Controllern.

Also einfach machen, das CLEAR tut nicht weh indem das etwa zu einem 
flackern des Bildschirms führt oder zu einer deutlichen Verzögerung wie 
das bei einfachen LCDs der Fall wäre.

Dennoch kann man sich ja ersparen statische Inhalte immer und immer 
wieder an den FT8xx zu schicken, das habe ich in dem Beispiel ja mit dem 
CMD_APPEND umgesetzt, da wird einfach einmal ein Listen-Fragment 
generiert im Speicher vom FT8xx und anschliessend immer wieder in die 
Liste eingebaut. Da gehen dann pro Update nicht die vcllen 1500 Bytes 
über den SPI die für die Liste gebraucht werden, sondern vielleicht nur 
noch die 300 mit den veränderlichen Inhalten.
Das lässt sich auch problemlos mit mehreren Seiten umsetzen indem 
einfach mehrere Listen-Fragmente vorab generiert werden.

Welches Display hast Du eigentlich und welchen Controller setzt Du ein?

[Peter (Gast)]

Hallo Rufolph,

Vielen Dank für Deine Antwort. Ich habe hier Atmel SAM4E mit FT810 und 
einem 800x480 Display.
Habe vorher mit ATmega2560 und einem eDIP128 gearbeitet, da konnte ich 
nur ausgewählte Bereiche löschen und neu beschreiben, das ging relativ 
ressourcenschonend weil nicht das ganze Bild durch die langsame 
Schnittstelle des eDIP durch musste. Deshalb habe ich angenommen, daß 
ich hier auch so arbeiten kann.
Bei dem FT8xx musste ich dann feststellen, daß das Vorgehen so nicht 
geht. Es hat dann irgednwann klick gemacht und ich habe begriffen, daß - 
egal bei welcher Änderung - ich das Bild neu aufgbauen muss. Ja, das mit 
dem Append habe ich verstanden, ist mir aber zu unsicher, weil ich nie 
wissen kann was gerade angezeigt wird und manchmal muss man eben paar 
Elemente ausblenden, also neu aufbauen erscheint mir schon sicherer.

Ich arbeite viel mit Bildelementen, das erfordert einen 
Ressourcenmangement.
Dafür habe ich mir einen Ressourcen Manager gebaut, der nimmt die 
Ressourcen (BIN/PNG/JPG Daten), dekomprimiert sie im RAM_G und hängt sie 
dicht an dicht hintereinander, dann referenziere ich sie nur:
zB:
resmgr_load(tabelle);
resmgr_set(bildref, x,y);

Die Ressourcen sind in Tabellen organisiert die bei Bedarf umgeladen 
werden. Dabei spielt es keine Rolle ob Inflate oder Loadimage benutzt 
wird, was benutzt wird in der Tabelle vermerkt. So kann ich JPG mit PNG 
und BIN gemischt benutzen. Für die Erstellung von Ressorce-Tabellen habe 
ich einen Python Script, der mir die Bilder umwandelt (img_cvt.exe), die 
Offsets nach dem INFLATE ermittelt und die Tabelleneinträge zum 
Copy&Paste ausgibt. Das erspart mir das manuelle Setzen von Adressen per 
Konstanten.

Habe schon etliche PNG Bilder als BIN reingeladen und auch PNGs und JPG. 
PNGs und BINs hatten Transparenzen, klappte auch alles.
Dabei habe ich eine Beobachtung gemacht: ich habe hier ein Bild, das 
habe ich als BIN reingeladen und es wird einfach nicht dekomprimiert.

Zunächst ein Gut Fall zum Vergleich:
Zum Testen habe ich ein Bild an RAM_G Adresse geladen (INFLATE) und 
angezeigt.
Zum Prüfen habe ich:
1) vor dem INFLATE die ersten 4 bytes zunächst mit 0x12345678 
beschrieben
2) ein INFLATE mit einem BIN (aus PNG) an RAM_G Adresse ausgeführt
3) und die 4 ersten Bytes wieder gelesen
da waren meine 4 bytes mit den Daten vom RAW Bild überschrieben, also 
alles wie erwartet. Bild wird später ohne Probleme angezeigt.

Dann habe ich ein anderes Bild genommen, BIN (ARGB1555) Länge 25960 und 
RAW Länge nach dem INFLATE sind 142800 Bytes. Hier funktionierte das 
INFLATE nicht!
Die o.g. 4 Bytes waren immer noch die selben und das Bild wurde auch 
nicht angezeigt. Waren hier drin noch Daten vom anderen Bild drin, dann 
konnte ich die verzerrte Darstellung des alten Bildes erkennen (wegen 
der unterschiedlichen Bild-Auflösung).

Ich habe keine Ahnung warum gerade dieses Bild nicht funktioniert, mit 
den anderen viel kleineren habe ich keine Probleme.
Habe sogar (linux) das BIN Bild manuell inflated und mit dem RAW bild 
verglichen, passt. Es ist so, als ob INFLATE eine Beschränkung auf dem 
Chip hat.

Habe die Kommunikation mit dem Oszi überprüft. Alles ist scheinbar wie 
immer. Habe den Anfang und Ende der Daten verglichen, auch den 
wiederholten FT8_busy() am Ende wo auch der Zähler immer weiter zählt 
bis er fertig ist.

Sind Dir irgendwelche Einschränkungen bei der Benutzung von INFLATE 
bekannt? Größe? Sonst was?

In Deinem Artikel auf www.mikrocontroller.net/articles/FT8xx_Library 
schreibst Du, daß INFLATE mehr für Monochrome Bilder geeignet ist, 
warum? Ich habe keine Hinweise im Programmer Guide gefunden.

Gruß
Peter

[Peter (Gast)]

Mist! Sorry, habe Deinen Namen falsch geschrieben :-/

[Rudolph R. (rudolph)]

Da habe ich mich gerade gewundert, warum ich wieder keine Benachrichtung 
erhalten habe, aber es wurde gepostet zwischen checken der Mails und 
checken des Threads, die Mails sind da. :-)

Peter schrieb:
> Mist! Sorry, habe Deinen Namen falsch geschrieben :-/

Man kann man hier aber editieren, auch für solche erste-Welt Probleme. 
:-)

Peter schrieb:
> Sind Dir irgendwelche Einschränkungen bei der Benutzung von INFLATE
> bekannt? Größe? Sonst was?

Yup, cmd_inflate hat immer noch die 4k Beschränkung drin.
Ich hatte mal versucht da was dran zu drehen, hat aber nicht geklappt, 
warum auch immer - das kommt davon wenn man den Code zu lange nicht 
aktiv braucht und das gelegentliche Projekt nur ein Subset der 
Möglichkeiten benötigt...

Peter schrieb:
> In Deinem Artikel auf www.mikrocontroller.net/articles/FT8xx_Library
> schreibst Du, daß INFLATE mehr für Monochrome Bilder geeignet ist,
> warum?

Naja, nicht ganz meine Wortwohl. :-)
Da gehen verschiedenen Dinge ein.
Und ich bekomme das gerade nicht zufriedenstellend klar ausformuliert. 
:-)

Monochrom, bzw. mit bis zu 256 Graustufen benutze ich Symbole und Icons, 
da speichert .jpg nicht nur zu viele Informationen mit, es erzeugt durch 
die Kompression auch noch Artefakte, vor allem in Flächen.
Das ist jetzt schwer den Finger da drauf zu legen und sicher nicht 
allgemeingültig, aber ein Bild mit komprimierten 4kB hat in Inflate 
gefühlt eine höhere Qualität als in .jpg.
Man könnte zwar noch .png anführen für Verlust-freie Kompression, gerade 
bei technischen Zeichungen packt das ja besser als .jpg und dazu ohne 
Artefakte, dafür sind die FT81x aber auch etwas zickig bei .png.

Bei Farb-Bildern, vielleicht gar Fotos, kann sich .jpg voll austoben.

Bringt natürlich auch nichts, wenn man monochrome Bilder nicht 
konsequent als .bmp oder .png bearbeitet, sobald man das als .jpg 
speichert sind Artefakte drin die man nicht mehr raus bekommt.

Ech ja, grundsätzlich hätte ich ja interesse an den 
Anpassungs-Funktionen für den SAM4E. :-)

[Peter (Gast)]

Hallo Rudolph,

ah, danke, 4K, das werde ich berücksichtigen.

Zum Code: bitte schön:

im FT8_config.h zusätzlich:

// SPI kommt aus dem ASF
#define FT8_SPI        SPI

// SPI_TIMEOUT kommt aus dem ASF
#define FT8_SPI_TIMEOUT    SPI_TIMEOUT

// delay_ms von ASF
#define DELAY_MS       delay_ms

// habe 12MHz Quarz am FT810
#define FT8_HAS_CRYSTAL 1

#define FT8_RETURN_ERROR  0xff

#define CS_FT800        IOPORT_CREATE_PIN(PIOA, 8)
#define PD_DISP         IOPORT_CREATE_PIN(PIOD, 22)

//uint8_t fetch_flash_byte(const uint8_t *data);
#define fetch_flash_byte(addr)  (*(addr))


dann habe ich eine eigene FT8_io.c:


void FT8_pdn_set(void)
{
  ioport_set_pin_level(PD_DISP, IOPORT_PIN_LEVEL_LOW);
}

void FT8_pdn_clear(void)
{
  ioport_set_pin_level(PD_DISP, IOPORT_PIN_LEVEL_HIGH);
}

void FT8_cs_set(void)
{
  ioport_set_pin_level(CS_FT800, IOPORT_PIN_LEVEL_LOW);
}

void FT8_cs_clear(void)
{
  ioport_set_pin_level(CS_FT800, IOPORT_PIN_LEVEL_HIGH);
}

void spi_transmit(uint8_t data)
{
  uint32_t timeout = FT8_SPI_TIMEOUT;
  while (!spi_is_tx_ready(FT8_SPI)) {
    if (!timeout--) {
      return;
    }
  }
  spi_write_single(FT8_SPI, data);

  timeout = FT8_SPI_TIMEOUT;
  while (!spi_is_rx_ready(FT8_SPI)) {
    if (!timeout--) {
      return;
    }
  }
}

uint8_t spi_receive(uint8_t data)
{
  uint8_t val;

  uint32_t timeout = FT8_SPI_TIMEOUT;
  while (!spi_is_tx_ready(FT8_SPI)) {
    if (!timeout--) {
      return FT8_RETURN_ERROR;
    }
  }
  spi_write_single(FT8_SPI, data);

  timeout = FT8_SPI_TIMEOUT;
  while (!spi_is_rx_ready(FT8_SPI)) {
    if (!timeout--) {
      return FT8_RETURN_ERROR;
    }
  }
  spi_read_single(FT8_SPI, &val);

  return val;
}

Die Funktionen spi_... stammen aus dem ASF, welches sich beim SAM 
ohnehin empfiehlt. Damit sie gehen setzt natürlich voraus, daß man ASF 
richtig initialisiert hat, was aber mit Atmel Studio kein Problem ist. 
Man braucht dafür eigentlich keine Hardware-Register anfassen :-)
Der o.g. Kram dürfte damit mit allen SAMs funktionieren.

Hierbei sei angemerkt, daß ich die CS manuell bediene, vielleicht ein 
wenig untypisch bei den SAMs mit ASF.
Dort gibt es eigentlich eine Möglichkeit über die Systemfunktionen, dh. 
CS wird dann automatisch bedient. Ist aber bei mir wegen der Hardware 
nicht anders möglich.

Gruß
Peter

[Peter (Gast)]

Ähmm..habe jetzt das Bild als PNG (das <name>_Converted.png) mit 
Loadimage ARGB1555 und das wird nun angezeigt aber mit falschen Farben 
und ohne Transparenz.

Eine Idee?

[Peter (Gast)]

die Transparenz ist doch da, aber die Farben sind falsch.

[Rudolph R. (rudolph)]

Mehr als das ich dem .png Support nach ersten Versuchen nicht mehr so 
richtig vertraue fällt mir da spontan auch nicht ein. :-)
Transparenz und so, die FT8xx können noch eine Menge was ich noch gar 
nicht ausprobiert habe. :-)
Und wie wir oben im Thread gelernt haben kann man .png auch nicht mal 
eben einfach so zum testen anhängen, weil die Forums-Software die 
automatisch durchmangelt.

[Mark (Gast)]

Hi after a long experiments with different STM32 discovery boards using 
HAL drivers and a FT810 display it seems the initial setup of the FT810 
chip has to be done at a SPI speed between 375 and 600kHz. (not exactly)

The first test was at 48mHz and a SPI speed of 375kHz. Driver works ok.

The next STM32F407 was running at 168mhz so my SPI speeds was 656kHz or 
one step lower 328kHz so that is too low or too high. The low speed init 
seems to work. The 0x7C is replied but nothing on screen. It took lots 
of debugging to find out the hardware was not the problem.
With a main clock of 150Mhz and SPI 585kHz it all works ok.

The datasheet talks only of a low speed and high speed lower than 30mHz 
no exact numbers.

[Rudolph R. (rudolph)]

Mark schrieb:
> Hi after a long experiments with different STM32 discovery boards using
> HAL drivers and a FT810 display it seems the initial setup of the FT810
> chip has to be done at a SPI speed between 375 and 600kHz.

Not quite.
While it is correct that the SPI speed has to be lower during setup than 
the maximum of 30MHz, it is not that low.

It just needs to be 11MHz or less.
As the AVR "only" allow up to 8MHz I do not even bother to use different 
speeds.
For faster CPUs such as the RH850 I switched to more than 11 MHz after 
init.

As for the documentation, this is interesting.
While the datasheet and programmers manual for the FT800 clearly state 
it:

4.2.3 Clock Enable
"If  SPI  is  used  as  host  interface,  the  SPI  clock  shall  not 
exceed  11MHz  before  system  clock  is
enabled. After system clock is properly enabled, the SPI clock is 
allowed to go up to 30MHz."

2.2.5 Initialisation Sequence
"This section describes the initialization sequence in the different 
scenario.
  Initialization Sequence during the boot up:
1.  Use MCU SPI clock not more than  11MHz"

The datasheet and programmers guide for FT81x have these limitations 
removed.

See 4.2.3 of the datasheet and 2.3 of the programmers manual.
The example in the programmers manual however still is the same and 
reads:
"MCU_SPI_CLK_Freq(<11MHz);//use the MCU SPI clock less than 11MHz"

So maybe, this limitation does not even aply anymore to the FT81x 
series.

In any case, if you can't go higher than 600kHz during init it is not 
because the FT8xx won't go any higher.

Is DELAY_MS() working correctly?
It is only used during FT8_init() but is has to be good enough to meet 
the power-down cycle requirements of the FT8xx.
If a DELAY_MS(1) is below 950µs it is possible that the FT8xx won't even 
take any commands when FT8_init() starts sending them out.

[stromverdichter (Gast)]

@Marc
I use the FT800 with different processors from atmel and even a STM407 
with the SPI-Clock of ~8 Mhz at startup and ~24Mhz later without any 
issues. So you seem to have a problem with your personal composition. 
The chip is working here as described in the datasheet.

[mark (Gast)]

Was someone able to use the FT8_cmd_setfont2 command? It nearly works 
there should be numbers only.The font is generated by eve studio.
The commands are:
FT8_cmd_inflate(0, fonts_Art,sizeof(fonts_Art));
FT8_cmd_setfont2(0, 0, 116);
FT8_cmd_text(96, 207, 0, 0, "tuvwxyz{|}~");

This is because i want real big numbers so only char 116-127 are used. 
So the t is shown as 0

[Roberto (Gast)]

Hallo Freunde des FT8xx,

ich möchte meine Erfahrungen zum Thema FT8xx und jpg’s einbringen. 
Vielleicht kann ich ein wenig helfen.

1.  Der FT8xx mag nur reine jpg’s  ohne Exif oder sonstige integrete 
Infos.
2.  Tritt beim laden des jpgs ein Fehler auf wird REG_CMD_READ auf 0xFFF 
gesetzt, der FT hängt.

Siehe FT81X_Series_Programmer_Guide ---  5.6 Fault Scenarios.
Mein Vorschlag für Rudolphs Lib, das REG_CMD_READ abfragen und wenn 
0xFFF den Co-Processor zu reseten.

Zu 1.
Meine jpgs  passe ich mit meiner Bildsoftware der Displaygröße oder 
kleiner an und speichere diese. Danach rufe ich  Irfanview auf und 
speichere die Bilder erneut, aber ohne Dateiinfos. Damit läuft alles 
prima.
Gruß

[Peter (Gast)]

Hallo Rudolph,

ich glaube das ist ein Copy&Paste Fehler in der FT8_commands.c:

uint16_t FT8_cmd_getptr(void)
{
  uint16_t offset;

  FT8_start_cmd(CMD_MEMCRC);  // soll das nicht CMD_GETPTR heissen?
  ...

Gruß
Peter

[Rudolph R. (rudolph)]

Danke, ist gefixt, Kommandos die keiner braucht... :-)

Ich habe schon wieder viel zu lange nichts aktiv damit gemacht, sind 
zwar immer alle schwer beeindruckt wenn ich das vorführe und was dazu 
erzähle, konkrete Projekte ergeben sich daraus aber eher nicht so wie 
ich mir das erhofft hatte...

[Peter (Gast)]

Hallo Rudolph,

ich arbeite konkret damit und bin Dir für Deine Arbeit dankbar :-)

Habe mir noch eine FT8_cmd_execute() Variante ohne wait gemacht, weil 
dann der Controller auch anderes erledigen kann statt Däumchen zu drehen 
während er auf ein gesetztes Bit wartet nur um sauber abzuschliessen. 
Die Busy-Prüfung mache ich dann beim nächsten Eröffnungskommando, dh. 
wenn ich den Bildschirm neu aufbaue.
Ansonsten funzt die Lib sehr stabil, mach auch kleine Animationen damit 
(durch Bilder umschalten).

Gute Arbeit!

Viele Grüße
Peter

[Rudolph R. (rudolph)]

Hallo,

ich habe gerade eine FT8_cmd_start() Funktion implementiert die nicht 
wartet und mit der die Liste nach einem größeren Update aktualisiert 
werden kann.
Naja, eigentlich habe ich alles bis auf das busy() aus FT8_cmd_execute() 
in FT8_cmd_start() verschoben und FT8_cmd_execute() ruft jetzt 
FT8_cmd_start() auf und busy().

Vielen Dank für den Hinweis, keine Ahnung wie ich das übersehen habe.
Ich hatte zwar mal geprüft wie lange die Ausführung von einigen 
Kommandos so dauert, aber nicht für das Update der grossen Liste.

In meiner Test-Version die ich über einen Timer mit eifachem Profiling 
versehen habe geht die Zeit von 2600µs auf 1900µs zurück, der FT811 der 
in diesem Display ist braucht also 700µs alleine nur um dieses 
Bildschirm-Update zu verarbeiten, sehr nice, schlapp 27% der Zeit hat 
die Funktion also noch sinnlos den Controller blockiert.

Darf ich fragen, was Du damit machst, mit welchem Display und welchem 
Controller?

Ich nutze das hauptsächlich beruflich, da ich das alles aber in meiner 
Freizeit entwickelt habe auf privat gekaufter Hardware und es dann in 
den Job eingebracht habe um Projekte zu starten, habe ich mir halt auch 
erlaubt das zu veröffentlichen.
Nur hatte ich damit bisher weniger Projekte als erhofft.

[pgue (Gast)]

Hallo Rudolph und Experten,

ist das Thema abgeschlossen oder bietet sich die Chance noch paar Fragen 
anzuschließen ?

Ein gutes 3/4 Jahr zu diesem Thema und echt viele Erkenntnisse. Ich gehe 
zwar einen etwas anderen Weg, habe aber immer mal paar grundsätzliche 
Probleme.

Zu meinem Projekt: Ich benutze (noch) den FT800 und als Host einen 
pobligen PIC (18F2550, low cost!). Programmiert habe ich ausschließlich 
in asm, um mir die Kosten für einen brauchbaren C-Compiler für den PIC 
zu sparen (die free-Version von Microchip ist zu schlecht, die Liz. 
unerschwinglich teuer). Mittlerweile ist genug implementiert, dass ich 
meine Oberflächen nur noch mit dem FTDI Screen Editor entwerfe, das 
Ergebnis als .proj-Datei mit einem "Code-Generator" zu Assembler-Code 
für den Pic umsetze. Der Code-Generator liefert mir Include-Files, die 
einfach in die Applikation includiert werden. Um die Bilder auch in der 
App ändern zu können werden vom Code-Generator Funktionen generiert, mit 
denen der Bildinhalt verändert werden kann. Ist zwar alles noch nicht 
fertig, aber geht  soweit ganz ordentlich. Eine expliz. Library verwende 
ich nicht, sie ist quasi Bestandteil des Appl.Bodys (jede Menge simple 
Funktionen). Diese Grundfunktionen schreiben in einen Ring-Buffer 
Display-Adresse und Daten, die zum FT800 über die SSP-Schnittstelle 
übertragen werden. Und zwar nur dann, wenn am Bild sich etwas ändert 
(die Daten werden direkt in die DisplayListe des FT800 geschrieben).

Nun aber zu meinem (ungelösten) Problem: Zwar bekomme ich mit schöner 
Regelmäßigkeit einen INT_TOUCH und INT_TAG Interrupt, wenn ich aber das 
REG_TOUCH_TAG Rgister auslese, bekomme ich nur 0x00 Resultate. Den 
INT_TAG bekomme ich (korrekt) immer dann, wenn ich auch die deklarierten 
TAG's touche. Dazu  als Auszug vom Screen-Editor:

CLEAR_COLOR_RGB(0,0,48)
CLEAR(1, 1, 1)
CMD_TEXT(80, 50, 25, 0, "Auswahl Anwendung")
CMD_TEXT(5, 250, 21, 0, "@ Bla Bla")
CMD_FGCOLOR(0x700000)
TAG(12)
TAG_MASK(1)
CMD_BUTTON(360, 200, 70, 35, 27, 0, "OFF")
TAG_MASK(0)
CMD_FGCOLOR(0x003000)
TAG(13)
TAG_MASK(1)
COLOR_A(0)
BEGIN(RECTS)
VERTEX2II(40, 130, 0, 0)
VERTEX2II(230, 170, 0, 0)
END()
COLOR_A(255)
CMD_BUTTON(40, 130, 190, 40, 27, 0, "PedelecMonitor")
TAG_MASK(0)
TAG(14)
TAG_MASK(1)
CMD_BUTTON(245, 130, 190, 40, 27, 0, "WindRichtungsMesser")
TAG_MASK(0)
DISPLAY()
(Das Bild ist auf dem Screen, der Assembler-Code dazu ist zu 
umfangreich, um ihn hier zu zitieren ! Könnte aber die 
gesendeten/empfangenen Daten ggf. für paar -welche?- Kommandos hier 
zitieren, wenn's wem nutzt)

Übrigens: Der Code-Gen. liefert mir auch C++ Code, mit dem kann ich mit 
meinem Lapi auch testen (FTDI USB/SPI Kabel direkt zwischen Lapi und 
Display, Glyn/Adam Display). Auch da gibt es keine TAG-Werte, ausser 
0xFF oder 0x00.

Wer verrät mir, warum dieses wunderbare Wunder ? Sonst wird das einfache 
Bild korrekt angezeigt, auch die XY-Touch-Position wird korrekt 
ausgelesen, nur der TAG-Wert nicht !

Bitte HILFE :-((
Gruss pgue

[pgue (Gast)]

Hallo liebe Leute

die Ursache ist gefunden :-)
Fehler: Y_HIGH (BIT20) in VERTEX2II nicht richtig gesetzt !!!

Also:
INT_TAG -> read REG_TOUCH_TAG: REG_TOUCH_TAG value = TAG value
danach
INT_TAG -> read REG_TOUCH_TAG: REG_TOUCH_TAG value = 0x00

ansonsten wenn irgendwo getoucht wrd:
INT_TAG -> read REG_TOUCH_TAG: REG_TOUCH_TAG value = 0xFF

(alles im PIC getestet)

Gruss pgue

[Rudolph R. (rudolph)]

Das Thema ist für mich noch nicht abgeschlossen, ich hoffe gerade wieder 
auf das nächste Projekt dazu.
Aber zum Interrupt kann ich nichts sagen, ich habe die Interrupt-Leitung 
nicht mal angeschlossen, ich polle einfach nur.
Meine Display-Funktion wird alle 10ms aufgerufen. Abwechselnd wird darin 
entweder das Bild aktualisiert oder Touch abgefragt.
Also 50 Bilder pro Sekunde und 50 Abfragen pro Sekunde.

Bisher hat sich das so bewährt, obwohl das tendenziell auch weniger 
Bilder pro Sekunde und mehr Abfragen pro Sekunde sein könnten.
Nur ist das Feedback eh visuell, 120 Abfragen pro Sekunde führen bei 30 
FPS zu keinem schnelleren Feedback.

Mit dem doch recht aufwendigen Test-Projekt bin ich so bei 1900µs für 
ein Bild. Also reserviere ich grade rund 20% Laufzeit für das TFT.
Da kann man aber nicht meckern wenn man bedenkt, dass das 800x480 in 50 
FPS aus einem 16 MHz AVR sind. :-)
Den statischen Teil der Anzeige halte ich dabei im Speicher vom FT813.
Wenn mein SPI schneller wäre würde die Zeit ausserdem verkürzt werden.
In den echten Anwendugen die ich bisher hatte war die Zeit für ein Bild 
sehr viel kürzer, weil der dynamische Teil der Anzeige auch viel kürzer 
war.

Interrupt-gesteuert und nur Änderungen darstellen macht den Aufwand 
etwas schwerer abzuschätzen.
Ich weiss jetzt, dass ich 7+ms Rechenzeit habe um was anderes zu machen, 
und zwar alle 10ms, da könnte ich mich anders nicht unbedingt drauf 
verlassen.
Wenn das nicht mehr reichen sollte würde ich ernsthaft überlegen das 
anders zu machen.

Oh, Du musst bei Interrupts auch aufpassen das die Bildwechsel nicht zu 
schnell aufeinander folgen. Mehr als 60 Hz mögen die FT8xx nicht.

[Robi (Gast)]

Hallo, ich habe mit dem FT8xx vor 2 Jahren ein Projekt (MP3-Player) 
begonnen und meine eigene Lib dazu geschrieben. Meine Hardware besteht 
aus
PIC18F67J50, FT810, VS1053B und Display 3.5" mit 320x480 und MicroSD bis 
max.
64GB. Die FAT32 Lib ist von Elm-chan (FATFS).
Compiler: Mikroe mikroC PRO for PIC. Das Gehäuse habe ich drucken 
lassen.

Gruss

[Rudolph R. (rudolph)]

Ich bin nicht sicher, was Du uns damit in diesem Thread mitteilen 
möchtest.

[Robi (Gast)]

Dachte du sucht nach einem Projekt.
Gruss

[Rudolph R. (rudolph)]

Ah okay, danke für den Vorschlag.
Einfach so zum Spass hätte ich da schon das eine oder andere.
Aber auch schon genug anderes was nicht fertig wird. :-)
So speziall nach einem 3,5" oder kliner mit FT811/FT813 könnte ich mal 
schauen.

Ich nutze die Teile im Job, ich hoffe also darauf das mich mal wieder 
jemand dafür bezahlt das ich ihm was schick visualisiere.
Macht schon was her wenn man für den Prüfstand ein 7" TFT hat.
Ein Kunde hat zum Beispiel für einen Komponententest so ein Teil von uns 
bekommen bei der auf der vebauten Platine noch eine CAN 
Restbus-Simulation lief.
Naja, mein Markt dafür ist etwas begrenzt.

Die Teile sind schon toll, aber gefühlt nehmen die gar keine Fahrt auf.
Mit dem Wechsel von FTDI zu Bridgetek ist nicht mal die Doku besser 
geworden,
geschweige denn, dass da mal was von FT82x zu sehen wäre.
Das Cleo Forum ist auch praktisch tot.

Fairerweise muss man aber auch sagen, TFTs sind keine Commodity Items 
wie 16x2 Text-Displays. Die werden nicht einfach als Standard-Ware auf 
Halde produziert.
Bei den kleinen größen bis vielleicht 3,5" kommt inzwischen auch noch 
die Konkurrenz durch die billigen Chinesischen TFTs dazu.
Die spielen zwar nicht mal ansatzweise in der gleichen Leistungs-Klasse, 
dazu fällt mir nicht mal ein schlechter Vergleich ein, aber hauptsache 
billig.

[Manfred W. (manfred53)]

Hallo Rudolf und andere FT810 Freunde

ich setze den FT811CB von Watterott ein und habe nach einem 
erfolgreichen Start jetzt plötzlich Probleme mit sporadischen Flackern 
und falschen Touch Werten.

Zum Umfeld: ArduinoMega 2560, SPI an FT811 und an SD Karte, I2C an RTC, 
Servo PWM und TIC Stepper Controller, .

Das ganz soll eine Steuerung für einen Vapor Phase Reflow Ofen werden 
(Umbau eines IMDES Ofens)

Refresh und Auslesen Touch erfolgt mit 10 Hz, also eigentlich nicht zu 
schnell. Aussetzer unabhängig vom Bild Inhalt Auch wenn nur 5 Knöpfe und 
zwei Texte gezeichnet werden.

Ich lasse in der Loop im Sekundentakt Pin13 toggeln als "Lebenszeichen". 
Dieses stockt auch manchmal und der Prozessor hängt.

Hatte sogar mehrmals den eingebauten FTDI Screen.

Verwende im Großen und Ganzen Rudolfs Lib. Um optische Feedback für 
Knöpf zu erhalten werden die CMD Befehle stets wiederholt.

Hat jemand Ähnliches beobachten können oder eine Idee was nicht korrekt 
sein könnte?

[Rudolph R. (rudolph)]

Flackern hatte ich schon lange nicht mehr, kam eigentlich auch nur bei 
zu schnellen Updates.

Da hilft wohl erstmal nur alles andere abzuschalten und nach und nach
dazu zu packen.
Es gibt zum Beispiel auch SD-Karten Module die den SPI falsch bedienen.

[Manfred W. (manfred53)]

[solved]

Es war wohl die Standard Arduino SPI Bibliothek.

Ich habe für die Ansteuerung des FT811 eine direkt auf die benutzen 
Ports gehende Software SPI Lösung geschaffen und jetzt läuft's ohne 
flackern und
verwendet 5 nebeneinander liegende Ports 3 bis 7.

[Rudolph R. (rudolph)]

Also die Standard SPI Lib habe ich auch schon benutzt, von einem 
pro-mini aus, das sollte eigentlich soweit kein Problem sein.

[Juergen (Gast)]

Hallo Freunde,

erstmal auch recht Herzlichen Dank an Rudolf für den sehr verständlichen 
Code, der so einiges Licht ins Dunkle gebracht hat..

Habe derzeit ein Projekt mit einen FT813. Nun muss ich eine kleine 
Videosequenz darstellen können und möchte hierzu ein AVI-Video abspielen 
können.

Gibt es ein Code-Beispiel, AVI-Videos über den Media-Fifo abzuspielen?

Juergen

[Rudolph R. (rudolph)]

FTDI hat ja ein Beispiel dafür, oder gar zwei, nicht, dass ich aus dem 
Code den FTDI so verzapft wirklich schlau werden würde. :-)
Aber an dem beigefügten Video sieht man schon mal, dass Format dafür ist 
relativ exotisch.

Na, Media-FIFO an den Start bringen und dann irgendwas machen mit 
CMD_PLAYVIDEO, CMD_VIDEOSTART und CMD_VIDEOFRAME. :-)

Nein, ernsthaft, damit habe ich noch gar nicht gespielt, diese 
Funktionalität geht mir dann doch zu weit.
Und neben der schwachen Beschreibung dazu sieht das auch noch so aus das 
die Geschichte über das Video-Format eingeschränkt ist.
MJPEG ist jetzt nicht so prall für Videos, wenn ich das richtig verstehe 
ist das quasi ein JPEG nach dem anderen, also immer volle Frames.
Das frisst Speicher ohne Ende, die Daten muss man erstmal anständig von 
einer SD-Karte und in den FT813 schaufeln können.
Im Gegensatz zu DIVX und anderen Codecs die nur immer mal wieder einen 
kompletten Frame im Stream haben und dazwischen Differenz-Daten.

Also ich würde mir höchstens eine kurze Animation aus Einzel-Bildern 
schnitzen, dafür brauche ich kein Video-Playback.

Eine andere Sache ist, ich verzichte bewusst auf Massen-Speicher am 
Display, der Fokus liegt für mich darauf das einfach zu halten.
Also liegen meine Bild-Daten auch komplett im Controller.
Selbst ein kurzes Video geht Ruckzuck über 10MB.

[Rudolph (Gast)]

Oha, es gibt wohl was neues: BT815.
Der wird nächste Woche auf der Embedded-World vorgestellt, ich bin 
gespannt.

[GrzegorzK (Gast)]

Hello, I am looking for a library for FT813 to nucleo STM32, MBED 
compiler. Could you help me?.
I use Arduino_Riverdi_TFT_shield_Rev.1.2 and Nucleo STM32F103RBT6

https://www.unisystem.pl/pl/products/development-kit/arduino-riverdi-tft-shield.html

best regards
Grzegorz

[Rudolph R. (rudolph)]

Well, I can not directly help you but it should be pretty easy to adapt 
my code-library to your needs.
That "mbed compiler" should be GCC anyways.

Take a look at FT8_config.c and FT8_config.h.
Only these two carry plattform specific code.
The target the code is compiled for is identified by defines that are 
set by the build enviroment such as "__GNUC__".
You need to look for a define like "__STM32__" or similar and add new 
sections like with the two examples provided.

The "__AVR__" and "__v851__" parts I provided show what could be done.
More clean in the AVR part where you only need to edit the .h, more 
direct in the V851 part where you would need to edit the .c to adapt the 
code to a different board.

Also your code has to provide proper initialisation of the port-pins and 
the SPI, I did not include that at all as I consider it part of main.c.

The clock of the SPI must be below 11 MHz during init of the display.
After init it can be as high as 30MHz but I doubt that will work with a 
setup like this where the signals go thru an Arduino shield.

Note that my code does a busy-wait for the SPI transfers to be complete.
This is not so bad for the AVR since that are only 16 clock-cycles with 
8MHz SPI clock and 16MHz system-clock.
Even with the rather low-end STM32F103 things are a bit different.
The function spi_transmit() could be changed to write to a memory-buffer 
and FT8_cs_clear() could trigger a DMA transfer of that buffer.
FT8_cs_set() could be used to ensure that the buffer is already 
transfered.
The function spi_receive() is then a problem to solve though, I guess it 
could be possible to let it call spi_transmit()/FT8_cs_clear() to 
trigger a transfer of just one byte, read the result and write that 
back.

Does the STM32 support 32 bit SPI transfers?
I only recently checked what a SAME51 can do and regardless of it having 
a Cortex-M4F core it can only do 8/9 bit SPI transfers.
That could be used to speed things up but this would require a complete 
re-write of FT8_commands.c.

The display and type of FT8xx also has to be selected in FT8_config.h.
You did not say which display from Riverdi you use.
I only have a profile for RVT70AQxxxxxx so far, if you do not use one of 
these you need to use one of the other profiles and tweek it, best would 
be to copy one of the blocks under a a new name.

And as always, please share the bits and pieces you need to adapt the 
library to your needs so that I could include it into the repository.
Sadly no-one contributed so far and most of my questions are left open.

[Rudolph R. (rudolph)]

Part of the documentation for the new BT815 is up: 
http://brtchip.com/bt815-6/

It's all a bit thin by now, the programming guide is yet to be updated.

-Support Adaptive Scalable Texture Compression (ASTC) format to save 
considerable memory space for larger fonts and graphics images
-Support external QSPI NOR flash to fetch graphic elements(image, font, 
widget etc)

And that is all what is different to the FT81x series, at least for now.
The programmers guide should reveal some more things.

I had a nice talk at the Embedded World earlier today with a guy from 
Bridgetek and say a few demos at their booth.
One additional feature would be support for Unicode fonts thru an 
additional font command.

And I had some more nice talks but I have to wait a little to see how 
these turn out. :-)

[Walter L. (Gast)]

Hallo,
bevor ich Geld ausgebe:

Eignet sich das VM800C50A ( FT800) für die Darstellung von Messwerten 
über der Zeit (z. B. zwei Temperaturen, zwei rel. Feuchte-Werte über 12 
Stunden)?
Kann man direkt in das RAM_G schreiben, um Pixel zu setzen und somit 
die Messwerte darzustellen?
Bisher benutze ich ein 2,8 ZOLL TFT, parallel, mit IL9341, das mir aber 
zu klein ist.
Danke für Hinweise.
VG Walter

[pedrem (Gast)]

Hallo
Ich spreche kein Deutsch und diese Übersetzung ist Google.
Ich entschuldige mich vor allem.
Ich änderte den ATMEGA644-Mikrocontroller-Code zu ATMEGA328.
Die Show findet statt, aber das Bild ist fehlerhaft. Die Seite wird 
aktualisiert und ist nicht klar.
Was denkst du ist das Problem?
Vielen Dank

[pedrem (Gast)]

pedrem schrieb:
> Hallo
> Ich spreche kein Deutsch und diese Übersetzung ist Google.
> Ich entschuldige mich vor allem.
> Ich änderte den ATMEGA644-Mikrocontroller-Code zu ATMEGA328.
> Die Show findet statt, aber das Bild ist fehlerhaft. Die Seite wird
> aktualisiert und ist nicht klar.
> Was denkst du ist das Problem?
> Vielen Dank

[Manfred W. (manfred53)]

Walter L. schrieb:
> Hallo,
> bevor ich Geld ausgebe:
>
> Eignet sich das VM800C50A ( FT800) für die Darstellung von Messwerten
> über der Zeit (z. B. zwei Temperaturen, zwei rel. Feuchte-Werte über 12
> Stunden)?

Ja, sogar mit 800x480 Auflösung für unter 40€ (FT811CB von HAOYU)

> Kann man direkt in das RAM_G schreiben, um Pixel zu setzen und somit
> die Messwerte darstellen?

Das sollte man nicht tun sondern die vielen vorhandenen Funktionen 
nutzen, die ein schön gerendertes und nicht pixeliges Bild ergeben. 
Anbei ein Beispiel.

[Rudolph R. (rudolph)]

Was geht denn hier ab? :-)

Walter L. schrieb:
> Kann man direkt in das RAM_G schreiben, um Pixel zu setzen und somit
> die Messwerte darzustellen?

Das geht zwar, die FT8xx arbeiten allerdings eher Objekt-orientiert und 
nicht Pixel-für-Pixel.
Eine Messwert-Reihe kann man zum Beispiel als Linien-Zug ausgeben.
Meine Beispiel-Applikation macht sowas mit einem festen Array aus 64 
Werten.

command(farbe)
command(linien-breite)
command(starte line-strip)
command(koordinate(x,y))
command(koordinate(x,y))
command(koordinate(x,y))
command(koordinate(x,y))
command(ende)

Und schon hat man drei Linien auf dem Schirm.

Was ich allerdings feststellen musste, dynamische Koordinaten-Kommandos 
kosten etwas Zeit, zumindest auf kleinen 8-Bit Controllern, aus den X/Y 
Werten einen 32 Bit Wert zu machen ist ein wenig aufwendig.

Ich habe mich da drüber bei FTDI gestern "beschwert", bin aber nicht 
sicher, ob das so angekommen ist, so im Gespräch auf Englisch. :-)

Naja, dürfte immer noch um mehrere Grössenordnungen schneller sein als 
komplette Linien zu berechnen und Pixel-für-Pixel zu übertragen, an 
Anti-Aliasing wäre da auch nicht zu denken.

Die FT8xx sind vor allem schnell und Resourcen-freundlich. Eindrucksvoll 
sieht man das auch an den Gameduino Demos.
Aber eben wenn man die auch machen lässt. :-)



pedrem schrieb:
> Ich spreche kein Deutsch und diese Übersetzung ist Google.

Please don't. Just use Englisch instead.
You could attach the source-code you modified that would be a bit 
easier.
As well as telling what display that actually is.
However, the code you used is rather old.
Please check out a current version here:
https://github.com/RudolphRiedel/FT800-FT813

The provided example projects are not updated to the latest versions of 
the
files but should do fine after an update.

The "90CAN" example should be a good starting point.

One thing, in FT8_config.c

  uint8_t fetch_flash_byte(const uint8_t *data)
  {
    return(pgm_read_byte_far(data));
}

That should be "pgm_read_byte(data)" for any AVR with 64k of FLASH or 
less.
Hmm, it should be possible to auto-detect that during compilation but I 
did not try that so far.

[Manfred W. (manfred53)]

Nicht unerwähnt bleiben sollte, dass das, was man "malt" also die 
commands, nicht unbegrenzt ist.
Daher stößt man bei langen Vektorzügen schnell and die Grenze. Ich 
sammele 600 Messpunkte für ein 10 Minuten Log.

Aber da gibt es Abhilfe.

Man zeichnet zunächst den statischen Teil seiner Graphik und kopiert das 
Ergebnis in einem RAM Bereich des FT8xx.

void SaveRTL()
{
        FT8Snapshot2(FT8_ARGB4, 10000L, 0, 44, RTLWIDTH, RTLHEIGHT);
}

Dann ruft man diese Hintergrundgraphik mit wenigen Commands auf und kann 
dann wieder mit etwas mehr Luft darüber malen.

void RestoreRTL()
{
  FT8Cmd(COLOR_UINT(White));
  FT8DrawRect(0, 44, RTLWIDTH, RTLHEIGHT, White);
  FT8SetBitmap(10000L, FT8_ARGB4, RTLWIDTH, RTLHEIGHT);
  FT8Cmd(BEGIN(FT8_BITMAPS));
  FT8Cmd(VERTEX2II(0, 44, 0, 0));
}

RTL ist meine Abkürzung für die Reflow-Temperatur-Log Graphik.

Beim Zeichnen der beiden Kurven zeichne ich live nur die letzten 5 
Sekunden "punktgenau". Der Rest wird im 5 Sekunden Abstand gezeichnet, 
was zu 120 Vektoren führt.

[Walter L. (Gast)]

Hallo Manfred und Rudolph,
herzlichen Dank für Eure Hinweise.
Ich hatte das schon geahnt, dass für meine Zwecke die Controller mit 16 
Bit-Interface besser geeignet sind (z.B. SSD1963, o. ILI9341).
VG Walter

[Manfred W. (manfred53)]

Walter L. schrieb:
> Hallo Manfred und Rudolph,
> herzlichen Dank für Eure Hinweise.
> Ich hatte das schon geahnt, dass für meine Zwecke die Controller mit 16
> Bit-Interface besser geeignet sind (z.B. SSD1963, o. ILI9341).
> VG Walter

Das kann ich absolut nicht teilen!


Ich arbeite kommerziell seit vielen Jahren mit ATMEL 8 Bit Prozessoren 
vom Mega8 bis zum Mega2560.
Früher mit AVR-Pascal & Assembler jetzt mit Arduino/Visual Studio mit 
VisualMicro.


Es kommt immer darauf an, was man machen will.


Man darf 8 Bit nicht verallgemeinern. Einen 8bit PIC und einen ATMEGA 
trennen Performance Welten. Nicht umsonst findet man in vielen CNC und 
3D Drucker Steuerungen ATMEL Prozessoren.

Parallel dazu programmiere ich übrigens auch 16 Bit (PIC24F256GB206 
32Mhz) in einer WiFi IoT Anwendung (FlyPort Pro) mit über I2C und SPI 
angeschlossenen Sensoren. Hier musste ich nach langen Fehlversuchen, es 
mit dem PIC24 alleine zu schaffen, einen extra ATMEL Mega8 spendieren, 
um ein Timing kritisches Signal zur Ansteuerung von 350 WS2812 RGB LEDs 
zu produzieren.

Wichtig ist die richtige Bibliothek zu finden.


Hier (FT8x) hat Rudolf eine exzellente Vorlage geschaffen, für die ich 
Ihm meinen Dank aussprechen möchte!

[Walter L. (Gast)]

Hallo Manfred,

ich schrieb vom TFT-Controller, nicht von dem Controller, der das TFT 
ansteuert.

Als ansteuernder Controller kommt der TSM320F2806x zum Einsatz.

Soweit ich Deine "REFLOW"-Graphik verstanden habe, sind die Messwerte 
zunächst erfasst worden und danach ist die "REFLOW"-Grafik erstellt 
worden.
Ich brauche aber eine "Oszilloskop-Funktion".

VG Walter

P.S.: Auch von meiner Seite ein herzliches Danke an Rudolf für die 
exzellente Vorlage.

[Manfred W. (manfred53)]

Walter:

Ich brauche aber eine "Oszilloskop-Funktion".

Um es vorweg zu nehmen: Bosch... ist schon möglich!

Der FT811 ist ein "intelligenter" TFT Controller mit Objektorientiertem 
Graphik Modell nicht nur Linien, Rechtecke, Polygone, Bitmaps sondern 
auch UI Objekte wie Knöpfe, Texte, Schalter, u.m.. Diese werden im 
Aufruf mit einer Zahl (0..255) zur Identifikation (Tag genannt) 
versehen.

Dabei kann das "Bild" mit bis 60 Hz vom steuernden MC in der üblichen 
Loop refreshed werden und gleichzeitig wird der oben genannte Tag bei 
einer eventuellen Touch Positionen als OBJEKT Referenz geliefert. Damit 
kann man sehr einfach "Klick Ereignisse" produzieren.

Das der FT811 hervorragend live rendert kann man an meinem Screenshot 
sicher erkennen.

Mit der von mir beschrieben Bitmaps Hintergrundmethode kann man dass 
Messraster schnell pro Frame laden und dann die Kurve darüber legen. So 
mache ich das in dem in Entwicklung befindlichen Reflow Controller bei 
dem auch blinkende und Farben wechselnde Texte und Knöpfe vorkommen.

Ich empfehle mal sich die diversen Videos zum FT8x und dem damit 
realisierten Gamduino anzuschauen.

[Rudolph R. (rudolph)]

Manfred W. schrieb:
> Hier (FT8x) hat Rudolf eine exzellente Vorlage geschaffen, für die ich
> Ihm meinen Dank aussprechen möchte!

Walter L. schrieb:
> P.S.: Auch von meiner Seite ein herzliches Danke an Rudolf für die
> exzellente Vorlage.

Danke!
Das Feedback die letzte Zeit war ganz schön positiv. :-)

Interessant war auch mein Besuch der Embedded World.
Ob nun am Stand von FTDI/Bridgetek, Matrix Orbital oder Glyn, die 
Herrschaften waren positiv überrascht als ich ihnen erzählt habe das ich 
eine FT8xx Library auf Github eingestellt habe.
Obwohl ich mich schon über zwei Jahre damit beschäftige und der Thread 
hier auch fast zwei Jahre alt ist, einfach so im Netz drüber stolpern 
ist wohl nicht so leicht.
Mal schauen, ob der Firmen-Kontakt die User-Basis etwas hoch bringt. :-)

Weil ich da gerade Bock drauf hatte habe ich heute mal ein bisschen was 
gemacht und https://github.com/RudolphRiedel/FT800-FT813 aktualisiert.
Nichts tiefgreifendes.
Die Support-Funktionen habe ich auf Inlining umgestellt und somit ist 
FT8_config.c verschwunden, das ist messbar schneller.
Weil ich diese Kombination gerade hier habe gibt es jetzt noch ein 
Beispiel Projekt "FT8xx_Test_90CAN_FT811_HY50HD".
Da hatte ich schon länger das Inlining drin und auch simples Profiling 
für die tft_loop(), das habe ich jetzt mal Release fähig gemacht.
Die anderen beiden Beispiel-Projekte habe ich auch mal auf den aktuellen 
Stand gebracht.
Und da ich FT8_config.h sowieso schon auf hatte, habe ich mal die ganzen 
Konfigurationen für die Matrix Orbital TFTs ergänzt.

Und ja, ich weiss, dass ich mich mit Github nicht hinreichend gut 
auskenne. :-)
Aber das sind ja im Grunde genommen nur vier Dateien und jede davon hat 
einen Header mit Versions-Nummer und Änderungen.

Ich hatte auch überlegt schon was für den BT815 einzubauen. Aber nur das 
Vorläufige Datenblatt ist mir dafür noch zu dünn. Ich weiss schon, dass 
das Teil mehr kann als da drin steht, schauen wir mal wann das 
User-Manual kommt und wann überhaupt Hardware verfügbar wird.

[Walter L. (Gast)]

Hallo,

Frage an die mit dem THAOYU FT811CB bewanderten Fachmenschen:
Auf der linken Seite des PCB befindet sich zwischen zwei 
Kreutzschlitzschrauben der 7-pinnige P1 Anschluss.
Wozu ist dieser? Vermutliche der Anschluss zum TOUCH-CONTROLLER.

Kennt jemand die PIN-Belegung?

Danke für Hinweise.

VG Walter

P.S.: In den Schaltplänen habe ich nichts gefunden.

[Manfred W. (manfred53)]

Ja, im bekannten FT81xCB_SCH.pdf ist P1 nicht zu finden.

Aber was soll's?

Über J2 oder, wer den Adapter hat, über J1 ist alles verfügbar, was man 
so braucht.
Auf den INT kann man eigentlich verzichten, wenn man in der Loop das 
FT8GetTouchTag() ausführt.

Für den "Sound" auf AUDIO PWM braucht man noch einen Tiefpass nebst 
Verstärker und Pin 10 Gnd ist auf der PCB mit PIN 2 verbunden.

[Walter L. (Gast)]

Ohne Gewähr:

pin 7 NC      -> FT5206GE1
pin 6 INT
pin 5 WAKE
pin 4 MISO
pin 3 SSEL/SCL
pin 2 GND
pin 1 VDD3

pin1 = quadratisch

VG Walter

[Rudolph R. (rudolph)]

Walter L. schrieb:
> Auf der linken Seite des PCB befindet sich zwischen zwei
> Kreutzschlitzschrauben der 7-pinnige P1 Anschluss.
> Wozu ist dieser? Vermutliche der Anschluss zum TOUCH-CONTROLLER.

Oh, der ist mir noch gar nicht aufgefallen, die anderen aus der Serie 
haben den auch nicht.

http://www.haoyuelectronics.com/Attachment/FT811CB-HY50HD/FT811CB-4.jpg

Also dem Bild nach würde ich auch sagen, der ist nur mit dem 
Touch-Controller verbunden, vielleicht sowas wie ein Test-Zugang.
Mein erster Reflex war jetzt auch das Gehäuse aufzuschrauben in dem ich 
das Display hier rum liegen habe, aber dafür lohnt sich das irgendwie 
nicht. :-)

Edit: Beitrag zu lange offen gehabt Fehler. :-)

Vorhin habe ich eine EMail von Glyn bekommen, die ADAM Module gibt es 
auch immer noch.
Ich wüsste jetzt zwar nicht, wie ich da privat rankommen könnte und auch 
im B2B ist das nicht einfach Katalog-Ware.
Aber ich finds erstmal gut, dass es die auch noch gibt.

[Rudolph R. (rudolph)]

Minor update of FT8_config.h.
- Arduino for ESP8266 has a spi.write() function, plain Arduino only has 
a spi.transmit() function - the correct function is used automatically 
now.
- AVR with more than 64kB are auto-detected now and pgm_read_byte_far() 
is used instead of pgm_read_byte_near().

[Rudolph (Gast)]

Neues Spielzeug. :-)

Läuft gerade so zum ersten Mal, das sind 10,1" mit 1024x600 Pixeln.
Kapazitiv-Touch natürlich, die Schutzfolie ist auch noch drauf.
Da klemmt gerade ein Wattuino Uno hinter - #oberfettestftshield :-)

Wie man gerade so auf dem Bild erkennen kann sind das 588 Bytes die pro 
Bild auf dem SPI übertragen werden und ein Frame dauert da gerade 2,9ms.
Der SPI läuft dabei auf nur 4MHz.
Ich lasse das Bild gerade 33 Mal pro Sekunde neu ausgeben.

[Rudolph R. (rudolph)]

Was, niemand der fragt was für ein Display das ist? Ich bin enttäuscht. 
:-)

Das ist ein ADAM101-LCP-SWVGA-NEW von der Firma Glyn.
Da ich die Freigabe dafür habe und das sonst noch nicht zu finden ist 
hänge das Datenblatt dazu einfach mal hier an.

Ich wüsste jetzt nicht ob ich da privat überhaupt rankommen könnte, das 
ist jetzt von der Arbeit aus beschafft für die Arbeit.
Und die kosten jetzt auch etwas mehr als ich privat bereit wäre 
auszugeben.

Wie man auf der ersten Seite im Datenblatt erkennen kann verfügt das 
Display auf der Platine über einen kompletten Satz Pins für einen 
Arduino.
Da ist aber auch der bei Glyn EVE Displays übliche 16polige FPC 
Anschluss drauf.

Man kann in etwa erahnen wie gross das Teil ist wenn man sich überlegt, 
dass der Arduino nicht über die Platine hinaus ragt.

Zum Testen benutze ich das jetzt auch erstmal als Arduino-Shield.
Da ich keine Hardware für den 16pol FPC habe, weil ich bisher eben auch 
kein Display von Glyn in die Finger bekommen konnte, war das schlicht 
der einfachste Weg das Monster in Betrieb zu nehmen.
Das hätte mich jetzt auch nur 10 Minuten aufgehalten wenn ich ncht einen 
Fehler in meinen aktuellen Arduino Beispiel-Code eingebaut hätte der den 
SPI gekillt hat.

Im Github liegt auch schon die aktualisierte FT8_config.h.

Was technisches noch, mit 6V Versorgung und ungefähr 70% 
Hintergrundbeleuchtung zieht der Aufbau knapp unter 400mA.
Das ist jetzt deutlich weniger als ich erwartet habe.
Ermittelt mit der Strombegrenzung von meinem Labor-Netzteil muss die 
Versorgung aber auch mindestens 1A liefern können damit das sauber 
anläuft - da ist eben ein Schaltregler drauf, und auf dem Panel selber 
sitzt noch einer für die Beleuchtung.

[Rudolph R. (rudolph)]

Okay, something for a wider audience, so in Englisch.

I already mentioned above that I visited the booth of Matrix Orbital at 
Embedded World in Nürnberg. https://www.matrixorbital.com
Last week I received two of their modules which they provided as samples 
for me to play with.
https://www.matrixorbital.com/ftdi-eve/EVE%20FT812/eve2-38a
https://www.matrixorbital.com/ftdi-eve/EVE%20FT812/eve2-35g

I chose the EVE2-38 for its form-factor.
At 480x116 and 1U it is sawn out of a 4.3" TFT.
I did not have anything like this in my collection.
The only thing that perplexed me was that the panel actually is the 
lower half of that 4.3", so it does not start at 0/0 but 0/155.

The EVE2-35G is annother story.
First of I have an application for it but it is way too soon to tell.
This is a very nice panel, from the looks and feel very much like the 
RVT70 module from Riverdi I worked with before.
So it has an all glas front and tape on the back to glue it into a case.
I very much like that, this makes using TFTs so much easier than using 
this naked panels with metal-frame.
I dare to say that I believe that the EVE2-35G looks better than the 
RVT70, it maybe has a higher viewing-angle and the backlight definately 
is brighter.
Unfortunately I do not have a 3.5 from Riverdi for a fair comparision.

Both modules come with FT81x, namely FT812 and FT813, Matrix Orbital 
does not use FT80x for any of their modules which I also like a lot.
So the EVE2-35G is a 3.5 320x230 TFT with 24 bit color and 1MB of 
object-memory.

I ran into one problem with the EVE2-35G though.
These come with a Goodix GT911 touch-controller and these are not 
suported by the FT813 out-of-the-box.
FTDI/Bridgetek released AN_336 though which I was aware of and it holds 
the solution for this problem.
The FT813 is patched with a binary-blob provided by FTDI/Bridgetek to 
support the GT911.
And yesterday I got this to work.

Check https://github.com/RudolphRiedel/FT800-FT813 for the update.

I also uploaded a much simpler example to play with the EVE2-35G.

[TFTL (Gast)]

Hello from México. Congratulations for visit the Embedded World. Many 
things to see!.

I am very interest in the 10.1 TFT, that you have, it's amazing.

I have a FT813 NHD displays: 3.5", 4.3" y 5" and my teal and I has been 
working on the mod of the gameduino 2/3 library in order to work in 
STM32 boards like F746IG (Core7XXI) or the new nucleo-F767.

Congratulations for two years of EVE-fan life!

Our project: ft81xmania.com

[Rudolph R. (rudolph)]

TFTL schrieb:
> I am very interest in the 10.1 TFT, that you have, it's amazing.

It's big, it's bright and the panel panel really is much better than the 
RVT70 from Riverdi.
It has a few problems though and I am waiting for a response from Glyn.
I am afraid that if anyone wants one of these he has to contact Glyn and 
ask for a quote.

> I have a FT813 NHD displays: 3.5", 4.3" y 5"

I have seen these online after Embedded World so I totally missed the 
oportunity to visit their booth.
Could not order one of these so far, Digikey is not a real option for me 
and while a co-worker will order at Mouser later this week they have no 
stock.

But I do not like these "naked" TFTs anways.
With the RVT70 or the EVE2-35G you just cut a hole in your case and 
throw the panel in there, with the ADAM101 or all NHD modules you have 
to construct a case around them.
The mounting holes are only a minor improvement.

> and my teal and I has been working on the mod of the gameduino 2/3
> library in order to work in STM32 boards like F746IG (Core7XXI)
> or the new nucleo-F767.
>
> Our project: ft81xmania.com

Yes, I came across that before. :-)
And yes, STM32 is the hype, for whatever reason. There are no automotive 
versions of STM32 however which kept me from playing with them.
At work we just adapted my library for use with Infineon Aurix TC222.

[Rudolph (Gast)]

I felt a picture of the EVE2-35G is missing.

That is my new example code in action.
That button is implemented as radio-button, push once to activate, touch 
a second time to de-activate.
When activated the star picture will rotate, deliberately off-center.

The EVE2-35G is running at almost the lowest possible brightness,
I tuned it down as I have no sunlight at my desk at home. :-)

I just noticed that the whole setup only draws around 50mA.


Below is the EV2-38 and a 2x16 LCD just for reference.

[Axel V. (axel-f)]

Klasse Arbeit, vielen Dank. Und vor allem ist der Code (für mich) sehr 
gut verständlich.

Nun mein Problem: ich verwende den FT812 an einem SAM4S; mußte also die 
SPI ein wenig anpassen. Aber prinzipiell kann man das am Oszi gut 
nachvollziehen.
Die Krux ist, daß die Schaltung zwar aufgeweckt wird, aber dann nicht 
mehr viel passiert.
init:
PIOA->PIO_CODR = PD_FT812;  // PD aktiv
delay_ms(6);
PIOA->PIO_SODR = PD_FT812;  // PD inaktiv
delay_ms(21);
FT8_cmdWrite(FT8_CLKEXT);
FT8_cmdWrite(FT8_ACTIVE);
delay_ms(500);        // TEST
chipid = FT8_memRead8(REG_ID);
while(chipid != 0x7C)
{
  chipid = FT8_memRead8(REG_ID);
  delay_ms(5);
  timeout++;
  if(timeout > 200)
     return 0;
}
delay_ms(10);
return 1;

Das funktioniert soweit, der ext. Quarz wird aktiv, das REG_ID wird 
ordnungsgemäß gelesen (return ==1).
Wenn ich jetzt als einfachen Test  FT8_memWrite8(REG_PWM_DUTY, 70);
absende, passiert nichts, kein PWM aktiv am Backlight. Auch alle anderen 
Initialisierungen bzgl. Display zeigen keine Wirkung. Das einzige, was 
ich noch beobachtet habe, daß nach dem ersten Zugriffnach dem Aufwachen 
(hier:FT8_memRead8(REG_ID)) der Audioausgang mit 117 kHz taktet.

Spannungen sind natürlich nachgemessen.
Ich bin ein bißchen mit meinem Latein am Ende. Hast Du noch einen guten 
Tip, was man versuchen sollte?

Gruß
Axel

[Rudolph R. (rudolph)]

Axel V. schrieb:
> Hast Du noch einen guten Tip, was man versuchen sollte?

Oh, mir fallen da bestimmt ein paar ein. :-)

Als erstes Mal wäre gut zu wissen, welches Display Du überhaupt 
verwendest.
Und dann, warum machst Du die Anpassung an den SAM4S nicht da wo ich das 
vorgesehen habe und zwar in der FT8_config.h? :-)

Mit etwas Hilfe zum SAM4S könnte ich Dir das Beispiel bestimmt soweit 
anpassen das es läuft, mein Atmel-Studio kann auch für ARM compilieren.
Ich plane auch gerade eine SAME51 Platine.

Hier, spontan ein Projekt erstellt und das hier in der FT8_config.h 
eingefügt, das compiliert sogar fehlerfrei durch:

    #if defined (__SAM4S8C__)
    
      #include "sam.h"

      #define DELAY_MS(ms)
      
      #define PD_FT812 12
      #define CS_FT812 11

      static inline void FT8_pdn_set(void)
      {
        PIOA->PIO_CODR = PD_FT812;
      }

      static inline void FT8_pdn_clear(void)
      {
        PIOA->PIO_SODR = PD_FT812;
      }

      static inline void FT8_cs_set(void)
      {
        PIOA->PIO_CODR = CS_FT812;
      }

      static inline void FT8_cs_clear(void)
      {
        PIOA->PIO_SODR = CS_FT812;
      }

      static inline void spi_transmit(uint8_t data)
      {

      }

      static inline uint8_t spi_receive(uint8_t data)
      {

        return 1;
      }

      static inline uint8_t fetch_flash_byte(const uint8_t *data)
      {
        return *data;
      }
    
    
    #endif

Da fehlt halt noch einiges, wie das delay().

[Axel V. (axel-f)]

Ah, danke für die spontane Antwort.

Beim SAM4 wollte ich meistenteils die Möglichkeit der 16 Bit Ausgabe 
nutzen. Macht aber wohl eher mehr Arbeit. Allerdings sehen, die Routinen 
etwas anders aus, da ich die Automatik für den CS nutzen möchte.
Delay() habe ich, funktioniert auch.
Mittlerweile habe ich weitergeforscht und weiß, wo der Fehler lag: Das 
Lesen ist 4 Byte vorgesehen, das schreiben nur mit 3. Aaargh!
Jetzt kommen die Reaktionen vom FT, wie sie sein sollen, also PWM, PCLK 
usw.

Display:
https://www.pollin.de/p/lcd-modul-et043003dh6-tft-480x272-121498
auch interessant:
https://www.pollin.de/p/tft-modul-et020007dmu-tft-176x220-121299
https://www.pollin.de/p/lcd-modul-tm080sdh01-tft-8-800x600-4-3-121575

Für den Preis MUSSTE ich das einfach ausprobieren!

[Rudolph R. (rudolph)]

Ah, Du hast dann den FT812 und den SAM4 auf einem eigenen Board?
Interessant.
Das würde ich gerne mal sehen.

Ja, 16 oder gar 32 Bit machen mit dem FT8xx nur begrenzt Sinn.
Die SPI-Kommandos haben 24 Bit mit 22 Bit Adresse, die Co-Prozessor 
Kommandos die ich praktisch ausschliesslich nutze haben 32 Bit.
Bei den Lese-Funktionen wird auch immer ein Dummy-Byte gesendet, weil 
SPI ja immer ein Byte Versatz hat zwischen Lesen und Schreiben.

Mit dem RH850 wollte ich auch schon mal automatisches Chip-Select 
benutzen, habe das dann aber letztlich verworfen weil dem Controller 
nicht beizubringen war das flexibel wieder auf High zu setzen.
Da müssen drei Bytes am Stück gesendet werden, oder vier, fünf, sechs, 
sieben, acht - das sind die Basis-Operationen.
Mit den Listen sende ich jetzt über den "Burst-Modus" auch mal >700 
Bytes am Stück.

Für sowas wie den SAM4 würde DMA Ausgabe vielleicht Sinn machen, bisher 
habe ich aber noch gar keinen Controller benutzt der DMA kann.
Das wäre aber vor allem auch nur für die Listen interessant, bei einem 
einsamen FT8_get_touch_tag() kann man sich den Luxus erlauben, dass der 
Controller damit beschäftigt wird, 8 Bytes per DMA ist jetzt nicht so 
hilfreich und auf das Ergebnis der Aktion muss eh gewartet werden.

Hmm, kurz drüber nachgedacht wie man DMA einbauen könnte, das ist gar 
nicht so leicht.
Zum einen ist mit cmd_burst, bzw. 
FT8_start_cmd_burst()/FT8_end_cmd_burst(() schon ein Mechanismus 
eingabaut um viele Kommandos am Stück abzusetzen ohne immer wieder neu 
adressieren zu müssen.
Mit einem Define FT8_DMA oder so könnte man bewirken das die Funktionen 
für DMA was anderes machen.
Wobei eigentlich nicht mal das, FT8_cs_set() und FT8_cs_clear() müssten 
sich zunächst anders verhalten, nämlich bei DMA gar nichts machen.
Das spi_transmit() müsste bei DMA dann in einen Puffer schreiben wenn 
cmd_burst aktiv ist.
Am Ende muss FT8_cmd_start() den DMA Transfer anschieben - und jetzt 
wird es nervig - für einen DMA-complete Interrupt den Offset im 
FT8_RAM_CMD zur Verfügung stellen der ins REG_CMD_WRITE Register 
geschrieben wird.
Bis zum Abschluss der Aktion muss der SPI komplett gelocked sein.
Und nach dem Interrupt ist der Co-Prozessor ja erstmal damit beschäftigt 
die Kommandos zu verarbeiten.
Der ganze Aufriss dient auch nur dazu ein paar Hundert µs alle 20ms oder 
so früher aus der tft_loop() raus zu kommen.

Ein Argument dafür wäre jetzt das der Controller früher wieder schlafen 
gehen kann, aber selbst ein 3,5" TFT benötigt ja mit runter-gedimmter 
Hintergund-Beleuchtung immer noch sehr viel mehr Strom als der 
Controller.

Wenn der Controller dicker ist und die Hardware das her gibt kann man 
auch einfach den SPI auf einen höheren Takt setzen und schon werden 
alleine dadurch aus 700µs nur noch 300µs für den SPI-Transfer.

Das nächste was ich mir für die Applikations-Schicht, sprich meine tft.c 
überlegt habe ist tft_loop() quasi Event-gesteuert zu machen.
Also den zweiten Teil der das Bild aktualisiert nicht immer auszuführen, 
sondern nur wenn es notwendig ist.
Etwa wenn der erste Teil ein Touch-Event erkannt hat.
Einer der Auslöser für den Refresh sollte dabei auch ein simples Timeout 
sein das alle zwei Sekunden mal dafür sorgt das neu gemalt wird.
Für statische HMI könnten die Bilder pro Sekunde auch generell gesenkt 
werden in der tft_loop(), also gar nicht jeder zweite Aufruf macht 
(potentiell) ein Bild, sondern jeder vierte.
Die für den Bildaufbau notwendigen 1-4ms sollten aber den restlichen 
Ablauf im Controller nicht aus der Bahn werfen, das darf man auch nicht 
vergessen.

Bisher habe ich mir sowas nicht gegeben, weil ich zum einen gar kein 
Problem mit der Laufzeit habe, als nächstes das "Profiling" machen will 
und dann Animation mit einer festen Zeitbasis einfach besser 
kontrollierbar sind.
Für die Arbeit habe ich gerade eine Oberfläche gebaut die Rechts fünf 
Touch-Buttons mit Status-Anzeige hat und Links eine Status-Ausgabe für 
11 Variablen hat mit Punkten die ihre Farbe ändern und vom Status der 
Variablen abhängigen Text.
Das verlangt geradezu nach einem Event-gesteuertem Refresh, nur einen 
echten Vorteil sehe ich damit nicht.

[Axel V. (axel-f)]

Was genau möchtest Du denn sehen? Ein Foto vom Board oder den passenden 
Schaltplan? Falls gewünscht und sobald es funktioniert, kann ich meine 
config.h posten.

Ich werde dann mal den Code auf 8 Bit umstellen und in die config.h 
einbauen. Prinzipiell arbeite ich nicht mit dem Atmel Studio sondern mit 
Eclipse (unter Linux), deswegen sieht das bei mir in Teilen etwas anders 
aus.

An DMA hatte ich auch gedacht, das schien sich hier anzubieten. 
Allerdings sind hier zu viele Fallunterscheidungen, womit die Sache 
einfach nur nervig wird. Ich werde dafür nach dem init das SPI auf 24 
MHz hochtakten, das muß reichen (ist ja kein 4k Display).

Womit ich noch ein wenig Probleme habe: ich kann ja direkt in die 
Display List schreiben (über FT8_memWrite32(FT8_RAM_DL, ...) und ich 
kann das über die Coprozessor Kommandos machen (dann schreibt der in die 
DL).
Ich habe im Init den Bildschirm auf Blau eingestellt und das 
funktioniert auch. Dann habe ich das hier versucht:

void draw_welcome(void)
{
FT8_memWrite32(FT8_RAM_DL, (DL_CLEAR_RGB | 0xff00));  //Grün
FT8_memWrite32(FT8_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | 
CLR_TAG));
FT8_memWrite32(FT8_RAM_DL + 8, COLOR_RGB(160, 22, 22)); // change to red
FT8_memWrite32(FT8_RAM_DL + 12, BEGIN(FT8_BITMAPS));
FT8_memWrite32(FT8_RAM_DL + 16, VERTEX2II(220, 110, 31, 'A'));
FT8_memWrite32(FT8_RAM_DL + 20, END());
FT8_memWrite32(FT8_RAM_DL + 24, DL_DISPLAY);  /* END OF DISPLAY LIST */
FT8_memWrite32(REG_DLSWAP, FT8_DLSWAP_FRAME);
}

.. aber das hat nichts gebracht. Geht das prinzipiell nicht oder muß ich 
dem FT noch irgendwie sagen 'Fang eine neue DL an!'?

[Rudolph R. (rudolph)]

Axel V. schrieb:
> Was genau möchtest Du denn sehen? Ein Foto vom Board oder den passenden
> Schaltplan?

Na alles, inklusive Layout. :-)
Nein, nicht so wichtig, gibt ja genug freie Unterlagen dazu. :-)
Wie zum Beispiel im User-Manual von Matrix Orbital.

> Falls gewünscht und sobald es funktioniert, kann ich meine
> config.h posten.

Ja gerne, das übernehme ich dann auch gerne, bisher gab es zwar viel 
positives Feedback, aber wenig bis keinen Beitrag in der Form von 
Konfigurationen.
Wobei, da oben steht noch was zum SAM4E das ich irgendwie nie eingebaut 
habe.

> Ich werde dann mal den Code auf 8 Bit umstellen und in die config.h
> einbauen. Prinzipiell arbeite ich nicht mit dem Atmel Studio sondern mit
> Eclipse (unter Linux), deswegen sieht das bei mir in Teilen etwas anders
> aus.

Na, die IDE ist ja soweit egal, die Kollegen denen ich zuarbeite bauen 
nur per Build-Script und Makefile.
Nur einen anderen Compiler als den GCC hatte ich noch nicht.
Keine Ahnung was passiert wenn man da zum Beispiel einen GHS drauf los 
lässt, sollte aber eigentlich anpassbar sein.

> An DMA hatte ich auch gedacht, das schien sich hier anzubieten.
> Allerdings sind hier zu viele Fallunterscheidungen, womit die Sache
> einfach nur nervig wird. Ich werde dafür nach dem init das SPI auf 24
> MHz hochtakten, das muß reichen (ist ja kein 4k Display).

24MHz ist schon sportlich für die Signale, aber SPI ist ja robust.

> Womit ich noch ein wenig Probleme habe: ich kann ja direkt in die
> Display List schreiben (über FT8_memWrite32(FT8_RAM_DL, ...) und ich
> kann das über die Coprozessor Kommandos machen (dann schreibt der in die
> DL).
> Ich habe im Init den Bildschirm auf Blau eingestellt und das
> funktioniert auch. Dann habe ich das hier versucht:

Ich schreibe gar nicht in die Liste weil das zu eingeschränkt ist, 
insofern kann ich da jetzt auch nicht so viel sagen.
Ich fange auf jeden Fall immer mit CMD_DLSTART an und nach der 
Beschreibung setzt das wohl vor allem REG_CMD_DL auf Null.
Aber wie das funktioniert das eine zweite Liste gebaut wird bin ich 
gerade überfragt, möglicherweise wird zwischen zwei Bänken von RAM_DL 
umgeschaltet.

> void draw_welcome(void)
> {
> FT8_memWrite32(FT8_RAM_DL, (DL_CLEAR_RGB | 0xff00));  //Grün
> FT8_memWrite32(FT8_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN |
> CLR_TAG));
> FT8_memWrite32(FT8_RAM_DL + 8, COLOR_RGB(160, 22, 22)); // change to red
> FT8_memWrite32(FT8_RAM_DL + 12, BEGIN(FT8_BITMAPS));
> FT8_memWrite32(FT8_RAM_DL + 16, VERTEX2II(220, 110, 31, 'A'));
> FT8_memWrite32(FT8_RAM_DL + 20, END());
> FT8_memWrite32(FT8_RAM_DL + 24, DL_DISPLAY);  /* END OF DISPLAY LIST */
> FT8_memWrite32(REG_DLSWAP, FT8_DLSWAP_FRAME);
> }
>
> .. aber das hat nichts gebracht. Geht das prinzipiell nicht oder muß ich
> dem FT noch irgendwie sagen 'Fang eine neue DL an!'?

Auf jeden Fall sieht das viel zu kompliziert aus. :-)

FT8_cmd_dl(CMD_DLSTART);
FT8_cmd_dl(DL_CLEAR_RGB | 0xff00);
FT8_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
FT8_cmd_dl(COLOR_RGB(160, 22, 22));
FT8_cmd_text(220, 110, 31, 0, "A");
FT8_cmd_dl(DL_DISPLAY);  
FT8_cmd_dl(CMD_SWAP);
FT8_cmd_execute();

Und das ist nur die vereinfachte Version inklusive Adress-Overhead durch 
jedes einzelne Kommando.

Also eine wichtige Aufgabe die meine Library für mich hat ist das 
Gefummel mit dem Offset beim Schreiben zu verbergen.

Und die Handbremse ist gelöst.
Zum einen wird nicht ständig getestet ob im FIFO auch noch genug Platz 
ist, weil der Test fast immer überflüssig ist.
Man muss eben aufpassen das man nicht mehr als 4k am Stück in den FIFO 
schreibt, das ist aber gar nicht mal so wenig.
Also es gilt die Annahme, dass der FIFO quasi leer ist und für geöhnlich 
trifft das auch zu.

FT8_cmd_loadimage() könnte ein Problem haben mit grossen Bildern bei 
hohen SPI Geschwindigkeiten, aber der Co-Pro wühlt sich schon ordentlich 
flott durch die Daten, ich weiss gar nicht wie schnell man sein müsste 
um den Co-Pro beim Abarbeiten einzuholen.

Mein FT8_busy() macht auch nicht drei Lese-Zugriffe wie das Original von 
FTDI, sondern nur einen.

Meine Implementierung mag nicht kugelsicher sein, ich möchte aber mal 
ganz frech behaupten das sie deutlich fixer ist als das was FTDI 
vorgelegt hat.

[Axel V. (axel-f)]

Deinen Programmvorschlag habe ich eingebaut, funktioniert aber noch 
nicht; vielleicht stimmt was mit meiner Funktion 'FT8_cmd_dl' nicht. Das 
werde ich dann mal morgen mit dem Oszi anschauen.

Was mir noch aufgefallen ist: in Deinem init() sprichst Du nur die gpio 
Register an, nicht die gpiox. Obwohl die gpio angeblich veraltet sind. 
Ist das zufällig so?

[Rudolph R. (rudolph)]

Die GPIOX habe ich bisher nur einfach nicht gebraucht.
In der FT8_command.c vom Github benutze ich jetzt das erste Mal 
REG_GPIOX_DIR um GPIO3 zu bedienen - für den Touch der Matrix Orbital 
Module.

[Axel V. (axel-f)]

SPI Geschwindigkeit: sehe ich mal nicht als kritisch an. Wenn man sieht, 
daß serielle Flash mit 90 MHz und mehr betrieben werden, sollte das kein 
Problem sein. Außerdem sehen die Pulse am Oszi sehr sauber aus, exakte 
und stabile Flanken.

Die Matrix Orbitalmodule sehen sehr interessant aus, vor allem die 
Produtpalette läßt kaum Wünsche übrig. Was meinst Du zu den 
Pollin-Modulen? Über die Anzeigequalität kann ich erst später was 
sagen...

Schaltplan kannst Du prinzipiell bekommen (als PM). Kannst auch das 
Layout haben. Einfacher wäre es allerdings, wenn ich Dir einfach eine 
Platine schenke, sozusagen als Danke für die FT Lib (bei China 
Bestellungen bekommt man automatisch min. 5 Stück). Es handelt sich um 
einen Frequenzgenerator per DDS plus digitaler Frequenzgeber per PLL 
Synthese. Kann man aber auch prinzipiell als Spielwiese für den SAM4S 
verwenden.

[Rudolph R. (rudolph)]

Axel V. schrieb:
> SPI Geschwindigkeit: sehe ich mal nicht als kritisch an. Wenn man sieht,
> daß serielle Flash mit 90 MHz und mehr betrieben werden, sollte das kein
> Problem sein. Außerdem sehen die Pulse am Oszi sehr sauber aus, exakte
> und stabile Flanken.

SPI ist recht robust, aber saubere Flanken habe ich da schon länger 
nicht mehr gesehen - ich muss man mein Oszi putzen. :-)

> Die Matrix Orbitalmodule sehen sehr interessant aus, vor allem die
> Produtpalette läßt kaum Wünsche übrig.

Mir "fehlt" aktuell bestenfalls ein etwas kleineres Modell, aber sowas 
hat keiner im Sortiment, so 3,2" oder so, weiss nicht genau, als Ersatz 
für ein 128x64 LCD.
Mir gefallen aus der Matrix Orbital Palette ja am meisten die "G" Typen 
mit der Glasfront die auf das Gehäuse geklebt wird.
Was anderes als kapazititv-touch will ich auch nicht mehr benutzen.

> Was meinst Du zu den Pollin-Modulen?

Na, die sind vor allem sehr preiswert.
Bei sowas mache ich mir dann vor allem eher Sorgen um die 
Nachhaltigkeit, ich habe Zweifel ob man die in einem Jahr noch bekommen 
kann.
Pollin hat ja eher so Artikel die beim Aufräumen in irgendeinem Lager 
noch gefunden wurden.
Womit ich das nicht schlecht reden will, das hat seinen Markt.
Und die Pin-Belegung ist ja auch nicht einheitlich, also einfach mal 
ersetzen kann funktionieren, kann aber auch in Suchen ausarten.

Das erste hat auch zwei Stränge zu sechs LEDs in Reihe -> braucht halt 
noch einen Stepup-Wandler.

Das zweite ist total niedlich mit 2", hat nur keinen Touch.
Aber dafür auch nur zwei LEDs.
Sieht nach einem Display für eine Kamera aus.

Das dritte ist so Kategorie digitaler Bilderahmen, leider ohne 
Datenblatt bei Pollin, aber Google wirft was aus.
Hat wohl auch kein Touch.

> Über die Anzeigequalität kann ich erst später was sagen...

Man wird gut was erkennen können und es wird bunt sein. :-)

> Schaltplan kannst Du prinzipiell bekommen (als PM). Kannst auch das
> Layout haben. Einfacher wäre es allerdings, wenn ich Dir einfach eine
> Platine schenke, sozusagen als Danke für die FT Lib

Danke, aber ich bin wirklich eher neugierig, ein Bild vom fertigen 
Aufbau wäre schon schick.
Ich will zwar langsam auch mal auf ARM wechseln, habe mir dafür aber den 
SAME51 ausgesucht, ein erstes Test-Board läuft auch schon bei einem 
Kollegen.
Für ein Display packe ich da aber nur einen kleinen 7pol. Stecker mit 
drauf und bereite noch eine weitere Platine mit Netzteil für das TFT, 
Level-Shifter und FFC-Anschlüssen vor.

[Axel V. (axel-f)]

Ja, es ist bunt. Und recht gut ablesbar. Nicht gerade 
4k-crystalclear-Handydisplay aber für meine Zwecke allemal gut. Ich 
nehme an, daß die Touchfolie hier einiges an Schärfe und Klarheit nimmt.
Apropos Touch: was macht die kapazitive Version so wertvoll bzw. was ist 
am res. Touch soo schlecht?

Mittlerweile habe ich bei mir was am laufen und es ist völlig verrückt- 
nach vielem Probieren und kurz vorm wahnsinnig werden habe ich 
herausgefunden, daß ich vor dem Start einer neuen Displayliste meinen 
PCLK auf 0 setzen muß um ihn am Schluß der Liste wieder einzuschalten. 
Gibt's dafür eine Erklärung?

[Rudolph R. (rudolph)]

Axel V. schrieb:
> Apropos Touch: was macht die kapazitive Version so wertvoll bzw. was ist
> am res. Touch soo schlecht?

Bei resistiv hast Du immer zwei Plastik-Folien die über mechanischen 
Druck zusammen gepresst werden.
Die liegen natürlich vor der Anzeige, machen das Bild von vornherein 
etwas trüber, sind nicht so empfindlich und sind lange nicht so 
widerstandsfähig.
Das schlimmste an Touch-Oberflächen überhaupt ist das man die dauernd 
anfassen muss. :-)
Da ist mir eine Glasplatte über die ich wischen kann echt lieber.
Resistiv-Touch ist auch eher für die Bedienung mit Stift.

Die nächste Steigerung davon sind die Displays wie das EVE2-35G weiter 
oben die keinen Rahmen benötigen und im Gehäuse versenkt werden, sondern 
den Rahmen quasi schon mitbringen.
Ich habe mir auch gerade noch zum Vergleich ein NHD-3.5 gekauft und das 
gefällt mir mechanisch so gar nicht.
Dazu kommt, dass das zwar die gleiche Pin-Belegung wie Riverdi und 
Matrix Orbital hat, bis auf den Audio-Ausgang der einen Pin versetzt 
ist, aber ein Folien-Kabel mit deutlich grösseren Abständen, so kann ich 
das spontan nicht mal irgendwo anschliessen. :-(
Dabei ist die Qualität der Panels wohl sogar ziemlich gut, das "Premium" 
hat einen Blickwinkel von 70° in alle Richtungen.
Aber mit dem Stecker sind die bei mir echt raus.

Axel V. schrieb:
> habe ich
> herausgefunden, daß ich vor dem Start einer neuen Displayliste meinen
> PCLK auf 0 setzen muß um ihn am Schluß der Liste wieder einzuschalten.
> Gibt's dafür eine Erklärung?

Äh nein, nicht wirklich, ich setze PCLK genau einmal.
Schreibst Du jetzt immer noch direkt in die Display-Liste, oder benutzt 
Du den Co-Prozessor dafür?

[Rudolph (Gast)]

I got a NHD-3.5-320240FT_CSVX module with my very first private order 
from DigiKey.
And I can not use it.

The picture shows the NHD-3.5-320240FT_CSVX next to a EVE2-35G from 
Matrix Orbital.
As you can see, the 20pin FFC header on the NHD-3.5 is almost twice the 
size of the connector on the EVE2-35G.

Another idea would be to use jumper-cables to connect to the header on 
the other side of the PCB. But this side also has no level-shifters, so 
directly connecting it to an Arduino for a quick test does not work.

I do not get it, why even bother to copy the pin assignment that Riverdi 
introduced (while shifting the Audio pin) and then use a different 
connector?

[Rudolph (Gast)]

Something completely different.

I just was curious how much time is needed by the co-prozessor to unpack 
graphics-files into memory.
So I put FT8_cmd_loadimage() in a loop and changed FT8_cmd_execute() a 
bit:

void FT8_cmd_execute(void)
{
  FT8_cmd_start();
PORTD |= (1<<PD3);
  while (FT8_busy());
PORTD &= ~(1<<PD3);
}

And the result is interesting.
The ugly star.png I use for the tests with 3867 bytes in length takes 
53ms to process while a .jpg with 3903 bytes takes only 480µs to 
process.
At least with a FT813 this means that processing .jpg is 110 times 
faster than using .png.

That is just annother reason to not use .png with the FT8xx.

[Axel V. (axel-f)]

Es ist egal, ob ich direkt in die DL schreibe oder via CoProzessor; es 
funktioniert immer nur, wenn ich den PCLK aus und wieder einschalte. An 
der Frequenz vom PCLK liegt es nicht, die habe ich schon von 6-15 MHz 
eingestellt. Vermutlich gibt es einen kurzen Riß im Raum-Zeit-Kontinuum 
;-) , wenn eine neue DL 'rausgelegt' wird. Ich werde mal noch ein wenig 
herumspielen, vielleicht läßt sich noch etwas finden. Im Grunde genommen 
könnte ich damit leben, nur erfahrungsgemäß fallen einem solche dubiosen 
Sachen irgendwann auf die Füße.

Die Matrix Orbitaldisplays- wo kaufst Du die? Soweit ich gesehen habe, 
gibt's die praktisch nur beim Hersteller; nicht in Deutschland.

[Rudolph R. (rudolph)]

Axel V. schrieb:
> Die Matrix Orbitaldisplays- wo kaufst Du die? Soweit ich gesehen habe,
> gibt's die praktisch nur beim Hersteller; nicht in Deutschland.

Die gibt es bei DigiKey oder Mouser. Da ich die eher nicht Europa 
zuordne habe ich das dem Chef von Matrix Orbital auch so gesagt am 
Messe-Stand und ihm zum Beispiel Watterott empfohlen als Händler, keine 
Ahnung ob da mal was draus wird oder ob da überhaupt Kontakt besteht 
oder Interesse.
Jetzt habe ich gerade meine erste private DigiKey Bestellung durch und 
das war erheblich leichter als ich befürchtet hatte, zudem recht fix.
DigiKey nimmt sogar Paypal an, Sonntag bestellt, Mitwoch morgen da.
Wenn jetzt nicht noch eine der berüchtigten 
Vorlage-Provisions-Rechnungen von UPS kommt ist alles schick.

Die von mir bevorzugten "G" Typen sind allerdings bisher nur gelistet, 
aber nicht verfügbar.
Es gibt ja auch noch Riverdi, die kleinen Module habe allerdings nur 
einen FT801 verbaut, es gibt gar kein 3.5".
RVT50UQFNWC00 gibt es zum Beispiel bei TME.

[Johan S. (johan_s)]

Guten Tach,
Thank you for the library, I have used it very successfully.
I am using 7"Riverdi screen with FT813.
2 Problems:
1. Simple Cursor for use in menus.
2. I get data to display in text from canbus, varying width.
After using cmd_text, what is the x position?
cmd_text returns void. Where to put next text message?

Vielen Dank
Johan Smit

[Rudolph R. (rudolph)]

Johan S. schrieb:

Hello,

> Thank you for the library, I have used it very successfully.

I am always like to hear that. :-)

> I am using 7"Riverdi screen with FT813.

Which Controller are you using? I am just curious.

> 2 Problems:
> 1. Simple Cursor for use in menus.

And the problem is what exactly?
You could use a rectangle for this.

> 2. I get data to display in text from canbus, varying width.

I just had a similiar applidation, reading variables from CAN and 
printing text depending on the value.

> After using cmd_text, what is the x position?
> cmd_text returns void. Where to put next text message?

The FT8xx do not provide this information, it can not be retrieved thru 
the command.
And even if somehow there is a way to find out, the co-processor command 
is not executed untill the display-list is complete.
And the result would be calculated during execution of the display-list 
that has been constructed from the co-processer command-list.

This makes it a problem for the application level, you need to calculate 
the resulting width yourself.
But since most of the fonts are proportional and not fixed-width fonts 
this would either require to read back the width of each character from 
the font-tables or to use your own tables in the controller.
So far I just avoid the problem, I am not trying to print text 
dynamically.
I rather setup a table with fixed column positions.
Granted I have to adjust these positions manually.
Annother option would be to build longer strings before feeding them 
thru cmd_txt().

So far the fonts in the FT8xx only have 128 characters.
Looks like the upcoming BT815/BT81 will feature Unicode support but have 
to wait how this works out.

[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.

[Rudolph R. (rudolph)]

Happy new year everyone! :-)

I am still interested in expanding the supported platforms and so I have 
added GD32VF103 for RISC-V a couple of days ago.
I have not tested it though (yet), as that would require me to solder 
jumper wires to my Longan Nano.

Since the GD21VF103 is "just" a GD32F103 with a RISC-C core, basic 
support for STM32 should be almost implemented now as well.
Well, apart from DMA that is.

If you would like to see other controllers added, tell me which.
And if you already have implemented the support code for a different 
controller, please post it.

And to keep things interesting, Bridgetek and FTDI posted news in 
november that they will be showing BT817 at Embedded World in february.

I have no solid idea so far what they are up to, but I will stay on top 
of it and add whatever new registers, defines and/or functions the BT817 
may require to unlock its added functionality.

[M. B. (mokkka)]

Hallo Rudolph,

erstmal vielen Dank für die Bibliothek, die Arbeit die du da rein 
steckst und  den Support den du hier gibst.

Ich habe den FT800 mit einem 4,3" Resistiven Touchdisplay an ein STM32 
Chip angeschlossen. Die Kommunikation mit dem FT800 funktioniert und ich 
kann auch Elemente auf dem Display anzeigen.

Nun habe ich folgendes Problem:

Im ersten Schritt habe ich das Beispielprojekt von GitHub genommen und 
den Teil zur Kalibrierung im tft.c File aktiviert. Die Werte werden mir 
angezeigt und ich habe sie in einen eigenen define-Block übernommen.

Danach habe ich mit dem unteren Programmteil eine neue Displayliste 
erzeugt und mir einen Button anzeigen zu lassen.

  EVE_cmd_dl(CMD_DLSTART);
  EVE_cmd_dl(CLEAR_COLOR_RGB(31, 63, 127));
  EVE_cmd_dl(CLEAR(1,1,1));
  EVE_cmd_text(240, 68, 27, EVE_OPT_CENTER, "Test Text!!");
  EVE_cmd_dl(TAG_MASK(1));
  EVE_cmd_dl(TAG(5));
  EVE_cmd_button(180, 120, 120, 36, 27, EVE_OPT_CENTER, "Test Button!!");
  EVE_cmd_dl(DL_DISPLAY);
  EVE_cmd_dl(CMD_SWAP);
  EVE_cmd_execute();

Das alles geschieht vor dem while(1)-Block in der main-Routine.

Im while(1)-Block polle ich das REG_TOUCH_TAG-Register und gebe das 
Touch-Tag mit Hilfe von UART über Putty aus.

Beim Berühren des Buttons auf dem Display wird aber weiterhin eine 0 
ausgegeben bzw. wenn ich wahrlos auf dem Display neben dem Button drücke 
erscheint manchmal die erwartete 5 manchmal die 0.

Ich hab dann wieder die Kalibrierung durchgeführt und siehe da, es 
kommen andere Werte heraus.

Jetzt ist die Frage, ob man eine Kalibrierung jedes mal beim Start 
ausführen muss und die Kalibrierungsdaten ändern sich oder ob ich 
einfach ein Montagsprodukt erwischt habe und meine Toucheinheit einen 
Schuss weg hat.

Danke schonmal im Vorraus!

Gruß
Moritz

[Rudolph R. (rudolph)]

Hallo,

ich will nicht ausschliessen, dass ich gerade was kaputt gemacht habe, 
ich muss mir das noch genauer ansehen.

Aber benutzt mal einen anderen TAG Wert ab 10 aufwärts, da drunter ist 
das bei mir gerade nicht so richtig stabil.
Bei 5 schwankt der Wert komischerweise die ganze Zeit zwischen 4 und 5.
Bei 9 zwischen 8 und 9.
Bei 1 zwischen 0 und 1.
2, 3, 4, 6, 7, 8, 11, 15 und 19 funktionieren - was auch immer da los 
ist.

Zumindest stelle ich das gerade mit meinem EVE3-43G fest, wobei ich mir 
die Werte anzeigen lasse.

Meine FT800 Displays bekomme ich spontan nicht reaktiviert, die sind 
schon länger nicht mehr so wirklich interessant. :-)

Das TAG_MASK habe ich auch noch nie vewendet, das bewirkt so auch nichts 
da "1" sowieso der Default Wert ist.

Ich setze einfach ein TAG(0) für kein Touch, obwohl ohne einen Tag Wert 
zu setzen erstmal 255 geliefert wird.
Aber wenn kein Touch erkannt wird ist der Wert eben auch Null.

M. B. schrieb:
> Ich habe den FT800 mit einem 4,3" Resistiven Touchdisplay

Welches?

> an ein STM32 Chip angeschlossen.

Welchen und magst Du mal den Code dafür posten?


Was die Kalibrierung angeht, die mache ich in der Regel für jedes 
Display nur einmal und bisher passt es meistens sogar für verschiedene 
Displays vom gleichen Typ.
Wichtig ist allerdings, dass man die Kalibrierung präzise ausführt.
Bei resistiv geht das ja mit irgeneinem feinen aber stumpfen Gegenstand.
Für meine kapazitiven Displays habe ich mir extra Eingabestifte gekauft 
um die Punkte besser treffen zu können.

Und beim Spielen mit dem Stift auf dem Button habe ich gerade 
festgestellt, dass meine aktuellen Kalibrierwerte einen leichten Versatz 
nach Rechts haben, die Werte sind okay, das geht aber noch besser.

[M. B. (mokkka)]

> Aber benutzt mal einen anderen TAG Wert ab 10 aufwärts, da drunter ist
> das bei mir gerade nicht so richtig stabil.
> Bei 5 schwankt der Wert komischerweise die ganze Zeit zwischen 4 und 5.
> Bei 9 zwischen 8 und 9.
> Bei 1 zwischen 0 und 1.
> 2, 3, 4, 6, 7, 8, 11, 15 und 19 funktionieren - was auch immer da los
> ist.

Ok implementiert und keine Besserung immernoch wird nur der Wert 0 
ausgegeben

> M. B. schrieb:
>> Ich habe den FT800 mit einem 4,3" Resistiven Touchdisplay
>
> Welches?

ConnectEVE der Firma mikroE. Display ist schwer herauszufinden ich habe 
vorne noch einen Schriftzug mit RXA-043005 das ist allerdings nur die 
Bezeichnung vom Touchpanel. Zum TFT habe ich gar nichts gefunden.

>> an ein STM32 Chip angeschlossen.
>
> Welchen und magst Du mal den Code dafür posten?

STM32F407VG

Das ist die main() ohne Initialisierung der ganzen Schnittstellen welche 
automatisch generiert werden

  /* USER CODE BEGIN 2 */ 
  LL_SPI_Enable(SPI1);

  TFT_init();

  EVE_cmd_dl(CMD_DLSTART);
  EVE_cmd_dl(CLEAR_COLOR_RGB(31, 63, 127));
  EVE_cmd_dl(CLEAR(1,1,1));
  EVE_cmd_dl(TAG(0));
  EVE_cmd_text(240, 68, 27, EVE_OPT_CENTER, "Test Text!!");
  EVE_cmd_dl(TAG(10));
  EVE_cmd_button(180, 120, 120, 36, 27, 0, "Test Button!!");
  EVE_cmd_dl(DL_DISPLAY);
  EVE_cmd_dl(CMD_SWAP);
  EVE_cmd_execute();

  /* USER CODE END 2 */
 
 

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
   touch_tag=EVE_memRead8(REG_TOUCH_TAG);
   //if (touch_tag>0){
     if(touch_tag>9){
       touch_tag_uart[1]=(touch_tag%10)+48; //zehner Stelle als ASCII
       touch_tag_uart[0]=(touch_tag/10)+48; //einer Stelle als ASCII
     } else {
       touch_tag_uart[0]=32; // ASCII Space
       touch_tag_uart[1]=touch_tag+48;
     }
     HAL_UART_Transmit_IT(&huart2, touch_tag_uart, 4);
     while(HAL_UART_GetState(&huart2)!=HAL_UART_STATE_READY);
     touch_tag=0;
      //}
  }
  /* USER CODE END 3 */

Das ist der Teil aus der target.h

#if defined (STM32F407xx)

#include "EVE_config.h"
#include "main.h"

  static inline void EVE_pdn_clear(void)
  {
    HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
  }

  static inline void EVE_pdn_set(void)
  {
    HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
  }
  static inline void EVE_cs_clear(void)
  {
    HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
  }

  static inline void EVE_cs_set(void)
  {
    HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
  }

  static inline void spi_transmit(uint8_t byte)
  {
       while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 LL_SPI_ReceiveData8(EVE_SPI);
  }

  static inline uint8_t spi_receive(uint8_t byte)
  {
       while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 return LL_SPI_ReceiveData8(EVE_SPI);
  }

  static inline void spi_transmit_async(uint8_t byte)
  {
    #if EVE_DMA
        //TODO dma implementieren
    #else

    while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 LL_SPI_ReceiveData8(EVE_SPI);

    #endif
  }

  static inline uint8_t spi_receive_async(uint8_t byte)
  {
    #if EVE_DMA
        //TODO dma implementieren
    #else

    while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
       LL_SPI_TransmitData8(EVE_SPI, byte);

       while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
                 return LL_SPI_ReceiveData8(EVE_SPI);

    #endif
  }

  static inline void DELAY_MS(uint32_t delay)
  {
    HAL_Delay(delay);
  }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
        return *data;
    }

#endif

> Was die Kalibrierung angeht, die mache ich in der Regel für jedes
> Display nur einmal und bisher passt es meistens sogar für verschiedene
> Displays vom gleichen Typ.
> Wichtig ist allerdings, dass man die Kalibrierung präzise ausführt.
> Bei resistiv geht das ja mit irgeneinem feinen aber stumpfen Gegenstand.
> Für meine kapazitiven Displays habe ich mir extra Eingabestifte gekauft
> um die Punkte besser treffen zu können.
>
> Und beim Spielen mit dem Stift auf dem Button habe ich gerade
> festgestellt, dass meine aktuellen Kalibrierwerte einen leichten Versatz
> nach Rechts haben, die Werte sind okay, das geht aber noch besser.

Ja ein bisschen nach rechts oder links finde ich in Ordnung allerdings 
weichen die Werte schon sehr stark ab.

z.B.:

                         1.Durchlauf     2.Durchlauf     3.Durchlauf     

TOUCH_TRANSFORM_A:          98982 UL        33658 UL        33536 UL
TOUCH_TRANSFORM_B:            158 UL        65690 UL   4294966582 UL
TOUCH_TRANSFORM_C:     4293468776 UL   4276760870 UL   4294069736 UL 
TOUCH_TRANSFORM_D:     4294966920 UL   4294966974 UL   4294966694 UL
TOUCH_TRANSFORM_E:          20348 UL        20404 UL        86052 UL
TOUCH_TRANSFORM_F:     4293312168 UL   4293521822 UL   4276733650 UL

Daher die Überlegung dass das Panel nicht ganz in Ordnung ist.

[Rudolph R. (rudolph)]

M. B. schrieb:
>> Aber benutzt mal einen anderen TAG Wert ab 10 aufwärts, da drunter ist
>> das bei mir gerade nicht so richtig stabil.
>
> Ok implementiert und keine Besserung immernoch wird nur der Wert 0
> ausgegeben

Seltsam.

> ConnectEVE der Firma mikroE. Display ist schwer herauszufinden ich habe
> vorne noch einen Schriftzug mit RXA-043005 das ist allerdings nur die
> Bezeichnung vom Touchpanel. Zum TFT habe ich gar nichts gefunden.

Das ist schon etwas schwer angestaubt soweit. :-)
Ich hoffe das hast Du nicht gerade erst zu dem auf Mouser immer noch 
angezeigtem Kurs von 62 Euro gekauft.
Es gibt Beispielcode von MikroElektronika und da sind die Parameter 
drin, das habe ich gerade mal verglichen und ein Profil dafür 
hinzugefügt.

/* untested */
/* MikroElektronika ConnectEVE, FT800 480x272 4.3" */
#if defined (EVE_CONNECTEVE)
#define EVE_HSIZE  (480L)
#define EVE_VSIZE  (272L)

#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (10L)
#define EVE_VOFFSET  (12L)
#define EVE_VCYCLE  (286L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (41L)
#define EVE_HOFFSET  (43L)
#define EVE_HCYCLE   (525L)
#define EVE_PCLKPOL  (1L)
#define EVE_SWIZZLE  (0L)
#define EVE_PCLK  (5L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (2000L)
#define EVE_HAS_CRYSTAL
#endif

Die Parameter sind fast die gleichen wie bei den anderen 4.3" Displays.
Seltsamerweise weichen die Werte für VCYCLE and HCYCLE ab.

Das einzubauen und dafür zu compilieren hat auf jeden Fall noch einen 
Bug in EVE_get_touch_tag() aufgedeckt - die FT80x haben ja nur ein 
TOUCH_TAG Register...

> STM32F407VG

Ah okay, das ist schon eine ordentlich fixe Kachel. :-)

> touch_tag=EVE_memRead8(REG_TOUCH_TAG);
>    //if (touch_tag>0){
>      if(touch_tag>9){
>        touch_tag_uart[1]=(touch_tag%10)+48; //zehner Stelle als ASCII
>        touch_tag_uart[0]=(touch_tag/10)+48; //einer Stelle als ASCII
>      } else {
>        touch_tag_uart[0]=32; // ASCII Space
>        touch_tag_uart[1]=touch_tag+48;
>      }
>      HAL_UART_Transmit_IT(&huart2, touch_tag_uart, 4);
>      while(HAL_UART_GetState(&huart2)!=HAL_UART_STATE_READY);
>      touch_tag=0;

Auf den ersten Blick finde ich da nichts.
Du könntest mal REG_TOUCH_SCREEN_XY lesen und per sprintf() in einen 
String werfen, am besten als Hex-Wert.

M. B. schrieb:
> Das ist der Teil aus der target.h
...

Danke, ich schaue mal das ich das einbaue.
Wie sehen die Defines für EVE_PDN und EVE_CS und EVE_SPI aus?

Und die Includes passen nicht so richtig, EVE_config.h sollte nicht 
gebraucht werden und die main.c sollte eher die EVE_target.h inkludieren 
anstatt anders herum.
Statt dessen sollte da eher nur #include "stm32f4xx.h" stehen.

Die HAL Funktionen dürften das ganze übrigens nicht nur aufblähen, die 
sind auch verhältnismäßig langsam.
Die haben das gleiche Problem wie z.B. digitalWrite() beim Arduino, 
überflüssigerweise wird zur Laufzeit ermittelt was man eigentlich tun 
will.
Immer und immer wieder.
Zusätzlich fängt man sich mit dem Funktionsaufruf auch noch eigentlich 
überflüssige Stack-Zugriffe ein, was noch mehr Zeit kostet.

Daher benutzen meine AVR und ATSAM Funktionen direkte Register-Zugriffe.
Alleine den Funkions-Aufruf zu vermeiden macht das messbar schneller.

In den spi_transmit Funktionen LL_SPI_ReceiveData8(EVE_SPI); aufzurufen 
macht das ganze dann noch mal extra langsam.

> Ja ein bisschen nach rechts oder links finde ich in Ordnung allerdings
> weichen die Werte schon sehr stark ab.
>
> z.B.:                         1.Durchlauf     2.Durchlauf
> 3.Durchlauf
>
> TOUCH_TRANSFORM_A:          98982 UL        33658 UL        33536 UL
> TOUCH_TRANSFORM_B:            158 UL        65690 UL   4294966582 UL
> TOUCH_TRANSFORM_C:     4293468776 UL   4276760870 UL   4294069736 UL
> TOUCH_TRANSFORM_D:     4294966920 UL   4294966974 UL   4294966694 UL
> TOUCH_TRANSFORM_E:          20348 UL        20404 UL        86052 UL
> TOUCH_TRANSFORM_F:     4293312168 UL   4293521822 UL   4276733650 UL

Och, die Werte weichen bei mir auch immer mehr oder weniger stark ab, 
egal wie oft ich das neu kalibriere.
Richtig erklären kann ich das auch nicht, das liegt erstmal auch daran 
wie diese Werte verwendet werden.

Du kannst Dir ja mal die Funktion EVE_calibrate_manual() ansehen.
Da sieht man wie sich die Werte ergeben.
Da das aber auch nur bestenfalls die Hälfte des Puzzles ist, habe ich 
mich lieber was anderem gewidmet als bis ins Detail zu verstehen wie das 
funktioniert. :-)

[Rudolph R. (rudolph)]

Ich habs mal eingebaut und dabei beschleunigt:

    #if defined (STM32F407xx)
    
    #include "stm32f4xx.h"

    #define EVE_CS_PORT GPIOD
    #define EVE_CS GPIO_PIN_12
    #define EVE_PDN_PORT GPIOD
    #define EVE_PDN GPIO_PIN_13
    #define EVE_SPI SPI1
    
    #define DELAY_MS(ms) HAL_Delay(ms)
      
    static inline void EVE_pdn_clear(void)
    {
      EVE_PDN_PORT->BSRR = EVE_PDN;
//      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
    }

    static inline void EVE_pdn_set(void)
    {
      EVE_PDN_PORT->BSRR = (uint32) EVE_PDN << 16;
//      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
    }

    static inline void EVE_cs_clear(void)
    {
      EVE_CS_PORT->BSRR = EVE_CS;
//      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
    }

    static inline void EVE_cs_set(void)
    {
      EVE_CS_PORT->BSRR = (uint32) EVE_CS << 16;
//      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
    }

    static inline void spi_transmit(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
        EVE_SPI->DR = byte;
        while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      while((EVE_SPI->SR & SPI_SR_RXE) == 0); /* does most likely nothing */
      return EVE_SPI->DR;
    }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
      return *data;
    }

    #endif  /* STM32F407xx */

Ich kann das nicht bauen, ich habe mir jetzt nur mal angesehen was im 
STM32F407 Referenz-Manual so steht und was der STM32F4xx_HAL_Driver so 
treibt.

Und natürlich sind die Defines für die Ports und die Pins frei erfunden. 
:-)

Edit: okay, die Optimierung für den PowerDown Pin ist eher überflüssig, 
das wird ja kaum mal verwendet.

Edit2: das Define für DELAY_MS war falsch..

[M. B. (mokkka)]

Rudolph R. schrieb:
> Und die Includes passen nicht so richtig, EVE_config.h sollte nicht
> gebraucht werden und die main.c sollte eher die EVE_target.h inkludieren
> anstatt anders herum.
> Statt dessen sollte da eher nur #include "stm32f4xx.h" stehen.

Ich benutze die CubeMX Oberfläche um den Chip zu initialisieren. Die 
kreiert defines in der main.h. Diese defines habe ich in der config.h 
umdefiniert damit man nur an die config.h und nicht immer wieder an die 
target.h heranmuss.

Rudolph R. schrieb:
> Ich habs mal eingebaut und dabei beschleunigt:

Ich hab einen neuen pull gemacht und es sind noch ein paar Probleme 
aufgetaucht.

Rudolph R. schrieb:

static inline void spi_transmit(uint8_t byte)
     {
       EVE_SPI->DR = byte;
       while((EVE_SPI->SR & SPI_SR_TXE) == 0);
     }
 
     static inline void spi_transmit_async(uint8_t byte)
     {
       #if EVE_DMA
         EVE_dma_buffer[EVE_dma_buffer_index++] = data;
       #else
         EVE_SPI->DR = byte;
         while((EVE_SPI->SR & SPI_SR_TXE) == 0);
       #endif
     }
 
     static inline uint8_t spi_receive(uint8_t byte)
     {
       EVE_SPI->DR = byte;
       while((EVE_SPI->SR & SPI_SR_TXE) == 0);
       while((EVE_SPI->SR & SPI_SR_RXE) == 0); /* does most likely 
 nothing */
       return EVE_SPI->DR;
     }

Soweit ich das verstanden habe wird der Indikator SPI_SR_TXE gesetzt, 
wenn das Byte aus SPI*_DR erfolgreich in den Transmit Buffer geschrieben 
wurde. Deshalb hatte ich das vor dem Schreiben in das SPI*_DR Register 
abgefragt. Ich habe es mal mit beiden Versionen versucht also vor und 
nach dem Schreiben in das DR-Register. Ich konnte jetzt keinen 
Unterschied feststellen.

Der zweite Indikator heißt SPI_SR_RXNE.

Das zweite Problem entstand in der EVE_commands.h. Ich weiß nicht wie es 
bei anderen MCUs ist allerdings musste ich für den STM32F4 zusätzlich 
inttypes.h einbinden.

Nach diesen Änderungen, konnte ich die Bibliothek kompilieren. Trotzdem 
läuft es nicht und ich bekomme bei einem Read keine anständigen Werte 
zurück. Nach meiner Vermutung liegt das daran dass der Chip zu schnell 
für den FT800 ist. Durch Delays konnte ich das Display kurzzeitig zum 
Laufen kriegen. Nach einer Kalibrierung funktionierte es aber wieder 
nicht. Mit den LL-Bibliotheken funktioniert es weiterhin.

Rudolph R. schrieb:
> In den spi_transmit Funktionen LL_SPI_ReceiveData8(EVE_SPI); aufzurufen
> macht das ganze dann noch mal extra langsam

Meinst du damit den Aufruf von mehreren Funktionen? Im Grunde macht die 
Funktion ja nichts anderes als den Register auszugeben bzw beim Transmit 
das Register mit einem Pointer zu verbinden und mit dem dann die Daten 
über den Pointer in das Register zu schreiben. Bringt das soviel 
Overhead?

__STATIC_INLINE uint8_t LL_SPI_ReceiveData8(SPI_TypeDef *SPIx)
{
  return (uint8_t)(READ_REG(SPIx->DR));
}

__STATIC_INLINE void LL_SPI_TransmitData8(SPI_TypeDef *SPIx, uint8_t TxData)
{
#if defined (__GNUC__)
  __IO uint8_t *spidr = ((__IO uint8_t *)&SPIx->DR);
  *spidr = TxData;
#else
  *((__IO uint8_t *)&SPIx->DR) = TxData;
#endif /* __GNUC__ */
}

[Rudolph R. (rudolph)]

M. B. schrieb:
> Rudolph R. schrieb:
>> Und die Includes passen nicht so richtig, EVE_config.h sollte nicht
>> gebraucht werden und die main.c sollte eher die EVE_target.h inkludieren
>> anstatt anders herum.
>> Statt dessen sollte da eher nur #include "stm32f4xx.h" stehen.
>
> Ich benutze die CubeMX Oberfläche um den Chip zu initialisieren. Die
> kreiert defines in der main.h. Diese defines habe ich in der config.h
> umdefiniert damit man nur an die config.h und nicht immer wieder an die
> target.h heranmuss.

Wenn Du Dir mal mein (veraltetes, okay) Beispiel ansiehst, da gibt es 
noch eine "tft.c" und eine "tft.h".

Da habe ich die High-Level Funktionen drin die von der main.c aus
aufgerufen werden, modular und so.

Die "tft.h" exportiert bei mir aktuell:

extern uint16_t num_profile_a, num_profile_b;

void TFT_init(void);
void TFT_touch(void);
void TFT_display(void);

Die beiden Zahlenwerte beschreibe ich in der Hauptschleife, dazu messe 
ich mit einem Timer wie lange die TFT_touch() und die TFT_display() 
jeweils zur Ausführung benötigen.

Die "tft.c" includiert:
#include "EVE.h"
#include "EVE_target.h"
#include "EVE_commands.h"
#include "tft_data.h"

Da nun die "EVE_target.h" wiederrum die Platform-spezifischen Includes 
einfügt ist die tft.c als solche mit jeder Plattform benutzbar.

Packt man das alles in die main.c greift das natürlich soweit nicht, da 
die main.c quasi zwindend Plattform-spezifisch ist.

Also klar, mach doch, aber das ist ein wenig anders gemeint. :-)

> Soweit ich das verstanden habe wird der Indikator SPI_SR_TXE gesetzt,
> wenn das Byte aus SPI*_DR erfolgreich in den Transmit Buffer geschrieben
> wurde. Deshalb hatte ich das vor dem Schreiben in das SPI*_DR Register
> abgefragt. Ich habe es mal mit beiden Versionen versucht also vor und
> nach dem Schreiben in das DR-Register. Ich konnte jetzt keinen
> Unterschied feststellen.

Die einfachste Anwort ist erstmal, ich mache das überall so, für jede 
Plattform, schreiben, dann warten das der Transfer durch ist.
Damit ist zum Beispiel sichergestellt, dass das Chip-Select nicht zu 
früh wieder hoch gezogen wird und der SPI kann immer Daten annehmen.
Natürlich kann man das auch anderes herum machen und erstmal testen ob 
der SPI bereit ist Daten anzunehmen, da ich das aber nirgendwo sonst 
gemacht habe, ist es anders herum konsistenter.

> Der zweite Indikator heißt SPI_SR_RXNE.

Ups, das kommt davon wenn man das nicht compiliert.

Ich muss mal schauen ob ich irgendwoher ein STM32F407 Projekt bekomme 
das ich mit PlatformIO bauen kann.

Im Datenblatt ist mir dann noch was aufgefallen, die reinen Schreiben 
Funktionen sollten besser noch das RXNE Flag löschen.
Das ist vielleicht nicht ganz so fatal wie bei den ATSAM, aber wenn man 
Lesen und Schreiben auf dem SPI aktiv hat gibt es sonst einen Überlauf.

    static inline void spi_transmit(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      (void) EVE_SPI->DR; /* dummy read-access to clear SPI_SR_RXNE */
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
        EVE_SPI->DR = byte;
        while((EVE_SPI->SR & SPI_SR_TXE) == 0);
        (void) EVE_SPI->DR; /* dummy read-access to clear SPI_SR_RXNE */
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
      EVE_SPI->DR = byte;
      while((EVE_SPI->SR & SPI_SR_TXE) == 0);
      while((EVE_SPI->SR & SPI_SR_RXNE) == 0); /* does most likely nothing */
      return EVE_SPI->DR;
    }

> Das zweite Problem entstand in der EVE_commands.h. Ich weiß nicht wie es
> bei anderen MCUs ist allerdings musste ich für den STM32F4 zusätzlich
> inttypes.h einbinden.

Da die EVE_commands.c die EVE_target.h includiert wird damit implizit 
oder explizit auch die stdint.h mit includiert.
Für AVR, ATSAM, RISC-V und auch STM32 passiert das automatisch über die 
System-Includes.
#include "stm32f4xx.h" -> #include "stm32f407xx.h" -> #include 
<stdint.h>

> Trotzdem läuft es nicht und ich bekomme bei einem Read
> keine anständigen Werte zurück.

Oh, vielleicht habe ich das gerade schon gefixt mit dem Löschen von RXNE 
bei den Schreib-Funktionen.

> Nach meiner Vermutung liegt das daran dass der Chip zu schnell
> für den FT800 ist.

Das sollte eigentlich so gut wie nicht passieren können.

> Durch Delays konnte ich das Display kurzzeitig zum
> Laufen kriegen.

Delays an welcher Stelle?
Wie schnell hast Du den SPI laufen? Zumindest für das Init sollte das 
unter 11MHz sein, dann unter 30MHz wobei die Hardware das auch mit 
machen muss.

Wenn Du einen Logik-Analyzer hast, zieh doch mal einen Trace.

>> In den spi_transmit Funktionen LL_SPI_ReceiveData8(EVE_SPI); aufzurufen
>> macht das ganze dann noch mal extra langsam
>
> Meinst du damit den Aufruf von mehreren Funktionen? Im Grunde macht die
> Funktion ja nichts anderes als den Register auszugeben bzw beim Transmit
> das Register mit einem Pointer zu verbinden und mit dem dann die Daten
> über den Pointer in das Register zu schreiben. Bringt das soviel
> Overhead?
> __STATIC_INLINE uint8_t LL_SPI_ReceiveData8(SPI_TypeDef *SPIx)
> {
>   return (uint8_t)(READ_REG(SPIx->DR));
> }

In dem besonderen Fall macht es überhaupt keinen Unterschied,
da LL_SPI_ReceiveData8() als STATIC INLINE definiert ist, genau wie die 
Funktionen in der EVE_target.h.
Das ergibt überhaupt keinen Overhead da kein Funktionsaufruf statt 
findet.

Nett, das habe ich schon ganz anders gesehen.
Hilft halt echt wenn man das bauen und wirklich nachsehen kann, was da 
so passiert. :-)

Damit wäre das hier mein Vorschlag:

    #if defined (STM32F407xx)
    
    #include "stm32f4xx.h"

    #define EVE_CS_PORT GPIOD
    #define EVE_CS GPIO_PIN_12
    #define EVE_PDN_PORT GPIOD
    #define EVE_PDN GPIO_PIN_13
    #define EVE_SPI SPI1
    
    #define DELAY_MS(ms) HAL_Delay(ms)
      
    static inline void EVE_pdn_clear(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
    }

    static inline void EVE_pdn_set(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
    }

    static inline void EVE_cs_clear(void)
    {
//      EVE_CS_PORT->BSRR = EVE_CS;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
    }

    static inline void EVE_cs_set(void)
    {
//      EVE_CS_PORT->BSRR = (uint32) EVE_CS << 16;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
    }

    static inline void spi_transmit(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
           LL_SPI_TransmitData8(EVE_SPI, byte);
           while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
           LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         return LL_SPI_ReceiveData8(EVE_SPI);
    }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
      return *data;
    }

    #endif  /* STM32F407xx */

Das HAL_GPIO_WritePin() braucht zwar ein paar Takte mehr, das fällt aber 
nicht wirklich auf und im Gegenzug ist das auch gar nicht mehr 
STM32F407, sondern STM32F4xx.
Für EVE_pdn_clear() / EVE_pdn_set() ist der Overhead irrelevant.
Für EVE_cs_set() / EVE_cs_clear() ist das auch nicht relevant, weil man 
für eine große Display-Liste sowieso besser den Burst-Modus benutzt, ob 
nun mit DMA oder nicht, damit hat man für den ganzen Datenblock nur noch 
ein set/clear Paar und vor allem nur noch einmal am Anfang des Blocks 
die Ziel-Adresse.

Und bei einzelnen Komandos merkt man die paar Takte Overhead sowieso 
nicht.

[Rudolph R. (rudolph)]

Okay, ich habe ein neues PlatformIO Projekt erstellt.
Als Board habe ich einfach eine Drucker-Platine mit STM32F407 
ausgewählt.

--------------------------------------------------------------
Das ist nicht funktional und dient nur als Test ob das baut!
This does not work, the purpose is to see if it compiles!
--------------------------------------------------------------

Da wird nichts initialisiert, weder der Controller, noch die IOs oder 
der SPI.
Und die while(1) dreht einfach frei, die TFT_display() darf nur so alle 
20ms aufgerufen werden.

Nothing gets initialised, not the Core, or the IOs or the SPI.
And TFT_display() has to be called once every 20ms or more.


Ich musste die EVE_target.h jetzt doch noch ein wenig erweitern.
Ich dachte ja eigentlich, dass die HAL gleich mit includiert wird,
das war aber nichts.

#if defined (STM32F4)
    
#include "stm32f4xx.h"
#include "stm32f4xx_hal.h"
#include "stm32f4xx_ll_spi.h"
...

Edit, ich habe gerade noch aus dem STM32F407xx ein STM32F4 gemacht, das 
müsste soweit für die ganze Familie gelten.

Edit2: jetzt wüsste ich gerne noch, wie man Anhänge löscht :-)

[M. B. (mokkka)]

Rudolph R. schrieb:
> Da die EVE_commands.c die EVE_target.h includiert wird damit implizit
> oder explizit auch die stdint.h mit includiert.
> Für AVR, ATSAM, RISC-V und auch STM32 passiert das automatisch über die
> System-Includes.
> #include "stm32f4xx.h" -> #include "stm32f407xx.h" -> #include
> <stdint.h>

Das Problem entsteht auch nicht in der EVE_commands.c sondern 
EVE_commands.h. die EVE_commands.c ist soweit glücklich und hat alles

Rudolph R. schrieb:
> Delays an welcher Stelle?
> Wie schnell hast Du den SPI laufen? Zumindest für das Init sollte das
> unter 11MHz sein, dann unter 30MHz wobei die Hardware das auch mit
> machen muss.

Am Anfang um die 6 MHz danach würde ich gerne auf 21 MHz es funktioniert 
aber nur bis 10,5 MHz

Gegenvorschlag =). Das Problem liegt tatsächlich an dem RXNE Flag. Man 
muss mit dem Read allerdings warten bis das Flag geworfen wird. Der Chip 
rennt an dieser Stelle schneller als der SPI_Bus dementsprechend muss 
auf das
Flag gewartet werden.

    #if defined (STM32F407xx)
    
    #include "stm32f4xx.h"

    #define EVE_CS_PORT GPIOD
    #define EVE_CS GPIO_PIN_12
    #define EVE_PDN_PORT GPIOD
    #define EVE_PDN GPIO_PIN_13
    #define EVE_SPI SPI1
    
    #define DELAY_MS(ms) HAL_Delay(ms)
      
    static inline void EVE_pdn_clear(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_SET);
    }

    static inline void EVE_pdn_set(void)
    {
      HAL_GPIO_WritePin(EVE_PDN_PORT, EVE_PDN, GPIO_PIN_RESET);
    }

    static inline void EVE_cs_clear(void)
    {
//      EVE_CS_PORT->BSRR = EVE_CS;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_SET);
    }

    static inline void EVE_cs_set(void)
    {
//      EVE_CS_PORT->BSRR = (uint32) EVE_CS << 16;
      HAL_GPIO_WritePin(EVE_CS_PORT, EVE_CS, GPIO_PIN_RESET);
    }

    static inline void spi_transmit(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
         LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
    }

    static inline void spi_transmit_async(uint8_t byte)
    {
      #if EVE_DMA
        EVE_dma_buffer[EVE_dma_buffer_index++] = data;
      #else
           LL_SPI_TransmitData8(EVE_SPI, byte);
           while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
           while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
           LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXNE */
      #endif
    }

    static inline uint8_t spi_receive(uint8_t byte)
    {
         LL_SPI_TransmitData8(EVE_SPI, byte);
         while(!LL_SPI_IsActiveFlag_TXE(EVE_SPI));
         while(!LL_SPI_IsActiveFlag_RXNE(EVE_SPI));
         return LL_SPI_ReceiveData8(EVE_SPI);
    }

    static inline uint8_t fetch_flash_byte(const uint8_t *data)
    {
      return *data;
    }

    #endif  /* STM32F407xx */

Bis auf die Geschwindigkeit und die inttypes in der commands.h scheint 
es zu laufen.

[Rudolph R. (rudolph)]

M. B. schrieb:
> Das Problem entsteht auch nicht in der EVE_commands.c sondern
> EVE_commands.h. die EVE_commands.c ist soweit glücklich und hat alles

Ah okay, dagegen habe ich in EVE_target.c und tft.c erst das
EVE_target.h und dann EVE_commands.h.

Intuitiver ist aber vielleicht ein #include "EVE_target.h"
direkt in die EVE_commands.h zu packen.

M. B. schrieb:
> Gegenvorschlag =). Das Problem liegt tatsächlich an dem RXNE Flag. Man
> muss mit dem Read allerdings warten bis das Flag geworfen wird. Der Chip
> rennt an dieser Stelle schneller als der SPI_Bus dementsprechend muss
> auf das Flag gewartet werden.

Ich habs eingebaut, danke.
Die SPI Unit von zumindest dem STM32F4 ist schon ein wenig seltsam.
Alternativ bliebe noch das Busy-Flag abzufragen.
Das Kapitel 28.3.7 vom Referenz-Manual ist da aber etwas komisch.
Es gibt weder ein BDM noch ein BDOE Bit.

Das dürften BIDIMODE und BIDOE sein so vom Kontext her.
Mit MSTR = 1, BIDIMODE = 0 und BIDOE = 1 sollte das passen.

Aber dann kommt der nächste Satz:
"It is cleared:
• when a transfer is finished (except in master mode if the 
communication is continuous)"

Was soll das denn bitte heissen?
Unter welchen Umständen ist der SPI Transfer kontinuierlich?
Wenn man DMA benutzt?
Falls das so ist, warum sollte man mit den Status Bits rumspielen wenn 
gerade ein DMA Transfer läuft?


Edit:
>Am Anfang um die 6 MHz danach würde ich gerne auf 21 MHz es funktioniert
>aber nur bis 10,5 MHz

Das ist vor allem auch eine Frage der Hardware.
Mit meinen aktuellen ATSAMC21 Platinen kann ich 12MHz ohne 
Einschränkungen verwenden, also nach dem Init.
Wenn ich auf 24MHz hoch stelle funktioniert allerdings der Touch nicht 
mehr, also irgendwie läuft das mit MISO nicht rund.

[Ioan Mihai Cozac (Gast)]

Hallo Rudolf,

Erstmal Danke für deine erstklassiger Bibliothek, sie hat mir viel Zeit 
erspart.
Ich arbeite gerade bei einem Projekt in medizinische Bereich, dabei 
werden verschiedene Figuren und Texte teilweise animiert dargestellt, 
soweit funktioniert alles glücklicherweise wie gedacht.
Verwendet wird bei meinem Projekt ein 7" FT813 Display von Riverdi, und 
jetzt kommt mein problem: da die Pixels des displays nicht perfekt 
quadratisch sind die runde Formen wie Punkte und Kreisel werden leicht 
oval dargestellt.
Soweit habe keine Möglichkeit gefunden dies in Software zu kompensieren. 
Grundsätzlich müstte glaube ich ein Faktor von abs(sin(0,93 * PI) von 
Radius des Zirkels extrahieren sodass in verschiedene Richtungen dies 
unterschiedliche Länge hat. Also wie EVE_cmd_dl(POINT_SIZE (x - faktor) 
* 16).
Leider funktioniert das nicht wie erwartet, mir bleibt es immerhin oval.
Bei FTDI gibt auch keine weitere details über Primitives.
Sorry für meine Sprache, bin keiner nativen Deutschsprecher.

PS mit einem Display von Glyn funktioniert alles super, nur sind die 
vielmehr teurerer...

[Rudolph (Gast)]

Puh, ich muss zugeben, dass mir das bisher nicht mal aufgefallen ist, 
die Abweichung ist ja auch eher dezent.
Und ich benutze eher nur kleine Kreise.


Medizin ist ja mal interessant.
Wird das tatsächlich ein Produkt?
Welcher MikroController kommt da zum Einsatz?


Meine erste Idee war jetzt mal bei Matrix Orbital zu schauen, aber dem 
Datenblatt nach hat deren 7" Panel ein Pixel-Pitch von 0.1923*0.1784 und 
ist damit minimal "schlechter" als das Panel von Riverdi.

Wobei jetzt noch interessant gewesen wäre, welches Display das von 
Riverdi genau ist, ich habe mir jetzt nur das Datenblatt von den 
RVT70UQFNWC0x angesehen.

Die dritte Adresse für FT813 Displays wäre Newhaven, sowas wie das hier: 
https://www.newhavendisplay.com/nhd70800480ftctxlctp-p-9579.html

Da finde ich aber gerade gar keine Angabe im Datenblatt zum Pixel-Pitch, 
dazu müsstest Du denen mal eine Support-Anfrage einstellen.

Die haben auch mechanisch eine etwas andere Schnittstelle.


Direkt manipulieren kann man die "Primitives" nicht, die landen im 
Gegensatz zu den "Widgets" direkt so in der Display-Liste.
Und sowas wie CMD_SCALE wirkt sich nur auf Bilder aus, nicht etwa auf 
POINTS.

Eine Alternative zu einem anderen Display wäre noch auf POINTS ganz zu 
verzichten und das mit Bitmaps zu machen die vorab so verzerrt werden, 
dass sich das mit der Anzeige dann wieder ausgleicht.

Wenn der FT813 damit in der Anwendung nicht mehr funktioniert, weil 
einfach der Grafik-Speicher jetzt schon voll ist, schau Dir mal die 
BT815 basierten Displays von Riverdi und Matrix Orbital an.
Die haben ein SPI-FLASH mit auf der Platine das von dem BT815 
angesprochen wird, da kann man unter anderem Bilder rein packen die 
direkt angezeigt werden können.
Beschrieben wird der SPI-FLASH am bequemsten mit einem USB-SPI Interface 
was es ebenfalls von Riverdi oder Matrix Orbital gibt.

[TFTLCDCyg (Gast)]

The 7 "HD screen also has that uniqueness relative to" careless pixels "

Rudolph has considered using a microSD reader in your library, it is 
much more convenient to upload images on the GRAM of the FT81X screen, 
without running out of memory or complicating the code.

By the way, have you managed to upload videos in avi format with audio 
on the FT81x processor?

[Rudolph R. (rudolph)]

TFTLCDCyg schrieb:
> Rudolph has considered using a microSD reader in your library, it is
> much more convenient to upload images on the GRAM of the FT81X screen,
> without running out of memory or complicating the code.

I have considered it and just switched to a bigger controller. :-)
More seriously this is just out of scope for my code.
Sure, combining mass storage with EVE could be beneficial but apart from 
mayb e a helper function to transfer a memory buffer to EVE that is not 
my job.

And this function already exists for every other architecture than AVR 
in form of the code that reads from flash.
On ARM this can read from anywhere.

> By the way, have you managed to upload videos in avi format with audio
> on the FT81x processor?

Others have, but I have not even tried this so far.
This is just not what I use the FT81x/BT81x for.

[Ioan Mihai Cozac (Gast)]

The project is a time controller associated with low power therapy laser 
devices. It counts the various intervals needed for bacteria 
desinfection in mouth and teeths using laser beams. It displays among 
other information both progress circular sectors and various sounds 
every 10, 30 or 60 seconds.
I designed this using an ESP32 as microcontroller, there will be a 
wireless link between the laser device and the time controller but this 
is not important here. The internal flash is big enough to store all the 
necesarry pieces of code and images.
Yesterday came another display from Riverdi this one is the BT815 
version, although the same LCD, so the ovalizing problem remains. We 
bought it because of the "umlaut" problem of the FT8xx series, we need 
the infos to be displayed in several languages.
So there is no easy way to fix the picture distortion, i think we will 
choose the expensive better displays from Glyn.

[Rudolph (Gast)]

While it is not really obvious for me when I look at the picture, 
measuring height and width shows a clear deviation, yes.

When you already use BT815 for extended font support, why not use 
pictures for the circles?
After all, these have 64MBit of FLASH installed and a few additional 
bitmaps should be easily possible, even more so when using ASTC 
compressed images directly from the external FLASH.

And does Glyn even offer a 7" with BT815?

[Ioan Mihai Cozac (Gast)]

I should have 60 or 90 different pictures for every display situation... 
and that for more than 10 different circular elements. I should compute, 
draw and store hundreds of bitmaps...
Such a circular sector widget has the following code:
[c]
FT8_cmd_dl(DL_BEGIN | FT8_LINES);
    FT8_cmd_dl(DL_COLOR_RGB | RED);
    FT8_cmd_dl(LINE_WIDTH(1 * 16));
    int r1 = 77, r2 = 128;
    for (int t1 = 0; t1 < 6; t1++)
    { // DRAWING 6 SEGMENTS 60 DEGREES AROUND MAIN CIRCLES
      float t = (t1 / 3.00) * PI;
      FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r1 * sin(t)) * 16, y * 16 - 
(int)(r1 * cos(t)) * 16));
      FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r2 * sin(t)) * 16, y * 16 - 
(int)(r2 * cos(t)) * 16));
    }
    FT8_cmd_dl(LINE_WIDTH(7 * 16));
    //FT8_cmd_dl(DL_COLOR_RGB | RED);
    byte segments = (sec_2 / 10) * 10 + 10; // HALF WIDTH POSITIVE 
OFFSET
    for (int t1 = 0; t1 < segments; t1++)
    { // DRAWING 30 SEGMENTS BARGRAPH AROUND TIME COUNTER
      float t = (t1 / 30.00) * PI + (0.5 / 30.00) * PI;
      if (min_2 < min2_max || sec_2 < sec2_max) //PROPER DISPLAY OF THE 
RED SEGMENTS
      {
        FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r1 * sin(t)) * 16 + 
(int)(abs(32 * cos(t))), y * 16 - (int)(r1 * cos(t)) * 16));
        FT8_cmd_dl(VERTEX2F(x * 16 + (int)(r2 * sin(t)) * 16, y * 16 - 
(int)(r2 * cos(t)) * 16));
      }
    }
[c/]

Glyn has sent us a custom board for test, but our old display is only 6 
bit so the picture is not properly displayed. They said they could 
produce them for us if enough pieces will be ordered.

[Rudolph (Gast)]

Ioan Mihai Cozac schrieb:
> I should have 60 or 90 different pictures for every display situation...
> and that for more than 10 different circular elements. I should compute,
> draw and store hundreds of bitmaps...

I see, that would be indeed a lot of additional work.

Ioan Mihai Cozac schrieb:
> FT8_cmd_dl(DL_BEGIN | FT8_LINES);

Oh, so are using an older 3.x version.
I changed the FT8_ prefixes to EVE_ prefixes a long time ago.
While most of the changes have been for BT81x, there also have been a 
number of additions and fixes for the older generations.

[Ioan Mihai C. (mihaicozac)]

Yes indeed...
I will try the new version on the new BT815 display, i think all the 
settings are the same only the EVE_HAS_CRYSTAL should be set to 1.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo und viel Erfolg im neuen Jahr!
Hat schon mal jemand ein Display der Firma ACTRON mit C-Touch am FT813 
betrieben? Lt. Datenblatt des Display hat er ein C-Touch-Controller 
HY4635 mit der I2C-Adresse Hx38. Mit dem Ossci kontrolliere ich Data und 
Takt der I2C-Schnittstelle. Und der FT813 spricht den HY4635 auch mit 
dieser Adresse an, es kommt das ACK und dann nur noch ein nicht 
vollständiges Byte - Schluss! Das Merkwürdigste ist dabei, dass die 
Taktleitung dauerhaft auf Low liegt (müsste aber in Ruhe auf High 
liegen). Gibt es noch irgend ein Register des FT813 (C-Touch-Register), 
was vielleicht in diesem Fall noch entsprechend gesetzt werden muss?
Benutze ich das DEMO-Board mit FT813 und mit 5" Display (Bridgetek), so 
funktioniert mit meiner selben Software natürlich alles. Ich setze 
lediglich am Beginn einmal den REG_CTOUCH_MODE und REG_CTOUCH_EXTEND und 
kann dann z.B. den Register REG_CTOUCH_TOUCH_XY auslesen und erhalte die 
Koordinaten. Auf der I2C-Schnittstelle des Demo-Board sehe ich die 
ordnungsgemäße Kommunikation mit dem Ossci. Hier ist die Takt-Leitung 
auf High, wenn keine Kommunikation statt findet.
Hat jemand einen Tipp?????

[Rudolph R. (rudolph)]

Dazu ist gerade eine Diskussion im BRT Community Forum durch: 
http://www.brtcommunity.com/index.php?topic=62.0

Und so wie es aussieht verkauft Actron Displays von Powertip,
das passt dann also praktisch genau auf den Thread.

Um welches Modell geht es denn konkret?

Die Kurzversion ist das  man den Touch-Controller im FT813 minimal 
patchen muss um den I2C Takt niedriger einzustellen.

Edit: was zum Geier meint Actron mit I³?
Das sind doch gar keine intelligenten Displays.

Edit2: ich würde das ja auch gerne ausprobieren, aber dazu müsste ich 
dann erstmal eine Platine designen an die man so ein Display 
anschliessen kann -> dann doch lieber nicht.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudi,
guter Tipp mit "minimaler Patch". I2C ist ja allgemein bekannt als 
langsame Schnittstelle, max. 160khz (ca.). Das messe ich mal nach, was 
der FT813 da macht (Geschwindigkeit)… Und wie könnte ich die 
Geschwindigkeit dieser Schnittstelle am FT813 ändern ?????????????
Es geht konkret um das SH800480TO13-IHC09, aber das spielt keine Rolle, 
glaube ich, da ich von ACTRON leichtsinniger Weise mal vor ein paar 
Monaten schon 40 Stück verschiedener Baugrößen und Art (10x 4,3"; 10x7" 
und je 10 mit Glas-Überstand und Glas-Abschließend) geordert hatte und 
das Problem sowohl mit dem 4,3-, als auch mit dem 7-Zöller habe. Das 
geniale an den ACTRON mit ACT I3 Anschlüssen ist, dass die damit genau 
"mein" Problem gelöst haben: Es gibt so viele Displays und jedes hat 
einen anderen Anschluss (das 40-50-polige Folienkabel). "Natürlich" sind 
das keine intelligenten Displays, einfach nur Displays. Und dafür habe 
ich mir nun Display-Treiber-PLatinen mit dem FT813 gebaut und kann dank 
der ACT I3 verschiedene Display für verschiedene Anwendungen mit dem 
einen Treiber realisieren - wenn ich denn das mit dem C-Touch noch 
hinbekomme!!! Schlimmstenfalls spreche ich diese Schnittstelle am FT813 
vorbei direkt mit meinem Prozessor an … Ich weiß, wie ich dich kenne 
krämpeln sich jetzt bei dir alle Fußnägel hoch - von wegen 
"Vergewaltigung" des FT8xx . Das ist wie mit "an dem Co-Prozessor" 
vorbei selbst Buttons generieren.. Hatte dazu ja schon meinen "Rüffel" 
von Dir bekommen!
Danke für den Link zum Thread. Schaue mich da jetzt mal um!

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

OK - Exakter geht es ja tatsächlich nicht! Habe ich also nicht allein 
das Problem. Wie es aus der Diskussion hervorgeht, ist es tatsächlich 
ein Geschwindigkeitsproblem und Hinweise zur Veränderung der 
Taktgeschwindigkeit des FT813 sind dort auch zu finden. Na dann probiere 
ich mal. Und in diesem Fall scheint mir die Bedienung dieser 
Schnittstelle am FT vorbei direkt durch meinen Prozessor immer weniger 
abwegig!!!

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> I2C ist ja allgemein bekannt als
> langsame Schnittstelle, max. 160khz (ca.). Das messe ich mal nach, was
> der FT813 da macht (Geschwindigkeit)…

I2C hat normalerweise 100kHz oder 400kHz und es gibt auch noch HighSpeed 
Versionen mit 1MHz oder so.
Die FT81x/BT81x machen 400kHz und der HY4635 ist mit 100kHz glücklicher.


Bernd I. schrieb:
> Und wie könnte ich die
> Geschwindigkeit dieser Schnittstelle am FT813 ändern ?????????????

Den Wert 40 an Adresse 0x30b1ac schreiben.
Das gibt 58kHz und mit 20 bekommt man wohl so 98kHz.

Die Bilder sieht man in dem Forum meine ich nur wenn man da angemeldet 
ist.
Die haben ein "code.png" angehängt.

Und da steht drin:

/* Hycon fix */
delay(50);
Gpu_Hal_Wr8(host, REG_CPURESET, 2);
Gpu_Hal_Wr8(host, 0x301b1ac, 40);
Gpu_Hal_Wr8(host, REG_CPURESET, 0);

Also EVE_memWrite8().

Und danach besser noch so eine Schleife wie in EVE_init():

  timeout = 0;
  while (0x00 != (EVE_memRead8(REG_CPURESET) & 0x03)) /* check if EVE is in working status */
  {
    DELAY_MS(1);
    timeout++;
    if(timeout > 50)
    {
      return 0;
    }
  }

Der Touch-Controller braucht nämlich ein wenig bis er wieder aus dem 
Reset da ist.

Oder eben einfach nur ein delay(50) oder so.


Bernd I. schrieb:
> Das
> geniale an den ACTRON mit ACT I3 Anschlüssen ist, dass die damit genau
> "mein" Problem gelöst haben: Es gibt so viele Displays und jedes hat
> einen anderen Anschluss (das 40-50-polige Folienkabel).

Also im Grunde genommen das was Glyn auch mit dem "Familie Konzept" 
macht.
Und solche Faxen mit den Display-Anschlüssen sind genau der Grund warum 
ich lieber fertige Module verwende. :-)

Bernd I. schrieb:
> Und dafür habe
> ich mir nun Display-Treiber-PLatinen mit dem FT813 gebaut

Hat auch was, jetzt noch auf BT815 aufrüsten, einen Controller dazu und 
einen 3,3V Regler. :-)

Nein im Ernst, niedliches Platinchen.
Die Displays haben einen Regler für die Beleuchtung integriert?
12V ist da schon etwas ungewöhnlich.

Bernd I. schrieb:
> Schlimmstenfalls spreche ich diese Schnittstelle am FT813
> vorbei direkt mit meinem Prozessor an … Ich weiß, wie ich dich kenne
> krämpeln sich jetzt bei dir alle Fußnägel hoch - von wegen
> "Vergewaltigung" des FT8xx .

Keine Ahnung was Du meinst. :-)
Es gibt genau für sowas den sogenannten "Host" Mode bei dem der 
Controller im Ziel-System die I2C Kommunikation mit dem Touch-Controller 
abwickelt und die Daten an den FT81x schickt damit dieser die auswertet.
Das ist sicherlich lästig und I2C gefällt mir so oder so nicht, aber 
bevor man eben gar keinen Touch hat, weil EVE nicht mit dem 
Touch-Controller spielen will...

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Rudi schrieb:
Die Bilder sieht man in dem Forum meine ich nur wenn man da angemeldet
ist.
Die haben ein "code.png" angehängt.

Und da steht drin:
/* Hycon fix */
delay(50);
Gpu_Hal_Wr8(host, REG_CPURESET, 2);
Gpu_Hal_Wr8(host, 0x301b1ac, 40);     ICH HOFFE, DAS IST EIN 
SCHREIBFEHLER !
Gpu_Hal_Wr8(host, REG_CPURESET, 0);

Hallo Rudi,
ich traue mich nicht so recht, in den Bereich 30b1ac einen Wert zu 
schreiben (die 40). Dieser Bereich ist im Datenblatt nirgendwo 
benannt/beschrieben!
Der letzte Bereich endet bei 308FFF (der Command Buffer). Und ich hoffe, 
das da oben ist ein Schreibfehler - eine Eins zu viel hinter der 30. 
Denn der Herr "BRT Community" schreibt ja auch vom 30b1ac oder den 
RAM_JBOOT + 1ac.
Über den RAM_JBOOT finde ich nichts !!! Soll ich also ??? :):) Und an 
anderer Stelle schreibts Du selbst auch 30b1ac
Denn wenn man mal eben an eine falsche Stelle etwas schreibt, kann der 
FTI danach auch hinüber sein!

Das mit den 12V für die Hintergrundbeleuchtung ist tatsächlich etwas 
ungewöhnlich, bedeutet aber eben nur eine Ader zu meinem "Platinchen" 
mehr. Der Regler ist auf dem Display, der kommt aber eben nicht mit 3,3V 
aus, sondern braucht mind. 5V (max. 17V).

OK ich traue mich jetzt!

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Ich habe mich getraut !!!
Nachdem sich die Rauchwolke verzogen hatte …

Nein - alles Super. I2C arbeitet jetzt auf 57kHz (gemessen) und der 
Touch funktioniert! Auf alles andere hat diese Taktveränderung doch wohl 
keinen Einfluss ???

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Da meine "Platinchen" ja nun zu 100% so funktionieren, wie ich es mir 
gedacht hatte, kann ich ja mal 100 Stück davon fertigen lassen (wir 
machen bei uns im Haus, außer ein paar Muster keine SMD-Bestückung, nur 
THT). Möchtest Du eine davon? Würde ich Dir schenken, als kleines 
Dankeschön für die Hilfe!!!
Aber die sind eben nur für die ACTRON-Display's nützlich!

Schönen Sonntag noch.

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Über den RAM_JBOOT finde ich nichts !!! Soll ich also ??? :):) Und an
> anderer Stelle schreibts Du selbst auch 30b1ac

Ja, Tippfehler. :-)
RAM_JBOOT gibt es auch nirgendwo in den Unterlagen, das stammt sicher 
aus internen Unterlagen von FTDI/Bridgetek.

Das ist der Bereich in dem der Code für den Touch-Controller liegt.
da kann man auch nichts kaputt machen, von der Architektur sehen die EVE 
nämlich so aus, dass die ein ROM haben (oder vielleicht auch ein FLASH), 
das beim Start in RAM kopiert wird, ein Shadow-RAM.
So funktionieren auch die FT9xx von FTDI.
Man kann den Speicher zwar nicht auslesen, aber beschreiben geht.

In AN_336 gibt es Binär-Blobs die an diese Stelle kopiert werden.
Das sieht man da nicht direkt, da der Blob in den Kommando Co-Processor 
geschrieben und ausgeführt wird.
Wenn man das aber zerlegt, kommt man schnell dahinter das da im 
wesentlichen ein CMD_INFLATE die Daten an 0x3b1ac entpackt.

Spannende Sache, die EVE sind also patchbar, viel weiter als das bin ich 
aber noch nicht gekommen, da sich FTDI/BRT da sehr bedeckt hält.
Die haben intern sicherlich ein SDK dafür.
Was die in den Thread gepackt haben hat mich jetzt ein wenig überrascht.

Bernd I. schrieb:
> Möchtest Du eine davon? Würde ich Dir schenken, als kleines
> Dankeschön für die Hilfe!!!
> Aber die sind eben nur für die ACTRON-Display's nützlich!

Ich würde eine nehmen, klar, ab in die Sammlung. :-)
Aber erstmal muss ich schauen ob ich ein Display dafür bekomme.
Actron sind aber nicht die einzigen die Displays von Powertip 
vertreiben.
Dann 8 Fädeldrähte und es sollte laufen. :-)

[Rudolph R. (rudolph)]

Interessant, Powertip hat FT813 Displays im Sortiment von denen ich noch 
nie gehört habe.

PH800480T024-IFC03 5"
PH800480T013-IFC05 7"

Leider kann ich dazu nichts finden, keine Datenblätter, kein 
Distributor.

[Rudolph R. (rudolph)]

Rudolph R. schrieb:
> Bernd I. schrieb:
>> Möchtest Du eine davon? Würde ich Dir schenken, als kleines
>> Dankeschön für die Hilfe!!!
>> Aber die sind eben nur für die ACTRON-Display's nützlich!
>
> Ich würde eine nehmen, klar, ab in die Sammlung. :-)

Okay, ich habe intensiv gesucht und ich würde dann eher doch keines 
nehmen, aber vielen Dank für das Angebot!

Dazu passen praktisch nur eine Handvoll Displays:

PH320240T023-IHC04 PH320240T023-IHC06
PH480272T009-IHC05 PH480272T009-IHC07
PH800480T024-IHC07 PH800480T024-IHC11
PH800480T013-IHC09 PH800480T013-IHC12

Und die bekomme ich zum einen allesamt nicht einfach so bestellt.
Dann fallen die ersten 4 mit 3,5" und 4,3" auch praktisch gleich raus.

Wenn man tatsächlich Produkte verkauft sieht die Sache sicher anders 
aus, dann kann man da über die Mengen ganz anders heran gehen.

Da die Ganze Geschichte für mich aber eher ein Hobby ist, wenn auch mit 
dem Benefit gelegentlich dienstlich Arbeit zu generieren, kaufe ich 
Displays nur in niedrigen einstelligen Stückzahlen.
Ich habe gerade ein 5" EVE2-50G auf dem Tisch das als Einzelstück an 
einen Kunden geht.
Und daneben liegt ein 4,3" EVE3-43G für das ich eine Demo-Software 
vorbereite um Kollegen davon zu überzeugen die Neu-Auflage eines 
Haus-internen Tools mit Display zu machen.
Davon brauche ich dann vielleicht mal >10 Stück.
Als nächstes werde ich dann wohl wieder ein 7" als Einzelstück in einen 
Testplatz stecken dürfen.
Okay, ich habe praktisch den ganzen Spass ohne Probleme wie 
Produktkosten wirklich berücksichtigen zu müssen. :-)

Also für mich lohnt sich das einfach nicht einzelne Displays mit eigenen 
FT81x/BT81x Platinen zu verwenden

[Ioan Mihai C. (mihaicozac)]

Found a pretty simple workaround for the ovalization, i draw 2 points 
for every point needed, with the center vertically misaligned, about 6% 
of the radius of points. Mathematically is not quite a perfect circle 
but optically looks much better as before.
But i have some trouble with the newest version of your EVE, there is an 
error that appears regarding the SPI library. It apperas regardless if i 
use the FT813 or the BT815 display.
IDE is VS Code for Platform.io, microcontroller is ESP32 and the error 
is like this:

In file included from src\EVE_target.h:849:0,
                 from src\EVE_commands.c:192:
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:28:1: error: unknown type name 'class'
 class SPISettings
 ^
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:29:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
In file included from src\EVE_target.h:849:0,
                 from src\EVE_commands.c:192:
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:38:1: error: unknown type name 'class'
 class SPIClass
 ^
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:39:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\libraries\SPI\src/SPI.h:86:8: error: unknown type name 'SPIClass'
 extern SPIClass SPI;
        ^
In file included from C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\cores\esp32/Arduino.h:35:0,
                 from src\EVE_target.h:850,
                 from src\EVE_commands.c:192:
C:\Users\Mihai\.platformio\packages\framework-arduinoespressif32\cores\esp32/esp32-hal.h:48:0: warning: "NOP" redefined
 #define NOP() asm volatile ("nop")
 ^
In file included from src\EVE_commands.c:191:0:
src\EVE.h:755:0: note: this is the location of the previous definition
 #define NOP() ((45UL<<24))
 ^
In file included from src\EVE_commands.c:192:0:
src\EVE_target.h: In function 'EVE_cs_set':
src\EVE_target.h:882:6: error: request for member 'setDataMode' in something not a structure or union
   SPI.setDataMode(SPI_MODE0);
      ^
src\EVE_target.h: In function 'spi_transmit_async':
src\EVE_target.h:894:7: error: request for member 'write' in something not a structure or union
    SPI.write(data);
       ^
src\EVE_target.h: In function 'spi_transmit':
src\EVE_target.h:899:7: error: request for member 'write' in something not a structure or union
    SPI.write(data);
       ^
src\EVE_target.h: In function 'spi_receive':
src\EVE_target.h:915:13: error: request for member 'transfer' in something not a structure or union
   return SPI.transfer(data);
             ^
src\EVE_target.h:916:2: warning: control reaches end of non-void function [-Wreturn-type]
  }
  ^

Using the older FT8... library the program compiles and runs OK.

[Rudolph R. (rudolph)]

Ioan Mihai C. schrieb:
> Found a pretty simple workaround for the ovalization, i draw 2 points
> for every point needed, with the center vertically misaligned, about 6%
> of the radius of points. Mathematically is not quite a perfect circle
> but optically looks much better as before.

Interesting, thank you for the suggestion.

Ioan Mihai C. schrieb:
> But i have some trouble with the newest version of your EVE, there is an
> error that appears regarding the SPI library.

This is a "feature" of Arduino that for "reasons" the classes are not 
supposed to work with plain .c files.
It should work just fine if you rename "EVE_commands.c" to 
"EVE_commands.cpp".

There might be a solution to fix that without renaming the file but I 
have not found one yet and I am normally not reminded about this since I 
am normally not using the Arduino framework.

Plus that renaming the file works kind of tells me that the issue is not 
really on my side...

[Karol B. (karol_b135)]

Hi Rudolph! A lot of thanks for your job. I still have very old lib, its 
working with FT800 and FT810 well. I have RVT70UQFNWC00 from Riverdi and 
a lot of problems with it. Pleas visit url link, there are schematic, 
PCB, some C listing and movie. Could you give me an advice what I do 
wrong? I mage another project with the same tft panel and its workinkg 
well. Im getting crazy, I spent more then 2 days traing to fix it. Pleas 
help.

Beitrag "FT800 / FT810 Library"

[Karol B. (karol_b135)]

Hi Rudolph! A lot of thanks for your job. I still have very old lib, its 
working with FT800 and FT810 well. I have RVT70UQFNWC00 from Riverdi and 
a lot of problems with it. Pleas visit url link, there are schematic, 
PCB, some C listing and movie. Could you give me an advice what I do 
wrong? I mage another project with the same tft panel and its workinkg 
well. Im getting crazy, I spent more then 2 days traing to fix it. Pleas 
help.
Beitrag "FT800 / FT810 Library"

https://www.elektroda.pl/rtvforum/viewtopic.php?p=18496421#18496421

[Rudolph (Gast)]

Hello,

I can have a closer look when I am home again.

But please describe what the problem actually is.
I had to translate the website to Englisch and I am not sure if it got 
lost in translation but there is no description of the issue.

Also, please attach the code here as well, I would need to login to that 
other forum in order to see it.

And then, why not just switch to the latest version of my library?

[Karol B. (karol_b135)]

Thanks for your answer.
There is a movie, didn't you saw it?
I have a lot of strange behavior of display. Its live on his own life, 
changing all elements on screen also pressing touch without physical 
finger touch.

void ft800_init(void)
{
  uint8_t chipid;
  uint16_t timeout = 0;
  
  FT_PDN_DDR |= FT_PDN;
  FT_CS_DDR |= FT_CS;

  FT_PDN_PORT &= ~FT_PDN;
  DELAY_MS(6);  // minimum time for power-down is 5ms
  FT_PDN_PORT |= FT_PDN;
  DELAY_MS(21);  // minimum time to allow from rising PD_N to first access is 20ms

  //ft800_cmdWrite(FT_CLKEXT);  // Set FT800 for external clock
  ft800_cmdWrite(FT_CLKINT);
  ft800_cmdWrite(FT_CLK48M);  // FT_CLK48M Set FT800 for 48MHz PLL
  ft800_cmdWrite(FT_ACTIVE);  // Start FT800

  chipid = ft800_memRead8(REG_ID);  // Read ID register
  while(chipid != 0x7C)  // if chipid is not 0x7c, continue to read it until it is, FT81x may need a moment for it's power on selftest
  {
    chipid = ft800_memRead8(REG_ID);
    DELAY_MS(1);
    timeout++;
    if(timeout > 400)
    {
      break;//return 0;
    }
  }

  ft800_memWrite8(REG_PCLK, 0x00);    // Set PCLK to zero - don't clock the LCD until later
  ft800_memWrite8(REG_PWM_DUTY, 30);    // Turn off backlight

  // Initialize Display
  ft800_memWrite16(REG_HSIZE,   FT_HSIZE);  // active display width
  ft800_memWrite16(REG_HCYCLE,  FT_HCYCLE);  // total number of clocks per line, incl front/back porch
  ft800_memWrite16(REG_HOFFSET, FT_HOFFSET);  // start of active line
  ft800_memWrite16(REG_HSYNC0,  FT_HSYNC0);  // start of horizontal sync pulse
  ft800_memWrite16(REG_HSYNC1,  FT_HSYNC1);  // end of horizontal sync pulse
  ft800_memWrite16(REG_VSIZE,   FT_VSIZE);  // active display height
  ft800_memWrite16(REG_VCYCLE,  FT_VCYCLE);  // total number of lines per screen, incl pre/post
  ft800_memWrite16(REG_VOFFSET, FT_VOFFSET);  // start of active screen
  ft800_memWrite16(REG_VSYNC0,  FT_VSYNC0);  // start of vertical sync pulse
  ft800_memWrite16(REG_VSYNC1,  FT_VSYNC1);  // end of vertical sync pulse
  ft800_memWrite8(REG_SWIZZLE,  FT_SWIZZLE);  // FT800 output to LCD - pin order
  ft800_memWrite8(REG_PCLK_POL, FT_PCLKPOL);  // LCD data is clocked in on this PCLK edge
  ft800_memWrite8(REG_CSPREAD,  FT_CSPREAD);  /* helps with noise, when set to 1 fewer signals are changed simultaneously, reset-default: 1 */
  // Don't set PCLK yet - wait for just after the first display list

  ft800_memWrite8(REG_ROTATE, 1);  // rotate display by 180°

  // Configure Touch
  ft800_memWrite8(REG_TOUCH_MODE, FT_TMODE_CONTINUOUS);  // enable touch
  ft800_memWrite16(REG_TOUCH_RZTHRESH, FT_TOUCH_RZTHRESH);  // Eliminate any false touches

  // Configure Audio - not used, so disable it
  ft800_memWrite8(REG_VOL_PB, 0x00);      // turn recorded audio volume down
  ft800_memWrite8(REG_VOL_SOUND, 0x00);    // turn synthesizer volume off
  ft800_memWrite16(REG_SOUND, 0x6000);    // set synthesizer to mute

  ft800_memWrite32(FT_RAM_DL, DL_CLEAR_RGB);
  ft800_memWrite32(FT_RAM_DL + 4, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
  ft800_memWrite32(FT_RAM_DL + 8, DL_DISPLAY);  // end of display list
  ft800_memWrite32(REG_DLSWAP, FT_DLSWAP_FRAME);

  ft800_memWrite8(REG_GPIO, 0x80);  // Enable the DISP signal to the LCD panel
  ft800_memWrite8(REG_PCLK, FT_PCLK);  // Now start clocking data to the LCD panel

  ft800_memWrite8(REG_PWM_DUTY, 70);  // Turn on backlight
  ft800_memWrite8(REG_INT_EN,1);      // włączam przerwana)

  DELAY_MS(10);  // just to be safe
  cmdOffset =ft800_memRead16(REG_CMD_WRITE);
}

///////////////////////////////////////////////////////////////////////////////////////
// kilka podstawowych funkcji do obsługi FT8xx
// atmega128
void init_spi(void)
{
  SPCR = (1<<SPE) | (1<<MSTR);  // SPI on, MSB first, Mode 0, Master, 
  //SPSR = (1<<SPI2X);      // Fosc/2 
  SPCR |= (1<<SPR0);        //     /16
}
void ft800_memWrite8(uint32_t ftAddress, uint8_t ftData8)
{
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));    // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit(ftData8);      // Send data byte
  ft800_cs_clear();
}
void ft800_memWrite16(uint32_t ftAddress, uint16_t ftData16)
{
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));    // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit((uint8_t)(ftData16));    // Send data low byte
  spi_transmit((uint8_t)(ftData16 >> 8));    // Send data high byte
  ft800_cs_clear();
}
void ft800_memWrite32(uint32_t ftAddress, uint32_t ftData32)
{
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));    // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit((uint8_t)(ftData32));    // Send data low byte
  spi_transmit((uint8_t)(ftData32 >> 8));
  spi_transmit((uint8_t)(ftData32 >> 16));
  spi_transmit((uint8_t)(ftData32 >> 24));    // Send data high byte
  ft800_cs_clear();
}
void ft800_cmdWrite(uint8_t data)
{
  ft800_cs_set();
  spi_transmit(data);
  spi_transmit(0x00);
  spi_transmit(0x00);
  ft800_cs_clear();
}
// Beginn a co-processor command
void ft800_start_cmd(uint32_t command)
{
  uint32_t ftAddress;

  ftAddress = FT_RAM_CMD + cmdOffset;
  ft800_cs_set();
  spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); // Send Memory Write plus high address byte
  spi_transmit((uint8_t)(ftAddress >> 8));  // Send middle address byte
  spi_transmit((uint8_t)(ftAddress));    // Send low address byte
  spi_transmit((uint8_t)(command));    // Send data low byte
  spi_transmit((uint8_t)(command >> 8));
  spi_transmit((uint8_t)(command >> 16));
  spi_transmit((uint8_t)(command >> 24));    // Send data high byte
  ft800_inc_cmdoffset(4);      // update the command-ram pointer
}
// virtually the same as ft800memWrite32() but calculating the address and offset as the other commands
void ft800_cmd_dl(uint32_t command)
{
  ft800_start_cmd(command);
  ft800_cs_clear();
}
//
void page_start(void)
{
  ft800_cmd_dl(CMD_DLSTART); // Start the display list
  ft800_cmd_dl(DL_CLEAR_RGB | GRAY_LIGHT2); // Set the default clear color 
  ft800_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); // Clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers
}
//
void page_stop(void)
{
  ft800_cmd_dl(DL_DISPLAY);  // Instruct the graphics processor to show the list
  ft800_cmd_dl(CMD_SWAP); // Make this list active
  ft800_cmd_execute();
  _delay_ms(5);
  uint8_t int_mask = ft800_memRead8(REG_INT_FLAGS);
}
//

//przykładwe użycie:
const  uint8_t ds1307_daysinmonth [] PROGMEM = { 31,28,31,30,31,30,31,31,30,31,30,31 };
void ustaw_zegar(uint8_t minuty,uint8_t godziny,uint8_t dzien,uint8_t miesiac,uint8_t rok)
{
  uint8_t CurrTag=0,Pendown=0,PrevTag = 0, space;
  uint16_t tmp;
  btn_struct btn_s;
  char tmp_str[100];

  while(PrevTag!=TAG_OK && PrevTag!=TAG_CANCEL)
  {
    strcpy(tmp_str,num2string(2000+rok,NONE)); strcat(tmp_str,"/"); if(miesiac<10)  strcat(tmp_str,"0");
    strcat(tmp_str,num2string(miesiac,NONE)); strcat(tmp_str,"/"); if(dzien<10)  strcat(tmp_str,"0");
    strcat(tmp_str,num2string(dzien,NONE)); strcat(tmp_str,"  "); if(godziny<10)  strcat(tmp_str,"0");
    strcat(tmp_str,num2string(godziny,NONE)); strcat(tmp_str,":"); if(minuty <10) strcat(tmp_str,"0");
    strcat(tmp_str,num2string(minuty,NONE)); //strcat(tmp_str,":"); if(sekundy <10) strcat(tmp_str,"0");
    //
    if(!timDisp)
    {
      timDisp = 10;    
      page_start();  
      
      ft800_cmd_fgcolor(RED);
      ft800_cmd_gradcolor(RED);  //gradient przycisków
      ft800_cmd_dl(DL_COLOR_RGB | BUTTONS_TEXT_COLOR);    // kolor 
      
      ft800_cmd_ramfont(1, 34);
      ft800_cmd_dl(DL_COLOR_RGB | WHITE);  // kolor tekstu 
      ft800_cmd_text(800/2,200,1,FT_OPT_CENTERX|FT_OPT_CENTERY,tmp_str);
      
      space = 10; btn_s.w=(800-3*space)/2; btn_s.h=70; btn_s.y= 480-space-btn_s.h;
      btn_s.x=800-btn_s.w-space; btn_s.color=11141120; btn_s.tag=TAG_OK;
      draw_button_text2(btn_s,CurrTag,30,"ZAPIASZ");
      
      btn_s.color=2434341;  // ciemny szary
      btn_s.x=space;   btn_s.tag=TAG_CANCEL;
      draw_button_text2(btn_s,CurrTag,30,"ANULUJ"); //strcpy_P(tmp_str, txt[5+lng])
      
      ft800_cmd_dl(DL_COLOR_RGB | BLACK);  // kolor tekstu 
      space = 65; btn_s.w=180; btn_s.h=60; btn_s.y= 70;
      btn_s.x=30; btn_s.color=YELLOW; btn_s.tag=10;
      draw_button_text2(btn_s,CurrTag,31,"+");      
      
      btn_s.x+=btn_s.w+space+1; btn_s.w=70; btn_s.color=YELLOW; btn_s.tag=11;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.x+=btn_s.w+space+10; btn_s.color=YELLOW; btn_s.tag=12;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.x+=btn_s.w+space+5; btn_s.color=YELLOW; btn_s.tag=13;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.x+=btn_s.w+space-3; btn_s.color=YELLOW; btn_s.tag=14;
      draw_button_text2(btn_s,CurrTag,30,"+");
      
      btn_s.w=180;btn_s.y= 270;
      btn_s.x=30; btn_s.color=YELLOW; btn_s.tag=15;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space+1; btn_s.w=70; btn_s.color=YELLOW; btn_s.tag=16;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space+10; btn_s.color=YELLOW; btn_s.tag=17;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space+5; btn_s.color=YELLOW; btn_s.tag=18;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      btn_s.x+=btn_s.w+space-3; btn_s.color=YELLOW; btn_s.tag=19;
      draw_button_text2(btn_s,CurrTag,31,"-");
      
      page_stop();
    }
      
    CurrTag = ft800_memRead8(REG_TOUCH_TAG);
    Pendown = ((ft800_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01);
    if(( 1 == Pendown) && (CurrTag != PrevTag))
    {
      if(PrevTag == 14){
        minuty++;
        if(minuty>59)minuty = 0;
      }
      if(PrevTag == 13){
        godziny++;
        if(godziny>23) godziny = 0;
      }
      if(PrevTag == 12){
        dzien++;
        if(dzien>pgm_read_byte(ds1307_daysinmonth + miesiac - 1)) dzien = 0;
      }
      if(PrevTag == 11){
        miesiac++;
        if(miesiac>12) miesiac = 1;
      }
      if(PrevTag == 10){
        rok++;
        if(rok>99) rok = 19;
      }
      if(PrevTag == 15){
        if(rok>19)rok--;
        else rok = 99;
      }
      if(PrevTag == 16){
        if(miesiac)miesiac--;
        else miesiac = 12;
      }
      if(PrevTag == 17){
        if(dzien)dzien--;
        else dzien = pgm_read_byte(ds1307_daysinmonth + miesiac - 1);
      }
      if(PrevTag == 18){
        if(godziny)godziny--;
        else godziny = 23;
      }
      if(PrevTag == 19){
        if(minuty)minuty--;
        else minuty = 59;
      }
      sygnal(100,1,1);
    }
    PrevTag = CurrTag;
  }
  // oczekiwanie na zwolnienie przycsiku
  while(!(ft800_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01){};
  if(PrevTag == TAG_OK)
  {
    tmp = ((minuty&0x3F)) | ((godziny&0x3F) <<6);
    send_tx_frame_wait(48,CMD_SET_TINE,tmp>>8,(uint8_t)tmp);  // wysyłam dane przez rs485 do innego modułu
    tmp = (dzien&0x1F) | ((miesiac&0x0F) << 5) | ((rok&0x3F) <<9);
    _delay_ms(50);
    send_tx_frame_wait(49,CMD_SET_DATE,tmp>>8,(uint8_t)tmp);  // wysyłam dane przez rs485 do innego modułu
  }
  _delay_ms(100);      
}

F_CPU=11059200 (is it to slow?)
Atmega 128, hardware SPI
PD=PINE6
CS=PINB4

Here are sch and pcb:
https://obrazki.elektroda.pl/2410018900_1582788848.png
https://obrazki.elektroda.pl/4933762200_1582788970.png

And movie:
https://filmy.elektroda.pl/54_1582790312.mp4

Regards,
Karol

[Rudolph (Gast)]

Karol B. schrieb:
> There is a movie, didn't you saw it?

Yes, but apparently it played too small on the forum, I looked at it 
again and yes, it glitches.

> I have a lot of strange behavior of display. Its live on his own life,
> changing all elements on screen also pressing touch without physical
> finger touch.

Have you checked your 3.3V?
This displays draws current of 130mA or more on the 3.3V line.
I can not tell from the pictures which of the two 3.3V regulators is 
actually used for the display.
But, while I find no data for a LD117A, only LD1117A, the datasheet for 
the LD1117 lists 10µF minimum capacatiy at the output and you only have 
4.7µF.

And the APE8865-3 is designed to be stable with low ESR ceramic 
capacitors with 30mR to 50mR but it looks like you placed a tantalum cap 
there.
From what I can see in the video C12 at the display-connector also is a 
tantalum type.
Unless these are ultra low ESR types that might be the problem.

Annother idea, it looks like the case is made of metall and the 
anti-static bag under the display is a conductive one.
Please remove the display from the case and place it on a non-conductive 
underground.

>F_CPU=11059200 (is it to slow?)

This should be no problem.

I have to check the software later, looks like I need to translate some 
parts.

[Karol B. (karol_b135)]

PCB has 2 options for 3.3V regulator (1117-33 or APE8865Y5) I use only 
1117 series (spx1117m3-l-3-3). 1uF on input nad 100nF+4uF7 (tantalum) on 
output.
I checked by powered up pcb from laboratory power suplyy, still the same 
issue on display. That's weird but screen callibration or built in logo 
are working fine.

I placeed display on a non-conductive underground.

I have the same program working on anbother PCB, there are only a little 
changes:
- CS=PINB5, PD=PINB4
- ATMEGA128A@5V + 74125 for SPI level shift

As you can see on scheamtic, my connections on no-working PCB are: 
CS=PINB4, PD=PINE6, ATmega128A@3.3V

[Rudolph (Gast)]

Karol B. schrieb:
> I use only 1117 series (spx1117m3-l-3-3). 1uF on input nad
> 100nF+4uF7 (tantalum) on output.

So this is the one from Exar, what type exactly is the 4µ7 output 
capacitor?
What is the exact modell number or where did you order it from?

Karol B. schrieb:
> I checked by powered up pcb from laboratory power suplyy, still the same
> issue on display.

But you supplied 5V?

> That's weird but screen callibration or built in logo are working fine.

These are really simple commands, there is not much going over the SPI 
for these.

Karol B. schrieb:
> I have the same program working on anbother PCB, there are only a little
> changes:
> - CS=PINB5, PD=PINB4
> - ATMEGA128A@5V + 74125 for SPI level shift
>
> As you can see on scheamtic, my connections on no-working PCB are:
> CS=PINB4, PD=PINE6, ATmega128A@3.3V

This should work just fine.
11MHz should be well within the allowable frequence for 3.3V.
The only issue I could think of would be that PB0 is not set to output.

[Karol B. (karol_b135)]

>4µ7 output capacitor? =>
TAJA475K006R from www.tme.eu

>But you supplied 5V?
Both, 5V+3.3V (3.3 LDO was present but current flow thrue it was equal 
or near 0mA)

I'm preaty sure now, the point is my pcb. The same program (only CS/PD 
pin connection are diferent) work fine on another PCB, but there are 
74xx125 level shifter.
Maybe the point is about SPI connection:
1) working fine => Atmega128@5V -> SPI thru 74LCX125MTC -> TFT
2) working bad => Atmega128@3.3V -> SPI direct to -> TFT
However, I saw on osciloscope shape of signals, they looks fine, I 
think.

PS. From some time, I allways set PB0 (SS) as output.
By the way, if it is an output, can I change state (PORTB0) in 
interrupt routine?

[Rudolph (Gast)]

Karol B. schrieb:
>>4µ7 output capacitor? =>
> TAJA475K006R from www.tme.eu

Okay, this is the wrong capacitor for the job, the ESR is way too large.
Please replace it with a 4µ7 ceramic or put 2µ2+ in parallel to it.

>>But you supplied 5V?
> Both, 5V+3.3V (3.3 LDO was present but current flow thrue it was equal
> or near 0mA)

Hmm, okay.

> I'm preaty sure now, the point is my pcb. The same program (only CS/PD
> pin connection are diferent) work fine on another PCB, but there are
> 74xx125 level shifter.
> Maybe the point is about SPI connection:
> 1) working fine => Atmega128@5V -> SPI thru 74LCX125MTC -> TFT
> 2) working bad => Atmega128@3.3V -> SPI direct to -> TFT
> However, I saw on osciloscope shape of signals, they looks fine, I
> think.

I recently had an issue with an ATSAMC21 running at 3.3V and driving the 
SPI directly.
But that was because the ATSAMC21 is a lot weaker at driving the pins 
than the Mega128.
Also I was running the SPI at more than double the speed.
You could try to patch in a buffer for MOSI and SCK, something like a 
NC7WZ16P6X.
For MISO I am using a 74VHC1GT125 since I was hoping it would solve the 
issue that the data gets corrupted when reading with 24MHz - and it did 
not.

> PS. From some time, I allways set PB0 (SS) as output.

Excellent.

> By the way, if it is an output, can I change state (PORTB0) in
> interrupt routine?

Sure, this should not interfere with anything.

[Karol B. (karol_b135)]

MISO line:
https://obrazki.elektroda.pl/6391929500_1582828139.jpg
The same shape is present on PCB with 74xx125 buffer.

I have built several new tiles, this is the rule - it works with buffer, 
and without buffer doesn't.

What's the matter? As you said, Atmega128 has enough Pin-current to 
drive directly SPI interface. Also, speed isn't to fast (now I slow 
down: SPCR |= (1<<SPR0| 1<<SPR1); @ F_CPU=11059200).

PS. I have tryed run new librarry. I changed SMAC21 project (create new 
one with ATmega128, slect TFT, set PD,CS lines and still have blank 
screen).

[Rudolph R. (rudolph)]

That on the MISO line is quite normal, if you plot CS with it this 
should happen very shortly after CS goes high.
The line is just not driven anymore.

Karol B. schrieb:
> As you said, Atmega128 has enough Pin-current to
> drive directly SPI interface.

I can not find it in the datasheet right now but the M128-A should be 
able to drive at least 10mA @ 3.3V while the C21 can drive at best 6mA 
with two dedicated high-current pins while all the other pins can only 
drive 3mA.
And the 6mA is not enough, I had to put a second pin-pair for SCK and 
MOSI in parallel to make it work - which of course is no option with the 
M128-A.

I will add a buffer to my design and that is hopefully the end of it.

And the worst part of that issue was that the display just crashed after 
a few seconds for no apparent reason.
The voltage levels looked totally fine to me.
I had a small filter with 10R and 22pF and did quite some measurements, 
nothing worked.
Then I just put two 741G125 buffers in the SCK and MISO lines and it 
worked up to maximum speed.

Annother issue I had before that was with a board that had a slightly 
unstable 3.3V.
It would flicker on startup and after a short time the touch-controller 
crashed.
On a hunch I changed three caps on the board, I put an extra cap in 
parallel to the ouput-cap of my stepdown, the switched the boost cap at 
this stepdown in case I put on the wrong part and I put a second cap in 
parallel at the input to the stepdown.
One of these, or two or all three together did the trick and that 
display is rock solid now.


Anyways, I put together a small test version for the M128-A that might 
be even working - it compiles fine but I can not test it.
The init_ports() function might need adjustment to play nice with your 
board.
Oh yes, and the profiling values are completely wrong due to that 
strange clock of 11.0592MHz.

[Ioan Mihai C. (mihaicozac)]

Had this kind of self-tapping display error and found that the supply 
voltage was not stable enough, sometimes the current draw spikes and it 
leads to register corruption. Try with another power supply or use a 
extra ground wire from display to module, this helps also minimizing the 
audio noise if you use this function.

[Simon (Gast)]

Hallo Rudolph,

auch von meiner Seite ein großes Dankeschön für deinen Treiber. Aktuell 
bin ich dabei diesen für meine Zwecke anzupassen. Dieser Thread hat mir 
bei einigen Problemen und Fragen zum BT-Chip weitergeholfen, allerdings 
bin ich jetzt auf ein Problem gestoßen, zu dem ich weder hier noch sonst 
wo etwas finden konnte.
Ich habe verschiedene Schriften konvertiert und auf den externen Flash 
gespielt. Das funktionierte bisher auch wie gewünscht.
Jetzt benötige ich allerdings verschiedene Symbole. Dafür habe ich mir 
die entsprechenden Schriften generiert, die diese Symbole beinhalten und 
die Symbole über UTF-8 Kodierung ausgegeben. Das funktioniert allerdings 
nur bis Codepage EF (Bsp.: E2 AF 85 zzgl. 0 zur Terminierung). Sobald 
die Symbole nach UTF-8 mit vier Bytes kodiert werden müssen (Bsp.: F0 9F 
A1 83 zzgl. 0 zur Terminierung), werden diese bei mir auf dem Display 
nicht mehr dargestellt.
Für die Darstellung der Schrift bzw. der Symbole verwende ich die 
EVE_cmd_text Funktion. Der Text wird allerdings nicht der Funktion 
übergeben, sondern vorher in einen entsprechenden Text-Buffer 
geschrieben. Diese Veränderung ist notwendig, um Abwärtskompaitbilität 
zur Software des vorherigen Displays gewährleisten zu können.

Codebeispiel:

switch (direction)

         {
            case 0://arrow up
            {

               arrow_x = x1+((x2-x1)/2)-20;
               arrow_y = y1+((y2-y1)/2)-12;

               EVE_cmd_setfont2(13, SPECIAL_FONT2_RAM_ADR,0); //special font

         //Dieser Pfeil wird korrekt dargestellt
               LCD_FuncData.text_buffer[0] =0xE2;
               LCD_FuncData.text_buffer[1] =0xAF;
               LCD_FuncData.text_buffer[2] = 0x85;
               LCD_FuncData.text_buffer[3] = 0;
               break;
            }
            case 1://arrow down
            {
               arrow_x = x1+((x2-x1)/2)-20;
               arrow_y = y1+((y2-y1)/2)-12;

               EVE_cmd_setfont2(13, SPECIAL_FONT2_RAM_ADR,0); //special font

         //Dieser Pfeil wird nicht angezeigt
               LCD_FuncData.text_buffer[0] =0xF0;
               LCD_FuncData.text_buffer[1] =0x9F;
               LCD_FuncData.text_buffer[2] = 0xA1;
               LCD_FuncData.text_buffer[3] = 0x83;
               LCD_FuncData.text_buffer[4] = 0;
               break;
            }
  }

  if (button_down)
        {
               EVE_cmd_button(x1,y1,x2-x1,y2-y1,13,EVE_OPT_FLAT); //hier wird die Beschriftung des Buttons über EVE_write_string aufgerufen und der Buffer-Inhalt an den BT816 übertragen
        }
        else
        {
               EVE_cmd_button(x1,y1,x2-x1,y2-y1,13,0);
        }

Vielleicht hat hier ja jemand eine Idee warum dieses Problem aufritt. 
Über einen Lösungsansatz würde ich mich freuen.

Grüße Simon

[Karol B. (karol_b135)]

> von Ioan Mihai C:
I tried with another power supply with no effect. FPC between TFT module 
and my PBC is 10cm long (sometimes even 20cm long) also with no 
difference. I will try add some extra ground.
For now, I made 4 pcb extra with the same uC but also with 74x125  IC 
buffer. Its look terrible but is working :)

>Rudolph,
THX for EVE_Test_M128_RVT70.zip, I will try in few days (I hope today, 
I'm really cant wait for it :) )

[Rudolph R. (rudolph)]

Simon schrieb:
> Ich habe verschiedene Schriften konvertiert und auf den externen Flash
> gespielt. Das funktionierte bisher auch wie gewünscht.
> Jetzt benötige ich allerdings verschiedene Symbole. Dafür habe ich mir
> die entsprechenden Schriften generiert, die diese Symbole beinhalten und
> die Symbole über UTF-8 Kodierung ausgegeben. Das funktioniert allerdings
> nur bis Codepage EF (Bsp.: E2 AF 85 zzgl. 0 zur Terminierung). Sobald
> die Symbole nach UTF-8 mit vier Bytes kodiert werden müssen (Bsp.: F0 9F
> A1 83 zzgl. 0 zur Terminierung), werden diese bei mir auf dem Display
> nicht mehr dargestellt.

Okay, interessant, so tief habe ich das noch nicht getestet.
Ich war ja schon froh, einfache Sonderzeichen benutzen zu können. :-)
Mein Font hatte auch nur so 242 Glyphen oder so.

Was Du mal ausprobieren kannst ist das Flash-Image in den EVE-Screen 
Editor zu laden, bei der .glyph den Haken rein, dass die ins RAM geladen 
wird, etwa gleich in Adresse Null.
Dann einfach nur noch das SETFONT2(13, 0, 0) dazu und
ein CMD_TEXT() in das Fenster ziehen mit eben dem Font.
Zumindest ein "µ" konnte ich problemlos benutzen, also Sonderzeichen 
gehen schon mal grundsätzlich.
Was ist F0 9F A1 83 überhaupt? :-)

Simon schrieb:
> {
>                EVE_cmd_button(x1,y1,x2-x1,y2-y1,13,EVE_OPT_FLAT); //hier
> wird die Beschriftung des Buttons über EVE_write_string aufgerufen und
> der Buffer-Inhalt an den BT816 übertragen
>         }

Simon schrieb:
> Für die Darstellung der Schrift bzw. der Symbole verwende ich die
> EVE_cmd_text Funktion. Der Text wird allerdings nicht der Funktion
> übergeben, sondern vorher in einen entsprechenden Text-Buffer
> geschrieben. Diese Veränderung ist notwendig, um Abwärtskompaitbilität
> zur Software des vorherigen Displays gewährleisten zu können.

Hmm, okay,  warum nicht einfach den String übergeben?

In meinem aktuellen Projekt steht sowas drin:

char str_output[128];

...
uint_to_str(calc, str_output, 4);
EVE_cmd_text(480+115, 195, 27, EVE_OPT_RIGHTX, str_output);
int_to_str_3(calc_int32, str_output, 2);
EVE_cmd_text(310+265, 355, 27, EVE_OPT_RIGHTX, str_output);
GetErrCodeText(u16_Ctrl_ErrCode_F1, str_output);
EVE_cmd_text(310, 450, 27, 0, str_output);

Die Funktion EVE_cmd_text() will ja nur einen Pointer haben.
Und abgesehen von der Null für das Ende und das nach 249 Zeichen gekappt 
wird ist der Funktion auch der Inhalt egal.

Karol B. schrieb:
> FPC between TFT module
> and my PBC is 10cm long (sometimes even 20cm long)

That might be the issue, I only use 5cm cables.
And maybe your layout, the display shares the SPI with the SD card 
socket.
With the controller in die middle and running the SPI lines left and 
right you may have an issue with reflections.
You could try and add small resistors in the lines, 10R perhaps.
But ultimately I would suggest switching to a controller that is a 
little more advanced than the Mega128A.
Even a Mega1281 would be an upgrade since it has two SPI.

[Simon (Gast)]

Rudolph R. schrieb:
> Was ist F0 9F A1 83 überhaupt?

Das ist ein bestimmter Pfeil den ich gerne verwenden würde, also nicht 
so extrem wichtig. Ich bin mir aber nicht sicher ob ich ggf. später noch 
andere Symbole aus den entsprechenden Codepages benötige und versuche 
deswegen das Problem schonmal vorab zu klären.

Rudolph R. schrieb:
> Was Du mal ausprobieren kannst ist das Flash-Image in den EVE-Screen
> Editor zu laden

Das habe ich probiert und es sieht tatsächlich so aus, als könne der 
BT-Chip die 4-Byte codierten Pages nicht verarbeiten. Er hat alle 
Zeichen/Symbole unter der 4-Byte Grenze, die ich probiert habe 
problemlos angezeigt. Alles ab dieser Grenze wird nur noch mit zwei 
Fragezeichen dargestellt. Auf meinem realen Display wird gar nichts 
angezeigt.

[Rudolph (Gast)]

Simon schrieb:
> Rudolph R. schrieb:
>> Was Du mal ausprobieren kannst ist das Flash-Image in den EVE-Screen
>> Editor zu laden
>
> Das habe ich probiert und es sieht tatsächlich so aus, als könne der
> BT-Chip die 4-Byte codierten Pages nicht verarbeiten. Er hat alle
> Zeichen/Symbole unter der 4-Byte Grenze, die ich probiert habe
> problemlos angezeigt. Alles ab dieser Grenze wird nur noch mit zwei
> Fragezeichen dargestellt. Auf meinem realen Display wird gar nichts
> angezeigt.

Poste das bitte mal hier: http://www.brtcommunity.com/
So nach dem Motto "melden macht frei".
Mal schauen, was Bridgetek dazu zu sagen hat.

Wichtig wäre noch irgendwie zu verifizieren, dass die Glyphen wirklich 
im Font enthalten sind, die könnten ja auch bei der Konvertierung schon 
verloren gehen.

Eine Möglichkeit wäre dann vielleicht noch die Glyphen direkt selber 
anzuzeigen.
Wenn Du im EVE Screen Editor unten mal das Tab "Inspector" auswählst 
siehst
Du was der aus den Kommandos macht.

Bei mir taucht mit zwei Zeichen gerade das hier auf:

  Raw  Text
11  0x0500000d  BITMAP_HANDLE(13)
12  0x1f000001  BEGIN(BITMAPS)
13  0x0182c1ce  BITMAP_SOURCE(0x800000 | 180686)
14  0x405a02d0  VERTEX2F(180, 720)
15  0x01819cf4  BITMAP_SOURCE(0x800000 | 105716)
16  0x410802d0  VERTEX2F(528, 720)

Also im Grunde zerlegt der Co-Prozesser für das CMD_TEXT den String und 
berechnet für jedes Zeichen die Position und welches Bild anzuzeigen 
ist.
Der Knackpunkt wäre die Adresse zu finden, die steht wohl in der .glyph 
drin.

[Simon (Gast)]

Rudolph schrieb:
> Poste das bitte mal hier: http://www.brtcommunity.com/
> So nach dem Motto "melden macht frei".
> Mal schauen, was Bridgetek dazu zu sagen hat.

Ok mache ich im Laufe des Tages mal.

Rudolph schrieb:
> Wenn Du im EVE Screen Editor unten mal das Tab "Inspector" auswählst
> siehst
> Du was der aus den Kommandos macht.

Das habe ich gemacht und er macht aus meinem Pfeil tatsächlich zwei 
Fragezeichen:

Das ist meine Eingabe:

CMD_TEXT(123, 117, 13, 0, "??")

und das kommt dabei heraus:
  Raw  Text
13    0x01879bb4  BITMAP_SOURCE(0x800000 | 498612)
14    0x40f601d4  VERTEX2F(492, 468)
15    0x01879bb4  BITMAP_SOURCE(0x800000 | 498612)
16    0x411201d4  VERTEX2F(548, 468)
17    0x01879bb4  BITMAP_SOURCE(0x800000 | 498612)
18    0x412e01d4  VERTEX2F(604, 468)

Das merkwürdige ist, dass immer zwei Fragezeichen herauskommen, egal 
welches 4-Byte codierte Zeichen ich eingebe. Es scheint also von 
Bridgtek bewusst abgefangen zu werden....

[Rudolph R. (rudolph)]

Kann man so einen Font irgendwo frei herunter laden um das mal 
auszuprobieren?

Und ich merke gerade das mir was Fonts angeht etwas die Tools fehlen.

Naja, für sowas wie "Prüfstand" habe ich das auch schon mal eingetippt 
und einen Screenshot davon gemacht. :-)

[Simon (Gast)]

Rudolph R. schrieb:
> Kann man so einen Font irgendwo frei herunter laden um das mal
> auszuprobieren?

Der entsprechende Pfeil, der bei mir nicht funktioniert ist in dieser 
Schrift enthalten: 
https://fontlibrary.org/de/font/symbola#Symbola-Regular

Allgemein gibts es noch weitere nützliche Open Source Fonts, 
beispielsweise hier:
https://github.com/Microsoft/fonts
oder hier
https://github.com/adobe-fonts?page=1

[Rudolph (Gast)]

Das ist ein wenig anstrengender als ich dachte. :-)

Der Pfeil ist also U+1F843, damit findet man den dann zum Beispiel auch 
in der Character-Tabelle zu dem Symbole Font.
In UTF-8 kodiert sind das die F0 9F A1 83 - was ja sofort offensichtlich 
im Zusammenhang steht. :-)

Nun ist 00000 bis 0FFFD der Bereich BMP - Basic Multilingual Plane.
Und 1F843 gehört zum nächsten Bereich SMP - Supplementary Multilingual 
Plane und ist da im Block "Supplemental Arrows-C".

https://www.sql-und-xml.de/unicode-database/#blockbereiche

Da wird in den BT81x wohl "nur" BMP implementiert sein.
Scheinbar hat das Windows Tool "Zeichentabelle" das gleiche Problem, da 
finde ich die Pfeile nämlich auch nicht.

[Rudolph (Gast)]

Hast Du mal versucht den Offset der Glpyhe auszurechnen um diese direkt 
anzuzeigen?

Also wie hier:

11  0x0500000d  BITMAP_HANDLE(13)
12  0x1f000001  BEGIN(BITMAPS)
13  0x0182c1ce  BITMAP_SOURCE(0x800000 | 180686)
14  0x405a02d0  VERTEX2F(180, 720)

Im "BT81X Series Programminung Guide 1.1" steht auf Seite 100 / 101
wie man die die Adresse berechnet.

Dazu muss man die .glpyh auslesen.

Und dann im Kern sowas hier:

return (xf->start_of_graphic_data + xf->gptr[cp / 128] + bytes_per_glyph 
* (cp % 128) / 32);

Das hilft nur nicht, wenn die Daten gar nicht erst enthalten sind.

[Simon (Gast)]

Rudolph schrieb:
> Da wird in den BT81x wohl "nur" BMP implementiert sein.

Das ist auch meine aktuelle Vermutung. Auf der BRT Seite hat sich leider 
noch nicht allzu viel getan, bin mal gespannt was da von Bridgtek als 
Antwort kommt.

Rudolph schrieb:
> Hast Du mal versucht den Offset der Glpyhe auszurechnen um diese direkt
> anzuzeigen?

Hatte ich noch nicht probiert. Habe das gestern auch nur kurz probieren 
können. Bei meinen errechneten Adressen ist der Screen Editor allerdings 
abgestürzt, obwohl der Adressbereich eigentlich gültig war. Ich gucke 
mir das bei Gelegenhiet nochmal in Ruhe an. Danke für den Tipp.

[Rudolph (Gast)]

Ich habe mal ein wenig mit Fonts gespielt und mir fehlt vor allem immer 
noch ein Tool mit dem man Code-Blöcke aus Fonts löschen kann.
Über 8000 Glyphen zu haben ist zwar ganz nett, wenn man das auf Bitmap 
mit einer festen Größe konvertiert wird das aber schnell unlustig.

Der Webfont-Generator auf www.fontsquirrel.com ist schon sehr hilfreich, 
den finde ich von den Optionen her aber ein wenig eingeschränkt.
Und ich bin nicht mal sicher, ob der mit den Bereichen jenseits von BMP 
klar kommt.

Dann habe ich mir mal die resultierende .xfont Datei angesehen die der 
EVE Asset Builder erzeugt.
Und eine Sache ist schon mal sehr seltsam, die Anzahl der Glpyhen steht 
immer auf 65536, egal wie viele Glyphen der Font wirklich hat.

[Simon (Gast)]

Bisher habe ich immer nur alle Glyphen oder eine so geringe Auswahl 
verwendet, dass ich die händisch in eine .txt-Datei geschrieben habe. 
Die kann man ja dann in den EVE Asset Builder laden als Vorgabe. 
Deswegen kann ich dir aktuell beim Thema Software zur Auswahl von 
Codeblöcken leider auch nicht weiterhelfen.

Rudolph schrieb:
> Dann habe ich mir mal die resultierende .xfont Datei angesehen die der
> EVE Asset Builder erzeugt.

Worin hast du dir die denn angesehen? In Notepad++ oder im hex-Editor 
kann ich da keine Rückschlüsse auf die Anzahl der Glyphen ziehen. Aber 
das würde ja die Vermutung bestätigen dass das einfach nicht vorgesehen 
ist.

[Rudolph (Gast)]

Die .xfont habe ich einfach mit einem Hex-Editor aufgemacht.

Die Struktur dazu steht ja im Programming Manual.

Das sieht dann zum Beispiel so aus:

FF AA 00 01 Signatur
90 22 00 00 Size
B5 93 00 00 Format
4A 02 00 00 Swizzle
60 00 00 00 Layout Width
04 00 00 00 Layout Height
30 00 00 00 Pixel Width
14 00 00 00 Pixel Height
80 00 80 00 Start of Graphic Data
00 00 01 00 Number of Characters
00 2E 10 00 gptr - Offsets to glyph data

Anhand der Signatur sieht man, dass das erste Byte das LSB ist.

Die "Number of Characters" scheint dabei schon mal nicht richtig gesetzt 
zu werden, da steht immer 0x00010000 drin.

[Simon (Gast)]

Ach stimmt da war ja was...

Rudolph schrieb:
> Die "Number of Characters" scheint dabei schon mal nicht richtig gesetzt
> zu werden, da steht immer 0x00010000 drin.

Habe das jetzt mal für verschiedene Schriften durchgeschaut und kann das 
nicht bestätigen. Bei mir variiert das je nach Anzahl enthaltener 
Zeichen (damit meine ich die Anzahl an Zeichen, die ich über die 
.txt-Datei vorgeben habe).
Auffällig ist allerdings dass der Wert immer kleiner oder gleich 65536 
ist. Bei der Symbolschrift, mit der ich die beschriebenen Probleme habe, 
steht der besagte Wert von 65536 drin.

[Rudolph (Gast)]

Ich habe aktuell den Symbola.ttf mit den 8xxx Glyphen durch den EVE 
Asset Builder gezogen, ASTC, 12 Punkt, sowie einen Notosans-regular den 
ich mit Fontsquirrel auf 222 Glyphen reduziert habe.
Also einfach machen lassen ohne das über eine Datei einzuschränken.

Und da steht beide Male 0x00010000 drin.

Jetzt habe ich gerade mal den Notosans-regular mit 32xx Glyphen 
durchlaufen lassen und da ist das auch so.

[Simon (Gast)]

Habe das auch nochmal ausprobiert. Dieser Wert scheint sich auf die 
Einschränkungen durch die .txt-Datei zu beziehen. Wenn ich den gesamten 
Schriftsatz konvertiere habe ich auch immer den Wert 0x00010000.

[Rudolph R. (rudolph)]

Naja, mal davon ab, dass es dann eben nicht die Anzahl der Zeichen ist, 
das ist ja auch noch ein wenig niedrig angesetzt, so eigentlich.

Leider mahlen die Mühlen bei Bridgtek etwas sehr langsam und das hart 
moderierte Forum hilft da auch wenig diesen Eindruck zu entschärfen.

[Rudolph (Gast)]

"We discovered an issue with EAB regarding 4-byte UTF-8 characters.
EAB v1.4 is scheduled at Mar 25 and will include a fix for this."

Na, das klingt doch sehr vielversprechend und lange hin ist das auch 
nicht mehr. :-)

Das interpretiere ich so, dass EVE das grundsätzlich kann, die Daten nur 
gar nicht erst durch den Konverter gegangen sind.

[Simon (Gast)]

Ich bin auch positiv überrascht und werde das auf jeden Fall direkt 
testen, sobald die neue Software verfügbar ist. :-)

[JohnLemon (Gast)]

Hello all,
I'm trying to figure out how to upload custom font to ram into BT815. I 
have Riverdi RVT43ULBNWC03 connected to ESP32 (arduino framework). I 
generated font files in EVE Asset Builder and tried to upload content of 
.raw file with EVE_cmd_loadimage command but display stuck on black 
screen... Can someone explain me how to upload fonts to BT81x?

[Rudolph R. (rudolph)]

Well, do you also have a USB/SPI adapter like the Hermes board from 
Riverdi?
https://riverdi.com/product/hermes-board/

With that you can upload the flash image using the EVE Asset Builder to 
the on-board SPI-FLASH on the display.

In order to upload the data to EVEs G-RAM the font would need to be 
rather small.

Either way, EVE_cmd_loadimage() is only for .jpg and .png images.

You either need EVE_memWrite_flash_buffer() to transfer raw data from 
your target controller to G-RAM or EVE_cmd_inflate() if the data is 
z-lib compressed.

If you have the font data in the external SPI-FLASH you can use it 
directly from there if it is compressed in ASTC format.
In this case you only need to copy the .xfont file to G-RAM.
Preferably with EVE_cmd_flashread() as the .xfont can be stored in the 
SPI-FLASH as well.

When you have the .xfont in G-RAM and the .glyph either in G-RAM or in 
the SPI-FLASH you need to use EVE_cmd_setfont2() to assign a 
bitmap-handle to the new font.


What font are you using, how do you convert it and what sizes do the 
resulting files have?

[JohnLemon (Gast)]

Hello Rudolph,
thank you for your answer. I don't have Hermes Board from Riverdi. I'm 
basing on AN277 from FTDI:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_277_FT800_Custom_Font_Implement.pdf

I made .raw and .rawh files in EVE Asset Builder (Legacy Format), added 
content of metricblock and font table to my font.c file, and I tried to 
use it as in the AN277.
Is it possible to upload a font to FLASH via ESP32?

[Rudolph R. (rudolph)]

Okay, so this is legacy format with a maximum of 128 characters.
You can just follow the application note then.
It would be possible to write the data to the SPI-FLASH but this would 
only make things more complicated.

The code in the application note has this:

//load font data into memory
Ft_Gpu_Hal_WrMemFromFlash(phost, RAM_G + 1000, 
SAMApp_ShowCustomFont_MetricBlock, 148);
Ft_Gpu_Hal_WrMemFromFlash(phost, RAM_G + 1000 + 148, 
SAMApp_ShowCustomFont_FontBmpData,
36432);

Translated to my library this is:

EVE_memWrite_flash_buffer(RAM_G + 1000, 
SAMApp_ShowCustomFont_MetricBlock, 148);
EVE_memWrite_flash_buffer(RAM_G + 1000 + 148, 
SAMApp_ShowCustomFont_FontBmpData,
36432);

When you have this up and running you can try to use setfont2 instead.
But not like in the application note.
I have no idea what the guys at FTDI where thinking when they did 
chapter 4.2 but it makes the example overly complicated by loading the 
data from a file instead of loading it from the controllers memory like 
in 4.1.
And loading a file from disk while building a display list also is not 
the brightest idea.

Also the example is plain wrong, the four lines before 
Ft_Gpu_CoCmd_SetFont2() are useless, Setfont2 takes care of this.
And the comment says that it sets the starting character to 32 but the 
parameter is "97".

I do not have an ESP32 here right now but a whole lot of displays 
including a Riverdi 4.3" and a Matrix Orbital EVE3-43G.

And to test this with an Arduino I could use the CFAF800480E1 from 
Crystalfontz which has a FT813.
See: 
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x/example_projects/EVE_Test_Arduino_PlatformIO

Just change the target in platformio.ini , switch to EVE_RiTFT43 in 
EVE_config.h.
Then check the end of EVE_target.h for the Arduino options.
You need to provide the pins for Chip-Select and Power-Down.
And I am not sure about the ESP32, if the Arduino target provides a 
SPI.transfer() function the example already should compile and run just 
fine.

[Rudolph R. (rudolph)]

Okay, I just went ahead and tried to build my Arduino example for ESP32.

platformio.ini:

[env:esp32]
platform = espressif32
board = wemos_d1_mini32
framework = arduino

EVE_target.h:

...
#if defined (ARDUINO)

  #include <Arduino.h>
  #include <stdio.h>
  #include <SPI.h>

  #define EVE_CS     9
  #define EVE_PDN    8
...

For some reason the ESP32 needs the Arduino.h include while it just 
builds for the Uno and the Due.

And then there are warnings that NOP() gets redefined in EVE.h.
So you can just comment out line 757 of EVE.h:
//#define NOP() ((45UL<<24))

With that it at least builds for ESP32.

[JohnLemon (Gast)]

Hello,
thank you very much for your help. I will test it tomorrow. I know about 
warning with NOP and Arduino.h definitions. This is the case for every 
project.

[JohnLemon (Gast)]

Hello,
I bought Hermes and I uploaded the fonts to flash- it works perfectly 
:). But now I have problem with PNG without background.
I have a white icon (WIFI status) with background transparency. But when 
I display it on TFT I have icon in color that was previoulsy defined. 
When the color is the same like background where icon is, then it should 
be white, but it have color little bit darker than background.

drawBitmap(MEM_ICON_WIFI, 130, 3, 25, 25, EVE_RGB565, 0, WHITE);

void drawBitmap(uint mem_icon, uint x, uint y, uint w, uint h, uint fmt, uint tag, uint bg)
{
    EVE_cmd_dl(DL_COLOR_RGB | bg);
    EVE_cmd_dl(TAG(tag));
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(mem_icon, fmt, w, h);
    EVE_cmd_dl(VERTEX2F(x, y));
    EVE_cmd_dl(DL_END);
    EVE_cmd_dl(TAG(0));
}

[Vladislav N. (vladineufeld)]

Hallo Rudolph,

ich würde mich freuen, wenn du mir weiterhelfen würdest.

Ich programmiere aktuell das EVE 3 7 Zoll Touchdisplay von Riverdi mit 
einem Nucleo STM32 Board. Dafür benutze ich die von Riverdi zur 
Verfügung gestellte Bibliothek in C.

Ich habe den EIndruck, dass ich leider das noch nicht ganz genau mit dem 
FIFO vom Grafikcontroller verstanden habe.

Jedenfalls habe ich mir folgenden Demo-Code gemacht:

        Gpu_CoCmd_Dlstart(phost);
        App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
        App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
        App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
        App_WrCoCmd_Buffer(phost, VERTEX2II(220, 110, 26, 'T'));
        App_WrCoCmd_Buffer(phost, VERTEX2II(244, 110, 26, 'E'));
        App_WrCoCmd_Buffer(phost, VERTEX2II(270, 110, 26, 'X'));
        App_WrCoCmd_Buffer(phost, VERTEX2II(299, 110, 26, 'T'));

        App_WrCoCmd_Buffer(phost, END());

        App_WrCoCmd_Buffer(phost, COLOR_RGB(160, 22, 22));
        App_WrCoCmd_Buffer(phost, POINT_SIZE(320));
        App_WrCoCmd_Buffer(phost, BEGIN(POINTS));
        App_WrCoCmd_Buffer(phost, VERTEX2II(192, 133, 0, 0));
        Gpu_CoCmd_Number(phost, 50, 100, 26,OPT_SIGNED, value);


   Gpu_CoCmd_Text(phost, 0,0, 26,0, "Hallo Welt");
   Gpu_CoCmd_Text(phost, 100,0, 26,0, "Hallo Welt");
   //Gpu_CoCmd_Text(phost, 200,0, 26,0, "Hallo Welt");
        //App_WrCoCmd_Buffer(phost, VERTEX2II(320, 110, 31, 'T'));

        App_WrCoCmd_Buffer(phost, END());
        App_WrCoCmd_Buffer(phost, DISPLAY());

        Gpu_Hal_WaitCmdfifo_empty(phost);
        App_Flush_Co_Buffer(phost);
        Gpu_CoCmd_Swap(phost);

Wenn ich den Code so ausführen lasse, dann sehe ich alle Elemente, die 
ich programmiert habe. Wenn ich jedoch eines der auskommentierten 
Befehle noch hinzufüge, bleibt der Bildschirm schwarz.

Weißt du, was das Problem sein könnte?

Mein erster Gedanke war, dass der FIFO voll ist. Das kann aber nicht 
sein, da das bei jedem Befehl gecheckt wird und so lange gewartet wird, 
bis genug Platz vorhanden ist und dann wird der Befehl erst 
reingeschrieben. Und ich habe es auch schon mit dem Debugger gecheckt: 
Es werden alle Befehle ausgeführt, nur rührt sich das Display nicht.

Viele Grüße

Vladi

[Rudolph R. (rudolph)]

JohnLemon schrieb:
> drawBitmap(MEM_ICON_WIFI, 130, 3, 25, 25, EVE_RGB565, 0, WHITE);

That is your issue: EVE_ARGB1555
When you direclty load truecolor .png images they load as RGB565 - no 
alpha channel.
Either convert the images to ARG1555 and load them with cmd_inflate or 
even better since you already have the Hermes board now, use ASTC 
directly from the SPI-FLASH.
For example 8x8 which would be "EVE_COMPRESSED_RGBA_ASTC_8x8_KHR".

EVE_cmd_setbitmap(0x800000 | (adr_in_flash / 32), 
EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, sizex, sizey);

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
> ich würde mich freuen, wenn du mir weiterhelfen würdest.

Ich kann es versuchen, aber...


> Ich programmiere aktuell das EVE 3 7 Zoll Touchdisplay von Riverdi mit
> einem Nucleo STM32 Board. Dafür benutze ich die von Riverdi zur
> Verfügung gestellte Bibliothek in C.

...ich habe weder richtig Erfahrung mit den Nucleo Boards, noch bin ich 
ein Freund der ersten Library von FTDI.
Einer der Gründe warum ich meine eigene Library geschrieben habe war, 
dass mich der Code von FTDI so gar nicht überzeut hat.

Die erste Frage wäre ja mal, welcher STM32?
Für die F4xx habe ich ja schon Support eingebaut und auch ein PlatformIO 
Projekt dazu das zumindest mal baut.

Vladislav N. schrieb:
> Ich habe den EIndruck, dass ich leider das noch nicht ganz genau mit dem
> FIFO vom Grafikcontroller verstanden habe.

Ich habe mir mal erlaubt ein .pdf von Crystalfontz anzuhängen, das 
findet sich in den Datenblättern von deren Displays.
Das ist zwar für die EVE2, aber ich fand das schon sehr anschaulich.

Vladislav N. schrieb:
> Weißt du, was das Problem sein könnte?

Das ist es, nur die beiden auskommentierten Zeilen?

Naja, das erste ist mal, BEGIN und END gehören Paar-weise zusammen.

 App_WrCoCmd_Buffer(phost, BEGIN(POINTS));
 App_WrCoCmd_Buffer(phost, VERTEX2II(192, 133, 0, 0));
 Gpu_CoCmd_Number(phost, 50, 100, 26,OPT_SIGNED, value);
 App_WrCoCmd_Buffer(phost, END());

Und dann ist die Zeile
 //App_WrCoCmd_Buffer(phost, VERTEX2II(320, 110, 31, 'T'));
so komplett aus dem Kontext gerissen.
Ohne das
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
machen VERTEX2II und VERTEX2F gar nichts.

Das VERTEX2II soll ja ein Bild anzeigen, 31 ist das Bitmap-Handle, 
vorbelegt durch einen Zeichensatz.
Und 'T' ist die Nummer 84, das 84. Bild aus dem Set, auch Zelle genann 
oder eben "cell".

Vladislav N. schrieb:
> Mein erster Gedanke war, dass der FIFO voll ist.

Der FIFO hat 4k, so leicht bekommt man den nicht voll. :-)

[Vladislav N. (vladineufeld)]

Danke für die Datei. Die ist hilfreich!

Ich habe das Nucleo f20zfg (STM32 f2xx).

Ja wenn ich weiterhin nicht klar komme mit der Bibliothek, werde ich 
deine mal versuchen. Nur dann müsste ich den Code nochmal auf f2xx 
anpassen.

Ah ok ja stimmt das mit dem VERTEX Zeile ist wirklich ohne Zusammenhang 
^^
Aber das ist nicht das Problem. Diese auskommentierte Zeile können wir 
ruhig ganz ignorieren. Aber das Problem ist: Sobald ich das dritte 
"Hallo Welt" einkommentiere, dann wird gar nichts mehr angezeigt. Wenn 
ich das weglasse, dann werden die anderen Befehle problemlos angezeigt.

Was genau hat dir eigentlich nicht gefallen an der Bridgetek Bibliothek?

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
> Ja wenn ich weiterhin nicht klar komme mit der Bibliothek, werde ich
> deine mal versuchen. Nur dann müsste ich den Code nochmal auf f2xx
> anpassen.

Das habe ich gerade mal versucht und ein PlatformIO Projekt dafür 
aufgesetzt, analog zu dem F407 Projekt das ich schon hatte.

So wie es aussieht ist das HAL für den STM32F2xx komplett gleich zu 
benutzen wie das für den F4xx.

Ich habe in der EVE_target.h einfach nur den Block für den STM32F4 
kopiert und die Includes geändert.
Die größte Herausforderung war jetzt das richtige Define zu finden.
Die PlatformIO Board Dateien sind da hilfreich und so habe ich für das 
Nucleo_F207ZG schliesslich "#if defined (STM32F207xx)" gewählt.

Da müssen jetzt nur noch die Pins richtig angegeben werden.

Und wie beim letzten Projekt hier weiter oben, die main.c ist praktisch 
leer, das funktioniert so nicht, das ist nur um zu schauen ob es 
compiliert!

Warning This does compile but main.c does not work the way it is now!



Und schlau wäre auch in der EVE_target.c noch die entsprechenden 
Funktionen einzubauen um DMA machen zu können.
Nur benutze ich eben keine STM32 und zur Verfügung gestellt hat das 
bisher auch niemand.



Vladislav N. schrieb:
> Aber das Problem ist: Sobald ich das dritte
> "Hallo Welt" einkommentiere, dann wird gar nichts mehr angezeigt.

Hast Du das mit dem BEGIN/END denn gefixt?



Vladislav N. schrieb:
> Was genau hat dir eigentlich nicht gefallen an der Bridgetek Bibliothek?

Boah, so viele Ding und zu lange her. :-)
Aber wenn Du Dir nur mal die Zeilen ansiehst die Du gepostet hast, da 
taucht überall als Parameter "phost" auf.
Davon halte ich soweit gar nichts, das ist nämlich gar nicht für die 
Verwendung mit einem Mikro-Controller gedacht.
Anstatt das jedesmal wieder und komplett redundant zu übergeben habe ich 
den entscheidenden Parameter "cmdOffset" zu einer globalen Variable 
gemacht die auch absichtlich nur in der EVE_commands.c drin ist und 
nicht über die EVE_commands.h exportiert wird.

Und das ständige checken und noch mal checken des FIFOs bremst das ganz 
gut aus.

Meine Implementierung mag nicht ganz so robust sein, zum Beispiel könnte 
man den FIFO zu voll machen wenn man die Display-Liste erzeugt.
Aber wenn man das im Blick hat ist das komplett beherrschbar und so wie 
ich das implementiert habe deutlich schneller.
Das kostet ein paar kB extra, zugegeben.

Siehe auch das hier: http://www.brtcommunity.com/index.php?topic=100.0
Die neue "Portable MCU Library for EVE", beschrieben in BRT_AN_025 
gefällt mir deutlich besser als die erste Library von FTDI.
Wenn es das damals schon gegeben hätte, hätte ich meine Version 
vielleicht gar nicht angefangen.
Nur ist mein Code aktuell mit dem gleichen Controller eine ganze Ecke 
schneller.

Das was Riverdi in der Bibliothek gemacht hat ist auch deutlich 
aufgeräumter als die erste Implementierung von FTDI, viel leichter zu 
verstehen was da überhaupt passiert.
Ich bin allerdings sehr sicher, dass das langsamer läuft als meine 
Version.

[Vladislav N. (vladineufeld)]

Dankeschön,das hört sich gut an. Ich habe bislang noch nichts von 
PlatformIO gehört. Müsste mal ein neues Projekt in CubeIDE erstellen und 
die Dateien einfügen.

Ich habe jedenfalls gerade das Problem "behoben". Es sind gerade ganz 
verrückte Sachen passiert. Ich habe den Eindruck, der Grafikcontroller 
führt ein Eigenleben...

Ich bin auf die Idee gekommen, den Befehl 
Gpu_Hal_WaitCmdfifo_empty(phost) auszukommentieren. Dann hat die Anzeige 
plötzlich wie gewünscht geklappt. Auch etliche weitere Befehle wurden 
hinzugefügt und auch die problemlos angezeigt. Dann wollte ich mal beide 
Varianten mit dem Debugger vergleichen und mir den Befehl der wartet, 
bis der FIFO abgearbeitet wurde, genauer anschauen. Plötzlich ging die 
Anzeige auch als ich den Befehl einkommentiert hatte. Dann habe ich noch 
ein paar weitere Male das Programm draufgeflasht und alles war gut trotz 
des Befehls. Dann habe ich mal die Versorgungsspannung an und aus 
gemacht und dann ging es mit dem Befehl wieder nicht... oh ja Embedded 
Systeme sind manchnmal ganz komisch...
Jedenfalls denke ich, dass das nun der Fehler ist: Lieber 
Gpu_Hal_WaitCmdfifo_empty(phost) weglassen. Auch wenn ich nicht verstehe 
warum... Was ist das Problem? Dann wartet er eben noch bis der FIFO 
abgearbeitet wurde und erst dann wechselt er die Displayliste. Das war 
ja jetzt keine zeitkritisches Beispiel...(das Programm hat sich ja nie 
aufgehangen in ner Endschlosschleife, sondern wurde immer ganz 
durchgeführt.) Hast du als erfahrener Programmierer eine Erklärung? :D

Abgesehen davon: Warum wird eigentlich vom Hersteller im Datenblatt 
empfohlen, nicht direkt in die Displayliste zu schreiben, sondern den 
Umweg über den Co-Prozessor zu machen?
Was diesbezüglich komisch ist: Bei so einem Beispielprogramm von Riverdi 
wo ein Bildschirmschoner realisiert wurde (Ball baumelt von Ecke zu 
Ecke) haben die das nur mit direkten Befehlen in die DL gemacht...

Eine weitere Frage hätte ich auch noch: In der Riverdi Bibliothek kann 
man mit einem define auch noch eine "BUFFER_OPTIMIZATION" hinzuschalten. 
Ich habe mir mal den Code angeguckt und wenn man das aktiviert, dann 
werden die Befehle für den Co-Prozessor bzw. die DL-Befehle in einem 
extra Buffer gespeichert. Ich habe dir mal die entscheidenden vier 
Funktionen als Code im Anhang gepackt. Und mit den Befehlen 
App_Flush_Co_Buffer(phost); bzw App_Flush_DL_Buffer(phost); wird der 
Buffer dann komplett in RAM_CMD bzw. RAM_DL geschrieben. Wenn man das 
nicht aktiviert hat, dann wird jeder Befehl sofort in RAM_CMD bzw. 
RAM_DL geschrieben. Aber das komische ist: Wenn man diese Funktion 
aktiviert hat, dann passiert beides: Also dann wird beispielsweise durch 
den Befehl App_WrCoCmd_Buffer(Gpu_Hal_Context_t *phost,uint32_t cmd) 
sowohl der Buffer mit dem CMD gefüllt als auch sofort der CMD in RAM_CMD 
geschrieben. Und wenn man am Ende dann auch noch 
App_Flush_Co_Buffer(phost) schreibt, dann sind die Befehle ja doppelt in 
RAM_CMD.Einmal erst durch das direkte schreiben und danach nochmal nach 
schreiben des Buffer Inhalts. Ich weiß nicht ob das so gewollt? Eher 
nicht. Oder sollte man wenn man die BUFFER_OPTIMIZATION macht dann den 
anderen Codeteil der den Befehl direkt in den Speicher schreibt 
weglassen?
Was ich noch nicht erwähnt habe: Wenn man die die Funktion zuschaltet, 
dann wird auch geprüft, ob der Buffer schon voll ist. Wenn ja dann wird 
der komplette Inhalt direkt in den Speicher geschrieben

Jedenfalls liefen bei mir deren Demos stabiler als ich die 
BUFFER_OPTIMIZATION hinzugeschaltet habe (ohne hat es geflackert und mit 
gab es dann kein Flackern mehr).

Eine andere Sache noch:
Ich habe mit folgendem Programm, welches in der main() in der 
Dauerschleife läuft, versucht einfach mal die Touchkordinaten und den 
Tag Wert auf dem Bildschirm anzuzeigen:

void touchVersuch(Gpu_Hal_Context_t *phost, uint8_t* p_currTag, 
uint16_t* p_x_pos, uint16_t* p_y_pos)
{
  uint8_t tag = App_Touch_Update(phost, p_currTag, p_x_pos, p_y_pos);
  *p_currTag = tag;
  Gpu_CoCmd_Dlstart(phost);
  App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
  App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
  Gpu_CoCmd_Number(phost, 0, 0, 26 ,OPT_SIGNED,*p_x_pos);
  Gpu_CoCmd_Number(phost, 0, 20, 26 ,OPT_SIGNED,*p_y_pos);
  Gpu_CoCmd_Number(phost, 0, 40, 26 ,OPT_SIGNED,*p_currTag);
  App_WrCoCmd_Buffer(phost, DISPLAY());
  //Gpu_Hal_WaitCmdfifo_empty(phost);
  App_Flush_Co_Buffer(phost);
  Gpu_CoCmd_Swap(phost);
}


Aber leider läuft das kaum. Nur zufällig mal. Mal kann ich mir die X 
Koordinaten anzeigen aber nach ner Zeit hängt es sich auf. Manchmal 
kommt direkt ein starres Bild, was sich durch Touch nicht mehr ändert. 
X- und Y Werte zusammen aktuallisieren klappt nie.
Weißt du das Problem?

[Rudolph R. (rudolph)]

Um das noch mal zu erwähnen, ich bin für die Merkwürdigkeiten in der 
FTDI Library und auch der Variante davon von Riverdi ein wenig der 
falsche Ansprechpartner. :-)

PlatformIO, vor allem in Kombination mit VScode ist enorm praktisch um 
"mal eben schnell" ein Projekt für zig verschiedene Platformen 
aufzusetzen.
Zumindest solange es eine passende Board-Definition gibt.
CubeIDE habe ich gar nicht - und auch gar keine Verwendung dafür, weil 
ich mit den STM32 eben nichts anfangen kann.
Aber das Projekt da oben hat "stm32cube" als Framework.


Das mit dem Auskommentieren von Gpu_Hal_WaitCmdfifo_empty() ist 
merkwürdig.
Wie oft rufst Du den Display-Code eigentlich auf?
Das muss schon seltener passieren als die Bildrate vom Display ist.

Vladislav N. schrieb:
> Abgesehen davon: Warum wird eigentlich vom Hersteller im Datenblatt
> empfohlen, nicht direkt in die Displayliste zu schreiben, sondern den
> Umweg über den Co-Prozessor zu machen?

Wird das wirklich irgendwo empfohlen?
Der Co-Prozessor kann auf jeden Fall mehr und man muss auch weniger 
Daten übertragen, viele einfache Kommandos werden in mehrere Befehle in 
der Display-Liste zerlegt.

Spiel mal mit dem EVE Screen Editor.
Wenn Du da was von links in den Bildschirm ziehst, etwa ein "Text" dann 
taucht unten dazu auf was in den Co-Prozessor FIFO geschrieben wird.
Schaltet man dann den Tab unten auf "Inspector" um so sieht man was der 
Co-Prozessor da draus für Display-Listen Befehle macht.
Ein "einfacher" Button ist im Ergebnis doch ganz nett komplex.

Vladislav N. schrieb:
> Eine weitere Frage hätte ich auch noch: In der Riverdi Bibliothek kann
> man mit einem define auch noch eine "BUFFER_OPTIMIZATION" hinzuschalten.

Eigentlich nützlich ist sowas um den erzeugten Puffer dann anschliessend 
per DMA zu übertragen.
Optimiert ist das so in dem Sinne nur dadurch, dass beim Erzeugen des 
Puffers nicht auf das Ende der SPI-Übertragung gewartet wird.
Aber ob man nun Kommando-SPI-Kommando-SPI oder Kommando-Kommando SPI-SPI 
auführt ändert in Summe ja nichts an der Ausführungszeit.

Vladislav N. schrieb:
> Aber das komische ist: Wenn man diese Funktion
> aktiviert hat, dann passiert beides: Also dann wird beispielsweise durch
> den Befehl App_WrCoCmd_Buffer(Gpu_Hal_Context_t *phost,uint32_t cmd)
> sowohl der Buffer mit dem CMD gefüllt als auch sofort der CMD in RAM_CMD
> geschrieben.

Okay, das ist Unsinn, mit der Option an sollten die Kommandos nicht mehr 
direkt auf den SPI schreiben.

Vladislav N. schrieb:
> void touchVersuch(Gpu_Hal_Context_t *phost, uint8_t* p_currTag,
> uint16_t* p_x_pos, uint16_t* p_y_pos)
> {
>   uint8_t tag = App_Touch_Update(phost, p_currTag, p_x_pos, p_y_pos);
>   *p_currTag = tag;
>   Gpu_CoCmd_Dlstart(phost);
>   App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
>   App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
>   Gpu_CoCmd_Number(phost, 0, 0, 26 ,OPT_SIGNED,*p_x_pos);
>   Gpu_CoCmd_Number(phost, 0, 20, 26 ,OPT_SIGNED,*p_y_pos);
>   Gpu_CoCmd_Number(phost, 0, 40, 26 ,OPT_SIGNED,*p_currTag);
>   App_WrCoCmd_Buffer(phost, DISPLAY());
>   //Gpu_Hal_WaitCmdfifo_empty(phost);
>   App_Flush_Co_Buffer(phost);
>   Gpu_CoCmd_Swap(phost);
> }

Das verwirrt mich jetzt doch mal, ich benutze das ja selber nie.
Aber ist das wirklich richtig, dass das "App_WrCoCmd_Buffer" mit 
"Gpu_CoCmd_Number" vermischt wird?
Muss wohl so, aber konsistent ist sowas nicht gerade.

Auf jeden Fall ist "App_Touch_Update()" wohl eher nicht so hilfreich.
Da passiert doch einfach mal zu viel drin.

Hilfreicher wäre da:
Gpu_Hal_Rd8(phost,REG_TOUCH_TAG);

Nur dazu müsstest Du in der Display-Liste überhaupt mal einen Touch-Tag 
vergeben und in dem Ausschnitt ist nichts.

Ohne Touch-Tag wäre das hier besser:
Gpu_Hal_Rd32(phost, REG_TOUCH_SCREEN_XY);

Und einfach mal mit cmd_number ausgeben.

void touch_test(Gpu_Hal_Context_t *phost)
{
 uint32_t koordinaten = Gpu_Hal_Rd32(phost, REG_TOUCH_SCREEN_XY);

 Gpu_CoCmd_Dlstart(phost);
 App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(0,0,255));
 App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
 Gpu_CoCmd_Number(phost, 20, 20, 28 , 0, koordinaten);
 App_WrCoCmd_Buffer(phost, DISPLAY());
 Gpu_CoCmd_Swap(phost);
 App_Flush_Co_Buffer(phost);
 Gpu_Hal_WaitCmdfifo_empty(phost);
}

Mir ist da am Ende noch aufgefallen das die Reihenfolge von 
App_Flush_Co_Buufer und Gpu_Hal_WaitCmdfifo_empty falsch herum war.
Und nachdem ich jetzt meinen Code eingefügt habe, habe ich noch die 
Position von dem SWAP Kommando verändert.


Bei mir würde das so aussehen:

void TFT_display(void)
{
 uint32_t koordinaten;

 koordinaten = EVE_memRead32(REG_TOUCH_SCREEN_XY);

 EVE_cmd_dl(CMD_DLSTART); /* start the display list */
 EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
 EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
 EVE_cmd_number(20, 20, 28, 0, koordinaten);
 EVE_cmd_dl(DL_DISPLAY);
 EVE_cmd_dl(CMD_SWAP); /* make this list active */
 EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
}

So etwas vereinfacht, normalerweise habe ich da noch ein 
EVE_start_cmd_burst() / EVE_end_cmd_burst() Paar drum herum.

[Vladislav N. (vladineufeld)]

Ah ok das ist ja praktisch mit PlatformIO!

Ja vieleicht könnte das wirklich ein Problem bei mir sein mit dem 
Timing. Denn damit kenne ich mich noch nicht so gut aus.

Das hier ist der Code, der automatisch von der Entwicklungsumgebung 
erzeugt wurde zur für die SystemClockConfiguration:

RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  /** Initializes the CPU, AHB and APB busses clocks
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
  RCC_OscInitStruct.PLL.PLLM = 13;
  RCC_OscInitStruct.PLL.PLLN = 195;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 5;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Initializes the CPU, AHB and APB busses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != 
HAL_OK)
  {
    Error_Handler();
  }

Ich habe dann noch folgende paar Zeilen aus der Bibliothek von Riverdi 
inkludiert. Anschließend war die Anzeige stabiler (vorher war die 
Anzeige öfter mal zweigeteilt):

 /* configure the Systick interrupt time */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

  /* configure the Systick */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

   SystemCoreClock = 48000000; /* 48MHz */
   SystemCoreClockUpdate();

Also gehe ich maol davon aus, dass das Bild mit ner Frequenz von 48 MHz 
aktuallisiert wird.

So berechnet man dann die Bildrate des Displays:
800 x 480 = 384000  x 60 Hz x 24 Bit Auflösung = 552960000 Hz = 0,5 GHz

Der Aufruf ist also deutlich weniger als die Bildrate.
Oder habe ich jetzt irgendwas nicht verstanden?

Rudolph R. schrieb:
> Wird das wirklich irgendwo empfohlen?

Ja habe den Ausschnitt aus dem BT81x Programmierguide mal angehängt. 
Aber dort steht ja die Erklärung. Ist also nur eine Vorsichtsmaßnahme. 
Ah ok man hat also einfach mehr Möglichkeiten mit dem Co-Prozessor.

Später sollte ich mich auch mal mit DMA befassen. Aktuell ist es nicht 
in der Bib drinne aber habe gesehen, dass es von STM in der 
HAL-Bibliothek da Funktionen für gibt. Oder ich nutze deine Lib dann 
habe ich das schon :D Aber gut müsste bestimmt noch irgendwo mit den HAL 
Befehlen ergänzen.

Rudolph R. schrieb:
> Mir ist da am Ende noch aufgefallen das die Reihenfolge von
> App_Flush_Co_Buufer und Gpu_Hal_WaitCmdfifo_empty falsch herum war.
> Und nachdem ich jetzt meinen Code eingefügt habe, habe ich noch die
> Position von dem SWAP Kommando verändert.

Also das verstehe ich nicht, warum ist das falsch rum? Erst muss man 
doch die Anweisung geben, dass der Buffer in RAM_CMD geschrieben wird. 
Dann kann man mit Gpu_Hal_WaitCmdfifo_empty(phost); prüfen, ob das 
erledigt wurde (Also sind Lesezeiger REG_CMD_READ und Schreibzeiger 
REG_CMD_WRITE gleich ?). Und falls ja anschließend die Display Liste 
wechseln. Wo ist mein Denkfehler...?

Bist du dir sicher, dass der Code bei dir klappt mit dem Register 
REG_TOUCH_SCREEN_XY?
Bei mir hat es leider nicht funktuioniert. Also prinzipiell schon wenn 
man durchdebuggt. Aber nach ein paar Durchläufen hängt sich der Code auf 
nach dem Befehl: App_Flush_Co_Buffer(phost); Aber paar mal konnte ich 
wirklich den Registerwert auslesen und das wurde nach dem Swap Befehl 
dann angezeigt auf dem Display beim Debuggen. Scheint irgendein Problem 
mit dem Timing wohl zu geben...

Ja als nächstes werde ich mich mal mit dem EVE Screen Designer vertraut 
machen.

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
> Das hier ist der Code, der automatisch von der Entwicklungsumgebung
> erzeugt wurde zur für die SystemClockConfiguration:

Ja nun, ich habe gar keinen STM32. :-)

Vladislav N. schrieb:
> SystemCoreClock = 48000000; /* 48MHz */
>    SystemCoreClockUpdate();
>
> Also gehe ich maol davon aus, dass das Bild mit ner Frequenz von 48 MHz
> aktuallisiert wird.

Da draus geht bestenfalls hervor, dass Dein Controller mit 48MHz 
getaktet ist.
Kann man machen, nur läuft der STM32F207 mit bis zu 120 MHz.

>So berechnet man dann die Bildrate des Displays:
>800 x 480 = 384000  x 60 Hz x 24 Bit Auflösung = 552960000 Hz = 0,5 GHz

Äh, nein, die Bildrate wären die 60 Hz.
Aber die Bildrate sind auch nicht 60Hz, die ergeben sich aus dem 
Pixel-Clock.
Bei mir steht PCLK für dieses Display auf 2 und mit meiner Library sind 
das 36Mhz.
Wenn Riverdi da auch den Wert von 2 benutzt sind das entweder 30MHz oder 
eben auch 36MHz, je nachdem ob sie den Takt passend zu den BT81x 
einstellen.
Nun hat so ein Display nicht 800x480, das hat 1056 HCYCLE und 525 
VCYCLE.
Die Bildrate beträgt also so 65 Hz oder 54 Hz.
-> Zwischen zwei Updates sollten mindestens  18,5 ms sein.

Meine Software aktualisiert das alle 20 ms.

Interessant wäre an der Stelle dann auch noch, wie schnell überhaupt der 
SPI läuft.
Beim Init muss der nämlich langsamer als 11 MHz sein, danach darf der 
bis zu 30 MHz haben, das muss man aber erstmal stabil hin bekommen.

Vladislav N. schrieb:
>> Wird das wirklich irgendwo empfohlen?
>
> Ja habe den Ausschnitt aus dem BT81x Programmierguide mal angehängt.
> Aber dort steht ja die Erklärung. Ist also nur eine Vorsichtsmaßnahme.

Ah okay, das ist nur Quatsch, so wie das formuliert ist.
Der Co-Prozessor schreibt ja nicht einfach so aus Jux in die 
Display-Liste.
Richtiger wäre, dass es gefährlicher wird wenn man beides gleichzeitig 
versucht.

Vladislav N. schrieb:
> Also das verstehe ich nicht, warum ist das falsch rum? Erst muss man
> doch die Anweisung geben, dass der Buffer in RAM_CMD geschrieben wird.
> Dann kann man mit Gpu_Hal_WaitCmdfifo_empty(phost); prüfen, ob das
> erledigt wurde (Also sind Lesezeiger REG_CMD_READ und Schreibzeiger
> REG_CMD_WRITE gleich ?). Und falls ja anschließend die Display Liste
> wechseln. Wo ist mein Denkfehler...?

Nun ja, und wo wird dann auf die Ausführung von dem CMD_SWAP gewartet?

Die spannende Frage dazu ist schon mal, was macht App_Flush_Co_Buffer() 
eigentlich?

void App_Flush_Co_Buffer(Gpu_Hal_Context_t *phost)
{
#ifdef  BUFFER_OPTIMIZATION
    if (CmdBuffer_Index > 0)
    Gpu_Hal_WrCmdBuf(phost,CmdBuffer,CmdBuffer_Index);
#endif
    CmdBuffer_Index = 0;
}

So normalerweise, ohne diese "Buffer Optimisation" macht das praktisch 
garnichts weiter. Es wird auch automatisch jedes einzelne Kommando 
ausgeführt -> Handbremse.
Aber mit der "Buffer Optimisation" ist das der Befehl mit dem der 
CMD-FIFO beschrieben und das dann ausgeführt wird.
Lustigerweise beinhaltet das übrigens auch das Warten.

void Gpu_Hal_WaitCmdfifo_empty (Gpu_Hal_Context_t *host)
{
  while(Gpu_Hal_Rd16(host,REG_CMD_READ) != 
Gpu_Hal_Rd16(host,REG_CMD_WRITE));

  host->cmd_fifo_wp = Gpu_Hal_Rd16(host,REG_CMD_WRITE);
}

Okay, das macht was ich erwartet habe, wenn auch eher nicht so prall.
Wenn man REG_CMD_WRITE schon beschreibt weil man besser auch trackt wo 
der steht, dann muss man den  nicht lesen.
Und wenn man den schon liest, dann reicht einmal völlig aus...

In einem Beispiel von Riverdi habe ich das aber auch gerade so gefunden:
 App_WrCoCmd_Buffer(phost, DISPLAY());
 Gpu_CoCmd_Swap(phost);
 App_Flush_Co_Buffer(phost);
 Gpu_Hal_WaitCmdfifo_empty(phost);

Also das gehört schon so herum.

Vladislav N. schrieb:
> Bist du dir sicher, dass der Code bei dir klappt mit dem Register
> REG_TOUCH_SCREEN_XY?

Ja, habe ich gerade mal ausprobiert.
Allerdings habe ich dabei noch festgestellt, dass dem CMD_NUMBER noch 
eine Farbe fehlt:
 EVE_cmd_dl(DL_COLOR_RGB | BLACK);
 EVE_cmd_number(20, 20, 28, 0, koordinaten);

Und die Anzeige ist so alles anderes als nützlich, das gibt nur eine 
dicke Zahl.
Als Hex-Werte wäre das hilfreicher, oder eben wenn man die X/Y 
Koordinaten da raus zieht und getrennt ausgibt.

void TFT_display(void)
{
 uint32_t koordinaten;
 uint16_t x_koord, y_koord;

 koordinaten = EVE_memRead32(REG_TOUCH_SCREEN_XY);
 x_koord = (koordinaten >> 16);
 y_koord = koordinaten;

 EVE_cmd_dl(CMD_DLSTART);
 EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
 EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
 EVE_cmd_dl(DL_COLOR_RGB | BLACK);
 EVE_cmd_number(20, 20, 28, 0, x_koord);
 EVE_cmd_number(20, 40, 28, 0, y_koord);
 EVE_cmd_dl(DL_DISPLAY);
 EVE_cmd_dl(CMD_SWAP);
 EVE_cmd_start();
}

Das zeigt mir zwei Zahlen auf dem Display an, in Ruhe jeweils 32768 oder 
auch 0x8000 wie es im Programming-Manual steht.

Und wenn ich mit dem Finger über das Display gehen werden mir die 
Koordinaten angezeigt.
Das hat mich auch gerade darauf gebracht das mein Display schlecht 
kalibriert ist.
Ich habe einen leichten Versatz nach Rechts und etwas mehr nach Oben.

[Vladislav N. (vladineufeld)]

Puhh ich habe das mit den unterschiedlichen Clocks nun mal versucht 
nachzuvollziehen um PCLK herauszufinden und habe leider noch einiges an 
Verständnisproblemen.

Ich habe mal den Code und nachvollzogen und dort wird eine externe 
Quelle  als Taktversorgung eingesetzt(Weiß ich jetzt nicht, warum 
Riverdi nicht den internen relaxation oscillator clock benutzt).

Hier ist der Befehl:
Gpu_HostCommand(phost,GPU_EXTERNAL_OSC);

der ist mit 44h hinterlegt. Der Host Command 44h ist zum Festlegen der 
PLL.
"Select PLL input from external crystal oscillator or external input 
clock."

Laut Datenblatt kann man nur externe Quellen mit 12 MHz wählen, also 
gehe ich davon aus, dass die PLL nun 12 MHz ist.

Nun verstehe ich den Host Befehl CLKSEL nicht. Wann benutzt man denn 61h 
und wann 62h für das erste Byte?

Die benutzen bei der Initialisierung folgende Zeile:
Gpu_HostCommand(phost,GPU_PLL_48M)

GPU_PLL_48M ist mit 62h hinterlegt, also wird 620000h gesendet

Warum durch diesen Befehl die PLL auf 48 MHz setzen soll (so entnehme 
ich das dem typedef) erschließt sich mir nicht. Im Anhang ist die 
Bedeutung der Bits in Byte 2 zu sehen. Die sind ja alle 0.

"For compatibility to FT800/FT801, set Byte2 to 0x00. This will set the 
PLL clock back to default (60 MHz)"

Also laut dem Zitat wird die "PLL" auf 60 MHz gesetzt. Und nicht auf 48 
MHz?

Aber die eigentliche Funktion deises Befehl ist es ja, den Systemtakt 
festzulegen:
"Select the system clock frequency. Note that software shall also update 
the register value for REG_FREQUENCY to align with system clock 
selected."


In der Library habe ich auch noch folgende Funktion gefunden (die aber 
bei der Initialisierung nicht benutzt wurde):

Gpu_81X_SelectSysCLK (Gpu_Hal_Context_t  *host,
                      GPU_81X_PLL_FREQ_T  freq)
{
  if(GPU_SYSCLK_72M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x40 << 8) | (0x06 << 
8));
  else if(GPU_SYSCLK_60M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x40 << 8) | (0x05 << 
8));
  else if(GPU_SYSCLK_48M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x40 << 8) | (0x04 << 
8));
  else if(GPU_SYSCLK_36M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x03 << 8));
  else if(GPU_SYSCLK_24M == freq)
    Gpu_HostCommand_Ext3(host, (uint32_t)0x61 | (0x02 << 8));
  else if(GPU_SYSCLK_DEFAULT == freq)
    Gpu_HostCommand_Ext3(host, 0x61);
}

Da sie nicht benutzt wurde, gehe ich mal davon aus, dass der Systemtakt 
60 MHz ist.

In das Register REG_PCLK schreiben Sie in der Initialisierung den Wert 2 
rein, also denke ich mal, dass PCLK 30 MHz ist.


Rudolph R. schrieb:
> Die Bildrate beträgt also so 65 Hz oder 54 Hz.

Wie hast du die Bildrate berechnet?

Rudolph R. schrieb:
> Meine Software aktualisiert das alle 20 ms.

In welchem Teil deiner Library kann man das sehen, wie du das 
eingestellt hast?

Rudolph R. schrieb:
> Interessant wäre an der Stelle dann auch noch, wie schnell überhaupt der
> SPI läuft.
> Beim Init muss der nämlich langsamer als 11 MHz sein, danach darf der
> bis zu 30 MHz haben, das muss man aber erstmal stabil hin bekommen.

Woher hast du die Info, dass er langsamer als 11 MHz sein muss? Also du 
meinst bei der Initialisierung des Chips oder?

Ich habe jetzt übrigens mal diese

Vladislav N. schrieb:
> /* configure the Systick interrupt time */
>   HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
>
>   /* configure the Systick */
>   HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
>
>   /* SysTick_IRQn interrupt configuration */
>   HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
>
>    SystemCoreClock = 48000000; /* 48MHz */
>    SystemCoreClockUpdate();

Ich habe überigens diese Befehle nun rausgenommen. Plötzlich 
funktionieren die Beispiele von Riverdi es auch ohne diese Befehle 
stabil. Also jetzt habe ich nur den Code für sie System Clock 
Configuration der automatisch von der IDE erzeugt wurde (Da werden dann 
auch die 120 MHZ benutzt :D)

Die Einstellungen des SPI habe ich graphisch über die IDE gemacht und da 
habe ich den Baudraten prescaler auf 2, was einer Baudrate von 30 Mbit/s 
entspricht. Die haben da nach so ein Beispiel wo das Bridgetek Logo 
angezeigt wird. Das läuft mit den 30 Mhz nicht ganz stabil. Da Habe ich 
herausgefunden, dass ein prescaler von 4 besser ist, also 15 MHz.

Aber mit beiden Frequenzen funktioniert das nicht mit der stabilen 
Anzeige der X und Y-Werte.

Es wird wohl bestimmt daran liegen, dass ich mir bislang noch gar keine 
Gedanken dazu gemacht habe, wie oft das Display aufgerufen wird und wie 
oft der Code in der Main aufgerufen wird. Erstmal wäre gut zu wissen, 
was für eine Bildrate eingestellt ist.
Und wie realisiere ich das, wie oft ein Code in der Main aufgerufen 
werden soll? Dafür muss ich mich wahrscheinlich über Timer informieren 
und dann vor den Code eine If Bedingung mit einer Timing Variablen 
machen und immer wenn der Timer die Variable setzt, dann erst den Code 
ausführen? (So wie du das in deiner Main gemacht hast). Aktuell wird der 
Code ja einfach wahrscheinlich mit den 120 MHz abgearbeitet und das ist 
ja viel schneller als die Bildrate...

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
> Ich habe mal den Code und nachvollzogen und dort wird eine externe
> Quelle  als Taktversorgung eingesetzt(Weiß ich jetzt nicht, warum
> Riverdi nicht den internen relaxation oscillator clock benutzt).

Naja, sie haben eben einen Quarz auf der Platine und mit diesem ist der 
Takt etwas stabiler.

Vladislav N. schrieb:
> Da sie nicht benutzt wurde, gehe ich mal davon aus, dass der Systemtakt
> 60 MHz ist.
>
> In das Register REG_PCLK schreiben Sie in der Initialisierung den Wert 2
> rein, also denke ich mal, dass PCLK 30 MHz ist.

Gut, das passt.

Vladislav N. schrieb:
>> Die Bildrate beträgt also so 65 Hz oder 54 Hz.
>
> Wie hast du die Bildrate berechnet?

30MHz / (1056 * 525) = 54,112554

Du hast bei Dir in der Formel noch 24 Bit Auflösung mit drin gehabt.
Die Daten werden allerdings parallel übertragen, nicht seriell.

Vladislav N. schrieb:
>> Meine Software aktualisiert das alle 20 ms.
>
> In welchem Teil deiner Library kann man das sehen, wie du das
> eingestellt hast?

In gar keinem, das ist Teil meiner Anwendung.
Die beiden Beispiele die ich auf Github habe machen das.
In dem ATSAMC21 Beispiel wird der Systick-Timer für einen 5 ms Interrupt 
verwendet damit die Hauptschleife nur alle 5 ms durchlaufen wird.
Und alle vier Durchläufe wird TFT_display() aufgerufen.
In dem Arduino Beispiel mache ich das gleiche, nur benutze ich da 
millis() um die Hauptschleife nur alle 5 ms auszuführen.

https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/example_projects/EVE_Test_SAMC21_FT813_EVE2-35G/main.c

Vladislav N. schrieb:
> Woher hast du die Info, dass er langsamer als 11 MHz sein muss? Also du
> meinst bei der Initialisierung des Chips oder?

Ja, bei der Initialisierung des Chips.

Und das ist eine interessante Frage.
Im "FT800 Programmers Guide.pdf" steht noch im Kapitel 2.2.5: "Use MCU 
SPI clock not more than 11MHz".
Und im Kapitel 4.2.3 vom "DS_FT800.pdf" steht:
"If SPI is used as host interface, the SPI clock shall not exceed 11MHz 
before system clock is
enabled. After system clock is properly enabled, the SPI clock is 
allowed to go up to 30MHz."
Im Datenblatt vom FT81x findet sich das nicht mehr.
Im "FT81X_Series_Programmer_Guide_1.2.pdf" steht das im Kapitel 2.3 auch 
nicht mehr explizit drin, das Beispiel hat aber noch die Zeilen dafür.
Und im Kapitel 2.4 vom 
"BRT_AN_033_BT81X_Series_Programming_Guide_1.1.pdf" taucht nicht mal 
mehr das auf.

Hmm, interessant, sich daran zu halten ist jetzt nicht in dem Sinne 
falsch, aber scheinbar schon seit den FT81x so nicht mehr notwendig.

Das habe ich gerade mal ausprobiert.
Bis 17 MHz SPI Takt hoch kann ich den BT815 starten lassen.
Da drüber klappt es aber nur nicht mehr so richtig, weil ich noch ein 
Problem mit dem MISO habe und dann nur noch Murks über die Leitung 
kommt.
Mit 17MHz SPI Takt bleiben die X/Y Koordinaten auch nicht fest auf 
32768, da sind ständig Bit-Kipper drin.

Vladislav N. schrieb:
> Es wird wohl bestimmt daran liegen, dass ich mir bislang noch gar keine
> Gedanken dazu gemacht habe, wie oft das Display aufgerufen wird und wie
> oft der Code in der Main aufgerufen wird. Erstmal wäre gut zu wissen,
> was für eine Bildrate eingestellt ist.

(Sytem-Clock / PCLK) / (HCYLCE * VCYCLE)

Wobei man PCLK sinnigerweise so einstellt das sich in etwa 60 Hz 
ergeben.
Und nachdem ich das gerade in meine Excel-Tabelle für die 
Display-Parameter eingegeben habe, sollte ich vielleicht noch ein paar 
Parameter anpassen, da gerade viele von den kleinen Displays da deutlich 
drüber liegen.
Das EVE3-43G etwa das ich gerade benutze hat wie alle anderen 4.3" bei 
mir eine Einstellung von PCLK = 5, mit den 72MHz von dem BT815 macht das 
90Hz.
Ein PCLK = 7 und entsprechend 64 Hz wären sinnvoller.

Was man daran auch schön erkennen kann, die Framerate wird mit höheren 
Auflösungen zunehmend zum Problem, zumindest bis einschliesslich BT816.
Unter 2 sollte man gar nicht gehen, da EVE sonst Probleme bekommt die 
Pixel auch noch zu erzeugen.

Aber wenn man so eines wie das ADAM101 mit 1024x600 hat bei VCYCLE = 720 
und HCYCLE = 1100, da kommt man mit PCLK = 2 und den maximal 60 MHz des 
darauf verbauten FT813 eben nur auf 38 Bilder pro Sekunde.
Hätte das einen BT815 käme man wenigstens auf 45 FPS.

Deshalb gibt es auch (noch) keine EVE Displays mit etwa 1280x800.

[Vladislav N. (vladineufeld)]

Hallo,

ich habe mich mal einbisschen recherchiert über die Möglichkeiten die 
man mit EVE hat. Dabei bin ich auf das Beispiel 4 von dieser Seite 
gestoßen:

https://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm

So eine Anzeige wäre ziemlich cool für meine Endanwendung.

Natürlich gibt es den Code zu diesen Beispielen aber nur für andere 
Zielplattformen. Das Application Layer und das EVE Layer sind aber 
nahezu identisch wie auch in der Riverdi Bibliothek.

Ich habe versucht, den Code von der Datei "App_Gauges.c" in mein Projekt 
zu integrieren. Kompilieren hat dann auch geklappt, jedoch funktioniert 
die Anwendung leider nicht auf meinem Display.

Erst habe ich die Variable prog_uchar8_t digits[] aus "App_Gauges.c" nur 
in uchar8_t geändert. Denn in deren "platform.h" war das hier zu finden: 
#define prog_uchar8_t  uchar8_t
Keine Ahnung, warum die das gemacht haben aber das sollte ja nicht das 
Problem sein.

Die hatten in Ihrer Bibliothek noch die Funktion
Gpu_Hal_WrCmdBufFromFlash(...) drinne, welche ich auch einfach noch in 
meine Gpu_hal.c hinzugefügt habe.

Außerdem waren in deren Hal.utils.c noch folgende defines die ich 
hinzugefügt habe:
#define pgm_read_byte_near(x)   (*(x))
#define pgm_read_byte(x)        (*(x))
#define random(x)    (rand() % (x))

Wenn ich durch den Code debugge, dann hängt er sich irgendwann bei einem 
Gpu_Hal_WaitCmdfifo_empty(phost); auf.

Vieleicht liegt es aber auch daran, dass ich mich bislang noch gar nicht 
mit dem Flash Speicher des Riverdi beschäftigt habe, dieses Beispiel 
aber offenbar auch was mit Flash zu tun hat (wegen der Funktion 
Gpu_Hal_WrCmdBufFromFlash ). Das ist der Code der Funktion:

void Gpu_Hal_WrCmdBufFromFlash(Gpu_Hal_Context_t *host,uchar8_t 
*buffer,uint32_t count)

 uint32_t length =0, SizeTransfered = 0, getfreespace;
    do {
        length = count;
        getfreespace = Gpu_Cmdfifo_Freespace(host);
        if (length > getfreespace){
            length = getfreespace;
        }
        Gpu_Hal_CheckCmdBuffer(host,length);

        Gpu_Hal_StartCmdTransfer(host,GPU_WRITE,length);


        SizeTransfered = 0;
        while (length--) {
            Gpu_Hal_Transfer8(host,pgm_read_byte_near(buffer));
            buffer++;
            SizeTransfered ++;
        }
        length = SizeTransfered;

        Gpu_Hal_EndTransfer(host);
        Gpu_Hal_Updatecmdfifo(host,length);

        Gpu_Hal_WaitCmdfifo_empty(host);

        count -= length;
    }while (count > 0);

Aber hier ist ja als Flash dieses großen Zahlenarray aus "App_Gauges.c" 
gemeint. Was nicht klar ist, warum Gpu_Hal_Transfer8 benuitzt wird (hier 
erwartet man auch noch eine Antwort von der GPU die aber nirgendswo 
gespeichert wird)

Dort ist auch noch eine Schriftartendatei "digits.fon" (siehe Anhang). 
Aber ich habe nirgendswo in deren Code gesehen, wo Sie diese benutzen. 
Weißt du, was man mit der machen muss?

Hast du ne Idee, wie man das Beispiel zum Laufen bringen könnte?

Noch ne andere Sache: Dieser EVE Screen Designer, bringt der mir 
irgendwas wenn ich nicht eine von den supporteten Zielplattformen 
benutze? Nach dem Anschauen des Guides habe ich eher festgestellt, dass 
ich keinen Mehrwert erschließen kann, da ich ja nur den C-Code für 
andere Platformen bekommen kann.

Im ESD sind zwei Widgets die evtl. auch für mich in Frage kommen könnten 
(siehe die letzten beiden Anhänge). Aber diese findest man nicht im 
Programmierguide. Weißt du, wie es mir möglich wäre, diese Widgets 
einzubinden?

Der EVE Screen Editor hingegen kann mir helfen, da ich dort mal Sachen 
ausprobieren könnte, ohne sie kompilen zu müssen.

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
> Hast du ne Idee, wie man das Beispiel zum Laufen bringen könnte?

Äh, so spontan nicht, habe ich noch nicht versucht.
Gpu_Hal_WrCmdBufFromFlash() hat aber nichts mit dem SPI-FLASH auf dem 
Modul zu tun, das bezieht sich auf den Programm-Speicher vom Controller.
Sowas habe ich ja auch eingebaut, siehe oben, das stammt alles noch aus 
der Zeit vor den BT81x.

Den EVE Screen Designer benutze ich auch nicht.
Ich hoffe im Moment das dem EVE Screen Editor mal ein Exporter für die 
neue Library nach AN025 beigebracht wird, das ist dann schon mal viel 
dichter an meinem eigenen Code dran.

Was die Widgets angeht, zumindest das erste ist als Beispiel enthalten 
in dem aktuellen EVE Screen Editor.
Die Beispiele sind sowieso interessant, wenn auch etwas versteckt in dem 
Installations-Ordner.

[Rudolph R. (rudolph)]

Hello,

yesterday evening I pushed a small update.
Among other things I marked the function EVE_get_touch_tag() as 
deprecated.
If you using it you will get a warning that it is deprecated.

Just use EVE_memRead8(REG_TOUCH_TAG); instead.
Or EVE_memRead8(REG_TOUCH_TAG1); and so in case of multi-touch.

And make sure EVE is not busy when you use DMA:

void TFT_touch(void)
{
  uint8_t tag;
  static uint8_t toggle_lock = 0;
  
  if(EVE_busy()) /* is EVE still processing the last display list? */
  {
    return;
  }

  tag = EVE_memRead8(REG_TOUCH_TAG); /* read the value for the first touch point */

  switch(tag)
  {
...

With the upcoming BT817 a couple more changes will be necessary.
The "#if defined (BT81X_ENABLE)" needs to be changed since BT817 
obviously still is a BT81x and yet it is beyond BT815 with additional 
registers.
Instead I am thinking about using "EVE2", "EVE3" and "EVE4".
EVE2 == FT81X_ENABLE
EVE3 == BT81X_ENABLE and EVE2 is to be set as well
EVE4 for BT817 with EVE3 and EVE2 to be set as well

Well, it may be time to make EVE2 base-line when the first BT817 
displays are released.
Meaning to finally remove FT80x support, clean it up some more and call 
it 5.x.

[Bernd Ickert (Gast)]

Simple Frage an erfahrene Fachleute! Mit lang erprobter Hardware und 
Displays ab 4,3 Zoll (mind. 480x272) versuche ich nun schon seit Stunden 
ein 3,5 Zoll Display mit 320x240 zum Laufen zu bringen. Display-Treiber: 
FT813. Ist es möglich, dass dieser FT gar nicht für solche "kleinen" 
Displays vorgesehen ist? Hat der außer der Ober- auch eine 
Untergrenze???
Meine Erfahrungen zeigten, dass die Einstellungen der Register
HCYKLE  HOFFSET  HSYNC0 / HSYNC1 (und das Gleiche für V) recht 
großzügig in bestimmten Bereichen verändert werden können, ohne dass es 
sichtbare Auswirkungen hat.
Klar, HSIZE und VSIZE sollten wohl immer richtig sein (hier also 320 und 
240).
Zum Laufen bringen: Damit meine ich das Display einfach nur vollflächig 
mit einer Farbe beschreiben...
Je nach Einstellungen (an denen ich wie gesagt, nun schon seit Stunden 
probiere) habe ich angefangen von gar kein Bild bis zu halben/über Eck, 
flackernd die Hälfte, mit weißen Balken mal hier und da na usw...
Schließe ich einfach mal ein 480x272 an, habe ich ein grünes Bild (die 
Farbe, die es sein soll!) in der Größe 320x240 und weißem Balken 
unterhalb und "Farbschrott" rechts, was der Bereich > 320x240 ist!
Wo ist der Denkfehler?

Bernd

[Rudolph R. (rudolph)]

Ich habe hier ein EVE2-35G liegen: 
https://www.matrixorbital.com/ftdi-eve/eve-ft812/eve2-35g

Das hat einen FT813, 3,5", 320x240 und spielt einwandfrei.
Ebenso das EVE3-35G mit dem noch dickeren BT815.

Mein Beispiel-Projekt ist für ein EVE2-35G konfiguriert:
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x/example_projects/EVE_Test_SAMC21_FT813_EVE2-35G

Auf was für einer Hardware bist Du unterwegs, was für ein Display ist 
das genau und welche Timing-Einstellungen benutzt Du im Detail?

[Bernd Ickert (Gast)]

Ich bin  mit dem "niedlichen Platinchen" (siehe 18.1. diesen Jahres) 
unterwegs, also einfach nur den FT813, den ich per SPI bediene, so wie 
zuvor mit allen anderen Displays. Das 3,5' ist jetzt Premiere - und 
klappt nicht. Anbei das Datenblatt des Display. ACTRON, die mit dem 
einheitlichen 50-poligen Anschluss, weshalb ich einfach mal von einem 
Display zum anderen Wechseln kann.
Seite 18 findest Du die entsprechenden Timings für dieses Display. 
Kannst Du mir bitte, bitte sagen, welche Werte für HCYKLE  HOFFSET 
HSYNC0 / HSYNC1 (und V....) dafür erforderlich sind?!
REG_HSIZE = 320
REG_VSIZE = 240

Werte in Klammern dahinter, was ich schon alles u.a. probiert habe
REG_HCYCLE: 408 - 450 ???
REG_HOFFSET ? (40)
REG_SYNCO ? (20, 40, 0)
REG_SYNC1 ? (68, 48, 2, 1)
REG_VCYCLE: 262 - 350 ???
REG_VOFFSET ? (40, 30, 22
REG_VSYNC0 ? (10, 1 , 0)
REG_VSYNC1 ? (40, 18, 10)

REG_PCLK habe ich auch schon mal hochgesetzt (also Takt runter), derzeit 
auf 10, also 4,5MHz... Alles egal! Nur bei REG_PCLK = 1 geht nichts mehr 
(48 MHz), ab 2 geht es. Oder liege ich da falsch? Ich betreibe den FT813 
mit 12MHz-Quarz, also durch PLL 48Mhz. Wie hoch ist dann PCLK, wenn 
REG_PCLK = 1 ist? 48 oder 12 MHz (FOSC / 4) ???

Angebot "niedliches Platinchen" steht noch - wenn Du es brauchst!

[Bernd Ickert (Gast)]

Nun ist mir noch etwas aufgefallen:
Im Datenblatt des Display 3,5' sind die Impulse (HSYNC / VSYNC) Positiv 
im Diagramm gezeichnet, während sie bei allen anderen (bisher von mir 
verwendeten) stets negativ sind und so auch im 
FT813-Programmieranweisung (s.28) aufgeführt sind, also auch negativ.
Außer die Polarität des Clock (mit REG_PCLK_POL) kann man aber die H- 
und V-Sync-Ausgänge nicht negieren. (?). Müsste man nun also die ganzen 
Zeiten (Anzahl CLK, Anzahl Lines) so umrechnen, dass sich eben die 
positiven Werte ergeben. Hattest Du so was schon mal?

[Rudolph R. (rudolph)]

Okay, das ist also schon mal ein FT813.

Ist jetzt nicht so, als hätte ich mich damit schon oft herum schlagen 
müssen, normalerweise habe ich ja die Daten von den Modul-Herstellern.

Das Beste an den Timings ist ja, jeder Hersteller gibt das ein klein 
wenig anders an, mal ist der Buchstabensalat anders, mal fehlen auf den 
ersten Blick Werte.

Probier das mal:

#define EVE_HSIZE  (320L)
#define EVE_VSIZE  (240L)
#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (4L)
#define EVE_VOFFSET  (22L)
#define EVE_VCYCLE  (262L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (20L)
#define EVE_HOFFSET  (88L)
#define EVE_HCYCLE   (408L)
#define EVE_PCLKPOL  (1L)
#define EVE_PCLK  (9L)

Die Clock-Polarität sagt ja nur, ob das nun auf die fallende oder auf 
die steigende Flanke zu beziehen ist.
Und nach dem Datenblatt ist es die fallende Flanke und somit 
REG_PCLK_POL=1.

Bernd Ickert schrieb:
> Ich betreibe den FT813 mit 12MHz-Quarz, also durch PLL 48Mhz.

Der hat aber per Default 60MHz, da muss man sich schon ein wenig Mühe 
geben den auf 48MHz runter zu bekommen. :-)

[Bernd Ickert (Gast)]

Vielen Dank für die Daten! Das sind ja genau die, die lt. Datenblatt 
richtig sein sollten und mit denen ich (Plus/Minus) schon in allen 
Richtungen experimentiert hatte. Ich habe jetzt bei ACTRON ein neues 
geordert, um auszuschließen, ob es sich nicht doch um ein 
"Montags-"Display handelt. Wenn sich ein neues Display genauso verhält, 
wie dieses, na dann geht's weiter...

Ich betreibe den FT mit einem separaten Quarz 12MHz, so wie es im 
Datenblatt des FT813 in "Application Examples" vorgegeben ist. Was der 
FT dann mit dieser Frequenz noch macht, weiß ich (nicht) mehr. Ich 
meinte, mal gelesen zu haben, dass mit Hilfe der inneren PLL daraus dann 
48 MHz gemacht werden (beim PIC ist es jedenfalls so - einstellbar). 
Aber natürlich auch möglich, dass durch "Mal 5" - PLL daraus 60Mhz 
werden...
Ich melde mich wieder - Eine schöne Woche

[Bernd Ickert (Gast)]

Da haben wir (wahrscheinlich) das Problem. Nach Rücksprache mit ACRON 
mit einem sehr kompetenten Techniker (hat man selten bei 
Display-Lieferanten!!!) liegt das Problem an der DE-Polarität. Autor der 
beigefügten AppNote ist auch der, mit dem ich eben sprach. Auf Seite 10 
siehst Du in der Tabelle letzte Spalte von Unten das Aktive low für den 
DE, während alle anderen Aktive High sind. Und das kann der FT8xx nicht. 
Da das Problem bekannt ist, haben sie da schon was in petto und ich 
bekomme ein äquivalentes Display.
Dieses Muster kann ich aber auch noch durch Umlöten eines Widerstandes 
trotzdem verwenden. Anleitung dazu erhalte ich heute noch. Na dann mal 
sehen!!!

[Rudolph (Gast)]

Doch, ja, ich bin mit den fertigen Modulen immer noch ganz glücklich 
soweit. :-)
Und ich bin schon gespannt was Matrix Orbital feines mit den BT817 raus 
bringen wird für EVE4.
Ich hoffe da auf ein EVE4-100G mit 10.1" und 1280x800. :-)

Bernd Ickert schrieb:
> Ich betreibe den FT mit einem separaten Quarz 12MHz, so wie es im
> Datenblatt des FT813 in "Application Examples" vorgegeben ist. Was der
> FT dann mit dieser Frequenz noch macht, weiß ich (nicht) mehr. Ich
> meinte, mal gelesen zu haben, dass mit Hilfe der inneren PLL daraus dann
> 48 MHz gemacht werden (beim PIC ist es jedenfalls so - einstellbar).
> Aber natürlich auch möglich, dass durch "Mal 5" - PLL daraus 60Mhz
> werden...

Das ist korrekt soweit, der Takt wird per PLL aus den 12MHz erzeugt.
Aber das mit den 48MHz war bei den FT80x der Fall, bei den FT81x waren 
das schon per Default 60MHz.
Bei den BT81x sind es per Default auch erstmal 60MHz, die lassen sich 
aber auf 72MHz hoch stellen - was meine Library auch macht.

[Mila Mik (Gast)]

Rudolph schrieb:
> Doch, ja, ich bin mit den fertigen Modulen immer noch ganz glücklich
> soweit. :-)
> Und ich bin schon gespannt was Matrix Orbital feines mit den BT817 raus
> bringen wird für EVE4.
> Ich hoffe da auf ein EVE4-100G mit 10.1" und 1280x800. :-)

Ich warte seit Februar auf Muster vom BT817. Ich brauche den für eine 
Neuentwicklung wo ein Display mit 1024x600 gefordert wird. 
Seltsamerweise ist auf der Bridgetek-Seite jetzt wieder jeder Hinweis 
verschwunden, während der embedded war dort noch die Ankündigung. Weiß 
jemand wo die bei bridgetek dafür Zuständige Abteilung sitzt ? Ist das 
in UK oder Singapore ? Dürfen die noch arbeiten ?

[Rudolph R. (rudolph)]

Ich hatte jetzt auch schon länger keinen direkten Kontakt mehr zum 
Support, aber das Forum läuft ja noch und das geht nur moderiert.
Eigentlich ja, dafür das im Februar der Release sein sollte sind die 
Informationen immer noch recht dünn.

So wie ich das verstehe, muss nicht stimmen, läuft das schon 
international.
Support auf jeden Fall aus UK.

Was die Entwicklung mit dem BT817 und dem 1024x600 Display angeht,
so wie ich das verstehe, kannst Du das im Grunde mit einem BT815 
anfangen.
Die dürften ziemlich kompatibel werden.
Die BT817 sind dann nachher schneller und erlauben eine höhere Bildrate.
Aber um das LVDS Interface kommt man wohl nicht herum, es sei denn 
Bridgetek nutzt die Zeit um den BT817 nach den Ankündigungen über das 
eine Bild zur Embedded World noch mal zu überarbeiten.
Meine letzten Informationen sind von Anfang März.

Das ADAM101 von Glyn ist übrigens ein 10.1" mit FT813 und 1024x600.
Da ist ein LVDS Chip drauf.
Der FT813 ist meiner Meinung nach mit dem Display aber ein klein wenig 
überfordert.

Edit: es gibt einen neuen EVE Asset Builder V1.4:
https://brtchip.com/eve-toolchains/#EVEAssetBuilder

Unter anderem sollen die UTF-8 Probleme gefixt sein.

[Simon (Gast)]

Rudolph R. schrieb:
> Edit: es gibt einen neuen EVE Asset Builder V1.4:
> https://brtchip.com/eve-toolchains/#EVEAssetBuilder
>
> Unter anderem sollen die UTF-8 Probleme gefixt sein.

Ist mir auch schon aufgefallen und teste seit gestern. Habe die gleichen 
Tests gemacht wie bereits vor einigen Wochen beschrieben, aber das 
Problem ist unverändert da. Werde bei Bridgetek mal nach einem 
ESE-Beispiel inkl. Flashdaten fragen, mit dem es funktionieren soll.

[Rudolph R. (rudolph)]

Was mich ein wenig wundert ist die Größe der Dateien.
Ich habe gestern noch mal eine gestrippte Version von dem 
notosans-regular auf 100 Punkte konvertiert.
notosans-regular-webfont_100_ASTC.glyph 3272kB

Okay, warum nicht, ist ja auch Mordsgroß.
Nur wenn ich diese Datei in eine .zip packe, dann schrumpft das zu 74kB.
Okay, der Font hat 222 Glyphen.
Also mal ein einzelnes Zeichen testen.
"1": 40kB - 581 Bytes als .zip
".": 8kB - 337 Bytes als .zip
"a": 96kB - 924 Bytes als .zip

So schlecht kann ASTC doch eigentlich gar nicht komprimieren?

Dazu die Release-Notes:
V1.4.0:
    - Fix bugs:
      + The UTF-8 code point 0xF09FA183 (i.e. 0x1F843 for unicode) 
cannot be displayed
      + The glyph file is not compressed when the code point is in UTF-8
      + eab_tools.exe will not run on a fresh 64-bit Win10 machine
      + Image conversion fail if current output folder does not exist
    - Add the "Verify" function in flash utility
    - Recognize UTF8-BOM and remove it before converting
    - Speed up generating font when code point mode is UTF-8
    - Replace 'numpy' by 'tinynumpy' to reduce distribution package size

Irgendwie sieht das danach aus als wäre bei der 1.4.0 nicht der 
Font-Converter für die 1.4.0 dabei.

Edit: "eab_tools font_convert -v" : EVE Font Conversion Utility V0.1.6

Mit der 1.4.0 habe ich exakt das gleiche wie mit der 1.2.0.

[Simon (Gast)]

Klingt nach einer plausiblen Erklärung. Werde das im Bridgetekforum mal 
mit anklingen lassen :-)

[Mike T. (miket)]

Rudolph R. schrieb:
> Das ADAM101 von Glyn ist übrigens ein 10.1" mit FT813 und 1024x600.
> Da ist ein LVDS Chip drauf.
> Der FT813 ist meiner Meinung nach mit dem Display aber ein klein wenig
> überfordert.

Danke, das kannte ich noch nicht. Im Datenblatt des BT815/FT813 steht 
eigentlich eine maximale Auflösung von 800x600, aber scheinbar geht dann 
ja auch mehr.
Wieso meinst du, dass man dann unbedingt LVDS braucht ? Das Display das 
ich anstrebe gibt es auch mit TTL Interface. Müsste das dann nicht 
direkt gehen ?
Noch einen LVDS-Transmitter dazu bauen wäre aber auch kein Problem.

[Rudolph R. (rudolph)]

Mike T. schrieb:
> Danke, das kannte ich noch nicht. Im Datenblatt des BT815/FT813 steht
> eigentlich eine maximale Auflösung von 800x600, aber scheinbar geht dann
> ja auch mehr.

Das Maximum sind so theorethische 4096x4096 oder so.
Ist aber uninteressant, das Problem sind nicht die Pixel an sich.
Sondern der Pixel-Takt und dass das Bild ja auch noch erzeugt werden 
muss.
Mit dem ADAM101 lag ich glaube ich bei um 30 Bilder pro Sekunde.

> Wieso meinst du, dass man dann unbedingt LVDS braucht?

Na, unbedingt nicht, aber jenseits von 800x600 wird die Auswahl an 
Panels mit TTL Interfaces echt dünn.
Und LVDS stirbt auch schon wieder, MIPI DSI ist angesagt.

> Das Display das ich anstrebe gibt es auch mit TTL Interface.
> Müsste das dann nicht direkt gehen ?

Doch, das geht natürlich.

> Noch einen LVDS-Transmitter dazu bauen wäre aber auch kein Problem.

Das ist ganz schön hässlich im Layout, vor allem auch da die Signale 
vergleichsweise schnell sind.

[Mike T. (miket)]

Rudolph R. schrieb:
> Das ist ganz schön hässlich im Layout, vor allem auch da die Signale
> vergleichsweise schnell sind.

Da muss man auf die richtige Impedanz (100Ohm differenziell, 50 Ohm 
single ended) und gleiche Länge der einzelnen Leitungen achten, dann 
geht das schon. Dafür sind es auch nur 4 oder 5 Leitungspaare also 10 
Leitungen und nicht 27. Hab ich schon oft gemach, funktioniert wenn mans 
richtig macht.

[Rudolph R. (rudolph)]

Klar, geht das, keine Frage.
Und ich meinte jetzt auch mehr die andere Seite, also das TTL Interface 
an den LVDS Chip anzuklemmen.
Ich habe noch keinen LVDS Chip gesehen bei dem das einfach wäre, so mit 
TTL auf der einen Seite und LVDS+Versorgung auf der anderen Seite.
Irgendwie muss man immer 1/3 der Leitungen um den Chip herum wickeln.

Naja, ich werde sowas auch weiterhin nicht versuchen.
Gestern habe ich mal wieder nach Displays gefischt.
Über 800x600 und/oder über 7" gibt es praktisch nur welche mit LVDS.
Mit MIPI DSI habe ich jetzt gar nicht so viele gesehen.
Dann habe ich mit dem WF101FSYAPLNG0 ein nettes Teil gefunden mit dem 
man mal herum spielen könnte, nur kaufen kann man sowas dann natürlich 
nicht.
Aber naja, gibt eh kein richtiges Datenblatt einfach so frei dafür und 
der Aufwand dafür eine Platine zu machen steht auch in keinem Verhältnis 
zu dem Nutzen den ich davon hätte.

Das Spiel macht ohne Stückzahlen einfach keinen Spaß.

[Rudolph R. (rudolph)]

Ich habe heute einen Test-Sockel auf ein EVE3-43G gelötet um mal einen 
Satz weiterer Flash-Chips zu testen.

http://www.brtcommunity.com/index.php?topic=77.msg318#msg318

Chip  Size(MBit)  Detect  Erase  Read/Write  CMD_FLASHFAST
W25Q128JVSIQ  128  Yes  Yes  Yes  Yes
SST26VF064BA-104I/SM  64  Yes  Yes  Write fails  -
AT25QF128A-SHB-T  128  Yes  Yes  Yes  0xE004 - device/blob mismatch
W25Q32JVSSIQ  32  Yes  Yes  Yes  Yes
W25Q64JVSSIQ  64  Yes  Yes  Yes  Yes
IS25LP128F-JBLE   128  Yes  Yes  Yes  Yes
S25FL064LABMFI010  64  Yes  Yes  Yes  Yes
S25FL128LAGMFV010  128  Yes  Yes  Yes  Yes
MX25L6433FM2I-08G  64  Yes  Yes  Yes  Yes
IS25LP064A-JBLE  64  Yes  Yes  Yes  Yes
AT25SF641-SUB-T  64  Yes  ?  Yes  0xE004 - device/blob mismatch

[Axel V. (axel-f)]

Gestern habe ich versucht, ein Bild anzeigen zu lassen.
Habe es zuerst mit dem "EVE Asset Builder" in ein ARGB1555 umwandeln 
lassen. Angezeigt wurde nur ein gelbes Rechteck (foreground colour). 
Dann habe ich es mit ARGB4 versucht- gleiches Ergebnis. Bildgröße war 
200 x 130. Dann habe ich eine andere Datei genommen, auf ARGB4 gewandelt 
und als 108 x 123 angezeigt. Das hat funktioniert.
Erst als ich das Ursprungsbild auf 50 x 33 verkleinert hatte, konnte ich 
es (als ARGB4) anzeigen. Ich hänge das Ursprungsbild mal an.
Gibt es da irgendwelche Größenbeschränkungen?
Zum Anzeigen habe ich aus Deinem Beispiel verwendet:
  FT8_cmd_dl(DL_BEGIN | FT8_BITMAPS);
  FT8_cmd_setbitmap(MEM_WOLKE, FT8_ARGB4, 50, 33);
  FT8_cmd_dl(VERTEX2F(240*16, 10*16));

Muß man hier irgendwie mit den Farben im Ursprungsbild aufpassen?

Danke,
Gruß Axel

[Axel V. (axel-f)]

Oh, ich glaube ich hab's. Da war ganz am Anfang des Beitrags was von 
4k-Grenze zu lesen. An welcher Stelle ist die zu finden bzw. wodurch 
besteht diese Grenze?

Gruß Axel

[Rudolph R. (rudolph)]

Ich habe das gerade mal in meinen Test-Code eingebaut und ich habe 
soweit keine Probleme mit der Anzeige in 200x130.
Das erste ist ARGB4, das zweite ist ARGB1555 und das dritte ist direkt 
als .jpg verwendet und entsprechend als RGB565 angezeigt.
Ach ja, das ist ein EVE3-50G.

Die Bilder habe ich mit dem EVE Asset Converter Builder 1.4.0 
konvertiert aus der hier angehängten Original Datei.
Option "Compressed" an und "Dithering" aus.

ARGB4: 5925 Bytes
ARGB1555: 9665 Bytes

Zwei Sachen sind mir aufgefallen.
Zum einen das oben angehängt Bild, das ist komplett "verseucht" mit 
Meta-Daten.
Wenn ich das in IrfanView aufmache wird mir angezeigt: JPEG, quality: 
90, subsampling ON (2x2)
Also habe das ohne Meta-Daten und mit 90% Kompression wieder 
gespeichert.

JPG: 5190 Bytes

Entweder ist die Angabe zur Kompression in der Original-Datei gelogen, 
oder da stecken wirklich über 40KiB Daten in der Datei die nichts mit 
dem Bild zu tun haben.
Ich habe das nicht nachgezählt, aber wenn man die Datei mit einem 
Hex-Editor aufmacht ist da Text drin ohne Ende.

Oh ja, schöner Test, packt man die Original-Datei in eine .zip, so hat 
das Archiv dann 17053 Bytes.
Packe ich die neue Datei in eine .zip werden das 5222 Bytes.


Zum anderen benutzt Du irgendeinen alten Stand aus 2018.

[Rudolph R. (rudolph)]

Axel V. schrieb:
> Da war ganz am Anfang des Beitrags was von
> 4k-Grenze zu lesen. An welcher Stelle ist die zu finden bzw. wodurch
> besteht diese Grenze?

Das Problem besteht seit FT8_Commands.c Version 3.10 nicht mehr, also 
für cmd_inflate, für cmd_loadimage seit Version 2.7.
Die Ursache war, dass der Kommando-FIFO eben nur 4k groß ist und die 
Lösung war die Daten in Häppchen zu verschicken die kleiner als 4k groß 
sind.
Aus dem Grund ist in dem Zuge auch dazu gekommen, dass cmd_inflate nicht 
mehr "von Hand" ausgeführt werden muss, jedes Segment erfordert sowieso 
schon die Ausführung.

Aber ich bin mir gerade nicht mal sicher, ob in so einem Fall überhaupt 
was angezeigt worden wäre.

[Rudolph R. (rudolph)]

Wooohoo, it's happening:
https://www.matrixorbital.com/ftdi-eve/eve-bt817-bt818/eve4x-101g-ips-1

And I have no idea why, but I need to get one of these as well:
https://www.matrixorbital.com/ftdi-eve/eve-bt817-bt818/eve4x-40g-ips

[Rudolph R. (rudolph)]

A little heads up, 5.0 will remove FT80x support.
But 5.0 will also support BT817/BT818 and since I do not even have a 
programming manual for EVE4 yet, do not hold your breath. :-)

[Vladislav N. (vladineufeld)]

Hallo Rudolph,

haben die BT81X Chips Probleme dabei, große Grafiken darzustellen?
500x193 Pixel hat bei mir noch funktioniert. Aber bei 700x212 oder auch 
600x232 Pixel da wurde nur noch ein kleiner Teil des Logos dargestellt.

Mein aktuelles Vorgehen ist es, erst den Hintergrund des Logos zu 
entfernen und anschließend mit dem EVE Asset Builder zu komprimieren. 
Das Datenarray des komprimierten Logos speichere ich dann im Quellcode. 
Zur Übertragung des Arrays in RAM_G des Grafikcontroller nutze ich den 
inflate-Befehl. Dann sieht dann in etwa so aus:
....
Gpu_Hal_WrCmd32(phost,  CMD_INFLATE);
Gpu_Hal_WrCmd32(phost,  0);
Gpu_Hal_WrCmdBufFromFlash(phost,Logo_compressed, SIZE_COMPRESSED);

Gibt es eine Möglichkeit, größere Grafiken darzustellen?

Viele Grüße

Vladi

[Rudolph R. (rudolph)]

Zufällig habe ich am Freitag erst mit größeren Bilder was ausprobiert.
Da ging es zwar darum ob der BT815 ASTC komprimierte Bilder aus dem 
RAM_G benutzen kann, dafür habe ich aber ein 1400x792 Bild auf ASTC 8x8 
komprimiert.
Das hat per zlib komprimiert 267664 Bytes und per cmd_inflate() entpackt 
sind es 277200 Bytes.

Das Bild ist übel chaotisch, soll glaube ich Kunst sein, im Grunde eine 
Farb-Explosion die in Kacheln zerlegt wurde welche zufällig verteilt 
sind.
Egal, ich habe mir eben bewusst ein Bild gesucht das schlecht 
komprimierbar ist.

Und das klappt ohne Probleme.
Selbst rotierend und gleichzeitig gezoomt.

Ach ja, das ist auf einem EVE3-50G, also mit 800x480.

Also dachte ich mir gerade mal so, machen wir EVE doch ein wenig Stress. 
:-)
https://www.nasa.gov/multimedia/imagegallery/image_feature_329.html

Okay, das Bild hat 3000x3000, das bekomme ich weder in den Speicher, 
noch dürfte der BT815 das anzeigen, weil das Limit meine ich so bei 
2048x2048 liegt.
Also habe ich erstmal den Rand etwas abgeschnitten und das dann in 
mehreren Stufen verkleinert bis ich endlich eine Datei hatte die in 
meinen ATSAME51J19A passt - der hat "nur" 512k FLASH. :-)
Bei 1440x1440 sind das 484178 Bytes als ASTC 8x8 und "compressed",
514800 Bytes im RAM_G nach cmd_inflate().

Funktioniert auch einwandfrei, sogar rotierend und mit Faktor 1,567 
vergrößert. :-)

Also an dem BT815 liegt es nicht.
Und meine Library macht das auch einfach so mit:
https://github.com/RudolphRiedel/FT800-FT813

Wobei ich ja zugeben muss, ich habe am Freitag die Parameter für die 
Länge der Daten bei cmd_inflate(), cmd_loadimage() usw. von uin16_t auf 
uint32_t angehoben.

Das sieht bei mir im Kern so aus:

EVE_cmd_setbitmap(MEM_PIC2, EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 1440, 1440);

EVE_cmd_dl(CMD_LOADIDENTITY);
EVE_cmd_rotatearound(720, 720, rotate, 1.234 * 0xffff);
EVE_cmd_dl(CMD_SETMATRIX);

EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(VERTEX2F(-420, 65));
EVE_cmd_dl(DL_END);

EVE_cmd_dl(RESTORE_CONTEXT());

[Vladislav N. (vladineufeld)]

Rudolph R. schrieb:
 weil das Limit meine ich so bei
> 2048x2048 liegt.
> [/code]

Ok, jetzt bist du einen Anfänger eine Erklärung schuldig :D
Wie kann man denn Bilder mit 2048x2048 Pixeln oder so auf einem Display 
anzeigen, welcher nur eine Auflösung von 800 x 480 Pixeln hat?
Ich dachte, meine Bilder müssen kleiner als die 800x480 Pixel sein...

[Rudolph R. (rudolph)]

Klar, komplett anzeigen ohne das zu verkleinern geht natürlich nicht 
größer als die Auflösung des Displays ist.

Aber da die Koordinaten von VERTEX2F mit Vorzeichen sind kann man einen 
beliebigen Ausschnitt aus dem Bild anzeigen.

Die Frage war ja, ob die BT81x mit großen Bildern klar kommen.
Und die Antwort ist, dass die sogar mit übertrieben großen Bildern kein 
Problem haben. :-)

Was natürlich nicht geht ist ein .jpg mit 1024x600 zu laden, nach 
cmd_loadimage() ist das schlicht größer als die 1MB RAM_G.
Aber in ASTC bekommt man sogar mehrere 800x480 Bilder gleichzeitig in 
das RAM_G.

[Vladislav N. (vladineufeld)]

Moin,

benutzt du eigentlich SPI oder QSPI zur Kommunikation mit dem Display?

Ich mache gerade komischerwiese die Erfahrung, dass das Programm mit 
QSPI sehr instabil ist und sich schnell aufhängt, nachdem ich paar 
Nachrichten gesendet habe. Mit single SPI läuft alles perfekt. Kannst du 
dir das erklären? Am Code kanns wohl nicht liegen, da ich einfach die 
Bridgetek Bibliothek für den FT900 mC benutze.

Viele Grüße

Vladi

[Rudolph R. (rudolph)]

Ich benutze rein SPI, QSPI habe ich bisher nicht mal ernsthaft in 
Erwägung gezogen.
Die einzige Verwendung die mir dafür einfällt wären Videos.

Bei den HMIs die ich mache müssen für das Display-Update alle 20ms so 
<2k übertragen werden, bei 4MHz SPI dauert das so 4ms.
Und mit DMA sind das 4ms in denen der Controller nicht mal beschäftigt 
ist.

Beim Startup könnte QSPI noch helfen wenn man viele Bilder zu kopieren 
hat.
Mein letzter Test war ein 4xxk Bild im ASTC Format anzuzeigen,
das beim Start zu übertragen hat ein wenig länger gedauert.
Nur mache ich Projekte vorzugsweise nur noch mit BT815 und entsprechend 
externem FLASH.

Entsprechend habe ich auch noch nicht versucht eine Platine für QSPI zu 
designen, obwohl ich mit dem ATSAME51J19 zum Beispiel einen Controller 
einsetze der ein QSPI Interface hätte.

[Mike T. (miket)]

Falls die Info mal jemand benötigt :
Ich habe das ER-TFT101-1, ein günstiges 10,1" TFT mit 1024x600 und 
TTL-Schnittstelle von buydisplay.com an einem BT816 zum Laufen bekommen. 
Da im Datenblatt keine Angaben zum Timing stehen habe ich ne ganze Weile 
rumprobieren müssen. Hier sind die Displayeinstellungen die am Ende 
funktioniert haben ;

  wr32(REG_HCYCLE, 1232);
  wr32(REG_HOFFSET, 159);
  wr32(REG_HSIZE, 1024);
  wr32(REG_HSYNC0, 0);
  wr32(REG_HSYNC1, 1);
  wr32(REG_VCYCLE, 680);
  wr32(REG_VOFFSET, 23);
  wr32(REG_VSIZE, 600);
  wr32(REG_VSYNC0, 0);
  wr32(REG_VSYNC1, 1);
  wr32(REG_DITHER, 1);
  wr32(REG_PCLK_POL, 1);
  wr32(REG_PCLK, 2);//5
  wr32(REG_ROTATE, 0);
  wr32(REG_SWIZZLE, 0);

Vielleicht spart das ja jemandem ein bisschen Zeit.

[Rudolph R. (rudolph)]

Danke, das ist interessant.
Auch wenn ich dafür eher keine Platine bauen werde.

Die Timing Werte erscheinen mir (wie gewohnt) seltsam zu sein, auch die 
Werte aus den Arduino Beispielen auf BuyDisplay.com:

#define HPW       70
#define HND       160
#define HDW       1024
#define HST       160
#define VPW       10
#define VND       23
#define VDH       600
#define VST       12
#define SCREEN_WIDTH 1024
#define SCREEN_HEIGHT 600

Das schon echt zum Schreien, macht man drei Datenblätter auf, selbst vom 
geichen Hersteller, bekommt man drei unterschiedliche Datensätze die auf 
verschiedene Art unvollständig sind.

Deine Timing Werte ergeben mit dem BT816 auf 72MHz übrigens 42,97 Hz.

[Vladislav N. (vladineufeld)]

Rudolph R. schrieb:
> Bei den HMIs die ich mache müssen für das Display-Update alle 20ms so
> <2k übertragen werden, bei 4MHz SPI dauert das so 4ms.
> Und mit DMA sind das 4ms in denen der Controller nicht mal beschäftigt
> ist.

Wie kann man das berechnen mit den 4 ms?
Mit t = Datenmenge/Datenrate komme ich nicht auf den Wert

[Rudolph R. (rudolph)]

Schauen wir mal, ob das passt. :-)
4 MHz sind 250ns pro Bit, 1 Byte in 2µs.
4ms / 2µs sind 2000

Puh, nicht verrissen. :-)

[Vladislav N. (vladineufeld)]

Ahh klar, das war nicht so schwierig. :D

Was hat das für einen Grund, dass dein SPI auf 4 MHz läuft, wobei 30 MHz 
möglich sind?

Hast du einen Tipp, wie man herausfinden kann, wie viele Daten bei jedem 
Neuladen des Bildes an das Display gesendet werden?
Ich habe jetzt mal den Code genommen und alle DL- und CMD-Befehle 
gezählt und komme bei der GUI im Anhang auf 372 Byte.
Muss ich da noch etwas beachten? (Klar, wenn ich Bilder einfüge, dann 
muss ich deren Speicherbedarf auch noch addieren)
Kann ich irgendwie herausfinden, wie groß meine Display Liste am Ende 
ist?

Und wird bei EVE eigentlich immer das gleiche Bild nochmal gezeichnet? 
Gibt es dort keinen Mechanismus, der das effektiver gestaltet, wie zum 
Beispiel Differenzkodierung? Also dass nur die Parts neu gezeichnet 
werden, die sich auch wirklich ändern?

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
> Was hat das für einen Grund, dass dein SPI auf 4 MHz läuft, wobei 30 MHz
> möglich sind?

Das war nur ein Rechenbeispiel, war wohl nur nicht ganz ausführlich 
genug.
Meine Software ist gerade so aufgebaut das ich alle 5ms den Touch polle 
und alle 20ms das Display aktualisiere.
Die main.c im meinen Beispielen zeigt die Details.
Die Test-Funktion testet ob das Display noch beschäftigt ist, die Update 
Funktion nicht.
Also um nicht einen Touch-Poll zu überspringen muss das Update in 
weniger als 5ms durch sein, daher die 4ms.
Die 2k sind auch eher ein Phantasie-Wert, beim letzten richtigen Projekt 
hatte ich deutlich weniger als das.

Die Frage war nach QSPI, meine Antwort war das ich sebst bei single-SPI 
mit nur 4MHz noch kein Problem hätte.

Mit den ATSAMC21 lasse ich den SPI bei 12MHz laufen, beim ATSAME51 bin 
ich bei 15MHz.
Beim AVR habe ich 8MHz genutzt.

> Hast du einen Tipp, wie man herausfinden kann, wie viele Daten bei jedem
> Neuladen des Bildes an das Display gesendet werden?
> Kann ich irgendwie herausfinden, wie groß meine Display Liste am Ende
> ist?

Meine Beispiel-Programme machen das.
Unten links werden vier Zahlen angezeigt.
Geschickte Bytes, die resultierende Länge der Display-Liste, wie lange 
das Display-Update gedauert hat in micro-Sekunden und die wie lange die 
Touch-Poll Funktion beschäftigt war.

Das habe ich beim Entwickeln einer Oberfläche immer irgendwo auf dem 
Screen.
Die CMD-FIFO Liste sollte ja unter 4k bleiben, aber vor allem muss die 
resultierende Display-Liste unter 8k bleiben.

> Und wird bei EVE eigentlich immer das gleiche Bild nochmal gezeichnet?
> Gibt es dort keinen Mechanismus, der das effektiver gestaltet, wie zum
> Beispiel Differenzkodierung? Also dass nur die Parts neu gezeichnet
> werden, die sich auch wirklich ändern?

Man kann Display-Listen vorberechnen, per cmd_memcpy() irgendwohin in 
RAM_G schieben und so ein Fragment dann beim Erzeugen der eigentichen 
Display-Liste per cmd_append() einfügen.
Mein Beispiel zeigt auch das, es gibt eine Funktion 
initStaticBackground() in welcher die statischen Elemente der Anzeige 
drin sind, das ist im Fall des Beispiels ein Rechteck am oberen Rand, 
ein Logo, eine schwarze Linie zum trennen und Text für die 
Debug-Ausgabe.

Im dynamisch erzeugten Teil wird das per cmp_append mit eingeklinkt, 
zusätzlich ein Button angezeigt, ein Bild das gedreht wird und die 
Zahlenwerte für die Debug-Ausgabe.

Das könnte man auch noch weiter treiben und mit kleineren Blöcken machen 
bei denen sich nur ein Detail verändert.

/* display a button */
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_fgcolor(0x00c0c0c0); /* some grey */
EVE_cmd_dl(TAG(10)); /* assign tag-value '10' to the button that follows */
EVE_cmd_button(20,20,80,30, 28, toggle_state,"Touch!");
EVE_cmd_dl(TAG(0)); /* no touch */

Das braucht 32 Bytes, ein cmd_append braucht nur 12 Bytes.
Und das einzige was sich da ändert ist der Wert von "toggle_state" und 
auch nur mit zwei Werten.
Mit könnte also zwei Fragmente erzeugen und mit der Variable entscheiden 
welche man anhängt, das wären dann 20 Bytes weniger pro Update.

Oder man lässt es, weil man die Daten sowieso per DMA überträgt. :-)
Oder man setzt sich ein Limit von z.B. 1ms die das alles dauern darf und 
fängt erst mit trickreicheren Optimierungen an wenn man das reisst.

Da hört das auch noch nicht auf, was zum Beispiel auch was bringen kann 
ist die Kommandos so zu sortieren das weniger redundante Kommandos 
geschickt werden.

Wenn man zum Beispiel 16 Icons hat die rot grün oder blau sein können 
macht es mehr Sinn drei Blöcke für rot grün und blau zu haben als für 
jedes einzelne Icon die Farbe zu senden.
Das zieht zwar den Code im Controller auseinander, dafür hat man dann 
aber nur noch drei Farb-Kommandos statt 16.

[Vladislav N. (vladineufeld)]

Ah ok, interessant :)
Rudolph R. schrieb:
> Mit den ATSAMC21 lasse ich den SPI bei 12MHz laufen, beim ATSAME51 bin
> ich bei 15MHz.
> Beim AVR habe ich 8MHz genutzt.

wie kommen diese Werte zustande? Wie hast du ermittelt, dass sie am 
optimalsten sind?

Ich habe stelle mir gerade die Frage, welche SPI-Frequenz ich verwenden 
sollte. Ich muss MQTT-Daten (aktuelle Geschwindigkeit des Fahrzeugs) auf 
dem Bildschirm darstellen. Aktuell habe ich einen Task, welcher alle 100 
ms den MQTT-Buffer pollt und einen weiteren task, der alle 250 ms die 
Funktion aufruft, welche das Display neu zeichnen lassen soll. 
Eigentlich reicht es ja, die Fahrzeug-Daten 4 Mal pro Sekunde zu 
aktuallisieren sodass sich der Geschwindigkeitsbalken in Echtzeit 
aktuallisiert ^^
Nun habe ich berechnet, dass 30 MHz SPI 0,1 ms brauchen, um die 
EVE-Daten zu übertragen. Mit 1 MHz SPI würde das ganze 3 ms dauern. Also 
eigentlich könnte ich ja problemlos eine sehr geringe SPI Frequenz 
nehmen.

Sollte ich das tun? Das hat doch dann den Vorteil, dass der Strom durch 
das System geringer ist und dass das schonender für die Bauteile ist 
oder? ^^
Oder hast du einen Rat, welche Frequenz ich nehmen sollte.
Letzten Endes ist es egal aber ich will auch ne schöne Argumentation in 
meine Bachelor-Doku schreiben :D

[Rudolph R. (rudolph)]

Vladislav N. schrieb:
>> Mit den ATSAMC21 lasse ich den SPI bei 12MHz laufen, beim ATSAME51 bin
>> ich bei 15MHz.
>> Beim AVR habe ich 8MHz genutzt.
>
> wie kommen diese Werte zustande? Wie hast du ermittelt, dass sie am
> optimalsten sind?

Das sind nicht die "optimalsten" Werte, das sind die schnellsten Werte.
Beim AVR geht nicht mehr als 8MHz und da der kein DMA kann geht die 
Datenübertragung voll mit ein in die Zeit für die Aktualisierung.

Der ATSAMC21 läuft mit 48MHz, hat nur eine PLL und die Frequenz wird 
eingestellt mit der Formel: Clock / (2 * (BAUD + 1))
BAUD 0: 24MHz
BAUD 1: 12MHz
BAUD 2: 8MHz
BAUD 3: 6MHz

Bei 24MHz funktioniert nur der Touch nicht mehr mit meiner Hardware.
Ich vermute wegen der Laufzeit der Gatter die ich zwischen Controller 
und Display habe.

Beim ATSAME51 ist es im Grunde das gleiche, nur füttere ich da (nicht 
ganz nach Spec) 120MHz in den SPI und komme mit einem BAUD Wert von 3 
auf 15MHz.
Bei einem Wert von 4 und entsprechend 20MHz funktioniert der Touch nicht 
mehr.

Die Anzeige an sich ist auch mit viel schnellerem SPI stabil.

Benötigt wird das nicht wirklich und ich nutze mit beiden ATSAM DMA, 
also könnte ich den SPI auch langsamer machen, etwa aus EMV Gründen.
Dazu noch die Flanken etwas runder durch andere Bestückung.
Nur mache ich keine Produkte in dem Sinne, EMV ist zwar wichtig, aber 
normalerweise nicht entscheidend.
Und die Störabstrahlung messen um die Wirksamkeit einzelner Maßnahmen zu 
überprüfen könnte ich eh nicht.

[Rudolph R. (rudolph)]

Rudolph R. schrieb:
> A little heads up, 5.0 will remove FT80x support.
> But 5.0 will also support BT817/BT818 and since I do not even have a
> programming manual for EVE4 yet, do not hold your breath. :-)

Time for a status update, I just finished annother step of what I had in 
mind for 5.0 and somehow it went a lot smoother than I thought it would.

- FT800 / FT801 support is gone
- split all display-list commands into two functions: EVE_cmd_XXX() and 
EVE_cmd_XXX_burst()
- switched to use REG_CMDB_WRITE

My display-list generation looks like this now:

EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */
EVE_cmd_dl_burst(CMD_DLSTART); /* start the display list */
EVE_cmd_dl_burst(DL_CLEAR_RGB | WHITE); /* set the default clear color to white */
EVE_cmd_dl_burst(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); /* clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers */
EVE_cmd_dl_burst(TAG(0));
EVE_color_rgb_burst(BLACK);
EVE_cmd_text_burst(10,190,29,0, "The quick brown fox...");
EVE_cmd_dl_burst(DL_DISPLAY);  /* instruct the graphics processor to show the list */
EVE_cmd_dl_burst(CMD_SWAP); /* make this list active */
EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */

And to pick one example of what this looks like underneath with V4:

void EVE_cmd_bgcolor(uint32_t color)
{
  EVE_start_cmd(CMD_BGCOLOR);

  if(cmd_burst)
  {
    spi_transmit_async((uint8_t)(color));
    spi_transmit_async((uint8_t)(color >> 8));
    spi_transmit_async((uint8_t)(color >> 16));
    spi_transmit_async(0x00);
  }
  else
  {
    spi_transmit((uint8_t)(color));
    spi_transmit((uint8_t)(color >> 8));
    spi_transmit((uint8_t)(color >> 16));
    spi_transmit(0x00);
    EVE_cs_clear();
  }

  EVE_inc_cmdoffset(4);
}

With 5.0 this looks a bit different:

void EVE_cmd_bgcolor(uint32_t color)
{
  if(!cmd_burst)
  {
    EVE_start_command(CMD_BGCOLOR);
    spi_transmit((uint8_t)(color));
    spi_transmit((uint8_t)(color >> 8));
    spi_transmit((uint8_t)(color >> 16));
    spi_transmit(0x00);
    EVE_cs_clear();
  }
}

void EVE_cmd_bgcolor_burst(uint32_t color)
{
  spi_transmit_burst(CMD_BGCOLOR);
  spi_transmit_burst(color);
}

So spi_transmit_burst() replaces spi_transmit_async().
It will either write out four bytes over SPI or add a 32 bit value to 
the DMA buffer instead of splitting the parameters into bytes.

The normal commands are protected to be used outside of command-burst, 
they will just do nothing.
The new _burst commands are not protected anymore and also do not call 
annother function anymore.

I still have to finish this and retest this with a more complex display 
list but the initial speed tests I did back in June showed an 
improvement of about 30%, so display list generation will be faster.

Also the binary size should be a little smaller since all the functions 
that are not needed are removed by the linker.

[Rudolph R. (rudolph)]

Okay, I just did the first test directly comparing V40 und V50.
Attached are the functions that are compared.
These are functionally the same but for V50 all functions between 
EVE_start_cmd_burst() and EVE_end_cmd_burst() have the new suffix 
"_burst" attached.

This is just the simple test code I am using in the examples.

And the result surprised me a little.

V40
TFT_display() with DMA: 129µs
prog-size: 15436
TFT_display() without DMA: 360µs
prog-size: 15276

V50
TFT_display() with DMA: 51µs
prog-size: 12524
TFT_display() without DMA: 324µs
prog-size: 13420

That is fairly substantial.

The test werde done with an ATSAMC21 running 48MHz and an EVE3-50G.

And as V50 is somewhat tied to BT817/BT818, there was this statement 
over in the BRT Community a couple of days ago:
"The BT817 and BT818 will be released at the beginning of November"

I do already have a BT817 based module to tinker with, I can not share 
any details yet, but I should be prepared for the release. :-)

[Rudolph R. (rudolph)]

I just did annother small scale test, this time with an Arduino UNO 
clone and a slightly modified version of my example code.

V4:
TFT_display(): 664µs
prog-size: 12272

V5:
TFT_display(): 520µs
prog-size: 10322

So it might be less comfortable to have separate EVE_cmd_xxx() and 
EVE_cmd_xxx_burst() functions, but it sure is faster and takes less 
space even on 8 bit controllers.

And I changed my plans, I will release this earlier.
I only have to remove anything related to BT817 for now before I put it 
up on Github.
Well, I also need to brush up, modify and test my example codes.

[Rudolph R. (rudolph)]

The first version of V5 is up:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x

[Werner (Gast)]

Hallo Rudolph,
ich arbeite gerade an einem Projekt mit dem FT811 und habe eine einfache 
Frage:
Gibt es eine einfache Möglichkeit zum Zeichen eines gefüllten Dreiecks?
Habe dazu leider nichts gefunden.
Danke im Vorraus.
Werner

[Rudolph (Gast)]

Nein, Dreiecke kann EVE nicht, zumindest keine gefüllten.
Aber, mit Edgestrip und Scissors kann man das wohl hinbekommen, das 
fällt nur nicht mehr in die Kategorie "einfach".

[Rudolph (Gast)]

Hier wird sowas in der Art diskustiert, nur probiert habe ich das noch 
nicht: http://www.brtcommunity.com/index.php?topic=163.0

[Werner (Gast)]

Danke für die schnelle Antwort!
Das schau ich mir mal an.

Werner

[Daniel S. (snipod)]

Hi,
wollte mich auch mal kurz zu Wort melden.
Ich habe meine ersten Schritte mit dem EVE Controller auf einem ESP32 
mit Rudolphs Bibliothek gemacht und kann nur sagen, sau gut und vielen 
Dank!

Ich habe noch eine Hardware-Spezifische Frage und hoffe, dass mir jemand 
weiterhelfen kann.

Ich würde gerne für mein Projekt ein eigenes HMI erstellen, leider werde 
ich aus den Informationen, die man bei Bridgetec erhält nicht ganz 
schlau.
Und zwar würde ich gerne ein 4" Display mit 720x720 px und CTP verbauen 
und es mit einem EVE4 ansteuern.
Matrix Orbital baut wohl gerade so ein Display, allerdings wollen die 
mir meine Kundenspezifischen Wünsche nicht so ganz erfüllen (SPI über 
LVDS + Spannungsregler on Board...) 
https://www.matrixorbital.com/ftdi-eve/eve-bt817-bt818/eve4x-40g

Das Panel habe ich denke ich gefunden:
https://www.panelook.com/TL040HDS01-TDO-4-inch-4-square-720-720-tft-module-IPS-RGB-interface-touch-optionalw-YY1821-detail_92079.html

Meine Frage wäre: Kann der EVE ohne große Probleme die 720x720 px 
ansteuern (Nominell ja nur 800x600), Funktioniert das mit den "nur" 18 
Bit Farben? Hat jemand den ein oder anderen beispiel-Schaltplan? Bei NHD 
gibts ja bisschen was aber würde mir gerne mehr als nur ein Beispiel mal 
anschauen.

Für alle Tips und Hilfe bin ich sehr dankbar :)

[Rudolph R. (rudolph)]

die 720x720 sind erstmal so für sich kein Problem, das würde auch mit 
den FT81x gehen.
Wo der BT815 und erst recht der BT817 einen enormen Unterschied machen 
ist in der erreichbaren Wiederholrate.
Der BT815 hat den Vorteil einen höheren Basistakt zu haben und 
entsprechend einen daraus abgeleiteten höheren Pixel-Clock machen zu 
können.
Die BT817 gehen da einen Schritt weiter und sind generell besser geignet 
für Displays mit ein wenig mehr Pixeln, nur wieso, weshalb, warum, kann 
ich nicht ausplaudern. :-)
Aus dem Grund ist auch der ganze BT817/BT818 Code aus der V5 meiner 
Library entfernt.

Weniger Bits pro Farbe gehen schon, die unteren Bits bleiben dann offen 
soweit ich weiß.
Im Datenblatt vom FT81x sieht man das, die FT810/FT811 haben R0, R1, G0, 
G1, B0 und B1 gar nicht erst heraus geführt.
Mir fällt nur gerade kein Modul ein das einen FT812/FT813/BT81x 
verwendet aber nur 6 Bits pro Farbe nutzt.
Ich finde das nur anders herum, ein FT810 oder FT811 und nicht alle 
Anschlüsse am Display belegt.

NHD, also Newhaven ist jetzt auch nicht gerade das schönste Beispiel für 
Informationen so im Allgemeinen.
Auf der Homepage steht das die EVE Module Open Source wären, die Daten 
bekommt man aber nicht mal auf Anfrage, weil die offenbar gar nicht 
wissen wofür das "Source" eigentlich steht.
Immerhin haben die einen Schaltplan im Manual, das machen längst nicht 
alle so.


Ich habe mich damit abgefunden, dass ich einfach nicht die Stückzahlen 
habe um meine Wünsche in ein Display gegossen zu bekommen.

Also baue ich mir Platinen die ich über das Folien-Kabel mit den 
Display-Modulen verbinden kann.
Zwei Varianten davon speziell für 3D-Drucker habe ich veröffentlicht:
https://github.com/RudolphRiedel/EVE_display-adapter

Es gibt aber auch noch D5019-02, D5019-03, D5019-04 und D5019-06. :-)

Die D5019-02 ist eine Briefmarke für die 16pol. Schnittstelle von Glyn, 
der D5019-01 sehr ähnlich, nur ohne den dicken 10pol. Stecker.
Die D5019-03 hat einen SAMC21E18A drauf und eine CAN-FD-Schnittstelle.
Die D5019-04 hat einen SAMC21E18A und 1x CAN-FD und 1x LIN.
Die D5019-06 kann ich mit einem SAMC21J18A oder einem SAME51J19A 
bestücken und 2x CAN-FD und 2x LIN nutzen.

Mein aktuelles Projekt verpackt ein EVE3-43G in eine Art Tablett-Gehäuse 
mit der D5019-06, auf einem SAMC21 läuft die ganze Anwendung, ein CAN 
spricht mit dem Auto und ein LIN läuft als Master für eine weitere 
Komponente.
Mein Projekt davor hatte ein EVE2-70G und eine D5019-04 im Gehäuse und 
auf dem SAMC21 lief nur das HMI, Touch wurde per CAN gemeldet und die 
Anzeige auf Anforderung per CAN aktualisiert.

Bei den kleinen Displays packe ich die Controller-Platine als Sandwich 
über die Display-Platine.
Bei den 7" ist genug Platz das daneben zu legen.

Wenn ich denn unbedingt LVDS oder RS422 oder was anderes passives machen 
müsste was wieder einen SPI umgesetzt wird, würde ich entsprechend eine 
neue Adapter-Platine dafür bauen.
Na okay, eher würde ich versuchen dem Kollegen der das haben will die 
Geschichte auszureden und statt dessen eine Anbindung per CAN und 
Controller anbieten. :-)

[Daniel S. (snipod)]

Hi Rudolph,
erst mal vielen Dank für die fundierte Antwort!

Offensichtlich bist Du der EVE-Guru :)

Vermarktest Du deine BT816/817 basiertes Wissen, oder hat dein AG da die 
Hand drauf? :)

Der Kollege, der sich das mit dem SPI über LVDS ausgedacht hat, bin 
ich... Die Idee dahinter ist, dass ich mein HMI, welches dezentral von 
meinem Steuergerät verbaut werden wird, über mein Steuergerät updaten 
können will. Wenn ich nun einen weiteren Controller auf der 
Display-Platine verbaue, müsste ich diesen dann über z.B. CAN Updaten. 
Das wäre natürlich möglich, ob es wirklich besser ist, als SPI <-> LVDS 
/ RS422 Konversion weiß ich nicht... die LVDS Treiber / Receiver 
SN65LVDS33 / 31 sind jetzt nicht gerade aufwendig zu implementieren und 
auch nicht wirklich teuer.
CAN hätte den Charm, dass man weniger Kabel bräuchte 4 (5V/GND/CAN H/CAN 
L) vs 12, oder sogar auf eine kabellose Kommunikation ausweichen 
könnte... Außerdem wäre der Controller etwas entlastet, wobei sich mein 
ESP32 mit 240 MHz aktuell doch noch ziemlich langweilt und die 
Programmierung des Hauptprogramms ist so gut wie fertig...

Ich fange einfach mal an, einen Schaltplan zu erstellen und teile meinen 
Progress mit, vielleicht hat ja mal jemand ein Auge drauf ;)

Viele Grüße

[Rudolph (Gast)]

Daniel S. schrieb:
> Offensichtlich bist Du der EVE-Guru :)

Naja, ich bin eifrig bemüht, aber FTDI/BRT möchte auf viele meiner 
Fragen einfach nicht antworten. :-)

> Vermarktest Du deine BT816/817 basiertes Wissen, oder hat dein AG da die
> Hand drauf? :)

Weder noch, mein AG macht wenig bis keine Produkte, meine Projekte sind 
mehr so interne Tools, Einzelstücke.
Ich sehe das als Hobby und freue mich wenn ich das auch mal im Job 
anwenden kann.

> Der Kollege, der sich das mit dem SPI über LVDS ausgedacht hat, bin
> ich...

Da muss ich Dich enttäuschen, kein Daniel S. in unserem Telefonbuch. :-)

Ich habe ja nur ein wenig aus dem Nähkästchen geplaudert was für mich 
gerade Sinn macht, wir haben überall CAN und die Tools dafür.

Aber die Platinen für die Drucker gehen ja eher in die Richtung was Du 
gerade brauchst, Schnittstelle, Netzteil, kein Controller.
Das ist einfacher umzusetzen und flexibler als eine komplette Platine 
mitsamt EVE drauf zu bauen, vor allem weil sich dann der 
Modul-Hersteller mit den Displays an sich herum ärgern muss.

> Außerdem wäre der Controller etwas entlastet, wobei sich mein
> ESP32 mit 240 MHz aktuell doch noch ziemlich langweilt und die
> Programmierung des Hauptprogramms ist so gut wie fertig...

Was soll der eigentlich grob noch so machen? Die können ja eigentlich 
fast nichts per I/O.

[Daniel S. (snipod)]

Rudolph schrieb:
> Naja, ich bin eifrig bemüht, aber FTDI/BRT möchte auf viele meiner
> Fragen einfach nicht antworten. :-)

Ja, die sind irgendwie ziemlich langsam...

Rudolph schrieb:
> Ich habe ja nur ein wenig aus dem Nähkästchen geplaudert was für mich
> gerade Sinn macht, wir haben überall CAN und die Tools dafür.

CAN an und für sich ist ja auch nicht wirklich kompliziert, ich habe 
auch schon eine Handvoll Projekte damit gemacht, allerdings wird damit 
der ganze Programmieraufwand noch höher was das Update angeht. Mein 
Problem ist, dass das ganze zu groß wird, wenn ich es als "Rucksack" auf 
so ein EVE Board setze :( Das Projekt soll möglichst schlank werden, 
damit es gut zu verbauen ist, bzw gut in der Hand liegt.
Es handelt sich hier nicht um ein Einzelstück, aber auch nicht um eine 
Großserie, da mach ich mir nichts vor... Es soll am Ende eine Steuerung 
für ein Luftfahrwerk werden. Das heißt der Controller muss ein paar 
Sensoren auslesen und basierend auf deren Daten und den Eingaben des 
Benutzers Ventile öffnen...
"mehr" ist es nicht...
Die IO Kapazitäten des ESP erweitere ich aktuell einfach mit i2c ics, 
das funktioniert soweit auch ganz gut :) Ich habe mich seinerzeit für 
den Esp entschieden, da ich den Support und die Doku ganz gut finde, 
außerdem kann man Updates beliebig einfach einspielen und so weiter... 
Um seine magere IO Ausstattung komme ich ja per i2c ganz gut herum. Am 
Ende brauch ich eh "nur" 12 ADC Kanäle und um die 10 GPIOs...

Rudolph schrieb:
>> Der Kollege, der sich das mit dem SPI über LVDS ausgedacht hat, bin
>> ich...
>
> Da muss ich Dich enttäuschen, kein Daniel S. in unserem Telefonbuch. :-)

Ich meinte natürlich nicht das Prinzip, sondern als "workaround" für 
längere Kabellwege im KFZ in dieser Applikation :)

Ich schau mal wie weit ich komme und poste einfach mal meinen 
Schaltplan... :)

[Rudolph (Gast)]

Daniel S. schrieb:
> Rudolph schrieb:
>> Naja, ich bin eifrig bemüht, aber FTDI/BRT möchte auf viele meiner
>> Fragen einfach nicht antworten. :-)
>
> Ja, die sind irgendwie ziemlich langsam...

Das auch, ich meinte das aber wie ich schrieb, meine Fragen gehen zum 
Teil etwas zu tief. :-)

Daniel S. schrieb:
> Das Projekt soll möglichst schlank werden,
> damit es gut zu verbauen ist, bzw gut in der Hand liegt.

Mit den I/Os ist das schwieriger, keine Frage.

Angehängt mal zwei Bilder mit was ich gerade so herum spiele.
Mit 18mm Dicke ist das recht fett für ein "Tablett", liegt aber gut in 
der Hand.

Wenn man da mehr Kabel raus führen würde, wäre das aber sicher schnell 
sehr lästig, ich muss da aktuell nur +/-/CAN/LIN raus führen und es wird 
auch am Ende nicht mehr in der Hand gehalten.

Ein Platinchen als Schnittstellen-Adapter müsste deutlich kleiner 
werden.

[Daniel S. (snipod)]

Rudolph schrieb:
> Angehängt mal zwei Bilder mit was ich gerade so herum spiele.
> Mit 18mm Dicke ist das recht fett für ein "Tablett", liegt aber gut in
> der Hand.

Sieht sehr robust aus :) Ich denke für den Stationären Einsatz und 
generell als Einzellösung bin ich auch immer ein Freund für solche 
"Zusatzlösungen" um Entwicklungstools herum. Leider wird so etwas meinen 
Ansprüchen an dieses Projekt nicht so ganz gerecht :(

In der Kommunikation mit den Herstellern dieser EVE Boards kam bisher 
eigentlich raus, dass zumindest die Leute die mir die Mails schreiben, 
nicht wirklich wissen worum es geht...

Ich habe mal, basierend auf dem DB des BT815Q, sowie meiner bisherigen 
Testplatine (SPI <-> LVDS) einen Schaltplan erstellt, der relativ 
komplett und vor allem am Ende ziemlich kompakt sein dürfte.

Im DB des Displays, was ich gefunden habe, steht leider nichts zum 
"Reset" Pin, außerdem hab ich noch keine Info, was den Anschluss das CTP 
betrifft...

Den Reset Pin "Active Low" würde ich entweder einfach an 3V3 oder mit an 
PD vom EVE hängen...(?)

Vielleicht finde ich ja noch ein besser dokumentiertes Panel in der 
Größe und Auflösung mit 24 bit RGB... mal schauen

[Rudolph (Gast)]

Die Belegung von dem 40pol. am Panel sagt mir gleich wieder warum ich 
sowas nicht selber machen will, das passt zu nichts anderem. :-)

Die Positionen der Kabel am Display sind das nächste Problem.
Wenn man zwei Panels mit der gleichen Anschlussbelegung gefunden hat 
kann man sicher sein, dass die Kabel nicht auf der gleichen Position 
sind, oder unterschiedlich lang, das CTP Kabel mehr oder weniger Pins 
hat oder alles zusammen.

Für den Reset könnte es helfen ein Datenblatt von dem verbauten YY1821 
Treiber Chip zu haben, der chinesische Hersteller AXS bietet aber 
erstmal keines zum Download an.

So richtig ungewöhnlich ist das auch nicht, Displays sind keine 
Commodity Items und entsprechend ist das immer wieder lustig wenn man zu 
irgendeinem Display Informationen haben möchte.
Wenn man weniger als 100k Displays kaufen möchte existiert man für die 
Hersteller praktisch nicht.

Daniel S. schrieb:
> außerdem hab ich noch keine Info, was den Anschluss das CTP
> betrifft...

Das dürfte daran liegen, dass das Display gar keinen Touch hat.


Da fehlen wahrscheinlich auch noch ein paar Pullup/Pulldown Widerstände.
Und vielleicht auch noch Reihenwiderstände in den SPI Leitungen, damit 
man bei Problemen was über Null Ohm bestücken könnte.

[Daniel S. (snipod)]

Rudolph schrieb:
> Da fehlen wahrscheinlich auch noch ein paar Pullup/Pulldown Widerstände.
> Und vielleicht auch noch Reihenwiderstände in den SPI Leitungen, damit
> man bei Problemen was über Null Ohm bestücken könnte.

jaja, ich weiß :) war ja nur der stand ohne das richtige Display und 
so...

Rudolph schrieb:
> Das dürfte daran liegen, dass das Display gar keinen Touch hat.

Das stimmt, gibt es aber auch mit Touch und ist beim Hersteller 
angefragt...


Ich überlege gerade doch einen Controller auf die Platine zu packen und 
CAN zu nutzen... Vorteile wären, dass es 1. weniger Kabel sind, 2. CAN 
sicherlich noch mal Störungsunanfälliger ist als SPI über LVDS und 3. 
ich Displays nutzen könnte, deren Controller zusätzlich über SPI 
konfiguriert werden müssen, ohne noch einen weiteren LVDS Receiver auf 
die Platine packen zu müssen.

Nachteil wäre ich müsste noch Routinen Schreiben, um den Controller am 
Display über CAN upzudaten. Ist natürlich kein riesen Problem, über 
Bluetooth und WiFi habe ich es auch schon implementiert am ESP...

[Ioan Mihai C. (mihaicozac)]

Hallo nochmal,
  Versuche gerade eine Screenshot Funktion zu schreiben, und wie 
erwartet funktioniert nicht wie es seien sollte. Die Funktion startet 
und läuft, der Bildschirm zeigt bewegende vertikale Streifen die die 
verschiedenen Zeilen des Bildschirminhaltes entsprechen, wenn das Bild 
fertig gescannt wurde springt dann zurück auf normales Bild. Die Daten 
werden über die zweite serielle Anschluss des ESP32 versendet, auf dem 
Computer mit die Software "Free Serial Port Monitor" in .ppm Datei 
gespeichert danach mit Paint.net überarbeitet. Leider bekomme ich auf 
dem Computer nur vertikale Streifen als Dateiinhalt, die noch nicht mal 
einer originale Bildzeile ähnlichen. Die Kopfzeile der Datei ist OK, 
P6.800.480.255 (.ppm header).
Bin mir sicher dass ich irgendwas falsch mache, weiss aber nicht wo und 
was.
Anbei meiner verwendete Code:

 void screenshot()
 {
  unsigned long RAM_BUFFER = 0x00010000; // BUFFER START ADDRESS
  unsigned int x, y;
  EVE_memWrite8(0x00302010UL,1); // REG_SCREENSHOT_EN ACTIVATED
  Serial2.write("P6\n800\n480\n255\n");  // PPM FORMAT HEADER
  for (y = 0; y < 480; y++)
   {
    EVE_memWrite16(0x00302014UL, y);     // REG_SCREENSHOT_Y
    EVE_memWrite8(0x00302018UL, 1);      // REG_SCREENSHOT_START
    for (x = 0; x < 800; x++)
     {
      unsigned char b = EVE_memRead8(RAM_BUFFER + x);
      unsigned char g = EVE_memRead8(RAM_BUFFER + x + 1);
      unsigned char r = EVE_memRead8(RAM_BUFFER + x + 2);
      Serial2.write(r);
      Serial2.write(g);
      Serial2.write(b);
     }
   }
  EVE_memWrite8(0x00302010UL, 0);        // REG_SCREENSHOT_EN DEACTIVATED 
 }

Bin für jeden Tipp dankbar.

[Rudolph (Gast)]

Du hast doch schon einen FT81x, warum nimmst Du dann nicht 
CMD_SNAPSHOT2?

Selber benutzt habe ich das auch noch nicht, vor allem da ich die Daten 
nicht aus der Hardware raus bekomme.
Aber in einem Projekt hat ein Kollege das praktisch so benutzt:

EVE_cmd_snapshot2(EVE_RGB565, SNAPSHOT_BUFFER_START, 
Snapshot_X_Start_ui16, Snapshot_Y_Start_ui16, Snapshot_X_Size_ui16, 
Snapshot_Y_Size_ui16);

Für die V4 meiner Library käme da noch hinzu:
EVE_cmd_execute();

Für die V5 braucht man das aber nicht.

Danach ging das dann über CAN raus und er hat das irgendwie am PC 
eingelesen und konvertiert, war schon schick soweit.

[Ioan Mihai C. (mihaicozac)]

Danke, werde mal probieren.

[Simon (Gast)]

Hallo nochmal auch von mir,

für meine Screenshotfunktion verwende ich snapshot2, die Rudolph bereits 
empfohlen hat. Damit gab es bei mir keine Probleme.
Das Prinzip bei mir ist ähnlich, ich schreibe den Screenshot 
streifenweise in eine Datei auf einen USB-Stick. Das kann ich mir dann 
auf dem PC mit ffmpeg in ein gültiges Bild-Format konvertieren.
Was mir spontan auffällt ist, dass die snapshot Funktion, die du 
verwendestest das Bild im ARGB4-Format mit 16 Bit pro Pixel abspeichert. 
Du liest allerdings 24 Bit pro Pixel aus, wodurch sich alles verschieben 
dürfte. Die Zuweisung der RGB-Werte stimmt dann dementsprechend auch 
nicht.

[Rudolph R. (rudolph)]

It is happening. :-)
https://brtchip.com/bt81x/

Following the official release of BT817 / BT818 with datasheet and 
programming manual I just pushed the first release of my code library to 
Github with support for BT817 / BT818.

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

There may be some kinks left as I did not have the programming manual 
before and was using a preliminary version of the datasheet, but in 
general it works.

[Werner (Gast)]

Hallo Rudolph,

ich bekomme bei einem Display einen Streifen auf einen Button (siehe 
Bild, Button Prog)

Weisst du woran das liegen kann?

Viele Grüsse
Werner

[Karol (Gast)]

Werner schrieb:
> Hallo Rudolph,
>
> ich bekomme bei einem Display einen Streifen auf einen Button (siehe
> Bild, Button Prog)
>
> Weisst du woran das liegen kann?
>
> Viele Grüsse
> Werner

Are you sure, this line is only on "Prog" button? I saw something like 
this when ZIF connector has some dust on pin/pins (connector was dirty 
inside).

Best's
Karol

[Werner (Gast)]

I have it on another button with red color, too. And it deoends on the 
color I use.
When I use another display (other manufacturer) there is no line.

[Rudolph R. (rudolph)]

Okay, das ist mir auch noch nicht untergekommen.

Ist das ein normaler Button oder was eigenes?
Was ist das überhaupt für ein Display? CFAF240400?

Kannst Du die GUI soweit frei schneiden das Du einen Testcase erstellen 
kannst ohne sonst was von dem Projekt weitergeben zu müssen?

Oder zeigt doch mal bitte wie die Zeilen für den Button und unmittelbar 
drum herum so aussehen.

[Wertner (Gast)]

Es ist ein Button, der mit dem Button Befehl erstellt wird.

Hier der Code Ausschnitt:

EVE_cmd_romfont(0,32);      // Romfont laden
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_fgcolor(PINK_1);
EVE_cmd_dl(TAG(t_prog));
EVE_cmd_button(250, 710, 220, 80, 0, 0, "    Prog");
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_setbitmap(MEM_PIC_progsym, EVE_ARGB2, 50, 50);  // Prog Symbol 
Taste
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(VERTEX2F(267, 725));

Farben:
#define PINK_1  0xB97894UL
#define WHITE  0xffffffUL
#define RED  0xDC3545UL

Bei einem Button der Farbe RED gibts auch einen Streifen.
Wenn ich die Farben ändere bekomme ich die Streifen (fast ganz) weg.

Das Display ist von Autronic, speziell für dieses Projekt, Datenblatt im 
Anhang. Möglicherweise sollte ich mir die Timings mal genauer ansehen.

Wenn ich das Display vom VM810C Kit nehme ist kein Streifen zu sehen.

[Rudolph R. (rudolph)]

Das sieht soweit doch erstmal harmlos aus.
FT813?
Was der Button mit dem Bild zu tun hat ist mir so erstmal nicht klar.

Das Timing von dem Panel ist etwas anders als bei allen anderen 800x480 
die mir bisher untergekommen sind.
Das ist reichlich straff mit kurzen Zeilen und kaum extra Zeilen.
Meine "Standard" Timings für 800x480 würde ich dafür auch nicht 
verwenden wollen.

[Werner (Gast)]

Hallo Rudolph,
Der Controller ist der FT811.
Das Bild sind die 4 Quadrate auf dem Button. Das Timing schau ich mir 
jetz
mal noch genauer an aber trotzdem vielen Dank für die Unterstützung!!

[Rudolph R. (rudolph)]

Äh, ja, jetzt, danke. :-)

>Der Controller ist der FT811.

Lohnt sich das wirklich?
In der Apotheke kostet der FT813 doch gerade mal 30 Cent mehr pro Stück 
bei 100 Stück, aber dafür kann der das Display auch mit 24 Bit Farbe 
ansteuern.

Klar, das sollte nichts machen, aber so ein schönes Display und dann die 
Farbtiefe durch den EVE Chip beschneiden... :-)

Ich glaube ich muss das mal ausprobieren.
Eigentlich sollte das funktionieren, aber zuweilen führen "komplexe" 
GUIs auch zu interessanen Problemen für EVE. :-)

[Ioan Mihai C. (mihaicozac)]

#define PINK_1  0xB97894UL

Bei 6 bit pro Farbe sind keine ungerade Werte möglich...
Vielleicht ist der Wert B9 für Rot nicht zugelassen für FT811.

[Ioan Mihai C. (mihaicozac)]

Also wie 00, 03, 07, 0A usw. als Werte.

[Werner (Gast)]

Das mit den ungeraden Werten macht keinen Sinn, da ein anderes Display 
ja ohne den Streifen funktioniert.
#Rudolph
Mit der 24Bit Farbtiete hast du schon recht, ich war bisher auch der 
Meinung, daß der Preisunterschied grösser ist... und man darf auch nicht 
vergessen, daß man sich immer noch Platz nach oben lassen muß :-)

[Rudolph R. (rudolph)]

Der FT811 verarbeitet die Farbe schon, nur bei der Ausgabe werden die 
unteren zwei Bits nicht ausgegeben, dafür hat der schlicht die Pins 
nicht.

Nach Oben ist dann doch noch Luft, die BT817 sind ja gerade erst 
offiziell released. :-)

[roter_Milan (Gast)]

Moin zusammen,

erstmal Danke an rudolph für deine Library, die macht vieles einfacher!

Ich hab dein Bsp. aus github nachgebaut und dies hat auch funktioniert. 
Allerdings nicht immer nach einem Neustart. Dann fehlten Teile der 
statischen display list oder die Bilder wurden nicht richtig fertig 
geladen. Wenn ich aus deinem Bsp. "EVE_cmd_append_burst(MEM_DL_STATIC, 
num_dl_static)" auskommentiert hatte funktionierte aber zumindest der 
dynamische Teil immer nach einem Neustart.

Nach einigen Stunden habe ich dann herausgefunden, dass mein Timer (5ms) 
anscheinend die Übertragung der statischen display list unterbrochen 
haben muss.
In dem Timer werden "tft_touch()" (alle 5ms) und "tft_handling()" (alle 
25ms) aufgerufen.

Die Lösung des ganzen war dann die Timer erst nach dem tft_init() zu 
initialisieren. Seit dem funktioniert es wie es soll :)

Ich schreib das nur, falls jmd auch mal dieses Problem hat. So muss er 
nicht so viele Stunden investieren wie ich. Vllt. ist es ja auch normal 
die timer als letztes zu initialisieren...

P.S. Ich benutze momentan einen SAME54P20A mit dem EVE3-50G-BLM.

Gruß

[Rudolph R. (rudolph)]

Ich würde tft_touch() und tft_handling() nicht per Interrupt machen.
Selbst tft_touch() dauert doch dafür viel zu lange und das 
tft_handling() sowieso.

Klar, der "Scheduler" aus meinen Beispielen ist sehr stumpf mit der 
Hauptschleife die per Systick Timer alle 5ms durchlaufen wird.
Aber im Grunde genommen sieht das in einem größeren Projekt auch nicht 
anders aus, da ist dann nur weniger Code direkt in der main.c, etwa so:

while (1) 
{
 if(system_tick)
 {
  system_tick = 0;

  watchdog_task();
  debug_led_task();
  can_task();
  display_task();
  can_task();
 }
}

Nein, das habe ich so jetzt auch noch nirgendwo, außer die Anforderung 
den Code per Unit-Testing testen zu wollen, fällt mir dafür auch kein 
vernünftiger Grund ein.

Was da fehlt ist eigentlich nur den Controller am Ende schlafen zu 
schicken.
Nur ist das witzlos in Kombination mit dem Display.

Und natürlich findet die Initialisierung da drüber statt. :-)

[roter_Milan (Gast)]

Das ist mit dem "Scheduler" ist auch eine gute Idee, obwohl die beiden 
Funktionen "tft_touch()" und "tft_handling()" jetzt noch nicht so lange 
brauchen. Werde es bei Gelegenheit mal umbauen.

Das die Initialisierung darüber stattfindet war mir auch klar ;-) bloß 
habe ich halt in der Initialisierung zuerst die Timer initialisiert und 
gestartet und dann das Display initialisiert. Man sollte den Timer eben 
am Ende der Initialisierung starten :-)

[Rudolph (Gast)]

Das tft_touch() braucht auch auf dem SAME54 mehrere µs für single-touch, 
bei Multi-Touch entsprechend nach Anzahl der ausgewerteten Punkte 
länger.
Das erzeugt eben SPI Traffic.

Und für die Anzeige selber braucht man schon mal ein paar hundert Bytes 
bis mehrere KB.
Selbst wenn die Daten per DMA verschickt werden, den Puffer zu füllen 
kostet auch Zeit.
Das ist alles ein Witz im Vergleich zum Setzen einzelner Pixel, aber 
eben erheblich mehr Zeit als ich einen Controller im Interrupt 
verbringen lassen würde.

Interrupts nutze ich möglichst zurückhaltend um sie als Resource zur 
Verfügung zu haben wenn es wirklich mal darauf ankommt.

Und der Systick-Timer in den ARMs ist genau für sowas gedacht, als 
Zeitbasis für periodisch aufgerufene "Tasks".

[Simon (Gast)]

Have you used Bridgetek VM816C50A board? I don't see this board in your 
defines in EVE_config.h file.

[Rudolph (Gast)]

I have not, I tend to avoid resistive touch modules.
But I can look into adding a profile for the 5" display they used.
There is a good chance that the profile for EVE3-50 (EVE_EVE3_50) does 
work for the VM816C50A.

[Rudolph R. (rudolph)]

I just pushed a small update for EVE_config.h:
- moved the profile for the RiTFT50 over to the one for the RiTFT70
- added a profile for the VM816C50A-D from Bridgetek
- added a profile for PH800480T024-IFC03 and PH800480T013-IFC05 from 
PowerTip

[roter_Milan (Gast)]

Moin,

habe meinen Code mal nach deinem Vorschlag umgebaut und er läuft soweit 
auch.
Allerdings friert das Display ab und zu ein oder wird komplett schwarz.
Der uC funktioniert allerdings noch, ebenso werden über SPI noch Daten 
gesendet.
Danach kann es erst nach einem Reset wieder genutzt werden.
Ist das Problem irgendwie bekannt?

Danke und Gruß

[Rudolph (Gast)]

Ich sag mal so, normal ist das nicht, wenn ich mit dem SAME51 sowas 
schon bemerkt hätte, dann wäre das jetzt nicht mehr so. :-)
Also so grundsätzlich, mit nichts anderem auf dem Controller.

Läuft das hier denn durch?
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_SAME51_EVE3-43G

Also nach "leichter" Umkonfiguration auf die Takt-Quelle, die passende 
SERCOM, den anderen Pins und dem Display?

Kommt sich da was in die Quere?
Soll vielleicht was anderes den gleichen DMA Kanal benutzen?

Ein häufigeres Problem ist auch eine nicht ganz so stabile 
Stromversorgung für das Display.

[roter_Milan (Gast)]

Habe mir schon fast gedacht, dass du das Problem ansonsten schon gelöst 
hättest :D Ich wollte aber zumindest mal fragen :)

Hab das Problem auch schon gelöst.
Hatte mir die SPI Signale nochmal mit dem Oszi angeschaut und dann 
bemerkt, dass die Jumper Kabel, die ich benutze, nicht die Besten sind.

Nachdem ich zwei Kabel getauscht habe, läuft das Display jetzt auch ohne 
Aussetzer :)

[Rudolph R. (rudolph)]

Hör bloß auf mit Jumper-Kabeln, bei den letzten die ich gekauft habe 
konnte ich nur gerade so die Leitungen verwenden um da KFZ-Kontakte 
drauf zu crimpen.

[roter_Milan (Gast)]

Hatte dahingehend noch nie Probleme mit Jumper Kabeln gehabt.
Habe diese aber neugekauft und die Buchsen scheinen nicht so gut zu 
klemmen -.-

Naja wenigstens funktioniert es jetzt :)

[Daniel S. (snipod)]

Hi Rudolph,
ich habe deine Lib ja schon erfolgreich mit dem ESP32 und dem Arduino 
Framework ausprobiert und finde sie klasse :)

Da ich mit der Funktion des Arduino-Frameworks für den ESP aber nicht 
zufrieden bin, bin ich auf das IDF umgestiegen. Das IDF ist das vom 
Hersteller bereitgestellte Entwicklungsframework für die ESP Serie.

Ich Arbeite gerade daran, deine Software mit dem IDF zum Laufen zu 
bekommen, sehe aber ein paar Probleme, da SPI doch ziemlich anders 
aufgebaut ist, als bei Arduino.

Hast Du Interesse daran, deine Bibliothek um den Support zu erweitern, 
bzw. würdest Du mich dabei unterstützen?

Viele Grüße :)

[Rudolph R. (rudolph)]

Ich bin ja ohnehin gerade mit den ESP32 und auch ESP8266 am spielen, 
wenn jetzt auch nicht weil ich die selber für irgendwas einsetzen wollen 
würde.
Und eine Sache die ich noch auf dem Zettel habe ist der Arduino-ESP32 
Seite DMA zu verpassen über das IDF was da als driver_lib.a oder so noch 
mit verfügbar ist.

Das wäre zumindest vom IDF her die Richtung, zumindest hoffentlich, wenn 
denn das der gleiche Code ist.
Wie man mit dem ESP32 grundsätzlich klar kommt, so ohne Arduino auf 
RTOS, keine Idee.
Ich würde das auf jeden Fall mit PlatformIO anfangen wollen.

Meine Versuche mit dem ESP8266 haben auch erstmal dazu geführt das meine 
Adapter-Platine und wahrscheinlich auch der ESP8266 gestorben sind, 
Ersatz liegt hier jetzt, nur so richtig motiviert bin ich gerade nicht 
das wieder anzuschliessen. :-)

[Daniel S. (snipod)]

In das RTOS usw habe ich mich mittlerweile ganz gut eingearbeitet.
Ich werde versuchen deine Lib um die Funktionen zu erweitern damit sie 
auch mit der IDF funktioniert. Meine Erfolge - wenn es welche gibt :) - 
teile ich dann gerne

[Rudolph R. (rudolph)]

Das erfordert ja nur ein neues Segment in EVE_target.h und EVE_target.c.

Ich scheitere gerade spontan daran ein leeres ESP-IDF in PlatformIO 
anzulegen, das will nur mit Arduino, dabei sollte es auch anders gehen.

[Daniel S. (snipod)]

Rudolph R. schrieb:
> Das erfordert ja nur ein neues Segment in EVE_target.h und EVE_target.c.
>
> Ich scheitere gerade spontan daran ein leeres ESP-IDF in PlatformIO
> anzulegen, das will nur mit Arduino, dabei sollte es auch anders gehen.

Das ist mir schon klar, nur ich habe es gestern nicht hin bekommen :)
Ich werde mich heute noch mal intensiver damit auseinandersetzen.

In PlatformIO musst Du eigentlich nur Espressif IOT Development 
Framework als Framework auswählen beim erstellen des Projekts... Oder:
platform = espressif32
board = esp32dev (bzw. dein Board...)
framework = espidf

Grüße

[Rudolph (Gast)]

Naja, eigentlich und so, ich habe gestern über zwei Stunden gebraucht 
bis ich endlich mal espidf-blink compilieren konnte.
Seltsame Fehlermeldungen und keine Lösung dafür, so richtig sauber tickt 
PlatformIO oder auch Espressif-ESP32 noch nicht ganz.
Nach mehrmals Teile in PlatformIO entfernen und neu installieren wollte 
dann cmake nicht.
Am Ende habe ich \.platformio\packages\tool-cmake gelöscht, PlatformIO 
hat es neu installiert und ich konnte compilieren.
Heftig war dann allerdings was da alles für das einfache Blink-Beispiel 
compiliert wird, wie ewig das initial dauert und das da ein 145kB Binary 
bei raus kommt.

Danach hatte ich erstmal genug von dem Mist.

[Daniel S. (snipod)]

Ich habe die Kommunikation soweit am laufen, kämpfe jetzt bisschen mit 
dem Gerät...
Ich komme bei EVE_init() beim initialisieren des Touch Controllers 
niucht aus dem while(eve_busy()) nicht raus.

Aber hier wäre schon mal ein (von SPI Seite her) funktionierendes 
Projekt.

PS: Ich musste spi_write_eeprom in eve_spi_write_eeprom umbenennen, da 
es die Funktion im Framework schon gibt...

EDIT:
EVE_Init läuft durch, Backlight geht auch, nur sehen tu ich nix :(

[Rudolph R. (rudolph)]

Also ich kann schon mal compilieren so ohne Warnungen.
Und von der Struktur her sieht das erstmal so aus wie ich das auch 
gemacht hätte, so weitgehend.
Mal davon ab das ich inhaltlich mit dem ESP32 code noch nicht viel 
anfangen kann.

Nur bleibt das Bild bei mir noch komplett schwarz, nicht mal diese 
einfache Display-Liste wird angezeigt:

EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_dl(TAG(0));
EVE_cmd_dl(DL_COLOR_RGB | BLACK);
EVE_cmd_text(100,100,28,0,"Hello");
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);

Mal den Logic-Analyzer anwerfen, mit der Arduino Seite läuft das.

So ganz das gleiche wie auf der Arduino Seite macht die ESP-IDF Version 
aber noch nicht.

[Daniel S. (snipod)]

hmmm, das stimmt, das sieht etwas komisch aus...

Haben wir vielleicht ein Problem mit Little / Big Endian oder so?

Bin leider nicht wirklich der SPI Profi, geschweige denn EVE :P

Ich habe im Bridgetek Forum eine Lib gefunden für den ESP32, aber 
funktionieren tut die auch nicht :)
http://www.brtcommunity.com/index.php?topic=100.0

Das Initialisieren EVE_init() läuft bei mir aber durch - ich hab lauter 
Log einträger reingeballert, da ich keinen Logic analyzer besitze...
Nur wie du schon sagst, beim erstellen der DL gibt es dann wohl 
Probleme.

Vielleicht ist es dann tatsächlich dann Little / Big Endian Problem, 
weil beim Initialisieren ist glaube alles noch 8 bit groß, erst später 
kommen dann 16 und 32 bit commands und register

[Rudolph R. (rudolph)]

Es läuft jetzt bei mir.

Das Problem war die Byte-Order für die 32 Bit Transfers.
Irgendwo muss das doppelt gedreht sein.
Vielleicht ist aber auch auf der Arduino-Seite ein Byte-Dreher drin den 
ich durch das eigene Drehen kompensiert habe.

static inline void spi_transmit_32(uint32_t data)
{
//ESP is little endian
//uint32_t be_data = htobe32(data);
uint32_t be_data = data;

Und warum das auf dem SPI erstmal so komisch aussieht ist auch 
erklärbar.
Der ESP-IDF Code ist im Moment noch elendig langsam.
So richtig übel langsam.

Ich habe das in der Tabelle nebeneinander gestellt, der Arduino macht 
mehr Traffic, weil der Code da einfach schneller läuft, das heißt der 
BT815 den ich hier ansteuere ist in den Warteschleifen beim Init einfach 
noch nicht fertig und beim langsameren Code in der ESP-IDF Version 
schon.

Dabei ich auch schon die EVE_commands.c gegen die originale ersetzt, so 
ohne die "ESD_LOGE(..." Aufrufe.
Und mit den 40ms Delay am Anfang die Du durch 300ms ersetzt hast.
Das Delay vom ESP-IDF haut übrigens auch nicht hin, das ist zu lang.
Ist jetzt kein Problem, aber auch dadurch sind die Daten auf dem SPI 
beim Init auf den ersten Blick nicht gleich.

Nach den ganzen Erfahrungen, die Code-Qualität von Espressif überzeugt 
mich nicht.
Zwischen zwei Datenbytes auf dem SPI derart lange Pausen einzubauen ist 
schon ein Kunststück, vor allem bei 240MHz Core-Takt.

[Daniel S. (snipod)]

Ich hab das example jetzt auch am laufen... und er braucht zum builden 
der DL ganze 60ms, das ist natürlich nichts.

Ich habe versucht das ganze zu queuen, das wird aber net viel besser... 
Ich habe die delays aber gefixt, dazu muss man nur die tick rate vom 
Scheduler erhöhen, das sollte jetzt besser passen.

Ich habe versucht vom Software Treiber, auf den HAL Treiber umzustellen, 
jetzt zeigt er aber wieder nix an -.-'

Vielleicht kommst Du ja damit weiter :)

[Rudolph (Gast)]

Naja, inzwischen wundere ich mich nicht mehr über so Sprüche das 
Software-SPI mit dem ESP32 schneller ist als Hardware-SPI.
Das liegt im wesentlichen an der Software die Espressif liefert und der 
Dokumentation dazu.

Hier kann man den Weg für den Arduino Teil nachlesen:
https://github.com/RudolphRiedel/FT800-FT813/issues/14

Zwischen zwei Transfers über 6µs Pausen zu haben ist schon heftig, das 
sind bei 240MHz ja über 1400 Takt-Zyklen.

Um am Ende auf 140µs für die Demo zu kommen habe ich den DMA Support in 
meiner Library genutzt, nur bisher ohne DMA, da der ESP32 Arduino Core 
DMA nicht direkt unterstützt.

Ich bin sicher da geht noch was.

[Rudolph R. (rudolph)]

Der HAL Treiber ist doch der aus dem Arduino-ESP32?

Das ist jetzt nicht so die beste Idee, im Gegensatz zum ESP-IDF 
unterstützt der nämlich DMA gar nicht.

Ich habe gerade die Pin-Konfiguration an mein Board angepasst und das 
Display umgestellt, jetzt passiert auf dem SPI aber praktisch nichts 
mehr.
SCK macht irgendwas, das ist aber auch alles.

[Daniel S. (snipod)]

hmm...
also ich habe mir jetzt mal einen logic analyzer zugelegt und werde die 
Tage mal schauen wie ich es beschleunigt bekomme.

Bis dahin muss ich erst mal auf Arduino Basis mein Sample Display zum 
Laufen bekommen, da passt aber was noch nicht so 100%-ig.
Ich habe die Timings im Verdacht... Könnte Die sich mal jemand 
anschauen? Ich habe schon bisschen rumprobiert, aber so wirklich 
verstanden hab ich es nicht...

So gehe ich aktuell vor:

#define EVE_PCLK  (2L) //PCLK 36 MHz
#define EVE_PCLKPOL  (0L) // 0 = Output on Negative Edge, 1 = Output on Positive Edge
#define EVE_SWIZZLE  (0L) // dont switch output pins
#define EVE_CSPREAD  (0L) // 0 = change r/g/b before clock, 1 = change r/g/b with clock  

#define EVE_HSIZE  (800L)  /* Thd Length of visible part of line (in PCLKs) - display width */
#define EVE_VSIZE  (480L)  /* Tvd Number of visible lines (in lines) - display height */

#define EVE_VSYNC0  (4L)  /* Tvf Vertical Front Porch */
#define EVE_VSYNC1  (8L)  /* Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
#define EVE_VOFFSET  (20L)  /* Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
#define EVE_VCYCLE  (824)  /* Tv Total number of lines (visible and non-visible) (in lines) */
#define EVE_HSYNC0  (4L)   /* (40L)  // Thf Horizontal Front Porch */
#define EVE_HSYNC1  (8L)  /* Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
#define EVE_HOFFSET  (20L)  /* Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
#define EVE_HCYCLE   (504L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */

Ich versuche eine minimal DL darzustellen:

EVE_init();
EVE_memWrite8(REG_PWM_DUTY, 0x80);
EVE_init_flash();

EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_dl(TAG(0));
EVE_cmd_dl(DL_COLOR_RGB | BLACK);
EVE_cmd_text(100,100,28,0,"Hello");
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);

Der Bildschirm bleibt aber weitesgehend weiß :)

[Rudolph (Gast)]

Solche Timing Parameter sind genau der Grund warum ich nackte TFTs 
ziemlich unlustig finde. :-)

Die meisten 800x480 kommen allerdings mit den Parametern klar die ich in 
EVE_config.h unter "Resolution_800x480" abgelegt habe.
Das habe ich nicht so angelegt weil ich die Datei kleiner bekommen 
wollte, das hat sich aus den ganzen Daten für diverse Displays so 
ergeben.

Das BT815 5" von Riverdi zum Beispiel hatte mit den Daten einen Offset, 
obwohl das in deren Datenblatt so drin steht, grundsätzlich hat das aber 
was angezeigt und mit den Daten aus deren Demo-Software läuft es jetzt 
auch richtig.

Ich habe noch ein Display von Powertip herum liegen, 7" 800x480 FT813.
Das Datenblatt dazu ist praktisch nicht zu bekommen, nur auf Umwegen und 
veraltet, die Daten da drin sind ein Witz und auf Anfragen zu reagieren 
ist Powertip anscheinend zu lästig.

[Daniel S. (snipod)]

Ich bin in stetem Kontakt mit meinem Lieferanten, der ist auch relativ 
engagiert... leider hat der keine Ahnung vom EVE.

Ich hätte liebend gerne ein "fertiges" Modul genommen, leider habe ich 
immer noch nichts gefunden, was meinen Anforderungen entspricht :( Und 
der Wille zu Kundenspezifischen Lösungen scheint bei den üblichen 
verdächtigen nicht so wirklich gegeben zu sein...

Ich schau mal wie weit ich komme, ich werde berichten :)

Viele Grüße

[Rudolph R. (rudolph)]

Für die Timing-Parameter braucht der Display-Lieferant auch erstmal 
keine Ahnung von EVE zu haben, aber die Parameter da oben sind schon 
sehr dünn.
Wenn das stimmt müsste das Panel mit einem extrem weiten Bereich an 
Parametern klar kommen.

Was passiert denn mit den "Standard" Parametern?

Hast Du mal 
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO 
ausprobiert?

Trag als Display doch zum Beispiel mal EVE_NHD_50 ein.


Kundenspezisch geht schon, das ist nur eine Frage der Menge.

TFTs sind einfach keine Massenware, das Zeug das für wenig Geld 
verscherbelt wird sind so aufgekauften Restposten für die man erst recht 
keine Daten erwarten kann.

Wenn ich wirklich mit Mengen um mich werfen wollen würde, dann würde ich 
bei Riverdi anfragen.
Vielleicht auch bei Glyn.
Also zumindest wenn ich in Europa bleiben wollen würde.

[Rudolph R. (rudolph)]

Ach ja, der ESP8266 läuft jetzt auch, oder wieder.
Ich habe die Stelle gefunden an sich der ESP8266 immer wieder resettet 
hat, ich habe einen 32-bit Pointer auf den String für z.B. Buttons und 
Text erzeugt um gleich vier Bytes auf einmal zu kopieren.
Das gab sonst nirgendwo Probleme, auch nicht mit dem ESP32.
Nur kann der ESP8266 nicht per 32 Bit Pointer auf Daten zugreifen die 
nicht 32 Bit ausgerichtet sind.
ARMs können das wohl auch nicht, nur ist das vermutlich nicht 
aufgefallen weil der Compiler dafür gesorgt hat, dass die Strings auf 32 
Bit ausgerichtet sind.

Nun ja, um da nicht noch mal mit einem anderen Controller drüber zu 
stolpern habe ich gleich die ganze Funktion neu geschrieben.

[Daniel S. (snipod)]

Moin,
ich hab mein Problem gefunden. (und es macht für mich keinen Sinn...)

Folgendes: Beim Setup des ILI9806E habe ich ein Kommando hinzugefügt, 
welches das Interface auf 24 RGB festlegt (0x70), jetzt funktioniert es 
einwandfrei. Etwas Tweaking was die Timings angeht und schon hat das 
Display funktioniert.

Warum ich es nicht verstehe? 0x70 ist laut DB der verdammte Default Wert 
dieses Registers!

Jetzt kann ich mich darum kümmern, die Kommunikation mit dem EVE zu 
beschleunigen.

Falls jemand bei irgendeiner Web-Suche hierauf stößt: angehängt der Code 
für die Kommunikation zum ILI9806E über den SPI Treiber der ESP-IDF ;)

PS: mit den "standard parametern" läuft es sogar auch...

[Werner (Gast)]

Hallo zusammen,

kann mir jemand sagen woran es liegt, wenn man so "Störungen" wie im 
Bild auf dem Display bekommt.
Der Controler ist der FT811.

[Rudolph R. (rudolph)]

Daniel S. schrieb:
> Folgendes: Beim Setup des ILI9806E habe ich ein Kommando hinzugefügt,
> welches das Interface auf 24 RGB festlegt (0x70), jetzt funktioniert es
> einwandfrei.

Schön das es funktioniert, aber das ist ja eklig, die Notwendigkeit den 
eigentlichen Display-Chip zu konfigurieren hatte ich bisher nicht. :-)
Das der ILI9806E ein 9-Bit SPI Interface hat macht das auch nicht 
hübscher.

Das ESP32 Board habe ich immer noch auf dem Tisch liegen mit dem Display 
da dran, die letzten Tage konnte ich mich nur nicht dazu aufraffen mich 
da mal endlich richtig dran zu machen das schneller zu bekommen, auch 
auf der Arduino Seite.


Werner schrieb:
> kann mir jemand sagen woran es liegt, wenn man so "Störungen" wie im
> Bild auf dem Display bekommt.
> Der Controler ist der FT811.

Sowas in der Form habe ich leider auch noch nie beobachtet.
Ist das statisch, oder zappelt das?
Das sieht irgendwie aus wie ein Problem zwischen FT811 und Display.
Was passiert wenn Du den Wert für PCLK mal erhöhst, also den Takt 
verringerst?

Kannst Du das vielleicht frei schneiden und ein minimales Beispiel mit 
einer generischen Display-Liste erzeugen welche das Problem hat?

[Werner (Gast)]

Hallo Rudolph,
schon doof, daß das nur bei mir passiert.
Das ganze ist nicht statisch, es zappelt ein wenig.

Das mit dem freischneiden ist nicht ganz einfach, da es nur auftritt, 
wenn ich viel in die Liste schreibe.
Im Beispiel wird eine Liste mit bis zu 10 Einträgen angelegt. Diese wird 
dann entsprechend verschoben. Meist fängt es an zu zappeln, wenn mehr 
wie 6 Eintäge drinn sind.

Wenn ich den PCLK erhöhe flackert alles.

Ich versuch mal ein Beispiel freizuschneiden, das dauert allerdings ein 
wenig.

[Rudolph R. (rudolph)]

Wie voll ist die Display-Liste? Das sieht eigentlich noch total harmlos 
aus.

Und wie oft machst Du den Refresh?
Probiers mal ein wenig langsamer.

[Werner (Gast)]

Hallo Rudolph,
langsamer bringt leider keine Unterschied.
ich mache alle 20ms einen Refresh.

[Johannes (Gast)]

Hallo Rudolph!

Ich habe deine Library erfolgreich auf M328 und M644 genutzt. Jweils mit 
NHD43-Displays. Bisher mit einigen simplen Screens und Buttons. Also 
nichts extravagantes. Dennoch: Es klappt super und deine Bibliothek ist 
wikrlich hervorragend. Mein Kompliment!

Als nächstes gibt es ein Projekt mit einem XMEGA64, also mit durchaus 
etwas mehr Performance. Ich möchte eine SD-Karte als Speicher für Bilder 
verwenden um die Screens und die Menüpunkte etwas "schöner" zu 
gestalten. Ähnlich wie das Beispiel App-Mainmenu von FTDI.

Hast du bereits Dateien von SD-Karten eingebunden? Gibt es dazu irgendwo 
Beispielcode, von dem man vorhandene Elemente übernehmen könnte?

Gruß,
Johannes

[Rudolph R. (rudolph)]

Moin,

Johannes schrieb:
> Hast du bereits Dateien von SD-Karten eingebunden?

Nein, habe ich nicht, als ich noch mit AVR unterwegs war habe ich 
90CAN128 verwendet, dann ATSAMC21 mit 256k FLASH und aktuell habe ich 
ein Projekt laufen mit einem ATSAME51J19A der 512k FLASH hat.
Und dann hat das RiTFT50 das hier gerade vor mir liegt 16MB eigenen 
Speicher und kann ASTC komprimierte Bilder direkt daraus anzeigen.

Die XMEGA habe ich auch nie verwendet, zum einen gibt es die nicht mit 
CAN, zum anderen waren die Includes so anders das ich mich da ohne 
besonderen Grund nie einarbeiten mochte.
Auf der Arbeit habe ich noch ein Eval-Board von einem Seminar rum 
liegen.

Also ich würde durchaus von den XMEGA abraten und einen ATSAMC20 oder so 
empfehlen, also zumindest wenn mich jemand fragen sollte ob er von den 
AVR auf die XMEGA umsteigen soll.
Die Hürde ist in etwa die gleiche, nur sind die ATSAM weniger tot.


Da Speicher der limitierende Faktor ist und praktisch sämtliche Medien 
Block-orientiert arbeiten liest man Dateien in Häppchen ein, so 512 
Bytes oder so.

Für bereits konvertierte Daten habe ich die Funktion 
EVE_memWrite_sram_buffer() eingebaut.
sd_open_file()
wiederhole_bis_ende_der_datei
{
 sd_read_block()
 EVE_memWrite_sram_buffer(ziel+(anzahl*blocklänge), gelesene länge)
}

Die Funktionen EVE_cmd_inflate() und EVE_cmd_loadimage() gehen davon 
aus, dass sich die Daten im Speicher des Controllers befinden, zumindest 
für AVR Controller.
Das kommt von der Harvard-Architektur der AVR Controller und so steht in 
der EVE_target.h für AVR die Funktion fetch_flash_byte(const uint8_t 
*data) welche nichts weiter macht als return(pgm_read_byte_far(data)).
Für alle anderen Architekturen steht da einfach nur "return *data;" 
drin.

Also mit einem ARM könnte das so aussehen:
sd_open_file()
sd_read_block()
EVE_cmd_loadimage(ziel, optionen, sd_block, gelesene länge)
wiederhole_bis_ende_der_datei
{
 sd_read_block()
 EVE_memWrite_sram_buffer(REG_CMDB_WRITE, gelesene länge)
}

Das gleiche müsste auch mit EVE_cmd_inflate() funktionieren.

Das sollte funktionieren, weil sowohl CMD_LOADIMAGE als auch CMD_INFLATE 
zwar die Daten direkt nach dem Kommando bekommen, aber beide anhand der 
Daten feststellen ob diese schon vollständig sind.

Alternativ gibt es für die FT81x die Möglichkeit CMD_LOADIMAGE mit einem 
Puffer im RAM_G zu benutzen, der Puffer wird mit CMD_MEDIAFIFO 
eingerichtet.
Irgendwo da oben im Thread ist ein Beispiel zum Mediafifo.
Mit CMD_INFLATE funktioniert das aber nicht.

Aber aussehen würde das so:
EVE_cmd_mediafifo(mediafifo_ptr, size)
sd_open_file()
EVE_cmd_loadimage(ziel, EVE_OPT_MEDIAFIFO, 0, 0)
wiederhole_bis_ende_der_datei
{
 sd_read_block()
 EVE_memWrite_sram_buffer(mediafifo_ptr, gelesene länge)
}

So mehr oder weniger aus dem Kopf, ist ewig her das ich MEDIAFIFO 
benutzt habe, ich fürchte auch gerade das ist deutlich aufwendiger und 
da müssen dann auch noch zwei Zeiger in den MEDIAFIFO verwaltet werden.
Zu erwähnen ist noch das die Adresse und die Länge für den MEDIAFIFO 
4-Byte aligned sein müssen.
Ach ja, mit PNG Bildern gibt es auch noch was u beachten, zum einen ist 
die Dekodierung super langsam im Vergleich zu JPG, dann ist EVE etwas 
wählerisch was das Format angeht und wenn man PNG lädt kann man RAM_G ab 
Adresse 0xF5800 nicht benutzen weil der Speicher zum Entpacken des 
Bildes verwendet wird.

Mit den BT81x kommt noch CMD_INFLATE2 dazu, das kann den MEDIAFIFO 
benutzen oder alternativ auch Daten aus dem FLASH vom Display.

[Rudolph R. (rudolph)]

Zum Thema ESP32:
https://github.com/RudolphRiedel/FT800-FT813/issues/14

Letzter Beitrag da, ich gebe das erstmal auf, das führt irgendwie zu 
nichts.
Ja, man kann ESP-IDF Funktionen auch unter Arduino benutzen, leider wird 
das eher noch langsamer als mit dem esp32-hal-spi.c Treiber der Arduino 
Seite.

Aber mein letztes Problem war das ich DMA und nicht-DMA Transfers nicht 
mischen kann.

Ein paar Hundert Bytes per DMA zu verschicken ist super, etwas auf das 
ich nicht mehr verzichten möchte.
Ein paar Bytes per DMA zu verschicken ist albern, das Setup dauert 
länger als das eigentliche Senden.

[Johannes (Gast)]

Hallo Rudolph,

noch ist die Entscheidung über den MC nicht gefallen. ATSAMC21N wäre 
eine Option. Ich benötige eine ganze Menge Hardware-UART.

Ich denke, ich werde ein Probeboard mit dem Chip machen. Gibt es bei den 
SAMs etwas besonders zu beachten? Sind die internen Taktgeber 
zuverlässig oder lieber Quarz?

Schließt du den FT81X genauso an wie bei einem 8Bit-AVR?

Ist das CAN vollständig on board oder wird ein Treiber benötigt?

Gruß,
Johannes

[Rudolph R. (rudolph)]

Johannes schrieb:

>ATSAMC21N wäre eine Option. Ich benötige eine ganze Menge Hardware-UART.

Bisher habe ich "nur" die E, G und J verwendet, den J mit 64 Pins auch 
nur für die zwei CANs bzw. um eine Platine zu erstellen auf der sowohl 
ein SAME51J als auch ein SAMC21J bestückt werden können.

> Ich denke, ich werde ein Probeboard mit dem Chip machen. Gibt es bei den
> SAMs etwas besonders zu beachten? Sind die internen Taktgeber
> zuverlässig oder lieber Quarz?

Für CAN braucht man entweder einen sehr guten Resonator oder einen 
Quarz.
Ich verwende praktisch überall NX3225GB-16 (Digi-Key 644-1233-1-ND

Ein Kunde setzt in seinem Design für das wir Software liefern gerade 
einen Resonator ein, da bin ich gespannt wie das ausgeht.

> Schließt du den FT81X genauso an wie bei einem 8Bit-AVR?

Im Grunde genommen ja, mit QSPI kann ich an den EVE nichts anfangen.
Zum einen spiele ich keine Videos ab, zum anderen benutze ich DMA, bei 
meiner einfachen Demo braucht ein Display-Refresh mit dem E51 14µs.
Und ein Teil davon ist ein EVE_memRead16(REG_CMD_DL) für die 
Debug-Information das ohne DMA sechs Bytes über den SPI schiebt.

Das ist in der EVE_target.h zu sehen.
Wobei mein letzter Fehler auf einem Board war davon auszugehen das die 
SERCOMs von C21 und E51 gleich sind.
Blöderweise ist der E51 nicht ganz so flexibel, der kann SCK nur auf 
PAD1 legen, aber nicht auf PAD3.

Oh ja, zumindest bei den C21 sind die Ausgänge bei 3,3V zu schwach um 
ein Display mit mehr als nur ein paar MHz direkt treiben zu können, so 
über das Folien-Kabel mit den zwei Steckverbindungen.
Da verwende ich jetzt einen 74LVC2G17 für SCK und MOSI, sowie einen 
74VHC1GT125 für MISO.
Für direkt nur 3,3V auf 3,3V gehen sicher auch andere Teile, aber die 
Dinger habe ich eh da.

> Ist das CAN vollständig on board oder wird ein Treiber benötigt?

Für CAN wird praktisch immer ein Transceiver gebraucht, es gibt nur ganz 
wenig Controller die den eingebaut haben und mir fällt da gerade ein 
LPC11xx von NXP als Beispiel ein.

Hier, das war mein erstes C21 Board:
https://github.com/RudolphRiedel/SAMC21_one

Das Ding ist mit dem Transceiver und dem Spannungsregler Wakeup fähig.

An dem 7pol X5 habe ich so ein Board angeschlossen:
https://github.com/RudolphRiedel/EVE_display-adapter

Das L-D5019-01-02 hatte zusätzlich noch den gleichen Stecker.

Meine letzte Variante heißt L-D5019-06-02 und da sind neben dem Display 
Anschluss und ein wenig Logik noch zwei Stück TCAN1044V drauf für zwei 
Mal CAN-FD bis 8MBit/s, zwei Stück TLE7259-3GE für LIN, ein Schaltregler 
für die 3,3V und ein 5V LDO für den CAN.
Bestücken kann ich da einen ATSAMC21J oder einen ATSAME51J.

Eine von denen habe ich letzte Woche in ein 7" Display gesteckt mit 
einem E51 und einem CAN, vier Stück stecken mit C21 in 4.3" Displays und 
brauchen noch so ein paar Zeilen Code.

Was CAN angeht, das hier spielt soweit auch:
https://github.com/RudolphRiedel/USB_CAN-FD

Allerdings kämpft der Kollege noch damit das wir bei hoher Buslast 
Botschaften verlieren.
Nun ja, die Idee war ja auch nicht die Vector Tools zu ersetzen, sondern 
mehr so nach unten zu ergänzen.

[Daniel S. (snipod)]

Moin Moin,
also ich habe mich noch mal mit dem Thema ESP-IDF beschäftigt und eine 
Lösung für die Lücken in den Transaktionen gefunden.
Nutzt man "DMA" und sendet die ganze DL als ein Buffer bekommt man die 
Lücken raus und man landet bei 290 us für die Demo DL (bzw. 751 wenn man 
das EVE_busy()) mitzählt.

Wenn man das ganze jetzt weiter verbessen möchte, müsste man die ganzen 
einzelnen Commands umschreiben, dass nicht einzelne SPI Transaktionen 
erzeugt werden, sondern immer ein Buffer an Bytes gesendet wird. Dafür 
müsste ich aber den Kern der Bibliothek angreifen... Beispielsweise

void EVE_start_command(uint32_t command)
{
  uint32_t ftAddress;

  ftAddress = REG_CMDB_WRITE;
  EVE_cs_set();
  char spi_buf[7] = {
    (uint8_t)(ftAddress >> 16) | MEM_WRITE,
    (uint8_t)(ftAddress >> 8),
    (uint8_t)(ftAddress),
    (uint8_t)(command >> 24),
    (uint8_t)(command >> 16),
    (uint8_t)(command >> 8),
    (uint8_t)(command)};
  spi_transmit_bytes(spi_buf, 7);
}

PS: für "DMA" benötigt man natürlich noch die entsprechende Funktion:

void EVE_start_dma_transfer(void)
  {
    EVE_cs_set();

    static spi_transaction_t trans;
    trans.length = (4 * 8 * (EVE_dma_buffer_index)) - 8;   //we dont want the first byte of the EVE_start_cmd_burst
    trans.rxlength = 0;
    trans.flags = 0;

    trans.tx_buffer = ((char *)EVE_dma_buffer) + 1;      //we dont want the first byte of the EVE_start_cmd_burst
    spi_device_transmit(EVE_SPI_DEVICE_HANDLE, &trans); 
    EVE_cs_clear();
    EVE_dma_buffer_index = 0;
  }

[Rudolph R. (rudolph)]

Äh, schau doch mal wie ich das aktuell für die Arduino Seite umgesetzt 
habe, ich komme jetzt auf 100µs für die Demo ohne gleich alles über den 
Haufen zu werfen und ohne DMA.
Mit DMA sollte das deutlich unter 60µs fallen.
Das SPI.writeBytes() ist ja praktisch nichts anderes als 
spi_device_transmit(), das ist beides blockierend, nur ist die ESP-IDF 
Version langsamer als die Arduino variante.

Einzelne Kommandos auf DMA umzustellen macht überhaupt keinen Sinn, zum 
einen hat man dann wieder den Overhead der 3-Byte Adresse mit drin, zum 
anderen dauert das viel zu lange die Que für die paar Bytes anzuwerfen.
Mit dem ESP-IDF wird der DMA übrigens auch nicht direkt bedient, es wird 
vielmehr das RTOS freundlich darum gebeten irgendwann mal vielleicht den 
Request zu der passenden Que hinzufügen.

Gestern habe ich erst mal DMA für STM32duino eingebaut, auf dem 
"langsamen" Nucleo-64 mit STM32F446RE braucht der Display-Refresh jetzt 
12µs.
Auf dem Metro-M4 läuft DMA unter Arduino auch schon ein paar Tage.

Angehängt ist noch mal mein Test-Programm vom 23.12. das ich auf Github 
gepostet hatte.
Wenn das laufen würde, so mit den drei Blöcken in der loop() 
gleichzeitig aktiv, dann hätten wir DMA.

Also das hier:

#if 1
    spi_transaction_t trans;
    trans.length = 8;
    trans.rxlength = 0;
    trans.flags = SPI_TRANS_USE_TXDATA;

    trans.tx_data[0] = 0x55;
    EVE_cs_set();
    spi_device_transmit(EVE_spi_device_simple, &trans);
    EVE_cs_clear();
#endif

#if 1
    uint32_t data = __builtin_bswap32(0xdeadbeef);
    spi_transaction_t trans3;
    trans3.length = 32;
    trans3.rxlength = 0;
    trans3.flags = 0;
    trans3.tx_buffer = &data;
    EVE_cs_set();
    spi_device_transmit(EVE_spi_device_simple, &trans3);
    spi_device_transmit(EVE_spi_device_simple, &trans3);
//    spi_device_polling_transmit(EVE_spi_device_simple, &trans3);
//    spi_device_polling_transmit(EVE_spi_device_simple, &trans3);
    EVE_cs_clear();
#endif

#if 0
    uint32_t EVE_dma_buffer[1025];

    EVE_dma_buffer[1] = 0x12345678;
    EVE_dma_buffer[2] = 0x12345678;
    EVE_dma_buffer[3] = 0x12345678;
    EVE_dma_buffer[4] = 0x12345678;

    spi_transaction_t trans2;
    trans2.length = 43 * 4 * 8;
    trans2.rxlength = 0;
    trans2.flags = 0;
    trans2.addr = 0x00b02578;
    trans2.tx_buffer = (uint8_t *) &EVE_dma_buffer[1];
    EVE_cs_set();
    spi_device_queue_trans(EVE_spi_device, &trans2, portMAX_DELAY);
//    EVE_cs_clear();
#endif

Die ersten beiden Blöcke tun was sie sollen.
Der dritte Block funktioniert auch wenn der alleine benutzt wird.
Aber wenn ich den dritten Block zusammen mit einem der anderen beiden 
aktiviere crasht der ESP32 und resettet sich.
Ich habe keine Idee was da falsch läuft.

[Daniel S. (snipod)]

Hi,
also ich habs mir mal angeschaut, ich denke da kommt bisschen was 
zusammen.

Der Post Transaction Callback ist nicht richtig definiert und die 
structs solltest Du immer nullen bevor Du da was setzt...

Hat dann aber bei mir immer noch nicht so ganz funktioniert. Dann hab 
ich es eben "nativ" in die IDF gepackt, da gehts. Denke da gibts ein 
Problem mit dem Arduino Core und dem IDF SPI Treiber.

Ist aber nach wie vor eine riesen Zeitspanne zwischen CS setzen und 
start der Übertragung...

[Rudolph R. (rudolph)]

Top, mein Test-Programm läuft jetzt unter Arduino und alles was ich 
dafür geändert habe war ein paar Mal "= {0};" zu ergänzen.

Wofür haben wir eigentlich einen Compiler? :-)

Die Blöcke haben jeweils einen eigenen "spi_transaction_t" und diese 
hast Du nicht genullt. :-)

Die Post-Transaction Callback Funktion sollte so in Ordnung sein, der 
Parameter wird doch schliesslich nicht verwendet.

Nicht nur die Zeit von Chip-Select Down bis Anfang Transfer ist krank, 
die Zeiten zwischen zwei Bytes sind auch total übel.
Vor allem weil das mit Arduino Code "nur" 6µs dauert.

Den Unsinn bekommt man vermutlich nur in den Griff wenn man direkt auf 
die Register runter geht.
Aber naja, mal schauen wie das am Ende aussieht, der wichtigste Teil ist 
ja den Display-Refresh in den DMA zu verlegen, ob der Teil mit dem Touch 
nun fest 18µs oder 150µs dauert ist ja nich so relevant.
Aber wenn der Display-Refresh nur noch 80µs braucht und keine 1,2ms für 
2k, das merkt man schon eher. :-)

Dann muss ich da wohl noch mal ran. :-)

[Rudolph R. (rudolph)]

Okay, also der Display-Refresh Teil läuft jetzt schneller als ich 
erwartet habe. :-)

Aber der normale SPI Zugriff ist mit dem ESP-IDF echt übelst langsam.
Was zum Geier treiben die da eigentlich?

Da muss es doch irgendeinen Trick geben dem Treiber beizubringen nicht 
jedes Mal Pi auf 1000 Stellen zu berechnen.

Ich habe versucht Arduino SPI mit ESP-IDF SPI zu mischen,
dann kommt nur gar nichts mehr aus dem SPI raus.

Naja, die 251µs sind wie ich oben schon schrieb fest und ändern sich 
nicht mit einer längeren Display-Liste.
Außerdem entfallen rund 93µs auf das Lesen der Länge der letzten 
Display-Liste, das ist eine Debug-Information.

Man könnte noch auf die Idee kommen den SPI Takt zu erhöhen da ich jetzt 
für normale Kommandos nur 10MHz eingestellt habe, im Init darf es eben 
nicht schneller sein als 11MHz.
Nur habe ich gerade keine Idee wie man ein einmal eingestelltes 
spi-bus-device verändert, zum anderen bringt das ja nichts wenn auf ein 
8 Bit Read-Kommando mit 4+1+1 Byte Transfer von 93,2µs Dauer nur 5µs auf 
den eigentlichen Daten-Transfer entfallen...
Yeah, der Takt ist doppelt so hoch, es dauert nur noch 91µs.

[Rudolph R. (rudolph)]

Okay, jetzt kann ich so langsam mal einen Release vorbereiten.

Time2 ist jetzt auf 100µs runter, Pi wird zwischen zwei Transfers nur 
noch auf 200 Stellen berechnet...

Zuerst habe ich versucht mit
spi_device_acquire_bus(EVE_spi_device_simple, portMAX_DELAY);
in EVE_cs_set() und
spi_device_release_bus(EVE_spi_device_simple);
in EVE_cs_clear() dem SPI Treiber beizubringen das er nicht erst eine 
Partie Schach gegen den RTOS Task-Scheduler gewinnen muss damit er ein 
Byte auf den Bus werfen darf.
Nur blöderweise wurden die Abstände dann noch länger: 32µs.

Jetzt habe ich mal meine drei SPI Funktionen von
spi_device_transmit(EVE_spi_device_simple, &trans);
umgestellt auf
spi_device_polling_transmit(EVE_spi_device_simple, &trans);

Und sieh an, damit schrumft die Pause auf 8,2µs.
Wenn der Bus nicht belegt ist steigt das auf 12,2µs.

Also 100µs für den Touch ist jetzt nicht toll, aber sicher akzeptabel, 
vor allem als konstanter Wert.
Und davon entfallen jetzt 28,7µs auf das Lesen der Länge der letzten 
Display-Liste.

[Rudolph R. (rudolph)]

Ich habe gerade noch ein Update hochgeladen für ESP32 ESP-IDF, quasi der 
gleiche Code wie für die Arduino Seite mit ein paar Zeilen zusätzlich.

Komischerweise ist das mit 40ms/139ms etwas langsamer als für den 
Arduino.

Ein Beispiel-Projekt für PlatformIO schiebe ich nachher noch ins 
Repository.

[Rudolph R. (rudolph)]

Die Beispiele sind aktualisiert und das native ESP32 Beispiel ist jetzt 
auch da.

[Karol (Gast)]

Hi there, could you help me please? I have your very old library (for 
FT800). I'm using it for FT813 with no problem. Now I'm trying lunch it 
with BT815 but isn't working. So, I downloaded lastest version (added to 
my project) but still dont work. Only calibrations work (but with 
differents background collor than wrote in software).
TFT is from Riverdi, RVT70UQBNWC00: 
https://riverdi.com/product/ritft70capux/

Thanks in advance, regards,
Karol

[Rudolph (Gast)]

I am currently using the 5" BT815 from Riverdi as this is the closest 
match to the Riverdi IoT display I could find.
And the RiTFT-50 should be pretty much the same as the RiTFT-70, except 
for the size obviously.

So what are you using it with?
How exactly do you connect to the display, have you checked that the 
supply is stable and capable of delivering enough current and what 
controller from which pins?

[Robert S. (bimbo385)]

Hallo an Alle,

ich hoffe ich bin hier an der richtigen Stelle um ein paar Fragen zum 
Einstieg loswerden zu können.

Ich bin jetzt nicht der professionelle Softwareentwickler (sondern 
Hardware), habe aber einige Kenntnisse in C und bezüglich der Atmel 
Atmega und Xmega MCUs.

Ich stehe vor der Aufgabe ein HMI mit einem FT813 Display: 
https://4dsystems.com.au/gen4-ft813-50ctp-clb
und einem Atmel/Microchip ATxmega128A1U als Hostprozessor zu bauen.

Es geht hier nicht um grafikintensive Animationen oder ähnlich, viel 
mehr sollen Messwerte und ein paar Graphen angezeigt werden, ein Menü 
für ein paar Einstellungen wird wohl auch benötigt und Bedienung per 
touch ist halt gewünscht.

Ich bin jetzt etwas überwältig von den ganzen Tools auf der FTDI 
Webseite und dann gibt es ja noch solche Opensource-Libs wie diese hier 
und diverse (nicht besonders gute) first-step Geschichten in denen nicht 
erklärt wird wie was funktioniert.

Habt ihr ein paar Tipps welchen Weg man jetzt am Besten geht?

Kann ich in meinem Fall mit dem EVE Screen Designer (ESD) 4.8 überhaupt 
etwas anfangen? Habe bisher nur ein bisschen damit herumgespielt und mir 
ist nicht klar wie ich aus dem Tool jetzt ANSI-C herausbekomme um den 
Code auf meinen Xmega zu bekommen. Außerdem muss da ja irgendwie eine 
API dran um zum Einen den hardware SPI anzusteuern und zum Anderem um 
Events und Werte an das Display zu senden (aus der eigentlichen 
Anwendung heraus).

Auch habe ich noch nicht ganz verstanden, was jetzt eigentlich der FT813 
tut und was meine MCU tun muss. Also man schickt an den FT813 Kommandos 
wie z.B. zeichne eine Linie und male einen Text/Button. Aber was ist mit 
den analogen Anzeigen (Gauge) aus dem ESD? Da werden laut dem Fenster 
unten links ganz viele Kommandos mit einzelnen Linien draus... Also 
scheint der FT813 solche komplexeren Objekte nicht zu kennen und 
selbständig zu rendern. Daher kommt man nur mit den grundlegen Kommandos 
wohl nicht aus, wenn man eine GUI bauen will, sondern benötigt etwas wie 
ESD.

Muss ich den FT813 eigentlich jemals irgendwie programmieren oder 
updaten, Nein, oder? Das Teil hat ja laut Datenblatt keinen Flash oder 
EEPROM, nur RAM und ROM.

Ich bin definitiv nicht zu faul die Doku zu lesen und mich 
reinzuarbeiten, auch helfe ich gerne bei der Entwicklung dieser Lib in 
Richtung Xmega, wenn das den "der Weg" ist ;-) Nur weiß ich ATM garnicht 
wo ich anfangen soll.

Gruß,
Robert

[Rudolph R. (rudolph)]

Tach,

> ich hoffe ich bin hier an der richtigen Stelle um ein paar Fragen zum
> Einstieg loswerden zu können.

Jain. :-)
Das ist ja nur ein Thread hier, da geht schon mal was unter, wenn auch 
nicht so richtig viel los ist.
Manche Dinge kann oder auch mag ich nicht so richtig tief beantworten, 
zum Beispiel zum ESD weil ich zum einen nicht damit arbeite, zum anderen 
exportiert das Teil für eine Library mit der ich praktisch nichts 
anfangen kann.

> Ich bin jetzt nicht der professionelle Softwareentwickler (sondern
> Hardware), habe aber einige Kenntnisse in C und bezüglich der Atmel
> Atmega und Xmega MCUs.

XMega habe ich übersprungen, ich habe irgendwo noch ein Eval Board mit 
einem XMEga128A1 oder so herum liegen, so >10 Jahre alt.

> Ich stehe vor der Aufgabe ein HMI mit einem FT813 Display:
> https://4dsystems.com.au/gen4-ft813-50ctp-clb
> und einem Atmel/Microchip ATxmega128A1U als Hostprozessor zu bauen.

Okay, so eines habe ich noch nicht in die Finger bekommen und könnte 
auch spontan nichts damit anfangen, weil der 30pol FFC da drauf zu 
nichts anderem kompatibel ist.
Aber, ich habe Support für die Displays in Form eines Parametersatzes in 
meine Library eingebaut:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_config.h

EVE_GEN4_FT813_50

> Es geht hier nicht um grafikintensive Animationen oder ähnlich, viel
> mehr sollen Messwerte und ein paar Graphen angezeigt werden, ein Menü
> für ein paar Einstellungen wird wohl auch benötigt und Bedienung per
> touch ist halt gewünscht.

Dafür sind die Displays bestens geeignet.

> Ich bin jetzt etwas überwältig von den ganzen Tools auf der FTDI
> Webseite und dann gibt es ja noch solche Opensource-Libs wie diese hier
> und diverse (nicht besonders gute) first-step Geschichten in denen nicht
> erklärt wird wie was funktioniert.

Ja, das ganze gibt es jetzt auch schon eine Weile.

> Habt ihr ein paar Tipps welchen Weg man jetzt am Besten geht?

Fang mit der Hardware an, mach das Datenblatt auf.
Das gen4-ft813-50ctp-clb möchte mit 5V versorgt werden und
hat 3,3V Pegel auf der SPI Schnittstelle.
Die typische Stromaufnahme ist mit 525mA angegeben, das finde ich jetzt 
zwar übertrieben, aber die 5V Quelle sollte schon so 600mA liefern 
können.

4D Systems hat ein Breakout Board.
Neben der Versorgung benötigt man mindestens MISO, MOSI, SCK, CS und PD.

Um das mal laufen zu lassen kannst Du das über das Breakout Board zum 
Beispiel an einen 3,3V Arduino UNO Clone klemmen, sowas wie ein 
Seeduino, und meine Demo-Software benutzen:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO
8 = PD
9 = CS
11 = MOSI
12 = MISO
13 = SCK

Das einzige was dazu verändert werden müsste ist das in der EVE_config.h 
eingestellte Display.


> Kann ich in meinem Fall mit dem EVE Screen Designer (ESD) 4.8 überhaupt
> etwas anfangen?

Bestimmt, irgendwie, es gibt Leute die das benutzen, mir ist das
allerdings zu sperrig.
Gezielte Fragen dazu wären hier angebracht: http://www.brtcommunity.com/

> Habe bisher nur ein bisschen damit herumgespielt und mir
> ist nicht klar wie ich aus dem Tool jetzt ANSI-C herausbekomme um den
> Code auf meinen Xmega zu bekommen.

Ich habe ESD gerade aufgemacht und mir ist das ehrlich gesagt auch nicht 
klar. Früher ging das mal leichter da Code raus zu bekommen, auch mit 
dem EVE Screen Editor.
Den Code der da raus kam wollte ich nur nicht benutzen.

> Außerdem muss da ja irgendwie eine
> API dran um zum Einen den hardware SPI anzusteuern und zum Anderem um
> Events und Werte an das Display zu senden (aus der eigentlichen
> Anwendung heraus).

Als zumindest habe ich in meiner Library sicher mehr Targets für 
verschiedene Controller als im ESD zu finden sind, nur leider bisher 
auch keinen Support für die XMEga.

> Auch habe ich noch nicht ganz verstanden, was jetzt eigentlich der FT813
> tut und was meine MCU tun muss. Also man schickt an den FT813 Kommandos
> wie z.B. zeichne eine Linie und male einen Text/Button. Aber was ist mit
> den analogen Anzeigen (Gauge) aus dem ESD? Da werden laut dem Fenster
> unten links ganz viele Kommandos mit einzelnen Linien draus... Also
> scheint der FT813 solche komplexeren Objekte nicht zu kennen und
> selbständig zu rendern. Daher kommt man nur mit den grundlegen Kommandos
> wohl nicht aus, wenn man eine GUI bauen will, sondern benötigt etwas wie
> ESD.

Ganz so schlimm ist es nicht, es gibt in den FT8xx / BT8xx zwei Ebenen, 
das sind sind die "Graphics primitive", da fallen Punkte, Linien, 
Linien-Züge, Rechtecke und Bilder drunter.
Diese werden von der eigentlichen Graphics-Engine über die Display-Liste 
verarbeitet.
Dann gibt es noch den Kommando Co-Prozessor welchen man über den 
CMD-FIFO mit Befehlen füttert.
Der Co-Prozessor kümmert sich um die eingebauten Widgets, also Buttons, 
Gauges, Slider, Texte und einiges mehr.
Wenn man dem Co-Prozesser jetzt etwa ein CMD_BUTTON schickt dann zerlegt 
der das in Anweisungen für die Graphics-Engine und schreibt das in die 
Display-Liste.

Besonder gut sehen kann man das im EVE Screen Editor.

CMD_BUTTON(171, 183, 120, 36, 27, 0, "Button")

  Raw  Text
1  0x22000000  SAVE_CONTEXT()
2  0x27000002  VERTEX_FORMAT(2)
3  0x0e00003c  LINE_WIDTH(60)
4  0x1f000009  BEGIN(RECTS)
5  0x04003870  COLOR_RGB(0, 56, 112)
6  0x415d82eb  VERTEX2F(699, 747)
7  0x423e835d  VERTEX2F(1149, 861)
8  0x1f000001  BEGIN(BITMAPS)
9  0x23000000  RESTORE_CONTEXT()
10  0x22000000  SAVE_CONTEXT()
11  0x27000002  VERTEX_FORMAT(2)
12  0x0500001b  BITMAP_HANDLE(27)
13  0x99cbfdc2  VERTEX2II(206, 191, 27, 'B')
14  0x9b0bfdf5  VERTEX2II(216, 191, 27, 'u')
15  0x9c2bfdf4  VERTEX2II(225, 191, 27, 't')
16  0x9d0bfdf4  VERTEX2II(232, 191, 27, 't')
17  0x9debfdef  VERTEX2II(239, 191, 27, 'o')
18  0x9f2bfdee  VERTEX2II(249, 191, 27, 'n')
19  0x23000000  RESTORE_CONTEXT()

Und das ist jetzt nur der "flache" Button, mit 3D Effekt ist das mehr 
als doppelt so viel.

Mein Library geht exklusiv über den Co-Processor, das reduziert die 
notwendigen Daten über den SPI.

Sowas hier:
3  0x0e00003c  LINE_WIDTH(60)
4  0x1f000009  BEGIN(RECTS)
5  0x04003870  COLOR_RGB(0, 56, 112)
6  0x415d82eb  VERTEX2F(699, 747)
7  0x423e835d  VERTEX2F(1149, 861)

Malt zum Beispiel einfach nur ein Rechteck mit gerundeten Ecken,
das kann man auch an den Co-Prozessor schicken, der reicht das dann an 
die Display-Liste durch.

Jetzt füttert man den FT813 mit Kommandos, der packt die in eine 
Anweisungsliste und diese Liste wird dann immer wieder abgearbeitet.

In meiner Demo und auch sonst in Projekten generiere ich diese Liste 
einfach 50 Mal pro Sekunde neu.
Ändern sich irgendwelche Messwerte oder es muss zum Beispiel ein Button 
von nicht-gedrückt dargestellt auf gedrückt dargestellt verändert 
werden,
so erlaubt das kurze Intervall eine Aktualisierung ohne bemerkbare 
Verzögerung.
Und wie man in meiner einfachen Demo sieht erlaubt das nebenbei flüssige 
Animationen.
Diese Display-Liste ist doppelt gepuffert.
Wenn man dem Kommando Co-Prozessor mitteilt eine neue Liste anzulegen, 
dann passiert das in der aktuell nicht aktiven Liste.
Gibt man die Liste zur Anzeige frei dann wird das mit dem 
Bildschirmwechsel synchronisiert und der Speicher der alten Liste kann 
beschrieben werden.

> Muss ich den FT813 eigentlich jemals irgendwie programmieren oder
> updaten, Nein, oder? Das Teil hat ja laut Datenblatt keinen Flash oder
> EEPROM, nur RAM und ROM.

Die sind nicht programmierbar, richtig.
Teilweise muss man die patchen, jedesmal beim Start, um nicht direkt 
unterstützte Touch-Controller zu benutzen, das trift auf die 
gen4-ft813-50ctp-clb wohl aber nicht zu.

> Ich bin definitiv nicht zu faul die Doku zu lesen und mich
> reinzuarbeiten, auch helfe ich gerne bei der Entwicklung dieser Lib in
> Richtung Xmega, wenn das den "der Weg" ist ;-) Nur weiß ich ATM garnicht
> wo ich anfangen soll.

Och, ist nicht so als ob ich die ersten Tage nicht kräftig geflucht 
hätte, vor allem hatte ich auch noch keine Software die gelaufen wäre. 
:-)

Ein Logic-Analyzer ist übrigens hilfreich. :-)

Wenn Du mal schauen magst, ich habe das komplett aufgetrennt, in der 
EVE_target.h sind Basis-Funktionen als Inline-Funktionen angelegt.
Und die EVE_target.c enthält dann Funktionen die komplexer sind, für DMA 
zum Beispiel.

Um jetzt mal ein Target raus zu greifen, das für Arduino AVR ist schön 
kompakt:

#if  defined (__AVR__)
#include <avr/pgmspace.h>

#define EVE_CS     9
#define EVE_PDN    8

#define DELAY_MS(ms) delay(ms)

static inline void EVE_cs_set(void)
{
 digitalWrite(EVE_CS, LOW); /* make EVE listen */
}

static inline void EVE_cs_clear(void)
{
 digitalWrite(EVE_CS, HIGH); /* tell EVE to stop listen */
}

static inline void EVE_pdn_set(void)
{
 digitalWrite(EVE_PDN, LOW); /* go into power-down */
}

static inline void EVE_pdn_clear(void)
{
 digitalWrite(EVE_PDN, HIGH); /* power up */
}

static inline void spi_transmit(uint8_t data)
{
 SPDR = data;
 asm volatile("nop");
 while (!(SPSR & (1<<SPIF)));
}

static inline void spi_transmit_32(uint32_t data)
{
 spi_transmit((uint8_t)(data));
 spi_transmit((uint8_t)(data >> 8));
 spi_transmit((uint8_t)(data >> 16));
 spi_transmit((uint8_t)(data >> 24));
}

static inline void spi_transmit_burst(uint32_t data)
{
 spi_transmit_32(data);
}

static inline uint8_t spi_receive(uint8_t data)
{
 return SPI.transfer(data);
}

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
}

Das ist so alles an Funktionen die spontan für ein Target benötigt 
werden, so ohne DMA.
Weitgehend Einzeiler.
In dem Beispiel habe ich jetzt spi_transmit() mit ein paar mehr Zeilen 
direkt auf Register-Ebene ausgeführt.
Das ist messbar schneller, da zum einen der Funktions Aufruf gespart 
wird, das SPI.transfer() zum anderen aber auch noch mehr macht als 
wirklich benötigt wird, in dem Fall offensichtlich das Lesen der 
angekommenen Daten.

Die XMega unterstützen meine ich DMA,das wäre nett das zu benutzen, aber 
die ersten Schritte gehen sicher auch ohne.

[Robert S. (bimbo385)]

Moin Rudolph,

erstmal vielen vielen Dank für deine ausführliche Antwort. Ich werde 
mich morgen mal in Ruhe mit deiner Lib und den Bespielen befassen.

Hardware tut schon, ich hab das Keyboard Example von FTDI/4D am laufen 
mit einem Arduino Pro Micro auf 3,3 V, der FFC Breakout-Adapter war beim 
Display dabei. Das war kein Problem. Logicanalyzer hab ich (Saleae Logic 
8) und 4-Ch DSO mit SPI-Dekoder ebenso, kenne mich auch mit SPI aus. 
Also das auf unterster Ebene zu debuggen is prinzipiell kein Problem.

Meine Baustelle ist eher wie bekomme ich da effizent eine GUI zustande 
ohne jetzt das Rad (oder vielmehr den Bargraphen und die Buchstaben) neu 
zu erfinden.
Was ich jetzt noch nicht verstanden habe ist, wer bzw. wo ist dieser 
Coprozessor von dem du sprichst? Im FT813? Das würde heißen der FT813 
weiß doch was ein Button ist und ich kann dem sagen mach Button an 
Stelle XY in Größe mit Text usw? Also ohne auf die einzelen 
Grafikbefehle zurückzugreifen?

Datenblatt lesen werde ich wohl morgen mal in aller Ruhe angehen, also 
insbesondere die Abschnitte zu den Befehlen.

Schönen Abend!
Robert

[Rudolph R. (rudolph)]

Robert S. schrieb:
> Was ich jetzt noch nicht verstanden habe ist, wer bzw. wo ist dieser
> Coprozessor von dem du sprichst? Im FT813? Das würde heißen der FT813
> weiß doch was ein Button ist und ich kann dem sagen mach Button an
> Stelle XY in Größe mit Text usw? Also ohne auf die einzelen
> Grafikbefehle zurückzugreifen?

Ja genau, der Cmd-Coprozessor ist Teil von dem FT813.
Mit dem werden zum Beispiel auch JPG Bilder dekodiert.

Das sieht in meiner Library zum Beispiel so aus:
EVE_cmd_button_burst(20,20,80,30, 28, toggle_state,"Touch!");

Das ist, X, Y, Breite, Höhe, Font-Nummer, Optionen und Beschriftung.
Zusammen ergibt das 6 32 Bit Werte die über den SPI übertragen werden.


Hmm, ich habe gerade mal im Netz gefischt, kann es sein das ein SPI 
Transfer per DMA mit dem XMEGA verhältnismäßig eklig ist?
Ich lese das was davon das es mit der SPI Unit nur im Slave-Modus DMA 
gibt?
Oder man benutzt den UART im SPI Modus?

Also reines Senden wäre von Vorteil, so bis 4k.

[Robert S. (bimbo385)]

Hi,

so langsam wird mir klar wie das zusammenspielt. Bin durch Datasheet und 
Programmers Guide durch und für mich wird es wohl darauf hinauslaufen 
ausschließlich Kommandos für den Coprozessor abzusetzen und von der 
Displaylist selbst die Finger zu lassen. Sollte ich doch mal eine Linie 
oder so brauchen geht das ja auch bequem über den Coprozessor.

Da passt deine Lib ja 100tig zu, von daher werde ich jetzt mal versuchen 
ein Testprojekt auf meinen alten A1Xplained (mit dem 128A1) aufzusetzen 
und erstmal SPI ohne DMA zu implementieren.

Ich habe beim Xmega schon mit dem Eventsystem und DMA gearbeitet, 
allerdings gings da um Timer, ADC und Komparator um Samples von einer 
Wechselspannung zu erzeugen.
Laut Datenblatt gibt es keine DMA-Unterstützung für den SPI-Master, 
schade eigentlich. USART im Master SPI-Mode mit DMA soll zumindest laut 
Datenblatt möglich sein. Das wird dann aber frühstens Schritt 2.

Ich hab gelesen, dass man die ersten Kommandos nur mit max 11 MHz 
absetzen darf und erst danach mit max. 30 MHz loslegen soll. Hat deine 
Lib da schon eine "Stelle" für die Umschaltung der Geschwindigkeit, oder 
läuft die generell mit <= 11 MHz? Der Xmega könnte theoretisch bis 16 
MHz (Clkper = 32 MHz und double speed mode) am normalen SPI Master.

Gruß!

[Rudolph (Gast)]

SPI setup rechne ich eigentlich zur Anwendung, daher habe ich für die 
meisten Targets keine EVE_init_spi() Funktion implementiert und die wird 
auch nicht vorausgesetzt.

Also die Umschaltung von wie-schnell-auch-immer-aber-unter-11MHz vor dem 
Init auf so-schnell-die-hw es erlaubt macht mein Code nicht.

Ich habe auch gerade mal mein "Xplain" ausgegraben, Hust, XMega128A1, 
2008 steht drauf.

[Robert S. (bimbo385)]

Das ging ja einfacher als gedacht.

Vielen Dank schon mal!

Ich werde dann mal deine Lib forken und dir die Tage ein Pullrequest für 
Xmega und und das 4D Display zukommen lassen.

Ist jetzt noch ganz easy busy wait byte transfer per SPI mit 8 MHz.

Aber ich werde mich wohl noch an USART MSPI mit DMA machen und evtl. 
auch die Geschwindigkeit auf max. hochdrehen.

Ich hab festgestellt, dass mein Display jetzt summt. Wo stellst du die 
Frequenz fürs Backlight ein? Scheint daher zu kommen und ist bei dem 
FTDI Beispiel nicht aufgefallen.

Gruß,
Robert

[Rudolph (Gast)]

Na, das ging fix. :-)

Die PWM für die Beleuchtung wäre REG_PWM_HZ, die fasse ich nicht an und 
die steht daher auf dem Default-Wert von 250Hz.

Analog zu dem
EVE_memWrite8(REG_PWM_DUTY, 0x30);
in der TFT_init() in tft.c wäre das:
EVE_memWrite16(REG_PWM_HZ, 1234);

Da solltest Du aber auf jeden Fall vorher einen Blick ins Datenblatt 
werfen was das Display überhaupt mit macht.

[Robert S. (bimbo385)]

Moin,

Pullrequest ist raus, Zeitmessung für den Xmega ist noch nicht 
implementiert im Example, dass kann ich noch machen, da wird erstmal nur 
dumm ne Zahl gezählt...

Frequenz setzen geht, Danke für das Beispiel.
Allerdings schweigt sich 4D im Datenblatt über die gewünschte Frequenz 
aus. Im Schaltplan von 4D geht das PWM-Signal an den EN-Eingang eines 
TCS5526 (stromgeregelter Step-Up-Wandler für die LEDs im Backlight) für 
den es kein englisches Datenblatt zu geben scheint (China).

Funktionieren tut anscheinend alles von 250 Hz bis 10 kHz, Tonhöhe 
ändert sich mit der eingestellten Frequenz. Wenn man das Tastverhältnis 
auf 100% stellt ist das Geräusch weg (war auch beim FTDI Example so). 
Ursache ist klar, Lösung ist ne gute Frage...
Ob der Regler dafür gemacht ist um mit dem EN-Signal die LEDs zu dimmen 
wage ich zu bezweifeln. Besser wäre es den Sollwert für den Strom zu 
regeln, das geht aber mit diesem Regler nicht, da der Sollstrom über den 
Wert des Shuntwiderstandes festgelegt wird.

Erstmal schauen, ob man das überhaupt aus dem Gehäuse raushört und ggf. 
stelle ich einfach das Backlight auf 100%.

USART im MSPI Modus kann ich mit der bisherigen Hardware machen, Pins 
gehen bis zum Frontpanelanschluss. Von daher werde ich da weiter machen, 
evtl. am Wochenende.

Gruß,
Robert

[Rudolph R. (rudolph)]

Danke, auch für das Beispiel, ich habe das eben überflogen und Approved. 
:-)

Tja, und zu dem Backlight-Regler, es gibt ja noch ein paar mehr schöne 
Module in der Art. :-)
Zumal der FT813 jetzt auch nicht mehr ganz der aktuelle Stand ist.

[Ioan Mihai Cozac (Gast)]

Die Inverterspule einfach mit Kleber dichtmachen, oder gegen eine Chip 
Spule austauschen.

[Rudolph R. (rudolph)]

Verkleben ist schon mal nicht, da sitzt den Bildern und dem Datenblatt 
nach eine VLCF5020T-100M1R1-1 drauf, das ist eine geschirmte 10µH für 
1,1A mit 5mm x 5mm.

Und ob man die gegen was anderes tauschen kann ist nicht so leicht zu 
sagen, so ohne Datenblatt für den TC5526.

Wobei man das ja auch nicht unbedingt machen will, einmal vielleicht, 
aber nicht wenn man ein paar mehr Displays verbauen will.

Mit den anderen Displays hatte ich sowas noch nicht.
Höchstens Störungen mit meiner billigst Variante eines "Audio" 
"Verstärkers" auf meinem Display-Adapter.

[Karol B. (karol_b135)]

After half a day fighting with new software (new library for eve3) I 
found bug in my software :)
I send in my old sw command cmd_button with options=OPT_CENTER. Now I 
know, that is incorecte (this opt is for CMD_KEYS,CMD_TEXT, CMD_NUMBER 
not for button).

It's interesting that it's working for FT813 but not for BT815 (Black 
screen, nothing on it).

PS. As far i remember (from the begining of EVE, FT800) full screen 
gradinet looks not well. Is there any posibility to make it better?

[Karol B. (karol_b135)]

Gradient test software (7" 800*480 but its not matter):

enum {TAG_EXIT = 100,TAG_X0_PLUS=10,
TAG_X0_MINUS,TAG_Y0_PLUS,TAG_Y0_MINUS,TAG_X1_PLUS,TAG_X1_MINUS,TAG_Y1_PLUS,TAG_Y1_MINUS,};
void test_screen(void)
{
  uint8_t CurrTag=0,Pendown=0,PrevTag = 0;
  int16_t x0=0, y0=0, x1=0, y1=800;
  uint16_t btn_x, btn_x_next, btn_x_space, btn_w, how_many_buttons=4;
  char tmp_str[100];
  btn_w = 120;
  btn_x_space =20;
  btn_x_next = btn_w + btn_x_space;
  btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2;
  //
  while(PrevTag!=TAG_EXIT)
  {
    if(!timDisp)
    {
      timDisp = 10; // 10* 100times/second
      page_start();
      EVE_cmd_gradient(x0,y0,ORANGE,x1,y1,0x505050);
      
      EVE_cmd_dl(DL_COLOR_RGB | WHITE);  // text
      for(uint16_t y=0; y<=480; y+=10)  EVE_cmd_line(780,y,800,y,1);

      EVE_cmd_dl(DL_COLOR_RGB | WHITE);  // text color    
      EVE_cmd_text(400,40,31,OPT_CENTER,"Gradient test 1.0");
      EVE_cmd_line(220,70,580,70,3);
      // display texts+values:
      btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2 + btn_w/2;
      strcpy(tmp_str,"x0=");strcat(tmp_str,num2string(x0,NONE));
      EVE_cmd_text(btn_x, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
      strcpy(tmp_str,"x1=");strcat(tmp_str,num2string(x1,NONE));
      EVE_cmd_text(btn_x+=btn_x_next, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
      strcpy(tmp_str,"y0=");strcat(tmp_str,num2string(y0,NONE));
      EVE_cmd_text(btn_x+=btn_x_next, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
      strcpy(tmp_str,"y1=");strcat(tmp_str,num2string(y1,NONE));
      EVE_cmd_text(btn_x+=btn_x_next, EVE_VSIZE/2-90,29,OPT_CENTER,tmp_str);
      // buttons "plus":
      btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2;
      EVE_cmd_gradcolor(WHITE);      // buttons color
      EVE_cmd_dl(DL_COLOR_RGB | BLACK);  // text color
      draw_button_text(btn_x, (EVE_VSIZE/2) - (60/2),120,60,WHITE,TAG_X0_PLUS,CurrTag,29,"X0 +10");
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 - (60/2),120,60,WHITE,TAG_X1_PLUS,CurrTag,29,"X1 +10");
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 - (60/2),120,60,WHITE,TAG_Y0_PLUS,CurrTag,29,"Y0 +10");      
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 - (60/2),120,60,WHITE,TAG_Y1_PLUS,CurrTag,29,"Y1 +10");
      // buttons "minus":
      btn_x = EVE_HSIZE/2 - (btn_x_next * (how_many_buttons/2)) + btn_x_space/2;
      EVE_cmd_gradcolor(GRAY_LIGHT2);    // buttons color
      EVE_cmd_dl(DL_COLOR_RGB | BLACK);  // text color
      draw_button_text(btn_x, (EVE_VSIZE/2) + (60),120,60,WHITE,TAG_X0_MINUS,CurrTag,29,"X0 -10");
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 + (60),120,60,WHITE,TAG_X1_MINUS,CurrTag,29,"X1 -10");
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 + (60),120,60,WHITE,TAG_Y0_MINUS,CurrTag,29,"Y0 -10");
      draw_button_text(btn_x+=btn_x_next, EVE_VSIZE/2 + (60),120,60,WHITE,TAG_Y1_MINUS,CurrTag,29,"Y1 -10");
      // button "exit":
      draw_button_text(10,480-40-10,120,40,YELLOW,TAG_EXIT,CurrTag,29,"exit");
      // touch:
      strcpy(tmp_str,"CurrTag=");strcat(tmp_str,num2string(CurrTag,NONE));
      EVE_cmd_text(2, 20,26,EVE_OPT_CENTERY,tmp_str);
      strcpy(tmp_str,"Pendown=");strcat(tmp_str,num2string(Pendown,NONE));
      EVE_cmd_text(2, 40,26,EVE_OPT_CENTERY,tmp_str);
      strcpy(tmp_str,"PrevTag=");strcat(tmp_str,num2string(PrevTag,NONE));
      EVE_cmd_text(2, 60,26,EVE_OPT_CENTERY,tmp_str);
      //
      page_stop();
    }
    CurrTag = EVE_memRead8(REG_TOUCH_TAG);
    Pendown = ((EVE_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01);
    if((CurrTag != 0) && CurrTag !=255)//if(( 1 == Pendown) && (CurrTag != PrevTag))
    {
      PrevTag = CurrTag;
      if(PrevTag == TAG_X0_PLUS && x0 < 1000) x0 +=10;
      if(PrevTag == TAG_X0_MINUS ) x0 -=10; //
      if(PrevTag == TAG_Y0_MINUS ) y0 -=10; //&& y0 >= 10
      if(PrevTag == TAG_Y0_PLUS && y0 < 600) y0 +=10;
      
      if(PrevTag == TAG_X1_PLUS && x1 < 1000) x1 +=10;
      if(PrevTag == TAG_X1_MINUS ) x1 -=10;// && x1 >= 10
      if(PrevTag == TAG_Y1_MINUS) y1 -=10; // && y1 >= 10
      if(PrevTag == TAG_Y1_PLUS && y1 < 6000) y1 +=10;
      buzzer(100,1,1);
    }
  }
  buzzer(100,100,3);
  while(!(EVE_memRead32(REG_TOUCH_DIRECT_XY)>>31) & 0x01){};
}

Also there:

 void buzzer(unsigned short int on, unsigned short int off, unsigned char repeat)

 for simple sound from electromagnetic buzzer
and:

 
void page_start(void)
{
  EVE_cmd_dl(CMD_DLSTART); // Start the display list
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK); // Set the default clear color to X WHITE BLACK
  EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
}

becouse I use this 3 command a lot, as well:

void page_stop(void)
{
  EVE_cmd_dl(DL_DISPLAY);  // Instruct the graphics processor to show the list
  EVE_cmd_dl(CMD_SWAP); // Make this list active
  EVE_cmd_execute();
  _delay_ms(5);
  uint8_t int_mask = EVE_memRead8(REG_INT_FLAGS);
}

and:

void draw_button_text(uint16_t x,uint16_t y, uint16_t w, uint16_t h, uint32_t fg_color, uint8_t tag, uint8_t CurrTag,uint8_t font,const char *txt)
{
  EVE_cmd_dl(TAG_MASK(1));
  EVE_cmd_fgcolor(fg_color);        // button color
  EVE_cmd_dl(TAG(tag));
  //
  uint16_t opt=0;
  if(CurrTag == tag) opt =OPT_FLAT;// 256;
  EVE_cmd_button(x,y,w,h,font,opt,"");//(OPT_FLAT&(CurrTag&tag))
  EVE_cmd_text(x+(w/2), y+(h/2),font,OPT_CENTER,txt);
  EVE_cmd_dl(TAG_MASK(0));
}

[Rudolph R. (rudolph)]

Is there actually an issue left?

For a quick test I just copied this line in my basic demo:
EVE_cmd_gradient_burst(0,LAYOUT_Y1,ORANGE,EVE_HSIZE,EVE_VSIZE,0x505050);

And the result is attached, it seems to be doing what it is supposed to 
do.

This is running on a RiTFT50, so BT815, 5" and 800x480.
The controller is an ATSAME51J19A, 120MHz M4F running bare-metal with 
the SPI at 15MHz and with DMA, so the 7µs for the display-refresh is 
correct.

[Karol B. (karol_b135)]

There is no more an issue left, any big one ;)

Maybe there is something wrong in initialisation? Because yours command:

 EVE_cmd_gradient_burst(0,LAYOUT_Y1,ORANGE,EVE_HSIZE,EVE_VSIZE,0x505050);

 give me this result: (image)

[Rudolph R. (rudolph)]

What is wrong in your image?
This is a gradient from orange to grey, from top left to down right.

My orange is this:
#define ORANGE  0xffa500UL

I also tried these, slightly modified from the programming manual:
EVE_cmd_gradient_burst(0, LAYOUT_Y1, 0x0000ff, EVE_HSIZE, LAYOUT_Y1, 
0xff0000);
EVE_cmd_gradient_burst(0, LAYOUT_Y1, 0x808080, 0, EVE_VSIZE, 0x80ff40);
EVE_cmd_gradient_burst(0, LAYOUT_Y1, 0x808080, EVE_HSIZE, EVE_VSIZE, 
0x80ff40);

And these come out as displayed in the programming manual.

I also tried it in EVE Screen Editor:
CMD_GRADIENT(0, 0, 0x0000FF, 800, 0, 0xff0000)

This comes out pretty much the same.

[Karol B. (karol_b135)]

How about now? Could you see these colored stripes in the picture? 
Gradient isn't smooth. In my opinions its look awful ;)
Do you understand my problem? If so, could you pointer me where should I 
look solve?

[Karol B. (karol_b135)]

This is the best picture (attached image). Right white lines are at each 
10 pixels. So it can by our scale, then we can see that darker stripes 
are at near each 10 pixels.
Until I bought new tft with BT815 I was thinking that is becouse only 6 
from 8 lines for color data was connected (only 16 bits of color, not 
24), but now its fore sure, 24 bits color.

[Rudolph R. (rudolph)]

The diagonal lines?
I have no good idea what these are.

Is your supply stable?
That could be a ripple in the supply voltage due to barely enough 
current available.

What happens when you remove everything else from the display-list?
Especially the buttons.

[Karol B. (karol_b135)]

This is as simple as can be:

void quick_test(void)
{
  EVE_memWrite8(REG_PWM_DUTY, 13);
  EVE_cmd_dl(CMD_DLSTART); // Start the display list
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK); // Set the default clear color to X WHITE BLACK
  EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
  EVE_cmd_gradient(0,0,ORANGE,0,480,0x505050);
  EVE_cmd_dl(DL_DISPLAY);
  EVE_cmd_dl(CMD_SWAP);
  EVE_cmd_execute();
  while(1);
}

The same efects. Power suply is stable. What about EVE_init()? Can be 
there something wrong (for this screen)?
I have this function with no changes.

 #define EVE_EVE3_70

[Rudolph R. (rudolph)]

Karol B. schrieb:
> I have this function with no changes. #define EVE_EVE3_70

Hmmm, up there you wrote you have an EVE_RiTFT70.
The EVE3_70 is a resistive-touch display with BT816 from Matrix Orbital.

Please try "EVE_RiTFT70".

[Karol B. (karol_b135)]

It's no matter, i have tried many of them. What you thinking about REG 
DITHER and so on? I tried:

 EVE_memWrite8(REG_DITHER, 1);

 and

 EVE_memWrite8(REG_DITHER, 0);

with no changes.

[Rudolph R. (rudolph)]

As I wrote, I have no good idea what this is.

I am mostly ignoring REG_DITHER and leaving in on default, 1.

I had minor issues with CSPREAD but then it is active for RiTFT70 but 
disabled for EVE3-70 as specified by their datasheets.

[Karol B. (karol_b135)]

Thanks a lot. I will try tomorrow with Riverdi, this company is from 
Poland  as  I am, so it can be easy to understand each other ;)
My english is poor like the gradient quality :D

Rudolph could you explain how to deal with graphics (*.jpg, *.bmp etc)?
I have two hardware versions (old one with FT813 + ATMEGA128 + SDcard 
interface and new one with BT815 + 25Q64JVSIQ + ATMEGA128 + SDcard 
interface, both with 7" 800x480 TFT from Riverdi).
I haven't needed a SD card before, so I worry to use it. This is very 
important project. I worry about stable work, potential memory card 
errors and so on.
What is the best solutions?
How to prepare image files, adress it for EVE etc? image-convert 0.7 is 
enougth?

 /* 100x100 test-picture in .jpg format */
const uint8_t pic[3867] PROGMEM =..

Why 3876? When I saved pic[3867] as data.c then file was 22,7 KB..

Schönen Abend :)
Karol

[Rudolph R. (rudolph)]

Karol B. schrieb:
> I haven't needed a SD card before, so I worry to use it.

I can not help with that, the last time I used an SD card was for SD2IEC 
and I did not do the software for that one.

> How to prepare image files, adress it for EVE etc? image-convert 0.7 is
> enougth?

That is okay but terribly outdated. :-)
Try the EVE Asset Builder: https://brtchip.com/eve-toolchains/

>/* 100x100 test-picture in .jpg format */
>const uint8_t pic[3867] PROGMEM =..
>Why 3876? When I saved pic[3867] as data.c then file was 22,7 KB..

It really is what it says, a .jpg file, this is why it is used with 
CMD_LOADIMAGE().

[Daniel S. (snipod)]

Hi Rufolph,
bin heute mal dazu gekommen am Repo zu ziehen und sieht echt alles tip 
top aus...

Ich habe ne Frage bezüglich ner custom Font:
1. Mit Hilfe des EVE Asset Builders erstelle ich mir eine .rawh File
2. Aus diesem mache ich dann eine Header Datei, mit den Daten als 
uint8_t Array.
3. Das Array lade ich mit EVE_memWrite_sram_buffer? Oder 
EVE_cmd_loadimage? an Position X
4. Ich setze die Font mit EVE_cmd_setfont2(12, X, 32) an das Handle 12 - 
sofern die Font bei ASCII 32 beginnt
5. ich kann die Font normal nutzen auf dem Handle 12

Irgendwo hab ich nen Fehler... und wie wäre das mit setfont(1) - dafür 
muss man ja noch bisschen was Einstellen

[Rudolph R. (rudolph)]

Ich habe in der einfachen Demo auch einen UTF-8 font mit drin der bei 
BT81x displays in das externe FLASH geladen werden und von da benutzt 
werden kann.
Also im ASTC format.
Mit den FT81x ist man auf 127 Zeichen beschränkt.

Der ist in meinem letzten Foto auch zu sehen:
https://www.mikrocontroller.net/attachment/488936/20210114_193133.jpg
Das "EVE Demo" ist nicht so ganz original so. :-)

Wie man da hin kommt habe ich hier mal beschrieben:
http://www.lcdforums.com/forums/viewtopic.php?f=45&t=6894&sid=c3e51632d7eac81d3d95d1a32d81c7c4

Aber ich habe das gerade mal ausprobiert und einen Font mit dem EVE 
Asset Builder in das "Legacy" Format umgewandelt.

Die .rawh die dabei raus kommt würde ich einfach ignorieren.
Die ebenfalls generierte .c als Beispiel zeigt im Grunde wie das in den 
EVE kommt:
#define FONT_HANDLE       (1)
#define FONT_FILE_ADDRESS (RAM_G + 1000)
#define FIRST_CHARACTER   (32)

Gpu_Hal_LoadImageToMemory(phost, "../../../L8/ARCADE_R_12_L8.raw", 
FONT_FILE_ADDRESS, LOAD);

Gpu_CoCmd_SetFont2(phost, FONT_HANDLE, FONT_FILE_ADDRESS, 
FIRST_CHARACTER);
Gpu_CoCmd_Text(phost, 50, 50, FONT_HANDLE, 0, "AaBbCcDdEeFf");

Also die .raw wird in dem Beispiel einfach an RAM_G+1000 geschrieben, so 
wie das beim Konvertieren eingestellt war.
Also das muss man schon wissen wohin das soll.

Was ich jetzt machen würde und was ich gerade soweit ausprobiert habe, 
ich würde ja die .raw mit dem "Asset Compressor" packen, auf die Art 
habe ich aus der 13kB .raw für den Font gerade eine 3kB .zlib gemacht.

Dann mit dem "BIN2C" Modul im EVE Asset Compressor daraus ein .c file 
generieren mit dem Array.

Das würde ich bei mir in die tft_data.c / tft_data.h einbauen.
Und es einfach mit CMD_INFLATE laden:

EVE_cmd_inflate(MEM_FONT, font_array, sizeof(font_array));

Danach dann noch irgendwo das hier wie bei FTDI / BRT:
EVE_cmd_setfont2(12,MEM_FONT,32);
EVE_cmd_text(EVE_HSIZE/2, 15, 12, EVE_OPT_CENTERX, "EVE Demo");

Ich habe jetzt nur nich probiert ob der Font so angezeigt wird, ich 
wüsste aber auch keinen Grund warum nicht.

[Matrix O. (Firma: Matrix Orbital) (matrixorbital)]

Hello Everyone! First of all thank you to Rudolph for all the work he 
has done, we are thankful!

I also wanted to show two new EVE4 displays, a 10.1" 1280x800 and a 4" 
720x720 we are just about to release!

[Rudolph R. (rudolph)]

Matrix O. schrieb:
> Hello Everyone! First of all thank you to Rudolph for all the work he
> has done, we are thankful!

Thank you for your kind words!
It has been a while but I am still enjoying the ride. :-)

> I also wanted to show two new EVE4 displays, a 10.1" 1280x800 and a 4"
> 720x720 we are just about to release!

Sweet!
Looks like I am buying a bigger 3D printer for my lab at work this year. 
:-)

[Karol (Gast)]

Matrix O. schrieb:
> I also wanted to show two new EVE4 displays, a 10.1" 1280x800

> there have been some challenges with the code... but here it is!

Could you tell something more about it?

Can I easily use this lcd with Rudolph library?

[Rudolph R. (rudolph)]

Karol schrieb:
> Can I easily use this lcd with Rudolph library?

You will, I have not put in profiles for these as I have not seen the 
exact specs yet but that should be merely a formality.
BT817/BT818 support with the new commands and registers is in since 
Bridgetek officially launched these.

[Daniel S. (snipod)]

Rudolph R. schrieb:

> Dann mit dem "BIN2C" Modul im EVE Asset Compressor daraus ein .c file
> generieren mit dem Array.
>
> Das würde ich bei mir in die tft_data.c / tft_data.h einbauen.
> Und es einfach mit CMD_INFLATE laden:
>
> EVE_cmd_inflate(MEM_FONT, font_array, sizeof(font_array));
>
> Danach dann noch irgendwo das hier wie bei FTDI / BRT:
> EVE_cmd_setfont2(12,MEM_FONT,32);
> EVE_cmd_text(EVE_HSIZE/2, 15, 12, EVE_OPT_CENTERX, "EVE Demo");
>
> Ich habe jetzt nur nich probiert ob der Font so angezeigt wird, ich
> wüsste aber auch keinen Grund warum nicht.

Perfekt, habe es genau so ausprobiert und es funktioniert jetzt.
Ich hatte wohl zwei fehler :) EVE_cmd_inflate anstatt 
EVE_cmd_inflate_burst... und anscheinend möchte er die font nicht an 
stelle 0 schreiben, schreibe ich sie an EVE_RAM_G + 1000 (also 1000) 
klappts.

Das mit dem Bin2c Modul ist echt nützlich, hatte mir dafür schon mein 
eigenes Tool programmiert, aber das kann ich jetzt getrost wegwerfen :) 
Habe nicht mitbekommen, dass es mittlerweile die 2.1 gibt vom Asset 
Builder.

Ich arbeite aktuell noch mit dem FT815Q, da mein Prototyp mit dem NHD 
Display läuft... mein fertiges Display mit eigener Platine hat aber 
einen BT815Q und funktioniert mittlerweile auch sehr gut :) Warte nur 
noch auf mein Panel mit Touch... Für die Serie gehe ich dann vielleicht 
sogar direkt zum 817q über. Muss mir noch mal anschauen was das für die 
Platine bedeutet (vielleicht ist er ja sogar drop in kompatibel...)



Eine Frage zum Fash Builder:
Wenn ich jetzt zB einige Bilder und Font(s) im Flash ablegen möchte, 
würde ich da die komprimierten oder unkomprimierten Daten nehmen? Wenn 
ich das richtig verstanden habe, muss ich ohnehin alles in den RAM_G 
laden, weshalb - sofern genug Platz da ist - es nicht unbedingt Sinnvoll 
ist, die Assets zu komprimieren, oder?

[Daniel S. (snipod)]

Ah und noch eine Frage (sorry...) zu den Pointern im RAM_G.

Wenn ich mehrere Assets (Bild, Font, was auch immer) in den RAM_G laden 
möchte, dann muss ja der Pointer des nächsten Assets, der Pointer des 
vorheriges Assets + die RAW Größe sein.

Bsp.:
Font_1 : PTR = 1000, RAW_SIZE = 32638
Font_2 : PTR = FONT_1.PTR + FONT_1.RAW_SIZE = 33638, RAW_SIZE = 50152
...

Ich habe das mal exemplarisch versucht, aber bekomme die zweite Font 
einfach nicht zum Laufen. Wenn ich jeweils nur eine der beiden Fonts 
lade, funktionieren sie.

    ESP_LOGI("hmi", "writing light to: %u", MEM_ADR_MONTSERRAT_LIGHT_16);
    EVE_cmd_inflate(MEM_ADR_MONTSERRAT_LIGHT_16, Montserrat_Light_16_L8_ZLib, sizeof(Montserrat_Light_16_L8_ZLib));
    uint32_t size = EVE_cmd_getptr();
    ESP_LOGI("hmi", "ptr: %u", size);
    ESP_LOGI("hmi", "writing black to: %u", MEM_ADR_MONTSERRAT_BLACK_20);
    EVE_cmd_inflate(MEM_ADR_MONTSERRAT_BLACK_20, Montserrat_Black_20_L8_ZLib, sizeof(Montserrat_Black_20_L8_ZLib));
    size = EVE_cmd_getptr();
    ESP_LOGI("hmi", "ptr: %u", size);

Resultat:
I (1000) hmi: writing light to: 1000
I (1063) hmi: ptr: 33638
I (1063) hmi: writing black to: 50152
I (1152) hmi: ptr: 105020

(soweit) ja eigentlich alles gut... nur dass meine zweite font nicht 
mehr richtig funktioniert :(

Was mach ich denn nur falsch...?

[Rudolph (Gast)]

Daniel S. schrieb:
> Ich hatte wohl zwei fehler :)
> EVE_cmd_inflate anstatt EVE_cmd_inflate_burst...

Äh, was? Es gibt keine EVE_cmd_inflate_burst(). :-)
Es gibt so ein paar Kommandos die komplett untauglich für Display-Listen 
sind, die eben CMD_INFLATE und CMD_LOADIMAGE.

> und anscheinend möchte er die font nicht an stelle 0 schreiben,
> schreibe ich sie an EVE_RAM_G + 1000 (also 1000) klappts.

Na das wird ja in dem EVE Asset Builder eingestellt beim Konvertieren,
Default-Wert ist 1000, warum auch immer.

> Habe nicht mitbekommen, dass es mittlerweile die 2.1 gibt vom Asset
> Builder.

Dazu habe es auch keine Ankündigung.

> Für die Serie gehe ich dann vielleicht
> sogar direkt zum 817q über. Muss mir noch mal anschauen was das für die
> Platine bedeutet (vielleicht ist er ja sogar drop in kompatibel...)

Ja, die sind drop-in kompatibel.

> Eine Frage zum Fash Builder:
> Wenn ich jetzt zB einige Bilder und Font(s) im Flash ablegen möchte,
> würde ich da die komprimierten oder unkomprimierten Daten nehmen? Wenn
> ich das richtig verstanden habe, muss ich ohnehin alles in den RAM_G
> laden, weshalb - sofern genug Platz da ist - es nicht unbedingt Sinnvoll
> ist, die Assets zu komprimieren, oder?

Nun, das kommt darauf an, ASTC komprimierte Bilder und Fonts kann man 
direkt aus dem Flash benutzen, mein Demo-Code benutzt doch einen UTF-8 
Font aus dem Flash.
Dafür muss man die .glpyh und die .xfont in das Flash schreiben, direkt 
so zusammen und dann beim Start die .xfont irgendwohin in das RAM_G 
kopieren.

Man muss nur etwas aufpassen, die Bandbreite von dem Flash ist begrenzt, 
ich hatte schon seltsame Fehler mit zu vielen Bildern auf einmal und bei 
Fonts mit zu vielen unterschiedlichen Zeichen.

Und selbst wenn man einen Font aus dem RAM_G benutzt, die sind richtig 
gut komprimierbar, weil das viele einzelne Bilder sind.

> Wenn ich mehrere Assets (Bild, Font, was auch immer) in den RAM_G laden
> möchte, dann muss ja der Pointer des nächsten Assets, der Pointer des
> vorheriges Assets + die RAW Größe sein.
>
> Bsp.:
> Font_1 : PTR = 1000, RAW_SIZE = 32638
> Font_2 : PTR = FONT_1.PTR + FONT_1.RAW_SIZE = 33638, RAW_SIZE = 50152

Plus vielleicht mal ein paar Bytes für Alignment.
Ich tendiere dazu die Adressen auf 0xnnnn00 zu setzen.

> (soweit) ja eigentlich alles gut... nur dass meine zweite font nicht
> mehr richtig funktioniert :(

Hast Du beim Konvertieren des zweiten Fonts denn die Adresse an der 
dieser liegen wird denn mit angegeben?

Die Glyphen müssen ja irgendwie gefunden werden, in den Daten für den 
Font sind die Adressen eincodiert.

Wenn man einen UTF-8 font für die BT81x konvertiert dann stehen diese 
Daten in der .xfont Datei.
Und wenn man eine .glyph und eine .xfont mit dem EVE Asset Builder in 
das FLASH brennt, dann werden die Daten in der .xfont automatisch 
angepasst.

[Daniel S. (snipod)]

Rudolph schrieb:
> Äh, was? Es gibt keine EVE_cmd_inflate_burst(). :-)
> Es gibt so ein paar Kommandos die komplett untauglich für Display-Listen
> sind, die eben CMD_INFLATE und CMD_LOADIMAGE.

Ähh sorry, ich meinte natürlich CMD_SETFONT2...

Rudolph schrieb:
> Na das wird ja in dem EVE Asset Builder eingestellt beim Konvertieren,
> Default-Wert ist 1000, warum auch immer.

Das war der richtige hint. Ich war davon ausgegangen, dass die Addressen 
in der Tabelle am Anfang der Font relativ zur Startadresse sind. Dass 
die Font natürlich genau wissen muss, wo sie liegt... Kaum stellt man 
das mit richtig ein, funktioniert das einwandfrei.
Vielen Dank ;)

Rudolph schrieb:
> Ja, die sind drop-in kompatibel.

1A dann tausch ich die grad auf der BOM aus :)

Rudolph schrieb:
> Wenn man einen UTF-8 font für die BT81x konvertiert dann stehen diese
> Daten in der .xfont Datei.
> Und wenn man eine .glyph und eine .xfont mit dem EVE Asset Builder in
> das FLASH brennt, dann werden die Daten in der .xfont automatisch
> angepasst.

Das muss ich dann auch noch versuchen. Auf meinem PCB habe ich mal 128 
MB Flash platziert - kostet ja nix... Muss mir nur überlegen wie ich das 
Sinnvollerweise für eine eventuelle "serien" Fertigung mache.

[Rudolph R. (rudolph)]

Look at what I found:
https://riverdi.com/product-category/intelligent-displays/bt817q/

Earlier this week Riverdi launched a complete lineup of BT817 displays.
I could not find any of these at distributors yet.

I am a wee bit concerned about the touch controller Riverdi is using.
It is a ILI2132A from Ilitek and I have no idea yet if the BT817 
directly supports it or if it needs to be patched - and if so, how.

Also there is no sample-code yet from Riverdi.
Their Github repository is not getting much attention.

I just checked the datasheets and the displays with the same size do 
have the same display parameters listed.
All the datasheets do have a "PRELIMINARY" watermark though.
Well, the parameters may be wrong as it is the case with at least the 
RVT50UQB for example.

[Ioan Mihai Cozac (Gast)]

How works the rotation in case of the primitives, for example a square 
with the corners to the margins of the screen, also rotated 45 deg? Has 
someone succes with this? I have tried but failed so far, CMD_ROTATE 
shows only garbage on the screen instead of the rotated symbols. The 
JPEGs rotate properly.

[Rudolph R. (rudolph)]

Ioan Mihai Cozac schrieb:
> How works the rotation in case of the primitives, for example a
> square
> with the corners to the margins of the screen, also rotated 45 deg? Has
> someone succes with this? I have tried but failed so far, CMD_ROTATE
> shows only garbage on the screen instead of the rotated symbols. The
> JPEGs rotate properly.

Please add a couple of lines do demonstrate what you mean.
And perhaps two images.

[Ioan Mihai Cozac (Gast)]

I try to make my own spinner, 2 sectors rotating around a circle.
The sample code is this:

  float t = (spin / 360.00) * PI;
  int r = (int)(100 * cos(t));  // SPIN RADIUS
  FT8_cmd_dl(COLOR_MASK(0, 0, 0, 0));
  FT8_cmd_dl(STENCIL_OP(FT8_INCR, FT8_INCR));
  FT8_cmd_dl(DL_BEGIN | FT8_RECTS);
  FT8_cmd_dl(LINE_WIDTH(1 * 16));
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
  FT8_cmd_dl(VERTEX2F(540 * 16, 230  * 16));
  FT8_cmd_dl(VERTEX2F(340 * 16, 330 * 16));
  FT8_cmd_dl(VERTEX2F(440 * 16, 430 * 16));
  FT8_cmd_dl(DL_BEGIN | FT8_POINTS);
  FT8_cmd_dl(POINT_SIZE(60 * 16));
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
  FT8_cmd_dl(STENCIL_FUNC(FT8_GEQUAL, 2, 255));
  FT8_cmd_dl(COLOR_MASK(255, 255, 255, 255));
  FT8_cmd_dl(DL_COLOR_RGB | RED);
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
  FT8_cmd_dl(LINE_WIDTH(10 * 16));
  FT8_cmd_dl(DL_COLOR_RGB | WHITE);
  FT8_cmd_dl(POINT_SIZE(40 * 16));
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
  /*
  FT8_cmd_dl(DL_BEGIN | FT8_BITMAPS);
  FT8_cmd_dl(CMD_LOADIDENTITY);
  FT8_cmd_rotate((45 / 360) * 65536);
  FT8_cmd_dl(CMD_SETMATRIX);
  FT8_cmd_dl(VERTEX2F(440 * 16, 330 * 16));
  */
  FT8_cmd_dl(DL_COLOR_RGB | BLACK);
  //FT8_cmd_number(420, 315, 28, 0, spin);
  //FT8_cmd_number(420, 330, 28, 0, r);

I know its an old library version but i make tests on an older display, 
if it works i add the methods to the newer software.
The spin var is a loop counter for the rotating effect.
If i add the commented part it shows the garbage pixels, like the second 
picture.

In the example codes from FTDI/Bridgetek there are many moving parts but 
i saw no rotating squares yet. Maybe in the LOGO animation but i am not 
sure.

[Rudolph R. (rudolph)]

Hmm, I have no idea what these fragments are.
And where is the square in this?

My take on this would be to use an image of the outer segments with 
alpha channel and put a dot in the center of it.

I just tried this in EVE Screen Editor and it works.
Only the image I quickly cobbled up with paint.net was a bit fuzzy on 
the outer ring when being rotated.

[Ioan Mihai C. (mihaicozac)]

The square was just a general idea for the spinning concept, in my 
sketch there are 2 squares, the red ones, but only a part of them are 
visible (they go through masking and stencil so only the sector part is 
visible.
So is seams that the rotation works only on bitmaps not on primitives, i 
should take a part of the screen and process as a bitmap but this takes 
room in GRAM and with my main program it is almost full already. I will 
try the old road again with many thin segments placed in circle side by 
side, although this method implies a very long display list.

[Anguel S. (anguel)]

Hallo Rudolph,

ich schaue schon länger in Richtung FTDI/BRT EVE, hatte mich aber bis 
heute aufgrund der schlechten Doku nicht so ganz daran getraut :-) Heute 
habe ich es endlich gewagt und mir die gefühlt 101 Appnotes und 
zugehörige Beispiele von BRT angeschaut und sogar angefangen zu lesen. 
Wollte ursprünglich den Screen Designer nutzen, der aber nur mit deren 
Nischen-MCU FT9xx funktioniert. Zwischenzeitlich bin ich immer wieder 
auf deine qualifizierten Beiträge in den Foren und deine Lib gestoßen - 
Respekt!

Rudolph R. schrieb:

> Anstatt das jedesmal wieder und komplett redundant zu übergeben habe ich
> den entscheidenden Parameter "cmdOffset" zu einer globalen Variable
> gemacht

Das war eigentlich das Erste was mich bei deren erster "API" gestört 
hat.
Vielleicht war es Absicht, damit sich das "cmdOffset" beim Entwickler 
ins Gehirn einbrennt ;-)

> Die neue "Portable MCU Library for EVE", beschrieben in BRT_AN_025
> gefällt mir deutlich besser als die erste Library von FTDI.
> Wenn es das damals schon gegeben hätte, hätte ich meine Version
> vielleicht gar nicht angefangen.

Es ist für mich nicht ganz nachvollziehbar, warum die so viele Anläufe 
und Appnotes brauchen. Vor allem scheinen die immer noch keine logische 
und universelle Lösung zu haben. Evtl. Bachelorarbeiten oder 
Praktikanten? Dass das auch mit dem inzwischen lange verfügbaren eigenen 
Screen Editor noch nicht kompatibel ist, wundert mich noch mehr.
Und was soll der Mist mit Keil bei STM32 bei einer angeblich inzwischen 
portablen Lösung. Inzwischen ist GCC der offizielle Compiler der 
offiziellen STM32CubeIDE und der ist wieder mal nicht dabei...
Ich wette, dass die min. 100x mehr Chips verkauft hätten, wenn die eine 
anständige Library mit anständiger Doku mal entwickelt hätten.

> Nur ist mein Code aktuell mit dem gleichen Controller eine ganze Ecke
> schneller.

Gibt es momentan eigentlich etwas, was deine Lib nicht kann, was die 
neue von BRT kann? Kann man mit deiner Lib evtl. auch auf dem PC 
emulieren?

Werde mir wohl die neuen Riverdi-Diplays mit BT817 zulegen, wenn die mal 
verfügbar sind. Aber deren Lib wollte ich mir nicht auch noch antun, 
oder was meinst du dazu?

Viele Grüße,

Anguel

[Rudolph R. (rudolph)]

Anguel S. schrieb:
...
Hrmm, kein Kommentar. :-)

> Gibt es momentan eigentlich etwas, was deine Lib nicht kann, was die
> neue von BRT kann? Kann man mit deiner Lib evtl. auch auf dem PC
> emulieren?

Das ist genau das worüber ich noch gar nicht nachgedacht habe.
Wenn ich unter Windows mit EVE spielen möchte dann starte ich den EVE 
Screen Editor.
Matrix Orbital hat in der Richtung was gemacht.

Rein funktional habe ich bis hoch zum BT817/BT818 alles drin.

Bridgetek hat noch Support für BeagleboneBlack, MSP430, FT9xx, 
PIC18F46K22 und RaspberryPi mit der BRT_AN_025.
Mit keinen von denen habe ich jemals was gemacht und auch keine Anfragen 
in der Richung gehabt.

> Werde mir wohl die neuen Riverdi-Diplays mit BT817 zulegen, wenn die mal
> verfügbar sind. Aber deren Lib wollte ich mir nicht auch noch antun,
> oder was meinst du dazu?

Deren Lib basiert ja auf der von Bridgtek, was das mit dem "phost" soll 
ist mir immer noch nicht ganz klar.
Die funktioniert sicher auch.
Und sie haben Support für Linux. (äh, okay?)

Auf jeden Fall werde ich die Timings für die neuen Module noch einbauen, 
bisher ist die Doku allerdings noch etwas dünn, so Preliminary, und 
darauf in den nächsten Wochen an gar ein RVT101HVBNWC00-B  heran zu 
kommen mache ich mir gerade nicht viel Hoffnung.
Ich muss mal schauen was die mit dem neuen Touch-IC machen.

[Anguel S. (anguel)]

Rudolph R. schrieb:

> Matrix Orbital hat in der Richtung was gemacht.

Danke, schaue ich mir mal an.

> Deren Lib basiert ja auf der von Bridgtek, was das mit dem "phost" soll
> ist mir immer noch nicht ganz klar.

Ist wirklich eigenartig. Wollten die damit vielleicht mal mehrere 
Displays gleichzeitig ansteuern können?

> Ich muss mal schauen was die mit dem neuen Touch-IC machen.

Habe Riverdi gestern diesbezüglich mal gefragt, die sagten das ginge 
alles über den EVE chip, oder meinst du "Teufel im Detail" und so? ;-)

Wie ist das eigentlich mit der Kalibrierung bei diesen neuen 
Capacitive-Touch Panels, Riverdi sagte, dass man nur ein Display 
kalibrieren müsste und diese Daten dann für alle verwenden, wobei ich 
mich dann natürlich frage, warum die diese Daten dann nicht einfach 
irgendwo fest definieren.

Achso, noch eine generelle Frage: Werden eigentlich bei EVE diese 
Tag-Events schon beim Touch ausgelöst, oder kann man das auch so machen, 
dass die erst beim Wegnehmen des Fingers getriggert werden und das dann 
nur wenn man noch im Bereich des Buttons ist, also wie bei einem echten 
Touch-OS (iOS, Android)? Ich habe vor Kurzem nämlich mit 4DSystems 
Displays und deren Entwicklungsumgebung gearbeitet und das nervige war, 
dass man da mit dem Finger einmal über das Display ziehen konnte und 
alle Buttons auf dem Weg wurden dann mal eben getriggert, was IMHO für 
ein halbwegs professionelles Gerät ein absolutes No-Go ist. Das komische 
Verhalten ließ sich da auch nicht ändern :-)

Grüße

Anguel

[Rudolph (Gast)]

Anguel S. schrieb:
>> Deren Lib basiert ja auf der von Bridgtek, was das mit dem "phost" soll
>> ist mir immer noch nicht ganz klar.
>
> Ist wirklich eigenartig. Wollten die damit vielleicht mal mehrere
> Displays gleichzeitig ansteuern können?

Das mag sein, für sowas aber 99% der Anwendungen auszubremsen ist etwas 
seltsam, zumal ich für sowas auch noch kein Beispiel gesehen habe.
Was ich im Moment mache ist eine kleine Platine mit einem CAN-FD fähigen 
Controller mit in das Gehäuse zu packen.
Damit könnte ich auch mehrere davon parallel betreiben.

>> Ich muss mal schauen was die mit dem neuen Touch-IC machen.
>
> Habe Riverdi gestern diesbezüglich mal gefragt, die sagten das ginge
> alles über den EVE chip, oder meinst du "Teufel im Detail" und so? ;-)

Ja, genau, Details, der Touch-Controller taucht in den Bridgetek 
Unterlagen erstmal nicht auf.
Eine Mail hatte ich auch geschickt, aber praktisch keine Antworten 
erhalten.

> Wie ist das eigentlich mit der Kalibrierung bei diesen neuen
> Capacitive-Touch Panels, Riverdi sagte, dass man nur ein Display
> kalibrieren müsste und diese Daten dann für alle verwenden, wobei ich
> mich dann natürlich frage, warum die diese Daten dann nicht einfach
> irgendwo fest definieren.

Das funktioniert bestenfalls für die Displays aus einer 
Produktionscharge.
Die Kalibrierung macht man ja weil so ein Touchsreen einen Versatz zum 
Display haben kann und zudem noch gedreht sein kann.

Ich bin da auch gerne faul und speichere die Werte in der Software, 
teilweise geht das sogar über Familien hinweg, etwa EVE2-50G und 
EVE3-50G.
Und dann werden mal die Panels in der Produktion geändert und man hat 
zwei gleiche Modelle aus der selben Familie bei dem der Touch mit dem 
Daten von dem jeweils anderen Display gar nicht funktioniert.
Ist mir mit den EVE3-43G passiert, ich hatte schon länger eines und dann 
vier neue für ein Projekt gekauft.
Die vier neuen funktionieren mit einem Satz Daten, kein Problem, aber 
nicht mit den Daten vom alten Display.
Und da kann man dem Hersteller auch nichts vorwerfen, der kann ja nicht 
zusichern, dass die Dinger von jetzt bis immer exakt gleich hergestellt 
werden.

> Achso, noch eine generelle Frage: Werden eigentlich bei EVE diese
> Tag-Events schon beim Touch ausgelöst,

Ja, werden sie.

> oder kann man das auch so machen,
> dass die erst beim Wegnehmen des Fingers getriggert werden und das dann
> nur wenn man noch im Bereich des Buttons ist, also wie bei einem echten
> Touch-OS (iOS, Android)?

Also mein Android macht das auch nicht anders, wäre auch etwas nervig 
wenn ein Tastendruck erst beim loslassen erkannt werden würde.

> Ich habe vor Kurzem nämlich mit 4DSystems
> Displays und deren Entwicklungsumgebung gearbeitet und das nervige war,
> dass man da mit dem Finger einmal über das Display ziehen konnte und
> alle Buttons auf dem Weg wurden dann mal eben getriggert, was IMHO für
> ein halbwegs professionelles Gerät ein absolutes No-Go ist. Das komische
> Verhalten ließ sich da auch nicht ändern :-)

Mein aktuelles Projekt ist etwas mit Slider und Buttons überladen, also 
die Fläche ist knapp für die 4 großen Slider und 11 Buttons.
Und damit man keine Buttons auslöst wenn man mit dem Finger über den 
Rand eines Sliders geht habe ich da eine Verriegelung eingebaut.

Dazu lese ich jetzt REG_TOUCH_RAW_XY zusätzlich ein und reagiere auf den 
Tag 0x00 nur noch wenn REG_TOUCH_RAW_XY == 0xffffffff.
Damit kann ich mit dem Finger über das ganze Display streichen, 
ausgelöst wird dann nur das Event für das erste Objekt das ich treffe.

EVE ist da relativ stumpf, berührt man was steht das im REG_TOUCH_TAG 
Register.
Aber weil das so einfach ist, kann man das gewünschte Verhalten in 
Software kontrollieren, etwa das bei dem Druck auf einen Button nur 1 
Event generiert wird.

[Anguel S. (anguel)]

Rudolph schrieb:

> Was ich im Moment mache ist eine kleine Platine mit einem CAN-FD fähigen
> Controller mit in das Gehäuse zu packen.

Habe ich schon auf deinem Github Account gesehen. Nur schade, dass du 
kein STM32 Fan bist ;-) Habe mir deine EVE-Lib mal kurz angeschaut, 
sieht schon alles sehr durchdacht und performant aus :-) Werde wohl 
gleich damit losstarten, wenn ich mal ein Display habe. Übrigens nutze 
ich den neuen STM32G4, sollte aber dank STM-HAL alles die gleiche Suppe 
sein wie die F-Serie. Muss nur schauen, dass ich das ganze ins 
STM32CubeIDE reinbekomme, dein STM32-Beispiel ist PlatformIO und auch 
noch Arduino, sollte aber kein Riesenproblem sein.

> Ja, genau, Details, der Touch-Controller taucht in den Bridgetek
> Unterlagen erstmal nicht auf.
> Eine Mail hatte ich auch geschickt, aber praktisch keine Antworten
> erhalten.

Wundert mich nicht bei Bridgetek. So ein Chaos sieht man selbst in 
dieser Branche selten. Ich hoffe mal, dass Riverdi die Touchscreens 
irgendwie zumindest angetestet hat, bevor die es in den Markt werfen. 
Die haben dazu gemeint:
"CTP is directly connected to EVE chip. You can read coordinates by EVE, 
but generally You use widgets and for example You make tag on button and 
read tag or check event. "

> Das funktioniert bestenfalls für die Displays aus einer
> Produktionscharge.
> Die Kalibrierung macht man ja weil so ein Touchsreen einen Versatz zum
> Display haben kann und zudem noch gedreht sein kann.

Aaaaha, muss ich mir merken. Riverdi meinte dazu:
"Calibration is only to fullfill EVE calibration matrix.
EVE4 - no need calibration, because CTP has the same resolution as LCD.
EVE3 has different CTP, so it needs to be calibrated.
It’s one command – touching 3 point.
You can make calibration once, read calibration matrix 
REG_TOUCH_TRANSFORM_A-F  and save it, then use for all devices. "

> Also mein Android macht das auch nicht anders, wäre auch etwas nervig
> wenn ein Tastendruck erst beim loslassen erkannt werden würde.

Interessant. Probier mal bei deinem Android das aus: Touchelement (z.B. 
Button) berühren aber nicht loslassen, dann Finger wegziehen ohne 
loszulassen, dann außerhalb des Elements loslassen. Bei mir wird das 
Element dann nicht aktiviert. Ist bei iOS, Windows, etc. genau dasselbe. 
Kann man auch mit der Maus testen.
Übrigens hat jemand etwas hier von einer Sticky-Tag-Implementierung 
geschrieben:
http://www.brtcommunity.com/index.php?topic=147.10;wap2
Bin aber nicht ganz sicher, ob er sowas meint.

> Mein aktuelles Projekt ist etwas mit Slider und Buttons überladen, also
> die Fläche ist knapp für die 4 großen Slider und 11 Buttons.
> Und damit man keine Buttons auslöst wenn man mit dem Finger über den
> Rand eines Sliders geht habe ich da eine Verriegelung eingebaut.
>
> Dazu lese ich jetzt REG_TOUCH_RAW_XY zusätzlich ein und reagiere auf den
> Tag 0x00 nur noch wenn REG_TOUCH_RAW_XY == 0xffffffff.
> Damit kann ich mit dem Finger über das ganze Display streichen,
> ausgelöst wird dann nur das Event für das erste Objekt das ich treffe.

Genau sowas meine ich! Aber das ist wahrscheinlich (noch) nicht in 
deiner EVE-Lib drin, oder?

> Aber weil das so einfach ist, kann man das gewünschte Verhalten in
> Software kontrollieren, etwa das bei dem Druck auf einen Button nur 1
> Event generiert wird.

Das ist wohl einer der Vorteile der Lower-Level-Programmierung der 
Dinger.

Grüße
Anguel

[Rudolph (Gast)]

Anguel S. schrieb:
>> Was ich im Moment mache ist eine kleine Platine mit einem CAN-FD fähigen
>> Controller mit in das Gehäuse zu packen.
>
> Habe ich schon auf deinem Github Account gesehen. Nur schade, dass du
> kein STM32 Fan bist ;-)

Och, kann man so nicht sagen, ich finde die eigentlich ganz nett soweit.
Zumindest die aktuelleren Modelle.
Nur kann ich mit STM32 einfach beruflich nichts anfangen, da es die 
nicht in Automotive qualifiziert gibt.

Ich habe auch was vor mit dem STM32H7Bxxx, das kann ich momentan nur 
nicht mal anfangen, weil ich die Dinger einfach nicht in die Finger 
bekomme.
ST hat scheinbar gerade etwas Probleme den Markt zu bedienen.

> Habe mir deine EVE-Lib mal kurz angeschaut,
> sieht schon alles sehr durchdacht und performant aus :-) Werde wohl
> gleich damit losstarten, wenn ich mal ein Display habe. Übrigens nutze
> ich den neuen STM32G4, sollte aber dank STM-HAL alles die gleiche Suppe
> sein wie die F-Serie. Muss nur schauen, dass ich das ganze ins
> STM32CubeIDE reinbekomme, dein STM32-Beispiel ist PlatformIO und auch
> noch Arduino, sollte aber kein Riesenproblem sein.

Ich habe auch ein PlatformIO Projekt das querbeet für mehrere STM32 
compiliert, so ohne Arduino.
Nur bin ich da noch nicht weiter gekommen das wirklich mit einer 
lauffähigen main.c zu versehen.

>> Ja, genau, Details, der Touch-Controller taucht in den Bridgetek
>> Unterlagen erstmal nicht auf.
>> Eine Mail hatte ich auch geschickt, aber praktisch keine Antworten
>> erhalten.
>
> Wundert mich nicht bei Bridgetek.

Nee, Riverdi habe ich gefragt, die haben den CTP schliesslich
mit dem Display verheiratet.

> "CTP is directly connected to EVE chip. You can read coordinates by EVE,
> but generally You use widgets and for example You make tag on button and
> read tag or check event. "

Super, die Frage ist doch ob man was dafür machen muss damit der CTP und 
EVE sich überhaupt verstehen, und wenn ja, was denn.

Matrix Orbital nutzt ja zum Beispiel gerne die GT911, dafür muss man die 
FT813 patchen und die BT815 konfigurieren.

>> Die Kalibrierung macht man ja weil so ein Touchsreen einen Versatz zum
>> Display haben kann und zudem noch gedreht sein kann.
>
> Aaaaha, muss ich mir merken. Riverdi meinte dazu:
> "Calibration is only to fullfill EVE calibration matrix.
> EVE4 - no need calibration, because CTP has the same resolution as LCD.
> EVE3 has different CTP, so it needs to be calibrated.
> It’s one command – touching 3 point.
> You can make calibration once, read calibration matrix
> REG_TOUCH_TRANSFORM_A-F  and save it, then use for all devices. "

Also manchmal frage ich mich ob sich da jemand mit beschäftigt der sich 
da wirklich auskennt.
Es könnte sein das die Touch-Matrix anders in das Display integriert 
ist, so das es keinen Versatz oder Drehung geben kann.
Das wäre aber nicht das gleiche wie das der Touch die gleiche Auflösung 
wie das Panel hat.

Auf den Produkt-Seiten bei Riverdi findet sich aktuell auch zum Beispiel 
sowas:
2x Pixel Mode
Another feature implemented to EVE4 graphics controller for the first 
time is ‘2x pixel mode’. In this mode, picture is being refreshed 
simultaneously on two independent halves of the display which shortens 
the process by half and makes rapid changes of the image displayed super 
smooth.

Davon liest man im Programming Manual nur nichts, ich wüsste auch gar 
nicht wie sowas überhaupt möglich sein sollte, so mit einem Satz 
Leitungen zum Panel und einem Controller auf dem Panel.

REG_PCLK_2X Definition
Bit 0: graphics engine outputs 1 or 2 pixels per PCLK.
0 means 1 pixel per clock,
1 means 2 pixel per clock.
Core scan out 2 pixel data per system clock

>> Dazu lese ich jetzt REG_TOUCH_RAW_XY zusätzlich ein und reagiere auf den
>> Tag 0x00 nur noch wenn REG_TOUCH_RAW_XY == 0xffffffff.
>> Damit kann ich mit dem Finger über das ganze Display streichen,
>> ausgelöst wird dann nur das Event für das erste Objekt das ich treffe.
>
> Genau sowas meine ich! Aber das ist wahrscheinlich (noch) nicht in
> deiner EVE-Lib drin, oder?

Das ist Anwendungs-Ebene, damit hat die Lib selber erstmal nichts zu 
tun.
Und von daher funktioniert das schon.

In der tft.c aus meinem Beispiel habe ich in der TFT_touch() ja 
zumindest schon einen einfachen toggle-lock für den Button mit drin.
Der wird mit dem Button gesetzt und mit dem Tag 0 wieder gelöscht.
Erweitert habe ich das jetzt nur so das REG_TOUCH_RAW_XY == 0xffffffff 
damit das toggle_lock = 0; ausgeführt wird.
So reicht dann ein drücken-halten-wegwischen nicht mehr, man muss auch 
los lassen, bevor der Button neu betätigt werden kann.
Hmm ja, vielleicht erweitere ich einfach mal das Beispiel entsprechend.

[Anguel S. (anguel)]

Rudolph schrieb:

> Nur kann ich mit STM32 einfach beruflich nichts anfangen, da es die
> nicht in Automotive qualifiziert gibt.

Ach daher kommt deine Affinität zu CAN-FD :-) Ich mache zwar nix mit 
Automotive aber CAN-FD ist schon eine tolle Sache. Verbinde jetzt auch 
einige Boards damit untereinander.

> Ich habe auch was vor mit dem STM32H7Bxxx, das kann ich momentan nur
> nicht mal anfangen, weil ich die Dinger einfach nicht in die Finger
> bekomme.
> ST hat scheinbar gerade etwas Probleme den Markt zu bedienen.

Die Nucleo-Boards für STM32G4 gab es letztens noch, bei den größeren MCU 
sieht es wahrscheinl. anders aus. Ansonsten habe ich mich jetzt erstmal 
auf STM32 HAL festgelegt, in den neuen Versionen scheint es in 
Verbindung mit CubeMX gar nicht so schlecht zu laufen. Ok, vielleicht 
nicht so performant, aber dafür ist es einfach neue Sachen zu 
implementieren, auch CAN-FD.

> Super, die Frage ist doch ob man was dafür machen muss damit der CTP und
> EVE sich überhaupt verstehen, und wenn ja, was denn.

Das war eigentlich auch meine Frage, aber da diese Antwort kam und ich 
mich mit dem Thema noch nicht auskenne, bin ich davon ausgegangen, dass 
es auf Anhieb laufen sollte.

> Also manchmal frage ich mich ob sich da jemand mit beschäftigt der sich
> da wirklich auskennt.

Puh, bei einer polnischen Firma hatte ich das zumindest gehofft. Das 
wäre doch wieder ein Ding, wenn Riverdi so komplexe Hardware entwirft 
und nicht mal klar ist, ob alles zusammen funktioniert...

> In der tft.c aus meinem Beispiel habe ich in der TFT_touch() ja
> zumindest schon einen einfachen toggle-lock für den Button mit drin.
> Der wird mit dem Button gesetzt und mit dem Tag 0 wieder gelöscht.
> Erweitert habe ich das jetzt nur so das REG_TOUCH_RAW_XY == 0xffffffff
> damit das toggle_lock = 0; ausgeführt wird.
> So reicht dann ein drücken-halten-wegwischen nicht mehr, man muss auch
> los lassen, bevor der Button neu betätigt werden kann.
> Hmm ja, vielleicht erweitere ich einfach mal das Beispiel entsprechend.

Super, ich schaue es mir auf jeden Fall genauer an.

Da ich kein Display habe, schaufele ich momentan Visual Studio 2019 
Community auf die SSD, damit ich mal den Emulator antesten kann. So 
wirklich klare Doku dazu habe ich irgendwie auch nicht gefunden. Mal 
sehen, ob es nach Gefühl klappt ;-)

[Rudolph (Gast)]

Anguel S. schrieb:
> Die Nucleo-Boards für STM32G4 gab es letztens noch,

Ich möchte eine Platine designen, das bringt nur nichts wenn es die 
Teile nicht gibt.
Ein Nucleo gibt es für den Stein auch nicht.

>> Also manchmal frage ich mich ob sich da jemand mit beschäftigt der sich
>> da wirklich auskennt.
>
> Puh, bei einer polnischen Firma hatte ich das zumindest gehofft. Das
> wäre doch wieder ein Ding, wenn Riverdi so komplexe Hardware entwirft
> und nicht mal klar ist, ob alles zusammen funktioniert...

Oh, das habe ich nicht gemeint, ich meinte im Support und Marketing.
Ich glaube denen schon, dass die Module laufen.

[Rudolph R. (rudolph)]

Ich habe gerade mal in meine platformio.ini ein paar Zeilen zusätzlich 
geworfen:

[env:STM32G474]
board = nucleo_g474re
build_flags = -D STM32G4

Und beim bauen hat sich PlatformIO einfach das nächste Paket gezogen. 
:-)

Environment    Status    Duration
-------------  --------  ------------
STM32L073      SUCCESS   00:00:07.293
STM32F030      SUCCESS   00:00:06.566
STM32F103      SUCCESS   00:00:06.966
STM32F303      SUCCESS   00:00:08.502
STM32F446      SUCCESS   00:00:11.042
STM32G474      SUCCESS   00:00:10.078

In der 
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target.h
steckt ein Block für STM32 und STM32cube.

Das compiliert zwar so, also im Grunde genommen, das funktioniert dann 
nur noch nicht, weil in der main.c und in der EVE_target.c bisher nur 
ein bischen was spezifisch für den STM32F446 drin ist.

Das taugt noch lange nicht als Beispiel, aber ich nutze STM32 dann ja 
eben auch bisher nicht wirklich.

Ich würde übrigens gerne eine Platine mit einem STM32H7B0RBT6 bauen.
Es gibt da draußen nur keine.

[Anguel S. (anguel)]

Rudolph R. schrieb:

> STM32G474      SUCCESS   00:00:10.078
Cool! Sowas nenne ich Cross-Platform, nicht das was Bridgetek versucht 
:-)
Woher wusstest du, dass ich den G474 habe? ;-)

> In der
> https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target.h
> steckt ein Block für STM32 und STM32cube.
Du meinst wahrscheinlich eher die EVE_target.c, oder?
Normalerweise konfiguriere ich alles schön im CubeMX und der erzeugt 
dann die Konfig-Dateien die man als nette Option separat von der main() 
ausgeben kann. In der main() hat man dann nur noch ein MX_SPI2_Init() 
oder so ähnlich, das macht es noch leichter an andere STM32 anpassbar, 
wegen Pins und so. Nur so als Idee.

> Das taugt noch lange nicht als Beispiel, aber ich nutze STM32 dann ja
> eben auch bisher nicht wirklich.
Mir wurde es ganz gut klar, das einzig verwirrende war vielleicht, dass 
es ein Arduino-Projekt ist.

> Ich würde übrigens gerne eine Platine mit einem STM32H7B0RBT6 bauen.
> Es gibt da draußen nur keine.
Hmmm, ich hab nur ganz kurz geschaut, aber ich hatte damals das Gefühl, 
dass die keine Crypto-Chips in Nucleo-Boards u.ä. verbauen, evtl. wegen 
Gesetz und so, kann mich aber auch stark täuschen.

Habe jetzt übrigens den EVE-Emulator angeschmissen. Ist ganz nett, 
spielt sogar die Sounds ab. Der lässt sich bestimmt an deine Lib 
anpassen, eigentlich müsstest du nur den MCU-spezifischen Teil 
abgreifen, da ich aber zugegebenermaßen nicht soo erfahren bin, war es 
mir beim durchschauen doch etwas zu unübersichtlich, was da genau auf 
unterster Ebene passiert.
Ansonsten sind das die Platform-Demos, die auch für den Emulator 
konfiguriert sind:
https://brtchip.com/wp-content/uploads/2021/02/EveApps.v1.2-rc3.zip
und das ist der zugehörige Platform-Guide, wo alles beschrieben ist:
http://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_391-EVE-Platform-Guide.pdf

[Rudolph R. (rudolph)]

Anguel S. schrieb:
>> STM32G474      SUCCESS   00:00:10.078
> Cool! Sowas nenne ich Cross-Platform, nicht das was Bridgetek versucht
> :-)

Naja, das ist jetzt weniger mein Verdienst, als der von ST mit ihrer HAL 
Library und PlatformIO.

> Woher wusstest du, dass ich den G474 habe? ;-)

Ich habe einfach nur in PlatformIO nach einem unterstütztem Nucleo Board 
gesucht.
Man kann zwar auch Boards in PlatformIO hinzufügen, aber man muss sich 
das Leben für sowas ja nicht unnötig schwer machen. :-)

>> In der
>> https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target.h
>> steckt ein Block für STM32 und STM32cube.
> Du meinst wahrscheinlich eher die EVE_target.c, oder?

Jain, die Kernfunktionen sind als static Inline in der EVE_target.h zu 
finden, zusätzliche Funktionen wie für DMA habe ich in der EVE_target.c.

> Normalerweise konfiguriere ich alles schön im CubeMX und der erzeugt
> dann die Konfig-Dateien die man als nette Option separat von der main()
> ausgeben kann. In der main() hat man dann nur noch ein MX_SPI2_Init()
> oder so ähnlich, das macht es noch leichter an andere STM32 anpassbar,
> wegen Pins und so. Nur so als Idee.

Wenn ich primär mit STM32 arbeiten würde, würde ich das auch so machen, 
oder so ähnlich. :-)

>> Das taugt noch lange nicht als Beispiel, aber ich nutze STM32 dann ja
>> eben auch bisher nicht wirklich.
> Mir wurde es ganz gut klar, das einzig verwirrende war vielleicht, dass
> es ein Arduino-Projekt ist.

Arduino ist eben perfekt für sowas,

Das Beispiel baut mal eben Querbeet für diversen Plattformen:
uno                        SUCCESS   00:00:07.905
avr_pro                    SUCCESS   00:00:03.838
nano328                    SUCCESS   00:00:03.425
adafruit_metro_m4          SUCCESS   00:00:20.071
samd21_m0-mini             SUCCESS   00:00:07.731
ESP32                      SUCCESS   00:00:14.852
ESP8266_d1_mini            SUCCESS   00:00:11.784
nucleo_f446re              SUCCESS   00:00:21.354
teensys41                  SUCCESS   00:00:10.126
adafruit_feather_nrf52840  SUCCESS   00:00:15.965

Für den Metro-M4, den ESP32, das Nucleo 446 und den Teensy
ist dann aber noch jeweils spezieller Code in der EVE_target.c der SPI 
per DMA erlaubt.

Ich bin jetzt nicht wirklich ein Fan von Arduino im allgemeinen, aber 
für das Beispiel nimmt mir das erstmal alles ab was 
Controller-spezifisch ist.
Ich muss mich nicht mit so lästigen Dingen herum schlagen wie man den 
Takt konfiguriert, Timer und so, aber man kann an den Arduino Klassen 
vorbei gehen.
Mein AVR Code geht einfach mal direkt auf die Hardware für den SPI, das 
Nucleo 446 nutzt HAL, ESP32 den ESP-IDF Treiber.

Um mit dem STM32 Beispiel das gleiche zu erreichen bräuchte ich für dann 
für jeden Controller wieder speziellen Code.

>> Ich würde übrigens gerne eine Platine mit einem STM32H7B0RBT6 bauen.
>> Es gibt da draußen nur keine.
> Hmmm, ich hab nur ganz kurz geschaut, aber ich hatte damals das Gefühl,
> dass die keine Crypto-Chips in Nucleo-Boards u.ä. verbauen, evtl. wegen
> Gesetz und so, kann mich aber auch stark täuschen.

Also der ATSAME51 hat auch ein AES Modul, den bestelle ich einfach so 
bei DigiKey.
ST hat ja auch dickere H7 im Sortiment für die es auch kaufbare 
Nucleo-144 Boards gibt.
Der STM32H7B0RBT6 steht bei ST auf "active", dennoch gibt es nur einen 
Distributor bei dem ich ein Paket mit 960 Stück kaufen könnte.
Ich muss noch mal ein paar Vergleichen, eventuell hat der noch einen 
großen Bruder, leider ist das bei ST auf der Webseite etwas 
unübersichtlich und zum Teil auch falsch.

> Habe jetzt übrigens den EVE-Emulator angeschmissen.

Hmm, okay. :-)
Wenn ich mal ganz kurz was ausprobieren möchte dann werfe ich den EVE 
Screen Editor an, mit dem kann man auch sehen was der aus den Befehlen 
so macht.
Ansonsten liegen hier genug Displays zum Ausprobieren. :-)

[Anguel S. (anguel)]

Rudolph R. schrieb:.
> Ich muss noch mal ein paar Vergleichen, eventuell hat der noch einen
> großen Bruder, leider ist das bei ST auf der Webseite etwas
> unübersichtlich und zum Teil auch falsch.

Im Datenblatt ist ein Vergleich mit ähnlichen Modellen:
https://www.st.com/resource/en/datasheet/stm32h7b0rb.pdf

Sonst haben die spezielle Software zum MCU Vergleich:
https://www.st.com/en/development-tools/st-mcu-finder.html

Oder du lädst dir die STM32CubeIDE, dann kannst du den im CubeMX sogar 
per GUI fertigkonfigurieren und schauen ob du dann alle nötigen Module, 
Pins, Clocks so nutzen kannst ;-)

[Rudolph R. (rudolph)]

Stimmt, an das STM32CubeMX hatte ich nicht gedacht.

Es gibt noch drei, zumindest auf dem Papier.
Die stehen alle auf "Active" und "Product is in mass production".
Nur kann nicht mal ST einen Distributor dafür nennen.
Der STM32H7B0RBT6 ist dabei der kleinste mit "nur" 128k FLASH.

Tja nun, dann eben nicht, vielleicht später mal.

[Daniel S. (snipod)]

Hi Rudolph,
ich habe noch mal eine Frage:
Ich teste gerade mein Custom PCB mit meinem Custom Display.
Ich habe nen BT815Q drauf und das CTP arbeitet mit einem GT911.
Touch funktioniert soweit gut, nur wenn ich den extended Mode für 
Multitouch aktiviere, geht touch nicht mehr.
Interessanterweise freezed der Bildschirm dann im kalibrieren sogar, 
also im Kalibrierbildschirm "flashen" die Punkte nicht mehr.

Deaktiviere ich den Extended Mode wieder, geht alles...

Hast Du / jemand eine Idee?

Viele Grüße

[Rudolph (Gast)]

Ich kann gerade nicht nachsehen oder das zitieren, aber ich meine 
Kalibrieren geht nicht im Extended Mode.
Also erst Kalibrieren, bzw. die kalibrier-Werte schreiben, dann 
umschalten.

[Rudolph R. (rudolph)]

Kapitel 3.4.4 Capacitive Touch Engine, Seite 40:
"Note: The calibration process of the touch screen should only be 
performed in compatibility mode."

[Daniel S. (snipod)]

Perfekt, hat so geklappt... Dummer Fehler :)

Vielen Dank

[Bernd (Gast)]

Hallo Rudi,
ich bin's mal nach langer Zeit wieder - Bernd. Do You remember..?
Ganz banale Frage zum FT813: Bei den C-Tatch-Displays gibt es 
gravierende Unterschiede bei der Berührungsempfindlichkeit.
Während man beim Resistive mit REG_TOUCH_RZTHRESH die Empfindlichkeit 
einstellen kann, habe ich einfach nichts dergleichen zum C-Touch 
("REG_TOUCH_CZTHRESH" z.B.) finden können.
Ich arbeite im Kompatibilitätsmodus (als nur 1 Touch)...
Gibt es irgendwie die Möglichkeit, dass zu beeinflussen???

[Bernd (Gast)]

Noch was dazu:
Damit Du mich nicht falsch verstehst: Bei manchen Displays muss man 
regelrecht "raufdrücken", damit es reagiert (das ist weniger das 
Problem), bei anderen berührt man hauchzart das Glas und es reagiert. 
DAS ist das Problem, weil, wenn man dann stärker Drückt, ist der Touch 
wieder weg. Heißt: Eine Taste, die ich betätige, soll ja nur EINMAL als 
betätigt eingestuft werden, so lange bis ich sie wieder loslasse. Aber 
trotz halten, wird dann schon je nach dem, wie stark man hält, ein 2. 
Touch gewertet (ungünstig z.B. bei einer Code-Tastatur).

Ich habe nun schon das "Warten auf Loslassen" (Register 
REG_CTOUCH_TOUCH_XY muss statt 1x nun 100 mal in 1ms Abstand 
hintereinander je $80 sein) entsprechend verändert. Ist zwar besser - 
klar, aber hält man doch noch etwas länger, statt nur kurz zu tippen, 
kommt es trotzdem noch immer mal zur 2. Reaktion. Ist doch blöd!!!
Bernd

[Rudolph R. (rudolph)]

Hmmm, interessant.
Mit Cap-Touch hatte ich bisher überhaupt keine Probleme, alle Displays 
die ich bisher benutzt habe reagieren auf eine leichte Berührung und das 
die bei stärker drücken den Touch verlieren ist mir weder bisher 
aufgefalen, oder den Kollegen, noch kann ich das gerade nachvollziehen.

Die EVE3 die ich gerade verwende benutzen ja GT911, kein Problem.
Gegenüber resistive touch lief das bisher einfach immer stressfrei, 
bestenfalls musste ich mal die Kalibrierung verfeinern.

Ich habe mal nachgesehen und es gibt wohl wirklich keine Register dafür 
die Empfindlichkeit einzustellen oder was anders zu konfigurieren.
Unter den ganzen undokumentierten Registern für die mal ein Name 
durchgerutscht ist habe ich auch gerade nichts gefunden.

Datenblätter zu Touch Controllern zu finden ist allerdings eine 
Herausforderung.
Was man so findet ist uralt, unvollständig und geleaked.

Wenn da was geht müsste man vermutlich den Touch-Controller Code patchen 
und den Touch-Controller noch mal resetten.

Interessant in der Richtung ist noch der "Custom Touch Firmware 
compiler" im EVE Asset Builder für die BT817/BT818.
Bisher habe ich das allerdings noch nicht zum Laufen gebracht.
Aber dann gibt es auch sowieso noch einen erheblichen Mangel an real 
existierenden BT817 Modulen.

[Bernd Ickert (Gast)]

4 Wochen habe ich nahezu täglich an einem Projekt mit dem C-Touch 
gesessen und dabei ein "frei fliegendes" Display mit Cover-Lens benutzt. 
NUN habe ich das fertige Gerät mit einem in einem Kunststoff-Gehäuse 
eingebauten Display (gleiche Bauart, aber mit Glas so groß wie Display, 
nicht überstehend) testen wollen. Außerdem befindet sich über dem 
Display-Ausschnitt ein 0,5mm starker Metall-Blendrahmen, der quasi die 
Display-Oberfläche am technischen Rand berührt. Berührungen des 
Metallrahmens lösen bereits einen Touch aus!
Messungen zeigen, dass das Metallgehäuse des Display nicht auf GND 
liegt! Ein aufgeklebtes Stück Massekabel (mit Tape) verbessert die 
Situation nicht wirklich und hält auch nicht so richtig bzw. gibt keinen 
stabilen Kontakt. Auflöten kann man ja wohl kaum ein Kabel an das 
Display-Gehäuse !!!! Auch Masse auf dem Blendrahmen bringt nicht so viel 
Besserung.

Ich meinte mal IRGENDWANN und IRGENDWO gelesen gehabt zu haben, dass die 
Empfindlichkeit an die Glasstärke angepasst werden kann (z.B. 2mm Glas 
noch drüber...). Kann aber auch im Zusammenhang mit einem ganz anderen 
Berührungs-Taster gewesen sein...!!!???
Na Danke, dass Du mir bestätigen konntest, dass es beim FT813 den 
Parameter eben nicht gibt!

[Rudolph (Gast)]

Also sowas ist schon böse, Metall sollte man wohl generell um das 
Display herum vermeiden.
Aber was weiß ich schon, ich habe keine Erfahrung mit richtigen 
Produkten, ich verwende die fertigen Module mit dem Glas davor vom 
Hersteller und meine Gehäuse sind aus dem 3D-Drucker.
Meine Stückzahlen sind sehr überschaubar.

Auf jeden Fall habe ich gestern in der BRT Community die Frage 
abgeworfen ob und wie man den Touch-Controller konfigurieren kann.

In Deinem Fall ist es vielleicht besser den Touch-Controller an den 
Host-Controller zu hängen, so zum selber konfigurieren.
Man kann dem FT81x ja auch Touch-Events per SPI schicken.
Gemacht habe ich das allerdings noch nicht.

[Rudolph R. (rudolph)]

Anyone around with a Teensy 4.1?
I would like to know if the Teensy 4.1 target that I added a little 
while ago actually works, especially the DMA support for it.

There already is an entry for it in the platformio.ini of the Arduino 
example project:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO

[Rudolph R. (rudolph)]

I am in the process of adding the profiles for the Riverdi EVE4 display 
to EVE_config.h.

But the data is not that reliable so far with all the datasheets still 
in beta and although I ordered one it won't be here anytime soon.

So, does anyone already have one of these already?

[Rudolph R. (rudolph)]

Okay, I added profiles for all the EVE4 modules from Riverdi, from 3.5" 
to 10.1".
If you can test it, please do so and give me a note if anything fails.

[Johannes (Gast)]

Hat schonmal jemand vesucht auf dem statischen Background zwei 
Farbverläufe (CMD_Gradient) untereinander/nebeneinander darzustellen? 
Laut FTDI-Datenblatt soll man die Scissor-Funktion verwenden können. 
Wenn ich per Scissor die obere Hälfte des Displays mit einem Farbverlauf 
und die untere Hälfte des Displays ebenfalls mit Scissor mit einem 
zweiten Farbverlauf belege, kommt es zu dem Effekt, dass manche Widgets 
auf dem zuerst gezeichneten Farbverlauf verschwinden. Texte, Slider und 
Progress werden auf beiden Farbverläufen angezeigt, Buttons aber zum 
Beispiel nicht mehr, wenn sie auf dem zuerst gezeichneten Bereich 
liegen.

Gibt es dafür Workarounds?

[Rudolph R. (rudolph)]

Es ist nicht so als ob ich sowas schon mal gemacht hätte. :-)
Aber ich habe gerade mal ein wenig mit dem EVE Screen Editor gespielt 
und bin darauf gekommen, dass ein "RESTORE_CONTEXT" hilft:

Kopier das  mal in den ESE:
CLEAR(1, 1, 1)
SCISSOR_XY(0, 0)
SCISSOR_SIZE(800, 240)
CMD_GRADIENT(0, 0, 0x00AAFF, 800, 200, 0xFFFF00)
SCISSOR_XY(0, 240)
SCISSOR_SIZE(800, 240)
CMD_GRADIENT(0, 240, 0xcc00FF, 0, 480, 0x00FF00)
RESTORE_CONTEXT
CMD_BUTTON(139, 132, 120, 36, 27, 0, "Button")
CMD_BUTTON(115, 287, 120, 36, 27, 0, "Button")
CMD_SCROLLBAR(325, 153, 16, 160, 0, 120, 60, 480)
CMD_TOGGLE(435, 188, 40, 27, 0, 0, "on\xFFoff")

Man muss ja eigentlich nur die "Scissors" wieder los werden.

[Rudolph R. (rudolph)]

I finally got around trying out the target for the RP2040 on the 
Raspberry Pi Pico - no DMA yet but seems to be doing just fine. :-)

This is done as a baremetal target in PlatformIO using 
https://github.com/Wiz-IO/framework-wizio-pico

[Rudolph R. (rudolph)]

And the RP2040 target works with DMA now. :-)
This brings down "Time1" to 15µs.

[c-hater (Gast)]

Rudolph R. schrieb:

> And the RP2040 target works with DMA now. :-)
> This brings down "Time1" to 15µs.

Sehr schön. Ich spiele privat auch gerade mit dem Pico rum, allerdings 
nicht in Kombination mit den BT81x-Displays, sondern mit einem simplen 
parallelen RGB-LCD (960x160), sprich: ich baue an einem Framebuffer mit 
12bit-Pixeln. Aber das nur nebenbei.

Meine Frage dreht sich schon um die BT81x, konkret um ein Riverdi 
800x480 mit BT816, das ich zum Testen hier habe und an einem 
AVR128DA-Host verwende. Da bin ich an ganz anderer Stelle (also nicht 
bei der Hostkommunikation, auf du dich offensichtlich fokussierst) auf 
ein Bandbreitenproblem gestoßen.

Also, ich habe eine funktionierende Testanwendung, in der dein fast 
unveränderter EVE-Code verwendet wird (nur Anpassung an den AVR128DA und 
Unterstützung für AVR-Host-Flash >64kB) und auch noch kleine Teile aus 
deiner Demo, eigentlich nur noch das Performance-Display.
Meine Testanwendung (Slideshow mit animiertem Logo und teiltransparentem 
Framewindow) ist sehr einfach gestrickt, im Prinzip benutzt sie neben 
den kleinen Resten aus deiner Demo ausschließlich vier Bilder, die sich 
im Flash des Riverdi-Boards befinden. Diese Bilder werden direkt aus dem 
Flash gerendert. Das funktioniert auch wunderbar, so lange die Qualität 
der Bilder hinreichend gering ist oder halt nicht alle davon 
gleichzeitig benutzt werden. Ansonsten fängt's an zu "Ruckeln", je nach 
benötigter Bandbreite mehr oder weniger.

Die Ruckelgrenze für die Summe der komprimierten Datenströme der Bilder 
liegt irgendwo knapp unter 180Mbit/s, so weit habe ich das mit meiner 
Testanwendung schon "ausgeklingelt".
Das Problem ist: Dieser Wert liegt ganz erheblich unter dem, was ich 
erwartet hätte (die Bandbreite der Flashanbindung des BT816 sollte bei 
deutlich über 280Mbit/s liegen, bei QSPI mit 72MHz). Eine andere 
Beschränkung ist nirgendwo dokumentiert.

Hast du irgendwelche Hinweise? Also insbesondere auf irgendwas von mir 
in der Doku übersehenes?

[Rudolph R. (rudolph)]

Mit den Riverdi Displays habe ich das noch nicht probiert,
hatte ich mir eigentlich noch vorgenommen.

Aber ja, die Bandbreite ist begrenzt und der Takt mit dem das QSPI flash 
betrieben wird liegt wohl beim halben Systemtakt, also 36MHz.
Dazu kommt aber noch, dass die tatsächlich erreichbare Bandbreite 
scheinbar vom verwendeten Speicher und vom Layout der Platine abhängig 
sind.
Ich habe Platinen von unterschiedlichen Herstellern die sich bei etwas 
höherer Ausnutzung des externen Speichers unterschiedlich verhalten.
Mit dem Speed-Test im ProgFlash Tool kommen ich über diverse Chips mit 
dem EVE3-43G von Matrix Orbital nur so auf 10MB/s.
Ich weiß jetzt allerdings auch nicht genau was der Test eigentlich 
macht.

Wobei diese Platine im Vergleich zu zwei anderen von anderen Herstellern 
dabei noch am besten funktioniert.

Ein etwas fieserer Test ist ein Bild von 256x256 aus dem Flash 
anzuzeigen und dabei zu drehen.

Ich bin schon echt gespannt wie das mit einem EVE4 Display von Riverdi 
bei 1280x600 laufen wird.
Nach den bisherigen Erfahrungen mit dem BT817 braucht man das SRAM 
durchaus noch und solle das Flash eher dezent einsetzen.
Ein fetter UTF-8 Font im Flash ist schon toll, ab 40 Punkten oder so 
sollte man dann aber besser den Fontcache einschalten wenn man viel Text 
hat.

c-hater schrieb:
> nur Anpassung an den AVR128DA

Also grundsätzlich interessiert mich das ja schon, die letzten Monate 
habe ich ja vor allem bei den unterstützten Targets aufgerüstet.

Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar, 
der ist praktisch ein ATSAMC20 mit halbem Takt, halbem Speicher und AVR 
Kern.
Das Argument das wäre ein AVR zieht irgenwie auch nicht wenn die 
Software ganz anders aussieht und man sich trotzdem neu einarbeiten 
muss.

Nun ja, den RP2040 habe ich nach erfolgreicher "Portierung" auch erstmal 
wieder zur Seite gelegt, mit dem kann ich auch nicht wirklich was 
anfangen.
Und nach einem tieferen Blick in das SDK bin ich eher enttäuscht, dabei 
habe ich nur an der Oberfläche gekratzt.

c-hater schrieb:
> Unterstützung für AVR-Host-Flash >64kB)

Also grundsätzlich ist das drin:

static inline uint8_t fetch_flash_byte(const uint8_t *data)
{
#if defined (__AVR_HAVE_ELPM__)  /* we have an AVR with more than 64kB FLASH memory */
return(pgm_read_byte_far(data));
#else
return(pgm_read_byte_near(data));
#endif
}

Zum Beispiel mit dem AT90CAN128 habe ich das auch schon benutzt.
Und das fetch_flash_byte() müsste auch das einzige sein das überhaupt 
angepasst werden müsste wenn der AVR128DA das anders macht als die alten 
AVRs.

[Johannes (Gast)]

@Rudolph: Du hattest am Anfang des Thread mal geschrieben, dir wäre noch 
keine wirkliche Lösung für das Umlaut-Probleme der Werks-Fonts 
eingefallen. Hast du zwischenzeitlich mal irgendeinen Workaround 
gesehen, oder gibt es eine vernünftige Lösung? Die User-Fonts sind je 
ebenfalls auf 128 Zeichen begrenzt.

Ich arbeit mit FT812 an NHD 7" 480x800 mit SAMC21.

Gruß,
Johannes

[Rudolph R. (rudolph)]

Nein, zu Fonts mit den FT81x habe ich keine richtige Lösung.
Konvertieren in Bilder geht und macht auch schon mal die Display-Liste 
schlanker, ist aber aufwendig und unflexibel.

Zum Glück können wir aber seitdem es die BT81x gibt UTF-8 Fonts 
verwenden.
Das ist jetzt auch etwas aufwendig die Fonts zu konvertieren, vor allem 
muss man schon mal mit der Größe spielen.
Aber wenn man da durch ist macht das Spaß, mein Editor steht auf UTF-8 
und somit kann ich das einfach so eintippen.

Also von daher würde ich empfehlen auf einen BT815 zu wechseln.
Ja, und ich würde ganz stark empfehlen von Resistiv-Touch auf 
Kapazitiv-Touch zu wechseln.
Ich weiß aber auch, Newhaven hat keine BT81x.
Von dem was aktuell tatsächlich direkt zu bekommen wäre würde ich ein 
EVE3-70G von Matrix Orbital kaufen.

Was ich hoffe irgendwann mal in die Finger bekommen zu können wäre ein 
EVE4x-101G-IPS.
Oder von Riverdi ein RVT70HSBNWC00-B oder ein RVT101HVBNWC00-B.
In USA würde ich nach Crystalfontz schauen.
Die neuen von Riverdi sind alle in IPS, bei den "-B" Modellen bekommt 
man auch noch Optical Bonding oben drauf.
Nur hapert das da etwas an der Verfügbarkeit.

TME listet zwar zum Beispiel die neuen Riverdi Displays schon, die haben 
nach der Webseite aber noch nicht mal bestellt und die Lieferzeit wird 
mit 16 Wochen angegeben - ich hoffe doch das ändert sich vor dem Sommer 
noch.

[Spyy (Gast)]

Hi Rudolph,

ich habe in Deinem code gesehen das Du in EVE_Init schreibst:
if EVE_GEN > 2
  EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
#endif

Wieso 46Hex? Ich bekomme dann hier ca 34 Mhz statt 72 und im Manual 
steht man soll 24dez für 72Mhz reinschreiben.

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Boah, schock doch nicht so. :-)

EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */

Das ist schon richtig, nur nachdem ich mich gerade durch die ganze 
Dokumentation gewühlt habe nicht so ganz offensichtlich.
Je länger ich da drauf schaue, desto mehr Zweifel bekomme ich, eindeutig 
geht anders. :-)

Mit dem zweiten Byte in der CLKSEL Sequenz legt man den Multiplikator
für die PLL fest.
Bits 0 bis 5 sind für den Multiplikator selber:
0 - default
1 - ungülig, reserviert
2 bis 6 für eine Frequenz von 24MHz (2) bis 72MHz (6) bei 12MHz Takt
7 bis 31 ungültig

Bits 6 und 7 sind die "PLL range"
0 bei Multiplikator 0, 2 oder 3
1 bei Multiplikator 4, 5 oder 6

0x46: 01000110
Also Multiplikator 6 und - wofür auch immer - Bit 6 gesetzt.

Und 34MHz wäre mir zwar schon länger aufgefallen, zum Beispiel könnte 
ich dann nicht alle 20ms eine neue Display-Liste schicken.
Aber ich habe gerade mal den Takt nachgemessen über REG_CLOCK.
Ich lese REG_CLOCK gerade in der Touch-Funktion aus, bilde die Differenz 
zum alten Wert und speicher den Wert.
Damit habe ich aktuell in der Anzeige stehen: 36236x
Die letzte Stelle zappelt, sagen wir mal das ist eine 6.
362365 Takte alle 5ms, also Mal 200 -> 72473000 Takte pro Sekunde

5ms? Wirklich? :-)

Mein Logik-Analyzer meint dazu:
5,0003 ms
5,000375 ms
5,0004 ms
5,000625 ms

[Spyy (Gast)]

uff...ich wollte Dich nicht schocken....:( ;)

Also ich schreibe da ne 24 rein...habe ich aus der Doku...die ist 
wirklich etwas schwierig....was Du schreibst klingt logisch aber
Wenn ich dort 46Hex reinschreibe läuft das bei mir "nur auf 3 
Töppen"..ist irgendwie komisch...Ich lasse mir jede Sekunde die 
Differenz alt/neu des CLOCK Registers ausgeben...da steht dann bei 24 
z.B. 72356841...bei 46 Hex 36854752 oder habe ich da ein Denkfehler?

komisch ist auch der PLL2 wenn ich damit die Framerate des Displays 
anpassen möchte ft81xCmdPclkfreq(42000000L, 0), dann ändert sich die 
Framerate aber das ganze Bild hat ne Farbverschiebung...

Hast Du einen externen Quarz? Ich habe keinen, ist mir auch unklar warum 
das auch ohne geht bzw. warum dann überhaupt einer Vorgesehen ist...

...komisch...

[Spyy (Gast)]

Rudolph R. schrieb:
> Anyone around with a Teensy 4.1?
> I would like to know if the Teensy 4.1 target that I added a little
> while ago actually works, especially the DMA support for it.

ja, ja, ja...;-).ich mache das mit dem Teensy 4.1 leider mit DMA ohne 
Erfolg, habe mir aber nur Teile von Dir angesehen und dann wollte ich 
das selber programmieren und verstehen....

[Rudolph (Gast)]

Wo hast Du die 24 her und wie genau schreibst Du das in den Chip?

Die PLL2 ist etwas seltsam zu benutzen, da habe ich ein wenig dran 
geknobelt bis das so lief wie ich das wollte.
Farbverschiebung habe ich normalerweise nicht. CSPREAD steht auf Null?

Die meisten meiner Module haben einen externen Quarz.
Ein externer Quarz ist auf jeden Fall genauer und stabiler über die 
Temperatur, wie weit das wichtig ist für EVE ist mir aber auch nicht 
ganz klar.

Spyy schrieb:
> ja, ja, ja...;-).ich mache das mit dem Teensy 4.1 leider mit DMA ohne
> Erfolg, habe mir aber nur Teile von Dir angesehen und dann wollte ich
> das selber programmieren und verstehen....

Dagegen habe ich ganz sicher nichts einzuwenden, ich wäre Dir dennoch 
dankbar wenn Du das mal ausprobieren würdest. :-)

[Spyy (Gast)]

Rudolph schrieb:
> Wo hast Du die 24 her und wie genau schreibst Du das in den Chip?

Das habe ich aus dem Manual BT817/8 Advanced Embedded Video Engine 
Datasheet Version 1.1 Kapitel 4.1.5 Host command Seite 15, da steht so 
beiläufig:
2 to 6 times the osc frequency (i.e. 24 to 72MHz with 12MHz oscillator) 
in der Beschreibung für 61h CLKSEL.

Was passiert denn bei Dir wenn Du ne 24 da rein schreibst?

Ähm beim nochmal lesen soll das wahrscheinlich 24Mhz bis 72Mhz für x2 
bis x6 heissen...

[Rudolph (Gast)]

Ich möchte keine 24 mit dem CLKSEL Kommando übergeben, das wäre ein 
ungültiger Wert. :-)

Bleibt die Frage, was machst Du da genau?
Das ist ja ein Host-Kommando und als ich gestern danach gesucht habe 
konnte ich zwar die Empfehlung von Bridgetek finden den Takt für die 
BT81x auf 72MHz zu setzen, aber kein Beispiel wie man das machen soll.
Alles was ich spontan finden konnte waren CLKSEL Kommandos ohne 
Parameter und somit nur für die Default 60MHz.
Damit habe ich gerade nur meinen Code der das so macht.

[Spyy (Gast)]

Ich mache das so:
Serial.println("Waking up EVE chip");// Wake-up FT81x
ft81xPowerDown();  // 1) lower PD#
delay(100);    // 2) hold for 100ms
ft81xPowerUp();    // 3) raise PD#
delay(100);// 4) wait for another 100ms before sending any commands
sendCommand(FT81x_CMD_CLKINT);  //send command "CLKEXT"
delay(20);
//sendCommand(FT81x_CLKSEL); => das würde dann 60 Mhz machen
ft81xCmdParamWrite(FT81x_CLKSEL, 24);  //select the system clock
delay(10);
sendCommand(FT81x_ACTIVE);//send host command "ACTIVE" to wake up
SPI_TO_EVE_FAST;
delay(300);    // Give some time to process
....
mit ft81xCmdParamWrite:
inline void ft81xCmdParamWrite(unsigned char ftCommand, unsigned char 
ftParameter)
{
  EVE_CS_PIN_LOW;    // Set CS# low
  SPI.transfer(ftCommand);// Send command
  SPI.transfer(ftParameter);// Commands consist a parameter
  SPI.transfer(0x00);  // Send last zero byte
  EVE_CS_PIN_HIGH;  // Set CS# high
}

Fragen im BRT Forum ?

[Spyy (Gast)]

Ich muss ja gestehen, dass ich das gesamte EVE board selbst mit Fusion 
360 layoutet habe...aber bei dem Routen vom SPI kann man ja eigentlich 
nicht viel falsch machen. Ich betreibe den zunächst mit 4 Mhz für die 
Init und fahre den dann auf 30 Mhz hoch. Es scheint allerdings so, dass 
ich den drosseln muss, da der EVE cmd fifo damit überlastet wird im 
Zusammenhang mit dem Teensy Takt von 600 Mhz.
Der Teensy hat 600 Mhz und ich habe eine SPI Zykluszeit für ein command 
schreiben (ohne DMA) von ca. 4-6 µs. Wenn ich mir den FIFO Status 
ausgeben lasse sieht man, dass der es nicht schafft die Daten 
wegzuschreiben. Aber vielleicht habe ich da ja auch was falsch 
verstanden. Ich dachte eigentlich der Fifo hat 4096 Bytes kann also ca. 
1000 commands puffern, aber wahrscheinlich fülle ich den voll auf und 
dann kommt der Puffer in Schwierigkeiten....es ist alles ein wenig 
verwirrend...
Wieviel commands/sec schafft EVE denn bei 72 Mhz ?

[Rudolph (Gast)]

Spyy schrieb:
> Ich mache das so:
...

Das sieht jetzt spontan nicht falsch aus.
Ein wenig ineffizient und langsamer als es sein müsste, aber nicht 
falsch.

Spyy schrieb:
> Ich muss ja gestehen, dass ich das gesamte EVE board selbst mit Fusion
> 360 layoutet habe

Mit Fusion 360 kann man Layouts erstellen? Interessant.

Spyy schrieb:
> aber bei dem Routen vom SPI kann man ja eigentlich
> nicht viel falsch machen.

Also 30MHz sind schon ganz schön Analog.
Mit meinen Boards kann ich zwar locker bis über 30MHz schreiben, aber 
schon lange nicht mehr sauber lesen.

Spyy schrieb:
> Ich betreibe den zunächst mit 4 Mhz für die
> Init und fahre den dann auf 30 Mhz hoch. Es scheint allerdings so, dass
> ich den drosseln muss, da der EVE cmd fifo damit überlastet wird im
> Zusammenhang mit dem Teensy Takt von 600 Mhz.

Der Takt an sich überlastet den nicht, da geht auch noch mehr.
Bei Tests hatte ich den Takt auch schon auf 40MHz. Auf MISO kam zwar nur 
noch Unsinn, aber die Anzeige war korrekt.

Spyy schrieb:
> Der Teensy hat 600 Mhz und ich habe eine SPI Zykluszeit für ein command
> schreiben (ohne DMA) von ca. 4-6 µs.

Das sind aber schon lange Kommandos bei 30MHzs, so mit 12+ Bytes.

> Wenn ich mir den FIFO Status ausgeben lasse sieht man,
> dass der es nicht schafft die Daten wegzuschreiben.
> Aber vielleicht habe ich da ja auch was falsch
> verstanden. Ich dachte eigentlich der Fifo hat 4096 Bytes kann also ca.
> 1000 commands puffern, aber wahrscheinlich fülle ich den voll auf und
> dann kommt der Puffer in Schwierigkeiten....es ist alles ein wenig
> verwirrend...

Schreibst Du direkt in RAM_CMD oder über REG_CMDB_WRITE?

> Wieviel commands/sec schafft EVE denn bei 72 Mhz ?

Kommt schwer auf die Kommandos an, an in der Regel deutlich mehr als man 
rein stopfen kann oder muss.
Wenn Du die Kommandos auch ausführen lässt und dann noch den FIFO Status 
zurück liest, dann sollte der FIFO praktisch immer leer sein.

Darüber habe ich schon lange aufgehört mir Sorgen zu machen, einzig wenn 
man mehr als 4k in den FIFO schicken muss, etwa für ein Bild, dann muss 
man auch mal kurz warten bis der FIFO wieder frei ist.
So wie ich das mache ist nicht mal optimal, es wäre gar nicht notwendig 
zu warten bis der FIFO komplett leer ist, ich übertrage Bilder aber 
ohnehin nur beim Start des Programmes einmal.

[Spyy (Gast)]

...hm.... ich glaube ich muss nochmal neu anfangen...:(

[Spyy (Gast)]

Hi,

also Dein Beispiel läuft auf Teensy 4.1 mit und ohne DMA...das ganze 
Bild flackert aber so ca. jede Sekunde mal kurz...als wenn die 
Displaylist irgendwie ein Problem hat...wie es bei meiner Applikation 
auch war, gefühlt wenn die Transfers in den Fifo zu schnell waren...

Sonst sehr cool....

Grüße

[Rudolph R. (rudolph)]

Also das flackern ist nicht normal und mit einmal die Sekunde ist das 
eigentlich nichts was mein Programm machen sollte.
Die Transfers in den FIFO sind nicht so schnell, das sind ja nur 
irgendwas um 200 Byte alle 20ms.
Aber vielleicht ist das was, das mein Programm nicht macht, aber tun 
sollte?

Kann es sein das der Teensy einen Watchdog hat der bedient werden will?
Das würde ich eigentlich außerhalb der loop() erwarten.

Und das ich das mit DMA für den Teensy recht zügig umsetzen konnte lag 
vor allem daran, dass die SPI Klasse für den Teensy 4.1 DMA direkt 
unterstützt.
Das war mit Abstand am Einfachsten.
Leider kennt Arduino kein DMA und so macht das jeder etwas anders.

Sonst ist das aber alles fit? Da wird nicht zum Beispiel irgendwas zu 
heiß?

[Spyy (Gast)]

Ja sonst alles schick, wird nüscht zu heiss bei 600 MHz...mehr habe ich 
noch nicht probiert...

[Rudolph R. (rudolph)]

Hast Du einen Logic-Analyzer?
Eine Möglichkeit wäre ja, dass das Ding durch einen Reset läuft.
Und wenn man einen Logik-Analyzer an CS, SCK und MOSI anschliesst müsste 
man das sehen können.

[Holger H. (sachma)]

@Rudolph
ich möchte mich für die super Library bedanken.

ESP32-S2 240MHz DMA
Display: aus Tablet EMPIRE model K701 (7") 1024x600 50 PIN
EVE4-BT818

Grüße
Holger

[Spyy (Gast)]

Rudolph R. schrieb:
> Hast Du einen Logic-Analyzer?
> Eine Möglichkeit wäre ja, dass das Ding durch einen Reset läuft.
> Und wenn man einen Logik-Analyzer an CS, SCK und MOSI anschliesst müsste
> man das sehen können.

ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte 
Wert gelegt..;-)

Ein Reset bzgl. Watchdog kann ich nicht feststellen...

Ich werde mal ein paar Messungen machen (Register auslesen usw. und 
Anzeigen)
Ich kann aber auch mit meinem Code sehen, wenn ich mit voller 
Geschwindigkeit auf den EVe schreibe schaukelt sich da "ein Berg" auf 
(Ausgabe EVe busy) das heisst er verbringt immer mehr Zeit in der 
while(busy) und auch die SPI zykluszeit steigt in Wellen (schwingt) 
stark an (von 2000µs bis zu 20000µs) für meine gesamte Displayliste. 
Wenn ich dann den SPI ausbremse mit delaymicrosec geht der Wert für SPI 
natürlich hoch aber bleibt konstant und auch der Wert für busy ist dann 
konstant so bei 42µs...

[Rudolph R. (rudolph)]

Holger H. schrieb:
> ich möchte mich für die super Library bedanken.

Danke für das positive Feedback!

Holger H. schrieb:
> ESP32-S2 240MHz DMA
> Display: aus Tablet EMPIRE model K701 (7") 1024x600 50 PIN
> EVE4-BT818

Nettes Upcycling und man sieht zwar nichts von der BT818 Platine,
aber die ist ganz schön klein.

Hat das Display TTL oder LVDS?



Spyy schrieb:
> ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte
> Wert gelegt..;-)

Ich auch nicht, ein paar Drähte gehen immer. :-)

> Ein Reset bzgl. Watchdog kann ich nicht feststellen...

Das ist schon mal was.

Spyy schrieb:
> Ich kann aber auch mit meinem Code sehen, wenn ich mit voller
> Geschwindigkeit auf den EVe schreibe schaukelt sich da "ein Berg" auf
> (Ausgabe EVe busy) das heisst er verbringt immer mehr Zeit in der
> while(busy) und auch die SPI zykluszeit steigt in Wellen (schwingt)
> stark an (von 2000µs bis zu 20000µs) für meine gesamte Displayliste.
> Wenn ich dann den SPI ausbremse mit delaymicrosec geht der Wert für SPI
> natürlich hoch aber bleibt konstant und auch der Wert für busy ist dann
> konstant so bei 42µs...

Sorry, aber das passt rein konzeptionell überhaupt nicht zu EVE.
Wie Du in dem Bild das Holger gerade gepostet hat sehen kannst, übeträgt 
mein einfaches Test-Programm 224 Bytes an Kommandos für einen Refresh.
Die angezeigte Zeit ist mit DMA nur wie lange das dauert den Puffer zu 
füllen, danach braucht es dann noch mal xxx µs bis der Transfer durch 
ist.
Ein Arduino Uno braucht mit 8MHz SPI so ungefähr 500µs pro Bild bei dem 
Test-Programm.
Und dann ist erstmal Sende-Pause auf dem SPI.
Das nächste was in meinem Test-Programm passiert ist das zwei Register 
gelesen werden, das eine für die Länge der Display-Liste, das andere für 
den Touch, das hat Holger offenbar unterbunden, weil das Display keinen 
Touch hat.
Erst 20ms nach dem Refresh wird der nächste auf den Weg gebracht, der 
CMD-FIFO ist dann ganz sicher leer.
Warum erst 20ms später? Weil der Refresh nicht schneller erfolgen darf 
als EVE die Display-Liste abarbeitet und die Displays haben meistens so 
um die 60Hz.
Ein paar liegen drüber, weil das mit den Parametern nicht richtig 
einstellbar ist, EVE3-50G betreibe ich zum Beispiel mit 73Hz da sich der 
BT815 ja nicht fein einstellen lässt.
Das ist mit PCLK = 2 und bei PCLLK = 3 sind es gleich nur noch 49Hz.
Ein älteres 1024x600 mit FT813 kommt gerade so über 30Hz, da muss ich 
dann auch entsprechend den Refresh langsamer einstellen.

Wenn man das jetzt auf den Framewechsel synchronisieren würde, wofür 
auch immer, dann wäre da bei 73Hz trotzdem ein Abstand zwischen den 
Transfers auf dem SPI von 13,7ms und das reicht locker aus um den FIFO 
mehr als einmal voll zu machen für übertrieben viele Kommandos in einer 
Liste.

Oh ja:
https://user-images.githubusercontent.com/31180093/103809372-b42b9a80-5059-11eb-9906-6e049c975d07.png

Das "DL-size: 900" ist die Länge der Display-Liste die der Kommando 
Co-Prozessor aus den 224 Byte Kommandos generiert.
Das muss man im Blick behalten, das dürfen nicht mehr als 8k werden.
Und zum Beispiel 6 CMD_CLOCK füllen die Display-Liste mal eben zu 10%.

[Rudolph R. (rudolph)]

Spyy schrieb:
> ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte
> Wert gelegt..;-)

Wie sieht eigentlich der Schaltplan dazu aus und was für ein Display 
benutzt Du überhaupt?

[Holger H. (sachma)]

Rudolph R. schrieb:

> aber die ist ganz schön klein.
die Platine hat 57x32 mm
und ist nur ein Test ob alles läuft, ich hatte zuerst eine BT817 Version
mit LVDS erstellt, leider konnte ich den LVDS-Umsetzer und auch den 
BT817 nicht bekommen. Den LVDS-Umsetzer habe ich mittlerweile auf den 
BT817 warte ich noch.
Da sitzt dann auch ein Eeprom mit drauf und der cap. Touch ist 
herausgeführt.

> Hat das Display TTL oder LVDS?

TTL - LVDS werde ich hier über eine Zusatzplatine 50PIN TTL-> 40PIN LVDS 
aufbauen, so wie ich es mit der VCOM Platine gemacht habe.

[Rudolph R. (rudolph)]

Schick, das sieht so einfach und aufgeräumt aus.

Irgendwann muss ich sowas vielleicht doch mal machen, einfach um das 
gemacht zu haben, aber so viele Projekt, so wenig Zeit. :-)
Und für QFN kann ich mich dann auch eher nicht so begeistern.

BT817 sind scheinbar etwas knapp im Moment, damit sind die ja nicht 
alleine, der Markt ist insgesamt etwas schwierig.
Ich warte seit 6 Wochen auf ein Display und das wird sich noch weiter 
hin ziehen, ich weiß aber nicht ob der BT817 da das fehlende Teil ist.

[c-hater (Gast)]

Rudolph R. schrieb:

> Aber ja, die Bandbreite ist begrenzt

Dass sie begrenzt sein muss, war natürlich von vorn herein klar. Die 
Frage war bloß, wo diese Grenze liegt. Ich hatte mich da auf das DB 
verlassen, was dazu ausführt (Unter "4.4 SPI NOR Flash Interface"):

The interface will work at system clock speed (up to 72MHz) at 4
bit mode.

Ich meine: das kann man kaum fehlinterpretieren, dazu ist der Satz zu 
kurz und zu einfach gestrickt.

> und der Takt mit dem das QSPI flash
> betrieben wird liegt wohl beim halben Systemtakt, also 36MHz.

Das sehe ich inzwischen genau so. Erstens deshalb, weil es ja irgendwie 
"das Übliche" wäre und zweitens, weil ich es inzwischen ganz praktisch 
noch deutlich genauer ausgeklingelt habe und dabei auf eine Grenze von 
120..128MBit/s für völlige Ruckelfreiheit gekommen bin.

Das liegt prozentual ziemlich genau so viel unter den 144MBit/s, wie ich 
als Sicherheitsabstand zu den ursprünglich angenommenen 288MBit/s aus 
Erfahrung eingeplant hatte...

> Ein etwas fieserer Test ist ein Bild von 256x256 aus dem Flash
> anzuzeigen und dabei zu drehen.

Was soll dieser Test bezüglich der Bandbreite der Flashanbindung 
bringen? Gedreht (u.a.) wird bei mir nur das animierte Logo. Das ist 
allerdings nur 159x159 Pixel groß.
Die beiden Bilder der Slideshow sind jeweils 570x277 und der 
teiltransparente Frame im Vordergrund ist 800x480.

Vollständiges "Abschalten" aller Transformationen für das Logo hat 
übrigens nur eine minimale Änderung gebracht. So klein, dass man sie 
auch getrost als Meßfehler verbuchen kann.

> Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar

Sie haben ihre Nische, glaub' mir. Sonst müsste ich mich nicht damit 
beschäftigen. ;o)

[Spyy (Gast)]

Rudolph R. schrieb:
> Spyy schrieb:
>> ja habe ich, aber in meinem Boardlayout nicht so peinlich auf Messpunkte
>> Wert gelegt..;-)
>
> Wie sieht eigentlich der Schaltplan dazu aus und was für ein Display
> benutzt Du überhaupt?

Also Display ist von BuyDisplay 480x480 Platine siehe Bilder...

EvE ist jetz leider abgeraucht, plötzlich viel Strom gezogen und 
knallheiss...
Wie sieht den Deine VOUTV1 Beschaltung mit Kondensatoren aus?

[Spyy (Gast)]

...Blöd wenn man seinen Beitrag nicht editieren kann...habe ein Foto 
doppelt und Tippfehler...sorry..

[Rudolph R. (rudolph)]

Spyy schrieb:
>> Wie sieht eigentlich der Schaltplan dazu aus und was für ein Display
>> benutzt Du überhaupt?
>
> Also Display ist von BuyDisplay 480x480 Platine siehe Bilder...

Also das beantwortet die Frage nach der Verschaltung jetzt nicht mal 
ansatzweise. :-)
Also vor allem wie der BT81x versorgt ist und wie der SPI vom Teensy zu 
EVE und zurück gelangt wäre mal interessant. :-)

Ich werde zum Beispiel nicht grundlos Logik-Bausteine in der 
Schnittstelle, ich musste erstmal feststellen das die ATSAMC21 bei 3,3V 
nicht genug Strom liefern können um den SPI jenseits von 8MHz stabil 
laufen zu lassen.
Also jetzt vor allem auch mit den zwei Steckverbindern und dem 
Folien-Flex-Kabel dazwischen.

> EvE ist jetz leider abgeraucht, plötzlich viel Strom gezogen und
> knallheiss...

Mist.

> Wie sieht den Deine VOUTV1 Beschaltung mit Kondensatoren aus?

Ich habe ja noch kein Board designed, mir geht vor allem auf den Keks 
das Displays zum einen nicht ganz einfach beschaffbar sind, zum anderen 
jeder Hersteller mehrere Pin-Belegungen und Stecker für seine Modelle 
hat.

Aber wenn ich ein Board designen würde, das Datenblatt ist zwar 
unübersichtlich, aber es gibt wenigstens etwas Beschreibung zu den Pins 
und es gibt auch noch den Schaltplan von dem BT817 Board von Bridgtek.

An Pin 25 würde ich 4,7µF und 100nF packen.
Das ist mit Pin 2 verbunden, der bekommt 1µF und 100nF.
Und dann noch Pin 57, dem würde ich auch 100nF verpassen.
An Pin 2 vielleicht sogar auch 4,7µF, eine Position weniger in der 
Stückliste.

In den Schaltplänen hat Bridgetek sogar 10µF+100nF an Pin 25.

Wenn man mal in den EVE3 Schaltplan von Matrix Orbital schaut, die haben 
sogar nur 4,7µF und einmal 100nF an den drei Pins zusammen.
Und die laufen stabil, an denen stört mich nur die nicht abgetrennte 
Versorgung für die Hintergrund-Beleuchtung.

[Rudolph R. (rudolph)]

c-hater schrieb:
>> Ein etwas fieserer Test ist ein Bild von 256x256 aus dem Flash
>> anzuzeigen und dabei zu drehen.
>
> Was soll dieser Test bezüglich der Bandbreite der Flashanbindung
> bringen?

Damit haben die BT81x auf manchen Platinen ein Problem.
Das liegt wohl daran das der Zugriff auf das Flash dann nicht linear 
erfolgt.

c-hater schrieb:
>> Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar
>
> Sie haben ihre Nische, glaub' mir. Sonst müsste ich mich nicht damit
> beschäftigen. ;o)

Der gefällt Dir okay, viel Spass damit.
Das war aber nicht meine Aussage dazu.

Rudolph R. schrieb:
> Welche Nische der AVR128DA belegen soll ist mir allerdings nicht klar,
> der ist praktisch ein ATSAMC20 mit halbem Takt, halbem Speicher und AVR
> Kern.
> Das Argument das wäre ein AVR zieht irgenwie auch nicht wenn die
> Software ganz anders aussieht und man sich trotzdem neu einarbeiten
> muss.

Das war jetzt kein das-gibt-es-woanders-besser (STM32), der Witz ist 
doch das Microchip schon seit Jahren den ATSAMC20 im Sortiment hat und 
die AVR128DA sehen aus wie eine im Funktionsumfang reduzierte und 
langsamere Variante davon. Unter dem Aspekt scheint der AVR128DA ein 
komplett überflüssiges Produkt zu sein.

Ich finde nur Argumente gegen den AVR128DA, wie zum Beispiel das der 
kein DMA kann, was wäre denn ein Argument für das Teil?

[Spyy (Gast)]

So...Schaltung anbei kann man eigentlich nicht viel falsch machen...
Ich habe 2 Spannungsebenen, 3.3V und den Teensy und das Backlight mit 
5V.

Was hat denn das eigentlich auf sich mit den 1.2V VOUT und den 
Kondensatoren, bei den "älteren" EVEs musste man da ja sogar ein Elco 
ranhängen...

Crystal habe ich komplett weggelassen, ist dann ja einfacher und weniger 
Bauteile. Ich bestücke ja mit SMD selber, dass kann schon mal in Arbeit 
ausarten. Die ganze Anpassung an das Display (Backlight, Pins) habe ich 
auf einer eigenen Platine die dann auf dieses "Mainboard" geklibst wird. 
Und ich habe einfach die Widerstandswerte die in Reihe mit den RGB 
Leitungen geschaltet sind (33Ohm) von der Schaltung von den NewHaven 
Displays übernommen. Gibt es da Auslegungskriterien oder probiert man 
das einfach aus bis das Bild auf dem Oszi vernünftig aussieht ?

Grüße

[c-hater (Gast)]

Rudolph R. schrieb:

> Ich finde nur Argumente gegen den AVR128DA, wie zum Beispiel das der
> kein DMA kann, was wäre denn ein Argument für das Teil?

Die Hauptvorteile sind:
Weiter Bereich der Betriebsspannung (1,8V..5,5V).
Und nicht zu vergessen: der Preis.

Aber ich gebe zu: eine kleine DMA-Einheit wäre schon ganz nett gewesen.

[Rudolph R. (rudolph)]

Ich habe gerade mal in das Datenblatt der IMXRT1060 geschaut und die 
können pro Pin auf der höchsten Einstellung auch nur typisch 4mA 
liefern.
Keine Idee was da von dem Arduino Core eingestellt wird, oder ob 
überhaupt die Default-Einstellung verändert wird, oder was die 
Default-Einstellung wäre.
Aber wenn das wieder läuft könnte es sich lohnen den SPI mal langsamer 
zu machen, 4MHz, 2MHz oder gar 1MHz.

[Rudolph R. (rudolph)]

c-hater schrieb:
> Die Hauptvorteile sind:
> Weiter Bereich der Betriebsspannung (1,8V..5,5V).

OK, da gewinnt der AVR128DA, der ATSAMC20 ist "nur" von 2,7V bis 5,5V 
angegeben.

> Und nicht zu vergessen: der Preis.

Och, das gibt sich nicht viel, vor allem nicht bei kleinen Mengen.
Ein ATSAMC20J18A-AUT liegt bei €2,15, das sind 64 Pins und 256k Flash.
Ein ATSAMC21J18A-AUT der auch noch zwei CAN-FD Kanäle hat liegt bei 
knapp über 3 Euro.
Und das sind auch nur Apothekenpreise, wenn auch ohne Mehrwertsteuer.

Bei den Preisen habe ich bisher nicht mal erwägt die Versionen mit 
weniger Speicher zu verwenden, auch wenn ich mit zum Beispiel den 64k 
Versionen ein paar Cent sparen könnte.
Völlig egal wenn das nicht Serie ist.
Und wenn es Serie ist kauft man die Dinger auch nicht mehr in der 
Apotheke.

[c-hater (Gast)]

Rudolph R. schrieb:

> Och, das gibt sich nicht viel, vor allem nicht bei kleinen Mengen.

Huch? Bei Mouser gibt's den SAM als Einzelstück (Reel-Abschnitt) für 
2,16€. Zzgl. 5€ Strafgebühr für's Abschneiden. Macht satte 7,16€ netto 
total.

Den AVR128DA64 hingegen gibt es als Einzelstück ohne Strafgebühr für 
1,78€. Das ist nicht nur ganz erheblich billiger als das 
SAM-Einzelstück, sondern auch noch in anderer Hinsicht interessant:

Diesen Einzelpreis erreicht man nämlich (natürlich zufällig) bei dem SAM 
erst, wenn man ein komplettes Reel (1500 Stück abnimmt).

Wieder zurück zum AVR128DA64. Reel-Preise dafür gibt es noch nicht. 
Maximale Stückelung ist bisher 250 mit einem Einzelpreis von 1,47€. 
Keine Verhandlungsoption. Scheint also Verkäufermarkt zu sein, sprich: 
ist noch knapp. Aber selbst mit diesem Preis kosten dann 1500 Stück 
2205€.

Das SAM-Reel hingegen kostet 2670€. Allein schon dadurch hat mein 
Brötchengeber bei einer 1500er Serie 475€ extra Cash in de Täsch, ohne 
sich auch nur ein Stück zu bewegen. Das entspricht einer Einsparung von 
18%.

Was aber noch wichtiger ist: der SAM ist schon ewig am Markt. Bei der 
MC-Produktpolitik bedeutet das in der mittelfristigen Projektion: 
mindestens der Preis wird steigen, u.U. droht auch die Abkündigung. Das 
passiert in der Vergangenheit bei MC zwar eher selten, aber eindeutig 
mit zunehmender Häufigkeit.
Für den AVR128 hingegen ist im selben Projektionszeitraum eher mit 
fallenden Preisen zu rechnen (zumindest in Stückzahlen, das Einzelstück 
wird wohl kaum noch viel günstiger werden).

Fazit: schon jetzt ist der AVR128DA für jede Anwendung, für die seine 
Rechenleistung auch genügt, deutlich günstiger. Und in der 
mittelfristigen Zukunft wird der Vergleich mit an Sicherheit grenzender 
Wahrscheinlichkeit noch mehr zum Vorteil des AVR128DA ausfallen.

Aber um letztlich zum eigentlichen Thema zurück zu kommen: das 
Bandbreitenproblem der Flashanbindung der BT81x hat man mit beiden 
Host-Controllern gleichermaßen und sollte es bei der Planung der 
Anwendung entsprechend berücksichtigen. ;o)

[Rudolph R. (rudolph)]

Wie ich schrieb, bei kleinen Mengen.
Selbstverständlich kann man die bei Mouser auch als Gurtabschnitt ohne 
Reel kaufen und natürlich kostet das aufziehen von Minder-Mengen auf ein 
Reel extra.
Dann bleiben Deine genannten €2,16 zu €1,78 - Peanuts, vor allem wenn 
man dafür DMA, die doppelte Geschwindigkeit und mehr Peripherie bekommt.

Wenn man die bei Microchip direkt kauft kosten die auf Rolle:
ATSAMC20J17A-AUT €1.76
AVR128DA64T-I/PT €1.48

Aber ich würde ich eher mal bei Arrow, Avnet oder EBV anfragen, also 
auch gerade die AVR128DA64 wenn die für die Anwendung ausreichend sind.
Zumal die ATSAMC20J15A-AUT und die ATSAMC20J18A-AUT bei Microchip 
ebenfalls
€1.76 das Stück kosten sollen wenn man eine ganze Rolle bestellt,
da ist gegenüber der regulären Distribution eventuell noch etwas Luft.

Seltsam ist auch, bei den ATSAMC20J sind eine volle Rolle 1500 Stück,
bei den AVR128DA64 sind es aber nur 1200 Stück.
Das ist aber das gleiche Package.
Im Tray sind es bei beiden 260 Stück.

1500 Stück sind aber auch nur Peanuts, also wenn man schon über Preis 
pro Stück fabuliert.

Es gibt übrigens auch noch einen PIC32CM, der ist praktisch identisch 
mit dem ATSAMC20, Microchip hat den "aus Gründen" neu aufgelegt, 
vermutlich um die PIC Kunden an ARM ran zu führen.

Und um auch mal zum Thema zurück zu kommen... :-)
Vielleicht sollte ich mir mal ein DM164151 zulegen.
Einfach mal zu schauen was die da aktuell treiben. :-)

Aber vorher müsste ich eigentlich noch heraus finden warum ich mit dem 
BBC MicroBit V2 keine Anzeige bekomme obwohl der SPI gut aussieht.

[Daniel S. (snipod)]

Hallo,
ich habe mal wieder ein Problem, welches ich nicht durchblicken kann.

Ich lade 3 Fonts und einige Bilder in den EVE. Das Funktioniert soweit 
auch tip top, jetzt habe ich weitere Bilder ergänzt und sobald ich 
dieser neuen verwende funktioniert anscheinend eine Schriftart nicht 
mehr... Im RAM_G sollte noch genug Platz sein.

Die neuen Bilder sind ARGB2 formatiert, alles andere bisher ARGB1555.

Anbei die "Partitionstabelle" vom EVE, sowie Bilder wie es mit und ohne 
reinladen aussieht

void drawButton(uint16_t x, uint16_t y, uint16_t w, uint16_t h, uint16_t r, const char *label, uint64_t adr_img, uint16_t w_img, uint16_t h_img, bool highlighted)
{
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(LINE_WIDTH(r * 16)); 
    EVE_cmd_dl_burst(DL_COLOR_RGB | (highlighted ? HIGHLIGHT : RAL9001));
    EVE_cmd_dl_burst(VERTEX2F(x + r, y + r));
    EVE_cmd_dl_burst(VERTEX2F(x + w - r, y + h - r));
    EVE_cmd_dl_burst(DL_END);
    EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_BLACK);
    EVE_cmd_text_burst(x + (w / 2), (y + h + 16), OPENSANS_REGULAR_15, EVE_OPT_CENTER, label);

    if (adr_img != 0 && w_img != 0 && h_img != 0)
    {
        EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_WHITE);
        EVE_cmd_setbitmap_burst(adr_img, EVE_ARGB2, w_img, h_img);
        EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
        EVE_cmd_dl_burst(VERTEX2F((x + (w / 2) - (w_img / 2)), (y + (h / 2) - (h_img / 2))));
        EVE_cmd_dl_burst(DL_END);
    }
}

Weiß jemand was hier falsch läuft?

EDIT:// Es ist NUR die OPENSANS_REGULAR_15 die dann nicht mehr geht. Mit 
jeder anderen Schriftart tut es noch

[Daniel S. (snipod)]

Ich konnte das Problem lösen:

Nach den EVE_cmd_setfont2 muss das BITMAP_HANDLE wieder zurück gesetzt 
werden.

Ich habe die Fonts jetzt auf den Handles 13-15 und setze das Handle nach 
dem laden der Fonts wieder auf 0 EVE_cmd_dl(BITMAP_HANDLE(0));

[Rudolph R. (rudolph)]

Daniel S. schrieb:
> Nach den EVE_cmd_setfont2 muss das BITMAP_HANDLE wieder zurück gesetzt
> werden.
>
> Ich habe die Fonts jetzt auf den Handles 13-15 und setze das Handle nach
> dem laden der Fonts wieder auf 0 EVE_cmd_dl(BITMAP_HANDLE(0));

Das ist schon etwas seltsam, setfont2 sollte eigentlich nicht
das aktuelle Bitmap-Handle verdrehen.

Handle 15 ist übrigens nicht frei in dem Sinne, das ist "Scratch".
"Bitmap handle 15 is used by the 3D-effect buttons, keys and gradient, 
unless it is set to another bitmap handle using CMD_SETSCRATCH."

Es gibt ohnehin etwas wenig Bitmap-Handles, da hätte ich mir schon 
gewünscht, dass die mindestens verdoppelt werden.
Aber ich nutze zum Beispiel die Fonts 16 bis 25 nie, die würde ich 
einfach neu zuweisen wenn es mal echt knapp werden würde.

[Werner (Gast)]

Hallo Rudolph,
weisst du, ob der cap. Touch-Controller ILI2130 mit dem FT811 kompatibel 
ist?

Und hast du vielleicht eine Quelle, wo man den FT811 noch beziehen kann 
(oder hast du selbst Restbestände)?

Viele Grüsse
Werner

[Rudolph (Gast)]

Werner schrieb:
> weisst du, ob der cap. Touch-Controller ILI2130 mit dem FT811 kompatibel
> ist?

Ich kann es nicht sagen, ich habe zuletzt nach den ILI2132A gesucht die 
Riverdi aktuell auf die EVE4 packt und gar nichts dazu gefunden.

Werner schrieb:
> Und hast du vielleicht eine Quelle, wo man den FT811 noch beziehen kann
> (oder hast du selbst Restbestände)?

Ich habe keine, ich verbaue die ja auch nicht auf eigenen Platinen.
Und ich habe kurz mal danach geschaut, das sieht echt nicht gut aus. :-(
Unfassbar, das wird ja immer schlimmer mit Bauteilen.

[Ioan Mihai Cozac (Gast)]

Spyy schrieb:
> Ich mache das so:
..................................
> //sendCommand(FT81x_CLKSEL); => das würde dann 60 Mhz machen
> ft81xCmdParamWrite(FT81x_CLKSEL, 24);  //select the system clock
> delay(10);
> sendCommand(FT81x_ACTIVE);//send host command "ACTIVE" to wake up
> SPI_TO_EVE_FAST;
> delay(300);    // Give some time to process
> ....
> mit ft81xCmdParamWrite:
> inline void ft81xCmdParamWrite(unsigned char ftCommand, unsigned char
> ftParameter)
> {
>   EVE_CS_PIN_LOW;    // Set CS# low
>   SPI.transfer(ftCommand);// Send command
>   SPI.transfer(ftParameter);// Commands consist a parameter
>   SPI.transfer(0x00);  // Send last zero byte
>   EVE_CS_PIN_HIGH;  // Set CS# high
> }
ft81xCmdParamWrite(FT81x_CLKSEL, 24);
24 ist dezimal Wert glaube ich... das bedeutet 0x18 in hexadezimal.

[Rudolph (Gast)]

Ioan Mihai Cozac schrieb:
> ft81xCmdParamWrite(FT81x_CLKSEL, 24);
> 24 ist dezimal Wert glaube ich... das bedeutet 0x18 in hexadezimal.

Na, wie ich weiter oben im Detail ausgeführt habe, 24 ist ein ungültiger 
Wert, das wird als 0x18 auch nicht gültiger. :-)

>Mit dem zweiten Byte in der CLKSEL Sequenz legt man den Multiplikator
>für die PLL fest.
>Bits 0 bis 5 sind für den Multiplikator selber:
>0 - default
>1 - ungülig, reserviert
>2 bis 6 für eine Frequenz von 24MHz (2) bis 72MHz (6) bei 12MHz Takt
>7 bis 31 ungültig
>
>Bits 6 und 7 sind die "PLL range"
>0 bei Multiplikator 0, 2 oder 3
>1 bei Multiplikator 4, 5 oder 6
>
>0x46: 01000110
>Also Multiplikator 6 und - wofür auch immer - Bit 6 gesetzt.

[Spyy (Gast)]

So...nachdem mein neues Board erstmal mehrere Tage beim Zoll verbracht 
hat, habe ich es jetzt wieder zum laufen gebracht....ich muss dann doch 
nochmal darauf zurück kommen....leider, ich weiss ja hier auch nicht 
weiter...

Also ich habe noch mal "gemessen":

Ich habe ne Display/Command list von 204 Bytes => DL-size 692
Ich lasse mir den CmdRead und CmdWrite ausgeben.

Display FPS: 70 Hz
SPI: 1 Mhz-25Mhz => bei 20 Mhz => 21 µs => Signale auf dem Oszi bei 20 
Mhz nicht mehr schön aber OK
Übertragungsrate der Liste jede 1000 ms => OK CmdRd/CmdWr immer gleich
Übertragungsrate der Liste jede 500 ms => OK CmdRd/CmdWr immer gleich
......
Übertragungsrate der Liste jede 50 ms => OK CmdRd/CmdWr immer gleich
Übertragungsrate der Liste jede 30 ms => OK CmdRd/CmdWr immer gleich
Übertragungsrate der Liste jede 25 ms => Teilweise OK CmdRd/CmdWr nicht 
mehr immer gleich (Rd "hinkt" hinterher, Delta erhöht sich, Bild 
flackert)
Übertragungsrate der Liste jede 20 ms => Nicht mehr OK, CmdRd/CmdWr 
nicht mehr gleich (Wr "hinkt" hinterher, Delta erhöht sich, Bild 
flackert stark)

Wenn man jetzt die FPS etwas erhöht wird das wieder besser, hat also 
irgendwas damit zu tun. Jetzt habe ich mal in Deinen Code geschaut, ob 
irgendwo abgefragt wird, ob der EVE zu tun hat bzw. noch Platz hat. Habe 
ich das hier gefunden:

void EVE_start_cmd_burst(void)
{
  uint32_t ftAddress;

#if defined (EVE_DMA)
  if(EVE_dma_busy)
  {
    while (EVE_busy()); /* this is a safe-guard to protect segmented 
display-list building with DMA from overlapping */
  }
#endif

  cmd_burst = 42;
  ftAddress = REG_CMDB_WRITE;

Ich verstehe das so, dass das die Abfrage ist, ob der EVE "bereit" ist 
weitere Daten aufzunehmen. Hier ist aber zu erkennen, dass Du erstmal 
abfragst, ob DMA busy ist und wenn DMA busy ist dann den EVE chip. DMA 
scheint aber immer nicht busy zu sein => dadurch wird der EVE chip nicht 
mehr abgefragt while(EVE_busy()), da das ja in dem if ist. Ich habe das 
mal so geändert (in EVE_busy() ist ja auch die EVE_dma_busy Abfrage 
drin):
  if(EVE_busy())
  {
    while (EVE_busy());     /* this is a safe-guard to protect segmented 
display-list building with DMA from overlapping */
    {
      //Serial.println("EVE Busy");
    }
  }
Da ich das wohl aber nicht so ganz überblicke bleibt das Programm in 
einer Endlosschleife hängen (ich denke bei while(EVE_busy())).
Für das ganze ist übrigens die SPI Geschwindigkeit egal, ist auch so bei 
1 Mhz...

Grüße

Torsten

[Rudolph (Gast)]

Hast Du mal VSYNC gemessen?
Das klingt jetzt so als hättest Du eher 35 FPS als 70.

[Spyy (Gast)]

Also ich denke man kann nur mit 1/2 der aktuellen FPS des Displays Daten 
hinschicken und die DL swappen...das kommt ungefähr hin 80 Hz => mit 40 
Hz Daten...

[Spyy (Gast)]

...ja werde ich noch einmal messen...

[Spyy (Gast)]

...mich wundert natürlich wieso sonst keiner "diese Probleme" hat, also 
Hardware kann ich mal ausschliessen, keine Ahnung, ob das noch jemand 
mit dem Teensy 4.x gemacht hat. Ist auch unabhängig mit/ohne DMA, immer 
das gleiche Verhalten, ab einer gewissen Updategeschwindigkeit der Liste 
wird die Displayliste "zerschossen" bzw. Rd/Wr laufen auseinander und Wr 
überholt Rd.

[Rudolph R. (rudolph)]

Was Du noch machen könntest wäre einmal pro Sekunden den Inhalt von 
REG_FRAMES zu lesen und die Differenz zum vorherigen Wert auszugeben.

Edit: eben die Frage im BRT Forum gesehen.
REG_CLOCK geht auch, das ist einfach nur ein 32-Bit Zähler der mit 
Systemtakt läuft.

Und Du könntest mal die kompletten Timing-Werte für das Display über den 
Zaun reichen.

Das Problem hatte ich noch gar nicht, die 20ms habe ich schon querbeet 
über diverse Displays mit diversen MikroControllern benutzt, FT800, 
FT810, FT811, FT811, BT815, BT817.
Und bei dem einen 1024x600 Display mit FT813, bei dem es gar nicht 
möglich ist über 38 FPS zu kommen, lief das wie erwartet nicht richtig 
und hat geflackert, mt 30ms Refresh aber doch.

[Rudolph R. (rudolph)]

@Spyy
Da ich gerade mit einem billigen 24MHz Logik-Analyzer und Pulseview 
herum spiele, hast Du Dir mal angesehen was der Teensy so auf den SPI 
wirft?
Ich musste den SPI etwas runter drehen damit ich mit dem LA überhaupt 
brauchbar messen kann und bin jetzt bei 4MHz.
Aber unter Beibehaltung des 5ms Rasters reicht das locker für 2200 Bytes 
bevor auch nur die nächste Touch-Abfrage übersprungen wird.
Ein Pulseview Trace vom Startup hängt an.

Ich habe gerade mal bei den 904 Bytes die mein Bildwechsel im Moment 
braucht den SPI auf 400kHz runter gedreht.
Der einzige "negative" Effekt ist das der Touch nicht mehr alle 5ms 
abgefragt wird, sondern nur noch alle 20ms, die Übertragung für den 
Bildwechsel dauert so rund 18ms und damit ist der SPI dann einfach drei 
Mal beschäftigt wenn der Touch abgefragt werden soll.

Jetzt habe ich bei 4MHz SPI den Bildwechsel mal auf 15ms / 66Hz 
gestellt.
Das klappt ohne Probleme da ich das EVE3-50G das hier gerade anhängt auf 
74Hz laufen lassen - nicht, weil ich 74Hz brauche, sondern weil der 
BT815 etwas eingeschränkt ist was den Pixel-Clock angeht.

Stelle ich den Bildwechsel auf 10ms blinkt das nicht mal mehr.
Bei 12,5ms funktioniert es auch nicht.
Hmm, drehen wir mal an der Zeitbasis. :-)
Mit Intervallen von 1,7ms läuft es noch wenn ich alle 13,6ms einen 
Bildwechsel mache. :-)

[Daniel S. (snipod)]

Hi,
kann mir zufällig jemand erklären, wie ich Umlaute in die Fonts bekomme, 
bzw. generell "richtig" mit einem custom character set arbeite?

Was ich versucht habe:
User Defined Charater Set -> Textdatei, UTF-8 codiert mit folgendem 
Inhalt (ohne die Anführungszeichen natürlich...)

" 
!"%&()*+,-./0123456789?ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuv 
wxyzÄÖÜäöüß"

Font generiert, komprimiert, und ab damit in RAM_G

Dann

EVE_cmd_setfont2_burst(OPENSANS_REGULAR_22, Adr_OpenSans_Regular_22, 32);
EVE_cmd_text_burst(50, 220, OPENSANS_REGULAR_22, EVE_OPT_FILL, " !""%&()*+,-./0123456789?ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyzÄÖÜäöüß");

Leider kommt da aber ziemlicher Kauderwelsch raus :) ich tippe mal 
irgendwas mache ich bei der Adressierung der Buchstaben verkehrt

[Rudolph R. (rudolph)]

Speichert Dein Editor den Text auch wirklich mit UTF-8 Kodierung?
Das Atmel-Studio musste ich erstmal entsprechend umstellen.

Man kann beim Konvertieren übrigens auch alle Zeichen bis zum letzten 
gewünschten Mitnehmen, das wäre in dem Fall "ü" und ich habe mal eine 
entsprechende Charmap-Datei angehängt.

Das Format ist leider so ineffizient gestaltet das so oder so eine 
Glyphe für alle Zeichen bis zum letzten erzeugt wird, bei ungenutzen 
Zeichen ist die zwar leer, belegt aber dennoch den vollen Platz, da kann 
man die dann auch gleich mitnehmen.

Und schaut mal hier: http://www.brtcommunity.com/index.php?topic=127.15
Es gibt einen inoffiziellen EVE-Asset-Builder-setup-2.2.0-rc2.zip
Wesentlich ist da, der ASTC-Encoder wurde auf V2 aktualisiert, damit 
geht das Konvertieren von Fonts richtig schnell.
Nur wie ich schrieb, Bridgtek hat die Version für AVX2 in das Archiv 
gepackt, wenn die eigene CPU keine AVX2 kennt läuft das aber wenn man 
das durch eine entsprechende Version von hier 
https://github.com/ARM-software/astc-encoder ersetzt.

[c-hater (Gast)]

Rudolph R. schrieb:

> wenn die eigene CPU keine AVX2 kennt

Das kann doch nur eine sehr historische CPU sein, oder?

Ich meine, ich arbeite hier privat regulär mit einem zehn Jahre alten 
Core2Duo E8500. Selbst der kann das schon.

Was den AssetBuilder betrifft: Das war das Erste, was ich durch eigene 
Software ersetzt habe. (Wobei der eigentliche ASTC-Encoder "zugekauft" 
ist, das ist allerdings im BT-Original genauso ;o)

Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes 
Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings 
sehr viel komfortabler als das Original. Vor allem im Bezug auf einen 
AVR8-Host als Zielsystem...

[Rudolph R. (rudolph)]

c-hater schrieb:
>> wenn die eigene CPU keine AVX2 kennt
>
> Das kann doch nur eine sehr historische CPU sein, oder?

Naja, fast, ich habe einen AMD FX-8320E im Rechner, das war so praktisch 
die dickste CPU die ich vor ein paar Jahren noch für mein AM3+ Mainboard 
bekommen konnte, Markteinführung war September 2014, gekauft im Februar 
2016.
Der hat zwar schon eine ganze Latte an Features, aber kein AVX2.
Die SSE4 Version vom ASTENC ist V2 läuft und ist deutlich schneller als 
die V1.x die vorher beim EVE Asset Builder beilag.

> Ich meine, ich arbeite hier privat regulär mit einem zehn Jahre alten
> Core2Duo E8500. Selbst der kann das schon.

Also laut Wikipedia nicht, der kann nur bis SSE4.1, AVX kam Anfang 2011 
und AVX2 kam Mitte 2013 von Intel.

Ich schiele zwar schon auf einen Ryzen 5600X, aber das letzte Mal das 
ich ein paar Komponenten zusammen gestellt habe um den Rechner 
aufzurüsten war ich viel zu schnell bei über 1000 Euro, so langsam ist 
die Kiste dann auch wieder nicht. :-)
Der Markt ist im Moment auch insgesamt eher unlustig.

c-hater schrieb:
> Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes
> Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings
> sehr viel komfortabler als das Original. Vor allem im Bezug auf einen
> AVR8-Host als Zielsystem...

Die ersten EVE Asset Builder habe ich auch nicht genutzt, sondern lieber 
den Image-Converter aus der Shell.
Nur ist der EAB stetig besser geworden, Bridgetek hat auf meinen 
Vorschlag hin sogar ein ein BIN2C Tool eingebaut. :-)
Braucht man das? Nicht wirklich in dem Sinne, aber jetzt muss ich das 
Tool nicht mehr wechseln.
Und seit den BT815 erzeuge ich Flash Images mit dem EAB und übertrage 
die damit.

[c-hater (Gast)]

Rudolph R. schrieb:

>> Core2Duo E8500

> Also laut Wikipedia nicht, der kann nur bis SSE4.1, AVX kam Anfang 2011
> und AVX2 kam Mitte 2013 von Intel.

Nun, er selber behauptet von sich, das zu können. Und tatsächlich läuft 
auch die AVX2-Variante des ASTC-Encoders problemlos.
Könnte aber natürlich sein, dass ich beim Auslesen der Feature-Flags was 
falsch gemacht habe und der ASTC-Encoder ein Fallback hat. Guter 
Hinweis, da werde ich wohl nochmal ein wenig nachprüfen müssen.

Obwohl: Selbst wenn nur Fallback, ist es trotzdem locker schnell genug 
für meine Zwecke. Wechsel der Qualitätsstufe einer 800x480-Grafik dauert 
(inclusive der Decodierung des neuen Vorschaubilds und kompletter 
Aktualisierung des GUI) nur ca. 1/10 Sekunde. Damit kann ich gut leben.

> c-hater schrieb:
>> Allerdings hat mein "AssetBuilder" bislang nur ein sehr eingeschränktes
>> Repertoire. Fonts kann er z.B. noch garnicht, nur Bilder. Die allerdings
>> sehr viel komfortabler als das Original. Vor allem im Bezug auf einen
>> AVR8-Host als Zielsystem...

> Und seit den BT815 erzeuge ich Flash Images mit dem EAB und übertrage
> die damit.

Ich lade den Kram immer vom Host hoch. Entweder liegt er im Flash des 
Hosts (wenn dort genug Platz ist) oder es kommt von einer an den Host 
angebundenen SD-Karte. Sehr praktisch für Updates.

Genau dazu, beide Varianten schön einfach "packagen" zu können, dient im 
Wesentlichen der Komfort meines eigenen Asset-Builders. Das einzige, was 
bei der Entwicklung noch ein wenig nervt, ist das Hin- und Herstecken 
der SD-Karte. Dafür baue ich aber auch gerade an einer Lösung, bei der 
der Entwicklungsrechner für das Zielsystem eine virtuelle SD-Karte (und 
einen virtuellen Reset-Button über deren CD-Signal) bereitstellt.

[c-hater (Gast)]

c-hater schrieb:

> Könnte aber natürlich sein, dass ich beim Auslesen der Feature-Flags was
> falsch gemacht habe

So war es tatsächlich. Der E8500 kann nichtmal AVX, geschweige denn 
AVX2.

> und der ASTC-Encoder ein Fallback hat.

Was damit wohl nachgewiesen ist.

[Rudolph R. (rudolph)]

c-hater schrieb:
>> und der ASTC-Encoder ein Fallback hat.
>
> Was damit wohl nachgewiesen ist.

Ich habe das gerade noch mal ausprobiert, mit dem EAB 2.2 wird eine 
"astcenc.exe" ausgeliefert die sich so meldet:
ASTC codec v2.1, 64-bit avx2+popcnt
Copyright 2011-2020 Arm Limited, all rights reserved

Und damit bekomme ich in EAB das hier als Fehler: 
ASTCENC_ERR_BAD_CPU_ISA

Also auf meiner geringfügig frischeren CPU von AMD gibt es da kein 
Fallback.
Mit der aktuellen v2.5 auch nicht.

Da die SSE4.1 Version alles andere als langsam ist wäre es wohl schlauer 
das nächste offizielle Archiv damit auszuliefern.

Wir Zeit aufzurüsten, aber Zen4 mit DDR5 ist auch schon am Horizont zu 
sehen. :-)

[Johannes (Gast)]

Hallo,

hat mal jemand die Library mit einem RVT70xQB getestet?

Habe hier mal an einer laufende Applikation, die bisher NHD70 nutzte ein 
RVT70AQBNWC00 angeschlossen und die Display-Defines geändert. Trotz 
gutem timing (DL <100us) flackert das Display alle paar Sekunden. Es 
wird dann für ein paar Millisekunden dunkel und kommt dannach wieder.

Der Touch funktioniert auch nur gelegentlich...

Gruß,
Johannes

[Johannes (Gast)]

Kleine Ergänzung: Das Display blitzt im 2-Skunden-Takt sobald ein Button 
in der DL enthalten ist. Eine DL mit Bitmap, Slider und ein paar Texten 
verhält sich normal.

[Rudolph R. (rudolph)]

Also zumindest das RVT50AQBNWC00 habe ich selber schon benutzt in einem 
Projekt, das ist ja praktisch das gleiche, nur eben kleiner.
Der einzige Unterschied elektrisch ist, das RVT70 braucht mehr Strom.

Wie versorgst Du das Ding denn? Und wie viel Strom verträgt die 
Versorgung?

[Johannes (Gast)]

Hängt hinter einem TS2596 der 5V macht für die BL und dann ein TS9013 
der 3,3V macht. Spannungen passen und der Low-Drop-Regler wird so nur 
handwarm.

[Rudolph R. (rudolph)]

Johannes schrieb:
> Hängt hinter einem TS2596 der 5V macht für die BL und dann ein TS9013
> der 3,3V macht. Spannungen passen und der Low-Drop-Regler wird so nur
> handwarm

Okay, wenn die richtig funktionieren sollte das reichen.
Blöderweise hat Riverdi keine vernünftigen Daten, für die 3,3V muss man 
bei der Größe mindestens 200mA vorhalten.
Und für die Beleuchtung so um die 300mA bei 5V.

Wie sieht der Rest zum Display aus?
Und zeigt mal bitte etwas Testcode der nicht funktioniert.

[Johannes (Gast)]

Problem gelöst. Die DL wurde zu schnell geladen. 20ms Wiederholrate 
scheinen einen Hauch zu schnell zu sein. Bei 25ms funktioneirt alles 
problemlos.

[Rudolph R. (rudolph)]

Johannes schrieb:
> Problem gelöst. Die DL wurde zu schnell geladen. 20ms Wiederholrate
> scheinen einen Hauch zu schnell zu sein. Bei 25ms funktioneirt alles
> problemlos.

Dann stimmt aber was nicht, mit den Parametern die ich für das Display 
in die EVE_config geschrieben habe, zusammen mit dem Takt für den BT815 
von 72MHz sollte das eigentlich einen Refresh von schlapp 65Hz ergeben.
Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
Oder sind die 20ms gar keine 20ms?

Die EVE_RVT70 Konfiguration wäre zum Beispiel für ein RVT70AQFNWC00, 
also EVE2 / FT813, damit sollten sich 54Hz ergeben.
Und mit RVT70UQFNWC00 habe ich das auch im Einsatz bei 20ms.

[Daniel S. (snipod)]

Hi Rudolph,
also zuerst mal vielen Dank für die Grandiose Hilfe mal wieder :)

ich habe meine Fonts aus dem Legacy Format auf ASTC umgestellt und das 
funktioniert tip top, auch mit Sonderzeichen.

Zu der Konvertierungsdauer kann ich nur sagen, dass ich es fast nicht 
mitbekomme, dass er überhaupt konvertiert. Es dauert vielleicht eine 
Sekunde und das auf einer - nicht wirklich aktuellen - CPU (AMD Ryzen 7 
1700X)


Nun aber zu einem neuen Problem:
Ich kämpfe mit falsch detektierten Touch punkten - und zwar nur, wenn 
ich im oberen rechten Bildschirmrand etwas anzeige... sehr komisch
Ich zeige auf meinem Screen ein Smartphone-Inspiriertes Menu an:

meine Touchausgabe (zuerst die 5 Tags, dann RawX und RawY) sieht dann 
wie folgt aus:

I (67548) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 199 0x  27
I (68398) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16
I (68403) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16
I (68408) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16
I (68413) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 198 0x  16

also die Anzahl an falschen Touch Ereignissen ist vertretbar -> erster 
Touch bei 67548, dann drei falsche - naja OK, dann bei 68413 der zweite 
richtige.

Wenn ich das Menü jetzt aber wieder mit Leben Fülle, rastet der Touch 
Controller anscheinend komplett aus, bis er zufällig irgendwas trifft, 
was das Menü wieder ausblendet:

I (6433) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 191 0x  1F
I (6518) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
I (6523) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
I (6528) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
I (6533) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2F9
I (6538) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2FB
I (6543) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1B2 0x 2FB
I (6668) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
I (6673) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
I (6678) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
I (6683) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
I (6688) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
I (6693) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A2 0x 1F4
I (6698) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A3 0x 232
I (6704) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A3 0x 232
I (6765) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
I (6770) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
I (6775) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
I (6780) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A4 0x 2C1
I (7140) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7145) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7150) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7155) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7160) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7165) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7170) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 1DD
I (7176) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x 1DE
I (7182) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x 1DE
I (7188) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  41 0x 1E6
I (7194) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4D 0x 213
I (7200) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4D 0x 213
I (7496) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
I (7501) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
I (7506) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
I (7511) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
I (7516) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 151 0x 293
I (7801) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
I (7806) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
I (7811) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
I (7816) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
I (7821) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
I (7826) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 250
I (7831) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 254
I (7837) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  49 0x 254
I (7843) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  B7 0x 264
I (7849) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  B7 0x 264
I (7855) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 125 0x 288
I (7861) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 125 0x 288
I (7867) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 194 0x 2A9
I (7873) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 2A0
I (7879) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 2A0
I (8060) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
I (8065) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
I (8070) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
I (8075) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19D 0x 257
I (8480) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
I (8485) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
I (8490) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
I (8495) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4A 0x 1CE
I (8500) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  48 0x 1F7
I (8505) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  48 0x 1F7
I (8855) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
I (8860) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
I (8865) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
I (8870) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  4F 0x 14C
I (8875) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  55 0x 19D
I (8880) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  55 0x 19D
I (8885) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  55 0x 19D
I (8966) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
I (8971) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
I (8976) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
I (8981) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A1 0x 1B5
I (9256) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
I (9261) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
I (9266) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
I (9271) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3C 0x 28E
I (9331) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
I (9336) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
I (9341) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
I (9346) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 196
I (9621) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9626) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9631) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9636) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9641) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9646) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9651) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 120 0x 277
I (9657) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 142 0x 27C
I (9663) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 16E 0x 286
I (9669) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 16E 0x 286
I (9675) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 199 0x 291
I (9681) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 199 0x 291
I (9687) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19E 0x 28A
I (9693) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19E 0x 28A
I (9699) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19B 0x 27C
I (9705) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 26F
I (9711) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 197 0x 26F
I (9717) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 195 0x 28B
I (9723) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 195 0x 28B
I (9729) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 194 0x 2A7
I (9735) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 194 0x 2A7
I (9741) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 192 0x 2AE
I (9747) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 192 0x 2AE
I (9753) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 16B 0x 252
I (9759) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  FE 0x 1F8
I (9765) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  FE 0x 1F8
I (9770) Touch: 0xF2 0x 0 0x 0 0x 0 0x 0 - 0x  92 0x 1D6
I (9776) Touch: 0xF2 0x 0 0x 0 0x 0 0x 0 - 0x  92 0x 1D6
I (9782) Touch: 0xF2 0x 0 0x 0 0x 0 0x 0 - 0x8000 0x8000
I (11324) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
I (11329) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
I (11334) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
I (11339) Touch: 0x 1 0x 0 0x 0 0x 0 0x 0 - 0x  3E 0x  8A
I (12034) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12040) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12045) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12050) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12055) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12060) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12065) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12070) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12076) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12082) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12089) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12095) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12101) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1A5 0x   A
I (12812) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12817) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12822) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12827) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12832) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12837) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12842) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12849) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12854) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12860) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12867) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12873) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12879) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12885) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12891) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12897) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12903) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12910) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (12915) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 1AB 0xFFFC
I (14061) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
I (14066) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
I (14071) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
I (14076) Touch: 0xFE 0x 0 0x 0 0x 0 0x 0 - 0x 19A 0x  17
I (14511) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
I (14516) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
I (14521) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
I (14526) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
I (14531) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 187 0x 1F6
I (16887) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC
I (16892) Touch: 0x 0 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC
I (16897) Touch: 0xF3 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC
I (16902) Touch: 0xF3 0x 0 0x 0 0x 0 0x 0 - 0x 158 0x 1CC

Jemand eine Idee was da los ist und was ich dagegen tun kann?

[Rudolph R. (rudolph)]

Wie schnell ist der SPI?
Probier den mal während der Touch-Phase auf eine kleinere Frequenz zu 
stellen.
Wenn Du einen Logic-Analyzer hast welcher problemlos den Takt auf dem 
SPI mitmacht, dann zieh mal einen Trace davon.

Das kann gut sein, dass der SPI zu schnell ist um sauber zu lesen.
Wenn ich hier den Takt zu hoch drehe kommt ab so 15Mhz Datenmüll zurück,
Schreiben geht deutlich schneller, CLK und MOSI kommen ja zusammen an.

[Rudolph R. (rudolph)]

Ok, time to try something new. :-)
https://github.com/RudolphRiedel/FT800-FT813/discussions

This might be the place to ask if for example the well moderated BRT 
forum is not your thing or if for example the Matrix Orbital forum is 
not apropriate since you module is from a different manufacturer.
And this here is only one thread afterall.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Mein bescheidener Beitrag dazu, vielleicht hilft's: Ich hatte ja gerade 
vor ein paar Wochen von meinem Problem mit dem C-Touch berichtet, dass 
immer wieder falsche Koordinaten abgeholt wurden. Die Empfindlichkeit 
des Touch ist dann einfach zu hoch. Sie ist ausgelegt dafür, das Display 
mit einer Glasscheibe zu betreiben. Im Datenblatt des Display sollte 
stehen, wie man das ändern kann. Aber eine große Hilfe ist bereits, die 
Applikation zu erden (Schutzleiter an Masse), bzw. ein entspr. Netzteil 
zu verwenden, dass den Schutzleiter auf Minus durchschleift (die meißten 
China-Netzteile haben ja nicht einmal einen Schutzleiter-Anschluss).

Ich arbeite seit einigen Jahren mit dem FT8xx, seit ca. 2 Jahren mit dem 
FT813. Habe schon recht beachtliche Oberflächen NUR mit den 
"Primitives-Befehlen" gezaubert. Nun aber rufen die Kunden nach 
"schöneren" Grafiken und nach Bitmaps. Rudi, Du sollst es nicht glauben, 
aber ich beginne JETZT den Co-Prozessor einzusetzen. Und da beginnt nun 
mein Problem. Ich bin am Verzweifeln, wälze das Datenblatt von vorn bis 
hinten und verstehe es nicht. Ich bekomme es nicht einmal hin, das 
FTDi-Demo (CMD_Logo) zu laden. Kannst Du mir bitte, bitte in 
"Echtworten" sagen, was ich an welche Adresse senden muss? Ich bin hier 
am "wilden" Probieren. Was übersehe ich da?
Ist es vielleicht genauso einfach (wenn man es denn einmal begriffen 
hat):
Ram_CMD ab Hx308000 setzen (hier auch nach jedem Befehl + 4 ???) gefolgt 
von  HxFFFFFF00 für "CMD_DLSTART". Dann Hx308004 (?) gefolgt von 
CMD_Logo. Wie beenden? Einfach nur Hx3080xx gefolgt von CMD_SWAP ???

[Rudolph R. (rudolph)]

Das steht in Kapitel 5 vom Programming Guide.

Ich benutze ja in meiner Libray von Anfang an exklusiv nur den 
Co-Prozessor.
Und da gibt es zwei Wege, entweder man schreibt in RAM_CMD und muss 
dabei die ganze Zeit zum Beispiel in einem Offset-Zähler mitrechnen was 
man so geschrieben hat, am Ende schreibt man dann den Wert in 
REG_CMD_WRITE.
Direkt nach Reset stehen REG_CMD_READ und REG_CMD_WRITE auf 0.
Dann schreibt man sagen wir mal 20 Bytes, setzt REG_CMD_WRITE auf 20 und 
was zwischen 0 und 20 steht wird ausgeführt.
Wenn REG_CMD_READ auch 20 hat ist der Co-Prozessor fertig.
Dann geht es ab 20 weiter.
Wenn man in RAM_CMD schreibt gibt es 4096 automatisch einen Überlauf und 
es wird wieder auf Adresse Null geschrieben.
Diesen Überlauf muss man mit im Offset berücksichtigen.

Das ist der "alte" Weg, das ist mit den FT80x kompatibel und das habe 
ich bis Version 4 von meiner Library auch so gemacht.
https://github.com/RudolphRiedel/FT800-FT813/blob/4.x/EVE_commands.c
EVE_begin_cmd() + EVE_inc_cmdoffset()

Mit den FT81x wurden neue Register eingeführt, REG_CMDB_WRITE und 
REG_CMDB_SPACE.
Wenn man ein 32 Bit Wort in REG_CMDB_WRITE schreibt, dann landet das an 
der nächsten freien Position von RAM_CMD und mit jedem weiteren 
Schreiben in REG_CMDB_WRITE wird auch immer wieder an die nächste 
Adresse geschrieben.
Wenn man mit Schreiben aufhört wird REG_CMD_WRITE automatisch gesetzt 
und ausgeführt was in RAM_CMD ist.
Den Offset nicht mitzurechnen spart einiges an Zeit, ist aber nicht
mehr mit den FT80x kompatibel.
Das habe ich in der aktuellen Version 5 umgesetzt.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_commands.c
eve_begin_cmd()

[Daniel S. (snipod)]

Bernd I. schrieb:
> Mein bescheidener Beitrag dazu, vielleicht hilft's: Ich hatte ja gerade
> vor ein paar Wochen von meinem Problem mit dem C-Touch berichtet, dass
> immer wieder falsche Koordinaten abgeholt wurden. Die Empfindlichkeit
> des Touch ist dann einfach zu hoch. Sie ist ausgelegt dafür, das Display
> mit einer Glasscheibe zu betreiben. Im Datenblatt des Display sollte
> stehen, wie man das ändern kann. Aber eine große Hilfe ist bereits, die
> Applikation zu erden (Schutzleiter an Masse), bzw. ein entspr. Netzteil
> zu verwenden, dass den Schutzleiter auf Minus durchschleift (die meißten
> China-Netzteile haben ja nicht einmal einen Schutzleiter-Anschluss).

Hi,
danke für den Input, aber das war tatsächlich nicht mein Problem.

Mein Problem liegt hier begraben:

        EVE_cmd_dl_burst(COLOR_A(0));
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
        EVE_cmd_dl_burst(VERTEX2F(menuXPos - 10, HEADER_HEIGHT + 1));
        EVE_cmd_dl_burst(VERTEX2F(menuXPos - 1, menuHeightYMax));
        EVE_cmd_dl_burst(DL_END);
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 1));
        EVE_cmd_gradienta_burst(188, HEADER_HEIGHT, 0UL, menuXPos, HEADER_HEIGHT, 0x64000000);
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));

sobald ich diesen Schatten mit hinzu nehme, rastet der Touch so aus. 
Ohne, läuft er perfekt. Setze ich hier etwas nicht richtig zurück was 
den Stencil angeht? Allerdings sollte das ja keine Auswirkungen auf den 
Touch haben... Oder ist es wohlmöglich doch ein Firmware-Bug im EVE?

Ich könnte noch mal den Logic Analyzer dranhängen, ich habe eine Logic 
Pro 8, der sollte den Takt schon mitmachen... Dafür müsste ich aber 
wieder Kabel an meine Platine löten, weil ich mal wieder vergessen habe, 
mir den Bus auf Testpunkte zu legen... Ich kann mir aber nicht 
vorstellen, dass bei ca. 96mm Leiterbahnlänge zwischen dem Controller 
und dem EVE es da Probleme gibt bei 40 MHz. Laut Eagle besitzen die 
Traces eine maximale Frequenz weit über 3 GHz.

Falls Ihr unabhängig meiner Beobachtung doch weiter den SPI verdächtigt, 
kann ich entweder die BUS-Geschwindigkeit drosseln, oder doch mal den 
Logic Analyzer anlöten...

Viele Grüße

[Rudolph (Gast)]

Daniel S. schrieb:
> Mein Problem liegt hier begraben:
>  EVE_cmd_dl_burst(COLOR_A(0));
> ...

Ok, sowas habe ich noch nicht probiert, muss ich mir mal ansehen.
Wenn das die Ursache ist, bitte mal an Bridgetek melden.

Daniel S. schrieb:
>Ich kann mir aber nicht vorstellen, dass bei ca. 96mm Leiterbahnlänge
>zwischen dem Controller und dem EVE es da Probleme gibt bei 40 MHz.

Abgesehen davon, dass der maximale Takt für EVE mit 30MHz angegeben ist 
und es auch darauf ankommt was in den Leitungen, neben den Leitungen und 
unter den Leitungen noch so liegt, dreh doch einfach mal den Takt auf 
8MHz runter und schau was passiert. :-)
Ich weiß halt aus Beobachtung, dass zumindest im meinem Aufbau Senden 
deutlich schneller noch funktioniert als Lesen.
In einem Test konnte ich bis 17MHz noch sauber lesen, aber bis 40MHz 
Schreiben.
Mit einem anderen Controller waren es 12MHz und 35MHz.

>Laut Eagle besitzen die Traces eine maximale Frequenz weit über 3 GHz.

Da habe ich so leichte Zweifel dran, bei 20MHz verfälschen ein paar pF 
schon gut die Messung, das wird zunehmend analog. Und dann müssen beide 
Seiten die Leitungen auch schnell genug treiben können was EAGLE wohl 
eher nicht berücksichtigen wird.

[Johannes (Gast)]

Rudolph R. schrieb:
> Dann stimmt aber was nicht, mit den Parametern die ich für das Display
> in die EVE_config geschrieben habe, zusammen mit dem Takt für den BT815
> von 72MHz sollte das eigentlich einen Refresh von schlapp 65Hz ergeben.
> Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
> Oder sind die 20ms gar keine 20ms?

Hi Rudolph,

der 5ms Tick ist exakt 5ms lang. Nutze einen SAMC/D auf 48 MHz. der SPI 
läuft auf 12 MHz.

Welche Parameter könnten denn angepasst werden müssen?

Johannes

[Rudolph (Gast)]

Johannes schrieb:
>> Hast Du EVE_RVT70 statt EVE_RiTFT70 eingestellt?
>> Oder sind die 20ms gar keine 20ms?
>
> Hi Rudolph,
>
> der 5ms Tick ist exakt 5ms lang. Nutze einen SAMC/D auf 48 MHz. der SPI
> läuft auf 12 MHz.
>
> Welche Parameter könnten denn angepasst werden müssen?

Schau mal in die EVE_config.h ob da wirklich EVE_RiTFT70 aktiv ist.

[Johannes (Gast)]

Ja, ist wirklich die RiTFT70.

[Rudolph (Gast)]

Tja, seltsam, vor allem habe ich die EVE_RiTFT50 Einstellung selber 
schon so benutzt, die ist ja mit der EVE_RiTFT70 identisch.

Muss ich mal auf dem Schreibtisch kramen, ein RVT50UQBNWC01 habe ich ja 
und eine Platine mit ATSAMC21 auf 48MHz.
Das lief soweit alles.


Und ohne Bezug, ich hatte vor einiger Zeit ein RVT101HVBNWC00-B 
bestellt, das ist jetzt unterwegs, ich werde berichten. :-)

[Rudolph R. (rudolph)]

Na toll, FedEx hat das Paket nicht geliefert und im Tracking steht immer 
noch: "Voraussichtlicher Zustelltermin: Freitag, 28. Mai 2021 bis Ende 
des Tages"
Also frühestens am Montag, danke FedEx mir so das WE zu versauen.


Das RVT50UQBNWC01 läuft übrigens einwandfrei auf 20ms mit meinem 
ATSAMC21 Board, nur auf 15ms spinnt der Touch.
Aber das Timing von Display liegt auch bei 15,3ms, also sind 15ms 
schlicht zu schnell.

[Spyy (Gast)]

Hallo Rudolph,

so nach langer Zeit komme ich mal wieder zu meinem Projekt...

Ich habe mal das hier in die EVE_Init() Routine geschrieben:

  // Write the EVE stats:
  uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
  delay(1000);
  uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
  Serial.print("EVE clock: ");
  Serial.println(eveClockNew - eveClockOld);

Ich lese einfach zweimal im Abstand von 1 Sekunde das CLOCK Register. 
Meine Erwartung wäre, dass ich dann so ein Wert vom 72000000 bekommen 
werde, da ich ja das hier geschrieben habe:
EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
Ich bekomme aber das hier:

Eve init...
EVE PCLK Frequency: 48000000
EVE clock: 34667018

Was bekommst Du für einen Wert, wenn Du das bei Dir machst ?

[Spyy (Gast)]

REG_CLOCK geht auch, das ist einfach nur ein 32-Bit Zähler der mit
Systemtakt läuft. => siehe letztes Posting

Und Du könntest mal die kompletten Timing-Werte für das Display über den
Zaun reichen.
#if defined (EVE_EVE4_ISFD)
#define Resolution_480x480

#define EVE_HSIZE  (480L)
#define EVE_VSIZE  (480L)
#define EVE_VSYNC0  (0L)
#define EVE_VSYNC1  (20L)
#define EVE_VOFFSET  (20L)
#define EVE_VCYCLE  (518L)
#define EVE_HSYNC0  (0L)
#define EVE_HSYNC1  (41L)
#define EVE_HOFFSET  (43L)
#define EVE_HCYCLE   (548L)
#define EVE_PCLK  (1L)
#define EVE_PCLKPOL  (1L)
#define EVE_SWIZZLE  (0L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_GEN 4

Ich verwende dieses Display hier:
https://www.buydisplay.com/4-inch-tft-lcd-display-480x480-pixel-with-mipi-interface-for-iot-devices

[Rudolph R. (rudolph)]

Spyy schrieb:
> Was bekommst Du für einen Wert, wenn Du das bei Dir machst ?

Ich habe nur den Systick-Timer und kein exaktes delay().
Also lese ich alle 200 * 5ms REG_CLOCK und lasse mir die Differenz
zu dem alten Wert anzeigen.

Das sind 72001711 mit einem ATSAMC21 und einem BT815.
Die Abweichung kommt jetzt entweder von meinem Quarz oder dem Quarz auf 
dem Display oder beiden.

Wenn ich das auf REG_FRAMES umstelle bekomme ich 65.

Spyy schrieb:
> Und Du könntest mal die kompletten Timing-Werte für das Display über den
> Zaun reichen.
> #if defined (EVE_EVE4_ISFD)
> #define EVE_VCYCLE  (518L)
> #define EVE_HCYCLE   (548L)
> #define EVE_PCLK  (1L)
#define EVE_GEN 4

Entscheidung für die Bildrate sind diese Werte.
Wenn Du einen BT817 / BT818 mit PCLK = 1 betreibst, dann nutzt der die 
zweite PLL.
Und wenn das Define für EVE_PCLK_FREQ nicht da ist lässt mein Code den 
Default-Wert drin, das sind 60MHz.
Also mit den Werten hast Du einen Pixel-Clock von 60MHz was in einer 
Bildrate von 211 HZ resultiert und etwas außerhalb der Spec liegen 
dürfte.

Probiere es mal mit PCLK = 4, damit wird die zweite PLL nicht verwendet 
und mit den dann geteilten 72MHz sind es 63,4Hz.
Oder mit PCLK = 1 und PCLK_FREQ = 17000000 wären es 59,89Hz, der Aufwand 
lohnt sich wohl aber eher nicht.

Wo kommen die Timing-Werte her? In dem "Datenblatt" von der Webseite 
habe ich die nicht gefunden.

[Spyy (Gast)]

Rudolph R. schrieb:
> Probiere es mal mit PCLK = 4, damit wird die zweite PLL nicht verwendet
> und mit den dann geteilten 72MHz sind es 63,4Hz.
> Oder mit PCLK = 1 und PCLK_FREQ = 17000000 wären es 59,89Hz, der Aufwand
> lohnt sich wohl aber eher nicht.

Ok habe ich gemacht (PCLK = 4) bekomme dann:

EVE clock: 34661499
EVE frames: 31

=> Irgendwie ist bei mir alles "durch 2" geteilt...31 * 2 => 62Hz


???? wo liegt der Fehler ? Ich habe keinen externen Quarz dran...???

Uff...Sch****e

[Spyy (Gast)]

und wenn ich in das Register gar nix reinschreibe
  #if EVE_GEN > 2
  //EVE_cmdWrite(EVE_CLKSEL,0x46); /* set clock to 72 MHz */
  #endif
=> laut Datenblatt dann default => 60 Mhz
bekomme ich das hier:
EVE clock: 28931524


Also 29 Mhz und mit

[Rudolph R. (rudolph)]

Wo hast Du keinen externen Quarz dran?
An dem BT817/BT818?
Dann wird ja einfach nur der interne RC-Oszillator verwendet, der hat 
auch 12Mhz. Der ist nur nicht unbedingt so präzise oder 
temperatur-stabil wie ein Quarz oder Resonator.

Wenn ich in dem EVE_RiTFT50 Profil das EVE_HAS_CRYSTAL auskommentiere 
dann komme ich immer noch auf 65Hz.
Aber die Anzeige für den Takt ändert sich jede Sekunde.
72077473
72093395
72077258
72066016
72101521

Jetzt nicht in der Reihenfolge.

Mit Quarz ändern sich höchstens mal die letzten zwei Stellen
72001727
72001719
72001734
72001727
72001726

Da würde ich dann aber eher vermuten das die Sekunde Mess-Intervall auch 
mal ein paar Taktzyklen mehr oder weniger haben kann.

[Rudolph R. (rudolph)]

Spyy schrieb:
> => laut Datenblatt dann default => 60 Mhz
> bekomme ich das hier:
> EVE clock: 28931524
>
> Also 29 Mhz und mit

Du misst nicht einmal pro Sekunde, sondern zwei Mal?

[Spyy (Gast)]

Ich habe zu früh auf senden gedrückt...

Ich messe so:
  // Write the EVE stats:
  uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
  delay(1000);
  uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
  Serial.print("EVE clock: ");
  Serial.println(eveClockNew - eveClockOld);

Also Wert lesen dann eine Sekunde warten dann nochmal lesen und 
voneinander abziehen...

Wie auch schon gesagt die Messergebnisse spiegeln auch das reale 
Verhalten wieder...bekomme immer nur 1/2 Framerate und bei ca. 25 ms 
Schreibzyklen Probleme mit der Displaylist..
und das delay(1000) sind wirklich 1 Sekunde...

[Rudolph (Gast)]

Dazu fällt mir jetzt nicht mehr wirklich was ein.

Miss das mal nachdem die EVE_init() durch ist, packe noch ein 
delay(1000) vor das erste Lesen des Registers und ziehe mal einen Trace 
davon mit dem Logic-Analyzer.

[Spyy (Gast)]

Ja mir leider auch nicht....aber...

Wenn ich das hier eintrage:
EVE_cmdWrite(EVE_CLKSEL,0x10);

bekomme ich das hier:
EVE PCLK Frequency: 60000000
EVE clock: 72306594
EVE frames: 102

ach so: Ich habe den BT818....also den neuen

Ich glaube das mit dem CLKSEL funktioniert nicht richtig...wenn ich da 
0x00 eintrage bekomme ich keine 60 Mhz....
Erst wenn ich im hohen "nibble" ne 1 eintrage bekomme ich 72

Keine Ahnung, ich habe mal im BRT Forum die Frage gestellt...mal 
sehen...

[Rudolph (Gast)]

Kannst Du das mit was anderem als dem Teensy ausprobieren?
Etwa mit einem Arduino Uno?

Die Frage wurde im BRT Forum ja schon das letzte Mal nicht wirklich 
beantwortet.
Und die Antwort fand ich jetzt nicht direkt hilfreich.

Vielleicht sollte ich mir mal einen Teensy 4 zulegen.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Vielen Dank für die Erklärungen zum Co_Prozessor. Das alles, was ab 
Kapitel 5 steht habe ich natürlich auch schon gelesen. Ich nutze auch 
nur noch den FT813, also was mal war, interessiert mich demzufolge auch 
nicht (mehr). Dennoch steht es im Programmer-Guide des FT813 noch so 
drin??!!!
Meine Frage nach KONKRET war ja diese:
Ich sende per SPI 7 Bytes:
Hx302574 (Reg_CMDB_Write) gefolgt von FF FF FF 31 (CMD_LOGO). Richtig? 
Blödsinn? Fertig?!?! Ich nehme an, auch hier muss das Register 
eigentlich mit HxB0.. (statt Hx30...) gesetzt werden, weil ja das erste 
Bit ein H sein muss.
Habe auch beides ausprobiert.
Das ist natürlich nicht das Einzigste, was ich seit Tagen immer wieder 
ausprobiere. Aber bisher geht es einfach nicht.
Einmal das grundlegende Prinzip...!!!! Ich denke schon, dass ich dann 
mit allen anderen Befehlen klar komme. Warum kann so etwas nicht im 
Datenblatt konkret drin stehen?

[Rudolph R. (rudolph)]

Um per Reg_CMDB_Write das Kommando CMD_LOGO zu senden wäre diese Sequenz 
richtig:

0xb0 0x25 0x78 0x31 0xff 0xff 0xff

Aus mysteriösen Gründen ist nämlich die Byte-Order für die Adressen 
anders als für die Daten.

Das steht auch alles im Datenblatt und Programming Guide, das muss man 
nur erstmal finden.
Da bist Du nicht der Erste der darüber stolpert und ganz sicher nicht 
der Letzte.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Ich glaub das jetzt nicht!!!!!!!!!! Jetzt läuft tatsächlich die 
Logo-Animation ab!!!! Na vielen herzlichen Dank.

[Rudolph R. (rudolph)]

Das RVT101HVBNWC00-B ist heute angekommen und funktioniert spontan. :-)

Die 10.1" sind schon heftig groß und das Panel ist derbe hell.
Mein Handy schaltet das Bild dunkler weil diese Leucht

Im Moment versorge ich das mit 9V über eine Verpolschutz-Diode.
Damit zieht das ganze System 360mA bei 25% (0x20) PWM für die 
Beleuchtung.

Edit: wenn ich die Beleuchtung abschalte zieht das System noch 185mA.
Mit so 10mA für die 5V Seite liefert der 3,3V Stepdown gerade so um 
500mA um das Display zu versorgen.

Die Hintergrund-Beleuchtung läuft gerade direkt mit den 9V (oder 8,xV 
nach der Diode) und davon werden noch 3,3V per Schaltregler für das 
Display und 5V per LDO für mein Controller-Board erzeugt.

Die nächsten Versionen von meinem Display-Adapter und Controller-Board 
mit Display-Anschluss werden wohl einen 9V Step-Down und einen 3,3V 
Stepdown haben.

Den Pixel-Clock habe ich von 72MHz auf 71MHz runter gedreht, sind immer 
noch 60 FPS, rechnerisch sollten das 58,58 FPS sein.
Das "Frequency" in der Anzeige ist der Takt mit dem der BT817 selber 
läuft.

Jetzt läuft erst mal der nächste Testdruck für das Gehäuse dazu - 5h.

Edit 2: ich musste die Hintergrundbeleuchtung auf 0x10 runter drehen, 
die Leuchtkachel ist mir am Schreibtisch echt zu heftig.
Das sind dann noch 270mA aus 9V.

[Spyy (Gast)]

Rudolph schrieb:
> Vielleicht sollte ich mir mal einen Teensy 4 zulegen.

Unbedingt!!!! Ich habe hier noch einen liegen...würde ich Dir 
spendieren....

Die Antwort auf meine Frage im BRT 
Forum...ist...ja...etwas...ähm...naja...

[Rudolph (Gast)]

Der Teensy 4.1 ist schon im Versand, das war die Gelegenheit mal wieder 
bei Reichelt zu bestellen. :-)

[Arnaud S. (arnsch)]

Guten Tag,

Viele Danken für ihren Arbeit an diese Library ! Einschuldigung, mein 
Deutsch ist ein bisschen schwach, so ich will auf Englisch weiter 
schreiben.

I am currently working on the RiTFT-35-FR (BT816) from Riverdi with a 
Teensy 3.5 and your library.
I now have good results with the display, but still runs into somes 
issues.

As it could help someone, I will first give some infos about what I did 
and the issues I had:

1) I am having good results with the EVE_EVE3_35 configuration, and 
since it is marked as untested in EVE_config.h, I am sure you would be 
happy to know ;)

2) At first I could not display anything due to SPI transmissions errors 
using Teensy 3.5, while it was totally fine with an Arduino Nano.
I found that using terminating resistors on signals generated by Teensy 
(SCK and MOSI) solved this. Currently using 30 Ohms, but it seems the 
value depends on the length of the wires.
From what I read, it seems like a common issue while using SPI with a 
Teensy.

Now, I still sometimes encounter unstabilities while communicating with 
the BT816,
so I tried to lower the SPI clock frequency as much as I could, but I 
can't go below circa 500kHz...
What happens next is that I am still partially able to write and read 
registers, but nothing appears on the screen

I had better read/write performances by using TFT_init() at higher SPI 
speed, and then lowering it, but still nothing on the screen.
I verified the frequency with an oscilloscope, and everything seems 
fine.

Can't tell whether the BT816 or Teensy is the issue here.

Do you have any info on that ?

Guten Abend,

Arnaud

[Rudolph R. (rudolph)]

Thank you and Englisch is just fine.
While updating all the different platforms in PlatformIO I checked the 
parameter sets for RiTFT-35 and EVE3-35 in my spreadsheet.
And while most of the parameters are the same or close enough,
a couple are not the same.
CLKPOL and SWIZZLE are different.
I'll check with the datasheet.
And as I also noticed now, there is no RiTFT-35 profile in EVE_config.h, 
yet.

Regarding the Teensy 3.5, did you add anything for it to EVE_target.h / 
EVE_target.c? Or are you just using the default Arduino target?

As so far with the Teensy 4.1, I can add it to the platformio.ini and 
check if it compiles, but I can not test it.
Which pins are you using for what?

[Rudolph R. (rudolph)]

I just added 
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO 
as a first step.

The platformio.ini has a teensy35 target and while it already build with 
the default Arduino setup I went ahead and changed EVE_target.h and 
EVE_target.cpp to put ARDUINO_TEENSY35 on the same target as 
ARDUINO_TEENSY41 which should enable DMA.

And of course EVE_config.h has a profile for RiTFT35 now.

Please test.


For some strange reason the nucleo_f446re target no longer builds after 
I updated the platform to the latest version.


----
Processing nucleo_f446re (platform: ststm32; board: nucleo_f446re; 
framework: arduino)
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
---------------------------------------------Verbose  mode can be 
enabled via `-v, --verbose` option
CONFIGURATION: 
https://docs.platformio.org/page/boards/ststm32/nucleo_f446re.html
PLATFORM: ST STM32 (14.0.0) > ST Nucleo F446RE
HARDWARE: STM32F446RET6 180MHz, 128KB RAM, 512KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, 
cmsis-dap, jlink)
PACKAGES:
 - framework-arduinoststm32 4.20000.210601 (2.0.0)
 - framework-cmsis 2.50700.210515 (5.7.0)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
Converting src.ino
ImportError: cannot import name 'IS_WINDOWS' from 'platformio.compat' 
(c:\users\ich\.platformio\penv\lib\site-packages\platformio\compat.py):
  File 
"C:\users\ich\.platformio\penv\lib\site-packages\platformio\builder\main 
.py",  line 177:
    env.SConscript("$BUILD_SCRIPT")
  File 
"C:\Users\Ich\.platformio\packages\tool-scons\scons-local-4.1.0\SCons\Sc 
ript\SConscript.py",  line 591:
    return _SConscript(self.fs, *files, **subst_kw)
  File 
"C:\Users\Ich\.platformio\packages\tool-scons\scons-local-4.1.0\SCons\Sc 
ript\SConscript.py",  line 280:
    exec(compile(scriptdata, scriptname, 'exec'), 
call_stack[-1].globals)
...
----

Whatever, not my fault, nothing I did there, I hope this gets fixed.

[Spyy (Gast)]

Rudolph schrieb:
> Der Teensy 4.1 ist schon im Versand

Ok...super, wäre schön wenn Du von Deinen Erfahrungen hier berichten 
könntest. Aus dem Beitrag von Amaut könnte man ja auch schliessen, das 
es hier ein Problem gibt...

@Amout: The resistor of 30Ω you are using is connected in serial to the 
signal line or signal to ground?

[Rudolph R. (rudolph)]

I am using one of these with all the third-party boards:
https://github.com/RudolphRiedel/EVE_display-adapter

[Arnaud S. (arnsch)]

Rudolph R. schrieb:
> Regarding the Teensy 3.5, did you add anything for it to EVE_target.h /
> EVE_target.c? Or are you just using the default Arduino target?

I was using the default Arduino target, and changed a few pin 
definitions to suit my needs:
- PDN changed from 8 to 9
- CS changed from 9 to 10
- SPI Clock Output changed from 13 to 14 (specific to Teensy boards)

Rudolph R. schrieb:
> The platformio.ini has a teensy35 target and while it already build with
> the default Arduino setup I went ahead and changed EVE_target.h and
> EVE_target.cpp to put ARDUINO_TEENSY35 on the same target as
> ARDUINO_TEENSY41 which should enable DMA.
>
> And of course EVE_config.h has a profile for RiTFT35 now.
>
> Please test.

I implemented your changes into my code, and it seems to work.
First took the new screen profile, and then changes in EVE_target.cpp 
and EVE_target.h.
I can't confirm that I have better performances, but it seems to work as 
good as before.

Spyy schrieb:
> @Amout: The resistor of 30Ω you are using is connected in serial to the
> signal line or signal to ground?

I put those resistors in series to the signal line, and placed as close 
as possible to the source of the signal

[Rudolph (Gast)]

Now I am mildly confused. :-)

What about:
>What happens next is that I am still partially able to write and read
>registers, but nothing appears on the screen
>
>I had better read/write performances by using TFT_init() at higher SPI
>speed, and then lowering it, but still nothing on the screen.

Does it display anything now?

>I can't confirm that I have better performances, but it seems to work as
>good as before.

Going from no output to no output would also mean it is "as good as 
before" :-)

>I was using the default Arduino target, and changed a few pin
>definitions to suit my needs:
>- PDN changed from 8 to 9
>- CS changed from 9 to 10
>- SPI Clock Output changed from 13 to 14 (specific to Teensy boards)

How can SCK0 be changed to pin 14?

Have you tried to directly run my simple demo?
CS is set to pin 9 now in line 1474 though.

I just checked https://www.pjrc.com/teensy/pinout.html
And according to this, SCK is on 13 for Teensy 3.5 and 4.1.
The several CS0 pins must be for Hardware-Controlled chip-select but I 
am directly using an I/O pin, CS = 10 and PDN = 9 is just fine.

What I really do not like about the Teensy, now that I have seen this, 
the SCK pin is not next to MISO and MOSI but on the opposite side.
And that there is a LED with a 470R resistor connected to SCK, looks 
like one of the first things I will do with the Teensy 4.1 is to remove 
the resistor as changing the pin for SCK0 does not seem to be an option.

[Arnaud S. (arnsch)]

Rudolph schrieb:
> Going from no output to no output would also mean it is "as good as
> before" :-)

I should have been more precise about the results, sorry about that :D

It does display what I want on the screen (basically some static text 
with variables), but I still run into the SPI frequency issue : low 
frequency = no output. So I use 1MHz at the moment.

I also suffer from screen freezes after some time, and am currently 
investigating this... Do you have any recommendations for monitoring the 
screen status ?

SCK0 (and other SPI-involved pins) can be switched using 
SPI.setSCK(_pin_num) which is part of the SPI library, and works for all 
compatible alternate pins
(see https://www.pjrc.com/teensy/td_libs_SPI.html for more info)

Rudolph schrieb:
> Have you tried to directly run my simple demo?

I tweaked some parameters to fit my pin definitions, and it failed. I 
did not investigate any further for the moment. It is on my todolist, I 
can retry to do that tomorrow.

Rudolph schrieb:
> What I really do not like about the Teensy, now that I have seen this,
> the SCK pin is not next to MISO and MOSI but on the opposite side.
> And that there is a LED with a 470R resistor connected to SCK, looks
> like one of the first things I will do with the Teensy 4.1 is to remove
> the resistor as changing the pin for SCK0 does not seem to be an option.

I totally agree, it is quite a mess to use. And this LED is one of the 
reason I changed it to pin 14.

[Rudolph (Gast)]

My Teensy 4.1 arrived so later I am doing some hands-on experiments with 
it. :-)

My basic demo shows the time it takes for a display-refresh:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

That is without DMA.

https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/EVE2-50G_ATSAMC21.jpg

And this is with DMA.
The "Bytes" is the number of bytes sent for a display-refresh and 
without DMA this information is not available.

I am always using the same setup across platforms, my main.c or src.ino 
is executing the display functions in a 5ms intervall.
The touch and some debug-information is read every time.
The display-refresh is done every fourth time for 20ms refresh.

So the demo sends 224 bytes and the resulting display-list hast a length 
of 784 bytes, a little less without DMA.
The 51µs are not the time it takes to send 224 bytes, this is only the 
time the controller is busy preparing the DMA buffer.
At 8MHz the SPI is busy for annother 224µs, at 1MHz for annother 1,8ms.
And without DMA this takes longer since there are pauses between the 
bytes depending on the speed of the controller and the SPI 
implementation.

The touch-function is checking if a transfer is ongoing but if there 
would be more bytes to be send at a low speed the first thing that would 
happen is that the next reading of the touch events would be skipped.

So you need to keep an eye on the amount of bytes send, the resulting 
display-list needs to stay below 8k and the packets need to be 
transferred in time.
This is why I never put the logic-analyzer out of reach. :-)

[Spyy (Gast)]

My Teensy 4.1 arrived so later I am doing some hands-on experiments with
it. :-) => Great!!!!

And if you have time can you please code this into the EVE_Init() near 
the end of function and report the results :)) with the setting 
EVE_cmdWrite(EVE_CLKSEL,0x46);

 Write the EVE stats:
  uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
  delay(1000);
  uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
  Serial.print("EVE clock: ");
  Serial.println(eveClockNew - eveClockOld);

Do you have a BT817 or a BT818 ?

[Spyy (Gast)]

Arnaud S. schrieb:
> I also suffer from screen freezes after some time, and am currently
> investigating this

This is exacly the reason why i am struggling with my setup too...with 
Teensy 4.1

I am using:
-SPI: 20 Mhz
-DMA for SPI
-Pins: standard for SPI channel 0 (10, 11, 12, 13)
-Display list well below 8k (approx. 3700 bytes)
-Refresh rate of display 102 Hz


With 20 ms data refresh rate to BT818 it stalls immediately (SPI LED is 
full on display freezes), 21 ms works.
Tried to tweak the SPI speed to 10 Mhz or lower makes no difference

[Rudolph R. (rudolph)]

Well, what shall I say, there might be an issue with the hardware as it 
only started to work after I re-connected the Logic Analyzer.
It pretty much worked right out of the box including DMA.
I only changed CS to 10 and PD to 9.

I also tried a couple of different SPI speeds now, default is 8MHz, 
1/2/4/6 MHz work just fine albeit not necessary at the exact select 
frequency.
6MHz is more like 6.25MHz.
Increasing the speed after TFT_init() also works, 10/12/16/20 MHz, no 
issue.
Setting up 100MHz by accident did not work though. :-)
Going slower than 925kHz is not working in the sense that the Teensy 4.1 
will not clock the SPI any slower than that.
I tried 500k, 200k, now 800k, the result is 925kHz.
So well, there are limitations what the chip can do, not an issue.

Hmm, I just tried to disconnect the Logic Analyzer and I need to keep it 
connected to CS and SCK.
So I am left with a hardware issue in my setup and a couple of pF as 
extra load seem to fix it.

The "shadow" on the display or rather the brighter area is just a 
rolling shutter effect, I took three pictures with my phone and between 
these this is clearly mooving.

To confirm the Frequency and Frames/s measurement I just checked the 5ms 
intervall derived from millis() with the logic-analyzer and the first 
falling edge of CS from one block to annother.
And it is spot-on, 5,00032ms.
The is 64µs more every second if this is stable which at least partly 
accounts for the little more than 72000000.

Oh yes, before I even connected the Teensy 4.1 for the first time I 
removed the LED resistor R1.

[Rudolph R. (rudolph)]

Ich habe jetzt auf das RVT101H gewechselt, 10,1", 1280x800, BT817.
Clock ist auf 20MHz hoch gedreht, CS und SCK sind immer noch mit dem 
Logik-Analzyer verbunden.

Spyy schrieb:
> And if you have time can you please code this into the EVE_Init() near
> the end of function and report the results :)) with the setting
> EVE_cmdWrite(EVE_CLKSEL,0x46);
>
>  Write the EVE stats:
>   uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
>   delay(1000);
>   uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
>   Serial.print("EVE clock: ");
>   Serial.println(eveClockNew - eveClockOld);

I changed it in tft.cpp like this:

uint32_t clock_test;

void TFT_init(void)
{
  if(EVE_init() != 0)
  {
    uint32_t eveClockOld = EVE_memRead32(REG_CLOCK);
    delay(1000);
    uint32_t eveClockNew = EVE_memRead32(REG_CLOCK);
    Serial.print("EVE clock: ");
    Serial.println(eveClockNew - eveClockOld);
    clock_test =  eveClockNew - eveClockOld;

It compiles, it uploads but I get nothing on the console.
Yes, I also added "Serial.begin(9600);" in src.ino.
So I added that var to print it on screen.

  EVE_cmd_text_var_burst(20, 160, 28, EVE_OPT_FORMAT, "Frequency: 
%d",1,clock_test);

The output of this line is: "Frequency: 72003042"
And the measurement I am taking every second now and printing it to the 
screen shows around 72002400.

[Arnaud S. (arnsch)]

So as promised, I retried your demo, only changed SPI SCK pin to 14, PDN 
and CS, and it worked ! (see demo_result.png).

But only for a rather short duration, after which I ran into the same 
issue as with my actual project : Screen freeze.
I began to monitor registers:
-CMD_READ and CMDB_SPACE to check if there was any issue with the 
commands we sent
-CPURESET to check if the chip was still running.

I am using USB Serial to directly read the values, which are read and 
sent every 500ms. Registers are read after display functions are 
executed.

And my observations are similar for both the demo code and my project:

Everything starts fine and screen is displaying what it should :
CMDB_SPACE = 4092 so RAM_CMD is empty and every commands have been 
executed

-CMD_READ != 0xFFF, so no coprocessor fault !
-CPURESET = 0, coprocessor is running

And then screen freeze,

-CMDB_SPACE != 4092 : RAM_CMD not empty
-CMD_READ != 0xFFF, still no coprocessor fault
-CPURESET = 0, coprocessor is still running

(see demo_registers_log.png : everything is fine for the first 4 
readings, using your demo code)

It is interesting to see that in the case of my project (not the demo, 
see own_project_OK.ng and ...NOK.png), CMDB_SPACE stays the same, and I 
am pretty sure that I am not sending any commands between registers 
readings*, so it seems the chip is not reading commands in RAM_CMD 
anymore.
But that is my own interpreatation, what do you guys think about this ?

*using if(!EVE_busy()) at the beginning of my display function to avoid 
that.

[Spyy (Gast)]

1000 thanks for your effords!!!

Rudolph R. schrieb:
> The output of this line is: "Frequency: 72003042"

Boah....this is....what the helll...

Ok...the only difference to my setup is i am using a BT818 and no 
external chrystal...

[Spyy (Gast)]

Arnaud S. schrieb:
> But that is my own interpreatation, what do you guys think about this ?

I have also no explenation for this...can you print out the clock 
frequency of your chip and the framerate of your screen?

The bahaviour of the registers before stalling here was the same you 
see...my feeling is the same, writings to the fifo stop or 
delays...whyever

I have SPI set to 20 Mhz, burst
LED to SCK still connected, standard pins 10, 11, 12,13
I have now 72 MHz with EVE_cmdWrite(EVE_CLKSEL,0x10); (which is an 
illegal setting, but it seems to work), and set the framerate to 102Hz, 
then i can run the demo with update rate of approx. 10 ms, but only with 
approx. 300 bytes of display list (i modified the demo a bit, i have no 
touch)

[Rudolph (Gast)]

At what speed are you running this?

This very much looks like a hardware issue, also what Spyy reports.
Your Riverdi Click board is nothing but a breakout board, it is 
completely passive and not buffered.
So the SPI is only driven by the MK64FX512VMD12 on your Teensy 3.5.
The drive strength for this 3.3V controller should not exceed 4mA, if 
it is configured to maximimum drive strength to begin with.
Same with the Teensy 4.1 and its IMXRT1062DVJ6A.

My display adapter board has drivers for all signals, one property of 
these is that the ones I am using are 5V tolerant even though these are 
powered with 3.3V, the other property is the decoupling from the 
controller, there is less load on the lines for the controller and their 
drive strength is a lot higher.
I have two 74LVC2G17 for SCK, MOSI, CS and PD plus one 74VHC1GT125 for 
MISO.


I configured my Teensy 4.1 to 20MHz and tried to measure the lines with 
an oscilloscope.
Well, tried, at 20MHz there is not much left to be measured.
And the CS line showed rather slow signal changes, even with no load 
except the probe from the oscilloscope.
I tried to change the frequency but using Arduino 1.8.13 plus 
Teensyduino resulted in no activity at all anymore on the SPI lines 
despite compiling and uploading worked.

Next, where do you get the 3.3V from to power the display?

I have a 3,3V stepdown regulator on my adapter to power the logic and 
the display module.
I can power the backlight from either the input voltage or from the 
generated 3.3V.
For the RVT101H I am supplying my adapter with 9V and use that for the 
backlight as well, most modules require a maximum backlight voltage of 
5V though or are even locked into using the 3.3V for the logic supply.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudi,
es ist schon zum Verzweifeln. Ich bekomme das einfach nicht hin. Am 
liebsten möchte ich einen Arbeitstag zu Dir kommen und die wichtigsten 
Punkte Stück für Stück durchgehen... Wie hoch ist Dein Tagessatz???
Nachdem nun also die FTDi-Animation funktioniert, möchte ich mal einen 
Buttom setzen. Ich sende an Adresse REG_CMDB_Write:
4 Byte 0D : FF : FF : FF   (CMD_BUTTON)
4 Byte X und Y -Koordinaten (0 : 200 : 0 : 100)
4 Byte Höhe x Breite (0 : 50 : 0 : 30)
2 Byte Font (0 : 31)  - richtige Reihenfolge???
2 Byte Option (0 : 0) - erst mal
4 Byte Text mit "Null" am Ende ("O" : "K" : "Ausrufezeichen" : 0)
Gesamt 20 Byte, also ein Vielfaches von 4.

Ich habe schon verschiedene Varianten (z.B. bei den Koordinaten und/oder 
Höhe und Breite) durch probiert, verschiedene Reihenfolgen der beiden 
Bytes z.B. Hilft alles nichts. Oder müssen die "Nullen" bei Fonts und 
Option vielleicht mit FF aufgefüllt werden, oder, oder ?
Was mache ich hier wieder alles falsch ?????????????????

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Am liebsten möchte ich einen Arbeitstag zu Dir kommen und
> die wichtigsten Punkte Stück für Stück durchgehen...
> Wie hoch ist Dein Tagessatz???

Das will ich gar nicht wissen, nicht-selbständig zu arbeiten hat den 
deutlichen Vorteil das ich mich nur minimal mit dem Finanzamt 
herumärgern muss. :-)

Bernd I. schrieb:
> Nachdem nun also die FTDi-Animation funktioniert, möchte ich mal einen
> Buttom setzen. Ich sende an Adresse REG_CMDB_Write:
> 4 Byte 0D : FF : FF : FF   (CMD_BUTTON)
> 4 Byte X und Y -Koordinaten (0 : 200 : 0 : 100)
> 4 Byte Höhe x Breite (0 : 50 : 0 : 30)
> 2 Byte Font (0 : 31)  - richtige Reihenfolge???
> 2 Byte Option (0 : 0) - erst mal
> 4 Byte Text mit "Null" am Ende ("O" : "K" : "Ausrufezeichen" : 0)
> Gesamt 20 Byte, also ein Vielfaches von 4.

Sowas muss ich inzwischen auch nachschauen, wenn nur irgendwer eine 
Library für sowas schreiben würde... :-)

Meine Funktion dazu sieht so aus:

void EVE_cmd_button(int16_t x0, int16_t y0, int16_t w0, int16_t h0, int16_t font, uint16_t options, const char* text)
{
  if(!cmd_burst)
  {
    eve_begin_cmd(CMD_BUTTON);
    spi_transmit((uint8_t)(x0));
    spi_transmit((uint8_t)(x0 >> 8));
    spi_transmit((uint8_t)(y0));
    spi_transmit((uint8_t)(y0 >> 8));
    spi_transmit((uint8_t)(w0));
    spi_transmit((uint8_t)(w0 >> 8));
    spi_transmit((uint8_t)(h0));
    spi_transmit((uint8_t)(h0 >> 8));
    spi_transmit((uint8_t)(font));
    spi_transmit((uint8_t)(font >> 8));
    spi_transmit((uint8_t)(options));
    spi_transmit((uint8_t)(options >> 8));

    private_string_write(text);
    EVE_cs_clear();
  }
}

Das eve_begin_cmd() setzt CS, sendet die Adresse, sendet das Kommando,
soweit nichts neues.

Also bei den Daten das niederwertigste Byte zuerst.

0x0d 0xff 0xff 0xff
0xc8 0x00
0x64 0x00
0x46 0x00
0x28 0x00
0x1c 0x00
0x00 0x00
0x4f
0x4b
0x21
0x00

Ja, Breite und Höhe habe ich angepasst und einen kleineren Font 
verwendet.
Das passte nämlich nicht auf den kleinen Button. :-)

Und der Text ist eine Folge von Bytes.

Hmm, wie sieht das eigentlich aus wenn einen UTF-8 Font verwendet und 
auf dem Button "nö!" steht?
So: 0x6e 0xc3 0xb8 0x21 0x00 0x00 0x00 0x00

Also am Ende vom String steht immer 0x00 und die nächsten drei 0x00 sind 
zum Auffüllen bis zum nächsten 32-Bit Wort.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Im Prinzip habe ich es schon so gemacht, nun aber noch einmal penibel 
alles genau so eingegeben, wie Du es aufgeschrieben hast. Geht dennoch 
nicht.
Ich denke das Problem ist folgendes (und ich oute mich jetzt mal wieder 
ein bisschen):
Ich weiß nicht einmal, was ich alles eventuell zuerst noch definieren 
muss. Wie gesagt, bisher habe ich ja ohne Co-Prozessor gearbeitet. Und 
dabei habe ich es nicht einmal geschafft, den Bildschirm am Beginn zu 
löschen (mit RGB = 1,1,1 und bCLEAR - hier habe ich nur senkrechte bunte 
Streifen). Das habe ich seit Jahren ignoriert, indem ich gleich zu 
Beginn (nach der Initialisierung des Display) dann ein RECT in der Größe 
des Display setze (bzw. mehrere RECTS stets um ein Pixel kleiner werdend 
mit dunkler werdender Farbe, so dass sich ein Bildschirm mit 
"beleuchteten" Rand ergibt (siehe Anhang). So beginnt jeder 
Bildschirm-Aufbau und dann folgend die gewünschten Primitives. Mit 
diesen Datenblättern, die einfach so chaotisch aufgebaut sind, habe ich 
so meine Probleme. Vor einem halben Jahr habe ich zum ersten mal einen 
LED-Treiber (IS31FL3737) in Betrieb nehmen wollen. Der kann 144 Einzel- 
bzw. hier 48 RGB in einer 12x12 Matrix ansteuern. Funktioniert nun 
super, NACHDEM ich mir ein Demo-Board (was es zum Glück dafür gab) 
kaufte und dort die I2C-Schnittstelle mitgelesen hatte. Das Datenblatt 
passt genauso in diese Kategorie: Schlimmer geht's nicht. Das hätte ich 
ohne das Board nie herausgefunden.
Naja und so habe ich mir meine Bibliothek für Buttons usw. geschaffen. 
Ich gebe nur noch gegebenenfalls die Koordinaten ein und lasse dann das 
Unterprogramm ausführen und habe auch 3D-Effekte und Farben, wie ich es 
will, die Tasten "versenken" sich beim Betätigen. So sieht eben auf dem 
Foto z.B. meine alpha-numerische Tastatur aus (ohne Co-Prozessor).

Zurück zur eigentlichen Sache:
Wenn ich zuerst MEIN Bildschirm (wie Foto - nur das Grün) auf 
herkömmliche Art setze und dann die Animation starte - das funktioniert. 
Nun passierte beim Experimentieren folgendes: Nach 3 Sekunden (die ich 
einfach warte bis zum Ende der Animation) gab ich mal versuchsweise den 
Befehl: CMD_DLStart und dann den Buttom-Befehl. Da spielte die 
FTDi-Animation ein 2. mal ab!!! Aber kein Buttom kommt.
Mir ist das ganze Prinzip einfach noch völlig unklar: Muss ich den 
gesamten Bildschirm mit 15 Elementen in einem "Atemzug" an den 
Reg_CMDB_Write senden, oder kann ich hier auch anhängen, oder sende ich 
nacheinander die einzelnen Elemente , oder, oder. Oder muss der 
Reg_CMDB_Write etwa gemäß den schon gesendeten Bytes aufaddiert werden 
(Reg_CMDB_Write + Anzahl schon gesendeter Bytes)? Was muss am Beginn 
noch definiert/gesetzt werden (außer alle Register für den richtigen 
Betrieb des Display natürlich)? Also Du merkst: Grundsatzfragen. Wenn 
ich nicht jetzt in diesem Zugzwang wäre, Bitmaps darstellen zu müssen, 
würde ich mir diesen ganzen Ärger nicht antun. Habe auch schon das Netz 
durchforstet, aber eine andere Hilfe, als dieses Forum und solch einen 
Spezialisten, wie Dich, habe ich nicht gefunden.

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Nach 3 Sekunden (die ich
> einfach warte bis zum Ende der Animation) gab ich mal versuchsweise den
> Befehl: CMD_DLStart und dann den Buttom-Befehl. Da spielte die
> FTDi-Animation ein 2. mal ab!!! Aber kein Buttom kommt.

Das ist seltsam, wenn das wirklich kein CMD_LOGO war muss das noch 
irgendwo im Speicher gewesen sein.

> Mir ist das ganze Prinzip einfach noch völlig unklar: Muss ich den
> gesamten Bildschirm mit 15 Elementen in einem "Atemzug" an den
> Reg_CMDB_Write senden, oder kann ich hier auch anhängen, oder sende ich
> nacheinander die einzelnen Elemente , oder, oder.

Die Kommandos können alle einzeln geschickt werden, das hat allerdings 
den Nachteil das man auch jedes Mal die 3-Byte Adresse für 
Reg_CMDB_Write senden muss.
Das geht auch in kleinen Kommando-Gruppen oder eben als komplettes 
Paket.
Ich mache das für gewöhnlich als ganzes Paket, zum einen geht das am 
schnellsten, zum anderen benutze ich ohnehin vorzugsweise DMA.

> Oder muss der Reg_CMDB_Write etwa gemäß den schon gesendeten
> Bytes aufaddiert werden
> (Reg_CMDB_Write + Anzahl schon gesendeter Bytes)?

Nein, das ist das tolle an REG_CMDB_WRITE, einmal als Adresse angeben am 
Anfang des Transfers und für zumindest die nächsten 4k am Stück passiert 
alles automatisch.

> Was muss am Beginn
> noch definiert/gesetzt werden (außer alle Register für den richtigen
> Betrieb des Display natürlich)? Also Du merkst: Grundsatzfragen.

Glaub mal nicht, dass ich mich damit nicht herum schlagen musste. :-)

Eine Display-Liste mit dem Coprozessor zu erstellen ist ja erstmal nicht 
anders als direkt in den Speicher der Display-Listen zu schreiben.

Es gibt eben am Anfang das CMD_DLSTART was nichts anderes macht als dem 
Co-Prozessor zu sagen, lege mal eine Display-Liste an.

Das DL_DISPLAY am Ende ist ja nichts weiter als eine Nullbyte-Kennung 
für die Raster-Einheit das die Liste da zu Ende ist, das kennst Du ja 
auch schon.
Und CMD_SWAP ist dann als letzes auch nichts anderes als DLSWAP_FRAME 
direkt in das REG_DLSWAP Register zu schreiben, nur weiß der 
Co-Prozessor damit dann auch, dass das alles war für die Display-Liste.

Nach dem CMD_DLSTART habe ich immer:
(DL_CLEAR_RGB | WHITE)
(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG)
TAG(0)

Wobei TAG(0) eigentlich überflüssig sein sollte, aber ich habe keine 
Idee mehr wann und warum ich das da reingesetzt habe und es funktioniert 
so. :-)

Als nächstes benutze ich CMD_APPEND und das ist das erste spezielle 
Kommando, damit kopiert der Co-Prozessor ein zuvor vorbereitetes 
Fragment Display-List aus RAM_G in die neue Display-Liste, da packe ich 
immer alles rein was ich bei einem Bildwechsel nicht ändert.

Naja, und so weiter, man bekommt mit dem Co-Prozessor einfach mehr 
Funktionen, von den Display-Listen Kommandos die einfach nur kopiert 
werden braucht man aber dennoch reichlich.

> Wenn ich nicht jetzt in diesem Zugzwang wäre,
> Bitmaps darstellen zu müssen,
> würde ich mir diesen ganzen Ärger nicht antun.

Also eigentlich braucht man dafür den Co-Prozessor nicht, das ist 
nicht einfacher.
Statt CMD_SETBITMAP kann man das auch über die Display-Listen Kommandos 
machen, das ist mit CMD_SETBITMAP nur bequemer.
BITMAP_LAYOUT, BITMAP_SIZE, BITMAP_SOURCE, etc.
Dann braucht man ein (DL_BEGIN | EVE_BITMAPS), VERTEX2F und DL_END.

Buttons gehen auch "von Hand", wenn man viel braucht fressen die als 
CMD_BUTTON ohnehin schnell die Display-Liste.

Aber die Widgets zu ersetzen wäre mir echt zu anstrengend.
Ganz vorne dabei CMD_TEXT und CMD_NUMBER.

> Habe auch schon das Netz
> durchforstet, aber eine andere Hilfe, als dieses Forum und solch einen
> Spezialisten, wie Dich, habe ich nicht gefunden.

Ich bin dann mehr auf der technischen Seite unterwegs, was bringt die 
Dinger zum Ticken, SPI, Register, Hardware und so.
Auf der Anwendungsseite habe ich dann nicht nur zu wenig konkrete 
Projekte und mache mir vermutlich auch oft das Leben zu schwer durch die 
Art und Weise wie ich meine GUIs gestalte, ein paar Sachen die EVE kann 
sind dann auch weitgehend an mir vorbei gegangen, vor allem die ganzen 
am Rande erwähnten Open_GL Features, Alpha-Blending, Scissors, die 
Transformations-Matrix. Auch zum Beispiel wofür EDGE_STRIPs gut sein 
sollen.
Oder wenn ich in die Bitmap-Formate rein schauen, da gibt es einige die 
ich noch nie benuzt habe. Text8V8, Bargraph, Paletted.

[Rudolph R. (rudolph)]

I had some issues with my jumper wires on friday and today I crimped a 
bunch of new ones.
I just reconnected the RVT101 to the Teensy 4.1 and took the attached 
trace with the Logic 2.3.28 software von Saleae.

This inludes the complete initialisation, the reading of REG_CLOCK with 
the one second delay, upload of the two images and the first four frame 
updates.

I am using PlatformIO and it is updated, this is the output
from the build:
> Executing task: C:\Users\Ich\.platformio\penv\Scripts\platformio.exe run 
--target upload --environment teensy41 <

Processing teensy41 (platform: teensy; board: teensy41; framework: 
arduino)
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
---------------------------------------------Verbose  mode can be 
enabled via `-v, --verbose` option
CONFIGURATION: 
https://docs.platformio.org/page/boards/teensy/teensy41.html
PLATFORM: Teensy (4.12.0) > Teensy 4.1
HARDWARE: IMXRT1062 600MHz, 512KB RAM, 7.75MB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES:
 - framework-arduinoteensy 1.153.0 (1.53)
 - tool-teensy 1.152.200516 (1.52)
 - toolchain-gccarmnoneeabi 1.50401.190816 (5.4.1)
Converting src.ino
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 89 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <SPI> 1.0
Building in release mode
Compiling .pio\build\teensy41\src\src.ino.cpp.o
Linking .pio\build\teensy41\firmware.elf
Building .pio\build\teensy41\firmware.hex
Checking size .pio\build\teensy41\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project 
Inspect"
RAM:   [=         ]  10.3% (used 53940 bytes from 524288 bytes)
Flash: [          ]   0.4% (used 34176 bytes from 8126464 bytes)
Configuring upload protocol...
AVAILABLE: jlink, teensy-gui
CURRENT: upload_protocol = teensy-gui
Uploading .pio\build\teensy41\firmware.hex
======================================================================== 
=======  [SUCCESS] Took 10.08 seconds 
======================================================================== 
=======

Environment    Status    Duration
-------------  --------  ------------
teensy41       SUCCESS   00:00:10.080
======================================================================== 
========  1 succeeded in 00:00:10.080 
======================================================================== 
========


And nice, there was an update for STM32 and it is building again:
Environment                Status    Duration
-------------------------  --------  ------------
uno                        SUCCESS   00:00:04.405
avr_pro                    SUCCESS   00:00:03.133
nano328                    SUCCESS   00:00:03.130
adafruit_metro_m4          SUCCESS   00:00:21.480
samd21_m0-mini             SUCCESS   00:00:08.109
ESP32                      SUCCESS   00:00:14.847
ESP8266_d1_mini            SUCCESS   00:00:11.637
nucleo_f446re              SUCCESS   00:00:08.395
teensy41                   SUCCESS   00:00:03.414
adafruit_feather_nrf52840  SUCCESS   00:00:11.694
bbcmicrobit_v2             SUCCESS   00:00:04.634
teensy35                   SUCCESS   00:00:05.731

[Spyy (Gast)]

Super...Danke..40 MSamples...Hm...sieht doch vernünftig aus...also sind 
ja ne Menge Daten, SPI hat 8 Mhz...? oder habe ich da was übersehen?
Ich hatte jetzt schon überlegt die Bustreiber einzubauen..
ich werde zunächst mal so eine Messung mit meinem China Logic Analyser 
machen...und mal schauen/vergleichen

Hat er nach 3 Frames abgebrochen?

[Rudolph R. (rudolph)]

Ja, der SPI hat 8MHz und nein, das lief durch, ich habe nur vorne und 
hinten kräftig was von den 4 Sekunden abgeschnitten die ich 
aufgezeichnet habe.

Was ich vergessen habe, ohne Logic-Analyzer läuft es immer noch nicht, 
aber ich musste jetzt nur CS anschließen damit es läuft.
Warum verstehe ich jetzt aber nicht, CS ist schließlich praktisch 
statisch und laut Datenblatt muss CS bei 3,3V nur 3ns vor der 
Clock-Flanke runter gehen. Gemessen habe ich in dem Trace als kleinstes 
110ns.
Das läuft bei 1MHz auch nicht besser, der Teensy ist soweit eine ganz 
schöne Mimose. :-)

[Rudolph R. (rudolph)]

Und gerade noch mal ausprobiert, das läuft so auch bei 1MHz, 10MHz und 
20MHz.
Auch schneller, mit dem Einstellen ist das nur so eine Sache, und mit 
dem Messen.
Im Moment läuft es gerade mit 25MHz, eingestellt sind 24MHz.
Also inklusive Touch.
Wenn ich den Logic16 auf 2 Kanäle stelle kann ich 100MBit/s abtasten,
aber natürlich ist das auch erheblich zu wenig, das reicht ja nicht mal 
um die 8MHz sauber zu messen.

Nun ja, die Daten sauber lesen zu können ist wichtiger als für jeden 
Clock die Länge auf 1ns genau zu haben. :-)

Ich fände da mal eine Tabelle interessant was der Controller auf dem 
Teensy für den SPI überhaupt einstellen kann.

Bei 4MHz braucht der komplette Refresh 723µs bei 320 Bytes.
Also könnte das 1370 Bytes lange werden bevor die 5ms um sind.

Angehängt sind 4s einfach mal so zwischendurch aufgenommen bei 4MHz.
Das lief vorher eine Weile, das läuft jetzt immer noch.

[Rudolph R. (rudolph)]

Ich habe den Teensy 4.1 heute noch mal an das Oszi gehängt.
Und die 2MHz waren ganz schön rund, so am Teensy gemessen.

Beim Chip-Select habe ich die Anstiegs- und Abfall-Zeiten gemessen,
die lagen bei etwa 50ns, dabei war die einzige "Last" auf der Leitung 
der Tastkopf und ein 10k Pullup gegen 3,3V.

Sind bei dem Teensy 4.1 per Default die Drive-Level auf die kleinste 
Stufe eingestellt?

[Spyy (Gast)]

Rudolph R. schrieb:
> Sind bei dem Teensy 4.1 per Default die Drive-Level auf die kleinste
> Stufe eingestellt?

Ich habe die Frage vor längerer Zeit im Teensy Forum gestellt...leider 
keine Antwort...:(

[Rudolph R. (rudolph)]

Ich habe gestern mal etwas durch das Teensyduino gestöbert und wenn ich 
das mit den Registern richtig verstehe sind mindestens die Pins um den 
SPI auf die höchste Stufe (7) eingestellt.
Heute habe ich da noch mal mit dem Oszi dran gemessen und dabei 
festgestellt, dass der Tastkopf auf X1 gestellt war, das kommt davon 
wenn man das Equipment verleiht und nicht kontrolliert wie die 
Einstellung sind.
Auf X10 waren die Flanken gleich viel steiler, eher zu steil und neben 
den Überschwingern eine Menge Schmutz drauf, das spricht für mehr 
Filtern, bzw. stärker belasten oder auch die Ausgangstreiber auf eine 
kleinere Stufe stellen könnte helfen.
Am Ausgang meiner Adapter-Platine war der Takt deutlich glatter, hatte 
aber auch Gezappel drauf.

[Rudolph (Gast)]

Gestern habe ich den Drive-Level runter gestellt, das hat aber soweit 
keinen merkbaren Einluss gehabt.

Jetzt habe ich gerade mal den Reihenwiderstand auf meiner 
Adapter-Platine größer gemacht, in SCK habe ich da normalerweise 10R in 
Reihe und 22pF gegen GND, also ein praktisch kaum wirksamer Tiefpass.
Jetzt habe ich die Widerstände durch 240R ersetzt und bei CS auch noch 
einen 22pF reingefummelt, das sind so 30MHz Grenzfrequenz.
Das sieht hinter dem Widerstand deutlich ruhiger aus.

Nachher schaue ich mal ob das dann auch endlich ohne Logic-Analyzer auf 
den Leitungen funktioniert.

Wenn das funktioniert kann der Widerstand sicher auch kleiner sein.

[Rudolph R. (rudolph)]

And to get back to Englisch, I just tested the modified display adapter 
with an EVE3-50G and the Teensy 4.1 and it works without connecting the 
logic
analyzer now.

Interestingly the display for the frequency changed:
7246628x for reading REG_CLOCK every second
72467376 for the reading REG_CLOCK right after init with the delay().
But since frames/s is up a little as well to 74/75 instead of 73/74 it 
is possible that the Teensy is running a little fast right now.

Setting the SPI to 21MHz after init works, at 22MHz the display stays 
dark.

This is the adapter with the configuration I am using:
https://github.com/RudolphRiedel/EVE_display-adapter/blob/master/L-D5019-01-05/L-D5019-01-05_EVE.PDF
Only the audio part with the speaker is not populated.

I changed R3, R5 and R8 from 10R to 240R and added a 22pF between pin 1 
of U2A and GND.

I have a second adapter that is populated to the same configuration as 
in the .pdf but with R17 removed and R24 populated.
Ok, and the audio part is not populated on this board either.
I am using this board with the RVT101 and I am supplying it with 9.6V 
for the backlight in order to keep the backlight current low.
And next I am changing R3, R5 and R8 to 150R on this one.

[Rudolph R. (rudolph)]

Hey, that worked just fine, I have the RVT101 now up and running with 
the Teensy 4.1 without the logic analyzer connected.

And with the lower vaule for the resistors of 150R instead of 240R the 
SPI works with a higher clock now.
With 26MHz reading from the display still works including the touch.
With 27MHz the number displayed for the Frequency and the Frames/s that 
are measured one per second is "0" and the touch is not working anymore.
When I setup the SPI to 30MHz, 40MHz or even 50MHz the display still 
works but I doubt that it really is using 40MHz let alone 50MHz.

Back to 20MHz, the display for the frequncy measured once is: 72003052
And for the frequency measured every second: 72002403

No idea why this is different now, maybe the clock on the EVE3-50G is 
running a little faster than 12MHz.
The RVT101 is using a crystal and the EVE3-50G is using a resonator, 
this is maybe 0,02% to maybe 0.5%.

So like  Arnaud reported for the Teensy 3.5, at least my Teensy 4.1 
needs a little more series resitance to play nice on the SPI even when 
working without a real load since I am using logic buffers.
Now I am glad that I did not optimise-away the 10R/22pF from my board. 
:-)


Hmm, I just tried to use the internal oscillator by removing the 
"EVE_HAS_CRYSTAL" define from the module configuration.
And there is some issue, this way the display is blinking, measuring the 
frequency and frames/s every second does not work and the frequency 
measured once only is 38069614.
I look into that.

[Rudolph R. (rudolph)]

Oh, big oh, the BT817/BT818 do not have the "internal relaxation 
oscillator" anymore or at least this has been removed from the 
datasheet.
From chapter 4.2 in the datasheet "System Clock" up to the CLKINT 
command.
It's gone, you have a add a crystal, a resonator.
"External Clock Input" also is gone.

But even if this still works somewhat contradicting the datasheet, my 
display
is wired for an crystal and not for the internal oscillator like in the 
datasheet of the BT815/BT816. This would require X1/Clk to be connected 
to GND.
So even if this still works, switching to internal oscillator with a 
crystal connected is not a valid experiment.

Edit: and I just posted this with more details from the datasheet to the 
BRT forum.

[Spyy (Gast)]

Oh, oh...wow thank you for investigating this....i will then add bus 
drivers and an external crystal...to get rid about my issues.

Which type of chrystal (part number) with which capacitors do you use?
Or do you think X1 to ground is sufficient?

[Spyy (Gast)]

Oh yes, found it...no word of internal anymore..this was changed last 
year...hm...i asked exactly this in the forum in the past if an external 
oscillator is necessary...:(

[Rudolph R. (rudolph)]

I am exclusively using readily available modules so far.
And I am not using 12MHz crystals with my controllers, but 16MHz mostly.

That said I went on to a quick fishing expedition on Digikey and found
CX3225GA12000D0PTVCC ( 1253-1151-1-ND ), if I were to add a 12MHz 
crystal and had to make due with what is available I probably would go 
for these.
Plus 12pF capacitors.
I prefer the crystals with two pads as I can solder these more easily by 
hand.

Since Matrix Orbital is sucessfully using ceramic resonators on their 
modules an alternative to a crystal might be a CSTNE12M0GH5L000R0 ( 
490-17947-1-ND ), I selected these for their better frequency tolerance 
of +/- 0.07% compared to the more standard +/- 0.5% for resonators.

[Karol (Gast)]

Hi there, How can I display an image with new library in old FT 800 
series? There no setbitmap command... also, I remember taht "FT80x is 
gone" so, what can I do, if I have to use old FT800?

When i use yours example:
#define IMG1_ADR  0
while(ft800_busy() == 1);
ft800_cmd_loadimage(IMG1_ADR, FT_OPT_NODL, jpg4, 2640);
ft800_cmd_execute();
//then in loop:
ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_dl(BITMAP_SOURCE(IMG1_ADR));//ft800_cmd_dl(BITMAP_SOURCE(MEM_P 
IC1));
ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
ft800_cmd_dl(VERTEX2II(FT_HSIZE-96-10,FT_VSIZE-96-10,0,0));
//ft800_cmd_dl(VERTEX2F((10)*16,30*16));

works fine, but when I try to use ft800_cmd_loadimage(RAM_IMAGES_LOGO_2, 
FT_OPT_NODL, IMAGES_LOGO_2, sizeof(IMAGES_LOGO_2)); and the same metod 
for display it, it doesn't work at all.

Sometimes, only ft800_cmd_loadimage(...) crashed.

PS. For this case, I am using "Spielplatz_90CAN_FT800.zip " from first 
post.

Regards
Karol

[Karol B. (karol_b135)]

Hi there, How can I display an image with new library in old FT 800
series? There no setbitmap command... also, I remember taht "FT80x is
gone" so, what can I do, if I have to use old FT800?

When i use yours example:

#define IMG1_ADR  0
while(ft800_busy() == 1);
ft800_cmd_loadimage(IMG1_ADR, FT_OPT_NODL, jpg4, 2640);
ft800_cmd_execute();
//then in loop:
ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_dl(BITMAP_SOURCE(IMG1_ADR));//ft800_cmd_dl(BITMAP_SOURCE(MEM_P 
IC1));
ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
ft800_cmd_dl(VERTEX2II(FT_HSIZE-96-10,FT_VSIZE-96-10,0,0));
//ft800_cmd_dl(VERTEX2F((10)*16,30*16));

works fine, but when I try to use

ft800_cmd_inflate(RAM_IMAGES_LOGO_2, IMAGES_LOGO_ASUZU_2, sizeof(IMAGES_LOGO_2));

 and the same metod
for display it, it doesn't work at all.

Sometimes, only ft800_cmd_inflate(...) crashed.

PS. For this case, I am using "Spielplatz_90CAN_FT800.zip " from first
post.

Regards
Karol

[Rudolph R. (rudolph)]

Karol B. schrieb:
> Hi there, How can I display an image with new library in old FT 800
> series? There no setbitmap command... also, I remember taht "FT80x is
> gone" so, what can I do, if I have to use old FT800?

Hello,
while my first recommendation is to switch to a newer display, you can 
also still use the older version of my library, it's all still there.
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x
And the API is pretty close to the current one with the exception that 
V5 additionally has the EVE...._burst() functions to shave off a few 
extra cycles from every function by not checking for burst-mode every 
time.

That thing I did over five years ago that is attached to the start of 
this thread, it is not supported anymore. :-)

[Karol B. (karol_b135)]

Thanks a lot for your quick answer. Could you give me short an example 
how to display 2 images, one with load_image and another with 
cmd_inflate functions?

[Rudolph R. (rudolph)]

It really has been a while since I used a FT800 based display.
I just took the Arduino example from the V4 archive which is displaying 
two images.
I modified the display to EVE_VM800B50A in EVE_config.h.
Compiling it showed that the example is not directly compatible with 
FT800.

First there is VERTEX_FORMAT that does not exist in FT80x and which 
allows to setup the pixel resolution for VERTEX2F.
So VERTEX2F for FT80x always is using 1/16 pixel resolution - which I 
really do not miss.

Next is CMD_SETBITMAP which does not exist for FT80x either and needs to 
be replaced with a sequence of comands.

EVE_cmd_setbitmap(MEM_LOGO, EVE_L8, 38, 59);
->
EVE_cmd_dl(BITMAP_SOURCE(MEM_LOGO));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_L8,38,59));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,38,59));

And there is a second CMD_SETBITMAP that I changed as well.

EVE_cmd_setbitmap(MEM_PIC1, EVE_RGB565, 100, 100);
->
EVE_cmd_dl(BITMAP_SOURCE(MEM_PIC1));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_RGB565,100*2,100));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,100,100));

I am not sure if this really works but at least it compiles without 
warning now for an Arduino Uno using PlatformIO.

[Karol B. (karol_b135)]

Thanks a lot :) I will try attached example. For now, i have got working 
one. Perhaps my mistake was all about PROGMEM attribute after 
cmd_inflate. I feel I forgotten read data form flash.

Thanks again, You'ar great :)

[Markus S. (Firma: LRP AG) (mastr64)]

Hallo Rudolph

ich habe ein Display von Riverdi mit kapazitivem Touch (RVT50AQBNWC00).
Das Display funktioniert einwandfrei und auch der Touch funktioniert 
wenn ich die Kalibrierfunktion am Anfang des Programms aufrufe.
Wenn ich aber die Kalibrierwerte abspeichere und diese dann nach dem 
Initialisiseren des Display in die REG_TOUCH_TRANSFORM_A-F Register 
schreibe, dann funktioniert der Touch nicht.
Gibt es da noch etwas spezielles zu beachten?
Was mir auch eigenartig erscheint, die Kalibrierwerte für die 
REG_TOUCH_TRANSFORM-Register sind nach jeder Kalibrierung komplett 
verschieden.

Freundliche Grüsse
Markus

[Rudolph (Gast)]

Also eigentlich klappt das mit dem Speichern und wieder rein schreiben, 
das mache ich schon seit Jahren so.
Etwas stumpf, da ich die Werte vom Display abschreibe und in die 
Software eintrage, so klappt das aber am ehesten quer über diverse 
Controller, so ohne Schnittstelle in ein EEPROM.

Und normalerweise ändern sich die Werte von einem Kalibrieren zum 
anderen auch nicht so deutlich.

Ich empfehle auch einen Stylus zu verwenden, die Dinger gibt es extra 
für Kapazitive Displays, mit dem Finger ist man leicht ein paar mm neben 
den Punkten.

[Markus S. (Firma: LRP AG) (mastr64)]

Ich mache das auch so mit Werte abschreiben und anschliessend im Code 
eintragen.

ich weiss nicht ob ich beim schreiben der REG_TOUCH_TRANSFORM Register 
etwas übersehe. Wo machst du das genau, beim EVE_init()oder wo?
Hast du mir ev ein kurzes Code-Beispiel.

[Rudolph R. (rudolph)]

Meine Beispiele haben alle den gleichen Code unten drunter.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_Arduino_PlatformIO/src/tft.c

void touch_calibrate(void)
{
/* send pre-recorded touch calibration values, depending on the display the code is compiled for */

#if defined (EVE_CFAF240400C1_030SC)
  EVE_memWrite32(REG_TOUCH_TRANSFORM_A, 0x0000ed11);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_B, 0x00001139);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_C, 0xfff76809);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_D, 0x00000000);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_E, 0x00010690);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_F, 0xfffadf2e);
#endif
....

/* activate this if you are using a module for the first time or if you need to re-calibrate it */
/* write down the numbers on the screen and either place them in one of the pre-defined blocks above or make a new block */
#if 0
  /* calibrate touch and displays values to screen */
  EVE_cmd_dl(CMD_DLSTART);
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK);
...

Das wird am Anfang von TFT_init() aufgerufen.

[Markus S. (Firma: LRP AG) (mastr64)]

Jetzt funktioniert es !!

Ich hatte einen Fehler in der Funktion EVE_memRead32,
somit waren die gelesenen Werte immer falsch.

Herzlichen Dank für deine Unterstützung.

Markus

[Rudolph R. (rudolph)]

There is a new Asset Builder available:
https://brtchip.com/eve-toolchains/#EVEAssetBuilder

And it has a couple of interesting new features like the enhanced font 
converter.

[Rudolph R. (rudolph)]

And as you probably have noticed, Bridgetek took down EAB 2.4 again.
No idea why though, it seems to be working just fine.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudi,
bin mit meinen Versuchen, ein Bitmap darzustellen einen großen Schritt 
weiter gekommen! Leider sehe ich am Ende auch nach vielem 
Experimentieren nur ein "verkrisseltes" Bild in der Größe ca. 35 x 35 
und das stets in der linken oberen Ecke, obwohl ich in VERTEX2II 
eindeutig die Koordinaten 100 x 100 (z.B.) eingebe.
Also: FT813! Keine Co-Prozessor-Nutzung!
Benutze den FTDI-EVE-Screen-Editor. Habe mal mein Logo mit "Paint" auf 
eine Größe von 100 x 35 Pixel gebracht und als Projekt in den 
Screen-Editor als ARGB1555 geladen. Nach dem Speichern des Projekts hat 
man die RAWH-Daten. Bei 2 Bytes pro Pixel und genannter Größe sind das 
immerhin stolze 7000 Bytes. Die Schreibe ich als erstes in den RAM_G. 
Zur Kontrolle habe ich dann erst mal 1 Sekunde später die Daten 
ausgelesen und auf den Bildschirm gebracht (zumindest mal die ersten 
255) und Verglichen: Alles richtig gemacht!
Dann setze ich:
Bitmap_Handle(0)
Bitmap_Source(0)  (habe ja die Daten ab Adresse Null des Ram_G 
geschrieben)
Bitmap_Lyout(ARGB1555, 200, 35)
Parameter "Linestride" (200) muss gemäß Anleitung Anzahl Bytes pro Pixel 
(2) mal Weite (hier 100) also 200 sein. Der EVE_Screen-Editor spuckt 
diesen Wert auch sofort allein aus, wenn ich als Format ARGB1555 setze. 
Am Editor kann man auch schön sehen, was passiert, wenn man diesen Wert 
ändert (Bild verzerrt sich zunehmend). Und genau so - abgesehen von dem 
kleinen Ausschnitt - sieht auch der Teil, den ich bei mir am Display 
sehe aus, mega stark verzerrtes Bild, was mit viel Fantasie erahnen 
lässt, dass das mein Logo (ein Ausschnitt davon) sein soll.
Dann setze ich natürlich noch:
Bitmap_Size(Nearest,Border,Border,100,35) (Bitmap_Size(0,0,0,100,35))
Zu guter letzt folgt dann natürlich noch Begin_Bitmaps, Vertex2II mit 
den X-Y-Koordinaten 100/100, EndList und Display...

Große Frage: Der EVE-Screen-Editor ist zwar für den FT800, aber gemäß 
Prorammer-Guide des FT813 sind die einzelnen genannten Befehle genau so.
Kann ich diese Bilddaten (RAWH) hier wirklich benutzen?

Irgendwie steckt in meinem Hinterkopf noch so drin, dass man 
"eigentlich" nur Bitmaps mit max. 64 x 64 darstellen kann. Aber 
Bitmap_Size sagt ja für Width und Height als erlaubte Werte je 511. Und 
wenn ich dann noch Size_H benutze, geht es ja noch größer...!
Habe ich noch etwas ganz wichtiges vergessen?

Vor dem Darstellen des Bitmap setze ich ja z.B. einen Begrüßungstext na 
usw. Die RAM_DL-List für das Bitmap ist (zunächst) der letzte Schritt. 
Wenn ich hier NICHT Clear(1,1,1) mit CLEAR_COLOR_RGB(0,0,0) setze, wird 
das "verkrisselte" Bitmap in der Breite ca. 35 Pixel von oben bis unten 
dargestellt. Füge ich CLEAR... ein, so erscheint das 35 x 35 Bild. Gibt 
es dafür eine sinnvolle Erklärung?

Außer, dass ich die noch bis vor kurzem nicht benutzten Befehle CLEAR 
(mit CLEAR_COLOR_RGB) nun einsetze, habe ich mich auch mit COLOR_A, 
sowie SCISSOR beschäftigt und es auch tatsächlich hinbekommen hiermit 
Überblend- und Ausblendeffekte zu erzielen.

Was kann ich nun noch Probieren, um ein Bitmap, so wie im Screen-Editor 
zu sehen auch real auf mein Display zu bekommen?

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Rudolph R. schrieb:
> ein paar Sachen die EVE kann
> sind dann auch weitgehend an mir vorbei gegangen, vor allem die ganzen
> am Rande erwähnten Open_GL Features, Alpha-Blending, Scissors, die
> Transformations-Matrix. Auch zum Beispiel wofür EDGE_STRIPs gut sein
> sollen.

Das war schon am 4.6.!!!
Kann ich Dir gern erklären, wofür man EDGE_STRIPs benutzt (für mich 
unabdingbar!). Und wie schon gesagt: Alpha-Blending und Scissor 
beherrsche ich nun auch. Brauchst Du das (noch)???? Dan sag' bescheid.

[Rudolph R. (rudolph)]

Moin,

Bernd I. schrieb:
> Hallo Rudi,
> bin mit meinen Versuchen, ein Bitmap darzustellen einen großen Schritt
> weiter gekommen! Leider sehe ich am Ende auch nach vielem
> Experimentieren nur ein "verkrisseltes" Bild in der Größe ca. 35 x 35
> und das stets in der linken oberen Ecke, obwohl ich in VERTEX2II
> eindeutig die Koordinaten 100 x 100 (z.B.) eingebe.

Hmm, seltsam.

> Also: FT813! Keine Co-Prozessor-Nutzung!

Ich verstehe immer noch nicht, warum Du das machst, aber das ist soweit 
nicht das Problem.

> Benutze den FTDI-EVE-Screen-Editor. Habe mal mein Logo mit "Paint" auf
> eine Größe von 100 x 35 Pixel gebracht und als Projekt in den
> Screen-Editor als ARGB1555 geladen. Nach dem Speichern des Projekts hat
> man die RAWH-Daten. Bei 2 Bytes pro Pixel und genannter Größe sind das
> immerhin stolze 7000 Bytes. Die Schreibe ich als erstes in den RAM_G.

Sowas habe ich auch gerade gemacht. das ESE Projekt hängt an.

> Bitmap_Handle(0)
> Bitmap_Source(0)
> Bitmap_Lyout(ARGB1555, 200, 35)
> Bitmap_Size(Nearest,Border,Border,100,35)
> Bitmap_Size(0,0,0,100,35))
> Begin_Bitmaps
> Vertex2II(100, 100, 0, 0)
> END()

Praktisch so habe ich das im ESE drin, mit drei zusätzlichen Zeilen.
CLEAR_COLOR_RGB(255, 255, 255)
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)

Also Hintergrund weiß, löschen und Basis-Farbe des Bildes auch weiß.

> Große Frage: Der EVE-Screen-Editor ist zwar für den FT800,

Der EVE-Screen-Editor geht für alle von FT800 bis BT818 und in dem 
angehängten Projekt ist ein FT813 ausgewählt mit 480x272.

> Kann ich diese Bilddaten (RAWH) hier wirklich benutzen?

Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem 
EVE-Asset-Builder, aber erstmal sieht das plausibel aus.

> Irgendwie steckt in meinem Hinterkopf noch so drin, dass man
> "eigentlich" nur Bitmaps mit max. 64 x 64 darstellen kann. Aber
> Bitmap_Size sagt ja für Width und Height als erlaubte Werte je 511. Und
> wenn ich dann noch Size_H benutze, geht es ja noch größer...!
> Habe ich noch etwas ganz wichtiges vergessen?

Das ist total richtig und das sind dann 2048x2048.
Wobei ich mir da normalerweise gar keine Gedanken mache, ich benutze 
einfach CMD_SETBITMAP und das erzeugt einfach die notwendige Sequenz.

> Vor dem Darstellen des Bitmap setze ich ja z.B. einen Begrüßungstext na
> usw. Die RAM_DL-List für das Bitmap ist (zunächst) der letzte Schritt.
> Wenn ich hier NICHT Clear(1,1,1) mit CLEAR_COLOR_RGB(0,0,0) setze, wird
> das "verkrisselte" Bitmap in der Breite ca. 35 Pixel von oben bis unten
> dargestellt. Füge ich CLEAR... ein, so erscheint das 35 x 35 Bild. Gibt
> es dafür eine sinnvolle Erklärung?

So direkt fällt mir dazu nichts ein, mit der Sequenz da oben bekomme ich 
im ESE mein 100x35 Pixel Bild angezeigt.
Wobei ich VERTEX2F mit VERTEXT_FORMAT(0) vorziehe.

Eventuell ist das ein Problem mit der vorherigen Liste.


> Außer, dass ich die noch bis vor kurzem nicht benutzten Befehle CLEAR
> (mit CLEAR_COLOR_RGB) nun einsetze, habe ich mich auch mit COLOR_A,
> sowie SCISSOR beschäftigt und es auch tatsächlich hinbekommen hiermit
> Überblend- und Ausblendeffekte zu erzielen.
>
> Was kann ich nun noch Probieren, um ein Bitmap, so wie im Screen-Editor
> zu sehen auch real auf mein Display zu bekommen?

Wie war das? Du nutzt kein C?

Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das 
Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt 
werden soll.
Das kann entweder für Pulseview oder Saleae Logic 2 sein.
Einfache Logic-Analyzer die mit Pulseview laufen bekommt man schon für 
10 Euro, dann sollte man allerdings den SPI-Takt runter setzen, mehr als 
24Mhz Abtast-Rate schaffen die nicht, also mehr als 2MHz bis 4Mhz kann 
man damit nicht sinnvoll messen.

Bernd I. schrieb:
> Kann ich Dir gern erklären, wofür man EDGE_STRIPs benutzt (für mich
> unabdingbar!). Und wie schon gesagt: Alpha-Blending und Scissor
> beherrsche ich nun auch. Brauchst Du das (noch)???? Dan sag' bescheid.

Danke, ich habe da nur bisher keine Verwendung für gefunden.
Was kann man mit Edge-Strips anfangen? Ich schaue gerade auf die vier 
Bilder im Programming-Manual und mir fällt nichts ein für das ich sowas 
schon mal hätte verwenden können.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Ein geschichtsträchtiger Morgen:
Mein Logo erscheint auf dem Display!!!
Habe es mal auf 50 x 17 gekürzt. DENNOCH: Es sitzt immer noch in der 
Ecke oben links, statt auf 200 x 200 (X , Y). Na den Fehler finden wir 
noch...

Rudolph R. schrieb:
> Praktisch so habe ich das im ESE drin, mit drei zusätzlichen Zeilen.
> CLEAR_COLOR_RGB(255, 255, 255)
> CLEAR(1, 1, 1)
> COLOR_RGB(255, 255, 255)

Brachte keinen Unterschied. Es hat auch nichts mit dem vorherigen 
Bildaufbau zu tun. Habe das mal übersprungen und nun nach dem großen 
Erfolg wieder aktiviert: Bleibt alles, wie es ist: Das kleine Logo (50 x 
17) steht "sauber" oben links in der Ecke...
Ich vermute mal, dass ich bei den 7000 Bytes irgendwo ein Vielfaches von 
32 oder 64 nicht richtig gelesen (geschrieben) habe. Lese die Daten im 
Moment vom Flash, da muss man diese Vielfache beachten. Später sollen 
die Daten dann als Editor-Datei in einen USB-Stick, der On-Board ist.

Rudolph R. schrieb:
> Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das
> Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt
> werden soll.

??????????????? Um Gottes willen!!!!
Ja, nach wie vor KEIN "C"! Immer noch in Basic. Ich schreibe das nur so 
in dieser Form hier, dann weißt Du (und jeder andere) gleich, was 
gemeint ist, also in der Form, wie es im Programmer-Guide steht.
Und immer noch kein Co-Prozessor! Alles eins nach dem anderen!

Überblenden von einem Bild zum Anderen mit SCISSOR:
Display 800 x 480
1. Start-Koordinaten in der Mitte des Bildschirms definieren: X=400, 
Y=240
2. Start-Größe des aufzublenden Bildes definieren (minimal): Höhe=1, 
Breite=2

3. For-Next-Schleife

For Var16 = 0 to 399
Beginn RAM_DL
Bildschirm komplett mit Farbe, Text etc. setzen (Bild VOR dem 
Überblenden)
Display(0)   'Bild VOR SCISSOR erscheint
SCISSOR_XY(X,Y)
SCISSOR_SIZE(Breite,Höhe)
clear(1,0,0)  'Ich glaube, das ist wichtig, funktioniert sonst nicht

Beginn RAM_DL
Bild NACH SCISSOR schreiben
Display(0)   'Bild NACH SCISSOR erscheint von Mitte immer größer werdend
  Breite = Breite + 2 : Höhe = Höhe + 2  'Bildausschnitt für Bild NACH
                                         SCISSOR langsam vergrößern UND 
...
  X=X-1 : Y=Y-1                          '... schräg nach oben links 
wandern
Verzögerung in Millisekunden      'Geschwindigkeit des Überblendens
next          'Nächster Schleifendurchlauf

In die Schleife noch einbauen: Wenn Y=0, dann das "Y=Y-1" natürlich 
überspringen.

Das neue Bild erscheint mit der Geschwindigkeit von "Verzögerung" von 
Innen nach Aussen über dem alten Bild.

Abblenden mit COLOR_A
Eigentlich wie unter 4.26 (COLOR_A) im Programmer-Guide (FT813) als 
Beispiel beschrieben. Um nun ein komplettes Bild abzublenden, wieder 
eine For-Next-Schleife ausführen, wobei Alpha von 255 bis gewünschten 
Minimum (bestenfalls Null) abwärts zählt
In Basic sieht das so aus:
For Alpha = 255 to 0 Step -1
Beginn RAM_DL
Bild setzen
Display(0)
Color_A(Alpha)
Verzögerung (Geschwindigkeit des Abblendens)
next

ODER auch nur Teile eines Gesamtbildes langsam ausblenden
For Alpha = 255 to 0 Step -1
Beginn RAM_DL
Bild-Teile setzen, die nicht ausgeblendet werden sollen
Color_A(Alpha)
Bild-Teile setzen, die ausgeblendet werden sollen
Display(0)
Verzögerung (Geschwindigkeit des Abblendens)
next

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Logo erscheint nun an gewünschter Stelle X,Y. Ich weiß es absolut nicht, 
was ich bei VERTEX2II falsch gemacht hatte. Habe lediglich festgestellt, 
dass ich das ja schon vor Jahren definiert hatte im Zusammenhang mit 
Text schreiben. Nur dass hier eben "Fonts" = "Handle" ist und der ASCI = 
"Cell" und beide Werte nun Null sein sollten. Also habe ich diese uralte 
Routine aufgerufen und siehe da es geht. Was leider aber trotz aller 
Sorgfalt immer noch nicht geht, ist das große Logo 100x35. Gleiche 
Erscheinung (nur jetzt auch nicht mehr Ecke oben links, sondern auf 
angegebenen Koordinaten), "verkrisseltes" kleines Bild.
Alles ist gegenüber dem Logo 50x17 identisch. Nur eben natürlich mehr 
Daten in den RAM_G schreiben und die Parameter LineStride, sowie Height 
und Width anpassen.
Was kann hier noch falsch sein ??????????

Noch mal zu Deiner Frage, was soll ich mit EDGE_STRIP:
Wie zeichnest Du ein Parallelogramm oder ein Dreieck? Sicherlich auf 
Deine Art (mit Co-Prozessor nehme ich mal an).
Ein Parallelogramm setze ich z.B., indem ich von links nach rechts die 
Seiten mit EDGE_STRIP_R setze. Voraussetzung ist allerdings eine 
homogene Hintergrund-Farbe.
Setze die 3 Koordinaten der linken Kante mit der gewünschte Füllfarbe 
des Parallelogramms. Setze die 3 Koordinaten der rechten Kante mit der 
Hintergrund-Farbe (bzw. eben der Farbe, die rechts vom Parallelogramm 
erscheinen soll). Ich weiß, jetzt krempeln sich dir alle Fußnägel hoch 
:):):).
Aber dafür könnte man es verwenden!!! Und habe es verwendet, z.B. eine 
offen stehende Tür, incl. Türschild (Tür-Klinke)...

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Nur zur Info:
Logo 100x35 geht jetzt auch. Fehler war eindeutig in meiner Software 
beim Generieren der Var32 für das Setzen beim Befehl BITMAP_LAYOUT ...

[Rudolph R. (rudolph)]

Bernd I. schrieb:
>> Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das
>> Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt
>> werden soll.
>
> ??????????????? Um Gottes willen!!!!
> Ja, nach wie vor KEIN "C"! Immer noch in Basic.

Ja nun, genau aus dem Grund die Idee einen Level tiefer anzusetzen.
Ich schaue mir den SPI Output regelmäßig mit dem Logik-Analyzer an, vor 
allem wenn ich Support für einen neuen Controller einbaue.

Denn dabei kommt oft genug sowas hier raus:
https://github.com/RudolphRiedel/FT800-FT813/discussions/32

Wenn ich jetzt rein auf das Display schauen würde, dann könnte ich 
vorschnell zu dem Ergebnis kommen, dass das nicht nur funktioniert, 
sondern auch benutzbar ist.
In dem konkreten Fall ist die unter der Arduino SPI Klasse liegende HAL 
so seltsam programmiert, dass der SPI mit angezogener Handbremse läuft.
Ich habe auch die HAL direkt manipulieren können weil die als Quelltext 
vorliegt, ich konnte ohne negative Seiteneffekte mehrere Zeilen 
auskommentieren und den SPI so beschleunigen.
Und das kommt nicht etwa von irgendwem, das kommt vom Hersteller des 
Controllers.
Im Gegensatz zu dem noch seltsameren Verhalten von z.B. ESP32 ist da 
nicht mal ein RTOS im Spiel und der Controller hat auch nur einen Kern.

Wenn Du jetzt auf der obersten Ebene alles richtig machst heißt das noch 
lange nicht, dass die Daten auf dem SPI auch so raus kommen wie 
beabsichtigt.

Bernd I. schrieb:
> Noch mal zu Deiner Frage, was soll ich mit EDGE_STRIP:
> Wie zeichnest Du ein Parallelogramm oder ein Dreieck?

Gar nicht. :-)
Und das Problem das ich mit dem EDGE_STRIP habe ist, das ist an eine 
Kante des Displays gebunden, damit kann man nicht mal eben ein Dreieck 
mitten auf den Bildschirm malen.
Und so bleibe ich bei RECT und POINT, zumal man Rechtecken mit der 
LINE_WIDTH auch gerundete Ecken verpassen kann.

Ach so, der Punkt ist auch schnell überschritten an dem es sich eher 
lohnt eine Grafik zu verwenden, alleine schon weil man damit weniger 
über den SPI schicken muss.

[Alf S. (alfsch)]

Hallo Rudolph,
ich habe deine Lib verwendet, mit einem STM32H7A3 und 7" TFT von 
Newhaven, als kleines Test-projekt in der STM32CubeIDE, läuft ohne viel 
tamtam ganz fein.
wenn es dich (oder andere..) interessiert, poste ich die wichtigen 
Punkte , bzw die source. (oder auf git , wenn das besser ist :-)
die SPI läuft mit 24 Mbit, ein screen update dauert etwa 500us (ohne 
jegliche Optimierung oder DMA ), soweit ganz ok. CPU Last liegt somit 
bei 5% für Graphik mit maximaler Geschwindigkeit, also mit rund 60Hz 
update rate.

könnte auch ein kleines Video von der Demo machen, mit bewegter Graphik 
;)

[Rudolph R. (rudolph)]

Äh, ok, meinst Du nicht, dass ein 280MHz Cortex-M7 mit 2MB Flash und 100 
Pins aufwärts ein klein wenig übertrieben ist? :-)
Ok, machen was geht halt, aber das Monster hat sogar einen eingebauten 
Grafik-Controller. :-)

Ich spiele gerade mit einem K32L2B3 rum, nur um das mal gemacht zu 
haben.
Das ist ein Cortex M0+ mit 48MHz und Laufen hatte ich den an dem 7" mit 
1024x600 zumindest schon.

So grundsätzlichen Support für diverse STM32 Familien habe ich ja schon 
eingebaut.
Aber es ist nicht so, als ob man irgendwelche interessanten STM32 gerade 
kaufen könnte.
DigiKey hat zum Beispiel gerade nur 17 verschiedene auf Lager, 9 davon 
im BGA Gehäuse.
Die restlichen 8 sind nicht geeignet mich von den ATSAMC21 / ATSAME51 
abzubringen die ich im Moment verwende.
Und ich weiß ich habe da auch noch nichts fertiges, aber so einen 
Controller ohne DMA zu nutzen ist irgendwie verschwendet. :-)

Aus Neugier habe ich gerade mal versucht H7 Support einzufrickeln, so 
für ein nucleo_h743zi da PlatformIO kein Board mit dem STM32HA3 zu 
kennen scheint.
Das compiliert nur spontan nicht, da es in der H7 LL_SPI HAL Library die 
Funktionen LL_SPI_IsActiveFlag_TXE() und LL_SPI_IsActiveFlag_RXNE() wohl 
nicht gibt.
Wenn ich die Zeilen auskommentiere baut es durch, "stm32cube", nur fehlt 
in meinem "Beispiel" der ganze Code drum herum, also was man so in der 
STM32CubeIDE als Grundgerüst generieren würde.

Also wenn Du die notwendigen paar angepassten Zeilen für spi_transmit() 
und spi_receive() posten magst, dann füge ich die gerne noch ein.

[Alf S. (alfsch)]

nu ja, der H7A3 ist nicht unbedingt nötig :)
aber: er war eben noch lieferbar... (neue Zeit, neue Regeln...)
aktuell ist ja fast nix lieferbar.

hier die Demo:
https://youtu.be/f-EG9uTTJ5k

Snoopy lässt grüssen !

[Rudolph R. (rudolph)]

Nice, irgendwann muss ich auch mal wieder Zeit finden sowas zu machen. 
:-)

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudolph,
zunächst mal vorab:
Rudolph R. schrieb:
> Und das Problem das ich mit dem EDGE_STRIP habe ist, das ist an eine
> Kante des Displays gebunden, damit kann man nicht mal eben ein Dreieck
> mitten auf den Bildschirm malen.
Das verstehe ich nicht! Bei EDGE_STRIP setzt Du doch beliebige 
Koordinaten, egal wohin!!! So (und nicht anders) setze ich Dreiecke / 
Parallelogramme etc. mitten in das Display:
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
LINE_WIDTH(256)
CLEAR(1, 1, 1)
BEGIN(EDGE_STRIP_R)
VERTEX2II(20, 65, 0, 0)      'Linke Ecke des Dreiecks
VERTEX2II(100, 100, 0, 0)    'Spitze Unten
COLOR_RGB(0, 0, 0)           'ab rechter Kante wieder schwarz
VERTEX2II(100, 100, 0, 0)    'Spitze Unten
VERTEX2II(180, 65, 0, 0)     'Rechte Ecke des Dreiecks
END(0)
DISPLAY(0)
Na klar, das geht eben nur, wenn man einen homogenen Hintergrund hat!
Aber da Du das ja sowie so gar nicht nutzt ...

Habe die letzten Tage viel experimentiert.
Danke für den Tip (Bemerkung):
Rudolph R. schrieb:
> Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem
> EVE-Asset-Builder, aber erstmal sieht das plausibel aus.
Das geht, wenn man eben nur die Bilddaten konvertieren möchte besser 
(ist übersichtlicher, einfacher). Zum Experimentieren ist der 
EVE-Screen-Editor trotzdem nicht schlecht. Man kann im Vorfeld so 
einiges Probieren...
MERWÜRDIG: Ein stichprobenartiger Vergleich der Daten ein und des selben 
Bildes, konvertiert einmal mit Screen-Editor und einmal mit 
Asses-Builder zeigt recht gravierende Unterschiede!!! Die Darstellung 
ist aber dennoch identisch, zumindest fürs menschliche Auge.

Da meine Hardware schon lange vorher fertig war, habe ich nun (nur ein 
kleines) Problem: Die Bilddaten schnell genug aus den USB-Stick zu 
bekommen.
Da ich mich nicht mit FAT32 und dem ganzen "USB-Gedöhns" auskennen, 
nutze ich den VNC1L (von FTDi), jedoch nicht den fertigen VDIP1, sondern 
eigentlich die Schaltung, so wie sie auf dem VDIP1 drauf ist, in meine 
Applikation komplett integriert. Den "blanken" Chip VNC1L programmiere 
ich vor dem Bestücken mit dem VPROG.
Bei der Schaltung nutze ich LEIDER die Kommunikationsart UART, obwohl 
dieser VNC1L auch SPI und sogar parallel-FIFO kann,  was ja alles viel, 
viel schneller ginge. Aber zum Experimentieren ist es erst mal super. 
Baudrate habe ich auf 1 Mega-Baud. Da benötigt die Grafik 
(Display-Füllend 3,5 Zoll) 320 x 240 eben ca. 6 Sekunden, ehe sie im 
RAM-G ist (besser gesagt: Ehe sie vom Stick herunter ist).
Ich hole die Daten ab (kommen ja als 2 ASCI, dann ein Leerzeichen, also 
3 Byte pro RAM-Byte), bilde SOFORT aus den ASCI das RAM-Byte und schiebe 
es per SPI in den RAM, während das nächste Byte vom VNC1L abgeholt wird. 
Dieses parallele Arbeiten (UART // SPI) funktioniert einwandfrei und ich 
brauch es nicht blockweise zu machen (erst 256 Bytes abholen, daraus ca. 
115 RAM-Bytes bilden, in den RAM schieben, die nächsten abholen, ständig 
mitrechnen ...). Und alles mit einem male abholen geht ja eben nicht, da 
ich nicht weiß, wohin mit den rund 430.000 Byte, wenn man keinen 
zusätzlichen RAM hat, sondern "nur" den PIC mit 128.000 Flash und 3800 
RAM.

Eigentlich bin ich nun VORERTS am Ziel meiner Wünsche (nächste Hardware 
mit Parallel-FIFO am VNC1L ist schon in Arbeit). Nun gibt es allerdings 
ein Phänomen. Ob das jemand kennt? :
Durch einen Zufall (ein Fehler in meiner Software) stellte sich das Bild 
nur in 64-Pixel Breite da (volle Höhe 240). Dabei war ein senkrechter 
hellgrauer Streifen (ca. 50 breit und mitten in diesen 64 Pixel) absolut 
top so dargestellt, wie er sollte. Nachdem ich dann nach 
Fehlerbeseitigung das ganze Bild sah, ist dieser Streifen und auch alles 
andere rechts neben den 64-Breite nach unten hin immer schwächer. Man 
sieht den hellgrauen Streifen unten so gut wie gar nicht mehr. Also habe 
ich mal eine Schleife gesetzt und von 64 Breite beginnend alle 100ms das 
Bild um einen Pixel wachsen lassen:
BITMAP_SIZE(NEAREST, BORDER, BORDER, 64...320, 240)
Und siehe da: Beginnend mit dem scharf gleichmäßig durchgehenden grauen 
Streifen links wurde er allmählich nach unten hin immer schwächer, je 
breiter das Bild wurde !!! ????
Den gleichen Versuch auf einem 7 Zoll Display, mal in die Mitte die 320 
x 240 gesetzt. Hier ist es nicht so, jedoch sind hier alle hellgrauen 
Streifen komplett so gut wie nicht zu sehen. Nur wenn ich mit einem 
Blickwinkel von mind. 45° drauf schaue, wird es so, wie das Original...
Beim 3,5 Zoller kann ich schief schauen, so viel ich will. Es bleibt 
dabei, dass das Bild nach Unten hin immer schwächer wird. So als wenn 
man den ALPHA-Channel nach unten hin immer größer werden lässt.
Hast Du eine Idee, ob man dagegen was unternehmen kann...???

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Das verstehe ich nicht! Bei EDGE_STRIP setzt Du doch beliebige
> Koordinaten, egal wohin!!! So (und nicht anders) setze ich Dreiecke /
> Parallelogramme etc. mitten in das Display:
> CLEAR(1, 1, 1)
> COLOR_RGB(255, 255, 255)
> LINE_WIDTH(256)
> CLEAR(1, 1, 1)
> BEGIN(EDGE_STRIP_R)
> VERTEX2II(20, 65, 0, 0)      'Linke Ecke des Dreiecks
> VERTEX2II(100, 100, 0, 0)    'Spitze Unten
> COLOR_RGB(0, 0, 0)           'ab rechter Kante wieder schwarz
> VERTEX2II(100, 100, 0, 0)    'Spitze Unten
> VERTEX2II(180, 65, 0, 0)     'Rechte Ecke des Dreiecks
> END(0)
> DISPLAY(0)

Das macht zwar ein Dreieck, aber wenn ich nur eine Koordinate verändere 
dann nicht mehr:

CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
LINE_WIDTH(256)
CLEAR(1, 1, 1)
BEGIN(EDGE_STRIP_R)
VERTEX2II(20, 65, 0, 0)
VERTEX2II(100, 100, 0, 0)
COLOR_RGB(0, 0, 0)
VERTEX2II(100, 100, 0, 0)
VERTEX2II(180, 75, 0, 0)
END(0)

Das ist jetzt nur der letzte Punkt 10 Pixel weiter runter.
Also mit "beliebige Koordinaten" wird das nichts, eben weil die 
Edge-Strips jeweils bis an den Rand gehen.

>> Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem
>> EVE-Asset-Builder, aber erstmal sieht das plausibel aus.
> Das geht, wenn man eben nur die Bilddaten konvertieren möchte besser
> (ist übersichtlicher, einfacher). Zum Experimentieren ist der
> EVE-Screen-Editor trotzdem nicht schlecht. Man kann im Vorfeld so
> einiges Probieren...

Definitiv, das Edgestrip Beispiel habe ich gerade im ESE offen.
Es gab übrigens gerade einen neuen ESE: 4.2.0

> MERWÜRDIG: Ein stichprobenartiger Vergleich der Daten ein und des selben
> Bildes, konvertiert einmal mit Screen-Editor und einmal mit
> Asses-Builder zeigt recht gravierende Unterschiede!!! Die Darstellung
> ist aber dennoch identisch, zumindest fürs menschliche Auge.

Welchen EAB hast Du?
Aber davon mal ab, Zumindest der EVE Asset Builder hat leider per 
Default die Option "Dithering" für Bilder an, der überlagert beim 
Konvertieren also praktisch die Bilder mit Rauschen.
Und da stehe ich überhaupt nicht drauf, ich fütter das Ding doch nicht 
mit PNG Dateien damit das nach dem Konvertieren anders ist.
Außerdem verringert das die Komprimierbarkeit mindestens mit zlib.

> Da meine Hardware schon lange vorher fertig war, habe ich nun (nur ein
> kleines) Problem: Die Bilddaten schnell genug aus den USB-Stick zu
> bekommen.
> Da ich mich nicht mit FAT32 und dem ganzen "USB-Gedöhns" auskennen,
> nutze ich den VNC1L (von FTDi),

Mit nichts von dem habe ich hinreichend Erfahrung, aber bis auf das ich 
schon mal einen Arduino mini in einem Projekt verwenden musste hatte ich 
bisher auch noch keine Probleme mit den Assets.

Wobei zur Zeit, ja, normalerweise benutze ich Controller mit 512k oder 
256k Flash, nur jetzt habe ich gerade von denen mit 256k nur welche 
bekommen die lediglich 64k haben, was man eben so bekommen kann...

> Baudrate habe ich auf 1 Mega-Baud. Da benötigt die Grafik
> (Display-Füllend 3,5 Zoll) 320 x 240 eben ca. 6 Sekunden, ehe sie im
> RAM-G ist (besser gesagt: Ehe sie vom Stick herunter ist).

Ugh, Autsch.

> Ich hole die Daten ab (kommen ja als 2 ASCI, dann ein Leerzeichen, also
> 3 Byte pro RAM-Byte),

Das ist übel ineffizient.

> bilde SOFORT aus den ASCI das RAM-Byte und schiebe
> es per SPI in den RAM, während das nächste Byte vom VNC1L abgeholt wird.
> Dieses parallele Arbeiten (UART // SPI) funktioniert einwandfrei und ich
> brauch es nicht blockweise zu machen (erst 256 Bytes abholen, daraus ca.
> 115 RAM-Bytes bilden, in den RAM schieben, die nächsten abholen, ständig
> mitrechnen ...). Und alles mit einem male abholen geht ja eben nicht, da
> ich nicht weiß, wohin mit den rund 430.000 Byte, wenn man keinen
> zusätzlichen RAM hat, sondern "nur" den PIC mit 128.000 Flash und 3800
> RAM.

Warum hast Du die Bilder unkomprimiert auf dem Stick?
Ich habe mir gerade mal ein möglichst chaotisches Bild gesucht, auf 
320x240 geschnitten und zu RGB565 konvertiert.
Das sind 153600 Bytes wie erwartet.
Wenn ich das entweder durch den "Asset Compressor" schicke oder beim 
Konvertieren den Haken bei "Compressed" drin habe, dann werden das 50574 
Bytes.
Gleich noch mal die Probe mit "Dithering" an - Ugh, 81506 Bytes.

Also auf die Hälfte kommt man schon runter, eher wird es noch weniger.
Ich habe gerade mal ein Hintergund Bild aus dem Netz gefischt und 
inklusive Watermark drin auf 320x240 konvertiert und bei 80% als .jpg 
gespeichert.
Komprimiert hat das 41305 Bytes.
Das sind so 27% und müssten unter gleichen Bedingungen in unter 1,7s 
übertragen sein. Auch nicht toll, aber besser als 6s.
Geladen wird das dann mit CMD_INFLATE.

> Durch einen Zufall (ein Fehler in meiner Software) stellte sich das Bild
> nur in 64-Pixel Breite da (volle Höhe 240).
>......
> Hast Du eine Idee, ob man dagegen was unternehmen kann...???

Ich kann nicht behaupten das ich sowas ähnliches schon mal beobachtet 
hätte.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Rudolph R. schrieb:
> Das macht zwar ein Dreieck, aber wenn ich nur eine Koordinate verändere
> dann nicht mehr:
>
> CLEAR(1, 1, 1)
> COLOR_RGB(255, 255, 255)
> LINE_WIDTH(256)
> CLEAR(1, 1, 1)
> BEGIN(EDGE_STRIP_R)
> VERTEX2II(20, 65, 0, 0)
> VERTEX2II(100, 100, 0, 0)
> COLOR_RGB(0, 0, 0)
> VERTEX2II(100, 100, 0, 0)
> VERTEX2II(180, 75, 0, 0)
> END(0)

Das ist korrekt, was Du sagts. Aber um z.B. ein Dreieck zu erhalten, 
musst Du eben den letzten Punkt auf die gleiche Höhe setzen. Und man 
kann beliebig viele Punkte setzen. Muss aber natürlich dabei wissen, was 
man tut. Und soll eine durchgehende Verbindungs- (Zick-Zack-Linie) 
beendet und da neben neu gesetzt werden (um ein "Zick-Zack-Rechteck zu 
erhalten), muss Du End(0) und wieder Begin(Edge_Strip_R) mit der Farbe 
rechts vom Rechteck setzen, da sonst die Linie weiter geführt wird.

Das ist schon interessant, was ich hier von Dir immer wieder so 
"nebenbei" herauslese. Ich frage nach einem konkreten Problem, bei dem 
Du mir (leider) nicht helfen kannst, aber beschreibts z.B. das 
"Dithering". Bei der Suche nach dem beschriebenen Phänomen habe ich 
schon mit dem Register "REG_DITHER" experimentiert. Hat nichts gebracht, 
ohne zu wissen, was dieses Register wirklich ändert. Denn "Dither" heißt 
ja "zittern" und "Dithering" heißt "schwankend". Wie soll man also auf 
"Rauschen" kommen, wenn beim Builder das Häkchen gesetzt ist. Das 
probiere ich noch aus, ob es hier dann einen Unterschied gibt. Kann das 
nicht einfach dann "Noise" heißen ???

Das Thema Kompression ist mir im Moment noch zu schwierig, da ich dann 
ja wieder auf den Co-Prozessor zugreifen muss. Ist immer noch kein 
Thema. Wie schon gesagt, ist auch nicht wirklich schlimm. Später nutze 
ich die schnelle Verbindung vom USB zum RAM-G. Und ein Komprimieren nach 
meiner Art kann ich dann auch noch machen und weiß dann auch, wie ich es 
beim Auslesen entschlüsseln (dekomprimieren) kann. Viele Bytes sind 
nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine 
Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche 
Bytes", dann eine 17 (17 mal das folgende Byte) und dann ein FF. Also 
aus 17 Bytes sind so 3 Bytes geworden. Mit ")" (Hex 29) kündigt man 2 
wechselnde Byte an, was auch sehr oft ist, da ja gleiche Pixel bei 2 
Byte pro Pixel diesen Wechsel ergeben. z.B. 12 Folgen von dem Wechsel 
der beiden Bytes 9C und 67: Hx29 Hx0C Hx9C Hx67. Aus 24 Byte sind 4 
geworden ...
Das mache mit einem eigenen "Komprimierer" (wenn es dann mal 
erforderlich ist).
So jage ich z.B. auch meine eigenen Update-Dateien, die an Kunden gehen, 
vorher durch einen "Verschlüsseler". Die Datei wird dann im Gerät beim 
Update wieder von dem Gerät entschlüsselt (da alle meine Update-fähigen 
Geräte einen einheitlichen Schlüssel dafür haben).
Einen schönen Abend noch !!!

[Rudolph R. (rudolph)]

> Das ist korrekt, was Du sagts. Aber um z.B. ein Dreieck zu erhalten,
> musst Du eben den letzten Punkt auf die gleiche Höhe setzen. Und man
> kann beliebig viele Punkte setzen. Muss aber natürlich dabei wissen, was
> man tut. Und soll eine durchgehende Verbindungs- (Zick-Zack-Linie)
> beendet und da neben neu gesetzt werden (um ein "Zick-Zack-Rechteck zu
> erhalten), muss Du End(0) und wieder Begin(Edge_Strip_R) mit der Farbe
> rechts vom Rechteck setzen, da sonst die Linie weiter geführt wird.

Ja genau, einfach mal so ein Dreieck zu malen ist damit nicht möglich. 
:-)
Aber der eigentliche Knackpunkt ist das ich Dreiecke bisher auch nicht 
wirklich vermisst habe.
Und was eben wirklich einfach geht sind Rechtecke, auch mit abgerundeten 
Ecken.

> Das ist schon interessant, was ich hier von Dir immer wieder so
> "nebenbei" herauslese. Ich frage nach einem konkreten Problem, bei dem
> Du mir (leider) nicht helfen kannst, aber beschreibts z.B. das
> "Dithering". Bei der Suche nach dem beschriebenen Phänomen habe ich
> schon mit dem Register "REG_DITHER" experimentiert. Hat nichts gebracht,
> ohne zu wissen, was dieses Register wirklich ändert. Denn "Dither" heißt
> ja "zittern" und "Dithering" heißt "schwankend". Wie soll man also auf
> "Rauschen" kommen, wenn beim Builder das Häkchen gesetzt ist. Das
> probiere ich noch aus, ob es hier dann einen Unterschied gibt. Kann das
> nicht einfach dann "Noise" heißen ???

REG_DITHER macht was vergleichbares, im Grunde soll es die Ausgabe 
verbessern indem harte Übergänge reduziert werden.
Nur während sich REG_DITHER auf die Ausgabe auswirkt, verändert das 
Dithering die Bilder bei der Konvertierung was sich wiederrum auf die 
Komprimierbarkeit auswirkt.
Das sagt nichts darüber aus ob das resultierende Bild besser oder 
schlechter aussieht, es lässt sich nur schlechter komprimieren und die 
Pixel die man da rein steckt sind nicht die Pixel die man da raus 
bekommt.

Ich habe gerade noch mal aus Jux ein Bild gepixelt, einfach ein paar 
Sterne ohne aktiviertes Anti-Aliasing.
Ohne Dithering komprimiert das auf 2661 Bytes, mit auf 3707 Bytes.

Es kann sogar sein, dass dieses Bild mit Dithering besser aussieht.

> Das Thema Kompression ist mir im Moment noch zu schwierig, da ich dann
> ja wieder auf den Co-Prozessor zugreifen muss.

Ja, das ist richtig.

> Und ein Komprimieren nach
> meiner Art kann ich dann auch noch machen und weiß dann auch, wie ich es
> beim Auslesen entschlüsseln (dekomprimieren) kann. Viele Bytes sind
> nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine
> Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche
> Bytes",

Ja, nennt sich Runtime Encoding, damit kommt man aber nicht ganz so weit 
wie mit der zlib Kompression die EVE bereits eingebaut hat. :-)

Dabei hatte ich gerade ein C64 Flashback. :-)

Nein, im Ernst, ein großer Vorteil ist ja das die Daten dann komprimiert 
über den SPI gehen. Also der Controller muss da gar nichts entpacken.

[Alf S. (alfsch)]

>Also wenn Du die notwendigen paar angepassten Zeilen für spi_transmit()
und spi_receive() posten magst, dann füge ich die gerne noch ein.

mit dem Projekt, in der STM32cubeIDE mit HAL lib, ohne jegliche 
Optimierung oder DMA , dauert ein Bild zu übertragen ca. 500us ; daher 
habe ich vorerst den Aufwand mit der DMA sein lassen, weil das die 
CPU-Last natürlich verrringern würde. aber der zu erwartende Gewinn von 
ca. 5% auf 2% runter zu kommen -- keine wirkliche Bedeutung hat.
hier die HAL Aufrufe:

 void spi_transmit(uint8_t data)
{
  HAL_SPI_Transmit(&hspi5, &data, 1 , 5);
}

uint8_t spi_receive(uint8_t data)
{
  uint8_t  dain;
  HAL_SPI_TransmitReceive(&hspi5, &data, &dain, 1 , 5);
  return (dain);
}


// die Definition für das 7" TFT ist diese:

#define EVE_EVE2_70G                // neu für :  NHD-7.0-800x480FT-CTXL-T, EVE2
#define EVE_HAS_CRYSTAL            // TFT hat 12 MHz extern

/* Matrix Orbital EVE2 modules EVE2-50G, EVE2-70G : 800x480 5.0" and 7.0" capacitive touch, FT813 */
/* Crystalfonts CFAF800480E0-050SC 800x480 5.0" , FT813 capacitive touch */
// NewHaven NHD-7.0-800480FT-CSXV-T
#if defined (EVE_EVE2_50G) || defined (EVE_EVE2_70G) || defined (EVE_CFAF800480E0_050SC)
#define Resolution_800x480
#define EVE_PCLK  (2L)
#define EVE_PCLKPOL  (1L)
#define EVE_SWIZZLE  (0L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (4800L)
#define EVE_GEN 2
//#define EVE_HAS_GT911  /* special treatment required for out-of-spec touch-controller */
#endif

[Rudolph (Gast)]

Alf S. schrieb:
> hier die HAL Aufrufe:

Hmm, hast Du einen Logic-Analyzer?
Zeiche das wenn möglich mal auf, das kann auch bei deutlich niedrigerem 
SPI Takt sein, 2MHz oder 4MHz, mich interessiert da vor allem wie lang 
die Pause zwischen den einzelnen Bytes ist.

[Alf S. (alfsch)]

na gut , einfach schnell Bild mit DSO gemacht, am TFT mit ca. 30cm 
Flachbandkabel davor ...
und nein, der Takt kann nicht anders sein, als ich ihn will/einstelle. 
Dazu muss im cube nur der clock-tree entsprechend eingastellt werden, 
hier auf 100MHz für die SPI unit und div4 in der SPI.
wie gesagt, mit 25MHz clk, die langen (1,8us) delays zwischen den Bursts 
kommen daher, wie schon gesagt, dass ich einfach die HAL lib Aufrufe 
benutzt habe, auch für das setzen der CS bit hi/lo , was ja jeweils in 
mindestens ein zwei Subroutinen verzweigt und daher ....dauert.
mit etwas mehr Zeit für das Ganze, würde ich erstmal die CS-bit setzen 
mit einem direkten write auf das Portrefister, das dauert dann statt 
rund 1us etwa 10ns , auch beim SPI Aufruf. DANN könnte man noch die DMA 
anwerfen und die CPU-Last auf < 1% bringen, bei maximaler "Action" (wie 
die bewegten Dreiecke, die ja bei jeden Bildaufbau des TFT andere 
Koordinaten haben)

[Rudolph (Gast)]

Genau so was habe ich befürchtet, keine Ahnung warum die Hersteller alle 
Bitcoin-Miner in die Treiber einbauen. :-)

Für CS ist die Verzögerung in Ordnung, das passiert ja nur zwei Mal.

Du könntest mal die LowLevel HAL verwenden wie ich das für die anderen 
STM32 schon vorgesehen habe, also stm32h7xx_ll_spi.h einbinden.

Blöderweise haben die Status-Flags im H7 leicht andere Namen.
Ich habe da gestern mal kurz reingeschaut, das hier könnte 
funktionieren, ist aber blind eingetippt.
Damit sollten die Pausen deutlich kleiner werden, da das im Grunde ja 
direkter Register-Zugriff ist.

static inline void spi_transmit(uint8_t data)
{
  LL_SPI_TransmitData8(EVE_SPI, data);
  while(!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {};
  while(!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {};
  LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXWNE */
}

static inline uint8_t spi_receive(uint8_t data)
{
  LL_SPI_TransmitData8(EVE_SPI, data);
  while(!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {};
  while(!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {};
  return LL_SPI_ReceiveData8(EVE_SPI);
}

[Alf S. (alfsch)]

die "ohne viel Nachdenken" Version mit HAL lib: CS setzen..

 void EVE_cs_set(void)
{
  HAL_GPIO_WritePin(GPIOF, GPIO_PIN_6, RESET);                  // set lo manually set chip-select to low */
}

void EVE_cs_clear(void)
{
  HAL_GPIO_WritePin(GPIOF, GPIO_PIN_6, SET);                  // set hi manually set chip-select to high */
}

 --> so wird EIN assembler Befehl daraus
 zB mit :  GPIOF->BSRR = 0x0020;  etwa so -->

#define EVE-cs_set()   GPIOF->BSRR = 0x0020

dann wird es wirklich flott, ca. 17ns hatte ich mit einem STM32F411 
gemessen für port -> lo + wieder -> hi setzen; bei dem H7A3 würde es 
wohl in 10ns laufen, sprich man muss evtl noch delays einfügen, weil die 
CPU sonst zu schnell für die anderen chips ist.
und bei so sofware erzeugten CS Signalen ist dann die DMA auch sinnlos, 
weil man für das CS->hi ja auf das Ende der DMA / SPI action warten 
muss, bis das CS hi gesetzt wird oder einen INT am DMA ready erzeugt, 
was dann aber vmtl genauso viel CPU Takte benötigt.
+ nebenbei: ich habe beim core D- und I- cache ON , somit wird die 
Benutzung der DMA echt komplex, da dann per MPU sichergestellt werden 
muss, dass die Speicherbereiche der DMA Transfers "dirty" sind, bzw vom 
cache ausgeschlossen sind. DAS war mir zu komplex, für den potentiellen 
"Gewinn" von ein paar Mikrosekunden.

und der SPI send entsprechend auch als ein Befehl:

 SPI5->TXDR = data;

die SPI sendet automatisch, sobald ins Tx register geschrieben wird...

[Rudolph (Gast)]

Alf S. schrieb:
> und bei so sofware erzeugten CS Signalen ist dann die DMA auch sinnlos,
> weil man für das CS->hi ja auf das Ende der DMA / SPI action warten
> muss, bis das CS hi gesetzt wird oder einen INT am DMA ready erzeugt,

Deshalb nutze ich dafür ja auch einen Interrupt.
Jetzt nicht für die STM32, okay, aber bei den ATSAM sieht man das zum 
Beispie in der EVE_target.c in der DMAC_Handler() Funktion.

Erst noch warten das der letzte Transfer durch ist, dann CS wieder hoch 
ziehen.

> + nebenbei: ich habe beim core D- und I- cache ON , somit wird die
> Benutzung der DMA echt komplex, da dann per MPU sichergestellt werden
> muss, dass die Speicherbereiche der DMA Transfers "dirty" sind, bzw vom
> cache ausgeschlossen sind.

Oha, sowas ist mir zum Glück noch nicht in die Quere gekommen.

>DAS war mir zu komplex, für den potentiellen
> "Gewinn" von ein paar Mikrosekunden.

Unterschätz das mal nicht, das dürfte auf dem H7 auf locker <10µs 
schrumpfen und zwar auch bei deutlich mehr auf dem Display.

> und der SPI send entsprechend auch als ein Befehl: SPI5->TXDR = data;
> die SPI sendet automatisch, sobald ins Tx register geschrieben wird...

LL_SPI_TransmitData8(EVE_SPI, data); ist ja auch nichts anderes, nur 
hübscher verpackt. :-)
Nur wartet das eben nicht das der Transfer durch ist.

Was anderes was mir gerade noch eingefallen ist, Du könntest den DMA 
Support nutzen um ohne DMA zu verschicken.

Du hast ja vorher das hier verwendet:
HAL_SPI_Transmit(&hspi5, &data, 1 , 5);

Die Funktion schickt also einen Puffer.
Und mit DMA und den EVE_cmd_xxx_var_burst() Funktionen wird der Puffer 
über spi_transmit_burst() zusammen gebaut:

static inline void spi_transmit_burst(uint32_t data)
{
#if defined (EVE_DMA)
EVE_dma_buffer[EVE_dma_buffer_index++] = data;
#else
spi_transmit_32(data);
#endif
}

Dieser Puffer wird mit EVE_start_dma_transfer() verschickt.

Die könnte auch so aussehen:

 void EVE_start_dma_transfer(uint8_t data)
{
  EVE_cs_set();
  HAL_SPI_Transmit(&hspi5, ((uint8_t *) &EVE_dma_buffer[0])+1, (((EVE_dma_buffer_index)*4)-1) , 5);
  EVE_cs_clear();
}

Ja, Adresse und Länge sehen etwas seltsam aus, das liegt daran das als 
erstes die Adresse verschickt wird und die hat nur 3 Bytes.

Das ist zwar immer noch kein DMA, sollte aber deutlich fixer gehen.

Dazu noch ein das hier in der EVE_target.h:

#if defined (EVE_DMA)
extern uint32_t EVE_dma_buffer[1025];
extern volatile uint16_t EVE_dma_buffer_index;
extern volatile uint8_t EVE_dma_busy;

void EVE_init_dma(void);
void EVE_start_dma_transfer(void);
#endif

Die EVE_init_dma() muss vorhanden sein, wäre in diesem Fall aber einfach 
leer.

[Alf S. (alfsch)]

Hi,  also wenn schon, dann mit DMA , sonst fehlt ja der Reiz.
(zu sehen, wie schnell das Ding wirklich ist)
Habe mir das ein wenig überlegt und es sollte eigentlich ohne Probleme 
mit cache+optimizer gehen, weil es wird ja nur in den buffer geschrieben 
und dann zum EVE gesendet, aber nie per DMA zurückgelesen.
wie muss ich das eigentlich machen: mit zusätzlichem " #define H7A3 " 
und jeweils in " #if defined (STM32L073xx) ||...." entsprechend 
DMA-Kanal usw ändern bzw rein schreiben ?

[Rudolph R. (rudolph)]

So, hilft zwar jetzt noch nicht direkt mit STM32, aber ich habe gerade 
endlich mal meinen Entwicklungs-Zweig mit dem mit dem 5.x Zweig 
synchronisiert.

Da ist jetzt zum einen die STM32H7 "Erweiterung" in EVE_target.h, zum 
anderen ist jetzt das STM32 "Beispiel" enthalten.

Dieses Beispiel macht immer noch nichts sinnvolles, da in der main.c 
nicht genug drin ist und DMA unterstützt das für STM32 auch immer noch 
nicht.
Aber das baut einfach so durch für diverse STM32:

Environment    Status    Duration
-------------  --------  ------------
STM32L073      SUCCESS   00:00:02.775
STM32F030      SUCCESS   00:00:02.468
STM32F103      SUCCESS   00:00:02.587
STM32F303      SUCCESS   00:00:03.115
STM32F446      SUCCESS   00:00:03.946
STM32G474      SUCCESS   00:00:03.678
STM32G431      SUCCESS   00:00:03.499
nucleo_f439zi  SUCCESS   00:00:03.888
nucleo_h743zi  SUCCESS   00:00:06.119

Damit wird zumindest schon mal der Code in der Library einwandfrei für 
STM32 compiliert.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Nun habe ich wochenlang so diverse Bitmaps geladen und dargestellt 
(teils zum Üben, aber dann hauptsächlich sinnvoll für bestimmte 
Projekte), habe mit diversen Befehlen herumgespielt und es funktioniert 
alles tadellos. Dank des EVE Screen Editors (V4.2.0) konnte ich so 
manche "Geheimnisse" entschlüsseln bzw. mir im Vorfeld so dieses oder 
jenes anschauen, ehe ich mühselig an der realen Platinen mit Koordinaten 
und dergleichen herum probiere. Und so habe ich auch einfach mal den 
Befehl CMD_GRADIENT im EVE Editor "entschlüsselt". Selbst wenn ich den 
Co-Prozessor benutzen würde, müsste man sich den gewünschten Farbverlauf 
ohnehin am EVE zurechtschieben und dann die Koordinaten übernehmen. Ich 
habe mir dazu eine Bibliothek geschaffen, der ich vor Aufruf die entspr. 
Werte für die 2 Farben, für TransformA-F, Source usw. übergebe und 
fertig ist mein Wunsch-Farbverlauf, auch ohne Co-Prozessor.
Nun habe ich das erste mal eine Grafik 600 x 480 darstellen wollen. Das 
Original (Lageplan ohne Kuller) sieht so aus. Nach dem Experimentieren 
mit SIZE_H und SIZE_H (auch mit Hilfe des EVE schnell entschlüsselt) hat 
es dann auch geklappt. Jedoch sah das Bild dann so aus 
(ARGB1555zuARGB1555). Nach vielen diversen Versuchen mit verschiedenen 
Formaten kam ich dann mal auf die glorreiche Idee, das Bild im Format 
RGB565 darzustellen. Und siehe da, es sah aus, wie das Original. Also: 
konvertiert als ARGB1555, aber dann als RGB565 darstellen !!! Gibt es 
dazu eine Erklärung? Das ist mir vorher (mit Bildern < 511 Pixel) nie 
passiert. Im Gegenteil: Hier sah das Bild eher so aus, wenn  nicht 
Konvertierungsformat gleich Darstellung. Nun ja, so geht es zwar, aber 
ist doch merkwürdig!!???
Co-Prozessor: Hier fehlt mir jedoch noch eine Kleinigkeit. Schön wäre 
es, wenn ich einen Spinner (der sich auch selbst im Hintergrund entspr. 
"bewegt") darstellen könnte (z.B. während des Ladens der Grafiken). Ohne 
Co-Prozessor hat man dabei (wenn man es "Zu Fuß" als mit DL-Befehlen 
macht) sogar noch mehr Gestaltungsmöglichkeiten in Form, Größe, Farbe 
... Jedoch bewegt der sich ja nicht. Es reicht hier leider nicht ganz, 
die DL-Befehle so einzugeben. Dann entsteht eben nur der "stehende" 
Spinner. Hier muss zum Schluss sicher noch ein ganz bestimmtes Register 
gesetzt werden ...?????
Hast Du da eine Idee?
Nun möchte ich ja auch gleich wieder noch mehr: Den BT815 testen, um 
auch 10 Zoll-Displays beschreiben zu können. Wie für den FT8... gibt es 
hier auch diverse Demo-Boards. Jedoch habe ich kein Set mit 
10-Zoll-Display gefunden. Im Gegensatz zum VM800, die es ohne und mit (7 
Zoll) Display als Set gibt. Kennst Du so ein Set, oder ein passendes 
10-Zoll-Display (Belegung des 50-poligen Flachbandkabels !!!) zu einem 
entspr. Demo-Board?
Besinnliche Adventzeit !!! Liebe Grüße von der Ostsee.

[Rudolph R. (rudolph)]

Die Bildfrage kann man über das Forum eigentlich nicht mal versuchen zu 
beantworten, da hier automatisch das Format von PNG Bildern konvertiert 
wird, warum auch immer.
Wenn ich das runter lade und zum bearbeiten in Paint.net öffne hat das 
schon mal gar keinen Alpha-Channel.
Das kann ja Absicht sein, aber ARGB1555 passt dann nicht wirklich.

Die Animation von dem Spinner dürfte der Co-Prozessor machen, an dem 
vorbei dürfte das nicht gehen, da die Display-Liste an sich ja statisch 
ist.
Und wenn man direkt die Display-Liste schreibt kann man auch die Daten 
über den SPI nicht wirklich optimieren, Stichwort CMD_APPEND.

Die BT815 sind für 10" nicht ernsthaft geeignet, die haben nur eine PLL, 
damit ist der Pixel-Takt nur durch feste Werte teilbar.
Bridgetek hatte zwar mal eine Demo, aber 60HZ hat die bei 1024x600 eher 
nicht erreicht.
Das ist mit den BT817 viel schicker gelöst.

Das nächste Problem bei 10" ist das die meistens Displays jenseits von 
800x480 inzwischen keine RGB Schnittstelle mehr, sondern LVDS haben.
Also muss da zu dem BT817 noch ein RGB/LVDS Converter mit drauf.
Ok, es gibt 1024x600 in 7", aber das fällt quasi unter exotisch.

Ich benutze ja ohnehin nur fertige Module, für den Fall würde sich das 
aber denke ich auch zunächst anbieten.
In 10" habe ich ein RVT101HVBNWC00-B mit 1280x800 und in 7" habe ich ein 
RVT70HSBNWC00-B mit 1024x600.
Die "-B" Version ist die höchste Variante mit optical bonding.
TME hat noch je 1 Stück, Mouser hat RVT70HSBNWC00.
Mein RVT101HVBNWC00-B habe ich direkt bei Riverdi gekauft, das hat dann 
aber etwas mehr gekostet, da kam ordentlich Versand drauf.
Ach so, das RVT70H ist ohne LVDS, das RVT101H mit LVDS.

[Holger H. (sachma)]

bei ali
10.1" LCD screen EJ101IA-01G (1280x800)
Kostet zwischen 24-34 EUR

Zum Testen von unterschiedlichen Displays habe ich mir ein paar kleine 
Boards zusammengebaut.
1)Konverterplatine TTL-LVDS(50Pin->40Pin)
2)Spannungsversorgung-Platine für das Display
3)BT815/6/7/8 Board (mit BT817 bestückt)

Meistens aber nicht immer:
1024x Displays Benötigen 2) aber nicht 1)
1280x Displays Benötigen 1) 2)

je nach Display sind die Pins an den Flexprintbuchsen umzubelegen oder 
umzulöten

[Rudolph R. (rudolph)]

Heads-Up: I am currently changing the return values for EVE_busy(), 
EVE_init() and EVE_init_flash().

So far these three return an uint8 with a 0 for FALSE and a 1 for TRUE.
However, returning a zero on success is more common and also allows for 
more meaningfull values to be returned on failure.

So far I have these:

enum
{
    E_OK = 0,
    E_NOT_OK,
    EVE_FAIL_CHIPID_TIMEOUT,
    EVE_FAIL_RESET_TIMEOUT,
    EVE_FAIL_PCLK_FREQ,
    EVE_FAIL_FLASH_STATUS_INIT,
    EVE_FAIL_FLASH_STATUS_DETACHED,
    EVE_FAIL_FLASHFAST_NOT_SUPPORTED,
    EVE_FAIL_FLASHFAST_NO_HEADER_DETECTED,
    EVE_FAIL_FLASHFAST_SECTOR0_FAILED,
    EVE_FAIL_FLASHFAST_BLOB_MISMATCH,
    EVE_FAIL_FLASHFAST_SPEED_TEST
};

You might wonder about the first two, this is a nod to Autosar 
Std_ReturnType.

[Rudolph R. (rudolph)]

And I just pushed a small update.
EVE_busy() practically works like always with returning zero for not 
busy but no longer 1 for beeing busy but EVE_IS_BUSY which currently has 
a value of 12.

[Spyy (Gast)]

Moin,

nach einem "Ausflug" zu einem Raspi CM4 mit Linux Treiber schreiben für 
mein Display, bin ich heute zum Teensy 4.1 mit meinem Display zurück 
gekehrt.
Ich habe keinen externen Quarz und speise jetzt vom Teensy ein 12 Mhz 
PWM 50% Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit 
externer clock :-) => ich nutze den ganzen internen quatsch nicht 
mehr....
und....
Ich habe den Fehler gefunden, warum ich nicht mit mehr als ca. 25ms 
zyklus per dma auf den Chip schreiben konnte ohne das sich das System 
aufgehängt hat...
Für das zyklische DMA Schreiben habe ich im Teensy ein Intervalltimer 
benutzt. Das verheddert sich dann offensichtlich bei kürzeren Zyklus < 
25ms...keine Ahnung warum. Ich habe nun "das zyklische Schreiben" in der 
normalen Loop Schleife mit delay....und siehe da...ich kann jetzt locker 
alle 10 ms mit 25 Mhz SPI schreiben, das läuft jetzt seit heute Mittag 
ohne Probleme...super...

Noch ne Frage: Ich sehe das der BT81x überall out of stock ist und kein 
mögliches Lieferdatum...ist das die Chip Krise oder ist der Chip 
abgekündigt?

Grüsse

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> Ich habe keinen externen Quarz und speise jetzt vom Teensy ein 12 Mhz
> PWM 50% Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit
> externer clock :-) => ich nutze den ganzen internen quatsch nicht
> mehr....

Na, das ist doch auch nett. :-)

Spyy schrieb:
> Ich habe nun "das zyklische Schreiben" in der
> normalen Loop Schleife mit delay....und siehe da...ich kann jetzt locker
> alle 10 ms mit 25 Mhz SPI schreiben, das läuft jetzt seit heute Mittag
> ohne Probleme...super...

Ich mach das in meinem Arduino Beispiel ja mit millis() und das läuft so 
auch mit dem Teensy 4.

Aber 10ms sind etwas sehr knapp, das wären ja 100Hz, das Update darf 
nicht schneller erfolgen als die Bildwiederholrate.
Da ich die Displays normal auf 60Hz konfiguriere mache ich den Refresh 
mit 50Hz, also alle 20ms.

Spyy schrieb:
> Noch ne Frage: Ich sehe das der BT81x überall out of stock ist und kein
> mögliches Lieferdatum...ist das die Chip Krise oder ist der Chip
> abgekündigt?

Also wenn man bei Mouser schaut, dann haben die 2888 BT818Q-R und 774 
BT818Q-T auf Bestellung, dazu über 5500 BT817.
Farnell/Newark hofft auf Bestand Mitte April.
Ich tippe auf Chipkrise.

Das wird auch noch lange so weiter gehen, mindestens dieses Jahr.
Das Problem wird auch dadurch nicht entschärft das man im Moment über 
Bedarf einkaufen muss, wenn man überhaupt mal was bekommt.
Mouser hat gerade ein Tray ATSAME51J19A-AU erhalten, 320 Stück, da hatte 
ich schon 12 Stück von im Warenkorb bevor die überhaupt angekommen sind.
Heute Vormittag konnte ich endlich bestellen und keine 12 Stunden nach 
Wareneingang haben die nur noch 218 Stück.
Die nächsten kommen dann vielleicht Mitte Februar 2023, ja 202*3*.
Ich bräuchte dann auch langsam mal wieder ATSAMC21, das wird dieses Jahr 
wohl nichts...

[Spyy (Gast)]

Rudolph R. schrieb:
>> Ich habe keinen externen Quarz und speise jetzt vom Teensy ein 12 Mhz
>> PWM 50% Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit
>> externer clock :-) => ich nutze den ganzen internen quatsch nicht
>> mehr....
>
> Na, das ist doch auch nett. :-)

=> ja dann kann man den Chip sogar übertakten....

Ich habe da nochmal ne Frage zu custom fonts...ich komme da nicht 
weiter...
Also ich habe:
1. Einen Font als TTF (10 Zahlen)
2. Eine .txt Datei um nur die 10 Zahlen umzuwandeln
3. EveAssetBuilder 2.10
4. Ich habe keinen Flash muss also aus dem Progmem in den EVE kopieren, 
brauche also irgendwie am Ende ne Headerdatei wo das "Feld" gespeichert 
ist.

Wie ist jetzt da der workflow und welches ist dann das einfachste Format 
?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> => ja dann kann man den Chip sogar übertakten....

Das klingt irgendwie verlockend, aber leider gibt es im Datenblatt auch 
keine Grenzen für die Frequenz, 12,000 MHz sollen es sein.

Spyy schrieb:
> 3. EveAssetBuilder 2.10

Ugh, wie ich gerade gesehen habe ist das wirklich die Version die man 
aktuell bekommen kann.
Irgendwie läuft das bei BRT gerade nicht mit der Software, die 2.4.1 war 
Anfang November raus, mein letzter Fehlerbericht war am 12.12.
Das ist doch mindestens eine Woche für einen Hotfix-Patch und 
Re-Release. :-)
Die 2.1.0 läuft auch, hat aber noch den alten ASTC Encoder drin, das ist 
dann etwas langsam.

Das BRT Forum stockt auch kräftig, hoffentlich sind das immer noch die 
Ferien, immerhin sind es inzwischen zwei Moderatoren.

> 4. Ich habe keinen Flash muss also aus dem Progmem in den EVE kopieren,
> brauche also irgendwie am Ende ne Headerdatei wo das "Feld" gespeichert
> ist.
>
> Wie ist jetzt da der workflow und welches ist dann das einfachste Format
> ?

Als das "einfachste" Format würde ich jetzt ASTC bezeichnen, aber ich 
habe eigentlich nur wegen UTF-8 am meisten damit gespielt.
In dem Fall sind die 128 Zeichen maximal ja kein Problem und ich habe 
das gerade mal durchgespielt.
Als ASTC hat ein 24er Font mit 0...9 genau 16kiB.
Im Legacy Format aber nur 3712 Bytes.

Wenn ich diese 3717 Bytes .raw mit dem "Asset Compressor" packe bleiben 
davon noch 1442 Bytes die man mit CMD_INFLATE verschieben kann.

In der .raw Datei sind sowohl die Glyphen drin als auch 
Verwaltungsinformationen.
Darum gibt man beim Konvertieren auch gleich die "Address of Font Data" 
mit an, per Default steht das auf RAM_G + 1000.
Aber, der "Legacy Font Metrics Block" ist dokumentiert, an Offset 144 
steht der Pointer auf die Glyph-Daten.

Darum funktioniert sowas hier:
 EVE_cmd_inflate(MEM_FONT, font_l4, sizeof(font_l4));
 EVE_memWrite32(MEM_FONT + 144, MEM_FONT + 148);

Für den Test hatte ich MEM_FONT so definiert:
 #define MEM_FONT 0x00001234

Also im Grunde kann das dann überall stehen.
Vielleicht vorsichtshalber auf 4 Byte aligned.

Und dann noch sowas:
 EVE_cmd_setfont2_burst(10, MEM_FONT, 32);
 EVE_cmd_text_burst(10, 100, 10, 0, "Hello there...");

Wobei in dem Fall eher so:
 EVE_cmd_setfont2_burst(10, MEM_FONT, 0x30);
 EVE_cmd_text_burst(10, 100, 10, 0, "0123456789");

Achtung Falle, CMD_SETFONT2 erwirkt einen BITMAP_HANDLE(x) Befehl in der 
Display-Liste und dreht den Kontext dann nicht wieder zurück.
Und ein folgendes CMD_SETBITMAP bezieht sich einfach auf das aktuelle 
Bitmap-Handle.

[Spyy (Gast)]

Hi Rudolph,

Sorry, hat sich überschnitten...hat jetzt geklappt...hatte das mit der 
Registrierung über setfont2 an der falschen Stelle stehen...
Ich mache das aber jetzt mit .glyph und .xfont in zwei Header 
Dateien...die ich dann ins MEM vom EVE kopiere...
Ich habe L1 verwendet und L2 => geht
Bei ASTC zeigt es nix...muss man da noch deflaten?
Mein Font sieht aber ein wenig dünn und etwas "zerfranzt" aus...liegt 
das an L1 oder L2 etc.? Wird das mit zunehmender Lx besser?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> Ich mache das aber jetzt mit .glyph und .xfont in zwei Header
> Dateien...die ich dann ins MEM vom EVE kopiere...
> Ich habe L1 verwendet und L2 => geht
> Bei ASTC zeigt es nix...muss man da noch deflaten?

Normal nicht, aber es lohnt sich durchaus die durch den Asset Compressor 
zu schicken und per CMD_INFLATE an EVE zu schicken.

Hast Du denn im EAB bei der Konvertierung auf ASTC von "FLASH" auf 
"RAM_G" umgestellt?
Die Adresse wird in die .xfont Datei eingetragen, für "RAM_G" sollte man 
sich da auch dran halten.
Für "FLASH" ist es so das EAB die .xfont Datei automatisch manipuliert 
wenn man die zusammen mit der .glyph in einen Flash-Container wirft.

> Mein Font sieht aber ein wenig dünn und etwas "zerfranzt" aus...liegt
> das an L1 oder L2 etc.? Wird das mit zunehmender Lx besser?

Dünn liegt villeicht eher am Font, zerfranst liegt an L1/L2. Mit 2 Bit 
kann das Dithering noch nicht wirklich was anfangen.

[Spyy (Gast)]

Rudolph R. schrieb:
> Hast Du denn im EAB bei der Konvertierung auf ASTC von "FLASH" auf
> "RAM_G" umgestellt?

Ja das war genau der Fehler...Danke...

Nochmal ne Frage, wieso sind denn immer 128 Glyphen in der .ttf 
drin...ich habe doch nur die Zahlen von 0 bis 9 und den Rest gelöscht?
Dann kommen bei mir uncompressed immer 32kB an .glyph raus...:(

Und irgendwie ist der Wurm drin, wenn ich das mit der .raw mache...
Ich habe im EAB (siehe screenshot):
1. Legacy format
2. L8
3. setfont2
4. RAMG+1000
5. User defined char set
=> Bekomme dann ne .raw => daraus mache ich ein Array mit "Convert a 
binary to textfile C Array => Daraus mache ich eine Header Datei.
Dieses kopiere ich hiermit ins RAMG

  for (uint16_t i = 0; i < sizeof(fontData24_L8); i++)
  {
    EVE_memWrite8(FONT_FILE_ADDRESS + i, fontData24_L8[i]);
  }

wobei FONT_FILE_ADDRESS = RAMG+1000 ist und
fontData24_L8[i] => das Array
dann das hier:

   void SetCustomFont(uint32_t fontHandle, uint32_t firstChar)
    {
        EVE_cmd_setfont2_burst(fontHandle, FONT_FILE_ADDRESS, firstChar);
    }

Mit fontHandle = 1 und firstchar = 1

Ich bekomme dann aber nur dort wo ein Zeichen stehen soll ein 
ausgefülltes Kästchen...so als wenn er in dem .raw nix findet...

Wie schon gesagt mit .xFont und .glyph geht das aber die glyph hat ja 
immer 32kByte

Grüße und Danke

[Rudolph R. (rudolph)]

Im Extended Format sind es immer 128 Glyphen oder ein vielfältiges 
davon, das ist im Grunde genommen richtig, bzw. so beabsichtigt.
Als ASTC ist das aber kleiner, da komme ich auf 16kiB.

Ich habe mir mal eben EAB 2.1 installiert um das nachzuvollziehen.
Tendenziell würde ich den ersten Char auf 48 setzen.
Konvertiert hat EAB das im Grunde genommen auch so, es gibt das .png 
dazu.

Nur versuche ich gerade die .raw durch den EVE Screen Editor zu ziehen 
und bekomme da gerade gar nichts außer Pixelmüll angezeigt.

[Spyy (Gast)]

Rudolph R. schrieb:
> Nur versuche ich gerade die .raw durch den EVE Screen Editor zu ziehen
> und bekomme da gerade gar nichts außer Pixelmüll angezeigt.

Genau, anbei mal meine .ttf im Anhang...aber ich habe mal geschaut..ich 
glaube ich brauche ja nur 3 Fontgrössen => 3x32kByte mit extendet ASTC 
und mit Glyph/xfont data=> approx. 100 kByte und man hat ja wohl im RamG 
0x000000-0x0FFFFF=>1024 Ki => das reicht bei mir...habe da nur noch ne 
statische Display List drin...

Generell mal die Frage: Was macht man eigentlich, wenn die Displaylist 
länger als 4096Bytes ist (bei mir jetzt über 5000 Bytes und ich bin noch 
nicht fertig)...aber es geht und wird alles korrekt angezeigt...
Ich glaube ich werde den EVE chip nie durchschauen...

Danke nochmal für Deine Unterstützung, wirklich sehr hilfreich...:)

Grüße

Torsten

[Rudolph R. (rudolph)]

Och, die Display-Liste darf 8kiB haben, der CMD-FIFO hat nur 4kiB.
Das Verhältnis von dem was man in den CMD-FIFO steckt und was in der 
Display-Liste landet ist für viele Befehle allerdings 1:2 oder größer, 
insofern läuft eher die Display-Liste über.

Und wenn es überläuft heißt es optimieren.
Zum Beispiel zwei Bilder verwenden statt einem Button.

[Spyy (Gast)]

Sorry, das ich von einem Thema ins andere "springe" aber der Chip 
"drives me crazy" auch die Beispiele in der EVE Dokumentation sind ja 
eher suboptimal...und teilweise völlig verwirrend.
Ich habe mich an Deine Codebeispiele (Deine Musterapplikation) 
gehalten...leider ist da ja kein Custom font drin aus dem RamG geladen, 
nur aus dem Flash...

[Rudolph (Gast)]

Ich habe die Fonts bis zum BT81x im Grunde genommen nie genutzt,
da das "Legacy" Format ja auf 128 Zeichen begrenzt ist.
Da habe ich mir sowas wie ein "µ" lieber von Hand gestrickt indem ich 
über ein "u" noch versetzt ein "i" ausgegeben habe.

[Spyy (Gast)]

Rudolph schrieb:
> Ich habe die Fonts bis zum BT81x im Grunde genommen nie genutzt

Also ich habe jetzt 2x xfont/glyph ins RAMG geladen, funktioniert 
prima...

Noch mal ne Frage, ich hoffe es nervt nicht...

Für mich sind die Einstellunge VSYNC/HSYNC/HSYNC1/usw, immer noch 
spanische Dörfer, das was ich habe funktioniert aber bin mir nicht 
sicher warum.

1. vom Hersteller habe ich das hier (ist ein st7701s chip)

/***********************************************************************/
/* Panel Name : HSD4.0IPS(HSD040BPN1-A00)                                   
/* Resulation : 480x480                                                       
/* Inversion  : 2dot                                                          
/* Porch      : vbp=15 , vfp=12                                               
/* Line Time  : 32us                                                          
/* Frame Rate : 60hz                                                          
/************************************************************************/

2. Eingestellt (und geht) habe ich das hier:

#define Resolution_480x480
#define EVE_HSIZE  (480L)
#define EVE_VSIZE  (480L)   

#define EVE_VSYNC0  (8L)        
#define EVE_VSYNC1  (8L + 8L)      
#define EVE_VOFFSET  (8 + 8 + 2)      
#define EVE_VCYCLE  (EVE_VSIZE + 8 + 8 + 2 + 2)  
#define EVE_HSYNC0  (8L)        
#define EVE_HSYNC1  (8L + 8L)      
#define EVE_HOFFSET  (8L + 8L + 20L)      
#define EVE_HCYCLE   (EVE_HSIZE + 8 + 8 + 20 + 2)    
#define EVE_PCLK  (1L)
#define EVE_PCLKPOL  (0L)                
#define EVE_SWIZZLE  (0L)                
#define EVE_CSPREAD  (0L)                
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_DITHER  (0L)
#define EVE_GEN 4
#define EVE_HAS_CRYSTAL
//#define EVE_PCLK_FREQ (14500000L)  /* 14.5MHz => 54 Hz value for EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (27000000L)  /* 27MHz => 100 Hz value for EVE_cmd_pclkfreq */
#define EVE_PCLK_FREQ (19000000L)  /* 27MHz => 100 Hz value for EVE_cmd_pclkfreq */

Wie kommt man denn jetzt mit porch vbp=15,vfp=12 und linetime 32µs auf 
die Werte für den BT81x ?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> Wie kommt man denn jetzt mit porch vbp=15,vfp=12 und linetime 32µs auf
> die Werte für den BT81x ?

Ähm, quasi gar nicht.
Auch wenn man die 60Hz dazu nimmt ist das doch nur raten.

Solche Erfahrungen habe ich mit nackten Panels bisher meistens gemacht, 
also nicht praktisch, von den Daten her.
Entweder man findet gleich kein Datenblatt, das Datenblatt ist ein Witz 
und enthält keine Timing-Informationen oder der Hersteller gibt die 
Timing Informationen in seinem eigenen Format an, möglichst 
unvollständig.

Ich habe ein Datenblatt von einem TFT-H040A1PVIST3N40 gefunden.
"Shenzhen Hot Display Technology Co.,Ltd" - ja, genau.
Unter "LCD display initialization code" steht der selbe seltsame Header.
Und ganz viele Daten die man per SPI an den Display-Controller schicken 
soll - Schauder.

Nur richtige Timing Informationen gibt es im dem "Datenblatt" gar nicht.
Der Pixel-Clock darf bis 30MHz haben.

Da hilft nur zu versuchen was ähnliches zu finden, raten und 
ausprobieren.

Vielleicht bringt es was zu entschlüsseln was dem ST7701S da eigentlich 
im Detail alles geschickt wird.

[Alf S. (alfsch)]

+ für die Display Daten:  habe gerade ein Riverdi TFT zum laufen 
gebracht,
RVT70AQBFWR00, EVE3 TFT , 7" , 800 x 480 , res.touch (von rs 193-1167 , 
66€ ).

Einstellung (auch mit Werten von riverdi /git driver ) war nicht 
korrekt, einige wundersame einzelne Pixel im Bild und eine blaue Linie 
rechts am Rand;
 so sieht das Bild fehlerfrei aus:

/* RVT70xQBxxxxx 800x480 7.0" Riverdi, various options, BT815/BT816 */
#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
#define EVE_HSIZE  (800L)  /* Thd Length of visible part of line (in PCLKs) - display width */
#define EVE_VSIZE  (480L)  /* Tvd Number of visible lines (in lines) - display height */

#define EVE_VSYNC0  (4L)  /*  0  Tvf Vertical Front Porch */
#define EVE_VSYNC1  (8L)  /* 13  10 Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
#define EVE_VOFFSET (13L)  /* 23 Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
#define EVE_VCYCLE  (512L)  /* 525 Tv Total number of lines (visible and non-visible) (in lines) */
#define EVE_HSYNC0  (0L)  /* 0 Thf Horizontal Front Porch */
#define EVE_HSYNC1  (4L)  /* 10 Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
#define EVE_HOFFSET (28L)  /*46  Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
#define EVE_HCYCLE (856L) //  (1056L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */
#define EVE_PCLK  (2L)  /* 72MHz / REG_PCLK = PCLK frequency 30 MHz */
#define EVE_PCLKPOL (1L)  /* 1L PCLK polarity (0 = rising edge, 1 = falling edge) */
#define EVE_SWIZZLE (0L)  /* Defines the arrangement of the RGB pins of the FT800 */
#define EVE_CSPREAD  (0L)  // 1L muss definitiv 0 sein !
#define EVE_TOUCH_RZTHRESH (1800L)  /* touch-sensitivity */
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif

[Rudolph (Gast)]

Danke!

Aber bäh, das sieht so aus als ob die das Panel geändert haben.
Spontan würde ich aber sagen, dass Du ein altes Modul erwischt hast, das 
auf RS verlinkte Datenblatt hat noch 928 typisch für eine Zeile.
In den aktualisierten Daten von Riverdi steht allerdings 1056.
Was steht denn auf dem Aufkleber von wann das ist?

Probier das mal aus:

#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
#define Resolution_800x480

#define EVE_PCLK (2L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif

[Spyy (Gast)]

Ah ok, danke...

Du hattest mal irgendwo geschrieben, dass Du Serienwiderstände in den 
SPI lines zum EVE verwendest.
Wonach legt man die denn aus? Ich "fahre" den SPI ja mit 25Mhz...

Ich habe, weil ich das mal in einem Beispiel gesehen habe, in den RGB 
lines zum Display 30 Ohm "reingemacht"...ob das was bringt...keine 
Ahnung.

Grüße und Danke

Torsten

[Rudolph (Gast)]

Spyy schrieb:
> Du hattest mal irgendwo geschrieben, dass Du Serienwiderstände in den
> SPI lines zum EVE verwendest.

Die habe ich mit dem Teensy 4 benötigt, sonst mit bisher keinem 
Controller.
Die 10R die ich da per Default in meinen Adapter-Platinen habe sind noch 
nicht so richtig wirksam bei den Frequenzen, die sind mehr Vorhalt als 
eine konkrete Maßnahme, ebenso die 22pF.

> Wonach legt man die denn aus?

Nach den Treibern, also wie schnell die schalten, den Leitungslängen, 
der Frequenz, etc.
Oder man probiert das aus und erhöht wie ich das mit dem Teensy 4 
gemacht habe einfach mal die Reihenwiderstände, weil vorher nichts 
anderes gegriffen hat und das bei Stückzahl 1 ja nicht perfekt sein 
muss.

Spyy schrieb:
> Ich "fahre" den SPI ja mit 25Mhz...

Da funktioniert mein Touch normalerweise schon nicht mehr.
Ich denke, weil die MOSI Signale durch die ganze Kette und zurück 
schlicht zu stark verzögert werden - denn reines Schreiben geht einiges 
schneller.

Spyy schrieb:
> Ich habe, weil ich das mal in einem Beispiel gesehen habe, in den RGB
> lines zum Display 30 Ohm "reingemacht"...ob das was bringt...keine
> Ahnung.

Die Leitungen schalten gerade bei den größeren Displays noch viel 
schneller.
Die Serien-Widerstände sollen da vor allem die Flanken ein klein wenig 
rund machen, das verringert die Stör-Abstrahlung nach Außen und vor 
allem auch
die gegenseitigen Einstrahlungen bei parallelen Leitungen.
Und es gibt so wohl auch weniger Reflexionen auf den Leitungen.
Es gibt hier im Forum sicher einige die das korrekter erklären können.

An der Stelle kann ich auch nur mit den Schultern zucken und darauf 
hoffen, dass die Empfehlungen vom Hersteller stimmen, 30+MHz parallele 
"Busse" sind eher nicht womit ich mich normalerweise herum schlage. :-)
Und Bridgetek hat zum Beispiel auf dem ME817EV praktisch in allen 
Leitungen 33R Serienwiderstände.

[Alf S. (alfsch)]

>Was steht denn auf dem Aufkleber von wann das ist?
2141 , also vmtl Mitte 2021 hergestellt.

Ich habe in meinem "Testbild" mit den bewegten Dreiecken einen 
Hintergrund mit Farbverlauf , der sieht auf dem Newhaven TFT perfekt 
aus, auf dem Riverdi TFT sieht man ganz leichte Stufen in der Farbe, als 
wäre das RGB zB 3 x 6bit statt 3 x 8bit ; oder gibts da noch was zum 
Einstellen ?
+ wenn man "sehr schräg" aufs TFT guckt, sieht das bewegte Dreieck auf 
dem Riverdi TFT eher "ruckelnd" aus, die Linien scheinen erst kurz 
Schwarz und dann erst Gelb gemalt zu werden und dadurch etwas 
"flimmern", beim Newhaven TFT sieht man davon nichts, einfach bewegte 
gelbe Linien eben. Oder könnte das am Controller liegen, EVE2 -> EVE3 
(im Riverdi TFT)?

+
zu den Widerständen in den Leitungen: die sind zur Vermeidung/Reduktion 
von Reflexionen auf der Leitung; das MUSS sein, sobald die Leitung von 
kräftig schnellen Treibern angesteuert wird. Das ist bei allen "neueren" 
ARM chips so, bei den STM32 sind (im Cube) die Ports in 3 , 4 oder 5 
Stufen in der Geschwindigkeit einstellbar; man sollte immer geringste 
Geschwindigkeit einstellen, die für die benutzte Taktrate ausreicht, um 
möglichst wenig Refexionen zu erzeugen. Ich mache "standardmässig" 51 
Ohm in jede Leitung, zB zur SD-Karte (50 Mbit clock) oder zum TFT (SPI 
mit 25 Mbit).
ZB mit max.port speed , ohne Widerstände drin, bekommt man gar keine 
Verbindung zu einer SD-karte, so, als wäre sie kaputt !
Die Impedanz einer "einsamen" Leitung auf PCB über Massefläche liegt so 
bei 50 Ohm, in einem Flachkabel dann her bei 120 ohm, also sollten die R 
in der Leitung irgendwo zwischen 33 Ohm (bei USB üblich) und 150 Ohm (in 
CD playern typisch) liegen; 50 ...100 sind ein guter Bereich.

[Alf S. (alfsch)]

zum Anschauen kurz simuliert:  20MHz , 3V Rechteck , auf ---->
10cm freie Leitung (hat etwa 100nH Induktivität), Ende an chip-pin (mit 
5pF Streukapazität, angenommen);

(1. bild 2x , man kann es anscheinend nicht löschen...)
1. schneller port, 1ns rise/fall , dünnes Kabel (1 Ohm angenommen)
2. schneller port, 0.5ns , mit 100 Ohm in der Leitung
3. etwas "gebremster" port, 5ns , 1 Ohm


da kann man gleich sehen, warum ein Widerstand rein muss,
wenn die Leitung von schnellem chip angetrieben wird. :)

[Rudolph (Gast)]

Alf S. schrieb:
>>Was steht denn auf dem Aufkleber von wann das ist?
> 2141 , also vmtl Mitte 2021 hergestellt.

Ok, das finde ich seltsam, Mitte 2020 hätte noch irgendwie Sinn ergeben.

Was passiert denn mit dem Setup das ich oben mit den Default-Werten 
gepostet habe?


Und Reflexionen, dann hatte ich wenigstens schon das richtige Stichwort. 
:-)
Als echtes Problem war mir bisher nur begegnet das die ATSAMC bei 3,3V 
nicht genug Strom liefern konnten um den SPI zu treiben, also so nach 
extern über das FFC und jenseits von 8MHz.
Auf die Idee zu schauen ob man bei dem Teensy 4 die Pins auf langsamer 
einstellen kann bin ich nicht gekommen, unter 240R habe ich auch nicht 
mehr ausprobiert. Kann also sein das es in Software lösbar wäre oder mit 
51R.


Und Tipp, es gibt einen neuen EAB:
https://brtchip.com/ic-module/wp-content/uploads/sites/3/2022/01/EVE-Asset-Builder-setup-2.5.0_3.0.0.zip

[Alf S. (alfsch)]

>Was passiert denn mit dem Setup das ich oben mit den Default-Werten
gepostet habe?
noch nix, kann ich erst nächste Woche mal testen.

>die Idee zu schauen ob man bei dem Teensy 4 die Pins auf langsamer einstellen 
kann

jepp, is doch auch so ein schneller ARM, siehe Bildchen.... :)
ist im DB sogar extra mit Bild , 2. Bild.

[Rudolph (Gast)]

Alf S. schrieb:
>>die Idee zu schauen ob man bei dem Teensy 4 die Pins auf langsamer einstellen
> kann
>
> jepp, is doch auch so ein schneller ARM, siehe Bildchen.... :)
> ist im DB sogar extra mit Bild , 2. Bild.

Ich hatte im DB nachgesehen und per Software gelesen was da über den 
Arduino Core eingestellt wird: 111
Also mit 011 oder 0100 hätte das direkt funktionieren können, 
interessant.

[Spyy (Gast)]

Super, Danke für den Hinweis...zum neuen EAB...

Noch ne Frage...warum kann man eigentlich "burst" und z.B. mem_read 
(z.B. ins G Ram schreiben/lesen) nicht mischen ?

Ich dachte wenn man burst startet und dann eine DL aufbaut macht man ja 
erst nur den SPI Buffer voll und erst bei "Burt end" wird das alles per 
SPI DMA aus dem Buffer weggeschickt...

Grüßeund Danke

[Spyy (Gast)]

Alf S. schrieb:
> zu den Widerständen in den Leitungen: die sind zur Vermeidung/Reduktion
> von Reflexionen auf der Leitung; das MUSS sein, sobald die Leitung von
> kräftig schnellen Treibern angesteuert wird. Das ist bei allen "neueren"
> ARM chips so, bei den STM32 sind (im Cube) die Ports in 3 , 4 oder 5
> Stufen in der Geschwindigkeit einstellbar; man sollte immer geringste
> Geschwindigkeit einstellen, die für die benutzte Taktrate ausreicht, um
> möglichst wenig Refexionen zu erzeugen. Ich mache "standardmässig" 51
> Ohm in jede Leitung, zB zur SD-Karte (50 Mbit clock) oder zum TFT (SPI
> mit 25 Mbit).
> ZB mit max.port speed , ohne Widerstände drin, bekommt man gar keine
> Verbindung zu einer SD-karte, so, als wäre sie kaputt !
> Die Impedanz einer "einsamen" Leitung auf PCB über Massefläche liegt so
> bei 50 Ohm, in einem Flachkabel dann her bei 120 ohm, also sollten die R
> in der Leitung irgendwo zwischen 33 Ohm (bei USB üblich) und 150 Ohm (in
> CD playern typisch) liegen; 50 ...100 sind ein guter Bereich.

Hallo Alf,

danke für die Info...tja...was mache ich nun...ich habe ein PCB ohne R 
in den SPI Leitungen und eigentlich kein Problem (mehr)...und ich habe 
kein so tolles Oszi...und wüsste auch gar nicht so genau wie die Signale 
bei 25 Mhz so aussehen müssten...
Die Leitungen vom Teensy zum EVE sind ca.3-4 cm lang....

[Rudolph R. (rudolph)]

Spyy schrieb:
> Noch ne Frage...warum kann man eigentlich "burst" und z.B. mem_read
> (z.B. ins G Ram schreiben/lesen) nicht mischen ?

Da musste ich erstmal drüber nachdenken.
Bei den Targets die DMA unterstützen sollte das sogar eigentlich 
funktionieren.
Nur auf die Idee gekommen bin ich noch nicht.

> Ich dachte wenn man burst startet und dann eine DL aufbaut macht man ja
> erst nur den SPI Buffer voll und erst bei "Burt end" wird das alles per
> SPI DMA aus dem Buffer weggeschickt...

Richtig, und Funktionen wie EVE_memRead8() sind in sich abgeschlossen 
und kümmern sich auch nicht darum ob nun gerade Burst ist oder nicht.

Man muss nur aufpassen das man nicht direkt nach dem EVE_end_cmd_burst() 
wieder was über den SPI schickt, so ohne EVE_busy().

Was anderes ist es wenn man ein Target ohne DMA Support hat, dann kann 
man zwar auch EVE_start_cmd_burst() / EVE_end_cmd_burst() benutzen, das 
bewirkt aber was ganz anderes, damit wird der SPI-Transfer direkt 
gestartet und jedes Kommando schickt nur die Nutz-Daten ohne Adresse 
vorweg.
Ein Arduino UNO hat ja zum Beispiel schon mal gar nicht die 4k SRAM die 
für den Puffer benötigt werden.

Spyy schrieb:
> danke für die Info...tja...was mache ich nun...ich habe ein PCB ohne R
> in den SPI Leitungen und eigentlich kein Problem (mehr)...und ich habe
> kein so tolles Oszi...und wüsste auch gar nicht so genau wie die Signale
> bei 25 Mhz so aussehen müssten...
> Die Leitungen vom Teensy zum EVE sind ca.3-4 cm lang....

Nun ja, erstmal ist das ein ganz anderes Problem, ich gehe ja von den 
ganzen Eval-Boards mit fliegenden Leitungen weg auf meine 
Adapter-Platine und dann hängt da noch das FFC zum Display dran.

Und dann könnstet Du einfach auf Verdacht die Geschwindigkeit der SCK 
und MOSI Pins von der Default-Einstellung 7 auf was kleineres ändern, 
der kleinste Wert eben der noch ohne Probleme funktioniert.

Und manchmal ist es auch gut den Stuss zu lesen den man selber 
geschrieben hat. :-)
Als ich mich hierhin durchgeklickt habe bin ich ganz oben auf der Seite 
gelandet und habe gesehen was ich im Juni letzten Jahres geschrieben 
hatte.
Ich schrieb da oben, dass ich von 240R auf 150R runter gegangen bin und 
dann 26MHz SPI mitsamt Touch benutzen konnte.
Ich schrieb auch, dass ich die Pin-Einstellung selber geändert habe, so 
ohne Effekt, aber ich schrieb nicht wie weit ich mit der Einstellung 
runter gegangen bin. Jetzt würde ich einen Wert von 3 oder 4 für 
plausibel halten, so ohne extra Widerstände.

[Alf S. (alfsch)]

>dass ich von 240R auf 150R runter gegangen bin und
> dann 26MHz SPI mitsamt Touch benutzen konnte
mit 150 R haste ja dann schon einen guten Wert gefunden :)

>ich habe ein PCB ohne R in den SPI Leitungen
>Leitungen vom Teensy zum EVE sind ca.3-4 cm lang

da solltest du einfach die drive/speed auf einen kleinen Wert 
einstellen, dann sollte das zuverlässig laufen; ich würde beim kleinsten 
anfangen, 001, und sehen, ob es mit vollem Takt geht; wenn nicht, eben 
010 versuchen.
anbei simu: kurze Leitung 25MHz mit 2mA drive - würde gut aussehen.

btw ein Beispiel: ich hatte mal ein Problem mit der Zuverlässigkeit 
eines FPGA, clock 80MHz ; der Entwickler hatte "vorsichtshalber" den 
Oszillator direkt neben das FPGA gesetzt, ca. 20mm Leitung, da denkt man 
schon, das ist perfekt so. Etwa 50% der Boards liefen, die anderen 
hatten diverse "Fehler", manche gingen bei Erwärmung nicht mehr, manche 
gar nicht. Da sucht man alles Mögliche als Grund...
bis ich versuchsweise die 20mm Bahn mit Cutter aufgetrennt und nen 100 R 
0805 SMD draufgelötet habe; dann liefen auch die "defekten" FPGA alle 
problemlos.
(speed Einstellung ändern gabs hier natürlich nicht).

[Spyy (Gast)]

Okay....also mit drive strenght 0b001 geht das sofort (keine Ahnung, ob 
da überhaupt was passiert ist) aber fein....:) freu....

[Spyy (Gast)]

...aber man weiss ja...wenn es sofort geht liegt der Fehler tiefer...das 
ist verdächtig....

[Alf S. (alfsch)]

...oder auch - ganz selten - einfach richtig.  :)

>>Probier das mal aus:

#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
#define Resolution_800x480
#define EVE_PCLK (2L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif


habe es versucht. Bild sieht (genauso) ok aus.
nur: compiler motzt ->
musste in EVE_commands das vorerst einfach raus kommentieren: Zeile 1313
//  EVE_memWrite16(REG_TOUCH_RZTHRESH, EVE_TOUCH_RZTHRESH);  /* 
eliminate any false touches */   geht nicht ! undeclared !

touch (resistiv) geht aber gut (wie vorher).

[Rudolph R. (rudolph)]

Alf S. schrieb:
> habe es versucht. Bild sieht (genauso) ok aus.

Super, danke, dann muss ich mir da mal was zu überlegen.

Alf S. schrieb:
> nur: compiler motzt ->
> musste in EVE_commands das vorerst einfach raus kommentieren: Zeile 1313

Dann hast Du noch eine alte Version, das habe ich Ende Dezember 
umgebaut. :-)

Der Hintergrund ist das die Einstellung für kapazitiv-Touch Displays gar 
nicht benötigt wird, stand aber in allen Profilen.
Wenn es nicht definiert ist wird jetzt 1200 geschrieben.
Ist es definiert weil 1200 für manche resistiv-Panels noch zu niedrig 
ist, aber eben über die Projekt-Einstellungen, z.B. in der 
platformio.ini, dann wird es auch wie gewohnt geschrieben.
Damit kann man das individuell anpassen ohne die EVE_config.h verändern 
zu müssen.

[Alf S. (alfsch)]

nu, bzgl "wieso Reflexionen" bei den aktuellen CPUs auf den Leitungen:
hier mit Magnetfeld-sonde direkt am Flachkabel zum Riverdi TFT gemessen, 
mit 51R in allen aktiven Leitungen und reduzierter pin-drive Einstellung 
:(medium/low)
immerhin noch ganz ordentlich Oberwellen bis 2 GHz !

genau selbe Einstellung der STM32H7A3 CPU , aber mit dem TFT von 
Newhaven, mit ca. 35cm Flachbandkabel dran. ca. 20dB weniger Oberwellen, 
also :
vermutlich sind auf dem TFT von Riverdi keine Dämpfungswiderstände in 
der SPI Leitung vom EVE chip; daher hat das heftige Abstrahlung, obwohl 
von der H7A3 CPU her das Signal eigentlich gedämpft ist. (wie man beim 
Newhaven TFT trotz des längeren Kabels ja gut sehen kann).


(btw die Uhrzeit vom Analyzer ist schon 6 Stunden vorne...warum auch 
immer)

[Spyy (Gast)]

Ok...also drive strenght runter UND 51R in die SPI Leitungen?

Alle SPI Leitungen, also auch CS?

Ach wenn man doch Ahnung von dem hätte was man so macht...;-)

[Alf S. (alfsch)]

>also drive strenght runter UND 51R in die SPI Leitungen?
ja + CS auch ; (einfach...aus Prinzip.)
vmtl. sind auf dem TFT von Riverdi keine R in den Leitungen (der EVE 
"sendet" ja auch , MOSI -> MISO ) und es sollte daher auch mit Rs nahe 
am EVE chip gedämpft werden.
Riverdi bewirbt auf ihrer Seite ja die neuen EVE4 Displays, auch mit EMI 
Messung dabei; bei den älteren EVE3 sehe ich davon nix (nur: Not 
recommended for new design.)
anscheinend ist ihnen auch aufgefallen, dass die TFTs so einiges an HF 
abstrahlen auf der SPI Leitung.

[Spyy (Gast)]

>ja + CS auch ; (einfach...aus Prinzip.)
Okay....will do....so

Sagt mal, weiss jemand ob es dann man einen EVE5 geben wird ?

[Rudolph R. (rudolph)]

Spyy schrieb:
> Ach wenn man doch Ahnung von dem hätte was man so macht...;-)

Ich ahne was, aber ich habe nicht mal ansatzweise die Messtechnik um 
sowas aufzuspüren oder hätte die Erfahrung mit der Art von Messtechnik 
richtig umzugehen. :-)

Spyy schrieb:
> Sagt mal, weiss jemand ob es dann man einen EVE5 geben wird ?

Solange nichts angekündigt ist kann ich da nur hoffen.
Leider wird der Druck auf so ein Produkt immer größer, etwa durch 
Mikrocontroller mit eingebautem Grafik-Interface.
Riverdi hat ja auch gerade ein 10.1" mit einem STM32H747XIH6 
vorgestellt.
Bei den Preisen legt Riverdi allerdings im Vergleich zu den EVE4 Modulen 
noch mal eine ordentliche Schippe drauf.
Für einen BT82x würden mir schon noch ein paar Dinge einfallen. :-)

[Spyy (Gast)]

Rudolph R. schrieb:
> Mikrocontroller mit eingebautem Grafik-Interface.
> Riverdi hat ja auch gerade ein 10.1" mit einem STM32H747XIH6
> vorgestellt.

Nicht schlecht...aber out of stock....die Frage ist natürlich, ob man da 
auch so schön entwickeln kann, so wie Teensy a la Arduino style...oder 
ob man sich dann da durch alle Tiefen des Microcontroller fräsen 
muss...und ob es dafür dann auch so eine tolle Library wie Deine 
gibt...und wie leistungsfähig das dann ist...

[Rudolph R. (rudolph)]

Nun, die H7 gehen glaube ich bei 280 MHz los und der RT1062 von dem 
Teensy hat auch eine Grafik-Einheit.
Sowas Mikrocontroller zu nennen ist ja irgendwie pervers. :-)
In der Kategorie setzt man dann aber auch ein Betriebssystem ein, hat 
Dutzende wenn nicht Hunderte Leute in dem Projekt und ein guter Teil der 
Zeit geht für Prozesse drauf.

Ich meine ja nur, als FTDI 2013 mit den FT800 an den Start gegangen ist, 
da sah die Controller-Landschaft noch anders aus.

Ich kenne auch immer noch keine Produkte die mit einem FT8xx oder BT8xx 
im Laden stehen würden, also zumindest keine bei denen man 5 oder 6 
stellige Mengen erwarten kann. Ich kenne nicht mal welche die ich nicht 
nennen dürfte.
Eigentlich muss es die geben, sonst würde sich das ganze Spiel wohl eher 
nicht lohnen, aber mir sind keine bekannt.
Ich weiß auch gar nicht so recht, was ich überhaupt von Bridgetek als 
Firma halten soll, mein persönlicher Eindruck ist ja, dass der Laden 
eher klein ist.
Dagegen sprechen aber zum Beispiel die ganzen Stellenausschreibungen.
Man versucht ja nicht 19 hauptsächlich Senior Stellen zu besetzen, wenn 
man nichts zu tun hat.
Aber nun, Singapur, ich glaube da würde ich mich richtig fremd fühlen. 
:-)

Also ich drücke die Daumen, dafür habe ich immer noch zu viel Spaß mit 
EVE. :-)

[Alf S. (alfsch)]

>Ich kenne auch immer noch keine Produkte die mit einem FT8xx oder BT8xx

Ich vermute, die sind auch (wenn überhaupt) eher in ..siehe Bilder.

und bisher wohl einfach wenig bekannt und "zu ungewohnt" für die 
Entwickler;
ich bin in der Firma auch der einzige, der ein neues Display dieser 
"unbekannten Art" machen will.
und auf dem STM Forum, gehen die meisten lieber den Weg, den LCD 
controller im Chip mit externem RAM aufzupeppen und dann mit zig 
Leitungen ein RGB-LCD anzudengeln, statt sich mal mit dem EVE Zeugs zu 
beschäftigen.

btw ich bin quasi (auch) Erfinder des EVE (eine meiner sinnlosen, 
unbekannten Erfindungen...) : vor ca. 23 Jahren hatte ich zu Zeiten mit 
den AVR rumgemacht und überlegt, wie man damit ein Farb-LCD ansteuern 
könnte, ohne 1MB RAM buffer zu haben; da kam mir die Idee: der Rechner 
hat nur ein paar Dinge darzustellen, Linien und paar Buchstaben, die er 
live Zeile für Zeile berechnet und zum LCD shiftet. Kein Monster RAM 
buffer mehr nötig. Leider natürlich auch (zu der Zeit) von den 
verfügbaren CPUs her völlig unmöglich, 10x zu langsam.
gut, dass ich es nicht patentiert habe, hätte nur 10 Jahre Gebühren 
bezahlt und kein Schwein hätte es haben wollen. :)

[Rudolph R. (rudolph)]

Da habe ich einen Moment Schnapp-Atmung bekommen. :-)
Ja, ich kann auch nur für FTDI/BRT hoffen, dass die EVE in solchen 
Produkten verbaut werden.
Bridgetek hat ja auch entsprechende Bilder auf der Homepage.
Nur natürlich und leider werden die nicht ihre Kunden nennen.
Dicke Kaffee-Automaten und andere Luxus Küchengeräte auf Verdacht zum 
Zerlegen zu kaufen ist auch nicht durchführbar. :-)

Wobei Automotive eher nicht so, zumindest nicht für ein Infotainment 
Panel.
Die EVE sind nicht Automotive qualifiziert.
Wobei es sicher auch Hersteller gibt die sich davon nicht abhalten 
lassen.
Immerhin hatte BRT in der Richtung auch schon Demos.

Das kanadische ATV von Theron fand ich spannend.
Aber xxxx Stück werden die davon ja eher auch nicht bauen.

Geil wäre ja mal sowas wie eine Wetterstation zu identifizieren die 
einen FT800 drin hat und inzwischen über Pearl oder Pollin verramscht 
wird.


AVR und Displays und so, ich erinnern mich da war mal was mit einem 
übertaktetem M644 oder so.
Aber das muss dann ja schon später gewesen sein.

[Alf S. (alfsch)]

ich habe mal geguckt, was es an anderen TFT controller Zeug so gibt: hm, 
die Konkurrenz schläft nicht...
gefunden:
RA8875   https://www.buydisplay.com/download/ic/RA8875.pdf
LT7683   http://www.levetop.tw/en/product1_7680.html
SSD1963   Built-in 128Mbit Display Memory !!
https://www.crystalfontz.com/controllers/SolomonSystech/SSD1963/

alle haben RAM drin und können auch komplexe Befehle, wie Kreise, Text, 
Flächen usw.  und sind wohl die direkte Konkurrenz zum EVE.

so Display damit:

https://www.buydisplay.com/serial-spi-arduino-7-inch-tft-lcd-touch-shield-ra8875-for-mega-due-uno

https://www.ebay.de/itm/143653876018

https://www.ebay.de/itm/304289715592

+ 7" res. touch mit SPI Interface für 53€ - ist schon ne Ansage.

[Rudolph R. (rudolph)]

Den LT768x kannte ich noch gar nicht.
Und so günstig können die Dinger gar nicht sein, dass ich sowas statt 
einem BT81x verwenden würde. :-)

Die haben ja auch eine Arduino Library und Demo Code.
Wenn ich mir da ansehe was die an Code haben um ein Rechteck zu 
zeichnen, das finde ich schon etwas gruselig im Vergleich.
Wenn ich das richtig sehe machen die alles mit 16 Bit Sequenzen.
Immer schön Command und Daten.

Das hier ist mir gerade unter gekommen:

void LT768LCD::SPI_DataWrite_Pixel(int data)
{
  LT768_LCD.SPISetCs(0);    //SS_RESET;
  LT768_LCD.SPIRwByte(0x80);
  LT768_LCD.SPIRwByte(data);
  LT768_LCD.SPISetCs(1);    //SS_SET;

  LT768_LCD.SPISetCs(0);    //SS_RESET;
  LT768_LCD.SPIRwByte(0x80);
  LT768_LCD.SPIRwByte(data>>8);
  LT768_LCD.SPISetCs(1);    //SS_SET;
}

Äh, nee, lieber nicht. :-)

Die 16MB RAM sind nett, die scheinen aber nicht so richtig allgemein 
benutzbar zu sein und müssen erst noch initialisiert werden.

[Spyy (Gast)]

Ich habe mir mal den Portenta H7 mit dem STM32H747 bestellt. Der kann 
wohl auch das RGB Interface (hat ja mein Display) und MIPI DSI (soll ja 
meins auch haben, bleibt aber immer dunkel mit meinem Raspi CM4 Modul 
und Linux Treiber Versuchen) "exponieren" und hat auch HDMI...und der 
hat so eine Art "Grafikbeschleuniger" aber nur sehr rudimentär... mal 
sehen...muss man dann quasi ne Grafikkarte draus machen mit Framebuffer, 
würde bei meiner Auflösung (480/480) mit double Buffering sogar in das 
lokale RAM passen. Dann kann man den einen Core für die Grafik benutzen 
und den anderen für den Rest...so stelle ich mir das jedenfalls vor.
Hat aber sonst alle Schnittstellen, die man sich wünschen kann (CAN, 
IP,...)
Mal sehen...
Ich finde den EVE ja eigentlich gut stehe jetzt aber vor dem "Problem" 
das ich in meiner Anwendung Skalen habe (Speed Tape/Alt Tape), die sich 
auf/ab bewegen. Die Striche bewegen sich schön mit 1/16 pixel Auflösung 
(sehr cool) aber die Zahlen "nur" mit 1/1 pixel Auflösung. Das sieht man 
natürlich sofort...
Ich versuche das jetzt mit eigenen Font aus Linien (Vector Font) zu 
lösen aber irgendwann läuft mir ja die Displayliste über. bzw. DMA 
"macht ja nur" 4096 Bytes. Ich habe dann mal die Lösung von "Obones" aus 
dem BRT Forum versucht (in das RAM_G statische Listen und dann mit 
direkten Manipulationen im Speicher die Koordinaten ändern). Das geht 
aber nur für ein Glyph vom Font, kann man offensichtlich nicht 
instanzieren/kopieren...wird wohl nicht in die  Displaylist kopiert, 
sondern nur referenziert...

[Spyy (Gast)]

...und das andere Problem was ich habe, dass ich offensichtlich ein 
synchronisations Problem habe...was zu sichtbaren "Rucklern" führt, wenn 
viel Dynamik auf dem Display ist.
Das kann ich minimieren (Ausrechnen von Framerate/Aktualisierungsrate 
mit Messung beim Starten des Display) aber bekomme ich nicht ganz weg 
was für meine Anwendung etwas frustrierend ist. Auch das Auslesen "New 
Frame" Register macht das eher noch schlimmer...

[Rudolph R. (rudolph)]

Äh, hast Du mal 1-2 Bilder zu dem Problem?
Also was Du vor hast, und wenn es in Paint ist. :-)

[Spyy (Gast)]

Kann man nur auf einem Video sehen...geht das hier ?

[Spyy (Gast)]

Anbei, als Bilder...

[Spyy (Gast)]

Da bewegt sich sehr viel, hängt dann auch von der Geschwindigkeit ab mit 
der dann "gescrolled" wird...wenn es relativ schnell scrolled sieht man 
es fast nicht, wenn es ganz schnell ist kommt natürlich die 
Wiederholrate ins Spiel und wenn es ganz langsam ist sieht man das am 
"besten". Hätte ich auch nicht gedacht, dass das bei 480x480 zusehen 
ist, aber dadurch, dass die Striche mit 1/16 laufen und die Zahlen mit 
1/1 sieht man das, da scheint das Auge sehr empfindlich zu 
sein...(jedenfalls meins ;-)

[Rudolph R. (rudolph)]

Aber dann beweg die Zahlen doch mit 1/16 Pixel Auflösung?

Für den ESE:
CLEAR(1, 1, 1)
BITMAP_HANDLE(30)
BEGIN(BITMAPS)
CELL(50)
VERTEX_FORMAT(4)
VERTEX2F(4000, 4001)
VERTEX2F(4250, 4002)
VERTEX2F(4500, 4003)

Die Zeichen sind doch auch nur Bilder.
Klar, Zeichenketten von Hand zusammen zu bauen ist so lästig,
aber einzelne Zeichen kann man schon mit VERTEX2F platzieren.

[Spyy (Gast)]

Hm...das habe ich probiert...habe ne Linie zusammen mit der Zahl so 
positioniert...die Zahl (Bitmap) ging immer nur mit einer Präzession von 
1/1 Pixel...kann ich ja nochmal probieren...vielleicht liegt es hier 
dran: VERTEX_FORMAT(4)...

[Spyy (Gast)]

Es schien bei mir so, ja ich kann 1/16 positionieren aber auf dem 
Display bewegte sich das ganze dann doch mit 1/1 Pixel. Ich habe das mit 
einer horizontalen Linie und einer Zahl probiert, die ich dann von oben 
nach unten "gescrolled" habe...

[Spyy (Gast)]

Rudolph R. schrieb:
> Aber dann beweg die Zahlen doch mit 1/16 Pixel Auflösung?
>
> Für den ESE:
> CLEAR(1, 1, 1)
> BITMAP_HANDLE(30)
> BEGIN(BITMAPS)
> CELL(50)
> VERTEX_FORMAT(4)
> VERTEX2F(4000, 4001)
> VERTEX2F(4250, 4002)
> VERTEX2F(4500, 4003)

Also ich habe das mal so gemacht....und ist wie ich das schon kenne. Die 
Linie bewegt sich mit 1/16 und "das Bild" (die Zahl) mit 1/1 auch mit 
VERTEX_FORMAT(4).
Ich kann zwar die Koordinaten (alles *16) verwenden aber die Zahl 
"springt in 16er Schritten"...:(

[Daniel S. (snipod)]

Spyy schrieb:
> Ich kann zwar die Koordinaten (alles *16) verwenden aber die Zahl
> "springt in 16er Schritten"...:(

Da die Fonts am Ende auch Bitmap basiert sind und diese nur Pixelgenau 
sind, denke ich geht unter Pixelgenau nix. Auch die ROM-Fonts sind nicht 
Vektorbasiert...

Ich habe noch ein anderes interessantes Problem; ich kann tun was ich 
will, bei einer langen Display-List fäng bei mir das Bild an zu 
glitchen, sprich ich bekomme Artefakte und Ghosting von meinen Bilder 
beispielsweise. Die magische Grenze scheinen 600 Kommandos in etwa zu 
sein anbei mal ein Bild von meinem Problem (ohne Wurstfinger 560er DL, 
mit Wurstfinger 650er DL)... Weiß jemand Rat?

[Rudolph R. (rudolph)]

Daniel S. schrieb:
> Da die Fonts am Ende auch Bitmap basiert sind und diese nur Pixelgenau
> sind, denke ich geht unter Pixelgenau nix. Auch die ROM-Fonts sind nicht
> Vektorbasiert...

Das kann natürlich sein das Bilder davon ausgenommen sind, nur wäre dann 
erst recht die Frage, warum man die per Default auf 1/16 Pixel 
platzieren kann.

Ich habe gerade noch mal den Programming Guide durchsucht und keinen 
Hinweis gefunden, dass das bei Bildern nicht funktionieren soll.
Aber auch nicht wirklich anders herum, auch wenn da "pixel precision" 
steht.
Interessant fand ich aber noch das hier:
"5.98 CMD_ANIMFRAMERAM
Note: If the pixel precision is not set to 1/16 in current graphics 
context, a VERTEX_FOMART(4) is mandatory to precede this command."

Äh, ok? Warum??

Daniel S. schrieb:
> Ich habe noch ein anderes interessantes Problem; ich kann tun was ich
> will, bei einer langen Display-List fäng bei mir das Bild an zu
> glitchen, sprich ich bekomme Artefakte und Ghosting von meinen Bilder
> beispielsweise. Die magische Grenze scheinen 600 Kommandos in etwa zu
> sein anbei mal ein Bild von meinem Problem (ohne Wurstfinger 560er DL,
> mit Wurstfinger 650er DL)... Weiß jemand Rat?

Also das kann ich jetzt nicht bestätigen, aber reize das in der Regel 
auch nicht aus.
Bandbreitenprobleme mit dem externen Flash kann ich bestätigen, so etwa 
mit großen Fonts aus dem Flash ohne Cache oder dicke Bilder.

Die Anzahl der Kommandos könnte ich auch gerade gar nicht nennen, vor 
allem nicht in der Display-Liste, da ich ja über den Co-Prozessor gehe.
Wie viel von den 8k Display-Liste hast Du denn konkret belegt?
Wie viel schickst Du über den SPI bei einem Update und wie lange dauert 
das, ist da genug Zeit vor dem nächsten Update?

Ich schicke in meinem aktuellen Projekt gerade 1416 Bytes per Update, 
daraus werden zusammen mit dem per CMD_APPEND dazu gepackten Teil dann 
2712 Bytes Display-Liste.
So, reichlich Text (interne Fonts), 9 Bilder, 1 Slider, drölf 
Farb-Kommandos.
Ich bohre das gleich mal auf indem ich einen der Blöcke kopiere, 8 der 
Bilder werden auch noch gedreht, so individuell, das sind jeweils ein 
paar Kommandos.
Ach ja, BT815 und die Bilder liegen im RAM.

[Rudolph R. (rudolph)]

So, ich habe mal mein Projekt massiv mit Stuss überladen, kein Problem. 
:-)

Die Display-Liste ist mit 8016 Bytes gefüllt, über den SPI gehen per 
Update 3888 Bytes.

Der "Killer" für Display-Listen sind Buttons, einer in 3D hat mal eben 
54 Kommandos, also in der Display-Liste selber, das kann man im EVE 
Screen Editor sehen.
Das kann sogar wirklich sein das jedes 32 Bit Wort in der Display-Liste 
ein Kommando ist, danach lasse ich gerade 2004 Kommandos laufen.
Alleine die Buttons sind ja schon 864.
Die Blöcke für die 48 Bilder haben jeweils 6 einfache Kommandos und 1 
komplexeres Co-Prozessor Kommando, sagen wir halt 7 einfache, das wären 
auch noch mal 336.

Das läuft hier die ganze Zeit fröhlich vor sich hin und die Elemente bei 
denen ich den Touch auswerte tun auch weiter was sie sollen.

Ach ja, wenn ich zu viel mache bleibt das Display schwarz.
In einer vierten Textzeile oben reicht es nicht mehr für " lazy dog".
Wenn ich jetzt den Slider auf 5-stellige Drehzahl stelle komme ich auf 
8188 Bytes in der Display-Liste und 3936 Bytes per Update.

Das Teil ist übrigens ein nebenbei Tool um per LIN angesteuerte Lüfter 
auszuprobieren, also schwer Automotive. :-)

[Daniel S. (snipod)]

Ich habe auch einige Grafiken drin, ein paar Fonts (alles im RAM_G) dazu 
arbeite ich viel mit dem Scissor Rectangle, zeichnen von Konturen mit 
dem Stencil und dem anschließenden Füllen per Gradient. Arbeite 
dahingehend also schon auch mit dem Co-Prozessor...

Es macht keinen Unterschied, ob ich das Bild alle 20 oder 200ms 
refreshe. Auch kann ich anstatt alles per burst zu machen, alles polling 
machen, das macht aber - außer dass es langsamer wird - keinen 
Unterschied.

Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten 
auf EVE_busy), per polling circa 20ms.

Edit:
Sorry und ich meinte die Anzahl an Kommandos, nicht die Größe der DL

[Rudolph R. (rudolph)]

Daniel S. schrieb:
> Es macht keinen Unterschied, ob ich das Bild alle 20 oder 200ms
> refreshe.

Also das ist schon mal gut.

> Auch kann ich anstatt alles per burst zu machen, alles polling
> machen, das macht aber - außer dass es langsamer wird - keinen
> Unterschied.
>
> Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten
> auf EVE_busy), per polling circa 20ms.

Was meinst Du jetzt mit Polling?
Jedes Kommando einzeln Plus ein busy()?
Solange man nicht versucht mehr als 4k auf einmal in den FIFO zu 
schieben und dazu auch noch bei sehr schnellem SPI, schafft man es nicht 
den FIFO überlaufen zu lassen mit einzeln geschickten Kommandos.
Der Unterschied zwischen Burst und einfach so sind nur die 3 Bytes 
Adresse die pro Kommando gespart werden, das ist messbar in xx%, aber 
nicht Faktor 4+. :-)

Was für einen Controller hast Du eigentlich und wie schnell ist der SPI, 
das scheint relativ langsam zu sein.


> Edit:
> Sorry und ich meinte die Anzahl an Kommandos, nicht die Größe der DL

Aber wie kommst Du auf die Anzahl der Kommandos?
Was genau meinst Du damit?
In der Display-Liste hat jedes Kommando 32 Bit, da war ich vorhin kurz 
verwirrt weil ich nie mit der Display-Liste direkt arbeite, aber es gibt 
wirklich keine Kommandos die länger sind.
Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten, 
da müsste man schon die Befehle im Quelltext zählen weil die keine 
einheitliche Größe haben.

Wie groß wird denn die Display-Liste?

[Spyy (Gast)]

Daniel S. schrieb:
> Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten
> auf EVE_busy), per polling circa 20ms.

Wann (vor welchem Befehl) wartest Du mit Eve_busy ? end_burst?
Ist das nur wenn Du touch auf dem Screen machst? Sind die Glitches nur 
auf einem Foto zu sehen, wieviel Hz Widerholrate/Kontentupdate hast Du 
denn? Ich benutze auch Scissor...das geht zuverlässig...

Also meine Erfahrungen sind jetzt, alles mit Teensy 4.1 und DMA burst:
- Ich "fahre" das Display mit 81 Hz, update den Kontent mit 81 Hz => 
geht gut, updateraten der gesamten Liste (zwei Bursts mit eve_busy vor 
dem 2. Burst) ca. 1.0x-1.3x ms. Dann Pause von 12.x ms (81 Hz). Ich 
lasse mir den fifo (gesamt und head/tail ausgeben und die Differenz ist 
immer 0). Ein Wehrmutstropfen ist ein, mitlerweile seltenes, Ruckeln 
(sieht aus als wenn die Applikation steht für ne ms oder so).
- Ich habe mit meinem neuen Layout 51 Ohm in den SPI lines und "fahre" 
den erst mit 4 Mhz zum Init, dann mit 25 Mhz und signal strenght auf der 
niedrigsten Stufe=>geht, ob der electrical noise level jetzt besser 
ist...keine Ahnung..
- Ich habe jetzt nen 12 Mhz Quarz auf dem Board mit 2x 18pF Cs=>geht. 
Ich weiss jetzt auch warum das mit meinen alten Boards nicht ging, die 
Library für den Quarz für Eagle/Fusion360 ist vom Pinning falsch...ganz 
toll!
Ich habe jetzt 72003281 Hz als internen Takt, wie es sein soll. Mit 
externer Taktquelle mit 12 Mhz PWM 50% duty nur 69xxxxxx Hz=>so nicht 
machen, ist Mist
- Ich habe jetzt eigene Vectorfonts gemacht, mit Linien, Linestrip, 
Punkten usw. damit "schwillt" natürlich der Fifo an=>musste ich in zwei 
Bursts aufteilen sonst wird die Fifo Liste zu lang (über 4096), Teensy 
"stalled" dann oder es gibt Artefakte.
Damit kann ich jetzt die "Fonts" um 1/16 pixel "schieben" und drehen mit 
AntiAliasing, geht ja bei den Fonts/Bildern auch nicht. Sieht nun top 
aus.
- Ich kann bestätigen, dass man den Fifo, ausser man schickt mehr als 4k 
auf einmal hin, nicht "überfordern" kann (SPI@25MHz), man muss aber, 
bevor man erneut ein burst hinschickt mit eve_busy warten.
- Display list hat bei mir so ca. 5000-6000 Bytes mit Optimierungen nur 
das anzuzeigen was auch wirklich zu sehen ist und Minimierung von 
Farb/Dicken/usw. Änderungen.
Leider kann man ja hier keine Videos anhängen...:(

Danke jedenfalls an alle hier....:)..für die Hilfen und Tips...

Mal sehen ob mein Display auch mit Mipi geht..HW mässig wird das von dem 
Display exponiert und man kann die Betriebsart per Codierung einstellen. 
Dann ggf. mit nem Raspi oder z.B. Portenta H7 oder X8. Die haben "nativ" 
Mipi Dsi.
Der Eve chip ist sicher eine gute Idee, auf Dauer ist der chip sicher 
etwas einschränkend...wäre aber sicher auch cool wenn der weiter 
entwickelt wird...

Grüße
Torsten

[Rudolph (Gast)]

Spyy schrieb:
> - Ich "fahre" das Display mit 81 Hz, update den Kontent mit 81 Hz =>
> geht gut, updateraten der gesamten Liste (zwei Bursts mit eve_busy vor
> dem 2. Burst) ca. 1.0x-1.3x ms.

Also 25MHz sind "nur" so 3000 Bytes pro ms, hast Du mal probiert 
REG_CMDB_SPACE zu lesen nachdem der DMA durch ist? So statt EVE_busy()?
EVE_busy() wartet ja bis der FIFO komplett leer ist.

Eine andere Idee wäre noch zwei DMA Puffer zu verwenden die abwechselnd 
gefüllt und verschickt werden, so um nicht einfach nur zu warten.

Wobei 8k SRAM schon deutlich unter Luxus fallen wenn man überlegt wofür 
die EVE Chips eigentlich gedacht sind. :-)
Und wenn ich dann noch bedenke das ich zur Zeit Controller mit weniger 
Speicher verwenden muss, weil eben nichts zu bekommen ist - Aua. :-)

[Daniel S. (snipod)]

Rudolph R. schrieb:
> Was meinst Du jetzt mit Polling?
> Jedes Kommando einzeln Plus ein busy()?

Jedes Kommando als "nicht-burst" und nach jeder Komponente (also mein 
Button / Slider...) ein busy().

Rudolph R. schrieb:
> Was für einen Controller hast Du eigentlich und wie schnell ist der SPI,
> das scheint relativ langsam zu sein.

Ist ein ESP32 der mit 240MHz rennt. Der SPI Läuft mit 30 MHz

Rudolph R. schrieb:
> Aber wie kommst Du auf die Anzahl der Kommandos?
> Was genau meinst Du damit?

Sorry, das war einfach schlecht erklärt von mir. Ich habe mir zum testen 
in EVE_end_cmd_burst(), EVE_dma_buffer_index ausgeben lassen. Dieser 
zählt dann dementsprechend 560 - 650 ungefähr...

Rudolph R. schrieb:
> Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten,
> da müsste man schon die Befehle im Quelltext zählen weil die keine
> einheitliche Größe haben.

Das stimmt, aber ist es nicht sogar wahrscheinlich, dass dieser bei ~600 
Kommandos die 8k zum überlaufen bringt?

Spyy schrieb:
> Wann (vor welchem Befehl) wartest Du mit Eve_busy ? end_burst?

Genau, ich warte auf EVE_busy() nach(!) end_burst.

Spyy schrieb:
> Ist das nur wenn Du touch auf dem Screen machst?

Interessante Frage, ich versuch mal die DL so zu verlängern und schau ob 
die Glitches auch ohne Touch auftreten.

Spyy schrieb:
> wieviel Hz Widerholrate/Kontentupdate hast Du
> denn?

Ich hab mich hier bisschen an Rudolphs Beispiel orientiert, lese alle 
7ms die Touch Register aus und jedes 5. mal zeichne ich die Seite neu. 
Dementsprechend fahre ich circa 28.5 Hz... eigentlich nicht viel. Dafür 
sind meine Controls halt ziemlich aufwendig, allein ein so ein 
Wippschalter hat knapp 180 Kommandos im worst-case.

ich probier mal bisschen weiter und melde mich :)

[Daniel S. (snipod)]

Folgendes hab ich probiert (ohne Erfolg):

1. das Display nicht anfassen -> programmatisch die Schalter auf 
"touched" setzen. => Glitches sind weiterhin da

2. SPI Speed auf 20MHz runter, Zeichnen der Seite alle 100ms => Glitches 
weiterhin da

3. REG_CMDB_SPACE während EVE_dma_busy auslesen nach end_burst -> circa 
2k während der Glitches

Gibts was womit man langen text hiden kann? Ich hänge mal meinen code 
für den Button an, vielleicht fällt jemandem etwas auf

EVE_cmd_dl_burst(VERTEX_FORMAT(0));
    EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_RGB(255, 255, 255));
    EVE_cmd_dl_burst(COLOR_A(0));
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));

    // draw outline
    // outline radius = _br
    // draw the outline with alpha = 0 to set stencil
    EVE_cmd_dl_burst(LINE_WIDTH(_br * 16));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_x + _br, _y + _br));
    EVE_cmd_dl_burst(VERTEX2F(_x + _w - _br, _y + _h - _br));
    EVE_cmd_dl_burst(DL_END);

    // fill the stencil area with the gradient
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
    GradientHelper::Gradient(_x, _y, _w, _h, 0x131314, 0x202428, 0.1405, 0.8529, 318.21, true);
    // reset the stencil
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

    // calculate size of the inner area
    _brInner = _br - 4;
    _xInner = _x + 4;
    _yInner = _y + 4;
    _wInner = _w - 8;
    _hInner = _h - 8;

    // set scissor rectangle for inner area
    EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));
    EVE_cmd_dl_burst(SCISSOR_SIZE(_wInner, _hInner));
    // draw inner area
    // draw the inner area with alpha = 0 to set stencil
    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
    EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_xInner + _brInner, _yInner + _brInner));
    EVE_cmd_dl_burst(VERTEX2F(_xInner + _wInner - _brInner, _yInner + _hInner - _brInner));
    EVE_cmd_dl_burst(DL_END);

    // fill the stencil area with the gradient
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
    GradientHelper::Gradient(_x, _y, _w, _h, 0x151618, 0x34393F, -0.05, 1.0, 331, true);

    // reset stencil and stencil function
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    // Up part is pressed
    if (Up)
    {
        uint16_t xPart = _x + 4;
        uint16_t yPart = _y + 4;
        uint16_t wPart = _w - 8;
        uint16_t hPart = (_h / 2) - 4;
        // set scissors to upper part of control
        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));
        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));
        // setup the stencil for the upper area
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart + _brInner));
        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart + _brInner));
        EVE_cmd_dl_burst(DL_END);

        // fill the stencil area with the gradient
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
        GradientHelper::Gradient(_x, _y, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);

        // reset stencil and stencil function
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    }

    // Down part is pressed
    if (Down)
    {
        uint16_t xPart = _x + 4;
        uint16_t yPart = _y + (_h / 2);
        uint16_t wPart = _w - 8;
        uint16_t hPart = (_h / 2) - 4;
        // set scissors to upper part of control
        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner + (_h / 2) - 4));
        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));
        // setup the stencil for the upper area
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart - _brInner));
        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart - _brInner));
        EVE_cmd_dl_burst(DL_END);

        // fill the stencil area with the gradient
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
        GradientHelper::Gradient(_x, _y + _h / 2, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);

        // reset stencil and stencil function
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    }
    // draw the center line
    EVE_cmd_dl_burst(SCISSOR_XY(_x + 4, _y + (_h / 2) - 2));
    EVE_cmd_dl_burst(SCISSOR_SIZE(72, 4));
    EVE_cmd_gradient_burst(_x + 5, _y + 86, 0x202428, _x + 76, _y + 74, 0x151618);

    // scissor rectangle for indicator
    EVE_cmd_dl_burst(SCISSOR_XY(_x, _y - 14));
    EVE_cmd_dl_burst(SCISSOR_SIZE(_w, 10));
    EVE_cmd_dl_burst(COLOR_A(255));
    // draw the activity indicator
    if (Up || Down)
    {
        // draw the border
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x202020);

        EVE_cmd_dl_burst(LINE_WIDTH(2 * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
        EVE_cmd_dl_burst(DL_END);
        // draw the indicator line
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xC02825);
        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
        EVE_cmd_dl_burst(DL_END);

        EVE_cmd_dl_burst(COLOR_A(255));
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);
    }
    else
    {
        // draw the inactive line
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x161A1D);
        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
        EVE_cmd_dl_burst(DL_END);
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);
    }
    EVE_cmd_dl_burst(SCISSOR_XY(0, 0));
    EVE_cmd_dl_burst(SCISSOR_SIZE(480, 800));

    // draw the arrows
    EVE_cmd_setbitmap_burst(UpArrowAsset::GetInstance()->currentMemoryAddress, UpArrowAsset::GetInstance()->GetFormat(), UpArrowAsset::GetInstance()->GetWidth(), UpArrowAsset::GetInstance()->GetHeight());
    EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_dl_burst(VERTEX2F(
        _x + (_w - UpArrowAsset::GetInstance()->GetWidth()) / 2,
        _y + (_h / 4) - (UpArrowAsset::GetInstance()->GetHeight() / 2)));
    EVE_cmd_dl_burst(DL_END);
    EVE_cmd_setbitmap_burst(DownArrowAsset::GetInstance()->currentMemoryAddress, DownArrowAsset::GetInstance()->GetFormat(), DownArrowAsset::GetInstance()->GetWidth(), DownArrowAsset::GetInstance()->GetHeight());
    EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_dl_burst(VERTEX2F(
        _x + (_w - DownArrowAsset::GetInstance()->GetWidth()) / 2,
        _y + 3 * (_h / 4) - (DownArrowAsset::GetInstance()->GetHeight() / 2)));
    EVE_cmd_dl_burst(DL_END);

    // draw the label
    if (_posLabel != NULL)
        EVE_cmd_text_burst(_x + (_w / 2), _y - 26, GothamMedium18_FontHandle, EVE_OPT_CENTER, _posLabel);

    // draw the touch area
    EVE_cmd_dl_burst(COLOR_A(0));
    EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
    // touch area for UP
    EVE_cmd_dl_burst(TAG(_tag));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_x, _y));
    EVE_cmd_dl_burst(VERTEX2F(_x + _w, _y + _h / 2));
    EVE_cmd_dl_burst(DL_END);
    // touch area for DOWN
    EVE_cmd_dl_burst(TAG(_secondaryTag));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_x, _y + _h / 2));
    EVE_cmd_dl_burst(VERTEX2F(_x + _w, _y + _h));
    EVE_cmd_dl_burst(DL_END);
    EVE_cmd_dl_burst(COLOR_A(255));
    EVE_cmd_dl_burst(TAG(0));

[Rudolph (Gast)]

Daniel S. schrieb:
> Rudolph R. schrieb:
>> Was für einen Controller hast Du eigentlich und wie schnell ist der SPI,
>> das scheint relativ langsam zu sein.
>
> Ist ein ESP32 der mit 240MHz rennt. Der SPI Läuft mit 30 MHz

Ah ok, kein Wunder, dass das ohne Burst so langsam ist.
Das ESP-IDF überzeugt mich so gar nicht.
Einen DMA Transfer zu starten bedeutet auch nicht einen DMA Transfer zu 
starten, sondern vielmehr beim RTOS freundlich anzufragen in Erwägung zu 
ziehen den irgendwann mal anzuwerfen...
Ich habe keine Ahnung, warum die Dinger so erfolgreich sind, an der 
Software kann es eher nicht liegen. Oder es schaut zumindest kaum einer 
genau hin, warum das für 240MHz so unfassbar langsam ist.

In dem Bild oben braucht mein Controller 718µs um die Display-Liste 
zusammen zu puzzeln und den FIFO mit 3888 Bytes zu füllen. Nur benutze 
ich einen ATSAMC21 mit 48MHz.

> Rudolph R. schrieb:
>> Aber wie kommst Du auf die Anzahl der Kommandos?
>> Was genau meinst Du damit?
>
> Sorry, das war einfach schlecht erklärt von mir. Ich habe mir zum testen
> in EVE_end_cmd_burst(), EVE_dma_buffer_index ausgeben lassen. Dieser
> zählt dann dementsprechend 560 - 650 ungefähr...

Das ist ja nur die Anzahl der 32 Bit Wörter im Co-Pro FIFO.
Das können direkt Display-Listen Kommandos sein, so alles was 
EVE_cmd_dl() ist, die Co-Pro Kommandos brauchen allerdings mehrere 32 
Bit Wörter und das werden dann diverse Display-Listen Kommandos.

> Rudolph R. schrieb:
>> Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten,
>> da müsste man schon die Befehle im Quelltext zählen weil die keine
>> einheitliche Größe haben.
>
> Das stimmt, aber ist es nicht sogar wahrscheinlich, dass dieser bei ~600
> Kommandos die 8k zum überlaufen bringt?

Jain.
Möglich auf jeden Fall, aber es kommt halt darauf an was da drin steckt.
Siehe mein Bild oben, das sind 3888 Bytes im FIFO, entsprechend 972 32 
Bit-Wörter.
Damit mache ich die Display-Liste voll.
Ich habe allerdings bewusst 16 CMD_BUTTON mit rein geworfen da ich 
wusste, dass die in viele Display-Listen Kommandos resultieren.
Dein Code da oben hat doch fast nur EVE_cmd_dl drin, das geht direkt so 
in die Display-Liste.

Weil der Zusammenhang zwischen Display-Liste und FIFO nicht direkt 
offensichtlich ist, lasse ich mir ja auch beides ausgeben um das im 
Blick zu behalten.

[Rudolph R. (rudolph)]

Ich habe EVE_busy() gerade mal ein wenig erweitert.
Es gibt einen neuen Rückgabewert: EVE_FIFO_HALF_EMPTY.

Damit gilt:
EVE_IS_BUSY - wenn ein DMA Transfer aktiv ist oder weniger als 2048 
Bytes frei sind
EVE_FIFO_HALF_EMPTY - wenn kein DMA Transfer aktiv ist und mehr als 2048 
Bytes frei sind
E_OK - wenn kein DMA Transfer aktiv ist und der FIFO ganz leer ist

Damit sollte es möglich sein einen zweiten DMA Transfer früher zu 
starten als bisher, wenn man mehr als die 4k FIFO braucht.
Außerdem gibt es noch die Variable EVE_dma_busy.
Die wird auf 0 gesetzt sobald der DMA Transfer durch ist, spätestens 
dann kann man anfangen den nächsten Puffer zu füllen.
Vor dem EVE_end_cmd_burst() noch mit EVE_busy() auf entweder E_OK oder 
EVE_FIFO_HALF_EMPTY warten und alles wird gut. :-)
Damit dürfte die Zeit zwischen zwei Transfers deutlich kürzer werden.

Edit: ach so, ist noch nicht auf Github, aber bald. :-)

[Spyy (Gast)]

Wow danke...

Mal sehen ob ich damit die Zeiten für ein refresh noch optimieren 
kann...

:)

[Rudolph R. (rudolph)]

Ich probiere gerade aus, die _burst Funktionalität wieder in die 
normalen Funktionen zu packen.

Das sieht dann so aus:

void EVE_cmd_dl(uint32_t command)
{
    if(cmd_burst)
    {
        spi_transmit_burst(command);
    }
    else
    {
        eve_begin_cmd(command);
        EVE_cs_clear();
    }
}


void EVE_cmd_dl_burst(uint32_t command)
{
    spi_transmit_burst(command);
}

Nur ist das selbst für die paar Kommandos in meinem Beispiel zum einen 
messbar langsamer, zum anderen 392 Bytes größer.
Nun ja, langsamer ist relativ, ich lasse das gerade bare-metall auf 
einem Raspberry Pi Pico laufen mit DMA, statt 15µs dauert das Befüllen 
des Puffers jetzt 17µs und 392 Bytes fallen da auch nicht auf.
Der Gewinn wäre die ganzen Funktionen nicht mehr mit _burst() schreiben 
zu müssen zwischen dem EVE_start_cmd_burst() / EVE_end_cmd_burst().

Alle Platformen ohne DMA haben dann allerdings gelitten.

Schon seltsam, dass 25 Vergleiche selbst auf einem Cortex-M0+ mit 125MHz 
schon so 2µs ausmachen.

Ich muss das mal auf einem UNO ausprobieren.

[Rudolph R. (rudolph)]

Hmm.
Ich habe das jetzt mit einem UNO (Arduino), einem Metro-M4 (Arduino) und 
dem Pi Pico (Bare-Metall) ausprobiert und bei allen drei zeigt sich das 
Gleiche.

Schreibt man das in der vereinfachten Form hin, also so:

EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_dl(TAG(0));
EVE_cmd_append(MEM_DL_STATIC, num_dl_static);
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_fgcolor(0x00c0c0c0);

Dann wird das Programm zum einen langsamer und zum anderen größer durch 
die nun etwas längeren Funktionen.

Benutzt man allerdings die xxx_burst() Funktionen zusammen mit der 
modifizierten EVE_commands.c, dann läuft die Software wieder schneller 
ist ist nur ein wenig größer.

Beim UNO ist der Unterschied am Größten, das sind 520µs mit _burst 
Funktionen und 548µs mit normalen Funktionen die den Burst können.
Das Programm wird 618 Byte größer.
Mit modifizierten Funktionen aber unter Verwendung der _burst Funktionen 
komme ich wieder auf 520µs, das Programm ist dann 58 Byte länger.

Ok, klar, mit anderen Display-Listen wird der Unterschied größer.
Vor allem wenn weniger Funktionen beim Compilieren raus optimiert werden 
können.
Aber der Preis dafür das _burst wegzulassen ist vor allem auf Platformen 
die DMA unterstützen so klein, das macht gar nichts.

Dann baue ich das mal komplett um, zurück rollen geht ja immer noch. :-)

[Rudolph R. (rudolph)]

Oh je, ich weiß jetzt gerade nicht warum, aber ich habe die neue Version 
eben auch mit dem Teensy 4.1 ausprobiert.
Und da ändert sich nichts, die Anzeige mit dem Demo-Code ist immer noch 
"0003us". :-)

[Spyy (Gast)]

....also ich habe kein Problem immer _burst zu schreiben...:)...da ich 
ja quasi fertig bin...
Das mit dem neuen busy habe leider noch nicht probieren können...kommt 
Zeit kommt rat...

[Rudolph R. (rudolph)]

Spyy schrieb:
> ....also ich habe kein Problem immer _burst zu schreiben...:)

Ich finde es sieht schon irgendwie doof aus. :-)
Aber wenn man das zur Laufzeit aufdröseln will kommt man nicht drum 
herum einen Vergleich zu machen und der kostet Zeit.
Das sind 5% beim UNO.
Und bei allem mit DMA, 5% von praktisch nichts ist immer noch nichts, da 
kann man sich auch erlauben weniger zu tippen. :-)

[Spyy (Gast)]

Moin,

ihr habt doch Ahnung....
Ich lese einen Rotaryencoder in einen Schmittrigger 1A und 2A 
(74LVC2G14, je ein Kanal des Rotary A und B) ein und habe direkt die 
Ausgänge 1Y und 2Y mit einem Seeeduino XIAO von Seeedstudios an die 
digitalen Eingänge 9 und 10 verbunden.
Diese habe ich als Interrupt Eingänge konfiguriert (Flanken).
Nun kommt es aber immer wieder zu IRQ Auslösungen obwohl der Rotary 
nicht bewegt wird. Das hört auf, wenn ich mit nem Taskopf vom Ossi da 
ran gehe...die Signale sehen Top aus.
Ich habe mit/ohne internen Pullup oder mit 2x externen Pullup (10kOhm, 
ist alles 3.3V) versucht...kein Erfolg..
Ist das irgendwas mit der eine kann den anderen nicht treiben, oder 
so...?

Grüße und Danke...

[Rudolph R. (rudolph)]

Oh, vorzugsweise kein Kommentar, zum Thema Drehimpulsgeber wurden hier 
im Forum schon Kriege geführt. :-)

Aber das klingt jetzt als würde Dir noch ein Kondensator an den 
Drehgeber Pins fehlen, so 100pF bis 1nF, was anderes als ein paar pF 
zusätzlich bewirkt der Tastkopf ja nicht.

Der D21 auf dem Seeeduino XIAO hat im External Interrupt Controller aber 
auch die Möglichkeit Filtern zu aktivieren.
Und den GCLK_EIC könnte man auch noch kleiner einstellen.

[Spyy (Gast)]

...Kriege...oh je...soll nicht sein...

Ich denke das war "mein alter Freund" drive strenth....habe ich runter 
gedreht...und zack, schon geht es...ich habe über ein FFC Flachbandkabel 
PWM "Signale" (keine Ahnung was da die Standardfrequenz ist) für die 
Helligkeitsregelung der LEDs und in dem gleichen Kabel die Signale vom 
Schmittrigger der Encodersignale A und B. Das übersprechen hat 
offensichlich schon gereicht die IRQs im XIAO auszulösen...obwohl ich 
die Störungen auf dem Oszi nicht sehen konnte...nach dem "runterdrehen" 
des drive strenth ist jedenfalls alles ruhig...sollte man da noch solche 
Kondensatoren (wie bei der IC Spannungsversorgung) gegen Masse an die 
Signalleitungen A und B machen? Encoder A und B Flanken haben ja ne 
relativ niedrige Frequenz...selbst wenn man schnell dreht...

Grüße und Danke

[Rudolph R. (rudolph)]

Spyy schrieb:
> sollte man da noch solche
> Kondensatoren (wie bei der IC Spannungsversorgung) gegen Masse an die
> Signalleitungen A und B machen?

Wie ich schrieb, kann man ja machen, nur eher bis so 1nF, aber das sind 
zusätzliche Teile. :-)
Die eingekoppelten Spikes werden auch sehr kurz sein, dagegen hilft das 
Hardware-Filtern durch den Interrupt-Controller, die Pins werden ja 
nicht nur einmal gelesen und sofort ein Interrupt ausgelöst.

[Spyy (Gast)]

Moin,

also ich bin ein mittelmäßiger Programmierer...und bei "analog Technik" 
hört es bei mir komplett auf...

Ich habe ja nun meine "Gerät" zusammengedengelt, läuft auch gut...habe 
da aber auch eine ziemlich aufwändige Spannungsversorgung drauf von 
Pololu (D36V28Fx) glaube ich also zwei davon (3.3 und 5V). Benötige 3.3V 
und 5V Gesamtleistungsaufnahme ca. 2-5 Watt Ströme so auf der 3.3 V um 
die 1 Amp bei 5 V etwas weniger....

Hat jemand Ahnung/eine gute Idee was es da für Bauteile gibt die man da 
verwenden könnte (also so aus 5-40V mache 5V und 3.3V oder 1.8V) um sich 
da ne eigene Spannungsversorgung für ICs zusammen zu zimmern ?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Ich benutze bei meinen ganzen Display-Platinen den gleich Typ 
Schaltregler.
https://github.com/RudolphRiedel/EVE_display-adapter/tree/master/L-D5019-08
Wobei Typ jetzt nicht in dem Sinne das Bauteil direkt ist, mehr so 
SOT-23-6 mit dem Pinout, um 1A und 1,4MHz, davon gibt es nämlich einen 
ganzen Satz.

Die RT8259GE habe ich zwar  im Schaltplan stehen, die zu bekommen war 
zwischendurch aber nicht ganz lustig und die können "nur" 24V.
Ein R1240N001B-TR-FE steht in meiner Tabelle mit 30V, wie gut die laufen 
kann ich nicht sagen, ausprobiert habe ich die noch nicht.

Für 40V braucht man vermutlich einen größeren Regler oder was in einem 
"moderneren" Package, mir gefällt das SOT-23-6 soweit aber sehr gut. :-)

Für das RVT101HVBNWC00-B habe ich zwei Regler auf der Platine, einen für 
3V3, den anderen für 9V6.
Für das RVT70HSBNWC00-B habe ich die gleiche Platine benuzt, nur den 
Regler für das Backlight auf 5V runter konfiguriert.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Oder versuche es damit:
https://www.we-online.com/katalog/datasheet/171020601.pdf
Der ist zwar ein bisschen teurer, kann man aber auch als Muster 
anfordern, wenn man nur 1 Stück benötigt. Vorteil: Kompakt, keine 
separate Spule erforderlich (alles drin) und eben sehr leistungsfähig 
(Ui 6-42V, Uout 0,8 - 6V, 2A).
Ansonsten mal bei farnell "Schaltregler" eingeben:
https://de.farnell.com/c/halbleiter-ics/power-management-ics-pmic-/spannungsregler/dc-dc-schaltregler-einstellbar?searchref=searchlookahead
(hier 4756 Ergebnisse).
ein paar gewünschte Filter setzen und man wird mit hunderten 
Schaltreglern zugeschüttet. Vorteil: Man sieht gleich, was auf Lager 
ist...
Bernd

[Stanley (homer2009)]

Hello, I bought a display like 
this:https://es.aliexpress.com/item/32639840939.html?spm=a2g0o.order_list.0.0.21ef194dLDRmAI&gatewayAdapt=glo2esp.Could 
someone tell me what the config for this display should be.I use this 
library:https://github.com/RudolphRiedel/FT800-FT813.I have 
documentation for this display. The frequencies measured on the display 
are as follows:VSYNC-45Hz,HSYNC-36kHz ,PCLK-21MHz

[Rudolph R. (rudolph)]

This is not that easy to answer.

If you have a FT81x / BT81x board that is wired correctly and can supply 
the necessary current for the different voltage rails, then this might 
be possible.

I have no idea though if additional configuration of the chip is 
necessary and there is no datasheet for the display itself.
The next question would be which of the three connectors is actually 
populated.
And regardless which one is populated, the SDO pin from the panel is not 
wired on the board, so there is no way to ready anything from the chip.
At least it looks like SPI is configured and not MIPI DBI Type C, this 
makes things a bit less complicated.
My library does not have code to configure individual display chips with 
an additional SPI interface though.

As for the configuration, I would try EVE_EVE2_50, but that depends on 
the EVE chip that is actually used and the PCB for it, EVE_EVE2_50 is 
probably the most generic though.

[Stanley (homer2009)]

OK thank you for the information

[Spyy (Gast)]

Super, danke für eure Hinweise...werde mir einen aussuchen....

Dazu noch eine Frage:
Ich habe ein PoE Modul, welches in den "Stufen" 12V, 5V, 3.3V für die 
Ausgangsspannung zu haben ist: z.B. hier 
https://www.mouser.de/ProductDetail/Silvertel/Ag9705S?qs=OlC7AqGiEDnLRebpRgMQIg%3D%3D
Macht aus PoE über nen Trafo die gewünschte Versorgungsspannung => Toll

So...soweit so gut...ich brauche aber "leider" 5V und 3.3V mit einer 
gesamt Leistungsaufnahme ca. 5 Watt.
Macht es Sinn hier ein 5V PoE Modul zu nehmen, davon die 5V als 
Versorgung zu nutzen und noch über einen Schaltregeler daraus 3.3V zu 
machen?
ODER
Ein PoE Modul mit 12V Ausgangsspannung und daraus über zwei 
Schaltregeler 5V und 3.3V machen?

Grüße und Danke
Torsten

[Rudolph R. (rudolph)]

Mit diesen POE Modulen habe ich keine Erfahrungen.

Was mir spontan nur auffällt, bei 12V Ausgang macht das Teil 12W, bei 5V 
Ausgang "nur" 9W.
Aber wenn Du davon nur 5W brauchst, dann passt das doch mit dem 5V 
Ausgang und noch mal 3,3V Schaltregler dahinter.
Mit 12V Ausgang und zwei Reglern ist das vielleicht universeller 
benutzbar, dafür sind es aber eben auch mehr Teile.

[Bernd (Gast)]

Spyy schrieb:
> Macht es Sinn hier ein 5V PoE Modul zu nehmen, davon die 5V als
> Versorgung zu nutzen und noch über einen Schaltregeler daraus 3.3V zu
> machen?
Wenn die Stromaufnahme bei 3,3 V überschaubar ist, kann man auch einen 
Linearregler nehmen.

[Paul B. (paule201)]

Hallo zusammen,

ich spiele gerade mit einem STM32F303 und einem EVE2 Display von 
NewHeaven rum. (NHD-4.3-480272FT-CSXP-T)
https://newhavendisplay.com/4-3-inch-ips-480x272px-eve2-resistive-tft/

Ich habe die Funktionen spi_transmit und spi_recieve auf die HAL 
Variante umgebaut. SPI Frequenz sind 4.5HMz.

static inline void spi_transmit(uint8_t data)
{
  HAL_SPI_Transmit(&hspi1, &data, 1 , 50);
}
#endif

und

static inline uint8_t spi_receive(uint8_t data)
{
    uint8_t  dain;
    HAL_SPI_TransmitReceive(&hspi1, &data, &dain, 1 , 50);
    return (dain);
}

Ich lese erfolgreich die Chip ID 0x7C = 124. SPI Kommunikation sollte 
also passen. Verbunden sind Display und Platine mit 20cm Flachband 
Kabel.

Im Precpocessor habe ich "EVE_NHD_43" definiert. In der "EVE_config.h" 
sind verschiedene Parameter angegeben, allerdings weniger als im 
Datenblatt.

Das Display flackert immer nur ganz kurz wenn der "PDN Pin" betätigt 
wird. Ansonsten passiert leider nichts.

Hab ich noch was übersehen? Muss ich die anderen Parameter aus dem 
Datenblatt noch mit in die EVE_config schreiben?

@Rudolph: Viel vielen Dank das du diese Lib mit allen teilst, das 
erspart sehr viel Zeit und Frust!

Edit: Ich rufe nur die TFT_init auf, aber die sollte ja zumindest die 
Rechtecke und Kreise anzeigen.

Beste Grüße

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Ich habe die Funktionen spi_transmit und spi_recieve auf die HAL
> Variante umgebaut. SPI Frequenz sind 4.5HMz.

Ok, gab es dafür einen besonderen Grund?
Der einzige Unterschied zu meiner Variante mit LL_SPI_TransmitData8() 
ist ja das dadurch der Code langsamer wird, da mehr an sich überflüssige 
Checks jedes Mal neu durchgeführt werden.
Also kann man sicher machen, ich wundere mich nur.

Paul B. schrieb:
> Im Precpocessor habe ich "EVE_NHD_43" definiert. In der "EVE_config.h"
> sind verschiedene Parameter angegeben, allerdings weniger als im
> Datenblatt.

Nicht wirklich, unter dem Define Resolution_480x272 gibt es am Ende der 
EVE_config.h noch einen ganzen Satz Defines, viele Displays verwenden 
einfach die gleiche Konfiguration und so wird die ganze Datei deutlich 
kompakter.

Paul B. schrieb:
> Das Display flackert immer nur ganz kurz wenn der "PDN Pin" betätigt
> wird. Ansonsten passiert leider nichts.

> Edit: Ich rufe nur die TFT_init auf, aber die sollte ja zumindest die
> Rechtecke und Kreise anzeigen.

Meine TFT_init() aus dem Beispiel zeigt gar nichts an, da wird nur das 
Display initialisiert, so grundsätzlich, dann Backlight, Touch, Bilder 
an EVE schicken und am Ende wird mit initStaticBackground() eine 
Display-Liste generiert und in den Speicher von EVE geschrieben als 
Fragment für spätere Benutzung.
Erst mit der TFT_display() wird was angezeigt, inklusive dem vorher 
generiertem Fragment das ziemlich am Anfang mit EVE_cmd_append_burst() 
in die Liste eingehängt wird.

Also einmal noch TFT_display() hinterher und es sollte was angezeigt 
werden.

Paul B. schrieb:
> @Rudolph: Viel vielen Dank das du diese Lib mit allen teilst, das
> erspart sehr viel Zeit und Frust!

Gerne, ich hatte auch mit den Herausforderungen soweit viel Spaß. :-)
Ich hätte jetzt auch nicht gedacht, dass das Projekt immer noch läuft.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Ok, gab es dafür einen besonderen Grund?

Ich habe die LL Libs auf die schnelle nicht zur Hand gehabt, daher bin 
ich auf die HAL Version umgestiegen. Für die finale Anwendung würde ich 
dann wahrscheinlich auf die LL gehen.

Rudolph R. schrieb:
> Nicht wirklich, unter dem Define Resolution_480x272 gibt es am Ende der
> EVE_config.h noch einen ganzen Satz Defines

Alles klar, soweit unter war ich gar nicht. Danke für die Aufklärung!

Rudolph R. schrieb:
> Meine TFT_init() aus dem Beispiel zeigt gar nichts an

Dann hab ich das falsch verstanden, ich dachte das wäre schon so eine 
Basic Anzeige dabei.

Rudolph R. schrieb:
> Also einmal noch TFT_display() hinterher und es sollte was angezeigt
> werden.

Danke, dass bringt mich schon mal einen Schritt weiter!
Jetzt sehe ich auch die EVE2 Demo mit dem Stern Logo. Leider sehe ich 
sie nur für den Bruchteil einer Sekunde, genau dann wenn der PDN Pin per 
"PDN_Set" auf LOW gesetzt wird. Ich kann das mit dem Debugger auch nicht 
anhalten, es ist genau der Moment wenn er auf low geht wo ich kurz was 
sehe.

Meine while Schleife ist ziemlich simple:

 
 while (1)
  {
    TFT_init();
    HAL_Delay(1000);
    TFT_display();
    HAL_Delay(1000);
}

Ich habe mir alle Spannungen direkt am Display mit dem Oszi angesehen 
(5V und 3,3V), die brechen nicht ein oder ähnliches.

Das Vergrößern des Delays zwischen PDN_SET und PDN CLEAR brachte auch 
nicht.

Hast du noch eine Idee?

Danke für deinen Support!

[Rudolph R. (rudolph_r)]

Die TFT_init() gehört vor die Schleife.

[Paul B. (paule201)]

Das hatte ich zuerst auch probiert, da kam der DEMO Screen genau einmal 
kurz aufgeblitzt (in der TFT_init bei PDN_SET) und auch nur dann wenn 
ich zwischendurch die Spannung nicht weggenommen habe. Fürs Debugging 
hab ich es dann alles in die "while" geschrieben.

Das bedeutet im Umkehrschluss, dass die Übertragung der Daten sauber 
läuft. Beim zweiten durchlauf der TFT_init durch den kurzen Reset nach 
dem Power Down zeigt er alle korrekt an und dann wird es wieder dunkel 
--> er hat die Daten im Speicher und kurz nach dem Reset blitzt eben das 
"letzte Bild" auf.

Auch der "warm start" funktioniert leider nicht. (PDN_SET und CLEAR sind 
dabei auskommentiert)

EVE_cmdWrite(EVE_RST_PULSE,0U);  // reset, only required for warm-start if PowerDown line is not used

So nah dran und doch so fern :D.

[Rudolph R. (rudolph)]

So, jetzt noch mal von zu Hause und nicht vom Handy, aus irgendeinem 
Grund konnte ich nicht "anonym" posten.

Zeig doch mal ein bisschen was von dem was Du da treibst. :-)
Ich weiß auch, dass ich kein STM32 Beispiel habe, zumindest kein 
vollständig lauffähiges, vor allem habe ich bisher keinen Weg gefunden 
den Controller über HAL zu initialisieren um somit das Beispiel für 
mehrere Controller compilieren zu können.
Und generell war das lange Zeit unlustig an STM32 Controll heran zu 
kommen.
Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts 
anfangen, so funktional und ohne AECQ.


Aber, zitiert aus dem hier: 
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_STM32_RiTFT50_PlatformIO/src/main.c

int main(void)
{
    uint8_t display_delay = 0;

    HAL_Init();
//  SystemClock_Config();
    HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/200U); /*Configure the SysTick to have interrupts in 5ms time basis*/

//  EVE_init_spi();
//  EVE_init_dma();

    TFT_init();
    
    while(1)
    {
        if(system_tick)
        {
            system_tick = 0;

            TFT_touch();

            display_delay++;
            if(display_delay > 3)
            {
                display_delay = 0;

                TFT_display();
            }
        }
    }
}

Das Projekt compiliert zumindest so quer durch die Familien:
Environment    Status    Duration
-------------  --------  ------------
STM32L073      SUCCESS   00:00:01.173
STM32F030      SUCCESS   00:00:01.149
STM32F103      SUCCESS   00:00:01.154
STM32F303      SUCCESS   00:00:01.246
STM32F446      SUCCESS   00:00:01.495
STM32G474      SUCCESS   00:00:01.265
STM32G431      SUCCESS   00:00:01.258
nucleo_f439zi  SUCCESS   00:00:01.499
nucleo_h743zi  SUCCESS   00:00:01.686

Damit ist das meiste im Grunde genommen fertig, die ganze Low-Level 
Geschichten mit dem SPI gehen ohne zu Murren durch den Compiler.

Von der Struktur ist das grundsätzlich so wie ein funktionierendes 
Projekt laufen würde.
Allerdings, SystemClock_Config() ist dann sehr speziell.
Aber EVE_init_spi() sowie EVE_init_dma() gibt es immer noch nicht 
richtig, spontan bekommen man das bestenfalls ohne DMA zu laufen wenn 
man zumindest EVE_init_spi() auf das Projekt anpasst oder eben gleich 
eine eigene Funktion verwendet.

Ich plane gerade eine Platine mit STM32G0B1, da wollte ich auch nebenbei 
einen Display-Anschluss dran packen, zumindest die Controller habe ich 
da.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Zeig doch mal ein bisschen was von dem was Du da treibst. :-)

Ich lad das Projekt mal mit hoch, erstellt mit der offiziellen CUBE IDE 
vo STM. Wenn du sowieso mal was mit STM machen willst ist das eventuell 
der Trigger um die CubeIDE mal zu installieren :D.

Rudolph R. schrieb:
> Ich weiß auch, dass ich kein STM32 Beispiel habe, zumindest kein
> vollständig lauffähiges

Du machst das ja auch freiweillig und stellst alles zur Verfügung, da 
erwartet keiner für jede µC Familie ein lauffähiges Beispiel! 95% sind 
der Miete sind ja schon erledigt, dank deiner Lib.

Rudolph R. schrieb:
> Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts
> anfangen, so funktional und ohne AECQ.

Der Vorteil war bei STM32 "damals" die Preisansage. 32bit in LQFP48 für 
1$, dass war damals schon was.
Es gibt für Automotive FuSi Anwendungen auch Controller von STM, aber 
nur gegen Vorlage deiner DNA...ich hatte mal zwei SPC5 von STM in der 
Mache aber Datenblatt und Co gabs nur mit der Firmen Mail Adresse und 
CubeIDE und Co unterstützen die Teile gar nicht. Alles in allem zu viel 
Initialaufwand für Privat. Mit dem U5 könnte es zumindest für FuSi 
Anwendung außerhalb von Automotive wieder interessant werden. Der ist 
auch zu 98% Pin Compatible mit dem F303 ;).

Dein Beispiel Code und mein Code unterscheiden sich nicht viel, ich hab 
extra ein neues Projekt erstellt zum rumspielen mit dem F303 und dem 
Display, daher verwende ich aus Faulheit einfach HAL_DELAY für die 
Wartezeiten.
Sollte aber funktional keinen Unterschied machen zu deinem Beispiel mit 
dem SysTick.

Wenn wir das Ganze zum Laufen bekommen kannst du das Projekt auch gern 
mit hochladen/referenzieren für den STM32. Die Portabilität ist ja dank 
HAL (und deiner cleveren defines) easy.

Viel kann es ja bald nicht mehr sein, ich hab auch noch ein das NHD 3.5 
hier aus der selben Familie, dass zeigt genau das gleiche Verhalten.

Danke für deine Zeit!

[Rudolph R. (rudolph)]

Ich habe die STM32CubeIDE installiert. :-)
Und das Projekt baut auch.
Nur so "trocken" fällt mir da leider gerade nchts dran auf.

Hast Du einen Logic-Analyzer?

Und wie versorgst Du das Display überhaupt?
Nicht, dass der Controller einen Reset macht, weil die 
Hintergrundbeleuchtung so viel Strom zieht, dass der Regler sich 
abschaltet...

Hmm, NHD, irgendeines von denen liegt hier auch irgendwo herum, nach dem 
ersten wollte ich aber keine mehr, das FFC mit 1mm Abständen und dem 
fast kompatiblen Pinout fand ich extrem unlustig.
Ah, habs, NHD-3.5-320240FT-CSVX-CTP - gefällt mir gar nicht.
Aber nun, Newhaven hat das scheinbar aufgegeben, mit BT81x haben die 
nichts.

Paul B. schrieb:
> Rudolph R. schrieb:
>> Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts
>> anfangen, so funktional und ohne AECQ.
>
> Der Vorteil war bei STM32 "damals" die Preisansage. 32bit in LQFP48 für
> 1$, dass war damals schon was.

Tja, nun, ich habe gerade 7,03 Euro ohne Mehrwersteuer für STM32G0B1CET6 
bezahlt, 48 Pins, ab 10 Stück liegen die bei 6,36 Euro.
Das ist auch nur ein Cortex M0+ mit 64MHz, aber Speicher wie ein M4.
Ein ATSAME51J19A-AU ist bei Mouser gerade für 5,76 € gelistet und 
Digikey hat gerade sogar welche für 6,39€ das Stück bei 1 Stück.
Die können deutlich mehr, 64 Pins, haben einen 120MHz M4F, mehr SRAM und 
das ist zwar nicht die AECQ Version, aber es gibt eine.

Paul B. schrieb:
> Es gibt für Automotive FuSi Anwendungen auch Controller von STM

Ja schon, aber eben keine STM32.
SPC5 ist PowerPC, der e200 Core ist schon reichlich angestaubt und von 
Freescale lizenziert. NXP hat die MPC5xx noch weiter geführt aber 
inzwischen sind die bei der S32 Familie für Automotive mit ARM Kernen.
ST10 ist sowas von tot.
Und die Stellar sind zwar ARM aber Cortex M7 und ein eigenes Gemüse.
Ein SPC5 Board habe ich im Büro, bisher habe ich allerdings nicht 
mitbekommen das meine Abteilung was mit dem Controller gemacht hätte.

Ein S32K144 Eval-Board liegt gerade vor mir.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Nur so "trocken" fällt mir da leider gerade nchts dran auf.

Hmm, schade. Ich bau das Ganze jetzt noch mal "on the fly" auf mit einer 
auf F303 umgelöteten BluePill. Ich habe den PORTC, PIN15 im verdacht. Da 
hängt PDN dran und die Pins C13, C14 und C15 sind bei STM schwache 
Sonderlinge.

Rudolph R. schrieb:
> Hast Du einen Logic-Analyzer?

Nein, aber ein DSO mit Dekoder und Protokollfenster. Willst du was 
bestimmtes sehen?

Rudolph R. schrieb:
> Und wie versorgst Du das Display überhaupt?

Versorgt wird es über ein USB C Buchse, das USB Kabel hat offene Enden 
und hängt an einem Labornetzteil mit 3A. Dahinter sitzt ein 400mA LDO 
der auf 3,3V runter regelt. Mit Display zieht das ganze 120mA. Peakstrom 
muss ich noch messen, aber Spannungseinbrüche gab es bisher keine 
(Trigger auf 4.8V auf der 5V Leitung und 3.1V auf der 3,3V Leitung, 
fallende Flanke). Gemessen wurde direkt am Connector des Displays, da 
waren keine Einbrüche feststellbar.

Rudolph R. schrieb:
> mit BT81x haben die
> nichts.

Ist der BT81X so viel besser als der FT81X?

Rudolph R. schrieb:
> Ah, habs, NHD-3.5-320240FT-CSVX-CTP - gefällt mir gar nicht.

Mir gerade auch nicht :D.

Rudolph R. schrieb:
> Die können deutlich mehr, 64 Pins, haben einen 120MHz M4F, mehr SRAM und
> das ist zwar nicht die AECQ Version, aber es gibt eine.

Ich bin mit dem Sprung von 8 auf 32bit von Atmel weg, eventuell wage ich 
noch mal einen Exkurs. Bei STM32 fand ich halt die relative gute 
grafische Konfigurationsoberfläche nett. Für jemanden der das 
professioneller macht wahrscheinlich eher ein KO Kriterium als ein 
Benefit.

Rudolph R. schrieb:
> Ein S32K144 Eval-Board liegt gerade vor mir.

Bei NXP hab ich nach dem 1769 aufgehört, den hatten wir mal in der alten 
Firma und ich musste die Leiterplatte um das Ding designen. Mehr als ein 
Komponententest hab ich für das Ding nie programmiert, es wurden nur 
alle Sensoren kurz mal angetriggert und die Daten per UART 
rausgeschoben.

Ich melde mich wenn ich den neuen Aufbau habe, sag mir gern wenn du 
konkrete Befehle hast die ich mal mitloggen soll.

[Paul B. (paule201)]

Es läuft!

Es lag an PINC 15, einem der Sonderlinge. Ich habe die PINs getauscht 
und jetzt läuft der Kollege.

Vielen Dank für deine Hilfe!

Wenn du noch etwas brauchst für dein git repo oder ähnliches, sag 
einfach bescheid.

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Rudolph R. schrieb:
>> Nur so "trocken" fällt mir da leider gerade nchts dran auf.
>
> Hmm, schade. Ich bau das Ganze jetzt noch mal "on the fly" auf mit einer
> auf F303 umgelöteten BluePill. Ich habe den PORTC, PIN15 im verdacht. Da
> hängt PDN dran und die Pins C13, C14 und C15 sind bei STM schwache
> Sonderlinge.

Interessant.
Vor allem frage ich mich gerade warum PD scheinbar zappelt.

Paul B. schrieb:
> Nein, aber ein DSO mit Dekoder und Protokollfenster. Willst du was
> bestimmtes sehen?

Vorzugsweise den Reset-Event der nicht passieren sollte. :-)


Die Versorgung klingt erstmal stabil, ja.

Paul B. schrieb:
> Ist der BT81X so viel besser als der FT81X?

Ich würde nur noch BT817 benutzen.
ASTC komprimierte Bilder machen einen großen Unterschied im benötigen 
Speicherplatz, statt 16 Bit pro Pixel brauchen z.B. ASTC 8x8 Bilder nur 
2 Bit pro Pixel.
Dann ist der etwas schneller getaktet und die BT817/BT818 haben eine 
zweite PLL mit der man den Pixel-Takt viel feiner einstellen kann.
Das externe Flash ist sehr nett.
Und dann UTF-8 Zeichensätze, endlich Umlaute und Sonderzeichen einfach 
so.

Paul B. schrieb:
> Ich bin mit dem Sprung von 8 auf 32bit von Atmel weg

Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar 
nichts.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Interessant.
> Vor allem frage ich mich gerade warum PD scheinbar zappelt.

Eine gute Frage, auf dem Oszi war nichts auffällig. Und mehr als 3mA 
sollte der PDN vom FT ja nicht ziehen. Aber wie gesagt, die Pins sind 
als Sonderlinge bekannt

Rudolph R. schrieb:
> Vorzugsweise den Reset-Event der nicht passieren sollte. :-)

OK, hier:

;)

Rudolph R. schrieb:
> Ich würde nur noch BT817 benutzen.

Danke, ich werde mich mal umsehen, nur so zum spielen.

Rudolph R. schrieb:
> Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar
> nichts.

Das stimmt, konnte ja damals keiner ahnen was das rennen macht, CAN-FD 
oder Flex Ray. Da hat STM das gleich ganz weggelassen. Musste man dann 
extern machen.


Die Maschine läuft, die Touch Kalibrierung ist auch durchgelaufen und 
reagiert sauber.

Einige Fragen zum Workflow hätte ich noch.

Angenommen du willst ein ansehnliches HMI designen, nutzt du dann auch 
den EVE Screen Designer von FTDI/BT?

Wenn ich mir den aktuellen ESD 4.X ansehe, dann kann ich da meinen FT812 
gar nicht mehr anwählen. Heißt das ich muss auf den ESE, den EVE SCREEN 
EDITOR 3.3 zurückgreifen und bin damit von der neuen Version des ESD 
quasi ausgeschlossen?

Was würdest du empfehlen für das HMI design in zusammenhang mit deiner 
Lib? (semi-professionell, ich mach das als Hobby).
Hast du einen guten Workflow/Toolchain die du weiterempfehlen kannst?

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Rudolph R. schrieb:
>> Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar
>> nichts.
>
> Das stimmt, konnte ja damals keiner ahnen was das rennen macht, CAN-FD
> oder Flex Ray.

Hmm, das habe ich anders in Erinnerung. :-)
Der CAN-FD Standard war Ende 2015 fertig und da gab es FlexRay schon ein 
paar Jahre. Das Datenblatt vom TJA1080 ist zum Beispiel von 2007.
FlexRay war quasi schon tot bevor es CAN-FD gab. :-)

> Angenommen du willst ein ansehnliches HMI designen, nutzt du dann auch
> den EVE Screen Designer von FTDI/BT?

Nein, mit dem habe ich mich bisher nicht anfreunden können.

> Wenn ich mir den aktuellen ESD 4.X ansehe, dann kann ich da meinen FT812
> gar nicht mehr anwählen.

Ich habe gerade ESD 4.15.1 gestartet und konnte da ein Display mit FT812 
auswählen. Nur weiter als das komme ich spontan nicht wirklich.
Und die FT_Eve_Hal Library die da drunter liegt war mal der Grund warum 
ich meine Library angefangen habe. :-)
Wobei die heute anders aussieht, das sieht zum Teil vertrauter aus, wie 
kommt das nur? Breit grins. :-)
Ich muss da mal wieder rein schauen, aber von dem was ich spontan so 
gesehen habe möchte ich dafür meine Library nicht aufgeben.

> Heißt das ich muss auf den ESE, den EVE SCREEN
> EDITOR 3.3 zurückgreifen und bin damit von der neuen Version des ESD
> quasi ausgeschlossen?

Der Screen Editor steht bei 4.4.0.

> Was würdest du empfehlen für das HMI design in zusammenhang mit deiner
> Lib? (semi-professionell, ich mach das als Hobby).
> Hast du einen guten Workflow/Toolchain die du weiterempfehlen kannst?

Nein, ich werde neben meinem Hobby die Lib zu pflegen zwar gelegentlich 
dafür bezahlt ein Projekt mit einem Display zu machen, der Level ist 
allerdings Tools und Proto-Typing. Das heisst ich kann mich da ohne 
formale Anforderungen oder Prozesse dran austoben und es geht oft nur um 
ein einziges Exemplar.
Also der Teil der in der Entwicklung Spaß macht. :-)

Vor Weihnachten hatte ich so ein Projekt, da musste eine Komponente mit 
LIN angesteuert werden ohne offen zu legen wie man das macht.
Statt einer CANoe Simulation mit LDF dazu habe ich das in ein 5" 
"Tablett" gegossen, wobei das "Tablett" ein EVE3-50G in einem 3D 
gedrucktem Gehäuse mit einer Platine von mir ist die 2x CAN-FD und 2x 
LIN hat.
Das HMI besteht da nur aus einem Screen, so mit Firmen-Logo, ein paar 
eigene Buttons, einem Slider und Text.
Das ist vom Code her sehr dicht an meinem Beispiel-Programm und das HMI 
habe ich da entsprechend einfach so runter programmiert.
Die Kollegen waren begeistert wegen der sehr spontanten Umsetzung mit 
wenigen Tagen Vorlauf, der Kunde der damit spielen durfte war 
begeistert, weil es eben "einfach so" lief, so spontan an und ohne 
Noteboook. Und ich hatte Spaß daran das umzusetzen.

Viel Text um zu sagen das ich gar keine HMI Entwicklung in dem Sinne 
mache. :-)

Ein 10.1" habe ich schon im Büro liegen, das wartet noch auf das 
Gehäuse, das HMI dafür werde ich wohl als Skizze auf einer Serviette 
erhalten. :-)

[Paul B. (paule201)]

Eine Frage hätte ich noch zum Thema "CMD_KEYS"

Ich erstelle mir mit

        EVE_cmd_keys_burst(280,100,160,38,28,0,"789");
        EVE_cmd_keys_burst(280,140,160,38,28,0,"456");
        EVE_cmd_keys_burst(280,180,160,38,28,0,"123");
        EVE_cmd_keys_burst(280,220,160,38,28,0,"0.>");

mein Keyboard. Wie bekomme ich jetzt die Info das eine Feld gedrückt 
wurde? Beim Button muss man ja das TAG zuweisen, aber wie läut das hier?

So?

EVE_cmd_dl_burst(DL_TAG+7U);
EVE_cmd_dl_burst(DL_TAG+8U);
EVE_cmd_dl_burst(DL_TAG+9U);
EVE_cmd_keys_burst(280,100,160,38,28,0,"789");

EVE_cmd_dl_burst(DL_TAG+4U);
EVE_cmd_dl_burst(DL_TAG+5U);
EVE_cmd_dl_burst(DL_TAG+6U);
EVE_cmd_keys_burst(280,100,160,38,28,0,"456");

[Rudolph R. (rudolph)]

CMD_KEYS liefert den ASCII Wert als TAG zurück.
Das dürfte auch einer der Gründe sein warum das kein UTF-8 unterstützt.

[Paul B. (paule201)]

Rudolph R. schrieb:
> CMD_KEYS liefert den ASCII Wert als TAG zurück.
> Das dürfte auch einer der Gründe sein warum das kein UTF-8 unterstützt.

Danke für die Info, ich hab gar keine Mail bekommen das du geantwortest 
hast. Komisch. Ich habe es dann über einzelne Buttons gelöst.


Ich hab mal auf deinen Rat gehört und mir ein RVT50HQBNWC00 mit BT817 
gegönnt. Das passende #define habe ich eingebunden (EVE_RVT50H), Chip ID 
lesen klappt auch (124 dec).
Allerdings bleibt der µC in der "EVE_busy()" kleben. "space" wird immer 
mit "0" zurück gegeben. Unregelmäßig kommt auch mal "59823" zurück und 
er führt den Code aus um den CoProcessor wieder ans laufen zu bringen.

Hatte das schon mal jemand bei EVE4?

Vielen Dank!

[Rudolph R. (rudolph)]

Also so grundsätzlich habe ich mit dem RVT50HQBNWC00 soweit keinen 
Stress gehabt, aber ich habe auch keinen STM32F303 mit dem ich das 
testen könnte, der STM32 Teil ist auch ohnehin mal dran überarbeitet zu 
werden.

Ich habe hier einen Prototyp einer Platine mit STM32G0B1 hier auf das 
ich einen Display-Anschluss designed habe, bisheriger Stand ist 
allerdings noch das die LED plausibel blinkt und der externe Oscillator 
so nicht funktionieren kann.
Und am Mittwoch habe ich in Nürnberg noch ein STM32C0 Nucleo 
abgegriffen, also das ist in der Pipeline das ich was damit mache. :-)

Kannst Du das mit irgendeinem anderen Board testen und wenn es ein UNO 
ist?

[Rudolph R. (rudolph)]

Nach zähem Ringen mit den STM32 HAL Funktionen läuft die angehängte 
Software gerade auf meinem erstem eigenen STM32 Board auf dem ein 
STM32G0B1 bestückt ist und einem RVT50HQBNWC00.

Ich habe erstmal mit STM32CubeIDE ein Projekt erstellt und die 
SystemClock_Config(), MX_GPIO_Init() sowie MX_SPI1_Init() in meine 
main.c kopiert.

Und dann habe ich die MX_SPI1_Init() noch um die Konfiguration der SPI 
Pins erweitert die blöderweise nicht mit generiert wird, obwohl die Pins 
eingestellt sind.

Das nutzt jetzt noch nicht den Code aus EVE_target.c, da war ich noch 
nicht dran. Und DMA nutzt das auch nicht.

Die EVE_target_STM32.h hat noch das Problem das sich die Parameter gar 
nicht wie vorgesehen von "Außen" über Defines einstellen lassen.

An meiner EVE Library habe ich jetzt praktisch nichts geändert, in der 
EVE_target.h wird auf "STM32G0" geprüft, in der EVE_target_STM32.h auch 
noch mal.
Und in der EVE_target_STM32.h werden die HAL Includes für das Target 
gezogen.

In der speziellen main.c ist alles drin damit der Controller 
grundsätzlich läuft, so wie das eigentlich sein soll.
Was noch "fehlt" ist einen Timer zu benutzen um die Laufzeit der beiden 
Funktionen in µs zu messen.
Im Logic-Analyzer sehe ich das ein Display-Update gerade 290µs dauert.

Zum Vergleich habe ich die spi_transmit() gerade mal auf 
HAL_SPI_Transmit() umgestellt, damit dauert das exakt gleiche Display 
Update satte 2,332 ms, statt so 3xx ns zwischen den Bytes hat man mit 
HAL_SPI_Transmit() >10µs -> nicht zu empfehlen.

Für heute hatte ich damit aber erstmal genug Spaß. :-)

[Paul B. (paule201)]

Hey Rudolph,

coole Sache das du an der STM Unterstützung dran bist :).

Deine Lib hast du also quasi nicht angefasst, bis auf den G0 Teil.
Komisch, bei mir läuft es immer noch nicht. Ich habe leider kein anderes 
Board da zum testen (es mangelt am Display Anschluss).
SPI Frequenz hab ich auch schon auf unter 1 MHz runter gedreht, ohne 
Erfolg. Ich komme aus der EVE_busy nicht raus. Das Display ist neu, 
glaube kaum das das kaputt ist. Lesen der Chip ID und setzen des 
Backlights klappen problemlos.

Was schickst du in deiner EVE_Init? Auch die 0x46? Ich fand das 
Datenblatt an der Stelle etwas verwirrend.

"2 to 6 times the osc
frequency (i.e., 24 to
72MHz with 12MHz
oscillator)"

#if EVE_GEN > 2
    EVE_cmdWrite(EVE_CLKSEL, 0x46U); /* set clock to 72 MHz */
#endif

Zumal die Clock Frequenz ja kurze Zeit später noch mal ins Register 
geschrieben wird:

/* tell EVE that we changed the frequency from default to 72MHz for BT8xx */
#if EVE_GEN > 2
            EVE_memWrite32(REG_FREQUENCY, 72000000UL);
#endif

Hast du noch eine CLK_FREQ in der config.h mit hinzugefügt? Welche PCKL 
hast du eingestellt? 3?

Danke!

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Deine Lib hast du also quasi nicht angefasst, bis auf den G0 Teil.

Ja, und die Änderungen sind eingecheckt, das Projekt da oben holt sich 
die Library aus Github.
Ich musst nur mal den Cache von PlatformIO löschen damit das neu geladen 
wird.

> SPI Frequenz hab ich auch schon auf unter 1 MHz runter gedreht,

Ich bin auf 8MHz aber ich habe auch meine Adapter-Platine dazwischen.

> Ich komme aus der EVE_busy nicht raus. Das Display ist neu,
> glaube kaum das das kaputt ist. Lesen der Chip ID und setzen des
> Backlights klappen problemlos.

Welchen Rückgabewert liefert EVE_busy?
Eigentlich sollte die Abfrage praktisch immer E_OK, also Null zurück 
liefern.

> Was schickst du in deiner EVE_Init? Auch die 0x46? Ich fand das
> Datenblatt an der Stelle etwas verwirrend.
>
> "2 to 6 times the osc
> frequency (i.e., 24 to
> 72MHz with 12MHz
> oscillator)"
> #if EVE_GEN > 2
>     EVE_cmdWrite(EVE_CLKSEL, 0x46U); /* set clock to 72 MHz */
> #endif

Ja, BT81x setze ich immer von den Default 60MHz auf 72MHz hoch.

> Zumal die Clock Frequenz ja kurze Zeit später noch mal ins Register
> geschrieben wird:/* tell EVE that we changed the frequency from default
> to 72MHz for BT8xx */
> #if EVE_GEN > 2
>             EVE_memWrite32(REG_FREQUENCY, 72000000UL);
> #endif

Das ist um dem Co-Processor mitzuteilen was eingestellt wurde.
Warum auch immer man das tun muss.

> Hast du noch eine CLK_FREQ in der config.h mit hinzugefügt? Welche PCKL
> hast du eingestellt? 3?

Ich habe die Konfiguration nicht verändert.
Ohne EVE_PCLK_FREQ und mit EVE_PCLK auf 3 kommt das Display mit den 
restlichen Parametern auf 59,3 Hz.
Ich hatte zuerst die Konfiguration für das EVE3_50G aktiv, damit lief 
das RVT50H auch grundsätzlich, nur sicher ohne Touch, weil ein anderer 
Touch-Controller konfiguriert wird.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Welchen Rückgabewert liefert EVE_busy?

ich lese den Wert "space" immerm mit "0" zurück, obwohl es "0xffcU" sein 
sollte. Damit springt er dann in den letzten "else" Zweig und liefert:
EVE_IS_BUSY (12) zurück. Damit hänge ich in der while von 
"EVE_excute_cmd" fest:

void EVE_execute_cmd(void)
{
    while (EVE_busy() != E_OK)
    {
    }
}

Rudolph R. schrieb:
> EVE3_50G aktiv, damit lief
> das RVT50H auch grundsätzlich

Hab ich auch probiert, gleiches Ergebnis. Bei dem GEN2 Display was ich 
hier habe (NHD43) klappt das rücklesen von "space" problemlos mit 
0xffcU.

[Rudolph R. (rudolph)]

Hmm, ja, das macht soweit gerade keinen Sinn.
Wie sieht der SPI traffic zu dem EVE_busy() denn aus?

Das müsste so aussehen:
MOSI: 0x30 0x25 0x74 0x00 0x00 0x00
MISO: 0x00 0x4a 0x43 0x42 0xfc 0x0f

Da Du "nur" ein Oszi hast würde ich dazu gerne mal ein paar Bilder 
sehen.

Und wenn das in EVE_execute_cmd() hängt, was wurde dann davor 
ausgeführt?
Hängt das am Ende von EVE_init() oder später?

[Paul B. (paule201)]

Rudolph R. schrieb:
> Wie sieht der SPI traffic zu dem EVE_busy() denn aus?

Kann ich dir leider erst morgen liefern, bin noch unterwegs.


Rudolph R. schrieb:
> Und wenn das in EVE_execute_cmd() hängt, was wurde dann davor
> ausgeführt?

Nur das was in der INIT steht (hab nur den Backlight Wert angepasst, 
damit ich  überhaupt eine Reaktion sehe)


Rudolph R. schrieb:
> Hängt das am Ende von EVE_init() oder später?

Ja, genau da.

[Rudolph R. (rudolph)]

Paul B. schrieb:
>> Hängt das am Ende von EVE_init() oder später?
>
> Ja, genau da.

An der Stelle passiert aber quasi gar nichts, es gab noch kein
Co-Processor Kommando und das Programm kommt da nur an wenn alle 
Einheiten signalisieren, dass sie aus dem Reset sind.
Da steht das praktisch nur pro-forma drin, daher mache ich da auch gar 
keine Fehler-Reaktion.

Was mir noch aufgefallen war, ich habe DELAY_MS() auf HAL_Delay(ms) 
umgebogen und damit etwas zu kämpfen gehabt.
Ich hatte erst einen eigenen SysTick_Handler(), der konnte so aber nicht 
funktionieren.
Dann habe ich das mit der HAL Implementierung probiert, wo auch immer 
die vergraben ist, wollte auch nicht so recht.
Am Ende habe ich das wieder selber implementiert, aber erweitert:

void SysTick_Handler(void)
{
    system_tick = 42;
    HAL_IncTick(); /* needed for HAL_Delay() to work */
}

Das HAL_Delay() braucht HAL_IncTick().
Aus dem Grund musste ich auch meinen "Scheduler" umbauen, von den 5ms 
Ticks die ich sonst benutze auf 1ms Ticks die von HAL_Init() eingestellt 
werden.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

RamDL "mitten drin" beschreiben:
Hallo Fan-Gemeinde. Hat schon mal jemand den RamDl nicht an der 
Startadresse beginnend (30.000) beschrieben, sondern mitten drin?
Hintergrund:
Ich schreibe ein komplettes Bild mit diverser Grafik, was ja je nach 
Umfang doch immerhin beim Schreiben per SPI einige Millisekunden dauern 
kann.
Bei einer zeitkritischen Anwendung kann das stören.

Nun muss das komplette Bild aber nur (nach dem ersten Setzen) immer mit 
2 Messwerten verändert werden. Diese Werte schreibe ich ganz am Ende der 
List. Vorher zähle ich den RamDL mit und springe dann, wenn besagte 
Werte geändert werden sollen an diese Stelle und öffne eine neue List 
mit RamDl = zuletzt benutzte Adresse. Das funktioniert so weit auch 
alles richtig gut! Zur Aktualisierung dieser Werte am Bildschirm 
benötige ich nun nur noch 500µs!

Am Ende schreibe ich natürlich noch in den REG_DLSWAP die 2. Und der 
neue Wert erscheint am Bildschirm. ABER mit jedem REG_DLSWAP springt die 
Anzeige zwischen dem 1. Wert, den ich auf diese Weise geschrieben habe 
und dem neuesten hin und her. Also z.B. 1. Wert = 1, wird angezeigt. 
Dann ist der Wert = 2, Bild springt auf 2, nächster Wert ist 3 aber 
Anzeige springt auf 1. Dann kommt Wert = 4, Anzeige springt auf 4, mit 
nächster Aktualisierung wieder auf 1 ... Erhöhe ich die 
Aktualisierungsfrequenz von eben ca. 100ms auf 5ms SCHEINT es zu 
funktionieren. Da sich die Werte dann aber so extrem schnell ändern, ist 
das nicht ganz klar erkennbar.

Ähnliches Vorgehen hatte ich schon mal bei einem Stellpult mit 
Schiebereglern angewendet. Um das Schieben der Steller flüssig zu 
gestalten, habe ich die gesamte Grafik an den Beginn gesetzt und nur die 
Schieber selbst dann am Ende per Sprung in den RAMDL an zuletzt benutzte 
Position (vor Beginn des Setzens der Schieber) gesetzt. Durch das nun 
sehr schnelle Beschreiben des Bildes, bewegen sich die Schieber 
schneller.
Erst sprang das komplette Bild zwischen dem zuletzt gesetzten Bild und 
der Regler-Ansicht hin und her (natürlich extrem schnell). Erst nachdem 
ich das Bild 3 mal beim ersten Sprung in das Regler-Menü gesetzt hatte, 
funktionierte es auch mit den Schiebereglern.

Mit REG_DLSWAP = 1 hatte ich es auch schon versucht. Ändert sich nichts. 
Mit jedem REG_DLSWAP springt doch der FT813 zwischen seinen 2 
Ringspeichern hin und her und führt immer gerade einen aus, während man 
den anderen "in Ruhe" beschreiben kann. Warum scheint es so, dass in 
diesem Fall, immer nur EIN Ringspeicher beschrieben wird?

[Rudolph R. (rudolph)]

Äh, ich bin nicht sicher was da schief läuft, ich schreibe nie in die 
Display-Liste, ich lasse nur die "Coprocessor Engine" in die Liste 
schreiben.

Auf jeden Fall ist RAM_DL schon mal kein Ring-Speicher, das gilt nur für 
RAM_CMD.
Entsprechend beginnt die Liste immer bei 0x300000 und man kann nicht 
über das Ende hinaus schreiben und automatisch wieder am Anfang landen.

>und öffne eine neue List mit RamDl = zuletzt benutzte Adresse.

Der Part ist mir nicht klar, sowas geht gar nicht in dem Sinne.

Der Bereich RAM_DL ist doppelt vorhanden, die 8kiB die man gerade sehen 
kann sind der inaktive Teil.
Und mit REG_DLSWAP = 2 wird getauscht, die 8kiB die man gerade 
bearbeitet hat sind weg und aktiv, die 8kiB die eben noch für die 
Generierung des Bildes verwendet wurden sind inaktiv und erreichbar.

Also um das zu manipulieren müsste man erstmal die Liste zwei Mal 
schreiben.

Und einfach mal mit dem EVE Screen Editor hingeworfen ergibt zum 
Beispiel
CLEAR(1, 1, 1)
CMD_NUMBER(642, 353, 28, 0, 42)

Das hier:
  Raw  Text
0  0x26000007  CLEAR(1, 1, 1)
1  0x22000000  SAVE_CONTEXT()
2  0x27000002  VERTEX_FORMAT(2)
3  0x0500001c  BITMAP_HANDLE(28)
4  0x1f000001  BEGIN(BITMAPS)
5  0x06000034  CELL(52)
6  0x45040584  VERTEX2F(2568, 1412)
7  0x06000032  CELL(50)
8  0x451c0584  VERTEX2F(2616, 1412)
9  0x23000000  RESTORE_CONTEXT()
10  0x00000000  DISPLAY()

Um die angezeigt Zahl zu ändern müsste man also nur wissen wo die im 
Speicher steht und die 0x34 und 0x32 auf die passenden Werte ändern.
Dann REG_DLSWAP = 2 und man sieht es auf dem Schirm und hat die 
vorherigen Werte im Speicher.

So, jetzt stehen da noch haufenweise Kommandos vor diesem Block die sich 
nie ändern sollen.
Zum Beispiel so im Coprozessor-Format:
CLEAR(1, 1, 1)
POINT_SIZE(100)
BEGIN(POINTS)
VERTEX2F(5760, 3408)
END()
BEGIN(LINES)
VERTEX2F(6112, 5312)
VERTEX2F(7776, 4992)
VERTEX2F(9424, 2656)
VERTEX2F(3888, 5456)
END()
BEGIN(RECTS)
VERTEX2F(10032, 1904)
VERTEX2F(10736, 3600)
VERTEX2F(9088, 4560)
END()
CMD_NUMBER(642, 353, 28, 0, 42)

Dazu lasse mir vom Coprocessor eine Display-Liste erzeugen ab 
POINT_SIZE() bis vor CMD_NUMBER(), kopiere die per CMD_MEMCPY aus RAM_DL 
nach RAM_G und dann lasse ich den Coprocessor dieses Fragment beim 
Generieren der nächsten Display-Liste per CMD_APPEND mit in die neue 
Liste kopieren.

CLEAR(1, 1, 1)
CMD_APPEND(0x12345, 42)
CMD_NUMBER(642, 353, 28, 0, 42)

Das ist in meinem Beispiel-Programm drin, siehe initStaticBackground().
Ich nutze das nicht so aggressiv, da für den Transfer ohnehin meistens 
DMA verwende und ich das Update "nur" alle 20ms machen lasse (darf auch 
nicht zu schnell sein, sonst flackert das).

Der Vorteil ist, dass ich gar nicht wissen muss wo irgendwas in RAM_DL 
landet und trotzdem nicht immer alles neu schicken muss.

https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

Der komische Stern (bzw. natürlich die Kommandos den aus dem Speicher 
anzuzeigen), der Button und die Messwerte werden immer geschickt, der 
Rest nicht.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Sorry, aber mit dem Co_Prozessor komme ich (immer) noch nicht klar. 
Meine eigene Software auf meine Art hat sich seit Jahren bewährt...:):).
Ich öffne die SPI schreibe die Startadresse Hx300000 (natürlich sendet 
man HxB00000 für "Schreiben"). Dann sende ich Befehl für Befehl jeweils 
4 Byte (32 Bit). Die Daten werden automatisch jeweils in die 
nachfolgende Speicherzelle des RamDL geschrieben. Am Ende der 
Befehlsliste wird CS wieder auf High gezogen, um anschl. sofort wieder 
auf Low zu ziehen, um das Register REG_DLSWAP mit 2 zu beschreiben...
OK, ob nun Ringspeicher oder nicht. Richtig, soweit ist mir das auch 
klar, dass es den RamDL 2 x gibt und jeweils mit REG_DLSWAP getauscht 
wird und das ich den natürlich nicht "überschreiben" darf (also über 8kB 
hinaus).

Nach dem Öffnen (SPI) und der Staradresse 30.0000 zähle ich nun jeden 
Befehl mit. Nach 2000 Befehlen wurde also der letzte Befehl in den 
Speicher Hx30.0000 + (Dx2000 x 4), also in 301F3C bis 301F3F 
geschrieben. Also muss Befehl 2001 in den Speicher 301F40 rein, was ja 
nun automatisch passieren würde! Hier startet nun das Setzen meiner zu 
aktualisierenden Werte Messwerte. Setze ich also das gesamte Bild, fahre 
ich hier weiter fort. Wenn ich NUR die Werte aktualisieren möchte ohne 
den ganzen Bildschirm dabei neu schreiben zu müssen, Öffne ich die SPI 
und beginne mit dem Schreiben der Adresse Hx301F40 und den folgenden 
restlichen Befehlen (die Werte auf den Bildschirm bringen), endend mit 
REG_DLSWAP = 2. Das meine ich mit "und öffne eine neue List mit RamDl = 
zuletzt benutzte Adresse".
Warum aber wird nun einer der beiden Speicher nicht überschrieben, 
obwohl ich doch jedes mal mit REG_DLSWAP tausche???

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Warum aber wird nun einer der beiden Speicher nicht überschrieben,
> obwohl ich doch jedes mal mit REG_DLSWAP tausche???

Mal davon ab, dass in Deiner Beschreibung immer noch fehlt, dass Du die 
Display-Liste initial zwei Mal komplett beschreibst, was Du vermutlich 
aber getan hast, ich sehe gerade keinen Grund, warum das so nicht 
funktionieren sollte.

Das mag zwar umständlich sein, aber durchaus zulässig.

Hmm, ich muss das mal ausprobieren. :-)

[Rudolph R. (rudolph)]

Ich habe das gerade ausprobiert, das Ergebnis hängt an.
Hier läuft gerade von einem Arduino UNO aus ein Punkt über den 
Bildschirm.

Ich schreibe zwei Mal die gleiche Display-Liste:

EVE_memWrite32(EVE_RAM_DL, DL_CLEAR_COLOR_RGB);
EVE_memWrite32(EVE_RAM_DL + 4U, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
EVE_memWrite32(EVE_RAM_DL + 8U, VERTEX_FORMAT(0U));
EVE_memWrite32(EVE_RAM_DL + 12U, DL_COLOR_RGB + 0xff00ff);
EVE_memWrite32(EVE_RAM_DL + 16U, POINT_SIZE(300U));
EVE_memWrite32(EVE_RAM_DL + 20U, DL_BEGIN + EVE_POINTS);
EVE_memWrite32(EVE_RAM_DL + 24U, VERTEX2F(100, 100));
EVE_memWrite32(EVE_RAM_DL + 28U, DL_DISPLAY);
EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

Und dann schreibe ich alle 20ms die Koordinaten für den Punkt neu:

EVE_memWrite32(EVE_RAM_DL + 24U, VERTEX2F(xc, yc));
EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

Da ist jetzt nicht ein CoProcessor Kommando drin und das läuft einfach.
Sicher, das Beispiel ist etwas wenig komplex, aber so grundsätzlich tut 
das halt was es soll.

Edit: mir ist gerade noch aufgefallen, das schreibt jedes Kommando für 
sich und nicht nur einmal die Adresse.
Das sollte keinen Unterschied machen, ist nur langsamer.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Klar scheibe ich das Display zunächst 2 mal, bevor man dann das eine 
Detail am Ende aktualisieren kann. Das Beispiel mit den 2000 Befehlen 
(mal 4 Byte = 8k) war auch unüberlegt. Dann wären wir ja schon über den 
erlaubten 8k. Also nehmen wir mal an, es sind nur 500 Befehle...
Aber ich sehe, Du hast das Prinzip, worum es mir geht, richtig 
verstanden. Und ich verstehe ebenso wie Du nicht, warum das so 
merkwürdig funktioniert.

In Deiner List schreibst Du in Adresse 28 vor dem DL_SWAP noch den 
DL_DISPLAY, wie es sich gehört. So weit , so gut. Aber wenn Du dann die 
Koordinaten des Punktes in Adresse 24 aktualisierst, führst Du anschl. 
NUR den DL_SWAP aus, ohne das DL_DISPLAY davor. Muss ich nachher gleich 
mal ausprobieren, ob sich dadurch etwas ändert!!!

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudi,
Du hast ja soooo Recht!!! Natürlich gibt es keinen vernünftigen Grund, 
warum es nicht funktionieren sollte! Es sei denn...
Ich schreibe die List und setze schon mal den RamDL auf HxB0 00 00. Dann 
zähle ich den RamDL mit jedem Befehl (mal 4) und komme also am 
entscheiden Punkt, wo ich später mal hinspringe, um NUR die letzten 
Daten am Bildschirm zu ändern, wo ich den Wert des RamDL speichere. Für 
die Aktualisierung der letzten Daten öffne ich dann also eine neue List 
und starte die mit RamDL, wie eben gemerkt. Nun hatte ich den blöden 
Fehler gemacht und hier noch einmal Hx80 00 00 dazu addiert, also bei 
JEDEM Sprung Dadurch war bei jeder Aktualisierung das erste Bit 
("Schreiben") mal Low und dann wieder High... So kommt der Wechsel zu 
Stande. Was soll man dazu sagen - Passiert ...

Das ganze ist aber (wenn man es also richtig anstellt) eine sehr gute 
Möglichkeit, einen Bildschirm teilweise zu beschreiben unter 
Beibehaltung aller möglichen Grafiken und kann somit wertvolle Zeit 
sparen, wenn es darauf ankommt. Vielleicht konnte ja jemand mit diesen 
Beiträgen etwas für sich daraus entnehmen ...!
Liebe Grüße, Bernd

[Rudolph R. (rudolph)]

Prima, dass das geklärt ist und der Fehler ist interessant kreativ.
Sowas hätte ich im Logic-Analyzer Trace gesehen. :-)

Ich bin nur bei der Schlussfolgerung nicht ganz bei Dir. :-)

Ein
EVE_cmd_number(100, 200, 28, EVE_OPT_RIGHTX, irgendeinezahl);
ist doch erheblich leichter im Code zu pflegen, rechnet selber aus 
welche Glyphen wo stehen müssen, passt die Anzahl der Stellen 
automatisch an und braucht immer nur 4 32 Bit Worte auf dem SPI.
Oh ja, negative Zahlen und 1-9 Stellen mit führenden Nullen gehen auch.
In Verbindung mit CMD_SETBASE kann man das auch binär, octal und 
hexadezimal ausgeben lassen.

Du hast ja Recht, dass das Update weniger Zeit braucht, dem gegenüber 
steht aber der vielfach höhere Aufwand das umzusetzen und zu pflegen und 
dann darf man die Liste ohnehin nicht häufiger wechseln als die Bildrate 
ist, das bedeutet man hat bei 60Hz mal eben 16,666ms Zeit zwischen zwei 
Aktualisierungen.
Und bei einer vollständigen Aktualisierung, etwa wenn man eine ganz 
andere Bildschirmseite anzeigen möchte, dann muss erheblich mehr über 
den SPI geschickt werden wenn direkt eine Display-Liste geschrieben 
wird, als wenn man das den Kommando Co-Prozessor machen lässt.

Wobei man das ja kombinieren kann, man könnte ja ein Stück Display-Liste 
in den Speicher schreiben und per CMD_APPEND in die Liste einfügen 
lassen.
Dann könnte man den Speicher manipulieren und neu einfügen lassen.
Keine Ahnnug, drei Kreise mit unterschiedlichen Farben für eine Ampel.
Statt das im Speicher zu manipulieren könnte man aber auch so viele 
Varianten anlegen wie man benötigt und jeweils die passende einfügen 
lassen - wenn sich der Aufwand überhaupt lohnt.

[Luky S. (luky)]

Ich habe mit der Bibliothek und einem Riverdi RVT43HLBN (BT817) 
rumexperimentiert, aber ich Frage mich immer noch, was der beste Weg 
ist, ein bildschirmfüllendes Hintergrundbild auf das Display zu 
bekommen. Muss nicht schnell sein, wird nur einmal geladen, aber mit 
welchem Tool konvertiere ich es und in welchem Format? Ist die 4k 
Begrenzung immer noch ein Thema oder inzwischen gefixt?

[Rudolph R. (rudolph)]

Luky S. schrieb:
> Ich habe mit der Bibliothek und einem Riverdi RVT43HLBN (BT817)
> rumexperimentiert,

So eines habe ich noch nicht.

> aber ich Frage mich immer noch, was der beste Weg
> ist, ein bildschirmfüllendes Hintergrundbild auf das Display zu
> bekommen. Muss nicht schnell sein, wird nur einmal geladen, aber mit
> welchem Tool konvertiere ich es und in welchem Format?

Mit dem EVE Asset Builder: https://brtchip.com/toolchains/

Für die BT81x kann ich nur ASTC empfehlen, ASTC 8x8 braucht vor allem 
nur 2 Bit pro Pixel bei voller Farbtiefe mit Alpha.
Das hier könnte hilfreich sein:
https://github.com/RudolphRiedel/FT800-FT813/discussions/83

Wobei es da vor allem darum ging ein Bild direkt aus dem Flash 
anzuzeigen.

> Ist die 4k Begrenzung immer noch ein Thema oder inzwischen gefixt?

Das ist schon lange gefixt, so irgendwann in V4, das betraf ja nur mal 
cmd_inflate und cmd_loadimage.

Für direktes Schreiben hätte ich noch EVE_memWrite_sram_buffer() und 
EVE_memWrite_flash_buffer() anzubieten, wobei die sich nur auf AVR 
Controllern wirklich unterscheiden.

[Luky S. (luky)]

Danke, das Beispielprogramm hat mir schon weitergeholfen, ich habe aber 
glaube ich noch ein grundsätzliches Verständnisproblem mit dem EVEx 
System:
Wie bekomme ich die Bilder ins Flash? Damit ist ja der direkt am BT817 
per QSPI angebundene NOR Flash gemeint, oder?

Ich habe leider nur eine Ansteuerplatine mit einem ATmega328 ohne 
zusätzlichen Speicher drauf.

[Rudolph R. (rudolph)]

Also "normalerweise" soll man das Flash-Image das EAB erzeugt auch mit 
EAB in das NOR-Flash vom Display schreiben, dazu braucht man einen 
USB/SPI Adapter.
https://www.matrixorbital.com/ftdi-eve/eve-bt817-bt818/eve-usb2spi-kit-b
https://www.matrixorbital.com/ftdi-eve/eve-bt815-bt816/eve2-usb2spi-kit-a
https://riverdi.com/blog/hermes-board-spi-usb-bridge-board-2/

Hmm, die Produkt-Seite für das Hermes Board ist nicht mehr da.
Und das "eve-usb2spi-kit-b" würde ich ja gerne kaufen, ich wüsste aber 
nicht wo.
Das "eve-usb2spi-kit-a" gibt es bei DigiKey und Mouser.

Meine Beispiele haben aber auch Code wie man das aus dem Controller 
heraus macht, siehe TFT_init() in tft.c.

Nur braucht man dafür den Speicher im Controller und ein M328 ist dafür 
doch etwas sehr knapp dran.
Wenn das Programm nichts anderes machen soll als Flash Daten zu 
schreiben, dann kommt man mit unter 4kiB für das Programm aus, dann 
bleiben 27kiB für die Daten.
Das Flash wird in 4kiB Happen beschrieben, also 24kiB.
Man könnte ein Flash-Image mit EAB erzeugen, mit irgendeinem Tool in 
24kiB Häppchen teilen, mit EAB die Binär-Happen in ein C-Array umwandeln 
und per extra Programm mit EVE_memWrite_flash_buffer() in RAM_G 
schreiben um dann per EVE_cmd_flashupdate() das RAM_G in das Flash zu 
schreiben.
Sobald der allererste 4kiB Block mit dem "Blob" geschrieben ist kann man 
per EVE_init_flash() den Modus auf "fast" stellen lassen.

Etwas nervig, aber durchführbar.

Wenn man einen dickeren Controller hätte wie einen ESP32 oder Teensy4, 
dann wäre bei der Methode das RAM_G der begrenzende Faktor, das ist halt 
"nur" 1MiB.
Dann müsste man das entweder in Etappen schreiben, oder aber 
EVE_cmd_flashwrite() benutzen.
Das erfordert aber auch, dass das Flash leer ist, also ein 
EVE_cmd_flasherase() braucht man dann auch noch.

In tft.c benutze ich EVE_cmd_inflate() um das Flash-Image vom Controller 
in RAM_G zu entpacken, das macht deshalb Sinn, weil in meinem 
Flash-Image ein UTF-8 Font drin ist und die sind auch in ASTC Format 
noch mal hoch komprimierbar, das könnte an den leeren Glyphen liegen.
Oder generell daran, dass Zeichen mehr Nichts als Pixel sind.

[Luky S. (luky)]

Direkt per USB-SPI Bridge aufs Display laden klingt für mich nach einer 
sinnvollen Variante. Der Eve Asset Builder scheint dafür aber ncith das 
richtige Tool zu sein, der erstellt "nur" passende Dateien in einem 
Ausgabeverzeichnis.
Riverdi macht leider auf mich einen nicht wirklich vertrauenserweckenden 
Eindruck. Das Zeug funktioniert so halb, Dokumentation ist mies bzw. 
unvollständig, eine Menge Links führen ins Nichts, der Support ist 
...langsam.

[Rudolph R. (rudolph)]

Im Reiter "Flash Utilities" gibt es 4 Tabs, Flash Image Generator, Flash 
Programmer, Flash Diagnostic und Sample Code.

Das Hermes Board ist inzwischen etwas älter, vielleicht haben die auch 
was neues in der Pipeline.

Richtige Probleme hatte ich mit deren Dokumentation auch nie, was daran 
soll jetzt bitte mies sein?

Ich finde höchstens, dass das Marketing auf der Homepage etwas neben der 
Spur ist.
"Revolutionary communication protocol"? I2C.
"2x Pixel Mode"? Existiert wie beschrieben nicht.

Aber das sind die ersten EVE4 Displays die man tatsächlich auch hier in 
Europa kaufen kann.
Und IPS, Optical Bonding und Hell gefällt mir ganz gut.
Ich würde gerne auch welche von Matrix Orbital kaufen, nur müsste ich 
die direkt bei denen in Kanada ordern, das ist mir dann doch zu krass 
was den Versand angeht.

[Luky S. (luky)]

Welches Interface verwendest du um die "Blobs" auf das Display zu 
bekommen?
Ich finde, das Riverdi eine Menge Marketing-BlaBla auf der Homepage hat, 
aber kaum harte technische Daten und ich glaube dass ich nicht der 
einzige bin, der sich mit den Tools und dem -wie ich finde- etwas 
merkwürdingen Workflow, nicht wirklich zurechtgefunden hat. "Getting 
Started" oder sowas fehlt mir einfach.

[Rudolph R. (rudolph)]

Ich habe ein eve2-usb2spi-kit-a und ein Hermes Board von Riverdi, ich 
benutze aber auch schon mal den Controller um Daten zu kopieren.
Wobei ich hauptsächlich ATSAME51 mit 512k Flash verwende.

Das hier ist die Produkseite von dem RVT43HLBNWC00:
https://riverdi.com/product/eve4-intelligent-display-rvt43hlbnwc00-4-3-inch-projected-capacitive-touch-panel-air-bonding-uxtouch/

Da gibt es das Datenblatt, eine Zeichnung, die Step-Datei, einen Reiter 
"Description" und einen Reiter "Additional Information".
Und es gibt einen Link auf ein "Getting Started":
https://riverdi.com/support/eve4-getting-started/

Das wird unten sogar zum Download als .pdf angeboten.

Was fehlt Dir da denn jetzt noch?

Die Beispiele sind für Riverdis Library: https://github.com/riverdi

Die Library ist soweit ich weiß dicht an dem was FTDI damals zuerst 
veröffentlich hatte und was man immer noch als Output vom EVE Screen 
Designer bekommt.

Das einzige was Riverdi jetzt nicht veröffentlich sind komplette 
Schaltpläne.

Was die Tools angeht, die kommen ja nicht von Riverdi, die sind von 
Bridgetek, früher mal von FTDI.
Die Chips sind ja auch nicht von Riverdi.

Das Repository von Bridgetek ist übrigens hier:
https://github.com/BRTSG-FOSS

Hilfreich ist dann noch der Programming Guide:
https://brtchip.com/wp-content/uploads/2022/12/BRT_AN_033_BT81X-Series-Programming-Guide.pdf

[Torsten (xpuipc)]

Hi Rudolph,

also ich habe jetzt dieses Display: 
https://www.displaymodule.com/products/3-4-480-x-480-transmissive-tft-lcd-rgb?_pos=8&_fid=10ae58c14&_ss=c

Es hat 480x480 sichtbare Pixel und dieses Timing für 60 Hz (die Werte in 
Klammern verstehe ich als soll:

DCLK frequency FCLK              -- (20) -- MHz
Horizontal Sync. Width hpw         (8)  Clock
Horizontal Sync. Back Porch hbp    (56) Clock
Horizontal Sync. Front Porch hfp   (20) Clock
Vertical Sync. Width vs            (10) Line
Vertical Sync. Back Porch vbp      (60) Line
Vertical Sync. Front Porch vfp     (40) Line

Nun die 1000 Dollar Frage....wie komme ich denn nun zu den Werten für 
den EVE, egal was ich "ausprobiere" ich bekomme kein stabiles Bild. Ich 
komme da nicht weiter.

Anbei mein "Code" geht speziell um die H und V Sync Werte...
#if defined (EVE_EVE4_ISFD_3dot4_Inch)
#define Resolution_480x480

#define EVE_HSIZE  (480L)              // THD; Visible horizontal 
resolution (in PCLKs)
#define EVE_VSIZE  (480L)                 // TVD; Visible vertical 
resolution (in lines)
//  Horizonttal
#define EVE_HSYNC0  (8L)                //  THF; Horizontal Front Porch 
(in PCLK cycles)
#define EVE_HSYNC1  (8L + 8L)              //  THF + THP; Horizontal 
Front Porch plus Hsync Pulse width (in PCLK cycles)
#define EVE_HCYCLE   (EVE_HSIZE + EVE_HSYNC0 + EVE_HSYNC1)    //  TH; 
Total length of line (visible and non-visible) (in PCLKs)
#define EVE_HOFFSET  (8L + 8L + 20L)            //  THF + THP + THB; 
Length of non-visible part of line. Must be < TH - THD (in PCLK cycles)

//  Vertical
#define EVE_VCYCLE  (EVE_VSIZE + 8 + 8 + 2 + 2)      //   TV; Total 
number of lines (visible and non-visible) (in lines)
#define EVE_VSYNC0  (40L)                //  TVF; Vertical Front Porch 
(in lines)
#define EVE_VSYNC1  (40L + 10L)              //  TVF + TVP; Vertical 
Front Porch plus Vsync Pulse width (in lines)
#define EVE_VOFFSET  (40L + 10L + 2)            //  TVF + TVP + TVB; 
Number of non-visible lines. Must be < TV - TVD (in lines)


#define EVE_PCLK  (1L)
#define EVE_PCLKPOL  (0L)                //(1L)
#define EVE_SWIZZLE  (0L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_DITHER  (0L)
#define EVE_GEN 4
#define EVE_HAS_CRYSTAL
//#define EVE_PCLK_FREQ  (14500000L)    /* 14.5MHz => 54 Hz value for 
EVE_cmd_pclkfreq */
#define EVE_PCLK_FREQ  (16250000L)    /* 16.25 MHz => 60.5 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (27000000L)    /* 27 MHz => 100 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (22000000L)    /* 22 MHz => 81.75 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (21500000L)    /* 21.5 MHz => 79.5 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (21000000L)    /* 21 MHz => 78.0 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (19000000L)    /* 19 MHz => 70.5 Hz value for 
EVE_cmd_pclkfreq */

Grüße und vielen Dank
Torsten

[Rudolph R. (rudolph)]

Moin,

das Gefummel ist genau der Grund warum ich die Idee aufgegeben habe 
irgendwelche Displays verwenden zu wollen. :-)
Normalerweise sind die Timing-Daten unvollständig und dann könnn sich 
die Hersteller nicht mal darauf einigen wie sie ihre Parameter benennen.

EVE_PCLK_FREQ benutze ich inzwischen anders, aber um nur ein Bild zu 
haben würde ich erstmal nur den normalen Takt benutzen.

Probier mal das hier:

#if defined(EVE_EVE4_ISFD_3dot4_Inch)
#define EVE_HSIZE (480L)
#define EVE_VSIZE (480L)

#define EVE_VSYNC0 (40L)
#define EVE_VSYNC1 (50L)
#define EVE_VOFFSET (110L)
#define EVE_VCYCLE (592L)
#define EVE_HSYNC0 (20L)
#define EVE_HSYNC1 (28L)
#define EVE_HOFFSET (84L)
#define EVE_HCYCLE (566L)
#define EVE_PCLK (4L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 4
#endif

Das ist natürlich auch nur aufgrund der Daten wild geraten.

Bei dem Display bin ich aber nicht sicher ob man nicht auch den SPI da 
dran braucht um den ST7701S zu konfigurieren.
Das sieht auf jeden Fall schwer danach aus, Pins 9, 10, 11 und 12.

Ich habe dann noch gerade das hier gefunden:
https://github.com/moononournation/Arduino_GFX
Das unterstützt wohl generell solche Displays, also mit ST7701S und 
480x480.
Da sind acht "Types" definiert, vom Timing her passt keiner so 100%.
Such mal nach ST7701 in dem Code, da gibt es zum Beispiel 
st7701_type1_init_operations - das sieht aus als wäre da ein ganzer 
Haufen Daten definiert die per SPI geschrieben werden.

[Torsten (xpuipc)]

Super, Danke!...

Ja für den St7701 braucht man wohl ne Ini Sequenz...die schicke ich per 
SPI an den ST7701s (ich habe zwie getrennte SPI, einen für EVE und einen 
eben für den Controller...
Ich habe allerdings keine Ahnung, ob man das überhaupt machen 
muss...also Reset und "Wecken" ist klar...ggf. Stimmen ja die 
Defaultwerte...oder der Hersteller des Displays hat das ja ggf. Schon 
"vorkonfektioniert"...

Normalen Takt, meinst Du über den "Teiler" aus der Tabelle? Wie benutzt 
Du den PCLK_FREQ jetzt? Ich hatte auch den Eindruck das da was nicht 
stimmt...

Grüße und nochmal Danke

Torsten

[Rudolph R. (rudolph)]

Ja, ob man den ST7701 betüddeln muss - keine Ahnung, sowas hatte ich 
noch nicht und das fände ich auch schwer lästig.

Torsten schrieb:
> Normalen Takt, meinst Du über den "Teiler" aus der Tabelle? Wie benutzt
> Du den PCLK_FREQ jetzt? Ich hatte auch den Eindruck das da was nicht
> stimmt...

Na, ohne die zweite PLL.
Mit EVE_PCLK = 4 ergeben sich 18MHz, das sollte erstmal laufen, falls 
denn der Rest der Parameter passt.
EVE_PCLK_FREQ setze ich wenn benötigt jetzt auf einen vorberechneten 
Wert wie er auch in der Tabelle zu finden ist, wenn das definiert ist 
wird REG_PCLK direkt auf 1 gesetzt.
20MHz gibt es in der Tabelle nicht, das müsste 0x8A3 sein.

[Torsten (xpuipc)]

Okay...werde ich ausprobieren und berichten...

Grüße
Torsten

[Torsten (xpuipc)]

Okay,

man muss nur die richtige Init Sequenz für den ST7701 haben dann geht es 
auch, ist natürlich problematisch, wenn der Hersteller des Displays sie 
erstmal auch nicht hat und mir ca. 10 Stück zur Auswahl schickt und 
keine davon geht. Habe dann Sitronic direkt angeschrieben...die sind 
sehr schweigsam dazu...haben aber versucht zu helfen. Da gibt es einen 
undokumentierten Registerbereich...ist wahrscheinlich nur für Hersteller 
gedacht...
Für ggf. hier anderen ST7701 Nutzer. Entscheidend scheinen die sog. GIP 
Werte zu sein, das Timing scheint gar nicht so kritisch zu sein.
Irgendwann nach erneutem Nachfragen hat er mir dann eine aktualisierte 
Sequenz geschickt, ist jetzt auch auf der Webseite...das Display ist 
wirklich hell, crisp, weiter Sichtwinkel und gut.
Ich habe die Werte die Du vorgeschlagen hast genommen...jetzt geht es 
wunderbar mit 70 Hz Wiederholrate mit 20Mhz Pixelclock...

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Vor ein Tagen ist mir das hier aufgefallen:
https://github.com/MatrixOrbital/EVE-Library/blob/main/src/eve/ST7789V.c

Wobei ich weiterhin froh bin, dass mir sowas noch nicht untergekommen 
ist. :-)

[Torsten (xpuipc)]

Rudolph R. schrieb:
> Vor ein Tagen ist mir das hier aufgefallen:
> https://github.com/MatrixOrbital/EVE-Library/blob/main/src/eve/ST7789V.c
>
> Wobei ich weiterhin froh bin, dass mir sowas noch nicht untergekommen
> ist. :-)

Genau so...ich mache das auch mit SPI BitBanging für die 
Initialisierung, da kann man dann jedes SPI Format erzeugen 8 Bit, 9Bit 
und xBit wenn notwendig.
Hier kommt es ja nicht auf Geschwindigkeit an, muss man ja nur einmal 
zum Start machen...

Grüße

[Bernhard B. (berni444)]

Hallo,

ich bin froh hier eine, sogar deutsch sprachige, Community gefunden zu 
haben, die sich mit dem BT8XX beschäftigt.
Ich hab momentan ein Problem und ich denke für euch ist das keines es zu 
lösen.

Zur Hardware:
Riverdi 7" mit EVE4 + eigenes PIC Board.

Ich hab bereits ein großes flash file mit dem EAB erstellt und 
erfolgreich in den externen flash auf dem Riverdi Board geschrieben. 
Erfolgreich deshalb, weil es kein Problem ist eins der darin 
gespeicherten Bilder anzeigen zu lassen. Das funktioniert mit jedem Bild 
soweit gut.
Mein Problem ist nun, dass ich es nicht schaffe mehr als drei Bilder 
gleichzeitig anzeigen zu lassen. Der RAM_G sollte ja eigentlich 1024k 
haben, Meine Bilder im flash haben zusammen über 6000k (es sind aber 
einige hundert). Ich möchte nun einen großen Teil des Displays mit 
Bilder füllen. leider funktioniert das nur bis einer RAM_G Adresse um 
die 50000 und nicht bis 1024000.

Leider verwende ich nicht die Bibliothek von Rudolph, sondern eine 
angepasste von BRT, aber ich denke das Verhalten ist ähnlich.

Hier mein Code:

    Gpu_Hal_WaitCmdfifo_empty(phost);

    Gpu_CoCmd_FlashFast(phost, 0);
    Gpu_CoCmd_Dlstart(phost);

    App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(0));
    Gpu_CoCmd_FlashRead(phost, 0, 5955008, 2240);
    Gpu_CoCmd_SetBitmap(phost, 0, COMPRESSED_RGBA_ASTC_5x5_KHR, 100, 
35);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(400*16, 0));
    App_WrCoCmd_Buffer(phost, END());

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(1));
    Gpu_CoCmd_FlashRead(phost, 2300, 5693888, 46080);
    Gpu_CoCmd_SetBitmap(phost, 2300, COMPRESSED_RGBA_ASTC_5x5_KHR, 180, 
400);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(0, 0));
    App_WrCoCmd_Buffer(phost, END());

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(2));
    Gpu_CoCmd_FlashRead(phost, 49000, 5959488, 1472);
    Gpu_CoCmd_SetBitmap(phost, 49000, COMPRESSED_RGBA_ASTC_5x5_KHR, 65, 
35);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(250*16, 1000));
    App_WrCoCmd_Buffer(phost, END());

Bis hier funktioniert es mit drei Bilder, wird der untere Teil mit 
eingebunden bleibt das Display schwarz oder die Bilder sind zerschossen.

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(2));
    Gpu_CoCmd_FlashRead(phost, 51000, 5959488, 1472);
    Gpu_CoCmd_SetBitmap(phost, 51000, COMPRESSED_RGBA_ASTC_5x5_KHR, 65, 
35);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(250*16, 1000));
    App_WrCoCmd_Buffer(phost, END());

Danach kommt noch das:

    App_WrCoCmd_Buffer(&host, DISPLAY());
    //swap the current display list with the new display list
    Gpu_CoCmd_Swap(&host);
    App_Flush_Co_Buffer(&host);
    Gpu_Hal_WaitCmdfifo_empty(&host);


    /* Close all the opened handles */
    App_Common_Close(&host);

Zuerst dachte ich der RAM_G reicht nicht aus aber laut ESE passen die 
Bilder rein.

Ich hoffe Ihr könnt mir dabei helfen.

Viele Grüßen,
Bernhard

[Walter L. (Gast)]

Hallo,

nach einigem Suchen, denke ich, dass ich hier richtig bin.

Ich habe hier seit gefühlten 100 Jahren ein

FT811CB von THAOYU

liegen, das ich jetzt mal in Betrieb nehmen möchte.

Hat jemand einen "Starter-C-code" oder eine Tipp, woher man ihn bekommen 
kann, damit die ersten Schritte schon mal erledigt sind.

Hat jemand einen  Tipp, woher man Infos über das Teil bekommen kann.


Danke für sachdienliche Hinweise und

VG Walter


P.S.:
IC ist der FT5206.
Auf GitHaub habe ich etwas in C++ gefunden, für mich nicht so schön.
Es geht nicht um  die SPI, die habe ich im Griff....

[Rudolph R. (rudolph)]

Moin,

was in dem Post etwas schwer zu finden war, jetzt so in dem Code 
"versteckt" ohne Code Tags, ist was denn überhaupt passiert.

>Gpu_CoCmd_FlashRead(phost, 51000, 5959488, 1472);

Probier mal die ganzen Gpu_CoCmd_FlashRead() da raus zu ziehen.
Die werden ja nur einmal gebraucht und sicher nicht in die Display-Liste 
eingebaut.
Und das BITMAP_HANDLE wird so auch nicht benötigt, auch wenn das nicht 
direkt falsch ist.
Das BITMAP_HANDLE ist ein Set Einstellungen zum Speichern und wieder 
verwenden, wenn man die Bilder nur einmal anzeigen will kann man das 
auch weg lassen, dann wird durch jedes neue SetBitmap das Default 
Bitmap-Handle verändert.

Gpu_CoCmd_FlashFast(phost, 0);
Gpu_CoCmd_FlashRead(phost, 0, 5955008, 2240);
...

Wobei da noch die Frage ist, was die Funktionen überhaupt machen.
Also ob die Rückgabewerte haben, ob gewartet wird und so.

Gpu_Hal_WaitCmdfifo_empty(phost);
Gpu_CoCmd_Dlstart(phost);
App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
Gpu_CoCmd_SetBitmap(phost, 0, COMPRESSED_RGBA_ASTC_5x5_KHR, 100, 35);
App_WrCoCmd_Buffer(phost, VERTEX2F(400*16, 0));
Gpu_CoCmd_SetBitmap(phost, 2300, COMPRESSED_RGBA_ASTC_5x5_KHR, 180,400);
App_WrCoCmd_Buffer(phost, VERTEX2F(0, 0));
...
App_WrCoCmd_Buffer(phost, END());
...

Boah, das ist die Library wegen der ich meine Library angefangen habe. 
:-)

Und ich weiß ja, dass ich keinen PIC Support in meiner Library habe,
den einzubauen sollte aber eher kein Problem sein.
Ich habe nur keine einzige Platine mit PIC drauf und ich müsste zum 
Programmieren MPLAB-X verwenden.
Und MPLAB-X ist einer der Gründe warum ich nicht mal in Erwägung ziehe 
irgendwelche PICs zu verwenden, vor allem nachdem was Microchip mit den 
ATSAM getrieben hat.

[Bernhard B. (berni444)]

Hallo Rudolph,

vielen Dank für deine Antwort. Ich hab nun deine Bibliothek auch ans 
laufen bekommen. Leider stoße ich nun nur etwas später an die Grenze. 
Jetzt funktionieren zumindest schon 7 Bilder je ca. 240x180px.

Ich lade nach dem initialisieren alle Bilder in das RAM_G, danach werden 
die Bilder aufgerufen. Momentan nur einmal beim initialisieren. Ich 
versuche die 7" mit mehreren kleineren Bilder zu füllen.

Hier der Code:

  // Switch Flash to FULL Mode 
  EVE_init_flash();                         // also does a flash_attach() !  
  
    EVE_cmd_flashread( EVE_RAM_G, 4288, 29184 ); 
    EVE_cmd_flashread( (EVE_RAM_G+29184), 33472, 28416 ); 
    EVE_cmd_flashread( (EVE_RAM_G+57600), 61888, 28416 ); 
    EVE_cmd_flashread( (EVE_RAM_G+86016), 90304, 27456 ); 
    EVE_cmd_flashread( (EVE_RAM_G+113472), 117760, 25600 ); 
    EVE_cmd_flashread( (EVE_RAM_G+139072), 143360, 24832 ); 
    EVE_cmd_flashread( (EVE_RAM_G+163904), 168192, 27264 ); 
//    EVE_cmd_flashread( (EVE_RAM_G+191168), 195456, 31488 ); 

  // *** begin of the display list *********************************************
  
  EVE_cmd_dl( CMD_DLSTART );                // start a new display-list
  EVE_cmd_dl( CLEAR( 1, 1, 1 ) );               // clear the display
  
  // *** displays an image loaded from Flash ***********************************
  // Bild1
  EVE_cmd_setbitmap( EVE_RAM_G, COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 190 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 0, 0 ) );
  // Bild2
  EVE_cmd_setbitmap( (EVE_RAM_G+29184), COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 185 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 4180, 0 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+57600), COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 185 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 0, 4180 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+86016), COMPRESSED_RGBA_ASTC_5x5_KHR, 245, 175 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 4180, 4180 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+113472), COMPRESSED_RGBA_ASTC_5x5_KHR, 235, 170 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 8180, 0 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+139072), COMPRESSED_RGBA_ASTC_5x5_KHR, 235, 165 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 8180, 4180 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+163904), COMPRESSED_RGBA_ASTC_5x5_KHR, 230, 185 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 12180, 4180 ) );
//    
//  EVE_cmd_setbitmap( (EVE_RAM_G+191168), COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 205 );
//  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
//  EVE_cmd_dl( VERTEX2F( 12180, 0 ) );
  // *** displays an image loaded from Flash ***********************************
  
  // *** end of the display list ***********************************************
  EVE_cmd_dl( END() );
  EVE_cmd_dl( DISPLAY() );
  EVE_cmd_dl( CMD_SWAP );                   // tell EVE to use the new display list
//  EVE_execute_cmd();

7 Bilder gehen noch beim 8. bleibt das Display schwarz.
Außerdem bleibt die Funktion EVE_execute_cmd(); hängen, darum ist sieh 
hier auskommentiert. Leider hab ich noch nicht verstanden, was diese 
genau macht.

[Rudolph R. (rudolph)]

Walter L. schrieb:
> Hat jemand einen "Starter-C-code" oder eine Tipp, woher man ihn bekommen
> kann, damit die ersten Schritte schon mal erledigt sind.

Schau mal in meine Library, da sind auch Beispiele dabei,
die Frage wäre nur für welchen Controller und ob Arduino oder nicht.

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

Walter L. schrieb:
> IC ist der FT5206.

Das ist "nur" der Touch-Controller, der Grafik-Chip selber ist ein 
FT811.
Die Dokumentation ist hier:
https://brtchip.com/documents-type/data-sheets/

[Rudolph R. (rudolph)]

Bernhard B. schrieb:
> Ich hab nun deine Bibliothek auch ans laufen bekommen.

Tendenziell hätte ich ja schon Interesse an dem PIC Code um
den für andere zu integrieren. :-)

Ansonsten fällt mir gerade nichts auf das nicht funktionieren sollte.
Es gibt schon noch andere Limits wie die 4kiB im RAM_CMD und die 8kiB in 
der Display-Liste, davon ist das bisschen Code aber sicher noch ganz 
weit weg.

Bernhard B. schrieb:
> Außerdem bleibt die Funktion EVE_execute_cmd(); hängen, darum ist sieh
> hier auskommentiert. Leider hab ich noch nicht verstanden, was diese
> genau macht.

Die wartet eigentlich nur darauf das alle Kommandos im RAM_CMD 
abgearbeitet sind, das sollte so nicht hängen bleiben können.

Lies ein paar ms nach dem CMD_SWAP mal das RAM_ERR_REPORT aus,
siehe Kapitel "5.7 Coprocessor Faults" im Programming Guide.
Vielleicht steckt der Fehler auch in den Bildern.

Anderes Experiment, lad doch mal die ersten paar Bilder die 
funktionieren mehrmals in RAM_G.

Ich hole gleich mal mein RVT70HSBNWC00-B raus und probiere das aus,
das schwierigste dabei wird sein Bilder zu finden, zu konvertieren und 
in das Flash zu brennen.

[Walter L. (Gast)]

Hallo Rudolph,

danke für die INFOs; mit denen komme ich wohl zurecht.

>die Frage wäre nur für welchen Controller und ob Arduino oder nicht

TMSP320F28069 oder MSP430FRxxx.

VG Walter

[Bernhard B. (berni444)]

Hallo Rudolph,

Danke für deine Unterstützung.

Momentan sieht es so aus, dass der CAN Bootloader vom PIC schuld daran 
ist und das mit den Bildern nur eine falsche Fährte war. Scheinbar 
überschreitet das Programm eine gewisse Größe und überschreibt damit die 
Checksumme oder sorgt dafür, dass die Berechnung nicht mehr richtig 
funktioniert. Beim einfügen mehrerer Bilder trat dass dann auf und 
führte dazu, dass der Bootloader die Anwendung garnicht erst startet 
(das war mir die ganze zeit nicht aufgefallen). Mit der Zeile 
EVE_execute_cmd() verhielt es sich scheinbar genauso.

Zum PIC Code, ich möchte die Anwendung noch optimieren und testen, 
außerdem hab ich noch Bilder verwendet, die nicht mir gehören. Das 
möchte ich noch geradeziehen, dann kann ich dir das gerne zuschicken.

Gruß,
Bernhard

[Rudolph R. (rudolph)]

Walter L. schrieb:
>>die Frage wäre nur für welchen Controller und ob Arduino oder nicht
>
> TMSP320F28069 oder MSP430FRxxx.

Jetzt gehts los. :-)
Ist heute Tag der Controller Challenge? :-)

https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_TMS320C28XX.h
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_MSP432.h

Die beiden sind ja vorhanden, wobei ich bei beiden nicht sicher bin wie 
gut die funktionieren, weil ich beide Controller noch nicht auf dem 
Tisch hatte.

Aber da kann man bestimmt drauf aufbauen, die Peripherie sollte ja 
ähnlich sein.
Und wenn man eine neue EVE_target...h macht, dann muss man die noch in 
der EVE_target.h eintragen.

Der TMS320 war seltsam, kennt beine Bytes und ich meine der SPI kann 
auch kein DMA, DMA wäre wohl möglich gewesen mit einem UART im SPI Mode, 
oder so ähnlich, ist eine Weile her das ich mir das angesehen habe.

[Rudolph R. (rudolph)]

Bernhard B. schrieb:
> Momentan sieht es so aus, dass der CAN Bootloader vom PIC schuld daran
> ist und das mit den Bildern nur eine falsche Fährte war. Scheinbar
> überschreitet das Programm eine gewisse Größe und überschreibt damit die
> Checksumme oder sorgt dafür, dass die Berechnung nicht mehr richtig
> funktioniert.

Das muss dann aber schon sehr knapp am Limit sein, die paar Zeilen
kosten doch erstmal nicht viel.

Bernhard B. schrieb:
> Zum PIC Code, ich möchte die Anwendung noch optimieren und testen,
> außerdem hab ich noch Bilder verwendet, die nicht mir gehören. Das
> möchte ich noch geradeziehen, dann kann ich dir das gerne zuschicken.

Klingt gut, wobei ich die Bilder ja eher nicht brauche. :-)

Mein 7" läuft gerade, jetzt mal ein paar Pixel für einen Test aus dem 
Netz fischen. :-)

[Rudolph R. (rudolph)]

Bernhard B. schrieb:
> EVE_cmd_setbitmap( EVE_RAM_G, COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 190 );

Detail am Rande, welche Version ist das?
Ich musste gerade nachschauen, im Dezember 2022 habe ich das auf
EVE_ASTC_5X5 geändert.

[Rudolph R. (rudolph)]

So, ich habe einen Satz Bilder auf 240xwhatever konvertiert, die auf 
ASTC 5x5 konvertiert, ein Flash-Image erstellt, das ins Flash gebrannt.
Wobei ich noch ein Downgrade auf EAB 2.8 machen musste, der EAB 2.9 ist 
ganz schön kaputt.

Jetzt kopiere ich gerade beim Start 12 Stück davon in RAM_G und lasse 50 
Mal pro Sekunde eine Diplay-Liste erstellen die per DMA über den SPI 
geschoben wird.
So zusätzlich in dem Code meines einfachen Beispiel-Codes.

In dem ATSAME51 der an meinem RVT70HSBNWC00-B hängt sind
das insgesamt 20068 Bytes Programm-Speicher, wobei 3597 Bytes für die 
beiden Bilder in dem Beispiel-Code sind.
Das Projekt verwendet keinen Bootloader.

Im Ergebnis sind das 480 Bytes die per Display-Update über den SPI 
verschickt werden und das ergibt eine Display-Liste von 1360 Bytes.

Da ginge noch viel mehr, aber die 1024x600 sind schon gut mit Pixeln 
gefüllt.

#define SPACE22 0UL
#define SPACE01 20736UL
#define SPACE02 41472UL
#define SPACE03 66048UL
#define SPACE04 86784UL
#define SPACE05 111360UL
#define SPACE06 135936UL
#define SPACE07 158976UL
#define SPACE08 179712UL
#define SPACE09 203520UL
#define SPACE10 228096UL
#define SPACE11 262656UL

if (E_OK == EVE_init_flash())
{
    EVE_cmd_flashread(SPACE22, 4096, 20736);
    EVE_cmd_flashread(SPACE01, 24832, 20736);
    EVE_cmd_flashread(SPACE02, 45568, 24576);
    EVE_cmd_flashread(SPACE03, 70144, 20736);
    EVE_cmd_flashread(SPACE04, 90880, 24576);
    EVE_cmd_flashread(SPACE05, 115456, 24576);
    EVE_cmd_flashread(SPACE06, 140032, 23040);
    EVE_cmd_flashread(SPACE07, 163072, 20736);
    EVE_cmd_flashread(SPACE08, 183808, 23808);
    EVE_cmd_flashread(SPACE09, 207616, 24576);
    EVE_cmd_flashread(SPACE10, 232192, 34560);
    EVE_cmd_flashread(SPACE11, 266752, 24576);
}

Tendenziell bevorzuge ich ASTC 8x8, das ist noch mal deutlich kleiner 
und von der Qualität auch noch recht gut.
Bei der Pixel-Dichte von fast 7 RGB Pixel pro mm fallen 
Komressions-Artefakte auch gar nicht so leicht auf.

Oh ja, und ich verwende den aktuellen Stand meiner Library, also nicht 
den Release 5.0.6 vom Mai, den ganz aktuellen Stand.

[Walter L. (Gast)]

Hallo,

ich möchte nochmal rückfragen.

Oben im Bild bei P1 (PINs nicht bezeichnet) liegt der FT5206, ein cap. 
touch controller.
Auf der Rückseite des PCB liegt der FT811 (hab ich kontrolliert).
Der FT811 kann auch cap. touch.

Beide IC's können also cap. touch.

Frage: Warum 2 cap. touch IC's?

Die PIN-Belegung des P1 ist offensichtlich (habe durchgekligelt) vom 
quad. PIN aus gezählt

1  5V,

2  5V,

3   SSEL/SCL PIN22 vom FT5206,

4   MOSI/SDA PIN24 vom FT5206,

5   WAKE PIN27 vom FT5206,

6   INT PIN28 vom FT5206,

7   weiß nicht, geht wahrscheinlich auf die BASIS/GATE eines 
Transistors.


Frage: Kennt jemand die Bedeutung (was macht man damit)?

Frage: Benutzt jemand das Display (nur Display, oder Display und cap. 
Touch)?

Danke für Antworten.

VG Walter

[Rudolph R. (rudolph)]

Der FT811 benutzt den FT5206 als Touch-Sensor per I2C.
Die FT8xx / BT8xx kümmern sich auch um den Touch, man kann zwar auch die 
Koordinaten raus lesen, am einfachsten ist allerdings einem Objekt per 
TAG eine Nummer zuzuweisen und die Touch-Events auszulesen.
Gibt man etwa einem Button die Nummer 10, dann steht im Register 
REG_TOUCH_TAG die 10 wenn man den Button auf dem Bildschirm berührt.
Man muss also nicht selber nachrechnen ob Touch Koordinaten vielleicht 
zu einem Objekt auf dem Bildschirm gehören könnten.
Man kann sogar einer ganzen Gruppe von Objekten einen TAG zuordnen, etwa 
wenn man sich eigene Buttons erstellt mit einem Bild und darüber 
liegendem Text.

FT810, FT812, BT816 und BT818 sind für Resistiv-Touch.
FT811, FT813, BT815 und BT817 sind für Kapazitiv-Touch.

Resistiv-Touch ist als passive Matrix ausgelegt und braucht vier Analaog 
Anschlüsse.
Kapazitiv-Touch braucht eine ganze Menge Anschlüsse und von daher 
dürften die meisten Panels mit integriertem Rasterizer für 
Kapazitiv-Touch den Sensor gleich integriert haben, normalerweise als 
Schaltung auf dem Folien-Leiter.

[Walter L. (Gast)]

Rudolph, danke.

Kommt wohl ne Menge Arbeit....

VG Walter

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Bescheidene Frage:
Ein simples Symbol mit homogen (weis) Hintergrund soll dargestellt 
werden (siehe Anhang, Beispiel). Dieses Weis des Bildes ist ja quasi der 
Bereich, wo eben nichts ist.
Definiere ich VOR dem Platzieren des Bildes eine Farbe, erscheint das 
Zahnrad mit dem Hintergrund dieser Farbe. Habe ich einen homogenen 
Bildschirm und ich möchte, dass man NUR das Zahnrad sieht und nicht ein 
(farbiges) Rechteck mit Zahnrad darin, so definiere ich zuvor die 
Hintergrundfarbe des Bildschirms und setzte dann das Bitmap. Zahnrad 
erscheint als reines Zahnrad. So weit so gut. Nun habe ich aber einen 
nicht homogenen Hintergrund (z.B. mit CMD_GRADIENT ... einen 
Farbverlauf). Da geht das sooo ja nicht. Warum (oder wie kann man) 
diesen Hintergrund des Bitmap undurchlässig machen, so dass der 
Farbverlauf an dieser Stelle des Bitmap erhalten bleibt und auch hier 
NJUR das Zahnrad zu sehen ist? Geht das?

[Rudolph R. (rudolph)]

Das Bild hat zwar ARGB1555 im Namen, das hat aber dem Alpha-Channel 
überhaupt nicht gesetzt und ist somit auch nicht transparent.

Ok, die Foren-Software vermurkst die Bilder auch gerne mal durch eine 
automatische Konvertierung.
Ich habe Dein Bild gerade mit Paint.net kurz bearbeitet und einen Teil 
transparent gemacht, das Ergebnis ist in dem .zip damit die 
Foren-Software da nicht direkt ran kommt.

Und dann habe ich beide Bilder in den EVE Screen Editor gezogen.
Beide im Format ARGB1555
Dazu noch ein Gradient.

CLEAR(1, 1, 1)

CMD_GRADIENT(158, 109, 0xFF0000, 215, 264, 0x0000FF)

BITMAP_HANDLE(0)
CMD_SETBITMAP(0, ARGB1555, 120, 120)
BEGIN(BITMAPS)
VERTEX2F(3680, 1424)
END()
BITMAP_HANDLE(1)
CMD_SETBITMAP(28800, ARGB1555, 120, 120)
BEGIN(BITMAPS)
VERTEX2F(1840, 3280)
END()

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

so ist es. Es war auch nur ein Beispiel-Bild (vom Kunden vorgegeben). 
Aber Du hast Recht, man kann das Problem nicht mit dem Grafik-Treiber 
lösen, sondern nur mit dem Bild selbst. Habe mal ein paar eigene Bilder 
entworfen, wo ich gleich von vornherein auf Paint den Hintergrund als 
transparent gesetzt habe. Funktioniert einwandfrei. Sorry - hatte mich 
noch nie tiefer mit Paint & Co. beschäftigt, außer den Zeichenbereich zu 
verändern, um die Kunden-Bilder entsprechend anzupassen ... Also vielen 
Dank für die Hilfe.

[Rudolph R. (rudolph)]

There are 12.1" modules with BT817 from Riverdi now like the 
RVT121HVBNWC00-B.
Has anyone already tried these?

[Luky S. (luky)]

Ich habe immer noch eine grundsätzliche Frage, die mal wieder 
hochgekommen ist: ich brauche für jemand anderen ein möglichst simples 
Arduino Programm ohne PlatformIO o.Ä., ganz normal mit der Arduino-IDE 
(die kennt sie...) um mit einem UNO und dem Riverdi Shield ein Riverdi 
RVT50 anzusteuern. Die Anwendung ist eigendlich sehr simpel. Es soll ein 
kleines Bild angezeigt werden, zwei große Buttons mitten auf dem 
Bildschirm, die auf Touch reagieren (dann wird der jeweilige Ausgang 
geschaltet und der Text auf dem Display umgeschaltet) und dann sollen 
noch 4 Messwerte 0..10V angezeigt werden.
Jetzt ist die Frage was die simplste Vorgehensweise ist. Das Bild wäre 
vermutlich am einfachsten im AVR Flash abzulegen, oder? Zumindest vor 
ein paar Jahren mit einem kleineren EVE1 Display ging das recht einfach, 
das Programm von damals läuft aber nicht mehr auf dem EVE4

[Rudolph R. (rudolph)]

Also so schwierig ist das nicht mit PlatformIO, im Gegenteil hat das 
eigentlich nur Vorteile, zum Beispiel kann man in der Arduino IDE keine 
Projekt-Defines setzen.

Wie auch immer, man kann meine Library auch mit der Arduino IDE 
verwenden, ich habe mal was ich im Laufwerk liegen hatte auf den 
aktuellen Stand der Dateien gebracht und angehängt.
Die größte Herausforderung das mit der Arduino IDE zu kompilieren 
bestand darin das ich die 2.x installiert und eine Weile nicht verwendet 
habe, das hat einen Moment gebraucht um sich zu aktualisieren.

In der EVE_config.h ist das Display eingestellt, normalerweise mache ich 
das über die platformio.ini und es gibt eben keine Projekt-Datei für 
Arduino.
Ich kann nicht sagen ob das wirklich läuft da ich das nicht extra 
nochmal ausprobiert habe, aber es kompiliert auf jeden Fall für UNO R3, 
UNO R4, ESP32 und "Generic STM32F4 series".
Die Pins für die Targets sind in den Dateien im EVE_target Verzeichnis 
definiert, die zeigt die Arduino IDE nicht direkt mit an, für den Editor 
gibt es die nicht, beim Kompilieren werden die aber benutzt.
Da muss man dann eventuell noch mal mit einem extra Editor die 
Einstellungen für das gewünschte Target prüfen.

Der eigentliche Code ist in der tft.c, wenn das so grundsätzlich läuft 
kann man das ja nach Belieben anpassen.

[Christoph M. (mchris)]

Könnte Deine Library das CYD unterstützen?
Beitrag "Cheap Yellow Display"

[Rudolph R. (rudolph)]

Christoph M. schrieb:
> Könnte Deine Library das CYD unterstützen?

Nein, das ist von der Technik her was völlig anderes, so ziemlich die 
einzige Gemeinsamkeit zwischen einem ILI9341 und einem FT81x / BT81x ist 
das die SPI verwenden.

[Luky S. (luky)]

Danke @Rudolph, werde ich am Abend gleich mal ausprobieren!
Noch eine Frage: wenn ich jetzt doch größere Bilder oder als Gag gar ein 
Filmchen aus dem eingebauten Flash abspielen will, wie bekomme ich die 
am einfachsten dort hinein? Riverdi beschreibt zwar den extra 
Programmüberanschluss fur den Speicher (ein TagConnect TC2050-IDC-NL) 
aber ohne weitere Infos. Hat das schon mal jemand verwendet?

[Rudolph R. (rudolph)]

Der EVE Asset Builder kann per USB/SPI Adapter durch den EVE Chip den 
externen Flash beschreiben.
Unterstützt werden dabei "FT4222", "MPSSE" und "Raspberry Pi Pico".

Die Software für den Pi-Pi-Co ist hier: 
https://github.com/Bridgetek/pico-brteve

MPSSE wäre sowas:
https://riverdi.com/de/blog/hermes-board-spi-usb-brueckenboard (ist 
meine ich eingestellt)
https://www.matrixorbital.com/interface-module/eve2-usb2spi-kit-a
https://www.matrixorbital.com/interface-module/eve-usb2spi-kit-b

Das Hermes und das EVE2-USB2SPI-KIT-A habe ich hier, das 
EVE-USB2SPI-KIT-B habe ich noch nirgendwo konkret zu kaufen gefunden.

Was ich aber auch gerne mache ist das Flash über mein Programm zu 
beschreiben, das hat vor allem den Vorteil das ich dafür nicht umstecken 
muss, die FFC Kabel sind nicht gerade auf Steckzyklen ausgelegt.
Der Nachteil ist, erstmal muss der Controller das Flash-Image speichern, 
da bietet sich aber zum Beispiel ein ESP32 an, und dann benutze ich 
CMD_FLASHUPDATE was über RAM_G läuft, das Flash-Image darf also entpackt 
nicht größer sein als 1MB.
Schau mal nach "TEST_UTF8" in der TFT.c, das Image dazu ist in der 
tft_data.c.

[Luky S. (luky)]

Ich bin ja aktuell leider auf den UNO beschränkt. Da bringt es mir dann 
eh keinen Vorteil, das Bild zuerst in den Flash vom EVE zu laden, oder? 
Also wenn ich mit dem Speicher vom AVR auskommen muss/will?

Anscheinend kann das STM32 Evalboard von Riverdi auch als Bridge 
konfiguriert werden, das könnte ich mir aus ausborgen.

[Rudolph R. (rudolph)]

Nun ja, kommt erstmal darauf an wie groß das Bild ist, ich empfehle für 
die BT81x auf jeden Fall ASTC und 8x8 liefert dabei eine gute Qualität 
bei nur 2 Bits pro Pixel.
Der nächste Schritt ist das mit EAB zu komprimieren, bzw. wenn das nur 
ein Bild ist kann man das gleich im Bild-Konverter machen.

Wenn dabei nur ein paar kiB raus und das Programm noch lange nicht die 
30kiB überschreitet, klar, kann man einfach im Programm lassen und 
jedesmal beim Start ins RAM_G laden.
Wenn das Bild oder die Bilder den Platz im Controller sprengen, dann 
kann man ein eigenes Programm dafür machen, das einmal ins Flash 
abkippen und dann mit dem eigentlichen Programm von da nutzen.

An dem Beispiel hängt zwar ein 7kiB Flash-Image für einen Font in 
tft_data.c, solange das nicht verwendet wird taucht das im eigentlichen 
Programm aber nicht auf.

In meinem aktuellen Projekt spiele ich gerade mit Icons aus Googles 
Material Icons Set, bei 64x64 Pixel und ASTC 8x8 sind das 1024 Bytes pro 
Bild.
Mein _iconlibrary.astc für den Test hat gerade 29kiB und als 
_iconlibrary.zopfli sind das 7262 Bytes.
Das könnte ich jetzt in das Flash-Image werfen, der ATSAME51 Controller 
den ich verwende hat aber ohnehin 512kiB Flash und ich weiß gerade weder 
welche Icons ich dann am Ende benutzen werde, noch stört mich gerade das 
die Start-Zeit ein paar ms länger ist als sie sein könnte.

Oh ja, aus Erfahrung kann ich nur dazu raten das Anzeigen von irgendwas 
direkt aus dem Flash nur sehr sparsam zu benutzen, sei es Zeichensätze 
oder Bilder.
Bei Auflösungen von 800x480 oder höher, also wenn die Pixel-Engine recht 
wenig Zeit hat die Bildzeilen zusammen zu basteln, wirkt sich zunehmend 
die zwar recht hohe aber am Ende doch begrenzte Bandbreite vom externen 
Flash aus, gerade größere Fonts sind ein Problem, zum einen sind das ja 
auch nur Bilder, zum anderen ist der wahlfreie Zugriff auf das Flash 
ganz gut mit Overhead behaftet.
Also Best Practice ist das RAM_G möglichst voll auszureizen, man kann ja 
auch beim Programmstart vom externen Flash ins RAM_G kopieren lassen.
Mit ASTC 8x8 bekommt man das RAM_G auch lange nicht so schnell voll.

[Luky S. (luky)]

Whow! Danke!
Eine Frage stellt sich mir aber noch: Wie gehe ich mit den "extended" 
Bitmapformaten EVE_ASTC_8X8 etc. um? Muss man da was besonderes 
beachten?
Ich habe hier ein Bild, das im ASTC_8X8 Format 32640 Bytes groß ist

[Luky S. (luky)]

Und noch zwei damit zusammenhängende Fragen: Der Eve Asset Builder wirft 
für die umgewandelten Bilder ja leider eine recht unübersichtliche Datei 
.binh aus (alles Deimalzahlen, keine Zeilenumbrüch etc.). Gibt es noch 
eine andere Ausgabe oder einen Trick, um die Zahlenkolonne einfach in 
eine ansprechendere Form zu bringen?
Und gibt es einen speziellen grund wieso im Beispiel die memory-map 
defines an diesen Stellen liegen? Bzw. genauer gesagt warum wird nicht 
bei 0x000000 gestartet?

[Rudolph R. (rudolph)]

Luky S. schrieb:
> Eine Frage stellt sich mir aber noch: Wie gehe ich mit den "extended"
> Bitmapformaten EVE_ASTC_8X8 etc. um? Muss man da was besonderes
> beachten?
> Ich habe hier ein Bild, das im ASTC_8X8 Format 32640 Bytes groß ist

Nö, da gibt es nicht wirklich was besonderes, anzeigen wie andere Bilder 
auch, z.B. EVE_cmd_setbitmap(ICON_ACCESS_ALARM, EVE_ASTC_8X8, 64U, 64U);
Und was man sonst noch so braucht aber nicht anders ist. :-)

Das sind eine ganze Menge Pixel und in den alten Formaten wären das so 
260kiB.
Also ich würde das auf jedem Fall in das RAM_G legen.
Für wie das da landet gibt es ein paar Optionen:

a) Einfach so aus dem Controller heraus: EVE_memWrite_flash_buffer()
b) Erst in EAB durch den "Asset Compressor" schicken, das in den 
Controller legen und dann EVE_cmd_inflate() benutzen
c) Das ins Flash schreiben und EVE_cmd_flashread() benutzen
d) Das packen, ins Flash schreiben und EVE_cmd_inflate2() benutzen

Die .rawh vom Bilder-Umwandeln werfe ich immer weg, keine Ahnung für was 
die gut sein soll, die .astc, die .json und und _converted.png lösche 
ich auch immer.
Das "BIN2C" Modul im EAB erzeugt ordentliche Arrays und lässt sich auch 
noch konfigurieren.

[Luky S. (luky)]

Was machen in deinem Code eigentlich

SPI.endTransaction();
SPI.beginTransaction(SPISettings(8UL * 1000000UL, MSBFIRST, SPI_MODE0));
SPI.endTransaction();
SPI.beginTransaction(SPISettings(16UL * 1000000UL, MSBFIRST, SPI_MODE0));

nach TFT_init();
?

[Rudolph R. (rudolph)]

Ich gebe es zu, diese Makro Wüste ist etwas hässlich geworden, aber das 
Beispiel baut für und läuft auf einer ganzen Liste unterschiedlicher 
Arduinos.

Das SPI.endTransaction(); gibt den SPI frei und 
SPI.beginTransaction(SPISettings(8UL * 1000000UL, MSBFIRST, SPI_MODE0)); 
konfiguriert den dann wieder neu.

Das TFT_init(); läuft in dem Beispiel mit dem SPI auf 1MHz.
Und dann wird der Takt hoch gedreht.

Der Hintergrund ist das der SPI Takt für das Init der EVE Chips unter 
11MHz sein muss.

Nochmal so drüber nachgedacht ist das vermutlich albern komplex für den 
Beispiel Code, ist etwas gewachsen mit den verschiedenen Optionen.
Auf 8MHz einstellen und fertig wäre auch eine Option.
Das zeigt aber auch, dass die Kontrolle über den SPI Takt nicht in 
meiner Library vergraben ist, wenn man mehr als ein Device am SPI muss 
man ja vielleicht sogar zwischen den Transfers den Takt und/oder den 
Mode umschalten.

[Luky S. (luky)]

War nur etwas verwirrt, weil die SPI zuerst auf 8MHz gestellt wird, dann 
nochmal auf 8Mhz und sofort auf dann 16MHz.

Darf ich fragen wie die Memory Map aussehen soll? Wie viel Speicher (von 
- bis) kann man da jetzt wirklich verwenden und was ist der Startpunkt? 
Im Programming Manual ist auch erwähnt, das es gewisse Einschränkungen 
beim Alignment geben soll?
Warum wird nicht bei 0x00000000 gestartet?

/* memory-map defines */
#define MEM_FONT 0x000f7e00 /* the .xfont file for the UTF-8 font is copied here */
#define MEM_LOGO 0x000f8000 /* start-address of logo, needs 6272 bytes of memory */
#define MEM_PIC1 0x000fa000 /* start of 100x100 pixel test image, ARGB565, needs 20000 bytes of memory */

[Rudolph R. (rudolph)]

Luky S. schrieb:
> War nur etwas verwirrt, weil die SPI zuerst auf 8MHz gestellt wird, dann
> nochmal auf 8Mhz und sofort auf dann 16MHz.

Nee, das wird erst auf 1MHz und dann entweder auf 8, 16, 20 oder 16 MHz 
eingestellt.
Wie ich schrieb, für das Beispiel-Programm ist das inzwischen 
übertrieben kompliziert.

> Darf ich fragen wie die Memory Map aussehen soll?

Wie Du meinst.

> Wie viel Speicher (von
> - bis) kann man da jetzt wirklich verwenden und was ist der Startpunkt?

Das RAM_G geht von 0 bis 0xfffff.

> Im Programming Manual ist auch erwähnt, das es gewisse Einschränkungen
> beim Alignment geben soll?

Ja, je nachdem was man macht, z.B. wenn man Bilder aus dem Flash 
anzeigen möchte, dann müssen die 32 Byte aligned abgelegt sein.

> Warum wird nicht bei 0x00000000 gestartet?

Kein besonderer Grund, ich habe in dem Beispiel nur von oben angefangen 
um zusätzliche Dinge wie Zeichensätze spontan auf 0x0000 werfen zu 
können.

>

> /* memory-map defines */
> #define MEM_FONT 0x000f7e00 /* the .xfont file for the UTF-8 font is 
> copied here */
> #define MEM_LOGO 0x000f8000 /* start-address of logo, needs 6272 bytes 
> of memory */
> #define MEM_PIC1 0x000fa000 /* start of 100x100 pixel test image, 
> ARGB565, needs 20000 bytes of memory */
>

Da folgt auch noch MEM_DL_STATIC.

In meinem aktuellen Projekt habe ich:
#define MEM_ICON_BASE 0x000f0000UL
Für 55 Icons in ASTC 8x8 mit 64x64 Pixel.
Aber ich habe noch keine Idee ob ich überhaupt 55 Icons brauche.
Das ist gefolgt von sechs Bereichen für .xfont Daten.
Aktuell sieht es aber danach aus das ich die .glyph Daten der 
Zeichensätze auch noch nach RAM_G verschieben muss.

[Luky S. (luky)]

Danke nochmals für deine Library und deine Hilfe Rudolph!
Der Speicher im Arduino ist mir leider zu knapp geworden - aber ich 
bekomme heute vielleicht noch das Riverdi STM32 Evaluation Board von 
einem Arbeitskollegen und kann dann am Abend weiterspielen. Das Board 
hat ja u.A. eine USB FT232H Bridge und damit sollte man ja den Flash auf 
dem Display direkt bespielen können. Das scheint mir für meine 
einzellösung die einfachste Variante zu sein, 1x umstecken wird das 
Kabel schon noch aushalten.
Was mir aber noch nicht klar ist: Wenn ich die Bilder (und eventuell 
auch 2 Fonts) in den Flash gespielt habe, wie genau kann ich sie dann 
anzeigen bzw die Fonts verwenden lassen? Irgendwelche Empfehlungen für 
die zu verwendenden Formate?

[Rudolph R. (rudolph)]

Wie man einen Zeichensatz aus dem Flash benutzt ist in meinem Beispiel 
drin.
Erstmal muss alles was aus dem Flash angezeigt werden soll im ASTC 
Format sein.
Also für den Font eben "Extended Format" und da am besten auf 8x8 
umstellen.
Die .glyph enthält die ganzen Bilder, die .xfont die 
Verwaltungsinformationen.
Die Adresse im Font-Converter ist quasi egal, wenn man in den "Flash 
Utilities" die .glyph und die .xfont für einen Font verwendet, dann wird 
die Adresse in der .xfont darauf angepasst wo die .glyph landet.
Um das Alignement kümmert sich das auch.

Um einen Font zu benutzen muss man die .font nach RAM_G kopieren:
EVE_cmd_flashread(MEM_FONT_28, 38464, 320);
Dann noch mit CMD_SETFONT2 benutzen:
EVE_cmd_setfont2(18,MEM_FONT_28,32);

Wenn man einen Font ins Flash gelegt hat und aus dem RAM_G benutzen 
will, dann wird es minimal komplizierter.
Dann muss man nämlich die Adresse der .glyph Daten in .xfont im RAM_G 
schreiben.

Bei Bildern braucht man die .raw Dateien die aus dem Converter fallen, 
nicht etwa die .astc.
Der Unterschied ist, die .astc hat noch einen 16 Byte Header.
Da kümmert EAB auch um das Alignment, das muss 32 Byte sein.

Beim Anzeigen von Bildern aus dem Flash wird es etwas seltsam,
die Adresse ist nämlich in Blöcken von 32 anzugeben mit dem obersten Bit 
der 24 Bit Adresse gesetzt:
EVE_cmd_setbitmap_burst(0x800000 | (4096/32), EVE_ASTC_8x8, 64, 64);

Siehe auch hier:
https://github.com/RudolphRiedel/FT800-FT813/discussions/116

[Rudolph R. (rudolph)]

So, in less than two weeks the BT822 is launched at the Embedded World 
2024 North America.

What little information I have so far is what I gathered from published 
pictures and this article: 
https://brtchip.com/discover-bt822-next-evolution-bridgetek-5th-gen-eve/

- two channel LVDS TX for displays with up to 1920 x 1200
- two channel LVDS RX for Video input up to 1920 x 1200
- "Embedded 1Gbit DDR3L SDRAM" - so 128MB of RAM
- "Advanced EVE with Frame Buffer support for High Resolution HMI"
- 16kiB display list
- SD card support
- Audio is stereo now and output is by I2S
- integrated Watchdog timer
- enhanced touch engine
- live video feed
- both resistive and capacive touch support in one chip
- clock source is a 38.4MHz crystal

And yet Bridgetek wrote: "Despite the frame buffer inside, we've 
retained the same features that made EVE so good and the screens are 
still created using the command/display lists etc. The frame buffer 
combined with the 16K RAM_DL will help with the more complex user 
interfaces without underrun etc. but from the application side it will 
still feel very familiar."

What I take away from this:
The changes to EVE5 are probably even bigger than between EVE1 and EVE2, 
so I probably will support BT822 with a new library instead of trying to 
fit EVE5 support into my current library.

I expect the API will move away from 22 bit adressing to 29 or 30 bit 
adressing and of course the memory map will be completely different.
I also wouldn't be surprised if RAM_CMD is doubled as well.

And I wonder what all the SDRAM is supposed to be used for.
A frame buffer for 1920x1200 would take 9MiB and there are likeley two 
to switch between display lists, another 9MiB for the video input.
That still leaves 100MiB, wow.

Anyways, I will keep an eye out for the release of the datasheet and the 
programming manual as well as for BT822 hardware to buy.

[Paul (m_e99999)]

Hallo Rudolph,
ich brauche mal etwas Unterstützung. Im Forum finde ich leider nichts.

Ich will zwei benutzerdefinierte Fonts auf einen BT817 schreiben. der 
erste Font funktioniert ohne Probleme. Den zweiten Font habe ich wie im 
Forum beschrieben erstellt.

###############

Will man zwei Fonts benutzen muss man also erstmal ein FLASH Image
generieren, so etwa mit Font1.glyph, Font1.xfont und irgendeiner anderen
Datei.
Dann die Adresse an der die andere Datei landet aufschreiben, mit dieser
Adresse den nächsten Font konvertieren und wieder von vorne.

###############


Die Dummy-Datei bringt

###############

default-fl.blob                       : 0     : 4096
aptos-semibold_200_ASTC.glyph         : 4096  : 91392
aptos-semibold_200_ASTC.xfont         : 95488 : 264
aptos-semibold_200_ASTC.xfont.padding : 95752 : 56
DUMMY.txt                             : 95808 : 0

##############


Mein Code funktioniert nicht

##############

EVE_cmd_inflate(0, font_1, sizeof(font_1));
EVE_memWrite32(95488UL + 32UL, 4096UL);

EVE_cmd_inflate(95808UL, font_2, sizeof(font_2));
EVE_memWrite32(95808UL + 39040UL + 32UL, 95808UL);

##############

Ich bin am verzweifeln und wäre über einen Hinweis sehr dankbar.

[Rudolph R. (rudolph)]

Moin,

>Will man zwei Fonts benutzen muss man also erstmal ein FLASH Image
generieren,

Jain, kann man machen, aber das FLASH Image ist ja eigenlich für das 
externe Flash am BT817 gedacht und ich schreibe das in meinem Beispiel 
ja auch per EVE_cmd_flashupdate() erstmal ins Flash.

Und EVE_cmd_inflate() benutze ich da nur weil sich Fonts zum einen so 
gut komprimieren lassen, zum anderen kommt CMD_INFLATE nicht damit klar 
wenn die Daten nicht ganz korrekt sind.

Der Asset Compressor in EAB kann auch archive erzeugen in denen wie bei 
den Flash-Utilities mehrere Dateien hinternander gehängt sind.

Die Flash Utilities machen dann eben noch mehr, die "default-fl.blob" 
Datei ist der Flash-Treiber für den BT817.
Und dann kümmert sich das auch noch um das korrekte Alignment im Flash.

Wobei der Asset Compressor die Offsets zu den Datein nicht so 
komfortabel auswirft wie die Flash Utilities.

>so etwa mit Font1.glyph, Font1.xfont und irgendeiner anderen Datei.

Das können auch mehrere .glyph und .xfont sein und die seltsame .padding 
ist nur für das Alignment im Flash.

Paul schrieb:
> Dann die Adresse an der die andere Datei landet aufschreiben, mit dieser
> Adresse den nächsten Font konvertieren und wieder von vorne.

Nicht unbedingt, wenn man eine .glyph und eine .xfont zusammen in ein 
Flash-Image wirft, dann wird die .xfont automatisch angepasst.
Wenn man den Font allerdings aus dem RAM_G verwenden möchte, dann muss 
man den Offset in der .xfont selber anpassen - was Du ja auch machst.
Also das anpassen der Adressen beim Konvertieren ist nur notwendig, wenn 
man das wirklich direkt wie es ist in das RAM_G schreiben und so 
verwenden will ohne noch anzupassen.

Paul schrieb:
> Mein Code funktioniert nicht
>
> ##############
>
> EVE_cmd_inflate(0, font_1, sizeof(font_1));
> EVE_memWrite32(95488UL + 32UL, 4096UL);
>
> EVE_cmd_inflate(95808UL, font_2, sizeof(font_2));
> EVE_memWrite32(95808UL + 39040UL + 32UL, 95808UL);

Ok, was funktioniert denn da nicht?
Das entpackt zwei Images in das RAM_G, das eine an Adresse Null, das 
andere dahinter.
Dann werden noch die Offsets in den .xfont Dateien angepasst.

Das sieht soweit fast richtig aus, der Offset der zweiten .xfont wird 
aber auf den Anfang des zweiten Images gesetzt, wenn das auch ein 
Flash-Image ist sind doch die ersten 4096 Bytes wieder belegt.

Und das benutzt die Fonts doch aber noch nicht.

[Paul (m_e99999)]

Danke für die schnelle Antwort!

ich habe deinen Hinweis mit dem Offset angepasst.
EVE_cmd_inflate(95808UL, font_2, sizeof(font_2));
EVE_memWrite32(95808UL + 39040UL + 32UL, 4096UL + 95808UL);

bekomme aber noch immer keine Ausgabe für font_2. Beide Fonts 
funktionieren - ich habe das Ausprobiert indem ich font_2 testweise an 
Adresse 0 beginnen lasse.

EVE_cmd_inflate(0, font_2, sizeof(font_2));
EVE_memWrite32(39040UL + 32UL, 4096UL);


Mein Programm ist so Aufgebaut:

define MEM_FONT_1  95488UL
define MEM_FONT_2  39040UL


EVE_color_rgb_burst(BLACK);

EVE_cmd_setfont2_burst(12,MEM_FONT_1,200);

EVE_cmd_text_burst(420, 70, 12, EVE_OPT_RIGHTX, "DATEN°");

EVE_color_rgb_burst(BLACK);

EVE_cmd_setfont2_burst(13,MEM_FONT_2,24);

EVE_cmd_text_burst(20, 20, 13, 0, "ÜBERSCHRIFT);



font_1

default-fl.blob                       : 0     : 4096

aptos-semibold_200_ASTC.glyph         : 4096  : 91392

aptos-semibold_200_ASTC.xfont         : 95488 : 264

aptos-semibold_200_ASTC.xfont.padding : 95752 : 56


font_2

default-fl.blob                      : 0     : 4096

aptos-semibold_24_ASTC.glyph         : 4096  : 34944

aptos-semibold_24_ASTC.xfont         : 39040 : 309

aptos-semibold_24_ASTC.xfont.padding : 39349 : 11

[Paul (m_e99999)]

Hallo Rudolph,

ich konnte es jetzt lösen.
Man musste zum MEM_FONT_2 auch 95808UL addieren.

Vielen Dank für die Unterstützung - der Tip mit dem Offset brachte mich 
auf die richtige Spur.

[Rudolph R. (rudolph)]

Prima.

Aber um das noch mal zu wiederholen, mit einem einzigen Flash-Image für 
alle Fonts zusammen wäre das ein klein wenig weniger fummelig. :-)

[Paul (m_e99999)]

Alle Fonts in einem Image würde mir auch besser gefallen. Ich habe es 
bis jetzt aber noch nicht hinbekommen. Gibt es dafür eine Anleitung?

[Rudolph R. (rudolph)]

Na, Du machst das gleiche was Du jetzt auch machst, nur ziehst Du eben 
mehr als eine .glyph und .xfont im EAB in das Flash-Image.

[Ufuk (horizon)]

Hallo Rudolph,

ich habe gerade mit EVE und Co. angefangen. Zum spielen habe ich mir die 
"VM810C EVE2 CREDIT CARD MODULE" besorgt. Eine ESP32 Wroom 32D (China 
Shop) verorgt das Display mit Daten. Ich habe diesen Beitrag von Anfang 
bis fast zum Ende durchgelesen und teilweise einige Beiträge sogar 
mehrmals.
Die Datenblätter FT81x, Programmer guide und noch andere. EVE Asset 
Builder und EVE Screen Editor installiert und versucht einige Sachen 
parallel nachzuvollziehen. Ich bekomme auch einige Beispiel-Projekte zum 
laufen, soll heißen, die ESP und das Display verstehen sich und ich habe 
entsprechn eine Anzeige. Leider scheitere ich an den einfachsten Dingen 
wie z.B. ein etwas größeres Bild zu laden/anzuzeigen (statisch) ohne 
jeden schnick schnack.

Rudolph R. schrieb:
> Dann einfach in TFT_init() laden:
>
> EVE_cmd_loadimage(MEM_BIGPIC, EVE_OPT_NODL, bigpic, sizeof(bigpic));
>
> Das sind 2 Byte pro Pixel, bei 800x480 also mal eben 768000 Bytes.
> MEM_BIGPIC sollte also nicht zu weit hinten im Speicher liegen.
>
> Und anzeigen mit:
>
> EVE_cmd_setbitmap(MEM_BIGPIC, EVE_RGB565, 800, 480);
> EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
> EVE_cmd_dl(VERTEX2F(0, 0));
> EVE_cmd_dl(DL_END);

Ich versteh ehrlich gesagt nicht wo das Bild in deinem Beispiel geladen 
wird. RAM_G (Speicher 1024*1024 Byte), alle anderen Speicher wären ja zu 
klein. Ich habe aus dem Datenblatt und in ESE nachvollziehen können das 
der RAM_G bei 0x00000000 anfängt und bis 0x000FFFFF (1.048.575). Wenn 
ich aus deinem Beispiel Projekt "EVE_Test_Arduino_PlatformIO" tft.c

/* memory-map defines */
#define MEM_FONT 0x000f7e00 /* the .xfont file for the UTF-8 font is copied here */
#define MEM_LOGO 0x000f8000 /* start-address of logo, needs 6272 bytes of memory */
#define MEM_PIC1 0x000fa000 /* start of 100x100 pixel test image, ARGB565, needs 20000 bytes of memory */

#define MEM_DL_STATIC (EVE_RAM_G_SIZE - 4096) /* 0xff000 - start-address of the static part of the display-list, upper 4k of gfx-mem */

anschaue, dachte ich mir ok MEM_PIC1 fängt bei 0x000fa000 (1.024.000) an 
und braucht 20000 bytes, also ist der Speicher am Ende (1.044.000) Rest 
(4.575) da passt kein Bild mehr rein.
Also setzte ich

 #define MEM_BIGPIC 0x00000000

 an den Anfang.
Trotzdem kein Bild. Ich habe mit EAB unterschiedliche Bilder in der 
Größenordnung von 50x50 bis ca. 400x200 convertiert. Laut ESE z.B. sieht 
es wie folgt aus. Size: 165888 Compressed: 67902 w:384 h:216 Line 
Stride:768

CLEAR(1, 1, 1)
BITMAP_HANDLE(0)
CMD_SETBITMAP(0, ARGB1555, 384, 216)
BEGIN(BITMAPS)
VERTEX2F(3504, 2064)
END()

BITMAP_HANDLE: 6%   RAM_DL: 0%   RAM_G: 15%

Übrigens, ich verändere nichts an dem Code. Ergänze lediglich im 
(tft_data files werden natürlich entsprechend angepasst)

void TFT_init(void)
{
.
.
EVE_cmd_loadimage(MEM_BIGPIC, EVE_OPT_NODL, bigpic, sizeof(bigpic));
}

und

void initStaticBackground(void)
{
    /* display the logo */
    EVE_color_rgb(WHITE);
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(MEM_LOGO, EVE_ARGB1555, 56U, 56U);
    EVE_cmd_dl(VERTEX2F(EVE_HSIZE - 58, 5));
    EVE_cmd_dl(DL_END);

    /* display BigPic
    EVE_cmd_setbitmap(MEM_BIGPIC, EVE_RGB565, 384, 216);
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_dl(VERTEX2F(EVE_HSIZE/2 - 192, 150));
    EVE_cmd_dl(DL_END);
}

Was mache falsch? Was übersehe ich?

[Rudolph R. (rudolph)]

Hallo,

spontan würde ich sagen, Du versuchst konvertierte Daten mit 
CMD_LOADIMAGE zu laden.
Das CMD_LOADIMAGE ist aber für Rohdaten in .jpg oder .png Format.

Wenn Du in RGB565 konvertierst kannst Du in EAB den AssetCompressor 
benutzen um die resultieren binär Daten etwas zu packen.
Diese Daten werden dann mit CMD_INFLATE verschickt und in RAM_G 
entpackt.

[Ufuk (horizon)]

Hallo,

das wundert mich jetzt, weil der EAB bei der Validierung das hier 
ausspuckt.

Validating wallpaper3_320x180_RGB565_Converted.png...

Validated File: wallpaper3_320x180_RGB565_Converted.png
Compatible    : YES
Optimized File: N/A
Output Format : RGB565
RAM_G Usage   : 112.5 KB

The image wallpaper3_320x180_320x180_RGB565_Converted.png is compatible with cmd_loadimage and BT81X series.
DONE!

OK hab mich da beirren lassen.
Also den compress kann man nur über die console anwenden.
Output File: wallpaper3_320x180_RGB565.bin (58.2 KB)
Format     : RGB565
Width      : 320
Height     : 180
Compressed : yes

mit CMD_INFLATE bekomme ich etwas wie ein Bild aufs Display. Hänge an 
wie es aussehen sollte und wie es tatsächlich aussieht.

wallpaper, Bild aus dem Internet runtergeladen und einfach nur auf 
320x180px gespeichert

wallpaper2, ohne EXIF(Irfanview)

wallpaper3, ohne EXIF und 8Bit-Farbtiefe(Irfanview)

Bei allen das gleiche Ergebnis.

void TFT_init(void)
{
 .
 .
 .
        EVE_cmd_inflate(MEM_LOGO, logo, sizeof(logo)); /* load logo into gfx-memory and de-compress it */
        EVE_cmd_loadimage(MEM_PIC1, EVE_OPT_NODL, pic, sizeof(pic));
        EVE_cmd_inflate(MEM_WALL, wallpaper, sizeof(wallpaper));


        initStaticBackground();
    }
}

void initStaticBackground(void)
{
    .
    .
    /* display BigPic */
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(MEM_WALL, EVE_ARGB1555, 320U, 180U);
    EVE_cmd_dl(VERTEX2F(EVE_HSIZE/2 - 160, 150));
    EVE_cmd_dl(DL_END);
    .
    .

Außerdem verstehe ich nicht warum nurt etwas auf dem Display erscheint , 
wenn ich bei setbitmap(...,EVE_ARG1555,...) eintrage, obwohl das Bild 
mit RGB565 convertiert/erzeugt wird. Stehe aufm Schlauch...

[Rudolph R. (rudolph)]

Welche Version vom EAB benutzt Du?

Edit: ich habe mir einfach mal das wallpaper3_320x180.jpg da oben 
gegriffen, in EAB umgewandelt in RGB565, Dithering ausgeschaltet, das 
macht nur Rauschen.
Dann in EAB mit dem Asset Compressor gezipped und mit dem BIN2C Tool im 
EAB in eine .c gewandelt.
Das Array hat 43091 Byte.

Das habe ich mein aktuelles Spielprojekt eingebaut.

Da ich da noch ein anderes Bild dran habe an Adress Null
musste ich das woanders hin entpacken:
EVE_cmd_inflate(0x16f00, wallpaper, sizeof(wallpaper));

Und dann habe ich das zusätzlich zu dem anderen Bild angezeigt:

        EVE_color_rgb(WHITE);
        EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
        EVE_cmd_setbitmap(0, EVE_ARGB4, 288U, 163U);
        EVE_cmd_dl(VERTEX2F(20, 100));

        EVE_cmd_setbitmap(0x16f00, EVE_RGB565, 320U, 180U);
        EVE_cmd_dl(VERTEX2F(320, 100));

        EVE_cmd_dl(DL_END);

Das Display hat einen FT813.

Edit2: reich doch sonst mal die tft.c, tft_data.c und tft_data.h rüber.

[Ufuk (horizon)]

Guten morgen,
ich benutze die neueste EAB v2.12.2 hier gibt es keine Option für 
compress. Aber über die console kann man die Option mit -z ausführen.
Zum testen habe ich mir eine ältere Version runtergeladen v2.8.0

EVE Chip: FT81X Output Format: RGB565 Compressed=1 Dithering=0

Anschließend die erzeugte .bin mit bin2c convertiert und in die 
tft_data.c kopiert. Ergebnis ist genau so wie vorher...

Also mal ein/zwei Verständnisfragen:
EAB 2.8.0 & 2.12.2 erzeugen mehrere Dateien bei Compress=1

.bin

.binh --> die hab ich direkt mit CMD_INFLATE probiert


bei Compress=0 gibt es

.raw

.rawh --> die hatte ich auch mit CMD_LOADIMAGE probiert (kein Bild)


Mit der .binh hatte ich zumindest auch das verzerte(Bild ähnl.) Gebilde.
Warum muss ich die .bin nochmal mit bin2c jagen, obwohl doch anscheinend 
EAB die Aufgabe auch durchführt. Oder hab ich ein Denkfehler?

Welche Dateilänge gibt man an? 320x180 -> 2 Byte/px 640x180=115200
Bin2c gibt die comprimierte größe an oder?

/*
  C-file generated by Bin2C
  Compiled:    Oct 11 2024 at 10:28:35

  Copyright (C) 2018
  Segger Microcontroller GmbH
  www.segger.com

  The Embedded Experts
*/

static const unsigned char _acwallpaper_320_320x180_RGB565[43101UL + 1]

Nun denn, es wird nicht besser. Ich packe mal die gewünschte Datein 
rein.
Danke für Unterstützung.

[Ufuk (horizon)]

Ich habs jetzt hinbekommen....

EVE_cmd_setbitmap(MEM_WALL, EVE_RGB565, 320U, 180U);

Ich hatte gestern bereits mit EVE_RGB565 probiert und es ging nicht, 
heute geht es (naja zugegeben hatte ich die Bilder nicht mit bin2c 
konvertiert sondern die .binc genommen).
Also EVE_ARGB1555 funktioniert nicht, eigl. auch klar, weil das Bild mit 
RGB565 konvertiert wird. OMG
Manchmal hat man einfach Tomaten auf den Augen.

Naja, vielleicht hilft es dem oder den anderen die auch solche Probleme 
haben.

[Rudolph R. (rudolph)]

Moin,

Ufuk schrieb:
> ich benutze die neueste EAB v2.12.2 hier gibt es keine Option für
> compress.

Stimmt, die Option habe ich auch nicht mehr.

> Anschließend die erzeugte .bin mit bin2c convertiert und in die
> tft_data.c kopiert. Ergebnis ist genau so wie vorher...

Also das sollte eigentlich funktionieren.

> Also mal ein/zwei Verständnisfragen:
> EAB 2.8.0 & 2.12.2 erzeugen mehrere Dateien bei Compress=1
>
> .bin
> .binh --> die hab ich direkt mit CMD_INFLATE probiert

Mal davon ab, dass die .xxxh keine Header File sind, die Zahlenwüste 
sollte sich eigentlich in ein Array packen lassen.

Aber diese Dateien benutze ich nie.

> .raw
> .rawh --> die hatte ich auch mit CMD_LOADIMAGE probiert (kein Bild)

Das sind unkomprimierte Rohdaten als Text, damit kann weder 
CMD_LOADIMAGE was anfangen, noch CMD_INFLATE.
Die müsste man direkt in den Speicher schreiben und dafür habe ich 
EVE_memWrite_flash_buffer().
Als .jpg / .png oder auch konvertiert und komprimiert sind es eben nur 
weniger Daten, das spart Platz im Controller und kostet weniger Zeit 
beim Übertragen per SPI.
Der Unterschied zwischen selber konvertieren und CMD_LOADIMAGE ist vor 
allem die Kontrolle über das Format das dabei heraus kommt.

Ich habe die Daten für das wallpaper array ersetzt, probier das mal mit 
CMD_INFLATE.

> Mit der .binh hatte ich zumindest auch das verzerte(Bild ähnl.) Gebilde.
> Warum muss ich die .bin nochmal mit bin2c jagen, obwohl doch anscheinend
> EAB die Aufgabe auch durchführt. Oder hab ich ein Denkfehler?

Ich benutze den in EAB eingebauten "ASSET COMPRESSOR", der erzeugt keine 
.xxxh Datei, da kommt eine .zlib oder .zopfli Datei raus und die sind 
Binär.
Wobei die zopfli Lib normalerweise besser komprimiert.

> Welche Dateilänge gibt man an? 320x180 -> 2 Byte/px 640x180=115200

Da hätte ich weiterlesen sollen bevor ich die tft_data.c verändert habe. 
:-)
Das Array muss natürlich die Länge der Daten haben.

> Bin2c gibt die comprimierte größe an oder?/*

Jain, die Länge der konvertierten Binär-Daten, ob nun komprimiert oder 
nicht.

>   C-file generated by Bin2C
>   Compiled:    Oct 11 2024 at 10:28:35
>   Copyright (C) 2018
>   Segger Microcontroller GmbH

In EAB ist ein BIN2C Tool mit eingebaut.
Nicht, das andere Tools nicht funktionieren, das ist einfach 
komfortabler zu nutzen direkt aus EAB heraus, statt erst eine Shell 
öffnen zu müssen.

> static const unsigned char _acwallpaper_320_320x180_RGB565[43101UL + 1]

Und das wäre richtig gewesen.

Die leicht abweichenden Daten die ich habe mit anderer Länge kommen wohl 
daher das ich die angehängte .jpg verwendet habe und Du ein .png benutzt 
hast.
Kann es sein, dass Dein .png einen transparenten Hintergrund hat?

Ein .png hier anzuhängen war allerdings zumindest als ich das zuletzt 
probiert habe nicht so hilfreich, aus irgendeinem Grund hat die 
Forens-Software die Datei verändert.

[Ufuk (horizon)]

Puh, wo soll ich anfangen...

Auf jeden Fall vielen Dank für die Erleuchtung, hab mich wohl 
tatsächlich im Kreis gedreht und die Ausfahrt nicht gefunden.

Jetzt wird mir so einiges klar.

Bin jetzt wieder auf die EAB 2.12.2 gewechselt, folgendes ist mir 
aufgefallen, wenn ich unter
1. "image utilities" meine Bilder konvertiere (ohne compress) bekomme 
ich nur Dateien wie: .raw, .rawh, .json etc.
diese lassen sich zwar mit dem
2. "asset compressor" in .zlib oder .zopfli "zippen" und anschließend 
mit dem
3. "bin2c" in header Dateien umwandeln, aber die Bilder werden nicht 
angezeigt.

Rudolph R. schrieb:
> In EAB ist ein BIN2C Tool mit eingebaut.
> Nicht, das andere Tools nicht funktionieren, das ist einfach
> komfortabler zu nutzen direkt aus EAB heraus, statt erst eine Shell
> öffnen zu müssen.

Ist mir vorher garnicht aufgefallen, wie gesagt, Tomaten auf den Augen 
:)

Also im Schritt 1 mit compress option (nur console) konvertieren. So 
erhält man .bin, .binh etc. Diese wiederum müssen praktisch gar nicht 
mehr den Schritt 2 durchlaufen, weil die bereits komprimiert sind. Wenn 
ich die "gezippten" Dateien nun mit bin2c konvertiere wird auch kein 
Bild dargestellt. Noch ein kleiner Nebeneffekt, in dem Fall wurde die 
Datei sogar ca. 12 bytes größer als ohne "zippen".

Nochmal kurz zusammengefasst:
1. "image utilities" (Command prompt)

eab_tools img_cvt -i "Dateipfad" -f 7 -o "Zielpfad" -d -z
// -f 7 = RGB565
// -d ohne Dithering
// -z compress

2. "bin2c" >> Datei.h
Den Inhalt[und größe] in die tft_data.c kopieren..

const uint8_t <dateiname>[12942] PROGMEM = 
{
    120, 218,   1, 131,  50, 124,.....
};

..und in tft_data.h eintragen.

Eigentl. ganz einfach ;)

Rudolph R. schrieb:
> Kann es sein, dass Dein .png einen transparenten Hintergrund hat?

Ich glaube nicht, ist ein .jpg gewesen. Soweit ich weiß können nur .png 
transparente Hintergründe haben.

Rudolph R. schrieb:
> Ein .png hier anzuhängen war allerdings zumindest als ich das zuletzt
> probiert habe nicht so hilfreich, aus irgendeinem Grund hat die
> Forens-Software die Datei verändert.

Ja, das stimmt. Heute habe ich es auch runtergeladen und die Datei war 
nur noch halb so groß.
Ich hänge mal die wallpaper nochmal an (so wie aus dem Netz ohne 
Manipulation) es sollte 640x360 und 28,6KB groß sein.

[Rudolph R. (rudolph)]

Ufuk schrieb:
> Also im Schritt 1 mit compress option (nur console) konvertieren. So
> erhält man .bin, .binh etc. Diese wiederum müssen praktisch gar nicht
> mehr den Schritt 2 durchlaufen, weil die bereits komprimiert sind. Wenn
> ich die "gezippten" Dateien nun mit bin2c konvertiere wird auch kein
> Bild dargestellt. Noch ein kleiner Nebeneffekt, in dem Fall wurde die
> Datei sogar ca. 12 bytes größer als ohne "zippen".

Man kann sich so zwar den zweiten Schritt sparen, aber dafür hat man 
auch erheblich mehr Getippe. :-)
Und ich sehe da keine Zopfli Option.

wallpaper3_320x180_320x180_RGB565.raw - 115200
wallpaper3_320x180_320x180_RGB565.zlib - 43091
wallpaper3_320x180_320x180_RGB565.zopfli - 40692

Das schlägt sie 12 Bytes knapp. :-)

Ufuk schrieb:
> Ich glaube nicht, ist ein .jpg gewesen. Soweit ich weiß können nur .png
> transparente Hintergründe haben.

Siehe Deinen ersten Post:
"Validating wallpaper3_320x180_RGB565_Converted.png..."

[Ufuk (horizon)]

Rudolph R. schrieb:
> Siehe Deinen ersten Post:
> "Validating wallpaper3_320x180_RGB565_Converted.png..."

Ja, das ist etwas verwirrend. Das war die log von EAB. Hochgeladen habe 
ich eine .jpg


Und wenn ich das richtig verstehe, jagst du die .raw durch den Asset 
compressor?
Muss ich gleich mal testen.

[Ufuk (horizon)]

Ja, du hast natürlich Recht. Ich muss mich mit dem Konvertieren näher 
beschäftigen. Die .raw Dateien lassen sich mit asset compressor "zippen" 
und diese kann man mit bin2c umwandeln und mit CMD_INFLATE in den RAM_G 
laden. War diese Zusammenfassung korrekt?

Ich habe noch ein bischen mehr gespielt, und zwar habe ich ein Bild mit 
paint.net in vier Ebenen getrennt (Hintergrund Transparent) und vier 
einzelne .png Bilder gespeichert.
Diesmal mit ARGB1555 konvertiert (wegen transparens). Ich wollte die 
vier einzelbilder auf dem Display wieder als ein Bild darstellen lassen. 
Mit dem ESE funktioniert das:

Coprocessor:
CLEAR(1, 1, 1)
BITMAP_HANDLE(0)
CMD_SETBITMAP(0, ARGB1555, 499, 224)
BEGIN(BITMAPS)
VERTEX2F(800, 1600)
END()
BITMAP_HANDLE(1)
CMD_SETBITMAP(223552, ARGB1555, 499, 224)
BEGIN(BITMAPS)
VERTEX2F(800, 1600)
END()
BITMAP_HANDLE(2)
CMD_SETBITMAP(447104, ARGB1555, 499, 224)
BEGIN(BITMAPS)
VERTEX2F(800, 1600)
END()
BITMAP_HANDLE(3)
CMD_SETBITMAP(670656, ARGB1555, 499, 224)
BEGIN(BITMAPS)
VERTEX2F(800, 1600)
END()

und im Inspector (RAM_DL) steht es so:

Offset
(decimal)  Raw  Text
0  0x26000007  CLEAR(1, 1, 1)
1  0x05000000  BITMAP_HANDLE(0)
2  0x01000000  BITMAP_SOURCE(0)
3  0x29000000  BITMAP_SIZE_H(0, 0)
4  0x0803e6e0  BITMAP_SIZE(NEAREST, BORDER, BORDER, 499, 224)
5  0x28000000  BITMAP_LAYOUT_H(0, 0)
6  0x0707cce0  BITMAP_LAYOUT(ARGB1555, 998, 224)
7  0x1f000001  BEGIN(BITMAPS)
8  0x41900640  VERTEX2F(800, 1600)
9  0x21000000  END()
10  0x05000001  BITMAP_HANDLE(1)
11  0x01036940  BITMAP_SOURCE(223552)
12  0x29000000  BITMAP_SIZE_H(0, 0)
13  0x0803e6e0  BITMAP_SIZE(NEAREST, BORDER, BORDER, 499, 224)
14  0x28000000  BITMAP_LAYOUT_H(0, 0)
15  0x0707cce0  BITMAP_LAYOUT(ARGB1555, 998, 224)
16  0x1f000001  BEGIN(BITMAPS)
17  0x41900640  VERTEX2F(800, 1600)
18  0x21000000  END()
19  0x05000002  BITMAP_HANDLE(2)
20  0x0106d280  BITMAP_SOURCE(447104)
21  0x29000000  BITMAP_SIZE_H(0, 0)
22  0x0803e6e0  BITMAP_SIZE(NEAREST, BORDER, BORDER, 499, 224)
23  0x28000000  BITMAP_LAYOUT_H(0, 0)
24  0x0707cce0  BITMAP_LAYOUT(ARGB1555, 998, 224)
25  0x1f000001  BEGIN(BITMAPS)
26  0x41900640  VERTEX2F(800, 1600)
27  0x21000000  END()
28  0x05000003  BITMAP_HANDLE(3)
29  0x010a3bc0  BITMAP_SOURCE(670656)
30  0x29000000  BITMAP_SIZE_H(0, 0)
31  0x0803e6e0  BITMAP_SIZE(NEAREST, BORDER, BORDER, 499, 224)
32  0x28000000  BITMAP_LAYOUT_H(0, 0)
33  0x0707cce0  BITMAP_LAYOUT(ARGB1555, 998, 224)
34  0x1f000001  BEGIN(BITMAPS)
35  0x41900640  VERTEX2F(800, 1600)
36  0x21000000  END()

Einzeln werden die Bilder auf dem Display korrekt dargestellt, sobald 
eins dazu kommt gibt es eine "Suppe"
Ich habe u.a folgendes probiert...

    /* display 1/4 (Linie) */
    EVE_color_rgb(WHITE);  
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(MEM_SHLI, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));
    EVE_cmd_dl(DL_END);    
    /* display 2/4 (Text oben)*/
    EVE_color_rgb(WHITE);
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(MEM_SHSO, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));
    EVE_cmd_dl(DL_END);
    /* display 3/4 (Zahnrad)*/
    EVE_color_rgb(WHITE);
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(MEM_SHZA, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));
    EVE_cmd_dl(DL_END);
    /* display 2/4 (Text unten)*/
    EVE_color_rgb(WHITE);
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_setbitmap(MEM_SHHO, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));
    EVE_cmd_dl(DL_END);

Ich dachte ich könnte die vier Einzelbilder einfach übereinander legen.
Verstehe auch noch nicht ganz wie ich die ESE Anweisungen mit deiner Lib 
umsetzen kann. Ich habe auch schon versucht mit BITMAP_HANDLE(0..3)

EVE_cmd_dl(BITMAP_HANDLE(0));
oder
BITMAP_HANDLE(0);
oder
EVE_cmd_dl(DL_BITMAP_HANDLE);

da steige ich nicht wirklich durch.

[Rudolph R. (rudolph)]

Hmm, sowas habe ich noch gar nicht probiert.
Aber ja, im Grunde genommen werden die einfach übereinander gelegt.

Das mit dem Bitmap-Handle ist dabei unnötig und man muss auch nicht alle 
Kommandos wiederholen:

    EVE_color_rgb(WHITE);  
    EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);

    /* display 1/4 (Linie) */
    EVE_cmd_setbitmap(MEM_SHLI, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));

    /* display 2/4 (Text oben)*/
    EVE_cmd_setbitmap(MEM_SHSO, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));

    /* display 3/4 (Zahnrad)*/
    EVE_cmd_setbitmap(MEM_SHZA, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));

    /* display 2/4 (Text unten)*/
    EVE_cmd_setbitmap(MEM_SHHO, EVE_ARGB1555, 499U, 224U);
    EVE_cmd_dl(VERTEX2F(10, 70));

    EVE_cmd_dl(DL_END);

Also was ESE da treibt ist nicht optimal, der geht das einfach Zeile für 
Zeile durch ohne die vorherigen Zeilen zu berücksichtigen.

Aber das hier:
2  0x01000000  BITMAP_SOURCE(0)
3  0x29000000  BITMAP_SIZE_H(0, 0)
4  0x0803e6e0  BITMAP_SIZE(NEAREST, BORDER, BORDER, 499, 224)
5  0x28000000  BITMAP_LAYOUT_H(0, 0)
6  0x0707cce0  BITMAP_LAYOUT(ARGB1555, 998, 224)

Wird vom Kommando co-processor generiert aus CMD_SETBITMAP.
Also man könnte in dem Fall die resultierende Display-Liste optimieren 
indem man nicht CMD_SETBITMAP verwendet, sondern die resultierenden 
Kommandos, dabei aber den Satz nur einmal und für das zweite und 
folgende Bild nur noch BITMAP_SOURCE mit der jeweils passenden Adresse.

Das ändert nur alles nichts am Ergebnis, der Unterschied ist nur wie 
viel in der Display Liste landet um das Gleiche zu machen.

Ufuk schrieb:
> Einzeln werden die Bilder auf dem Display korrekt dargestellt, sobald
> eins dazu kommt gibt es eine "Suppe"

Pack die .png doch bitte mal in ein .zip und häng die an, damit ich das 
ausprobieren kann.
Es ist durchaus möglich, dass das Überlagern von Bildern in ESE anders 
funktioniert als auf dem Display, das würde ich dann aber als Fehler in 
ESE deklarieren.

[Ufuk (horizon)]

ich habe mal alle Dateien u.a.
.png
.raw
.zopfli
.c
eingepackt.

Rudolph R. schrieb:
> EVE_color_rgb(WHITE);
>     EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
>     /* display 1/4 (Linie) */
>     EVE_cmd_setbitmap(MEM_SHLI, EVE_ARGB1555, 499U, 224U);
>     EVE_cmd_dl(VERTEX2F(10, 70));
>     /* display 2/4 (Text oben)*/
>     EVE_cmd_setbitmap(MEM_SHSO, EVE_ARGB1555, 499U, 224U);
>     EVE_cmd_dl(VERTEX2F(10, 70));
>     /* display 3/4 (Zahnrad)*/
>     EVE_cmd_setbitmap(MEM_SHZA, EVE_ARGB1555, 499U, 224U);
>     EVE_cmd_dl(VERTEX2F(10, 70));
>     /* display 2/4 (Text unten)*/
>     EVE_cmd_setbitmap(MEM_SHHO, EVE_ARGB1555, 499U, 224U);
>     EVE_cmd_dl(VERTEX2F(10, 70));
>     EVE_cmd_dl(DL_END);

Hat leider nichts gebracht.
Hab ich das eigl. richtig gemacht?

/* memory-map defines */
#define MEM_SHLI 0x0001f488 /* sh_logo linie 499x224, ARGB1555, size = 265 bytes*/
#define MEM_SHSO 0x00020488 /* sh_logo soft 499x224, ARGB1555, size = 1643 bytes*/
#define MEM_SHZA 0x00021488 /* sh_logo zahnrad 499x224, ARGB1555, size = 2885 bytes*/
#define MEM_SHHO 0x00022488 /* sh_logo horizon 499x224, ARGB1555, size = 4425 bytes*/

Ich habe pro #define 4kB reserviert, ich bin mir nicht mehr ganz sicher, 
aber in den letzten Tagen/Wochen habe ich soviel Zeug gelesen. Ich 
meine mich errinnern zu können das die Adresse durch vier teilbar sein 
muss. Vielleicht verwechsele ich auch gerade was.

[Rudolph R. (rudolph)]

Ufuk schrieb:
> Hab ich das eigl. richtig gemacht?/* memory-map defines */
> #define MEM_SHLI 0x0001f488 /* sh_logo linie 499x224, ARGB1555, size =
> 265 bytes*/
> #define MEM_SHSO 0x00020488 /* sh_logo soft 499x224, ARGB1555, size =
> 1643 bytes*/
> #define MEM_SHZA 0x00021488 /* sh_logo zahnrad 499x224, ARGB1555, size =
> 2885 bytes*/
> #define MEM_SHHO 0x00022488 /* sh_logo horizon 499x224, ARGB1555, size =
> 4425 bytes*/

Also wenn die Bilder 499x224 haben and ARGB1555 sind, dann werden die im 
RAM_G ja 499 x 244 x 2 Bytes haben -> 223552 / 0x36940 jeweils.
Die machen zusammen ja schon fast den Speicher komplett voll.

Die Adressen in ESE sind ja auch so, entsprechend müsste auch die RAM_G 
Auslastungsanzeige in ESE aussehen.

Der FT810 kann Farb-Bilder leider nur mit 16 Bit pro Pixel anzeigen.

CMD_LOADIMAGE konvertiert und CMD_INFLATE entpackt, der resultierende 
Speicherverbrauch im RAM_G ist bei gleicher Auflösung identisch.

[Ufuk (horizon)]

Ja, 85% laut ESE

Danke für die Ausführung. Kaum macht man es richtig und schon 
funktioniert es. Verständnisproblem meinerseits.
Ich habe die komprimierten Werte eingetragen, war natürlich falsch.