FT800 / FT810 Library

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.

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.

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.

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.

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.

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:

1

#define IMG1_ADR  0

2

while(ft800_busy() == 1);

3

ft800_cmd_loadimage(IMG1_ADR, FT_OPT_NODL, jpg4, 2640);

4

ft800_cmd_execute();

5

//then in loop:

6

ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);

7

ft800_cmd_dl(BITMAP_SOURCE(IMG1_ADR));//ft800_cmd_dl(BITMAP_SOURCE(MEM_P 

8

IC1));

9

ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));

10

ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));

11

ft800_cmd_dl(VERTEX2II(FT_HSIZE-96-10,FT_VSIZE-96-10,0,0));

12

//ft800_cmd_dl(VERTEX2F((10)*16,30*16));

works fine, but when I try to use

1

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

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. :-)

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?

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.

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

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

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.

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

1

void touch_calibrate(void)

2

{

3

/* send pre-recorded touch calibration values, depending on the display the code is compiled for */

4

5

#if defined (EVE_CFAF240400C1_030SC)

6

  EVE_memWrite32(REG_TOUCH_TRANSFORM_A, 0x0000ed11);

7

  EVE_memWrite32(REG_TOUCH_TRANSFORM_B, 0x00001139);

8

  EVE_memWrite32(REG_TOUCH_TRANSFORM_C, 0xfff76809);

9

  EVE_memWrite32(REG_TOUCH_TRANSFORM_D, 0x00000000);

10

  EVE_memWrite32(REG_TOUCH_TRANSFORM_E, 0x00010690);

11

  EVE_memWrite32(REG_TOUCH_TRANSFORM_F, 0xfffadf2e);

12

#endif

13

....

14

15

/* activate this if you are using a module for the first time or if you need to re-calibrate it */

16

/* write down the numbers on the screen and either place them in one of the pre-defined blocks above or make a new block */

17

#if 0

18

  /* calibrate touch and displays values to screen */

19

  EVE_cmd_dl(CMD_DLSTART);

20

  EVE_cmd_dl(DL_CLEAR_RGB | BLACK);

21

...

Das wird am Anfang von TFT_init() aufgerufen.

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

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.

And as you probably have noticed, Bridgetek took down EAB 2.4 again.
No idea why though, it seems to be working just fine.

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?

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.

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.

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

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

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 ...

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.

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

Ä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.

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 !

Nice, irgendwann muss ich auch mal wieder Zeit finden sowas zu machen. 
:-)

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...???

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.

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 !!!

> 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.

>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:

1

 void spi_transmit(uint8_t data)

2

{

3

  HAL_SPI_Transmit(&hspi5, &data, 1 , 5);

4

}

5

6

uint8_t spi_receive(uint8_t data)

7

{

8

  uint8_t  dain;

9

  HAL_SPI_TransmitReceive(&hspi5, &data, &dain, 1 , 5);

10

  return (dain);

11

}

12

13

14

// die Definition für das 7" TFT ist diese:

15

16

#define EVE_EVE2_70G                // neu für :  NHD-7.0-800x480FT-CTXL-T, EVE2

17

#define EVE_HAS_CRYSTAL            // TFT hat 12 MHz extern

18

19

/* Matrix Orbital EVE2 modules EVE2-50G, EVE2-70G : 800x480 5.0" and 7.0" capacitive touch, FT813 */

20

/* Crystalfonts CFAF800480E0-050SC 800x480 5.0" , FT813 capacitive touch */

21

// NewHaven NHD-7.0-800480FT-CSXV-T

22

#if defined (EVE_EVE2_50G) || defined (EVE_EVE2_70G) || defined (EVE_CFAF800480E0_050SC)

23

#define Resolution_800x480

24

#define EVE_PCLK  (2L)

25

#define EVE_PCLKPOL  (1L)

26

#define EVE_SWIZZLE  (0L)

27

#define EVE_CSPREAD  (0L)

28

#define EVE_TOUCH_RZTHRESH (4800L)

29

#define EVE_GEN 2

30

//#define EVE_HAS_GT911  /* special treatment required for out-of-spec touch-controller */

31

#endif

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)

die "ohne viel Nachdenken" Version mit HAL lib: CS setzen..

1

 void EVE_cs_set(void)

2

{

3

  HAL_GPIO_WritePin(GPIOF, GPIO_PIN_6, RESET);                  // set lo manually set chip-select to low */

4

}

5

6

void EVE_cs_clear(void)

7

{

8

  HAL_GPIO_WritePin(GPIOF, GPIO_PIN_6, SET);                  // set hi manually set chip-select to high */

9

}

 --> so wird EIN assembler Befehl daraus
 zB mit :  GPIOF->BSRR = 0x0020;  etwa so -->

1

#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:

1

 SPI5->TXDR = data;

die SPI sendet automatisch, sobald ins Tx register geschrieben wird...

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 ?

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.

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.

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.

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

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:

1

enum

2

{

3

    E_OK = 0,

4

    E_NOT_OK,

5

    EVE_FAIL_CHIPID_TIMEOUT,

6

    EVE_FAIL_RESET_TIMEOUT,

7

    EVE_FAIL_PCLK_FREQ,

8

    EVE_FAIL_FLASH_STATUS_INIT,

9

    EVE_FAIL_FLASH_STATUS_DETACHED,

10

    EVE_FAIL_FLASHFAST_NOT_SUPPORTED,

11

    EVE_FAIL_FLASHFAST_NO_HEADER_DETECTED,

12

    EVE_FAIL_FLASHFAST_SECTOR0_FAILED,

13

    EVE_FAIL_FLASHFAST_BLOB_MISMATCH,

14

    EVE_FAIL_FLASHFAST_SPEED_TEST

15

};

You might wonder about the first two, this is a nod to Autosar 
Std_ReturnType.

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 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 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 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.

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.

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 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.

+ 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:

1

/* RVT70xQBxxxxx 800x480 7.0" Riverdi, various options, BT815/BT816 */

2

#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)

3

#define EVE_HSIZE  (800L)  /* Thd Length of visible part of line (in PCLKs) - display width */

4

#define EVE_VSIZE  (480L)  /* Tvd Number of visible lines (in lines) - display height */

5

6

#define EVE_VSYNC0  (4L)  /*  0  Tvf Vertical Front Porch */

7

#define EVE_VSYNC1  (8L)  /* 13  10 Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */

8

#define EVE_VOFFSET (13L)  /* 23 Tvf + Tvp + Tvb Number of non-visible lines (in lines) */

9

#define EVE_VCYCLE  (512L)  /* 525 Tv Total number of lines (visible and non-visible) (in lines) */

10

#define EVE_HSYNC0  (0L)  /* 0 Thf Horizontal Front Porch */

11

#define EVE_HSYNC1  (4L)  /* 10 Thf + Thp Horizontal Front Porch plus Hsync Pulse width */

12

#define EVE_HOFFSET (28L)  /*46  Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */

13

#define EVE_HCYCLE (856L) //  (1056L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */

14

#define EVE_PCLK  (2L)  /* 72MHz / REG_PCLK = PCLK frequency 30 MHz */

15

#define EVE_PCLKPOL (1L)  /* 1L PCLK polarity (0 = rising edge, 1 = falling edge) */

16

#define EVE_SWIZZLE (0L)  /* Defines the arrangement of the RGB pins of the FT800 */

17

#define EVE_CSPREAD  (0L)  // 1L muss definitiv 0 sein !

18

#define EVE_TOUCH_RZTHRESH (1800L)  /* touch-sensitivity */

19

#define EVE_HAS_CRYSTAL

20

#define EVE_GEN 3

21

#endif

>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.

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. :)

>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.

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.

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

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

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.

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)

>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 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. :-)

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. :-)

>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. :)

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.

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.

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.

Äh, hast Du mal 1-2 Bilder zu dem Problem?
Also was Du vor hast, und wenn es in Paint ist. :-)

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 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?

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.

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. :-)

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

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?

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

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

1

EVE_cmd_dl_burst(VERTEX_FORMAT(0));

2

    EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_RGB(255, 255, 255));

3

    EVE_cmd_dl_burst(COLOR_A(0));

4

    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

5

    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));

6

7

    // draw outline

8

    // outline radius = _br

9

    // draw the outline with alpha = 0 to set stencil

10

    EVE_cmd_dl_burst(LINE_WIDTH(_br * 16));

11

    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);

12

    EVE_cmd_dl_burst(VERTEX2F(_x + _br, _y + _br));

13

    EVE_cmd_dl_burst(VERTEX2F(_x + _w - _br, _y + _h - _br));

14

    EVE_cmd_dl_burst(DL_END);

15

16

    // fill the stencil area with the gradient

17

    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));

18

    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));

19

    GradientHelper::Gradient(_x, _y, _w, _h, 0x131314, 0x202428, 0.1405, 0.8529, 318.21, true);

20

    // reset the stencil

21

    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

22

23

    // calculate size of the inner area

24

    _brInner = _br - 4;

25

    _xInner = _x + 4;

26

    _yInner = _y + 4;

27

    _wInner = _w - 8;

28

    _hInner = _h - 8;

29

30

    // set scissor rectangle for inner area

31

    EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));

32

    EVE_cmd_dl_burst(SCISSOR_SIZE(_wInner, _hInner));

33

    // draw inner area

34

    // draw the inner area with alpha = 0 to set stencil

35

    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));

36

    EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));

37

    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);

38

    EVE_cmd_dl_burst(VERTEX2F(_xInner + _brInner, _yInner + _brInner));

39

    EVE_cmd_dl_burst(VERTEX2F(_xInner + _wInner - _brInner, _yInner + _hInner - _brInner));

40

    EVE_cmd_dl_burst(DL_END);

41

42

    // fill the stencil area with the gradient

43

    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));

44

    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));

45

    GradientHelper::Gradient(_x, _y, _w, _h, 0x151618, 0x34393F, -0.05, 1.0, 331, true);

46

47

    // reset stencil and stencil function

48

    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));

49

    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

50

    // Up part is pressed

51

    if (Up)

52

    {

53

        uint16_t xPart = _x + 4;

54

        uint16_t yPart = _y + 4;

55

        uint16_t wPart = _w - 8;

56

        uint16_t hPart = (_h / 2) - 4;

57

        // set scissors to upper part of control

58

        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));

59

        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));

60

        // setup the stencil for the upper area

61

        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));

62

        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));

63

        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);

64

        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart + _brInner));

65

        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart + _brInner));

66

        EVE_cmd_dl_burst(DL_END);

67

68

        // fill the stencil area with the gradient

69

        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));

70

        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));

71

        GradientHelper::Gradient(_x, _y, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);

72

73

        // reset stencil and stencil function

74

        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));

75

        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

76

    }

77

78

    // Down part is pressed

79

    if (Down)

80

    {

81

        uint16_t xPart = _x + 4;

82

        uint16_t yPart = _y + (_h / 2);

83

        uint16_t wPart = _w - 8;

84

        uint16_t hPart = (_h / 2) - 4;

85

        // set scissors to upper part of control

86

        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner + (_h / 2) - 4));

87

        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));

88

        // setup the stencil for the upper area

89

        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));

90

        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));

91

        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);

92

        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart - _brInner));

93

        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart - _brInner));

94

        EVE_cmd_dl_burst(DL_END);

95

96

        // fill the stencil area with the gradient

97

        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));

98

        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));

99

        GradientHelper::Gradient(_x, _y + _h / 2, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);

100

101

        // reset stencil and stencil function

102

        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));

103

        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

104

    }

105

    // draw the center line

106

    EVE_cmd_dl_burst(SCISSOR_XY(_x + 4, _y + (_h / 2) - 2));

107

    EVE_cmd_dl_burst(SCISSOR_SIZE(72, 4));

108

    EVE_cmd_gradient_burst(_x + 5, _y + 86, 0x202428, _x + 76, _y + 74, 0x151618);

109

110

    // scissor rectangle for indicator

111

    EVE_cmd_dl_burst(SCISSOR_XY(_x, _y - 14));

112

    EVE_cmd_dl_burst(SCISSOR_SIZE(_w, 10));

113

    EVE_cmd_dl_burst(COLOR_A(255));

114

    // draw the activity indicator

115

    if (Up || Down)

116

    {

117

        // draw the border

118

        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x202020);

119

120

        EVE_cmd_dl_burst(LINE_WIDTH(2 * 16));

121

        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);

122

        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));

123

        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));

124

        EVE_cmd_dl_burst(DL_END);

125

        // draw the indicator line

126

        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xC02825);

127

        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));

128

        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);

129

        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));

130

        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));

131

        EVE_cmd_dl_burst(DL_END);

132

133

        EVE_cmd_dl_burst(COLOR_A(255));

134

        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);

135

    }

136

    else

137

    {

138

        // draw the inactive line

139

        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x161A1D);

140

        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));

141

        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);