FT800 / FT810 Library

[Spyy (Gast)]

Rudolph R. schrieb:
> Sind bei dem Teensy 4.1 per Default die Drive-Level auf die kleinste
> Stufe eingestellt?

Ich habe die Frage vor längerer Zeit im Teensy Forum gestellt...leider 
keine Antwort...:(

[Rudolph R. (rudolph)]

Ich habe gestern mal etwas durch das Teensyduino gestöbert und wenn ich 
das mit den Registern richtig verstehe sind mindestens die Pins um den 
SPI auf die höchste Stufe (7) eingestellt.
Heute habe ich da noch mal mit dem Oszi dran gemessen und dabei 
festgestellt, dass der Tastkopf auf X1 gestellt war, das kommt davon 
wenn man das Equipment verleiht und nicht kontrolliert wie die 
Einstellung sind.
Auf X10 waren die Flanken gleich viel steiler, eher zu steil und neben 
den Überschwingern eine Menge Schmutz drauf, das spricht für mehr 
Filtern, bzw. stärker belasten oder auch die Ausgangstreiber auf eine 
kleinere Stufe stellen könnte helfen.
Am Ausgang meiner Adapter-Platine war der Takt deutlich glatter, hatte 
aber auch Gezappel drauf.

[Rudolph (Gast)]

Gestern habe ich den Drive-Level runter gestellt, das hat aber soweit 
keinen merkbaren Einluss gehabt.

Jetzt habe ich gerade mal den Reihenwiderstand auf meiner 
Adapter-Platine größer gemacht, in SCK habe ich da normalerweise 10R in 
Reihe und 22pF gegen GND, also ein praktisch kaum wirksamer Tiefpass.
Jetzt habe ich die Widerstände durch 240R ersetzt und bei CS auch noch 
einen 22pF reingefummelt, das sind so 30MHz Grenzfrequenz.
Das sieht hinter dem Widerstand deutlich ruhiger aus.

Nachher schaue ich mal ob das dann auch endlich ohne Logic-Analyzer auf 
den Leitungen funktioniert.

Wenn das funktioniert kann der Widerstand sicher auch kleiner sein.

[Rudolph R. (rudolph)]

And to get back to Englisch, I just tested the modified display adapter 
with an EVE3-50G and the Teensy 4.1 and it works without connecting the 
logic
analyzer now.

Interestingly the display for the frequency changed:
7246628x for reading REG_CLOCK every second
72467376 for the reading REG_CLOCK right after init with the delay().
But since frames/s is up a little as well to 74/75 instead of 73/74 it 
is possible that the Teensy is running a little fast right now.

Setting the SPI to 21MHz after init works, at 22MHz the display stays 
dark.

This is the adapter with the configuration I am using:
https://github.com/RudolphRiedel/EVE_display-adapter/blob/master/L-D5019-01-05/L-D5019-01-05_EVE.PDF
Only the audio part with the speaker is not populated.

I changed R3, R5 and R8 from 10R to 240R and added a 22pF between pin 1 
of U2A and GND.

I have a second adapter that is populated to the same configuration as 
in the .pdf but with R17 removed and R24 populated.
Ok, and the audio part is not populated on this board either.
I am using this board with the RVT101 and I am supplying it with 9.6V 
for the backlight in order to keep the backlight current low.
And next I am changing R3, R5 and R8 to 150R on this one.

[Rudolph R. (rudolph)]

Hey, that worked just fine, I have the RVT101 now up and running with 
the Teensy 4.1 without the logic analyzer connected.

And with the lower vaule for the resistors of 150R instead of 240R the 
SPI works with a higher clock now.
With 26MHz reading from the display still works including the touch.
With 27MHz the number displayed for the Frequency and the Frames/s that 
are measured one per second is "0" and the touch is not working anymore.
When I setup the SPI to 30MHz, 40MHz or even 50MHz the display still 
works but I doubt that it really is using 40MHz let alone 50MHz.

Back to 20MHz, the display for the frequncy measured once is: 72003052
And for the frequency measured every second: 72002403

No idea why this is different now, maybe the clock on the EVE3-50G is 
running a little faster than 12MHz.
The RVT101 is using a crystal and the EVE3-50G is using a resonator, 
this is maybe 0,02% to maybe 0.5%.

So like  Arnaud reported for the Teensy 3.5, at least my Teensy 4.1 
needs a little more series resitance to play nice on the SPI even when 
working without a real load since I am using logic buffers.
Now I am glad that I did not optimise-away the 10R/22pF from my board. 
:-)


Hmm, I just tried to use the internal oscillator by removing the 
"EVE_HAS_CRYSTAL" define from the module configuration.
And there is some issue, this way the display is blinking, measuring the 
frequency and frames/s every second does not work and the frequency 
measured once only is 38069614.
I look into that.

[Rudolph R. (rudolph)]

Oh, big oh, the BT817/BT818 do not have the "internal relaxation 
oscillator" anymore or at least this has been removed from the 
datasheet.
From chapter 4.2 in the datasheet "System Clock" up to the CLKINT 
command.
It's gone, you have a add a crystal, a resonator.
"External Clock Input" also is gone.

But even if this still works somewhat contradicting the datasheet, my 
display
is wired for an crystal and not for the internal oscillator like in the 
datasheet of the BT815/BT816. This would require X1/Clk to be connected 
to GND.
So even if this still works, switching to internal oscillator with a 
crystal connected is not a valid experiment.

Edit: and I just posted this with more details from the datasheet to the 
BRT forum.

[Spyy (Gast)]

Oh, oh...wow thank you for investigating this....i will then add bus 
drivers and an external crystal...to get rid about my issues.

Which type of chrystal (part number) with which capacitors do you use?
Or do you think X1 to ground is sufficient?

[Spyy (Gast)]

Oh yes, found it...no word of internal anymore..this was changed last 
year...hm...i asked exactly this in the forum in the past if an external 
oscillator is necessary...:(

[Rudolph R. (rudolph)]

I am exclusively using readily available modules so far.
And I am not using 12MHz crystals with my controllers, but 16MHz mostly.

That said I went on to a quick fishing expedition on Digikey and found
CX3225GA12000D0PTVCC ( 1253-1151-1-ND ), if I were to add a 12MHz 
crystal and had to make due with what is available I probably would go 
for these.
Plus 12pF capacitors.
I prefer the crystals with two pads as I can solder these more easily by 
hand.

Since Matrix Orbital is sucessfully using ceramic resonators on their 
modules an alternative to a crystal might be a CSTNE12M0GH5L000R0 ( 
490-17947-1-ND ), I selected these for their better frequency tolerance 
of +/- 0.07% compared to the more standard +/- 0.5% for resonators.

[Karol (Gast)]

Hi there, How can I display an image with new library in old FT 800 
series? There no setbitmap command... also, I remember taht "FT80x is 
gone" so, what can I do, if I have to use old FT800?

When i use yours example:
#define IMG1_ADR  0
while(ft800_busy() == 1);
ft800_cmd_loadimage(IMG1_ADR, FT_OPT_NODL, jpg4, 2640);
ft800_cmd_execute();
//then in loop:
ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_dl(BITMAP_SOURCE(IMG1_ADR));//ft800_cmd_dl(BITMAP_SOURCE(MEM_P 
IC1));
ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
ft800_cmd_dl(VERTEX2II(FT_HSIZE-96-10,FT_VSIZE-96-10,0,0));
//ft800_cmd_dl(VERTEX2F((10)*16,30*16));

works fine, but when I try to use ft800_cmd_loadimage(RAM_IMAGES_LOGO_2, 
FT_OPT_NODL, IMAGES_LOGO_2, sizeof(IMAGES_LOGO_2)); and the same metod 
for display it, it doesn't work at all.

Sometimes, only ft800_cmd_loadimage(...) crashed.

PS. For this case, I am using "Spielplatz_90CAN_FT800.zip " from first 
post.

Regards
Karol

[Karol B. (karol_b135)]

Hi there, How can I display an image with new library in old FT 800
series? There no setbitmap command... also, I remember taht "FT80x is
gone" so, what can I do, if I have to use old FT800?

When i use yours example:

#define IMG1_ADR  0
while(ft800_busy() == 1);
ft800_cmd_loadimage(IMG1_ADR, FT_OPT_NODL, jpg4, 2640);
ft800_cmd_execute();
//then in loop:
ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
ft800_cmd_dl(BITMAP_SOURCE(IMG1_ADR));//ft800_cmd_dl(BITMAP_SOURCE(MEM_P 
IC1));
ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
ft800_cmd_dl(VERTEX2II(FT_HSIZE-96-10,FT_VSIZE-96-10,0,0));
//ft800_cmd_dl(VERTEX2F((10)*16,30*16));

works fine, but when I try to use

ft800_cmd_inflate(RAM_IMAGES_LOGO_2, IMAGES_LOGO_ASUZU_2, sizeof(IMAGES_LOGO_2));

 and the same metod
for display it, it doesn't work at all.

Sometimes, only ft800_cmd_inflate(...) crashed.

PS. For this case, I am using "Spielplatz_90CAN_FT800.zip " from first
post.

Regards
Karol

[Rudolph R. (rudolph)]

Karol B. schrieb:
> Hi there, How can I display an image with new library in old FT 800
> series? There no setbitmap command... also, I remember taht "FT80x is
> gone" so, what can I do, if I have to use old FT800?

Hello,
while my first recommendation is to switch to a newer display, you can 
also still use the older version of my library, it's all still there.
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x
And the API is pretty close to the current one with the exception that 
V5 additionally has the EVE...._burst() functions to shave off a few 
extra cycles from every function by not checking for burst-mode every 
time.

That thing I did over five years ago that is attached to the start of 
this thread, it is not supported anymore. :-)

[Karol B. (karol_b135)]

Thanks a lot for your quick answer. Could you give me short an example 
how to display 2 images, one with load_image and another with 
cmd_inflate functions?

[Rudolph R. (rudolph)]

It really has been a while since I used a FT800 based display.
I just took the Arduino example from the V4 archive which is displaying 
two images.
I modified the display to EVE_VM800B50A in EVE_config.h.
Compiling it showed that the example is not directly compatible with 
FT800.

First there is VERTEX_FORMAT that does not exist in FT80x and which 
allows to setup the pixel resolution for VERTEX2F.
So VERTEX2F for FT80x always is using 1/16 pixel resolution - which I 
really do not miss.

Next is CMD_SETBITMAP which does not exist for FT80x either and needs to 
be replaced with a sequence of comands.

EVE_cmd_setbitmap(MEM_LOGO, EVE_L8, 38, 59);
->
EVE_cmd_dl(BITMAP_SOURCE(MEM_LOGO));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_L8,38,59));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,38,59));

And there is a second CMD_SETBITMAP that I changed as well.

EVE_cmd_setbitmap(MEM_PIC1, EVE_RGB565, 100, 100);
->
EVE_cmd_dl(BITMAP_SOURCE(MEM_PIC1));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_RGB565,100*2,100));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,100,100));

I am not sure if this really works but at least it compiles without 
warning now for an Arduino Uno using PlatformIO.

[Karol B. (karol_b135)]

Thanks a lot :) I will try attached example. For now, i have got working 
one. Perhaps my mistake was all about PROGMEM attribute after 
cmd_inflate. I feel I forgotten read data form flash.

Thanks again, You'ar great :)

[Markus S. (Firma: LRP AG) (mastr64)]

Hallo Rudolph

ich habe ein Display von Riverdi mit kapazitivem Touch (RVT50AQBNWC00).
Das Display funktioniert einwandfrei und auch der Touch funktioniert 
wenn ich die Kalibrierfunktion am Anfang des Programms aufrufe.
Wenn ich aber die Kalibrierwerte abspeichere und diese dann nach dem 
Initialisiseren des Display in die REG_TOUCH_TRANSFORM_A-F Register 
schreibe, dann funktioniert der Touch nicht.
Gibt es da noch etwas spezielles zu beachten?
Was mir auch eigenartig erscheint, die Kalibrierwerte für die 
REG_TOUCH_TRANSFORM-Register sind nach jeder Kalibrierung komplett 
verschieden.

Freundliche Grüsse
Markus

[Rudolph (Gast)]

Also eigentlich klappt das mit dem Speichern und wieder rein schreiben, 
das mache ich schon seit Jahren so.
Etwas stumpf, da ich die Werte vom Display abschreibe und in die 
Software eintrage, so klappt das aber am ehesten quer über diverse 
Controller, so ohne Schnittstelle in ein EEPROM.

Und normalerweise ändern sich die Werte von einem Kalibrieren zum 
anderen auch nicht so deutlich.

Ich empfehle auch einen Stylus zu verwenden, die Dinger gibt es extra 
für Kapazitive Displays, mit dem Finger ist man leicht ein paar mm neben 
den Punkten.

[Markus S. (Firma: LRP AG) (mastr64)]

Ich mache das auch so mit Werte abschreiben und anschliessend im Code 
eintragen.

ich weiss nicht ob ich beim schreiben der REG_TOUCH_TRANSFORM Register 
etwas übersehe. Wo machst du das genau, beim EVE_init()oder wo?
Hast du mir ev ein kurzes Code-Beispiel.

[Rudolph R. (rudolph)]

Meine Beispiele haben alle den gleichen Code unten drunter.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_Arduino_PlatformIO/src/tft.c

void touch_calibrate(void)
{
/* send pre-recorded touch calibration values, depending on the display the code is compiled for */

#if defined (EVE_CFAF240400C1_030SC)
  EVE_memWrite32(REG_TOUCH_TRANSFORM_A, 0x0000ed11);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_B, 0x00001139);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_C, 0xfff76809);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_D, 0x00000000);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_E, 0x00010690);
  EVE_memWrite32(REG_TOUCH_TRANSFORM_F, 0xfffadf2e);
#endif
....

/* activate this if you are using a module for the first time or if you need to re-calibrate it */
/* write down the numbers on the screen and either place them in one of the pre-defined blocks above or make a new block */
#if 0
  /* calibrate touch and displays values to screen */
  EVE_cmd_dl(CMD_DLSTART);
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK);
...

Das wird am Anfang von TFT_init() aufgerufen.

[Markus S. (Firma: LRP AG) (mastr64)]

Jetzt funktioniert es !!

Ich hatte einen Fehler in der Funktion EVE_memRead32,
somit waren die gelesenen Werte immer falsch.

Herzlichen Dank für deine Unterstützung.

Markus

[Rudolph R. (rudolph)]

There is a new Asset Builder available:
https://brtchip.com/eve-toolchains/#EVEAssetBuilder

And it has a couple of interesting new features like the enhanced font 
converter.

[Rudolph R. (rudolph)]

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

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudi,
bin mit meinen Versuchen, ein Bitmap darzustellen einen großen Schritt 
weiter gekommen! Leider sehe ich am Ende auch nach vielem 
Experimentieren nur ein "verkrisseltes" Bild in der Größe ca. 35 x 35 
und das stets in der linken oberen Ecke, obwohl ich in VERTEX2II 
eindeutig die Koordinaten 100 x 100 (z.B.) eingebe.
Also: FT813! Keine Co-Prozessor-Nutzung!
Benutze den FTDI-EVE-Screen-Editor. Habe mal mein Logo mit "Paint" auf 
eine Größe von 100 x 35 Pixel gebracht und als Projekt in den 
Screen-Editor als ARGB1555 geladen. Nach dem Speichern des Projekts hat 
man die RAWH-Daten. Bei 2 Bytes pro Pixel und genannter Größe sind das 
immerhin stolze 7000 Bytes. Die Schreibe ich als erstes in den RAM_G. 
Zur Kontrolle habe ich dann erst mal 1 Sekunde später die Daten 
ausgelesen und auf den Bildschirm gebracht (zumindest mal die ersten 
255) und Verglichen: Alles richtig gemacht!
Dann setze ich:
Bitmap_Handle(0)
Bitmap_Source(0)  (habe ja die Daten ab Adresse Null des Ram_G 
geschrieben)
Bitmap_Lyout(ARGB1555, 200, 35)
Parameter "Linestride" (200) muss gemäß Anleitung Anzahl Bytes pro Pixel 
(2) mal Weite (hier 100) also 200 sein. Der EVE_Screen-Editor spuckt 
diesen Wert auch sofort allein aus, wenn ich als Format ARGB1555 setze. 
Am Editor kann man auch schön sehen, was passiert, wenn man diesen Wert 
ändert (Bild verzerrt sich zunehmend). Und genau so - abgesehen von dem 
kleinen Ausschnitt - sieht auch der Teil, den ich bei mir am Display 
sehe aus, mega stark verzerrtes Bild, was mit viel Fantasie erahnen 
lässt, dass das mein Logo (ein Ausschnitt davon) sein soll.
Dann setze ich natürlich noch:
Bitmap_Size(Nearest,Border,Border,100,35) (Bitmap_Size(0,0,0,100,35))
Zu guter letzt folgt dann natürlich noch Begin_Bitmaps, Vertex2II mit 
den X-Y-Koordinaten 100/100, EndList und Display...

Große Frage: Der EVE-Screen-Editor ist zwar für den FT800, aber gemäß 
Prorammer-Guide des FT813 sind die einzelnen genannten Befehle genau so.
Kann ich diese Bilddaten (RAWH) hier wirklich benutzen?

Irgendwie steckt in meinem Hinterkopf noch so drin, dass man 
"eigentlich" nur Bitmaps mit max. 64 x 64 darstellen kann. Aber 
Bitmap_Size sagt ja für Width und Height als erlaubte Werte je 511. Und 
wenn ich dann noch Size_H benutze, geht es ja noch größer...!
Habe ich noch etwas ganz wichtiges vergessen?

Vor dem Darstellen des Bitmap setze ich ja z.B. einen Begrüßungstext na 
usw. Die RAM_DL-List für das Bitmap ist (zunächst) der letzte Schritt. 
Wenn ich hier NICHT Clear(1,1,1) mit CLEAR_COLOR_RGB(0,0,0) setze, wird 
das "verkrisselte" Bitmap in der Breite ca. 35 Pixel von oben bis unten 
dargestellt. Füge ich CLEAR... ein, so erscheint das 35 x 35 Bild. Gibt 
es dafür eine sinnvolle Erklärung?

Außer, dass ich die noch bis vor kurzem nicht benutzten Befehle CLEAR 
(mit CLEAR_COLOR_RGB) nun einsetze, habe ich mich auch mit COLOR_A, 
sowie SCISSOR beschäftigt und es auch tatsächlich hinbekommen hiermit 
Überblend- und Ausblendeffekte zu erzielen.

Was kann ich nun noch Probieren, um ein Bitmap, so wie im Screen-Editor 
zu sehen auch real auf mein Display zu bekommen?

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Rudolph R. schrieb:
> ein paar Sachen die EVE kann
> sind dann auch weitgehend an mir vorbei gegangen, vor allem die ganzen
> am Rande erwähnten Open_GL Features, Alpha-Blending, Scissors, die
> Transformations-Matrix. Auch zum Beispiel wofür EDGE_STRIPs gut sein
> sollen.

Das war schon am 4.6.!!!
Kann ich Dir gern erklären, wofür man EDGE_STRIPs benutzt (für mich 
unabdingbar!). Und wie schon gesagt: Alpha-Blending und Scissor 
beherrsche ich nun auch. Brauchst Du das (noch)???? Dan sag' bescheid.

[Rudolph R. (rudolph)]

Moin,

Bernd I. schrieb:
> Hallo Rudi,
> bin mit meinen Versuchen, ein Bitmap darzustellen einen großen Schritt
> weiter gekommen! Leider sehe ich am Ende auch nach vielem
> Experimentieren nur ein "verkrisseltes" Bild in der Größe ca. 35 x 35
> und das stets in der linken oberen Ecke, obwohl ich in VERTEX2II
> eindeutig die Koordinaten 100 x 100 (z.B.) eingebe.

Hmm, seltsam.

> Also: FT813! Keine Co-Prozessor-Nutzung!

Ich verstehe immer noch nicht, warum Du das machst, aber das ist soweit 
nicht das Problem.

> Benutze den FTDI-EVE-Screen-Editor. Habe mal mein Logo mit "Paint" auf
> eine Größe von 100 x 35 Pixel gebracht und als Projekt in den
> Screen-Editor als ARGB1555 geladen. Nach dem Speichern des Projekts hat
> man die RAWH-Daten. Bei 2 Bytes pro Pixel und genannter Größe sind das
> immerhin stolze 7000 Bytes. Die Schreibe ich als erstes in den RAM_G.

Sowas habe ich auch gerade gemacht. das ESE Projekt hängt an.

> Bitmap_Handle(0)
> Bitmap_Source(0)
> Bitmap_Lyout(ARGB1555, 200, 35)
> Bitmap_Size(Nearest,Border,Border,100,35)
> Bitmap_Size(0,0,0,100,35))
> Begin_Bitmaps
> Vertex2II(100, 100, 0, 0)
> END()

Praktisch so habe ich das im ESE drin, mit drei zusätzlichen Zeilen.
CLEAR_COLOR_RGB(255, 255, 255)
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)

Also Hintergrund weiß, löschen und Basis-Farbe des Bildes auch weiß.

> Große Frage: Der EVE-Screen-Editor ist zwar für den FT800,

Der EVE-Screen-Editor geht für alle von FT800 bis BT818 und in dem 
angehängten Projekt ist ein FT813 ausgewählt mit 480x272.

> Kann ich diese Bilddaten (RAWH) hier wirklich benutzen?

Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem 
EVE-Asset-Builder, aber erstmal sieht das plausibel aus.

> Irgendwie steckt in meinem Hinterkopf noch so drin, dass man
> "eigentlich" nur Bitmaps mit max. 64 x 64 darstellen kann. Aber
> Bitmap_Size sagt ja für Width und Height als erlaubte Werte je 511. Und
> wenn ich dann noch Size_H benutze, geht es ja noch größer...!
> Habe ich noch etwas ganz wichtiges vergessen?

Das ist total richtig und das sind dann 2048x2048.
Wobei ich mir da normalerweise gar keine Gedanken mache, ich benutze 
einfach CMD_SETBITMAP und das erzeugt einfach die notwendige Sequenz.

> Vor dem Darstellen des Bitmap setze ich ja z.B. einen Begrüßungstext na
> usw. Die RAM_DL-List für das Bitmap ist (zunächst) der letzte Schritt.
> Wenn ich hier NICHT Clear(1,1,1) mit CLEAR_COLOR_RGB(0,0,0) setze, wird
> das "verkrisselte" Bitmap in der Breite ca. 35 Pixel von oben bis unten
> dargestellt. Füge ich CLEAR... ein, so erscheint das 35 x 35 Bild. Gibt
> es dafür eine sinnvolle Erklärung?

So direkt fällt mir dazu nichts ein, mit der Sequenz da oben bekomme ich 
im ESE mein 100x35 Pixel Bild angezeigt.
Wobei ich VERTEX2F mit VERTEXT_FORMAT(0) vorziehe.

Eventuell ist das ein Problem mit der vorherigen Liste.


> Außer, dass ich die noch bis vor kurzem nicht benutzten Befehle CLEAR
> (mit CLEAR_COLOR_RGB) nun einsetze, habe ich mich auch mit COLOR_A,
> sowie SCISSOR beschäftigt und es auch tatsächlich hinbekommen hiermit
> Überblend- und Ausblendeffekte zu erzielen.
>
> Was kann ich nun noch Probieren, um ein Bitmap, so wie im Screen-Editor
> zu sehen auch real auf mein Display zu bekommen?

Wie war das? Du nutzt kein C?

Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das 
Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt 
werden soll.
Das kann entweder für Pulseview oder Saleae Logic 2 sein.
Einfache Logic-Analyzer die mit Pulseview laufen bekommt man schon für 
10 Euro, dann sollte man allerdings den SPI-Takt runter setzen, mehr als 
24Mhz Abtast-Rate schaffen die nicht, also mehr als 2MHz bis 4Mhz kann 
man damit nicht sinnvoll messen.

Bernd I. schrieb:
> Kann ich Dir gern erklären, wofür man EDGE_STRIPs benutzt (für mich
> unabdingbar!). Und wie schon gesagt: Alpha-Blending und Scissor
> beherrsche ich nun auch. Brauchst Du das (noch)???? Dan sag' bescheid.

Danke, ich habe da nur bisher keine Verwendung für gefunden.
Was kann man mit Edge-Strips anfangen? Ich schaue gerade auf die vier 
Bilder im Programming-Manual und mir fällt nichts ein für das ich sowas 
schon mal hätte verwenden können.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Ein geschichtsträchtiger Morgen:
Mein Logo erscheint auf dem Display!!!
Habe es mal auf 50 x 17 gekürzt. DENNOCH: Es sitzt immer noch in der 
Ecke oben links, statt auf 200 x 200 (X , Y). Na den Fehler finden wir 
noch...

Rudolph R. schrieb:
> Praktisch so habe ich das im ESE drin, mit drei zusätzlichen Zeilen.
> CLEAR_COLOR_RGB(255, 255, 255)
> CLEAR(1, 1, 1)
> COLOR_RGB(255, 255, 255)

Brachte keinen Unterschied. Es hat auch nichts mit dem vorherigen 
Bildaufbau zu tun. Habe das mal übersprungen und nun nach dem großen 
Erfolg wieder aktiviert: Bleibt alles, wie es ist: Das kleine Logo (50 x 
17) steht "sauber" oben links in der Ecke...
Ich vermute mal, dass ich bei den 7000 Bytes irgendwo ein Vielfaches von 
32 oder 64 nicht richtig gelesen (geschrieben) habe. Lese die Daten im 
Moment vom Flash, da muss man diese Vielfache beachten. Später sollen 
die Daten dann als Editor-Datei in einen USB-Stick, der On-Board ist.

Rudolph R. schrieb:
> Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das
> Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt
> werden soll.

??????????????? Um Gottes willen!!!!
Ja, nach wie vor KEIN "C"! Immer noch in Basic. Ich schreibe das nur so 
in dieser Form hier, dann weißt Du (und jeder andere) gleich, was 
gemeint ist, also in der Form, wie es im Programmer-Guide steht.
Und immer noch kein Co-Prozessor! Alles eins nach dem anderen!

Überblenden von einem Bild zum Anderen mit SCISSOR:
Display 800 x 480
1. Start-Koordinaten in der Mitte des Bildschirms definieren: X=400, 
Y=240
2. Start-Größe des aufzublenden Bildes definieren (minimal): Höhe=1, 
Breite=2

3. For-Next-Schleife

For Var16 = 0 to 399
Beginn RAM_DL
Bildschirm komplett mit Farbe, Text etc. setzen (Bild VOR dem 
Überblenden)
Display(0)   'Bild VOR SCISSOR erscheint
SCISSOR_XY(X,Y)
SCISSOR_SIZE(Breite,Höhe)
clear(1,0,0)  'Ich glaube, das ist wichtig, funktioniert sonst nicht

Beginn RAM_DL
Bild NACH SCISSOR schreiben
Display(0)   'Bild NACH SCISSOR erscheint von Mitte immer größer werdend
  Breite = Breite + 2 : Höhe = Höhe + 2  'Bildausschnitt für Bild NACH
                                         SCISSOR langsam vergrößern UND 
...
  X=X-1 : Y=Y-1                          '... schräg nach oben links 
wandern
Verzögerung in Millisekunden      'Geschwindigkeit des Überblendens
next          'Nächster Schleifendurchlauf

In die Schleife noch einbauen: Wenn Y=0, dann das "Y=Y-1" natürlich 
überspringen.

Das neue Bild erscheint mit der Geschwindigkeit von "Verzögerung" von 
Innen nach Aussen über dem alten Bild.

Abblenden mit COLOR_A
Eigentlich wie unter 4.26 (COLOR_A) im Programmer-Guide (FT813) als 
Beispiel beschrieben. Um nun ein komplettes Bild abzublenden, wieder 
eine For-Next-Schleife ausführen, wobei Alpha von 255 bis gewünschten 
Minimum (bestenfalls Null) abwärts zählt
In Basic sieht das so aus:
For Alpha = 255 to 0 Step -1
Beginn RAM_DL
Bild setzen
Display(0)
Color_A(Alpha)
Verzögerung (Geschwindigkeit des Abblendens)
next

ODER auch nur Teile eines Gesamtbildes langsam ausblenden
For Alpha = 255 to 0 Step -1
Beginn RAM_DL
Bild-Teile setzen, die nicht ausgeblendet werden sollen
Color_A(Alpha)
Bild-Teile setzen, die ausgeblendet werden sollen
Display(0)
Verzögerung (Geschwindigkeit des Abblendens)
next

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Logo erscheint nun an gewünschter Stelle X,Y. Ich weiß es absolut nicht, 
was ich bei VERTEX2II falsch gemacht hatte. Habe lediglich festgestellt, 
dass ich das ja schon vor Jahren definiert hatte im Zusammenhang mit 
Text schreiben. Nur dass hier eben "Fonts" = "Handle" ist und der ASCI = 
"Cell" und beide Werte nun Null sein sollten. Also habe ich diese uralte 
Routine aufgerufen und siehe da es geht. Was leider aber trotz aller 
Sorgfalt immer noch nicht geht, ist das große Logo 100x35. Gleiche 
Erscheinung (nur jetzt auch nicht mehr Ecke oben links, sondern auf 
angegebenen Koordinaten), "verkrisseltes" kleines Bild.
Alles ist gegenüber dem Logo 50x17 identisch. Nur eben natürlich mehr 
Daten in den RAM_G schreiben und die Parameter LineStride, sowie Height 
und Width anpassen.
Was kann hier noch falsch sein ??????????

Noch mal zu Deiner Frage, was soll ich mit EDGE_STRIP:
Wie zeichnest Du ein Parallelogramm oder ein Dreieck? Sicherlich auf 
Deine Art (mit Co-Prozessor nehme ich mal an).
Ein Parallelogramm setze ich z.B., indem ich von links nach rechts die 
Seiten mit EDGE_STRIP_R setze. Voraussetzung ist allerdings eine 
homogene Hintergrund-Farbe.
Setze die 3 Koordinaten der linken Kante mit der gewünschte Füllfarbe 
des Parallelogramms. Setze die 3 Koordinaten der rechten Kante mit der 
Hintergrund-Farbe (bzw. eben der Farbe, die rechts vom Parallelogramm 
erscheinen soll). Ich weiß, jetzt krempeln sich dir alle Fußnägel hoch 
:):):).
Aber dafür könnte man es verwenden!!! Und habe es verwendet, z.B. eine 
offen stehende Tür, incl. Türschild (Tür-Klinke)...

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Nur zur Info:
Logo 100x35 geht jetzt auch. Fehler war eindeutig in meiner Software 
beim Generieren der Var32 für das Setzen beim Befehl BITMAP_LAYOUT ...

[Rudolph R. (rudolph)]

Bernd I. schrieb:
>> Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das
>> Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt
>> werden soll.
>
> ??????????????? Um Gottes willen!!!!
> Ja, nach wie vor KEIN "C"! Immer noch in Basic.

Ja nun, genau aus dem Grund die Idee einen Level tiefer anzusetzen.
Ich schaue mir den SPI Output regelmäßig mit dem Logik-Analyzer an, vor 
allem wenn ich Support für einen neuen Controller einbaue.

Denn dabei kommt oft genug sowas hier raus:
https://github.com/RudolphRiedel/FT800-FT813/discussions/32

Wenn ich jetzt rein auf das Display schauen würde, dann könnte ich 
vorschnell zu dem Ergebnis kommen, dass das nicht nur funktioniert, 
sondern auch benutzbar ist.
In dem konkreten Fall ist die unter der Arduino SPI Klasse liegende HAL 
so seltsam programmiert, dass der SPI mit angezogener Handbremse läuft.
Ich habe auch die HAL direkt manipulieren können weil die als Quelltext 
vorliegt, ich konnte ohne negative Seiteneffekte mehrere Zeilen 
auskommentieren und den SPI so beschleunigen.
Und das kommt nicht etwa von irgendwem, das kommt vom Hersteller des 
Controllers.
Im Gegensatz zu dem noch seltsameren Verhalten von z.B. ESP32 ist da 
nicht mal ein RTOS im Spiel und der Controller hat auch nur einen Kern.

Wenn Du jetzt auf der obersten Ebene alles richtig machst heißt das noch 
lange nicht, dass die Daten auf dem SPI auch so raus kommen wie 
beabsichtigt.

Bernd I. schrieb:
> Noch mal zu Deiner Frage, was soll ich mit EDGE_STRIP:
> Wie zeichnest Du ein Parallelogramm oder ein Dreieck?

Gar nicht. :-)
Und das Problem das ich mit dem EDGE_STRIP habe ist, das ist an eine 
Kante des Displays gebunden, damit kann man nicht mal eben ein Dreieck 
mitten auf den Bildschirm malen.
Und so bleibe ich bei RECT und POINT, zumal man Rechtecken mit der 
LINE_WIDTH auch gerundete Ecken verpassen kann.

Ach so, der Punkt ist auch schnell überschritten an dem es sich eher 
lohnt eine Grafik zu verwenden, alleine schon weil man damit weniger 
über den SPI schicken muss.

[Alf S. (alfsch)]

Hallo Rudolph,
ich habe deine Lib verwendet, mit einem STM32H7A3 und 7" TFT von 
Newhaven, als kleines Test-projekt in der STM32CubeIDE, läuft ohne viel 
tamtam ganz fein.
wenn es dich (oder andere..) interessiert, poste ich die wichtigen 
Punkte , bzw die source. (oder auf git , wenn das besser ist :-)
die SPI läuft mit 24 Mbit, ein screen update dauert etwa 500us (ohne 
jegliche Optimierung oder DMA ), soweit ganz ok. CPU Last liegt somit 
bei 5% für Graphik mit maximaler Geschwindigkeit, also mit rund 60Hz 
update rate.

könnte auch ein kleines Video von der Demo machen, mit bewegter Graphik 
;)

[Rudolph R. (rudolph)]

Äh, ok, meinst Du nicht, dass ein 280MHz Cortex-M7 mit 2MB Flash und 100 
Pins aufwärts ein klein wenig übertrieben ist? :-)
Ok, machen was geht halt, aber das Monster hat sogar einen eingebauten 
Grafik-Controller. :-)

Ich spiele gerade mit einem K32L2B3 rum, nur um das mal gemacht zu 
haben.
Das ist ein Cortex M0+ mit 48MHz und Laufen hatte ich den an dem 7" mit 
1024x600 zumindest schon.

So grundsätzlichen Support für diverse STM32 Familien habe ich ja schon 
eingebaut.
Aber es ist nicht so, als ob man irgendwelche interessanten STM32 gerade 
kaufen könnte.
DigiKey hat zum Beispiel gerade nur 17 verschiedene auf Lager, 9 davon 
im BGA Gehäuse.
Die restlichen 8 sind nicht geeignet mich von den ATSAMC21 / ATSAME51 
abzubringen die ich im Moment verwende.
Und ich weiß ich habe da auch noch nichts fertiges, aber so einen 
Controller ohne DMA zu nutzen ist irgendwie verschwendet. :-)

Aus Neugier habe ich gerade mal versucht H7 Support einzufrickeln, so 
für ein nucleo_h743zi da PlatformIO kein Board mit dem STM32HA3 zu 
kennen scheint.
Das compiliert nur spontan nicht, da es in der H7 LL_SPI HAL Library die 
Funktionen LL_SPI_IsActiveFlag_TXE() und LL_SPI_IsActiveFlag_RXNE() wohl 
nicht gibt.
Wenn ich die Zeilen auskommentiere baut es durch, "stm32cube", nur fehlt 
in meinem "Beispiel" der ganze Code drum herum, also was man so in der 
STM32CubeIDE als Grundgerüst generieren würde.

Also wenn Du die notwendigen paar angepassten Zeilen für spi_transmit() 
und spi_receive() posten magst, dann füge ich die gerne noch ein.

[Alf S. (alfsch)]

nu ja, der H7A3 ist nicht unbedingt nötig :)
aber: er war eben noch lieferbar... (neue Zeit, neue Regeln...)
aktuell ist ja fast nix lieferbar.

hier die Demo:
https://youtu.be/f-EG9uTTJ5k

Snoopy lässt grüssen !

[Rudolph R. (rudolph)]

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

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudolph,
zunächst mal vorab:
Rudolph R. schrieb:
> Und das Problem das ich mit dem EDGE_STRIP habe ist, das ist an eine
> Kante des Displays gebunden, damit kann man nicht mal eben ein Dreieck
> mitten auf den Bildschirm malen.
Das verstehe ich nicht! Bei EDGE_STRIP setzt Du doch beliebige 
Koordinaten, egal wohin!!! So (und nicht anders) setze ich Dreiecke / 
Parallelogramme etc. mitten in das Display:
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
LINE_WIDTH(256)
CLEAR(1, 1, 1)
BEGIN(EDGE_STRIP_R)
VERTEX2II(20, 65, 0, 0)      'Linke Ecke des Dreiecks
VERTEX2II(100, 100, 0, 0)    'Spitze Unten
COLOR_RGB(0, 0, 0)           'ab rechter Kante wieder schwarz
VERTEX2II(100, 100, 0, 0)    'Spitze Unten
VERTEX2II(180, 65, 0, 0)     'Rechte Ecke des Dreiecks
END(0)
DISPLAY(0)
Na klar, das geht eben nur, wenn man einen homogenen Hintergrund hat!
Aber da Du das ja sowie so gar nicht nutzt ...

Habe die letzten Tage viel experimentiert.
Danke für den Tip (Bemerkung):
Rudolph R. schrieb:
> Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem
> EVE-Asset-Builder, aber erstmal sieht das plausibel aus.
Das geht, wenn man eben nur die Bilddaten konvertieren möchte besser 
(ist übersichtlicher, einfacher). Zum Experimentieren ist der 
EVE-Screen-Editor trotzdem nicht schlecht. Man kann im Vorfeld so 
einiges Probieren...
MERWÜRDIG: Ein stichprobenartiger Vergleich der Daten ein und des selben 
Bildes, konvertiert einmal mit Screen-Editor und einmal mit 
Asses-Builder zeigt recht gravierende Unterschiede!!! Die Darstellung 
ist aber dennoch identisch, zumindest fürs menschliche Auge.

Da meine Hardware schon lange vorher fertig war, habe ich nun (nur ein 
kleines) Problem: Die Bilddaten schnell genug aus den USB-Stick zu 
bekommen.
Da ich mich nicht mit FAT32 und dem ganzen "USB-Gedöhns" auskennen, 
nutze ich den VNC1L (von FTDi), jedoch nicht den fertigen VDIP1, sondern 
eigentlich die Schaltung, so wie sie auf dem VDIP1 drauf ist, in meine 
Applikation komplett integriert. Den "blanken" Chip VNC1L programmiere 
ich vor dem Bestücken mit dem VPROG.
Bei der Schaltung nutze ich LEIDER die Kommunikationsart UART, obwohl 
dieser VNC1L auch SPI und sogar parallel-FIFO kann,  was ja alles viel, 
viel schneller ginge. Aber zum Experimentieren ist es erst mal super. 
Baudrate habe ich auf 1 Mega-Baud. Da benötigt die Grafik 
(Display-Füllend 3,5 Zoll) 320 x 240 eben ca. 6 Sekunden, ehe sie im 
RAM-G ist (besser gesagt: Ehe sie vom Stick herunter ist).
Ich hole die Daten ab (kommen ja als 2 ASCI, dann ein Leerzeichen, also 
3 Byte pro RAM-Byte), bilde SOFORT aus den ASCI das RAM-Byte und schiebe 
es per SPI in den RAM, während das nächste Byte vom VNC1L abgeholt wird. 
Dieses parallele Arbeiten (UART // SPI) funktioniert einwandfrei und ich 
brauch es nicht blockweise zu machen (erst 256 Bytes abholen, daraus ca. 
115 RAM-Bytes bilden, in den RAM schieben, die nächsten abholen, ständig 
mitrechnen ...). Und alles mit einem male abholen geht ja eben nicht, da 
ich nicht weiß, wohin mit den rund 430.000 Byte, wenn man keinen 
zusätzlichen RAM hat, sondern "nur" den PIC mit 128.000 Flash und 3800 
RAM.

Eigentlich bin ich nun VORERTS am Ziel meiner Wünsche (nächste Hardware 
mit Parallel-FIFO am VNC1L ist schon in Arbeit). Nun gibt es allerdings 
ein Phänomen. Ob das jemand kennt? :
Durch einen Zufall (ein Fehler in meiner Software) stellte sich das Bild 
nur in 64-Pixel Breite da (volle Höhe 240). Dabei war ein senkrechter 
hellgrauer Streifen (ca. 50 breit und mitten in diesen 64 Pixel) absolut 
top so dargestellt, wie er sollte. Nachdem ich dann nach 
Fehlerbeseitigung das ganze Bild sah, ist dieser Streifen und auch alles 
andere rechts neben den 64-Breite nach unten hin immer schwächer. Man 
sieht den hellgrauen Streifen unten so gut wie gar nicht mehr. Also habe 
ich mal eine Schleife gesetzt und von 64 Breite beginnend alle 100ms das 
Bild um einen Pixel wachsen lassen:
BITMAP_SIZE(NEAREST, BORDER, BORDER, 64...320, 240)
Und siehe da: Beginnend mit dem scharf gleichmäßig durchgehenden grauen 
Streifen links wurde er allmählich nach unten hin immer schwächer, je 
breiter das Bild wurde !!! ????
Den gleichen Versuch auf einem 7 Zoll Display, mal in die Mitte die 320 
x 240 gesetzt. Hier ist es nicht so, jedoch sind hier alle hellgrauen 
Streifen komplett so gut wie nicht zu sehen. Nur wenn ich mit einem 
Blickwinkel von mind. 45° drauf schaue, wird es so, wie das Original...
Beim 3,5 Zoller kann ich schief schauen, so viel ich will. Es bleibt 
dabei, dass das Bild nach Unten hin immer schwächer wird. So als wenn 
man den ALPHA-Channel nach unten hin immer größer werden lässt.
Hast Du eine Idee, ob man dagegen was unternehmen kann...???

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Das verstehe ich nicht! Bei EDGE_STRIP setzt Du doch beliebige
> Koordinaten, egal wohin!!! So (und nicht anders) setze ich Dreiecke /
> Parallelogramme etc. mitten in das Display:
> CLEAR(1, 1, 1)
> COLOR_RGB(255, 255, 255)
> LINE_WIDTH(256)
> CLEAR(1, 1, 1)
> BEGIN(EDGE_STRIP_R)
> VERTEX2II(20, 65, 0, 0)      'Linke Ecke des Dreiecks
> VERTEX2II(100, 100, 0, 0)    'Spitze Unten
> COLOR_RGB(0, 0, 0)           'ab rechter Kante wieder schwarz
> VERTEX2II(100, 100, 0, 0)    'Spitze Unten
> VERTEX2II(180, 65, 0, 0)     'Rechte Ecke des Dreiecks
> END(0)
> DISPLAY(0)

Das macht zwar ein Dreieck, aber wenn ich nur eine Koordinate verändere 
dann nicht mehr:

CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
LINE_WIDTH(256)
CLEAR(1, 1, 1)
BEGIN(EDGE_STRIP_R)
VERTEX2II(20, 65, 0, 0)
VERTEX2II(100, 100, 0, 0)
COLOR_RGB(0, 0, 0)
VERTEX2II(100, 100, 0, 0)
VERTEX2II(180, 75, 0, 0)
END(0)

Das ist jetzt nur der letzte Punkt 10 Pixel weiter runter.
Also mit "beliebige Koordinaten" wird das nichts, eben weil die 
Edge-Strips jeweils bis an den Rand gehen.

>> Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem
>> EVE-Asset-Builder, aber erstmal sieht das plausibel aus.
> Das geht, wenn man eben nur die Bilddaten konvertieren möchte besser
> (ist übersichtlicher, einfacher). Zum Experimentieren ist der
> EVE-Screen-Editor trotzdem nicht schlecht. Man kann im Vorfeld so
> einiges Probieren...

Definitiv, das Edgestrip Beispiel habe ich gerade im ESE offen.
Es gab übrigens gerade einen neuen ESE: 4.2.0

> MERWÜRDIG: Ein stichprobenartiger Vergleich der Daten ein und des selben
> Bildes, konvertiert einmal mit Screen-Editor und einmal mit
> Asses-Builder zeigt recht gravierende Unterschiede!!! Die Darstellung
> ist aber dennoch identisch, zumindest fürs menschliche Auge.

Welchen EAB hast Du?
Aber davon mal ab, Zumindest der EVE Asset Builder hat leider per 
Default die Option "Dithering" für Bilder an, der überlagert beim 
Konvertieren also praktisch die Bilder mit Rauschen.
Und da stehe ich überhaupt nicht drauf, ich fütter das Ding doch nicht 
mit PNG Dateien damit das nach dem Konvertieren anders ist.
Außerdem verringert das die Komprimierbarkeit mindestens mit zlib.

> Da meine Hardware schon lange vorher fertig war, habe ich nun (nur ein
> kleines) Problem: Die Bilddaten schnell genug aus den USB-Stick zu
> bekommen.
> Da ich mich nicht mit FAT32 und dem ganzen "USB-Gedöhns" auskennen,
> nutze ich den VNC1L (von FTDi),

Mit nichts von dem habe ich hinreichend Erfahrung, aber bis auf das ich 
schon mal einen Arduino mini in einem Projekt verwenden musste hatte ich 
bisher auch noch keine Probleme mit den Assets.

Wobei zur Zeit, ja, normalerweise benutze ich Controller mit 512k oder 
256k Flash, nur jetzt habe ich gerade von denen mit 256k nur welche 
bekommen die lediglich 64k haben, was man eben so bekommen kann...

> Baudrate habe ich auf 1 Mega-Baud. Da benötigt die Grafik
> (Display-Füllend 3,5 Zoll) 320 x 240 eben ca. 6 Sekunden, ehe sie im
> RAM-G ist (besser gesagt: Ehe sie vom Stick herunter ist).

Ugh, Autsch.

> Ich hole die Daten ab (kommen ja als 2 ASCI, dann ein Leerzeichen, also
> 3 Byte pro RAM-Byte),

Das ist übel ineffizient.

> bilde SOFORT aus den ASCI das RAM-Byte und schiebe
> es per SPI in den RAM, während das nächste Byte vom VNC1L abgeholt wird.
> Dieses parallele Arbeiten (UART // SPI) funktioniert einwandfrei und ich
> brauch es nicht blockweise zu machen (erst 256 Bytes abholen, daraus ca.
> 115 RAM-Bytes bilden, in den RAM schieben, die nächsten abholen, ständig
> mitrechnen ...). Und alles mit einem male abholen geht ja eben nicht, da
> ich nicht weiß, wohin mit den rund 430.000 Byte, wenn man keinen
> zusätzlichen RAM hat, sondern "nur" den PIC mit 128.000 Flash und 3800
> RAM.

Warum hast Du die Bilder unkomprimiert auf dem Stick?
Ich habe mir gerade mal ein möglichst chaotisches Bild gesucht, auf 
320x240 geschnitten und zu RGB565 konvertiert.
Das sind 153600 Bytes wie erwartet.
Wenn ich das entweder durch den "Asset Compressor" schicke oder beim 
Konvertieren den Haken bei "Compressed" drin habe, dann werden das 50574 
Bytes.
Gleich noch mal die Probe mit "Dithering" an - Ugh, 81506 Bytes.

Also auf die Hälfte kommt man schon runter, eher wird es noch weniger.
Ich habe gerade mal ein Hintergund Bild aus dem Netz gefischt und 
inklusive Watermark drin auf 320x240 konvertiert und bei 80% als .jpg 
gespeichert.
Komprimiert hat das 41305 Bytes.
Das sind so 27% und müssten unter gleichen Bedingungen in unter 1,7s 
übertragen sein. Auch nicht toll, aber besser als 6s.
Geladen wird das dann mit CMD_INFLATE.

> Durch einen Zufall (ein Fehler in meiner Software) stellte sich das Bild
> nur in 64-Pixel Breite da (volle Höhe 240).
>......
> Hast Du eine Idee, ob man dagegen was unternehmen kann...???

Ich kann nicht behaupten das ich sowas ähnliches schon mal beobachtet 
hätte.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Rudolph R. schrieb:
> Das macht zwar ein Dreieck, aber wenn ich nur eine Koordinate verändere
> dann nicht mehr:
>
> CLEAR(1, 1, 1)
> COLOR_RGB(255, 255, 255)
> LINE_WIDTH(256)
> CLEAR(1, 1, 1)
> BEGIN(EDGE_STRIP_R)
> VERTEX2II(20, 65, 0, 0)
> VERTEX2II(100, 100, 0, 0)
> COLOR_RGB(0, 0, 0)
> VERTEX2II(100, 100, 0, 0)
> VERTEX2II(180, 75, 0, 0)
> END(0)

Das ist korrekt, was Du sagts. Aber um z.B. ein Dreieck zu erhalten, 
musst Du eben den letzten Punkt auf die gleiche Höhe setzen. Und man 
kann beliebig viele Punkte setzen. Muss aber natürlich dabei wissen, was 
man tut. Und soll eine durchgehende Verbindungs- (Zick-Zack-Linie) 
beendet und da neben neu gesetzt werden (um ein "Zick-Zack-Rechteck zu 
erhalten), muss Du End(0) und wieder Begin(Edge_Strip_R) mit der Farbe 
rechts vom Rechteck setzen, da sonst die Linie weiter geführt wird.

Das ist schon interessant, was ich hier von Dir immer wieder so 
"nebenbei" herauslese. Ich frage nach einem konkreten Problem, bei dem 
Du mir (leider) nicht helfen kannst, aber beschreibts z.B. das 
"Dithering". Bei der Suche nach dem beschriebenen Phänomen habe ich 
schon mit dem Register "REG_DITHER" experimentiert. Hat nichts gebracht, 
ohne zu wissen, was dieses Register wirklich ändert. Denn "Dither" heißt 
ja "zittern" und "Dithering" heißt "schwankend". Wie soll man also auf 
"Rauschen" kommen, wenn beim Builder das Häkchen gesetzt ist. Das 
probiere ich noch aus, ob es hier dann einen Unterschied gibt. Kann das 
nicht einfach dann "Noise" heißen ???

Das Thema Kompression ist mir im Moment noch zu schwierig, da ich dann 
ja wieder auf den Co-Prozessor zugreifen muss. Ist immer noch kein 
Thema. Wie schon gesagt, ist auch nicht wirklich schlimm. Später nutze 
ich die schnelle Verbindung vom USB zum RAM-G. Und ein Komprimieren nach 
meiner Art kann ich dann auch noch machen und weiß dann auch, wie ich es 
beim Auslesen entschlüsseln (dekomprimieren) kann. Viele Bytes sind 
nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine 
Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche 
Bytes", dann eine 17 (17 mal das folgende Byte) und dann ein FF. Also 
aus 17 Bytes sind so 3 Bytes geworden. Mit ")" (Hex 29) kündigt man 2 
wechselnde Byte an, was auch sehr oft ist, da ja gleiche Pixel bei 2 
Byte pro Pixel diesen Wechsel ergeben. z.B. 12 Folgen von dem Wechsel 
der beiden Bytes 9C und 67: Hx29 Hx0C Hx9C Hx67. Aus 24 Byte sind 4 
geworden ...
Das mache mit einem eigenen "Komprimierer" (wenn es dann mal 
erforderlich ist).
So jage ich z.B. auch meine eigenen Update-Dateien, die an Kunden gehen, 
vorher durch einen "Verschlüsseler". Die Datei wird dann im Gerät beim 
Update wieder von dem Gerät entschlüsselt (da alle meine Update-fähigen 
Geräte einen einheitlichen Schlüssel dafür haben).
Einen schönen Abend noch !!!

[Rudolph R. (rudolph)]

> Das ist korrekt, was Du sagts. Aber um z.B. ein Dreieck zu erhalten,
> musst Du eben den letzten Punkt auf die gleiche Höhe setzen. Und man
> kann beliebig viele Punkte setzen. Muss aber natürlich dabei wissen, was
> man tut. Und soll eine durchgehende Verbindungs- (Zick-Zack-Linie)
> beendet und da neben neu gesetzt werden (um ein "Zick-Zack-Rechteck zu
> erhalten), muss Du End(0) und wieder Begin(Edge_Strip_R) mit der Farbe
> rechts vom Rechteck setzen, da sonst die Linie weiter geführt wird.

Ja genau, einfach mal so ein Dreieck zu malen ist damit nicht möglich. 
:-)
Aber der eigentliche Knackpunkt ist das ich Dreiecke bisher auch nicht 
wirklich vermisst habe.
Und was eben wirklich einfach geht sind Rechtecke, auch mit abgerundeten 
Ecken.

> Das ist schon interessant, was ich hier von Dir immer wieder so
> "nebenbei" herauslese. Ich frage nach einem konkreten Problem, bei dem
> Du mir (leider) nicht helfen kannst, aber beschreibts z.B. das
> "Dithering". Bei der Suche nach dem beschriebenen Phänomen habe ich
> schon mit dem Register "REG_DITHER" experimentiert. Hat nichts gebracht,
> ohne zu wissen, was dieses Register wirklich ändert. Denn "Dither" heißt
> ja "zittern" und "Dithering" heißt "schwankend". Wie soll man also auf
> "Rauschen" kommen, wenn beim Builder das Häkchen gesetzt ist. Das
> probiere ich noch aus, ob es hier dann einen Unterschied gibt. Kann das
> nicht einfach dann "Noise" heißen ???

REG_DITHER macht was vergleichbares, im Grunde soll es die Ausgabe 
verbessern indem harte Übergänge reduziert werden.
Nur während sich REG_DITHER auf die Ausgabe auswirkt, verändert das 
Dithering die Bilder bei der Konvertierung was sich wiederrum auf die 
Komprimierbarkeit auswirkt.
Das sagt nichts darüber aus ob das resultierende Bild besser oder 
schlechter aussieht, es lässt sich nur schlechter komprimieren und die 
Pixel die man da rein steckt sind nicht die Pixel die man da raus 
bekommt.

Ich habe gerade noch mal aus Jux ein Bild gepixelt, einfach ein paar 
Sterne ohne aktiviertes Anti-Aliasing.
Ohne Dithering komprimiert das auf 2661 Bytes, mit auf 3707 Bytes.

Es kann sogar sein, dass dieses Bild mit Dithering besser aussieht.

> Das Thema Kompression ist mir im Moment noch zu schwierig, da ich dann
> ja wieder auf den Co-Prozessor zugreifen muss.

Ja, das ist richtig.

> Und ein Komprimieren nach
> meiner Art kann ich dann auch noch machen und weiß dann auch, wie ich es
> beim Auslesen entschlüsseln (dekomprimieren) kann. Viele Bytes sind
> nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine
> Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche
> Bytes",

Ja, nennt sich Runtime Encoding, damit kommt man aber nicht ganz so weit 
wie mit der zlib Kompression die EVE bereits eingebaut hat. :-)

Dabei hatte ich gerade ein C64 Flashback. :-)

Nein, im Ernst, ein großer Vorteil ist ja das die Daten dann komprimiert 
über den SPI gehen. Also der Controller muss da gar nichts entpacken.

[Alf S. (alfsch)]

>Also wenn Du die notwendigen paar angepassten Zeilen für spi_transmit()
und spi_receive() posten magst, dann füge ich die gerne noch ein.

mit dem Projekt, in der STM32cubeIDE mit HAL lib, ohne jegliche 
Optimierung oder DMA , dauert ein Bild zu übertragen ca. 500us ; daher 
habe ich vorerst den Aufwand mit der DMA sein lassen, weil das die 
CPU-Last natürlich verrringern würde. aber der zu erwartende Gewinn von 
ca. 5% auf 2% runter zu kommen -- keine wirkliche Bedeutung hat.
hier die HAL Aufrufe:

 void spi_transmit(uint8_t data)
{
  HAL_SPI_Transmit(&hspi5, &data, 1 , 5);
}

uint8_t spi_receive(uint8_t data)
{
  uint8_t  dain;
  HAL_SPI_TransmitReceive(&hspi5, &data, &dain, 1 , 5);
  return (dain);
}


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

#define EVE_EVE2_70G                // neu für :  NHD-7.0-800x480FT-CTXL-T, EVE2
#define EVE_HAS_CRYSTAL            // TFT hat 12 MHz extern

/* Matrix Orbital EVE2 modules EVE2-50G, EVE2-70G : 800x480 5.0" and 7.0" capacitive touch, FT813 */
/* Crystalfonts CFAF800480E0-050SC 800x480 5.0" , FT813 capacitive touch */
// NewHaven NHD-7.0-800480FT-CSXV-T
#if defined (EVE_EVE2_50G) || defined (EVE_EVE2_70G) || defined (EVE_CFAF800480E0_050SC)
#define Resolution_800x480
#define EVE_PCLK  (2L)
#define EVE_PCLKPOL  (1L)
#define EVE_SWIZZLE  (0L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (4800L)
#define EVE_GEN 2
//#define EVE_HAS_GT911  /* special treatment required for out-of-spec touch-controller */
#endif

[Rudolph (Gast)]

Alf S. schrieb:
> hier die HAL Aufrufe:

Hmm, hast Du einen Logic-Analyzer?
Zeiche das wenn möglich mal auf, das kann auch bei deutlich niedrigerem 
SPI Takt sein, 2MHz oder 4MHz, mich interessiert da vor allem wie lang 
die Pause zwischen den einzelnen Bytes ist.

[Alf S. (alfsch)]

na gut , einfach schnell Bild mit DSO gemacht, am TFT mit ca. 30cm 
Flachbandkabel davor ...
und nein, der Takt kann nicht anders sein, als ich ihn will/einstelle. 
Dazu muss im cube nur der clock-tree entsprechend eingastellt werden, 
hier auf 100MHz für die SPI unit und div4 in der SPI.
wie gesagt, mit 25MHz clk, die langen (1,8us) delays zwischen den Bursts 
kommen daher, wie schon gesagt, dass ich einfach die HAL lib Aufrufe 
benutzt habe, auch für das setzen der CS bit hi/lo , was ja jeweils in 
mindestens ein zwei Subroutinen verzweigt und daher ....dauert.
mit etwas mehr Zeit für das Ganze, würde ich erstmal die CS-bit setzen 
mit einem direkten write auf das Portrefister, das dauert dann statt 
rund 1us etwa 10ns , auch beim SPI Aufruf. DANN könnte man noch die DMA 
anwerfen und die CPU-Last auf < 1% bringen, bei maximaler "Action" (wie 
die bewegten Dreiecke, die ja bei jeden Bildaufbau des TFT andere 
Koordinaten haben)

[Rudolph (Gast)]

Genau so was habe ich befürchtet, keine Ahnung warum die Hersteller alle 
Bitcoin-Miner in die Treiber einbauen. :-)

Für CS ist die Verzögerung in Ordnung, das passiert ja nur zwei Mal.

Du könntest mal die LowLevel HAL verwenden wie ich das für die anderen 
STM32 schon vorgesehen habe, also stm32h7xx_ll_spi.h einbinden.

Blöderweise haben die Status-Flags im H7 leicht andere Namen.
Ich habe da gestern mal kurz reingeschaut, das hier könnte 
funktionieren, ist aber blind eingetippt.
Damit sollten die Pausen deutlich kleiner werden, da das im Grunde ja 
direkter Register-Zugriff ist.

static inline void spi_transmit(uint8_t data)
{
  LL_SPI_TransmitData8(EVE_SPI, data);
  while(!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {};
  while(!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {};
  LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXWNE */
}

static inline uint8_t spi_receive(uint8_t data)
{
  LL_SPI_TransmitData8(EVE_SPI, data);
  while(!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {};
  while(!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {};
  return LL_SPI_ReceiveData8(EVE_SPI);
}

[Alf S. (alfsch)]

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

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

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

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

#define EVE-cs_set()   GPIOF->BSRR = 0x0020

dann wird es wirklich flott, ca. 17ns hatte ich mit einem STM32F411 
gemessen für port -> lo + wieder -> hi setzen; bei dem H7A3 würde es 
wohl in 10ns laufen, sprich man muss evtl noch delays einfügen, weil die 
CPU sonst zu schnell für die anderen chips ist.
und bei so sofware erzeugten CS Signalen ist dann die DMA auch sinnlos, 
weil man für das CS->hi ja auf das Ende der DMA / SPI action warten 
muss, bis das CS hi gesetzt wird oder einen INT am DMA ready erzeugt, 
was dann aber vmtl genauso viel CPU Takte benötigt.
+ nebenbei: ich habe beim core D- und I- cache ON , somit wird die 
Benutzung der DMA echt komplex, da dann per MPU sichergestellt werden 
muss, dass die Speicherbereiche der DMA Transfers "dirty" sind, bzw vom 
cache ausgeschlossen sind. DAS war mir zu komplex, für den potentiellen 
"Gewinn" von ein paar Mikrosekunden.

und der SPI send entsprechend auch als ein Befehl:

 SPI5->TXDR = data;

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

[Rudolph (Gast)]

Alf S. schrieb:
> und bei so sofware erzeugten CS Signalen ist dann die DMA auch sinnlos,
> weil man für das CS->hi ja auf das Ende der DMA / SPI action warten
> muss, bis das CS hi gesetzt wird oder einen INT am DMA ready erzeugt,

Deshalb nutze ich dafür ja auch einen Interrupt.
Jetzt nicht für die STM32, okay, aber bei den ATSAM sieht man das zum 
Beispie in der EVE_target.c in der DMAC_Handler() Funktion.

Erst noch warten das der letzte Transfer durch ist, dann CS wieder hoch 
ziehen.

> + nebenbei: ich habe beim core D- und I- cache ON , somit wird die
> Benutzung der DMA echt komplex, da dann per MPU sichergestellt werden
> muss, dass die Speicherbereiche der DMA Transfers "dirty" sind, bzw vom
> cache ausgeschlossen sind.

Oha, sowas ist mir zum Glück noch nicht in die Quere gekommen.

>DAS war mir zu komplex, für den potentiellen
> "Gewinn" von ein paar Mikrosekunden.

Unterschätz das mal nicht, das dürfte auf dem H7 auf locker <10µs 
schrumpfen und zwar auch bei deutlich mehr auf dem Display.

> und der SPI send entsprechend auch als ein Befehl: SPI5->TXDR = data;
> die SPI sendet automatisch, sobald ins Tx register geschrieben wird...

LL_SPI_TransmitData8(EVE_SPI, data); ist ja auch nichts anderes, nur 
hübscher verpackt. :-)
Nur wartet das eben nicht das der Transfer durch ist.

Was anderes was mir gerade noch eingefallen ist, Du könntest den DMA 
Support nutzen um ohne DMA zu verschicken.

Du hast ja vorher das hier verwendet:
HAL_SPI_Transmit(&hspi5, &data, 1 , 5);

Die Funktion schickt also einen Puffer.
Und mit DMA und den EVE_cmd_xxx_var_burst() Funktionen wird der Puffer 
über spi_transmit_burst() zusammen gebaut:

static inline void spi_transmit_burst(uint32_t data)
{
#if defined (EVE_DMA)
EVE_dma_buffer[EVE_dma_buffer_index++] = data;
#else
spi_transmit_32(data);
#endif
}

Dieser Puffer wird mit EVE_start_dma_transfer() verschickt.

Die könnte auch so aussehen:

 void EVE_start_dma_transfer(uint8_t data)
{
  EVE_cs_set();
  HAL_SPI_Transmit(&hspi5, ((uint8_t *) &EVE_dma_buffer[0])+1, (((EVE_dma_buffer_index)*4)-1) , 5);
  EVE_cs_clear();
}

Ja, Adresse und Länge sehen etwas seltsam aus, das liegt daran das als 
erstes die Adresse verschickt wird und die hat nur 3 Bytes.

Das ist zwar immer noch kein DMA, sollte aber deutlich fixer gehen.

Dazu noch ein das hier in der EVE_target.h:

#if defined (EVE_DMA)
extern uint32_t EVE_dma_buffer[1025];
extern volatile uint16_t EVE_dma_buffer_index;
extern volatile uint8_t EVE_dma_busy;

void EVE_init_dma(void);
void EVE_start_dma_transfer(void);
#endif

Die EVE_init_dma() muss vorhanden sein, wäre in diesem Fall aber einfach 
leer.

[Alf S. (alfsch)]

Hi,  also wenn schon, dann mit DMA , sonst fehlt ja der Reiz.
(zu sehen, wie schnell das Ding wirklich ist)
Habe mir das ein wenig überlegt und es sollte eigentlich ohne Probleme 
mit cache+optimizer gehen, weil es wird ja nur in den buffer geschrieben 
und dann zum EVE gesendet, aber nie per DMA zurückgelesen.
wie muss ich das eigentlich machen: mit zusätzlichem " #define H7A3 " 
und jeweils in " #if defined (STM32L073xx) ||...." entsprechend 
DMA-Kanal usw ändern bzw rein schreiben ?

[Rudolph R. (rudolph)]

So, hilft zwar jetzt noch nicht direkt mit STM32, aber ich habe gerade 
endlich mal meinen Entwicklungs-Zweig mit dem mit dem 5.x Zweig 
synchronisiert.

Da ist jetzt zum einen die STM32H7 "Erweiterung" in EVE_target.h, zum 
anderen ist jetzt das STM32 "Beispiel" enthalten.

Dieses Beispiel macht immer noch nichts sinnvolles, da in der main.c 
nicht genug drin ist und DMA unterstützt das für STM32 auch immer noch 
nicht.
Aber das baut einfach so durch für diverse STM32:

Environment    Status    Duration
-------------  --------  ------------
STM32L073      SUCCESS   00:00:02.775
STM32F030      SUCCESS   00:00:02.468
STM32F103      SUCCESS   00:00:02.587
STM32F303      SUCCESS   00:00:03.115
STM32F446      SUCCESS   00:00:03.946
STM32G474      SUCCESS   00:00:03.678
STM32G431      SUCCESS   00:00:03.499
nucleo_f439zi  SUCCESS   00:00:03.888
nucleo_h743zi  SUCCESS   00:00:06.119

Damit wird zumindest schon mal der Code in der Library einwandfrei für 
STM32 compiliert.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Nun habe ich wochenlang so diverse Bitmaps geladen und dargestellt 
(teils zum Üben, aber dann hauptsächlich sinnvoll für bestimmte 
Projekte), habe mit diversen Befehlen herumgespielt und es funktioniert 
alles tadellos. Dank des EVE Screen Editors (V4.2.0) konnte ich so 
manche "Geheimnisse" entschlüsseln bzw. mir im Vorfeld so dieses oder 
jenes anschauen, ehe ich mühselig an der realen Platinen mit Koordinaten 
und dergleichen herum probiere. Und so habe ich auch einfach mal den 
Befehl CMD_GRADIENT im EVE Editor "entschlüsselt". Selbst wenn ich den 
Co-Prozessor benutzen würde, müsste man sich den gewünschten Farbverlauf 
ohnehin am EVE zurechtschieben und dann die Koordinaten übernehmen. Ich 
habe mir dazu eine Bibliothek geschaffen, der ich vor Aufruf die entspr. 
Werte für die 2 Farben, für TransformA-F, Source usw. übergebe und 
fertig ist mein Wunsch-Farbverlauf, auch ohne Co-Prozessor.
Nun habe ich das erste mal eine Grafik 600 x 480 darstellen wollen. Das 
Original (Lageplan ohne Kuller) sieht so aus. Nach dem Experimentieren 
mit SIZE_H und SIZE_H (auch mit Hilfe des EVE schnell entschlüsselt) hat 
es dann auch geklappt. Jedoch sah das Bild dann so aus 
(ARGB1555zuARGB1555). Nach vielen diversen Versuchen mit verschiedenen 
Formaten kam ich dann mal auf die glorreiche Idee, das Bild im Format 
RGB565 darzustellen. Und siehe da, es sah aus, wie das Original. Also: 
konvertiert als ARGB1555, aber dann als RGB565 darstellen !!! Gibt es 
dazu eine Erklärung? Das ist mir vorher (mit Bildern < 511 Pixel) nie 
passiert. Im Gegenteil: Hier sah das Bild eher so aus, wenn  nicht 
Konvertierungsformat gleich Darstellung. Nun ja, so geht es zwar, aber 
ist doch merkwürdig!!???
Co-Prozessor: Hier fehlt mir jedoch noch eine Kleinigkeit. Schön wäre 
es, wenn ich einen Spinner (der sich auch selbst im Hintergrund entspr. 
"bewegt") darstellen könnte (z.B. während des Ladens der Grafiken). Ohne 
Co-Prozessor hat man dabei (wenn man es "Zu Fuß" als mit DL-Befehlen 
macht) sogar noch mehr Gestaltungsmöglichkeiten in Form, Größe, Farbe 
... Jedoch bewegt der sich ja nicht. Es reicht hier leider nicht ganz, 
die DL-Befehle so einzugeben. Dann entsteht eben nur der "stehende" 
Spinner. Hier muss zum Schluss sicher noch ein ganz bestimmtes Register 
gesetzt werden ...?????
Hast Du da eine Idee?
Nun möchte ich ja auch gleich wieder noch mehr: Den BT815 testen, um 
auch 10 Zoll-Displays beschreiben zu können. Wie für den FT8... gibt es 
hier auch diverse Demo-Boards. Jedoch habe ich kein Set mit 
10-Zoll-Display gefunden. Im Gegensatz zum VM800, die es ohne und mit (7 
Zoll) Display als Set gibt. Kennst Du so ein Set, oder ein passendes 
10-Zoll-Display (Belegung des 50-poligen Flachbandkabels !!!) zu einem 
entspr. Demo-Board?
Besinnliche Adventzeit !!! Liebe Grüße von der Ostsee.

[Rudolph R. (rudolph)]

Die Bildfrage kann man über das Forum eigentlich nicht mal versuchen zu 
beantworten, da hier automatisch das Format von PNG Bildern konvertiert 
wird, warum auch immer.
Wenn ich das runter lade und zum bearbeiten in Paint.net öffne hat das 
schon mal gar keinen Alpha-Channel.
Das kann ja Absicht sein, aber ARGB1555 passt dann nicht wirklich.

Die Animation von dem Spinner dürfte der Co-Prozessor machen, an dem 
vorbei dürfte das nicht gehen, da die Display-Liste an sich ja statisch 
ist.
Und wenn man direkt die Display-Liste schreibt kann man auch die Daten 
über den SPI nicht wirklich optimieren, Stichwort CMD_APPEND.

Die BT815 sind für 10" nicht ernsthaft geeignet, die haben nur eine PLL, 
damit ist der Pixel-Takt nur durch feste Werte teilbar.
Bridgetek hatte zwar mal eine Demo, aber 60HZ hat die bei 1024x600 eher 
nicht erreicht.
Das ist mit den BT817 viel schicker gelöst.

Das nächste Problem bei 10" ist das die meistens Displays jenseits von 
800x480 inzwischen keine RGB Schnittstelle mehr, sondern LVDS haben.
Also muss da zu dem BT817 noch ein RGB/LVDS Converter mit drauf.
Ok, es gibt 1024x600 in 7", aber das fällt quasi unter exotisch.

Ich benutze ja ohnehin nur fertige Module, für den Fall würde sich das 
aber denke ich auch zunächst anbieten.
In 10" habe ich ein RVT101HVBNWC00-B mit 1280x800 und in 7" habe ich ein 
RVT70HSBNWC00-B mit 1024x600.
Die "-B" Version ist die höchste Variante mit optical bonding.
TME hat noch je 1 Stück, Mouser hat RVT70HSBNWC00.
Mein RVT101HVBNWC00-B habe ich direkt bei Riverdi gekauft, das hat dann 
aber etwas mehr gekostet, da kam ordentlich Versand drauf.
Ach so, das RVT70H ist ohne LVDS, das RVT101H mit LVDS.

[Holger H. (sachma)]

bei ali
10.1" LCD screen EJ101IA-01G (1280x800)
Kostet zwischen 24-34 EUR

Zum Testen von unterschiedlichen Displays habe ich mir ein paar kleine 
Boards zusammengebaut.
1)Konverterplatine TTL-LVDS(50Pin->40Pin)
2)Spannungsversorgung-Platine für das Display
3)BT815/6/7/8 Board (mit BT817 bestückt)

Meistens aber nicht immer:
1024x Displays Benötigen 2) aber nicht 1)
1280x Displays Benötigen 1) 2)

je nach Display sind die Pins an den Flexprintbuchsen umzubelegen oder 
umzulöten

[Rudolph R. (rudolph)]

Heads-Up: I am currently changing the return values for EVE_busy(), 
EVE_init() and EVE_init_flash().

So far these three return an uint8 with a 0 for FALSE and a 1 for TRUE.
However, returning a zero on success is more common and also allows for 
more meaningfull values to be returned on failure.

So far I have these:

enum
{
    E_OK = 0,
    E_NOT_OK,
    EVE_FAIL_CHIPID_TIMEOUT,
    EVE_FAIL_RESET_TIMEOUT,
    EVE_FAIL_PCLK_FREQ,
    EVE_FAIL_FLASH_STATUS_INIT,
    EVE_FAIL_FLASH_STATUS_DETACHED,
    EVE_FAIL_FLASHFAST_NOT_SUPPORTED,
    EVE_FAIL_FLASHFAST_NO_HEADER_DETECTED,
    EVE_FAIL_FLASHFAST_SECTOR0_FAILED,
    EVE_FAIL_FLASHFAST_BLOB_MISMATCH,
    EVE_FAIL_FLASHFAST_SPEED_TEST
};

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

[Rudolph R. (rudolph)]

And I just pushed a small update.
EVE_busy() practically works like always with returning zero for not 
busy but no longer 1 for beeing busy but EVE_IS_BUSY which currently has 
a value of 12.

[Spyy (Gast)]

Moin,

nach einem "Ausflug" zu einem Raspi CM4 mit Linux Treiber schreiben für 
mein Display, bin ich heute zum Teensy 4.1 mit meinem Display zurück 
gekehrt.
Ich habe keinen externen Quarz und speise jetzt vom Teensy ein 12 Mhz 
PWM 50% Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit 
externer clock :-) => ich nutze den ganzen internen quatsch nicht 
mehr....
und....
Ich habe den Fehler gefunden, warum ich nicht mit mehr als ca. 25ms 
zyklus per dma auf den Chip schreiben konnte ohne das sich das System 
aufgehängt hat...
Für das zyklische DMA Schreiben habe ich im Teensy ein Intervalltimer 
benutzt. Das verheddert sich dann offensichtlich bei kürzeren Zyklus < 
25ms...keine Ahnung warum. Ich habe nun "das zyklische Schreiben" in der 
normalen Loop Schleife mit delay....und siehe da...ich kann jetzt locker 
alle 10 ms mit 25 Mhz SPI schreiben, das läuft jetzt seit heute Mittag 
ohne Probleme...super...

Noch ne Frage: Ich sehe das der BT81x überall out of stock ist und kein 
mögliches Lieferdatum...ist das die Chip Krise oder ist der Chip 
abgekündigt?

Grüsse

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> Ich habe keinen externen Quarz und speise jetzt vom Teensy ein 12 Mhz
> PWM 50% Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit
> externer clock :-) => ich nutze den ganzen internen quatsch nicht
> mehr....

Na, das ist doch auch nett. :-)

Spyy schrieb:
> Ich habe nun "das zyklische Schreiben" in der
> normalen Loop Schleife mit delay....und siehe da...ich kann jetzt locker
> alle 10 ms mit 25 Mhz SPI schreiben, das läuft jetzt seit heute Mittag
> ohne Probleme...super...

Ich mach das in meinem Arduino Beispiel ja mit millis() und das läuft so 
auch mit dem Teensy 4.

Aber 10ms sind etwas sehr knapp, das wären ja 100Hz, das Update darf 
nicht schneller erfolgen als die Bildwiederholrate.
Da ich die Displays normal auf 60Hz konfiguriere mache ich den Refresh 
mit 50Hz, also alle 20ms.

Spyy schrieb:
> Noch ne Frage: Ich sehe das der BT81x überall out of stock ist und kein
> mögliches Lieferdatum...ist das die Chip Krise oder ist der Chip
> abgekündigt?

Also wenn man bei Mouser schaut, dann haben die 2888 BT818Q-R und 774 
BT818Q-T auf Bestellung, dazu über 5500 BT817.
Farnell/Newark hofft auf Bestand Mitte April.
Ich tippe auf Chipkrise.

Das wird auch noch lange so weiter gehen, mindestens dieses Jahr.
Das Problem wird auch dadurch nicht entschärft das man im Moment über 
Bedarf einkaufen muss, wenn man überhaupt mal was bekommt.
Mouser hat gerade ein Tray ATSAME51J19A-AU erhalten, 320 Stück, da hatte 
ich schon 12 Stück von im Warenkorb bevor die überhaupt angekommen sind.
Heute Vormittag konnte ich endlich bestellen und keine 12 Stunden nach 
Wareneingang haben die nur noch 218 Stück.
Die nächsten kommen dann vielleicht Mitte Februar 2023, ja 202*3*.
Ich bräuchte dann auch langsam mal wieder ATSAMC21, das wird dieses Jahr 
wohl nichts...

[Spyy (Gast)]

Rudolph R. schrieb:
>> Ich habe keinen externen Quarz und speise jetzt vom Teensy ein 12 Mhz
>> PWM 50% Dutycycle am BT818 ein...und voila, jetzt geht das ganze mit
>> externer clock :-) => ich nutze den ganzen internen quatsch nicht
>> mehr....
>
> Na, das ist doch auch nett. :-)

=> ja dann kann man den Chip sogar übertakten....

Ich habe da nochmal ne Frage zu custom fonts...ich komme da nicht 
weiter...
Also ich habe:
1. Einen Font als TTF (10 Zahlen)
2. Eine .txt Datei um nur die 10 Zahlen umzuwandeln
3. EveAssetBuilder 2.10
4. Ich habe keinen Flash muss also aus dem Progmem in den EVE kopieren, 
brauche also irgendwie am Ende ne Headerdatei wo das "Feld" gespeichert 
ist.

Wie ist jetzt da der workflow und welches ist dann das einfachste Format 
?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> => ja dann kann man den Chip sogar übertakten....

Das klingt irgendwie verlockend, aber leider gibt es im Datenblatt auch 
keine Grenzen für die Frequenz, 12,000 MHz sollen es sein.

Spyy schrieb:
> 3. EveAssetBuilder 2.10

Ugh, wie ich gerade gesehen habe ist das wirklich die Version die man 
aktuell bekommen kann.
Irgendwie läuft das bei BRT gerade nicht mit der Software, die 2.4.1 war 
Anfang November raus, mein letzter Fehlerbericht war am 12.12.
Das ist doch mindestens eine Woche für einen Hotfix-Patch und 
Re-Release. :-)
Die 2.1.0 läuft auch, hat aber noch den alten ASTC Encoder drin, das ist 
dann etwas langsam.

Das BRT Forum stockt auch kräftig, hoffentlich sind das immer noch die 
Ferien, immerhin sind es inzwischen zwei Moderatoren.

> 4. Ich habe keinen Flash muss also aus dem Progmem in den EVE kopieren,
> brauche also irgendwie am Ende ne Headerdatei wo das "Feld" gespeichert
> ist.
>
> Wie ist jetzt da der workflow und welches ist dann das einfachste Format
> ?

Als das "einfachste" Format würde ich jetzt ASTC bezeichnen, aber ich 
habe eigentlich nur wegen UTF-8 am meisten damit gespielt.
In dem Fall sind die 128 Zeichen maximal ja kein Problem und ich habe 
das gerade mal durchgespielt.
Als ASTC hat ein 24er Font mit 0...9 genau 16kiB.
Im Legacy Format aber nur 3712 Bytes.

Wenn ich diese 3717 Bytes .raw mit dem "Asset Compressor" packe bleiben 
davon noch 1442 Bytes die man mit CMD_INFLATE verschieben kann.

In der .raw Datei sind sowohl die Glyphen drin als auch 
Verwaltungsinformationen.
Darum gibt man beim Konvertieren auch gleich die "Address of Font Data" 
mit an, per Default steht das auf RAM_G + 1000.
Aber, der "Legacy Font Metrics Block" ist dokumentiert, an Offset 144 
steht der Pointer auf die Glyph-Daten.

Darum funktioniert sowas hier:
 EVE_cmd_inflate(MEM_FONT, font_l4, sizeof(font_l4));
 EVE_memWrite32(MEM_FONT + 144, MEM_FONT + 148);

Für den Test hatte ich MEM_FONT so definiert:
 #define MEM_FONT 0x00001234

Also im Grunde kann das dann überall stehen.
Vielleicht vorsichtshalber auf 4 Byte aligned.

Und dann noch sowas:
 EVE_cmd_setfont2_burst(10, MEM_FONT, 32);
 EVE_cmd_text_burst(10, 100, 10, 0, "Hello there...");

Wobei in dem Fall eher so:
 EVE_cmd_setfont2_burst(10, MEM_FONT, 0x30);
 EVE_cmd_text_burst(10, 100, 10, 0, "0123456789");

Achtung Falle, CMD_SETFONT2 erwirkt einen BITMAP_HANDLE(x) Befehl in der 
Display-Liste und dreht den Kontext dann nicht wieder zurück.
Und ein folgendes CMD_SETBITMAP bezieht sich einfach auf das aktuelle 
Bitmap-Handle.

[Spyy (Gast)]

Hi Rudolph,

Sorry, hat sich überschnitten...hat jetzt geklappt...hatte das mit der 
Registrierung über setfont2 an der falschen Stelle stehen...
Ich mache das aber jetzt mit .glyph und .xfont in zwei Header 
Dateien...die ich dann ins MEM vom EVE kopiere...
Ich habe L1 verwendet und L2 => geht
Bei ASTC zeigt es nix...muss man da noch deflaten?
Mein Font sieht aber ein wenig dünn und etwas "zerfranzt" aus...liegt 
das an L1 oder L2 etc.? Wird das mit zunehmender Lx besser?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> Ich mache das aber jetzt mit .glyph und .xfont in zwei Header
> Dateien...die ich dann ins MEM vom EVE kopiere...
> Ich habe L1 verwendet und L2 => geht
> Bei ASTC zeigt es nix...muss man da noch deflaten?

Normal nicht, aber es lohnt sich durchaus die durch den Asset Compressor 
zu schicken und per CMD_INFLATE an EVE zu schicken.

Hast Du denn im EAB bei der Konvertierung auf ASTC von "FLASH" auf 
"RAM_G" umgestellt?
Die Adresse wird in die .xfont Datei eingetragen, für "RAM_G" sollte man 
sich da auch dran halten.
Für "FLASH" ist es so das EAB die .xfont Datei automatisch manipuliert 
wenn man die zusammen mit der .glyph in einen Flash-Container wirft.

> Mein Font sieht aber ein wenig dünn und etwas "zerfranzt" aus...liegt
> das an L1 oder L2 etc.? Wird das mit zunehmender Lx besser?

Dünn liegt villeicht eher am Font, zerfranst liegt an L1/L2. Mit 2 Bit 
kann das Dithering noch nicht wirklich was anfangen.

[Spyy (Gast)]

Rudolph R. schrieb:
> Hast Du denn im EAB bei der Konvertierung auf ASTC von "FLASH" auf
> "RAM_G" umgestellt?

Ja das war genau der Fehler...Danke...

Nochmal ne Frage, wieso sind denn immer 128 Glyphen in der .ttf 
drin...ich habe doch nur die Zahlen von 0 bis 9 und den Rest gelöscht?
Dann kommen bei mir uncompressed immer 32kB an .glyph raus...:(

Und irgendwie ist der Wurm drin, wenn ich das mit der .raw mache...
Ich habe im EAB (siehe screenshot):
1. Legacy format
2. L8
3. setfont2
4. RAMG+1000
5. User defined char set
=> Bekomme dann ne .raw => daraus mache ich ein Array mit "Convert a 
binary to textfile C Array => Daraus mache ich eine Header Datei.
Dieses kopiere ich hiermit ins RAMG

  for (uint16_t i = 0; i < sizeof(fontData24_L8); i++)
  {
    EVE_memWrite8(FONT_FILE_ADDRESS + i, fontData24_L8[i]);
  }

wobei FONT_FILE_ADDRESS = RAMG+1000 ist und
fontData24_L8[i] => das Array
dann das hier:

   void SetCustomFont(uint32_t fontHandle, uint32_t firstChar)
    {
        EVE_cmd_setfont2_burst(fontHandle, FONT_FILE_ADDRESS, firstChar);
    }

Mit fontHandle = 1 und firstchar = 1

Ich bekomme dann aber nur dort wo ein Zeichen stehen soll ein 
ausgefülltes Kästchen...so als wenn er in dem .raw nix findet...

Wie schon gesagt mit .xFont und .glyph geht das aber die glyph hat ja 
immer 32kByte

Grüße und Danke

[Rudolph R. (rudolph)]

Im Extended Format sind es immer 128 Glyphen oder ein vielfältiges 
davon, das ist im Grunde genommen richtig, bzw. so beabsichtigt.
Als ASTC ist das aber kleiner, da komme ich auf 16kiB.

Ich habe mir mal eben EAB 2.1 installiert um das nachzuvollziehen.
Tendenziell würde ich den ersten Char auf 48 setzen.
Konvertiert hat EAB das im Grunde genommen auch so, es gibt das .png 
dazu.

Nur versuche ich gerade die .raw durch den EVE Screen Editor zu ziehen 
und bekomme da gerade gar nichts außer Pixelmüll angezeigt.

[Spyy (Gast)]

Rudolph R. schrieb:
> Nur versuche ich gerade die .raw durch den EVE Screen Editor zu ziehen
> und bekomme da gerade gar nichts außer Pixelmüll angezeigt.

Genau, anbei mal meine .ttf im Anhang...aber ich habe mal geschaut..ich 
glaube ich brauche ja nur 3 Fontgrössen => 3x32kByte mit extendet ASTC 
und mit Glyph/xfont data=> approx. 100 kByte und man hat ja wohl im RamG 
0x000000-0x0FFFFF=>1024 Ki => das reicht bei mir...habe da nur noch ne 
statische Display List drin...

Generell mal die Frage: Was macht man eigentlich, wenn die Displaylist 
länger als 4096Bytes ist (bei mir jetzt über 5000 Bytes und ich bin noch 
nicht fertig)...aber es geht und wird alles korrekt angezeigt...
Ich glaube ich werde den EVE chip nie durchschauen...

Danke nochmal für Deine Unterstützung, wirklich sehr hilfreich...:)

Grüße

Torsten

[Rudolph R. (rudolph)]

Och, die Display-Liste darf 8kiB haben, der CMD-FIFO hat nur 4kiB.
Das Verhältnis von dem was man in den CMD-FIFO steckt und was in der 
Display-Liste landet ist für viele Befehle allerdings 1:2 oder größer, 
insofern läuft eher die Display-Liste über.

Und wenn es überläuft heißt es optimieren.
Zum Beispiel zwei Bilder verwenden statt einem Button.

[Spyy (Gast)]

Sorry, das ich von einem Thema ins andere "springe" aber der Chip 
"drives me crazy" auch die Beispiele in der EVE Dokumentation sind ja 
eher suboptimal...und teilweise völlig verwirrend.
Ich habe mich an Deine Codebeispiele (Deine Musterapplikation) 
gehalten...leider ist da ja kein Custom font drin aus dem RamG geladen, 
nur aus dem Flash...

[Rudolph (Gast)]

Ich habe die Fonts bis zum BT81x im Grunde genommen nie genutzt,
da das "Legacy" Format ja auf 128 Zeichen begrenzt ist.
Da habe ich mir sowas wie ein "µ" lieber von Hand gestrickt indem ich 
über ein "u" noch versetzt ein "i" ausgegeben habe.

[Spyy (Gast)]

Rudolph schrieb:
> Ich habe die Fonts bis zum BT81x im Grunde genommen nie genutzt

Also ich habe jetzt 2x xfont/glyph ins RAMG geladen, funktioniert 
prima...

Noch mal ne Frage, ich hoffe es nervt nicht...

Für mich sind die Einstellunge VSYNC/HSYNC/HSYNC1/usw, immer noch 
spanische Dörfer, das was ich habe funktioniert aber bin mir nicht 
sicher warum.

1. vom Hersteller habe ich das hier (ist ein st7701s chip)

/***********************************************************************/
/* Panel Name : HSD4.0IPS(HSD040BPN1-A00)                                   
/* Resulation : 480x480                                                       
/* Inversion  : 2dot                                                          
/* Porch      : vbp=15 , vfp=12                                               
/* Line Time  : 32us                                                          
/* Frame Rate : 60hz                                                          
/************************************************************************/

2. Eingestellt (und geht) habe ich das hier:

#define Resolution_480x480
#define EVE_HSIZE  (480L)
#define EVE_VSIZE  (480L)   

#define EVE_VSYNC0  (8L)        
#define EVE_VSYNC1  (8L + 8L)      
#define EVE_VOFFSET  (8 + 8 + 2)      
#define EVE_VCYCLE  (EVE_VSIZE + 8 + 8 + 2 + 2)  
#define EVE_HSYNC0  (8L)        
#define EVE_HSYNC1  (8L + 8L)      
#define EVE_HOFFSET  (8L + 8L + 20L)      
#define EVE_HCYCLE   (EVE_HSIZE + 8 + 8 + 20 + 2)    
#define EVE_PCLK  (1L)
#define EVE_PCLKPOL  (0L)                
#define EVE_SWIZZLE  (0L)                
#define EVE_CSPREAD  (0L)                
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_DITHER  (0L)
#define EVE_GEN 4
#define EVE_HAS_CRYSTAL
//#define EVE_PCLK_FREQ (14500000L)  /* 14.5MHz => 54 Hz value for EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (27000000L)  /* 27MHz => 100 Hz value for EVE_cmd_pclkfreq */
#define EVE_PCLK_FREQ (19000000L)  /* 27MHz => 100 Hz value for EVE_cmd_pclkfreq */

Wie kommt man denn jetzt mit porch vbp=15,vfp=12 und linetime 32µs auf 
die Werte für den BT81x ?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Spyy schrieb:
> Wie kommt man denn jetzt mit porch vbp=15,vfp=12 und linetime 32µs auf
> die Werte für den BT81x ?

Ähm, quasi gar nicht.
Auch wenn man die 60Hz dazu nimmt ist das doch nur raten.

Solche Erfahrungen habe ich mit nackten Panels bisher meistens gemacht, 
also nicht praktisch, von den Daten her.
Entweder man findet gleich kein Datenblatt, das Datenblatt ist ein Witz 
und enthält keine Timing-Informationen oder der Hersteller gibt die 
Timing Informationen in seinem eigenen Format an, möglichst 
unvollständig.

Ich habe ein Datenblatt von einem TFT-H040A1PVIST3N40 gefunden.
"Shenzhen Hot Display Technology Co.,Ltd" - ja, genau.
Unter "LCD display initialization code" steht der selbe seltsame Header.
Und ganz viele Daten die man per SPI an den Display-Controller schicken 
soll - Schauder.

Nur richtige Timing Informationen gibt es im dem "Datenblatt" gar nicht.
Der Pixel-Clock darf bis 30MHz haben.

Da hilft nur zu versuchen was ähnliches zu finden, raten und 
ausprobieren.

Vielleicht bringt es was zu entschlüsseln was dem ST7701S da eigentlich 
im Detail alles geschickt wird.

[Alf S. (alfsch)]

+ für die Display Daten:  habe gerade ein Riverdi TFT zum laufen 
gebracht,
RVT70AQBFWR00, EVE3 TFT , 7" , 800 x 480 , res.touch (von rs 193-1167 , 
66€ ).

Einstellung (auch mit Werten von riverdi /git driver ) war nicht 
korrekt, einige wundersame einzelne Pixel im Bild und eine blaue Linie 
rechts am Rand;
 so sieht das Bild fehlerfrei aus:

/* RVT70xQBxxxxx 800x480 7.0" Riverdi, various options, BT815/BT816 */
#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
#define EVE_HSIZE  (800L)  /* Thd Length of visible part of line (in PCLKs) - display width */
#define EVE_VSIZE  (480L)  /* Tvd Number of visible lines (in lines) - display height */

#define EVE_VSYNC0  (4L)  /*  0  Tvf Vertical Front Porch */
#define EVE_VSYNC1  (8L)  /* 13  10 Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
#define EVE_VOFFSET (13L)  /* 23 Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
#define EVE_VCYCLE  (512L)  /* 525 Tv Total number of lines (visible and non-visible) (in lines) */
#define EVE_HSYNC0  (0L)  /* 0 Thf Horizontal Front Porch */
#define EVE_HSYNC1  (4L)  /* 10 Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
#define EVE_HOFFSET (28L)  /*46  Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
#define EVE_HCYCLE (856L) //  (1056L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */
#define EVE_PCLK  (2L)  /* 72MHz / REG_PCLK = PCLK frequency 30 MHz */
#define EVE_PCLKPOL (1L)  /* 1L PCLK polarity (0 = rising edge, 1 = falling edge) */
#define EVE_SWIZZLE (0L)  /* Defines the arrangement of the RGB pins of the FT800 */
#define EVE_CSPREAD  (0L)  // 1L muss definitiv 0 sein !
#define EVE_TOUCH_RZTHRESH (1800L)  /* touch-sensitivity */
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif

[Rudolph (Gast)]

Danke!

Aber bäh, das sieht so aus als ob die das Panel geändert haben.
Spontan würde ich aber sagen, dass Du ein altes Modul erwischt hast, das 
auf RS verlinkte Datenblatt hat noch 928 typisch für eine Zeile.
In den aktualisierten Daten von Riverdi steht allerdings 1056.
Was steht denn auf dem Aufkleber von wann das ist?

Probier das mal aus:

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

#define EVE_PCLK (2L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif

[Spyy (Gast)]

Ah ok, danke...

Du hattest mal irgendwo geschrieben, dass Du Serienwiderstände in den 
SPI lines zum EVE verwendest.
Wonach legt man die denn aus? Ich "fahre" den SPI ja mit 25Mhz...

Ich habe, weil ich das mal in einem Beispiel gesehen habe, in den RGB 
lines zum Display 30 Ohm "reingemacht"...ob das was bringt...keine 
Ahnung.

Grüße und Danke

Torsten

[Rudolph (Gast)]

Spyy schrieb:
> Du hattest mal irgendwo geschrieben, dass Du Serienwiderstände in den
> SPI lines zum EVE verwendest.

Die habe ich mit dem Teensy 4 benötigt, sonst mit bisher keinem 
Controller.
Die 10R die ich da per Default in meinen Adapter-Platinen habe sind noch 
nicht so richtig wirksam bei den Frequenzen, die sind mehr Vorhalt als 
eine konkrete Maßnahme, ebenso die 22pF.

> Wonach legt man die denn aus?

Nach den Treibern, also wie schnell die schalten, den Leitungslängen, 
der Frequenz, etc.
Oder man probiert das aus und erhöht wie ich das mit dem Teensy 4 
gemacht habe einfach mal die Reihenwiderstände, weil vorher nichts 
anderes gegriffen hat und das bei Stückzahl 1 ja nicht perfekt sein 
muss.

Spyy schrieb:
> Ich "fahre" den SPI ja mit 25Mhz...

Da funktioniert mein Touch normalerweise schon nicht mehr.
Ich denke, weil die MOSI Signale durch die ganze Kette und zurück 
schlicht zu stark verzögert werden - denn reines Schreiben geht einiges 
schneller.

Spyy schrieb:
> Ich habe, weil ich das mal in einem Beispiel gesehen habe, in den RGB
> lines zum Display 30 Ohm "reingemacht"...ob das was bringt...keine
> Ahnung.

Die Leitungen schalten gerade bei den größeren Displays noch viel 
schneller.
Die Serien-Widerstände sollen da vor allem die Flanken ein klein wenig 
rund machen, das verringert die Stör-Abstrahlung nach Außen und vor 
allem auch
die gegenseitigen Einstrahlungen bei parallelen Leitungen.
Und es gibt so wohl auch weniger Reflexionen auf den Leitungen.
Es gibt hier im Forum sicher einige die das korrekter erklären können.

An der Stelle kann ich auch nur mit den Schultern zucken und darauf 
hoffen, dass die Empfehlungen vom Hersteller stimmen, 30+MHz parallele 
"Busse" sind eher nicht womit ich mich normalerweise herum schlage. :-)
Und Bridgetek hat zum Beispiel auf dem ME817EV praktisch in allen 
Leitungen 33R Serienwiderstände.

[Alf S. (alfsch)]

>Was steht denn auf dem Aufkleber von wann das ist?
2141 , also vmtl Mitte 2021 hergestellt.

Ich habe in meinem "Testbild" mit den bewegten Dreiecken einen 
Hintergrund mit Farbverlauf , der sieht auf dem Newhaven TFT perfekt 
aus, auf dem Riverdi TFT sieht man ganz leichte Stufen in der Farbe, als 
wäre das RGB zB 3 x 6bit statt 3 x 8bit ; oder gibts da noch was zum 
Einstellen ?
+ wenn man "sehr schräg" aufs TFT guckt, sieht das bewegte Dreieck auf 
dem Riverdi TFT eher "ruckelnd" aus, die Linien scheinen erst kurz 
Schwarz und dann erst Gelb gemalt zu werden und dadurch etwas 
"flimmern", beim Newhaven TFT sieht man davon nichts, einfach bewegte 
gelbe Linien eben. Oder könnte das am Controller liegen, EVE2 -> EVE3 
(im Riverdi TFT)?

+
zu den Widerständen in den Leitungen: die sind zur Vermeidung/Reduktion 
von Reflexionen auf der Leitung; das MUSS sein, sobald die Leitung von 
kräftig schnellen Treibern angesteuert wird. Das ist bei allen "neueren" 
ARM chips so, bei den STM32 sind (im Cube) die Ports in 3 , 4 oder 5 
Stufen in der Geschwindigkeit einstellbar; man sollte immer geringste 
Geschwindigkeit einstellen, die für die benutzte Taktrate ausreicht, um 
möglichst wenig Refexionen zu erzeugen. Ich mache "standardmässig" 51 
Ohm in jede Leitung, zB zur SD-Karte (50 Mbit clock) oder zum TFT (SPI 
mit 25 Mbit).
ZB mit max.port speed , ohne Widerstände drin, bekommt man gar keine 
Verbindung zu einer SD-karte, so, als wäre sie kaputt !
Die Impedanz einer "einsamen" Leitung auf PCB über Massefläche liegt so 
bei 50 Ohm, in einem Flachkabel dann her bei 120 ohm, also sollten die R 
in der Leitung irgendwo zwischen 33 Ohm (bei USB üblich) und 150 Ohm (in 
CD playern typisch) liegen; 50 ...100 sind ein guter Bereich.

[Alf S. (alfsch)]

zum Anschauen kurz simuliert:  20MHz , 3V Rechteck , auf ---->
10cm freie Leitung (hat etwa 100nH Induktivität), Ende an chip-pin (mit 
5pF Streukapazität, angenommen);

(1. bild 2x , man kann es anscheinend nicht löschen...)
1. schneller port, 1ns rise/fall , dünnes Kabel (1 Ohm angenommen)
2. schneller port, 0.5ns , mit 100 Ohm in der Leitung
3. etwas "gebremster" port, 5ns , 1 Ohm


da kann man gleich sehen, warum ein Widerstand rein muss,
wenn die Leitung von schnellem chip angetrieben wird. :)

[Rudolph (Gast)]

Alf S. schrieb:
>>Was steht denn auf dem Aufkleber von wann das ist?
> 2141 , also vmtl Mitte 2021 hergestellt.

Ok, das finde ich seltsam, Mitte 2020 hätte noch irgendwie Sinn ergeben.

Was passiert denn mit dem Setup das ich oben mit den Default-Werten 
gepostet habe?


Und Reflexionen, dann hatte ich wenigstens schon das richtige Stichwort. 
:-)
Als echtes Problem war mir bisher nur begegnet das die ATSAMC bei 3,3V 
nicht genug Strom liefern konnten um den SPI zu treiben, also so nach 
extern über das FFC und jenseits von 8MHz.
Auf die Idee zu schauen ob man bei dem Teensy 4 die Pins auf langsamer 
einstellen kann bin ich nicht gekommen, unter 240R habe ich auch nicht 
mehr ausprobiert. Kann also sein das es in Software lösbar wäre oder mit 
51R.


Und Tipp, es gibt einen neuen EAB:
https://brtchip.com/ic-module/wp-content/uploads/sites/3/2022/01/EVE-Asset-Builder-setup-2.5.0_3.0.0.zip

[Alf S. (alfsch)]

>Was passiert denn mit dem Setup das ich oben mit den Default-Werten
gepostet habe?
noch nix, kann ich erst nächste Woche mal testen.

>die Idee zu schauen ob man bei dem Teensy 4 die Pins auf langsamer einstellen 
kann

jepp, is doch auch so ein schneller ARM, siehe Bildchen.... :)
ist im DB sogar extra mit Bild , 2. Bild.

[Rudolph (Gast)]

Alf S. schrieb:
>>die Idee zu schauen ob man bei dem Teensy 4 die Pins auf langsamer einstellen
> kann
>
> jepp, is doch auch so ein schneller ARM, siehe Bildchen.... :)
> ist im DB sogar extra mit Bild , 2. Bild.

Ich hatte im DB nachgesehen und per Software gelesen was da über den 
Arduino Core eingestellt wird: 111
Also mit 011 oder 0100 hätte das direkt funktionieren können, 
interessant.

[Spyy (Gast)]

Super, Danke für den Hinweis...zum neuen EAB...

Noch ne Frage...warum kann man eigentlich "burst" und z.B. mem_read 
(z.B. ins G Ram schreiben/lesen) nicht mischen ?

Ich dachte wenn man burst startet und dann eine DL aufbaut macht man ja 
erst nur den SPI Buffer voll und erst bei "Burt end" wird das alles per 
SPI DMA aus dem Buffer weggeschickt...

Grüßeund Danke

[Spyy (Gast)]

Alf S. schrieb:
> zu den Widerständen in den Leitungen: die sind zur Vermeidung/Reduktion
> von Reflexionen auf der Leitung; das MUSS sein, sobald die Leitung von
> kräftig schnellen Treibern angesteuert wird. Das ist bei allen "neueren"
> ARM chips so, bei den STM32 sind (im Cube) die Ports in 3 , 4 oder 5
> Stufen in der Geschwindigkeit einstellbar; man sollte immer geringste
> Geschwindigkeit einstellen, die für die benutzte Taktrate ausreicht, um
> möglichst wenig Refexionen zu erzeugen. Ich mache "standardmässig" 51
> Ohm in jede Leitung, zB zur SD-Karte (50 Mbit clock) oder zum TFT (SPI
> mit 25 Mbit).
> ZB mit max.port speed , ohne Widerstände drin, bekommt man gar keine
> Verbindung zu einer SD-karte, so, als wäre sie kaputt !
> Die Impedanz einer "einsamen" Leitung auf PCB über Massefläche liegt so
> bei 50 Ohm, in einem Flachkabel dann her bei 120 ohm, also sollten die R
> in der Leitung irgendwo zwischen 33 Ohm (bei USB üblich) und 150 Ohm (in
> CD playern typisch) liegen; 50 ...100 sind ein guter Bereich.

Hallo Alf,

danke für die Info...tja...was mache ich nun...ich habe ein PCB ohne R 
in den SPI Leitungen und eigentlich kein Problem (mehr)...und ich habe 
kein so tolles Oszi...und wüsste auch gar nicht so genau wie die Signale 
bei 25 Mhz so aussehen müssten...
Die Leitungen vom Teensy zum EVE sind ca.3-4 cm lang....

[Rudolph R. (rudolph)]

Spyy schrieb:
> Noch ne Frage...warum kann man eigentlich "burst" und z.B. mem_read
> (z.B. ins G Ram schreiben/lesen) nicht mischen ?

Da musste ich erstmal drüber nachdenken.
Bei den Targets die DMA unterstützen sollte das sogar eigentlich 
funktionieren.
Nur auf die Idee gekommen bin ich noch nicht.

> Ich dachte wenn man burst startet und dann eine DL aufbaut macht man ja
> erst nur den SPI Buffer voll und erst bei "Burt end" wird das alles per
> SPI DMA aus dem Buffer weggeschickt...

Richtig, und Funktionen wie EVE_memRead8() sind in sich abgeschlossen 
und kümmern sich auch nicht darum ob nun gerade Burst ist oder nicht.

Man muss nur aufpassen das man nicht direkt nach dem EVE_end_cmd_burst() 
wieder was über den SPI schickt, so ohne EVE_busy().

Was anderes ist es wenn man ein Target ohne DMA Support hat, dann kann 
man zwar auch EVE_start_cmd_burst() / EVE_end_cmd_burst() benutzen, das 
bewirkt aber was ganz anderes, damit wird der SPI-Transfer direkt 
gestartet und jedes Kommando schickt nur die Nutz-Daten ohne Adresse 
vorweg.
Ein Arduino UNO hat ja zum Beispiel schon mal gar nicht die 4k SRAM die 
für den Puffer benötigt werden.

Spyy schrieb:
> danke für die Info...tja...was mache ich nun...ich habe ein PCB ohne R
> in den SPI Leitungen und eigentlich kein Problem (mehr)...und ich habe
> kein so tolles Oszi...und wüsste auch gar nicht so genau wie die Signale
> bei 25 Mhz so aussehen müssten...
> Die Leitungen vom Teensy zum EVE sind ca.3-4 cm lang....

Nun ja, erstmal ist das ein ganz anderes Problem, ich gehe ja von den 
ganzen Eval-Boards mit fliegenden Leitungen weg auf meine 
Adapter-Platine und dann hängt da noch das FFC zum Display dran.

Und dann könnstet Du einfach auf Verdacht die Geschwindigkeit der SCK 
und MOSI Pins von der Default-Einstellung 7 auf was kleineres ändern, 
der kleinste Wert eben der noch ohne Probleme funktioniert.

Und manchmal ist es auch gut den Stuss zu lesen den man selber 
geschrieben hat. :-)
Als ich mich hierhin durchgeklickt habe bin ich ganz oben auf der Seite 
gelandet und habe gesehen was ich im Juni letzten Jahres geschrieben 
hatte.
Ich schrieb da oben, dass ich von 240R auf 150R runter gegangen bin und 
dann 26MHz SPI mitsamt Touch benutzen konnte.
Ich schrieb auch, dass ich die Pin-Einstellung selber geändert habe, so 
ohne Effekt, aber ich schrieb nicht wie weit ich mit der Einstellung 
runter gegangen bin. Jetzt würde ich einen Wert von 3 oder 4 für 
plausibel halten, so ohne extra Widerstände.

[Alf S. (alfsch)]

>dass ich von 240R auf 150R runter gegangen bin und
> dann 26MHz SPI mitsamt Touch benutzen konnte
mit 150 R haste ja dann schon einen guten Wert gefunden :)

>ich habe ein PCB ohne R in den SPI Leitungen
>Leitungen vom Teensy zum EVE sind ca.3-4 cm lang

da solltest du einfach die drive/speed auf einen kleinen Wert 
einstellen, dann sollte das zuverlässig laufen; ich würde beim kleinsten 
anfangen, 001, und sehen, ob es mit vollem Takt geht; wenn nicht, eben 
010 versuchen.
anbei simu: kurze Leitung 25MHz mit 2mA drive - würde gut aussehen.

btw ein Beispiel: ich hatte mal ein Problem mit der Zuverlässigkeit 
eines FPGA, clock 80MHz ; der Entwickler hatte "vorsichtshalber" den 
Oszillator direkt neben das FPGA gesetzt, ca. 20mm Leitung, da denkt man 
schon, das ist perfekt so. Etwa 50% der Boards liefen, die anderen 
hatten diverse "Fehler", manche gingen bei Erwärmung nicht mehr, manche 
gar nicht. Da sucht man alles Mögliche als Grund...
bis ich versuchsweise die 20mm Bahn mit Cutter aufgetrennt und nen 100 R 
0805 SMD draufgelötet habe; dann liefen auch die "defekten" FPGA alle 
problemlos.
(speed Einstellung ändern gabs hier natürlich nicht).

[Spyy (Gast)]

Okay....also mit drive strenght 0b001 geht das sofort (keine Ahnung, ob 
da überhaupt was passiert ist) aber fein....:) freu....

[Spyy (Gast)]

...aber man weiss ja...wenn es sofort geht liegt der Fehler tiefer...das 
ist verdächtig....

[Alf S. (alfsch)]

...oder auch - ganz selten - einfach richtig.  :)

>>Probier das mal aus:

#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
#define Resolution_800x480
#define EVE_PCLK (2L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif


habe es versucht. Bild sieht (genauso) ok aus.
nur: compiler motzt ->
musste in EVE_commands das vorerst einfach raus kommentieren: Zeile 1313
//  EVE_memWrite16(REG_TOUCH_RZTHRESH, EVE_TOUCH_RZTHRESH);  /* 
eliminate any false touches */   geht nicht ! undeclared !

touch (resistiv) geht aber gut (wie vorher).

[Rudolph R. (rudolph)]

Alf S. schrieb:
> habe es versucht. Bild sieht (genauso) ok aus.

Super, danke, dann muss ich mir da mal was zu überlegen.

Alf S. schrieb:
> nur: compiler motzt ->
> musste in EVE_commands das vorerst einfach raus kommentieren: Zeile 1313

Dann hast Du noch eine alte Version, das habe ich Ende Dezember 
umgebaut. :-)

Der Hintergrund ist das die Einstellung für kapazitiv-Touch Displays gar 
nicht benötigt wird, stand aber in allen Profilen.
Wenn es nicht definiert ist wird jetzt 1200 geschrieben.
Ist es definiert weil 1200 für manche resistiv-Panels noch zu niedrig 
ist, aber eben über die Projekt-Einstellungen, z.B. in der 
platformio.ini, dann wird es auch wie gewohnt geschrieben.
Damit kann man das individuell anpassen ohne die EVE_config.h verändern 
zu müssen.

[Alf S. (alfsch)]

nu, bzgl "wieso Reflexionen" bei den aktuellen CPUs auf den Leitungen:
hier mit Magnetfeld-sonde direkt am Flachkabel zum Riverdi TFT gemessen, 
mit 51R in allen aktiven Leitungen und reduzierter pin-drive Einstellung 
:(medium/low)
immerhin noch ganz ordentlich Oberwellen bis 2 GHz !

genau selbe Einstellung der STM32H7A3 CPU , aber mit dem TFT von 
Newhaven, mit ca. 35cm Flachbandkabel dran. ca. 20dB weniger Oberwellen, 
also :
vermutlich sind auf dem TFT von Riverdi keine Dämpfungswiderstände in 
der SPI Leitung vom EVE chip; daher hat das heftige Abstrahlung, obwohl 
von der H7A3 CPU her das Signal eigentlich gedämpft ist. (wie man beim 
Newhaven TFT trotz des längeren Kabels ja gut sehen kann).


(btw die Uhrzeit vom Analyzer ist schon 6 Stunden vorne...warum auch 
immer)

[Spyy (Gast)]

Ok...also drive strenght runter UND 51R in die SPI Leitungen?

Alle SPI Leitungen, also auch CS?

Ach wenn man doch Ahnung von dem hätte was man so macht...;-)

[Alf S. (alfsch)]

>also drive strenght runter UND 51R in die SPI Leitungen?
ja + CS auch ; (einfach...aus Prinzip.)
vmtl. sind auf dem TFT von Riverdi keine R in den Leitungen (der EVE 
"sendet" ja auch , MOSI -> MISO ) und es sollte daher auch mit Rs nahe 
am EVE chip gedämpft werden.
Riverdi bewirbt auf ihrer Seite ja die neuen EVE4 Displays, auch mit EMI 
Messung dabei; bei den älteren EVE3 sehe ich davon nix (nur: Not 
recommended for new design.)
anscheinend ist ihnen auch aufgefallen, dass die TFTs so einiges an HF 
abstrahlen auf der SPI Leitung.

[Spyy (Gast)]

>ja + CS auch ; (einfach...aus Prinzip.)
Okay....will do....so

Sagt mal, weiss jemand ob es dann man einen EVE5 geben wird ?

[Rudolph R. (rudolph)]

Spyy schrieb:
> Ach wenn man doch Ahnung von dem hätte was man so macht...;-)

Ich ahne was, aber ich habe nicht mal ansatzweise die Messtechnik um 
sowas aufzuspüren oder hätte die Erfahrung mit der Art von Messtechnik 
richtig umzugehen. :-)

Spyy schrieb:
> Sagt mal, weiss jemand ob es dann man einen EVE5 geben wird ?

Solange nichts angekündigt ist kann ich da nur hoffen.
Leider wird der Druck auf so ein Produkt immer größer, etwa durch 
Mikrocontroller mit eingebautem Grafik-Interface.
Riverdi hat ja auch gerade ein 10.1" mit einem STM32H747XIH6 
vorgestellt.
Bei den Preisen legt Riverdi allerdings im Vergleich zu den EVE4 Modulen 
noch mal eine ordentliche Schippe drauf.
Für einen BT82x würden mir schon noch ein paar Dinge einfallen. :-)

[Spyy (Gast)]

Rudolph R. schrieb:
> Mikrocontroller mit eingebautem Grafik-Interface.
> Riverdi hat ja auch gerade ein 10.1" mit einem STM32H747XIH6
> vorgestellt.

Nicht schlecht...aber out of stock....die Frage ist natürlich, ob man da 
auch so schön entwickeln kann, so wie Teensy a la Arduino style...oder 
ob man sich dann da durch alle Tiefen des Microcontroller fräsen 
muss...und ob es dafür dann auch so eine tolle Library wie Deine 
gibt...und wie leistungsfähig das dann ist...

[Rudolph R. (rudolph)]

Nun, die H7 gehen glaube ich bei 280 MHz los und der RT1062 von dem 
Teensy hat auch eine Grafik-Einheit.
Sowas Mikrocontroller zu nennen ist ja irgendwie pervers. :-)
In der Kategorie setzt man dann aber auch ein Betriebssystem ein, hat 
Dutzende wenn nicht Hunderte Leute in dem Projekt und ein guter Teil der 
Zeit geht für Prozesse drauf.

Ich meine ja nur, als FTDI 2013 mit den FT800 an den Start gegangen ist, 
da sah die Controller-Landschaft noch anders aus.

Ich kenne auch immer noch keine Produkte die mit einem FT8xx oder BT8xx 
im Laden stehen würden, also zumindest keine bei denen man 5 oder 6 
stellige Mengen erwarten kann. Ich kenne nicht mal welche die ich nicht 
nennen dürfte.
Eigentlich muss es die geben, sonst würde sich das ganze Spiel wohl eher 
nicht lohnen, aber mir sind keine bekannt.
Ich weiß auch gar nicht so recht, was ich überhaupt von Bridgetek als 
Firma halten soll, mein persönlicher Eindruck ist ja, dass der Laden 
eher klein ist.
Dagegen sprechen aber zum Beispiel die ganzen Stellenausschreibungen.
Man versucht ja nicht 19 hauptsächlich Senior Stellen zu besetzen, wenn 
man nichts zu tun hat.
Aber nun, Singapur, ich glaube da würde ich mich richtig fremd fühlen. 
:-)

Also ich drücke die Daumen, dafür habe ich immer noch zu viel Spaß mit 
EVE. :-)

[Alf S. (alfsch)]

>Ich kenne auch immer noch keine Produkte die mit einem FT8xx oder BT8xx

Ich vermute, die sind auch (wenn überhaupt) eher in ..siehe Bilder.

und bisher wohl einfach wenig bekannt und "zu ungewohnt" für die 
Entwickler;
ich bin in der Firma auch der einzige, der ein neues Display dieser 
"unbekannten Art" machen will.
und auf dem STM Forum, gehen die meisten lieber den Weg, den LCD 
controller im Chip mit externem RAM aufzupeppen und dann mit zig 
Leitungen ein RGB-LCD anzudengeln, statt sich mal mit dem EVE Zeugs zu 
beschäftigen.

btw ich bin quasi (auch) Erfinder des EVE (eine meiner sinnlosen, 
unbekannten Erfindungen...) : vor ca. 23 Jahren hatte ich zu Zeiten mit 
den AVR rumgemacht und überlegt, wie man damit ein Farb-LCD ansteuern 
könnte, ohne 1MB RAM buffer zu haben; da kam mir die Idee: der Rechner 
hat nur ein paar Dinge darzustellen, Linien und paar Buchstaben, die er 
live Zeile für Zeile berechnet und zum LCD shiftet. Kein Monster RAM 
buffer mehr nötig. Leider natürlich auch (zu der Zeit) von den 
verfügbaren CPUs her völlig unmöglich, 10x zu langsam.
gut, dass ich es nicht patentiert habe, hätte nur 10 Jahre Gebühren 
bezahlt und kein Schwein hätte es haben wollen. :)

[Rudolph R. (rudolph)]

Da habe ich einen Moment Schnapp-Atmung bekommen. :-)
Ja, ich kann auch nur für FTDI/BRT hoffen, dass die EVE in solchen 
Produkten verbaut werden.
Bridgetek hat ja auch entsprechende Bilder auf der Homepage.
Nur natürlich und leider werden die nicht ihre Kunden nennen.
Dicke Kaffee-Automaten und andere Luxus Küchengeräte auf Verdacht zum 
Zerlegen zu kaufen ist auch nicht durchführbar. :-)

Wobei Automotive eher nicht so, zumindest nicht für ein Infotainment 
Panel.
Die EVE sind nicht Automotive qualifiziert.
Wobei es sicher auch Hersteller gibt die sich davon nicht abhalten 
lassen.
Immerhin hatte BRT in der Richtung auch schon Demos.

Das kanadische ATV von Theron fand ich spannend.
Aber xxxx Stück werden die davon ja eher auch nicht bauen.

Geil wäre ja mal sowas wie eine Wetterstation zu identifizieren die 
einen FT800 drin hat und inzwischen über Pearl oder Pollin verramscht 
wird.


AVR und Displays und so, ich erinnern mich da war mal was mit einem 
übertaktetem M644 oder so.
Aber das muss dann ja schon später gewesen sein.

[Alf S. (alfsch)]

ich habe mal geguckt, was es an anderen TFT controller Zeug so gibt: hm, 
die Konkurrenz schläft nicht...
gefunden:
RA8875   https://www.buydisplay.com/download/ic/RA8875.pdf
LT7683   http://www.levetop.tw/en/product1_7680.html
SSD1963   Built-in 128Mbit Display Memory !!
https://www.crystalfontz.com/controllers/SolomonSystech/SSD1963/

alle haben RAM drin und können auch komplexe Befehle, wie Kreise, Text, 
Flächen usw.  und sind wohl die direkte Konkurrenz zum EVE.

so Display damit:

https://www.buydisplay.com/serial-spi-arduino-7-inch-tft-lcd-touch-shield-ra8875-for-mega-due-uno

https://www.ebay.de/itm/143653876018

https://www.ebay.de/itm/304289715592

+ 7" res. touch mit SPI Interface für 53€ - ist schon ne Ansage.

[Rudolph R. (rudolph)]

Den LT768x kannte ich noch gar nicht.
Und so günstig können die Dinger gar nicht sein, dass ich sowas statt 
einem BT81x verwenden würde. :-)

Die haben ja auch eine Arduino Library und Demo Code.
Wenn ich mir da ansehe was die an Code haben um ein Rechteck zu 
zeichnen, das finde ich schon etwas gruselig im Vergleich.
Wenn ich das richtig sehe machen die alles mit 16 Bit Sequenzen.
Immer schön Command und Daten.

Das hier ist mir gerade unter gekommen:

void LT768LCD::SPI_DataWrite_Pixel(int data)
{
  LT768_LCD.SPISetCs(0);    //SS_RESET;
  LT768_LCD.SPIRwByte(0x80);
  LT768_LCD.SPIRwByte(data);
  LT768_LCD.SPISetCs(1);    //SS_SET;

  LT768_LCD.SPISetCs(0);    //SS_RESET;
  LT768_LCD.SPIRwByte(0x80);
  LT768_LCD.SPIRwByte(data>>8);
  LT768_LCD.SPISetCs(1);    //SS_SET;
}

Äh, nee, lieber nicht. :-)

Die 16MB RAM sind nett, die scheinen aber nicht so richtig allgemein 
benutzbar zu sein und müssen erst noch initialisiert werden.

[Spyy (Gast)]

Ich habe mir mal den Portenta H7 mit dem STM32H747 bestellt. Der kann 
wohl auch das RGB Interface (hat ja mein Display) und MIPI DSI (soll ja 
meins auch haben, bleibt aber immer dunkel mit meinem Raspi CM4 Modul 
und Linux Treiber Versuchen) "exponieren" und hat auch HDMI...und der 
hat so eine Art "Grafikbeschleuniger" aber nur sehr rudimentär... mal 
sehen...muss man dann quasi ne Grafikkarte draus machen mit Framebuffer, 
würde bei meiner Auflösung (480/480) mit double Buffering sogar in das 
lokale RAM passen. Dann kann man den einen Core für die Grafik benutzen 
und den anderen für den Rest...so stelle ich mir das jedenfalls vor.
Hat aber sonst alle Schnittstellen, die man sich wünschen kann (CAN, 
IP,...)
Mal sehen...
Ich finde den EVE ja eigentlich gut stehe jetzt aber vor dem "Problem" 
das ich in meiner Anwendung Skalen habe (Speed Tape/Alt Tape), die sich 
auf/ab bewegen. Die Striche bewegen sich schön mit 1/16 pixel Auflösung 
(sehr cool) aber die Zahlen "nur" mit 1/1 pixel Auflösung. Das sieht man 
natürlich sofort...
Ich versuche das jetzt mit eigenen Font aus Linien (Vector Font) zu 
lösen aber irgendwann läuft mir ja die Displayliste über. bzw. DMA 
"macht ja nur" 4096 Bytes. Ich habe dann mal die Lösung von "Obones" aus 
dem BRT Forum versucht (in das RAM_G statische Listen und dann mit 
direkten Manipulationen im Speicher die Koordinaten ändern). Das geht 
aber nur für ein Glyph vom Font, kann man offensichtlich nicht 
instanzieren/kopieren...wird wohl nicht in die  Displaylist kopiert, 
sondern nur referenziert...

[Spyy (Gast)]

...und das andere Problem was ich habe, dass ich offensichtlich ein 
synchronisations Problem habe...was zu sichtbaren "Rucklern" führt, wenn 
viel Dynamik auf dem Display ist.
Das kann ich minimieren (Ausrechnen von Framerate/Aktualisierungsrate 
mit Messung beim Starten des Display) aber bekomme ich nicht ganz weg 
was für meine Anwendung etwas frustrierend ist. Auch das Auslesen "New 
Frame" Register macht das eher noch schlimmer...

[Rudolph R. (rudolph)]

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

[Spyy (Gast)]

Kann man nur auf einem Video sehen...geht das hier ?

[Spyy (Gast)]

Anbei, als Bilder...

[Spyy (Gast)]

Da bewegt sich sehr viel, hängt dann auch von der Geschwindigkeit ab mit 
der dann "gescrolled" wird...wenn es relativ schnell scrolled sieht man 
es fast nicht, wenn es ganz schnell ist kommt natürlich die 
Wiederholrate ins Spiel und wenn es ganz langsam ist sieht man das am 
"besten". Hätte ich auch nicht gedacht, dass das bei 480x480 zusehen 
ist, aber dadurch, dass die Striche mit 1/16 laufen und die Zahlen mit 
1/1 sieht man das, da scheint das Auge sehr empfindlich zu 
sein...(jedenfalls meins ;-)

[Rudolph R. (rudolph)]

Aber dann beweg die Zahlen doch mit 1/16 Pixel Auflösung?

Für den ESE:
CLEAR(1, 1, 1)
BITMAP_HANDLE(30)
BEGIN(BITMAPS)
CELL(50)
VERTEX_FORMAT(4)
VERTEX2F(4000, 4001)
VERTEX2F(4250, 4002)
VERTEX2F(4500, 4003)

Die Zeichen sind doch auch nur Bilder.
Klar, Zeichenketten von Hand zusammen zu bauen ist so lästig,
aber einzelne Zeichen kann man schon mit VERTEX2F platzieren.

[Spyy (Gast)]

Hm...das habe ich probiert...habe ne Linie zusammen mit der Zahl so 
positioniert...die Zahl (Bitmap) ging immer nur mit einer Präzession von 
1/1 Pixel...kann ich ja nochmal probieren...vielleicht liegt es hier 
dran: VERTEX_FORMAT(4)...

[Spyy (Gast)]

Es schien bei mir so, ja ich kann 1/16 positionieren aber auf dem 
Display bewegte sich das ganze dann doch mit 1/1 Pixel. Ich habe das mit 
einer horizontalen Linie und einer Zahl probiert, die ich dann von oben 
nach unten "gescrolled" habe...

[Spyy (Gast)]

Rudolph R. schrieb:
> Aber dann beweg die Zahlen doch mit 1/16 Pixel Auflösung?
>
> Für den ESE:
> CLEAR(1, 1, 1)
> BITMAP_HANDLE(30)
> BEGIN(BITMAPS)
> CELL(50)
> VERTEX_FORMAT(4)
> VERTEX2F(4000, 4001)
> VERTEX2F(4250, 4002)
> VERTEX2F(4500, 4003)

Also ich habe das mal so gemacht....und ist wie ich das schon kenne. Die 
Linie bewegt sich mit 1/16 und "das Bild" (die Zahl) mit 1/1 auch mit 
VERTEX_FORMAT(4).
Ich kann zwar die Koordinaten (alles *16) verwenden aber die Zahl 
"springt in 16er Schritten"...:(

[Daniel S. (snipod)]

Spyy schrieb:
> Ich kann zwar die Koordinaten (alles *16) verwenden aber die Zahl
> "springt in 16er Schritten"...:(

Da die Fonts am Ende auch Bitmap basiert sind und diese nur Pixelgenau 
sind, denke ich geht unter Pixelgenau nix. Auch die ROM-Fonts sind nicht 
Vektorbasiert...

Ich habe noch ein anderes interessantes Problem; ich kann tun was ich 
will, bei einer langen Display-List fäng bei mir das Bild an zu 
glitchen, sprich ich bekomme Artefakte und Ghosting von meinen Bilder 
beispielsweise. Die magische Grenze scheinen 600 Kommandos in etwa zu 
sein anbei mal ein Bild von meinem Problem (ohne Wurstfinger 560er DL, 
mit Wurstfinger 650er DL)... Weiß jemand Rat?

[Rudolph R. (rudolph)]

Daniel S. schrieb:
> Da die Fonts am Ende auch Bitmap basiert sind und diese nur Pixelgenau
> sind, denke ich geht unter Pixelgenau nix. Auch die ROM-Fonts sind nicht
> Vektorbasiert...

Das kann natürlich sein das Bilder davon ausgenommen sind, nur wäre dann 
erst recht die Frage, warum man die per Default auf 1/16 Pixel 
platzieren kann.

Ich habe gerade noch mal den Programming Guide durchsucht und keinen 
Hinweis gefunden, dass das bei Bildern nicht funktionieren soll.
Aber auch nicht wirklich anders herum, auch wenn da "pixel precision" 
steht.
Interessant fand ich aber noch das hier:
"5.98 CMD_ANIMFRAMERAM
Note: If the pixel precision is not set to 1/16 in current graphics 
context, a VERTEX_FOMART(4) is mandatory to precede this command."

Äh, ok? Warum??

Daniel S. schrieb:
> Ich habe noch ein anderes interessantes Problem; ich kann tun was ich
> will, bei einer langen Display-List fäng bei mir das Bild an zu
> glitchen, sprich ich bekomme Artefakte und Ghosting von meinen Bilder
> beispielsweise. Die magische Grenze scheinen 600 Kommandos in etwa zu
> sein anbei mal ein Bild von meinem Problem (ohne Wurstfinger 560er DL,
> mit Wurstfinger 650er DL)... Weiß jemand Rat?

Also das kann ich jetzt nicht bestätigen, aber reize das in der Regel 
auch nicht aus.
Bandbreitenprobleme mit dem externen Flash kann ich bestätigen, so etwa 
mit großen Fonts aus dem Flash ohne Cache oder dicke Bilder.

Die Anzahl der Kommandos könnte ich auch gerade gar nicht nennen, vor 
allem nicht in der Display-Liste, da ich ja über den Co-Prozessor gehe.
Wie viel von den 8k Display-Liste hast Du denn konkret belegt?
Wie viel schickst Du über den SPI bei einem Update und wie lange dauert 
das, ist da genug Zeit vor dem nächsten Update?

Ich schicke in meinem aktuellen Projekt gerade 1416 Bytes per Update, 
daraus werden zusammen mit dem per CMD_APPEND dazu gepackten Teil dann 
2712 Bytes Display-Liste.
So, reichlich Text (interne Fonts), 9 Bilder, 1 Slider, drölf 
Farb-Kommandos.
Ich bohre das gleich mal auf indem ich einen der Blöcke kopiere, 8 der 
Bilder werden auch noch gedreht, so individuell, das sind jeweils ein 
paar Kommandos.
Ach ja, BT815 und die Bilder liegen im RAM.

[Rudolph R. (rudolph)]

So, ich habe mal mein Projekt massiv mit Stuss überladen, kein Problem. 
:-)

Die Display-Liste ist mit 8016 Bytes gefüllt, über den SPI gehen per 
Update 3888 Bytes.

Der "Killer" für Display-Listen sind Buttons, einer in 3D hat mal eben 
54 Kommandos, also in der Display-Liste selber, das kann man im EVE 
Screen Editor sehen.
Das kann sogar wirklich sein das jedes 32 Bit Wort in der Display-Liste 
ein Kommando ist, danach lasse ich gerade 2004 Kommandos laufen.
Alleine die Buttons sind ja schon 864.
Die Blöcke für die 48 Bilder haben jeweils 6 einfache Kommandos und 1 
komplexeres Co-Prozessor Kommando, sagen wir halt 7 einfache, das wären 
auch noch mal 336.

Das läuft hier die ganze Zeit fröhlich vor sich hin und die Elemente bei 
denen ich den Touch auswerte tun auch weiter was sie sollen.

Ach ja, wenn ich zu viel mache bleibt das Display schwarz.
In einer vierten Textzeile oben reicht es nicht mehr für " lazy dog".
Wenn ich jetzt den Slider auf 5-stellige Drehzahl stelle komme ich auf 
8188 Bytes in der Display-Liste und 3936 Bytes per Update.

Das Teil ist übrigens ein nebenbei Tool um per LIN angesteuerte Lüfter 
auszuprobieren, also schwer Automotive. :-)

[Daniel S. (snipod)]

Ich habe auch einige Grafiken drin, ein paar Fonts (alles im RAM_G) dazu 
arbeite ich viel mit dem Scissor Rectangle, zeichnen von Konturen mit 
dem Stencil und dem anschließenden Füllen per Gradient. Arbeite 
dahingehend also schon auch mit dem Co-Prozessor...

Es macht keinen Unterschied, ob ich das Bild alle 20 oder 200ms 
refreshe. Auch kann ich anstatt alles per burst zu machen, alles polling 
machen, das macht aber - außer dass es langsamer wird - keinen 
Unterschied.

Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten 
auf EVE_busy), per polling circa 20ms.

Edit:
Sorry und ich meinte die Anzahl an Kommandos, nicht die Größe der DL

[Rudolph R. (rudolph)]

Daniel S. schrieb:
> Es macht keinen Unterschied, ob ich das Bild alle 20 oder 200ms
> refreshe.

Also das ist schon mal gut.

> Auch kann ich anstatt alles per burst zu machen, alles polling
> machen, das macht aber - außer dass es langsamer wird - keinen
> Unterschied.
>
> Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten
> auf EVE_busy), per polling circa 20ms.

Was meinst Du jetzt mit Polling?
Jedes Kommando einzeln Plus ein busy()?
Solange man nicht versucht mehr als 4k auf einmal in den FIFO zu 
schieben und dazu auch noch bei sehr schnellem SPI, schafft man es nicht 
den FIFO überlaufen zu lassen mit einzeln geschickten Kommandos.
Der Unterschied zwischen Burst und einfach so sind nur die 3 Bytes 
Adresse die pro Kommando gespart werden, das ist messbar in xx%, aber 
nicht Faktor 4+. :-)

Was für einen Controller hast Du eigentlich und wie schnell ist der SPI, 
das scheint relativ langsam zu sein.


> Edit:
> Sorry und ich meinte die Anzahl an Kommandos, nicht die Größe der DL

Aber wie kommst Du auf die Anzahl der Kommandos?
Was genau meinst Du damit?
In der Display-Liste hat jedes Kommando 32 Bit, da war ich vorhin kurz 
verwirrt weil ich nie mit der Display-Liste direkt arbeite, aber es gibt 
wirklich keine Kommandos die länger sind.
Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten, 
da müsste man schon die Befehle im Quelltext zählen weil die keine 
einheitliche Größe haben.

Wie groß wird denn die Display-Liste?

[Spyy (Gast)]

Daniel S. schrieb:
> Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten
> auf EVE_busy), per polling circa 20ms.

Wann (vor welchem Befehl) wartest Du mit Eve_busy ? end_burst?
Ist das nur wenn Du touch auf dem Screen machst? Sind die Glitches nur 
auf einem Foto zu sehen, wieviel Hz Widerholrate/Kontentupdate hast Du 
denn? Ich benutze auch Scissor...das geht zuverlässig...

Also meine Erfahrungen sind jetzt, alles mit Teensy 4.1 und DMA burst:
- Ich "fahre" das Display mit 81 Hz, update den Kontent mit 81 Hz => 
geht gut, updateraten der gesamten Liste (zwei Bursts mit eve_busy vor 
dem 2. Burst) ca. 1.0x-1.3x ms. Dann Pause von 12.x ms (81 Hz). Ich 
lasse mir den fifo (gesamt und head/tail ausgeben und die Differenz ist 
immer 0). Ein Wehrmutstropfen ist ein, mitlerweile seltenes, Ruckeln 
(sieht aus als wenn die Applikation steht für ne ms oder so).
- Ich habe mit meinem neuen Layout 51 Ohm in den SPI lines und "fahre" 
den erst mit 4 Mhz zum Init, dann mit 25 Mhz und signal strenght auf der 
niedrigsten Stufe=>geht, ob der electrical noise level jetzt besser 
ist...keine Ahnung..
- Ich habe jetzt nen 12 Mhz Quarz auf dem Board mit 2x 18pF Cs=>geht. 
Ich weiss jetzt auch warum das mit meinen alten Boards nicht ging, die 
Library für den Quarz für Eagle/Fusion360 ist vom Pinning falsch...ganz 
toll!
Ich habe jetzt 72003281 Hz als internen Takt, wie es sein soll. Mit 
externer Taktquelle mit 12 Mhz PWM 50% duty nur 69xxxxxx Hz=>so nicht 
machen, ist Mist
- Ich habe jetzt eigene Vectorfonts gemacht, mit Linien, Linestrip, 
Punkten usw. damit "schwillt" natürlich der Fifo an=>musste ich in zwei 
Bursts aufteilen sonst wird die Fifo Liste zu lang (über 4096), Teensy 
"stalled" dann oder es gibt Artefakte.
Damit kann ich jetzt die "Fonts" um 1/16 pixel "schieben" und drehen mit 
AntiAliasing, geht ja bei den Fonts/Bildern auch nicht. Sieht nun top 
aus.
- Ich kann bestätigen, dass man den Fifo, ausser man schickt mehr als 4k 
auf einmal hin, nicht "überfordern" kann (SPI@25MHz), man muss aber, 
bevor man erneut ein burst hinschickt mit eve_busy warten.
- Display list hat bei mir so ca. 5000-6000 Bytes mit Optimierungen nur 
das anzuzeigen was auch wirklich zu sehen ist und Minimierung von 
Farb/Dicken/usw. Änderungen.
Leider kann man ja hier keine Videos anhängen...:(

Danke jedenfalls an alle hier....:)..für die Hilfen und Tips...

Mal sehen ob mein Display auch mit Mipi geht..HW mässig wird das von dem 
Display exponiert und man kann die Betriebsart per Codierung einstellen. 
Dann ggf. mit nem Raspi oder z.B. Portenta H7 oder X8. Die haben "nativ" 
Mipi Dsi.
Der Eve chip ist sicher eine gute Idee, auf Dauer ist der chip sicher 
etwas einschränkend...wäre aber sicher auch cool wenn der weiter 
entwickelt wird...

Grüße
Torsten

[Rudolph (Gast)]

Spyy schrieb:
> - Ich "fahre" das Display mit 81 Hz, update den Kontent mit 81 Hz =>
> geht gut, updateraten der gesamten Liste (zwei Bursts mit eve_busy vor
> dem 2. Burst) ca. 1.0x-1.3x ms.

Also 25MHz sind "nur" so 3000 Bytes pro ms, hast Du mal probiert 
REG_CMDB_SPACE zu lesen nachdem der DMA durch ist? So statt EVE_busy()?
EVE_busy() wartet ja bis der FIFO komplett leer ist.

Eine andere Idee wäre noch zwei DMA Puffer zu verwenden die abwechselnd 
gefüllt und verschickt werden, so um nicht einfach nur zu warten.

Wobei 8k SRAM schon deutlich unter Luxus fallen wenn man überlegt wofür 
die EVE Chips eigentlich gedacht sind. :-)
Und wenn ich dann noch bedenke das ich zur Zeit Controller mit weniger 
Speicher verwenden muss, weil eben nichts zu bekommen ist - Aua. :-)

[Daniel S. (snipod)]

Rudolph R. schrieb:
> Was meinst Du jetzt mit Polling?
> Jedes Kommando einzeln Plus ein busy()?

Jedes Kommando als "nicht-burst" und nach jeder Komponente (also mein 
Button / Slider...) ein busy().

Rudolph R. schrieb:
> Was für einen Controller hast Du eigentlich und wie schnell ist der SPI,
> das scheint relativ langsam zu sein.

Ist ein ESP32 der mit 240MHz rennt. Der SPI Läuft mit 30 MHz

Rudolph R. schrieb:
> Aber wie kommst Du auf die Anzahl der Kommandos?
> Was genau meinst Du damit?

Sorry, das war einfach schlecht erklärt von mir. Ich habe mir zum testen 
in EVE_end_cmd_burst(), EVE_dma_buffer_index ausgeben lassen. Dieser 
zählt dann dementsprechend 560 - 650 ungefähr...

Rudolph R. schrieb:
> Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten,
> da müsste man schon die Befehle im Quelltext zählen weil die keine
> einheitliche Größe haben.

Das stimmt, aber ist es nicht sogar wahrscheinlich, dass dieser bei ~600 
Kommandos die 8k zum überlaufen bringt?

Spyy schrieb:
> Wann (vor welchem Befehl) wartest Du mit Eve_busy ? end_burst?

Genau, ich warte auf EVE_busy() nach(!) end_burst.

Spyy schrieb:
> Ist das nur wenn Du touch auf dem Screen machst?

Interessante Frage, ich versuch mal die DL so zu verlängern und schau ob 
die Glitches auch ohne Touch auftreten.

Spyy schrieb:
> wieviel Hz Widerholrate/Kontentupdate hast Du
> denn?

Ich hab mich hier bisschen an Rudolphs Beispiel orientiert, lese alle 
7ms die Touch Register aus und jedes 5. mal zeichne ich die Seite neu. 
Dementsprechend fahre ich circa 28.5 Hz... eigentlich nicht viel. Dafür 
sind meine Controls halt ziemlich aufwendig, allein ein so ein 
Wippschalter hat knapp 180 Kommandos im worst-case.

ich probier mal bisschen weiter und melde mich :)

[Daniel S. (snipod)]

Folgendes hab ich probiert (ohne Erfolg):

1. das Display nicht anfassen -> programmatisch die Schalter auf 
"touched" setzen. => Glitches sind weiterhin da

2. SPI Speed auf 20MHz runter, Zeichnen der Seite alle 100ms => Glitches 
weiterhin da

3. REG_CMDB_SPACE während EVE_dma_busy auslesen nach end_burst -> circa 
2k während der Glitches

Gibts was womit man langen text hiden kann? Ich hänge mal meinen code 
für den Button an, vielleicht fällt jemandem etwas auf

EVE_cmd_dl_burst(VERTEX_FORMAT(0));
    EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_RGB(255, 255, 255));
    EVE_cmd_dl_burst(COLOR_A(0));
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));

    // draw outline
    // outline radius = _br
    // draw the outline with alpha = 0 to set stencil
    EVE_cmd_dl_burst(LINE_WIDTH(_br * 16));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_x + _br, _y + _br));
    EVE_cmd_dl_burst(VERTEX2F(_x + _w - _br, _y + _h - _br));
    EVE_cmd_dl_burst(DL_END);

    // fill the stencil area with the gradient
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
    GradientHelper::Gradient(_x, _y, _w, _h, 0x131314, 0x202428, 0.1405, 0.8529, 318.21, true);
    // reset the stencil
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);

    // calculate size of the inner area
    _brInner = _br - 4;
    _xInner = _x + 4;
    _yInner = _y + 4;
    _wInner = _w - 8;
    _hInner = _h - 8;

    // set scissor rectangle for inner area
    EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));
    EVE_cmd_dl_burst(SCISSOR_SIZE(_wInner, _hInner));
    // draw inner area
    // draw the inner area with alpha = 0 to set stencil
    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
    EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_xInner + _brInner, _yInner + _brInner));
    EVE_cmd_dl_burst(VERTEX2F(_xInner + _wInner - _brInner, _yInner + _hInner - _brInner));
    EVE_cmd_dl_burst(DL_END);

    // fill the stencil area with the gradient
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
    GradientHelper::Gradient(_x, _y, _w, _h, 0x151618, 0x34393F, -0.05, 1.0, 331, true);

    // reset stencil and stencil function
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    // Up part is pressed
    if (Up)
    {
        uint16_t xPart = _x + 4;
        uint16_t yPart = _y + 4;
        uint16_t wPart = _w - 8;
        uint16_t hPart = (_h / 2) - 4;
        // set scissors to upper part of control
        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));
        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));
        // setup the stencil for the upper area
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart + _brInner));
        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart + _brInner));
        EVE_cmd_dl_burst(DL_END);

        // fill the stencil area with the gradient
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
        GradientHelper::Gradient(_x, _y, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);

        // reset stencil and stencil function
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    }

    // Down part is pressed
    if (Down)
    {
        uint16_t xPart = _x + 4;
        uint16_t yPart = _y + (_h / 2);
        uint16_t wPart = _w - 8;
        uint16_t hPart = (_h / 2) - 4;
        // set scissors to upper part of control
        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner + (_h / 2) - 4));
        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));
        // setup the stencil for the upper area
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart - _brInner));
        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart - _brInner));
        EVE_cmd_dl_burst(DL_END);

        // fill the stencil area with the gradient
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
        GradientHelper::Gradient(_x, _y + _h / 2, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);

        // reset stencil and stencil function
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
    }
    // draw the center line
    EVE_cmd_dl_burst(SCISSOR_XY(_x + 4, _y + (_h / 2) - 2));
    EVE_cmd_dl_burst(SCISSOR_SIZE(72, 4));
    EVE_cmd_gradient_burst(_x + 5, _y + 86, 0x202428, _x + 76, _y + 74, 0x151618);

    // scissor rectangle for indicator
    EVE_cmd_dl_burst(SCISSOR_XY(_x, _y - 14));
    EVE_cmd_dl_burst(SCISSOR_SIZE(_w, 10));
    EVE_cmd_dl_burst(COLOR_A(255));
    // draw the activity indicator
    if (Up || Down)
    {
        // draw the border
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x202020);

        EVE_cmd_dl_burst(LINE_WIDTH(2 * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
        EVE_cmd_dl_burst(DL_END);
        // draw the indicator line
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xC02825);
        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
        EVE_cmd_dl_burst(DL_END);

        EVE_cmd_dl_burst(COLOR_A(255));
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);
    }
    else
    {
        // draw the inactive line
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x161A1D);
        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
        EVE_cmd_dl_burst(DL_END);
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);
    }
    EVE_cmd_dl_burst(SCISSOR_XY(0, 0));
    EVE_cmd_dl_burst(SCISSOR_SIZE(480, 800));

    // draw the arrows
    EVE_cmd_setbitmap_burst(UpArrowAsset::GetInstance()->currentMemoryAddress, UpArrowAsset::GetInstance()->GetFormat(), UpArrowAsset::GetInstance()->GetWidth(), UpArrowAsset::GetInstance()->GetHeight());
    EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_dl_burst(VERTEX2F(
        _x + (_w - UpArrowAsset::GetInstance()->GetWidth()) / 2,
        _y + (_h / 4) - (UpArrowAsset::GetInstance()->GetHeight() / 2)));
    EVE_cmd_dl_burst(DL_END);
    EVE_cmd_setbitmap_burst(DownArrowAsset::GetInstance()->currentMemoryAddress, DownArrowAsset::GetInstance()->GetFormat(), DownArrowAsset::GetInstance()->GetWidth(), DownArrowAsset::GetInstance()->GetHeight());
    EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
    EVE_cmd_dl_burst(VERTEX2F(
        _x + (_w - DownArrowAsset::GetInstance()->GetWidth()) / 2,
        _y + 3 * (_h / 4) - (DownArrowAsset::GetInstance()->GetHeight() / 2)));
    EVE_cmd_dl_burst(DL_END);

    // draw the label
    if (_posLabel != NULL)
        EVE_cmd_text_burst(_x + (_w / 2), _y - 26, GothamMedium18_FontHandle, EVE_OPT_CENTER, _posLabel);

    // draw the touch area
    EVE_cmd_dl_burst(COLOR_A(0));
    EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
    // touch area for UP
    EVE_cmd_dl_burst(TAG(_tag));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_x, _y));
    EVE_cmd_dl_burst(VERTEX2F(_x + _w, _y + _h / 2));
    EVE_cmd_dl_burst(DL_END);
    // touch area for DOWN
    EVE_cmd_dl_burst(TAG(_secondaryTag));
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
    EVE_cmd_dl_burst(VERTEX2F(_x, _y + _h / 2));
    EVE_cmd_dl_burst(VERTEX2F(_x + _w, _y + _h));
    EVE_cmd_dl_burst(DL_END);
    EVE_cmd_dl_burst(COLOR_A(255));
    EVE_cmd_dl_burst(TAG(0));

[Rudolph (Gast)]

Daniel S. schrieb:
> Rudolph R. schrieb:
>> Was für einen Controller hast Du eigentlich und wie schnell ist der SPI,
>> das scheint relativ langsam zu sein.
>
> Ist ein ESP32 der mit 240MHz rennt. Der SPI Läuft mit 30 MHz

Ah ok, kein Wunder, dass das ohne Burst so langsam ist.
Das ESP-IDF überzeugt mich so gar nicht.
Einen DMA Transfer zu starten bedeutet auch nicht einen DMA Transfer zu 
starten, sondern vielmehr beim RTOS freundlich anzufragen in Erwägung zu 
ziehen den irgendwann mal anzuwerfen...
Ich habe keine Ahnung, warum die Dinger so erfolgreich sind, an der 
Software kann es eher nicht liegen. Oder es schaut zumindest kaum einer 
genau hin, warum das für 240MHz so unfassbar langsam ist.

In dem Bild oben braucht mein Controller 718µs um die Display-Liste 
zusammen zu puzzeln und den FIFO mit 3888 Bytes zu füllen. Nur benutze 
ich einen ATSAMC21 mit 48MHz.

> Rudolph R. schrieb:
>> Aber wie kommst Du auf die Anzahl der Kommandos?
>> Was genau meinst Du damit?
>
> Sorry, das war einfach schlecht erklärt von mir. Ich habe mir zum testen
> in EVE_end_cmd_burst(), EVE_dma_buffer_index ausgeben lassen. Dieser
> zählt dann dementsprechend 560 - 650 ungefähr...

Das ist ja nur die Anzahl der 32 Bit Wörter im Co-Pro FIFO.
Das können direkt Display-Listen Kommandos sein, so alles was 
EVE_cmd_dl() ist, die Co-Pro Kommandos brauchen allerdings mehrere 32 
Bit Wörter und das werden dann diverse Display-Listen Kommandos.

> Rudolph R. schrieb:
>> Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten,
>> da müsste man schon die Befehle im Quelltext zählen weil die keine
>> einheitliche Größe haben.
>
> Das stimmt, aber ist es nicht sogar wahrscheinlich, dass dieser bei ~600
> Kommandos die 8k zum überlaufen bringt?

Jain.
Möglich auf jeden Fall, aber es kommt halt darauf an was da drin steckt.
Siehe mein Bild oben, das sind 3888 Bytes im FIFO, entsprechend 972 32 
Bit-Wörter.
Damit mache ich die Display-Liste voll.
Ich habe allerdings bewusst 16 CMD_BUTTON mit rein geworfen da ich 
wusste, dass die in viele Display-Listen Kommandos resultieren.
Dein Code da oben hat doch fast nur EVE_cmd_dl drin, das geht direkt so 
in die Display-Liste.

Weil der Zusammenhang zwischen Display-Liste und FIFO nicht direkt 
offensichtlich ist, lasse ich mir ja auch beides ausgeben um das im 
Blick zu behalten.

[Rudolph R. (rudolph)]

Ich habe EVE_busy() gerade mal ein wenig erweitert.
Es gibt einen neuen Rückgabewert: EVE_FIFO_HALF_EMPTY.

Damit gilt:
EVE_IS_BUSY - wenn ein DMA Transfer aktiv ist oder weniger als 2048 
Bytes frei sind
EVE_FIFO_HALF_EMPTY - wenn kein DMA Transfer aktiv ist und mehr als 2048 
Bytes frei sind
E_OK - wenn kein DMA Transfer aktiv ist und der FIFO ganz leer ist

Damit sollte es möglich sein einen zweiten DMA Transfer früher zu 
starten als bisher, wenn man mehr als die 4k FIFO braucht.
Außerdem gibt es noch die Variable EVE_dma_busy.
Die wird auf 0 gesetzt sobald der DMA Transfer durch ist, spätestens 
dann kann man anfangen den nächsten Puffer zu füllen.
Vor dem EVE_end_cmd_burst() noch mit EVE_busy() auf entweder E_OK oder 
EVE_FIFO_HALF_EMPTY warten und alles wird gut. :-)
Damit dürfte die Zeit zwischen zwei Transfers deutlich kürzer werden.

Edit: ach so, ist noch nicht auf Github, aber bald. :-)

[Spyy (Gast)]

Wow danke...

Mal sehen ob ich damit die Zeiten für ein refresh noch optimieren 
kann...

:)

[Rudolph R. (rudolph)]

Ich probiere gerade aus, die _burst Funktionalität wieder in die 
normalen Funktionen zu packen.

Das sieht dann so aus:

void EVE_cmd_dl(uint32_t command)
{
    if(cmd_burst)
    {
        spi_transmit_burst(command);
    }
    else
    {
        eve_begin_cmd(command);
        EVE_cs_clear();
    }
}


void EVE_cmd_dl_burst(uint32_t command)
{
    spi_transmit_burst(command);
}

Nur ist das selbst für die paar Kommandos in meinem Beispiel zum einen 
messbar langsamer, zum anderen 392 Bytes größer.
Nun ja, langsamer ist relativ, ich lasse das gerade bare-metall auf 
einem Raspberry Pi Pico laufen mit DMA, statt 15µs dauert das Befüllen 
des Puffers jetzt 17µs und 392 Bytes fallen da auch nicht auf.
Der Gewinn wäre die ganzen Funktionen nicht mehr mit _burst() schreiben 
zu müssen zwischen dem EVE_start_cmd_burst() / EVE_end_cmd_burst().

Alle Platformen ohne DMA haben dann allerdings gelitten.

Schon seltsam, dass 25 Vergleiche selbst auf einem Cortex-M0+ mit 125MHz 
schon so 2µs ausmachen.

Ich muss das mal auf einem UNO ausprobieren.

[Rudolph R. (rudolph)]

Hmm.
Ich habe das jetzt mit einem UNO (Arduino), einem Metro-M4 (Arduino) und 
dem Pi Pico (Bare-Metall) ausprobiert und bei allen drei zeigt sich das 
Gleiche.

Schreibt man das in der vereinfachten Form hin, also so:

EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_dl(TAG(0));
EVE_cmd_append(MEM_DL_STATIC, num_dl_static);
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_fgcolor(0x00c0c0c0);

Dann wird das Programm zum einen langsamer und zum anderen größer durch 
die nun etwas längeren Funktionen.

Benutzt man allerdings die xxx_burst() Funktionen zusammen mit der 
modifizierten EVE_commands.c, dann läuft die Software wieder schneller 
ist ist nur ein wenig größer.

Beim UNO ist der Unterschied am Größten, das sind 520µs mit _burst 
Funktionen und 548µs mit normalen Funktionen die den Burst können.
Das Programm wird 618 Byte größer.
Mit modifizierten Funktionen aber unter Verwendung der _burst Funktionen 
komme ich wieder auf 520µs, das Programm ist dann 58 Byte länger.

Ok, klar, mit anderen Display-Listen wird der Unterschied größer.
Vor allem wenn weniger Funktionen beim Compilieren raus optimiert werden 
können.
Aber der Preis dafür das _burst wegzulassen ist vor allem auf Platformen 
die DMA unterstützen so klein, das macht gar nichts.

Dann baue ich das mal komplett um, zurück rollen geht ja immer noch. :-)

[Rudolph R. (rudolph)]

Oh je, ich weiß jetzt gerade nicht warum, aber ich habe die neue Version 
eben auch mit dem Teensy 4.1 ausprobiert.
Und da ändert sich nichts, die Anzeige mit dem Demo-Code ist immer noch 
"0003us". :-)

[Spyy (Gast)]

....also ich habe kein Problem immer _burst zu schreiben...:)...da ich 
ja quasi fertig bin...
Das mit dem neuen busy habe leider noch nicht probieren können...kommt 
Zeit kommt rat...

[Rudolph R. (rudolph)]

Spyy schrieb:
> ....also ich habe kein Problem immer _burst zu schreiben...:)

Ich finde es sieht schon irgendwie doof aus. :-)
Aber wenn man das zur Laufzeit aufdröseln will kommt man nicht drum 
herum einen Vergleich zu machen und der kostet Zeit.
Das sind 5% beim UNO.
Und bei allem mit DMA, 5% von praktisch nichts ist immer noch nichts, da 
kann man sich auch erlauben weniger zu tippen. :-)

[Spyy (Gast)]

Moin,

ihr habt doch Ahnung....
Ich lese einen Rotaryencoder in einen Schmittrigger 1A und 2A 
(74LVC2G14, je ein Kanal des Rotary A und B) ein und habe direkt die 
Ausgänge 1Y und 2Y mit einem Seeeduino XIAO von Seeedstudios an die 
digitalen Eingänge 9 und 10 verbunden.
Diese habe ich als Interrupt Eingänge konfiguriert (Flanken).
Nun kommt es aber immer wieder zu IRQ Auslösungen obwohl der Rotary 
nicht bewegt wird. Das hört auf, wenn ich mit nem Taskopf vom Ossi da 
ran gehe...die Signale sehen Top aus.
Ich habe mit/ohne internen Pullup oder mit 2x externen Pullup (10kOhm, 
ist alles 3.3V) versucht...kein Erfolg..
Ist das irgendwas mit der eine kann den anderen nicht treiben, oder 
so...?

Grüße und Danke...

[Rudolph R. (rudolph)]

Oh, vorzugsweise kein Kommentar, zum Thema Drehimpulsgeber wurden hier 
im Forum schon Kriege geführt. :-)

Aber das klingt jetzt als würde Dir noch ein Kondensator an den 
Drehgeber Pins fehlen, so 100pF bis 1nF, was anderes als ein paar pF 
zusätzlich bewirkt der Tastkopf ja nicht.

Der D21 auf dem Seeeduino XIAO hat im External Interrupt Controller aber 
auch die Möglichkeit Filtern zu aktivieren.
Und den GCLK_EIC könnte man auch noch kleiner einstellen.

[Spyy (Gast)]

...Kriege...oh je...soll nicht sein...

Ich denke das war "mein alter Freund" drive strenth....habe ich runter 
gedreht...und zack, schon geht es...ich habe über ein FFC Flachbandkabel 
PWM "Signale" (keine Ahnung was da die Standardfrequenz ist) für die 
Helligkeitsregelung der LEDs und in dem gleichen Kabel die Signale vom 
Schmittrigger der Encodersignale A und B. Das übersprechen hat 
offensichlich schon gereicht die IRQs im XIAO auszulösen...obwohl ich 
die Störungen auf dem Oszi nicht sehen konnte...nach dem "runterdrehen" 
des drive strenth ist jedenfalls alles ruhig...sollte man da noch solche 
Kondensatoren (wie bei der IC Spannungsversorgung) gegen Masse an die 
Signalleitungen A und B machen? Encoder A und B Flanken haben ja ne 
relativ niedrige Frequenz...selbst wenn man schnell dreht...

Grüße und Danke

[Rudolph R. (rudolph)]

Spyy schrieb:
> sollte man da noch solche
> Kondensatoren (wie bei der IC Spannungsversorgung) gegen Masse an die
> Signalleitungen A und B machen?

Wie ich schrieb, kann man ja machen, nur eher bis so 1nF, aber das sind 
zusätzliche Teile. :-)
Die eingekoppelten Spikes werden auch sehr kurz sein, dagegen hilft das 
Hardware-Filtern durch den Interrupt-Controller, die Pins werden ja 
nicht nur einmal gelesen und sofort ein Interrupt ausgelöst.

[Spyy (Gast)]

Moin,

also ich bin ein mittelmäßiger Programmierer...und bei "analog Technik" 
hört es bei mir komplett auf...

Ich habe ja nun meine "Gerät" zusammengedengelt, läuft auch gut...habe 
da aber auch eine ziemlich aufwändige Spannungsversorgung drauf von 
Pololu (D36V28Fx) glaube ich also zwei davon (3.3 und 5V). Benötige 3.3V 
und 5V Gesamtleistungsaufnahme ca. 2-5 Watt Ströme so auf der 3.3 V um 
die 1 Amp bei 5 V etwas weniger....

Hat jemand Ahnung/eine gute Idee was es da für Bauteile gibt die man da 
verwenden könnte (also so aus 5-40V mache 5V und 3.3V oder 1.8V) um sich 
da ne eigene Spannungsversorgung für ICs zusammen zu zimmern ?

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Ich benutze bei meinen ganzen Display-Platinen den gleich Typ 
Schaltregler.
https://github.com/RudolphRiedel/EVE_display-adapter/tree/master/L-D5019-08
Wobei Typ jetzt nicht in dem Sinne das Bauteil direkt ist, mehr so 
SOT-23-6 mit dem Pinout, um 1A und 1,4MHz, davon gibt es nämlich einen 
ganzen Satz.

Die RT8259GE habe ich zwar  im Schaltplan stehen, die zu bekommen war 
zwischendurch aber nicht ganz lustig und die können "nur" 24V.
Ein R1240N001B-TR-FE steht in meiner Tabelle mit 30V, wie gut die laufen 
kann ich nicht sagen, ausprobiert habe ich die noch nicht.

Für 40V braucht man vermutlich einen größeren Regler oder was in einem 
"moderneren" Package, mir gefällt das SOT-23-6 soweit aber sehr gut. :-)

Für das RVT101HVBNWC00-B habe ich zwei Regler auf der Platine, einen für 
3V3, den anderen für 9V6.
Für das RVT70HSBNWC00-B habe ich die gleiche Platine benuzt, nur den 
Regler für das Backlight auf 5V runter konfiguriert.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Oder versuche es damit:
https://www.we-online.com/katalog/datasheet/171020601.pdf
Der ist zwar ein bisschen teurer, kann man aber auch als Muster 
anfordern, wenn man nur 1 Stück benötigt. Vorteil: Kompakt, keine 
separate Spule erforderlich (alles drin) und eben sehr leistungsfähig 
(Ui 6-42V, Uout 0,8 - 6V, 2A).
Ansonsten mal bei farnell "Schaltregler" eingeben:
https://de.farnell.com/c/halbleiter-ics/power-management-ics-pmic-/spannungsregler/dc-dc-schaltregler-einstellbar?searchref=searchlookahead
(hier 4756 Ergebnisse).
ein paar gewünschte Filter setzen und man wird mit hunderten 
Schaltreglern zugeschüttet. Vorteil: Man sieht gleich, was auf Lager 
ist...
Bernd

[Stanley (homer2009)]

Hello, I bought a display like 
this:https://es.aliexpress.com/item/32639840939.html?spm=a2g0o.order_list.0.0.21ef194dLDRmAI&gatewayAdapt=glo2esp.Could 
someone tell me what the config for this display should be.I use this 
library:https://github.com/RudolphRiedel/FT800-FT813.I have 
documentation for this display. The frequencies measured on the display 
are as follows:VSYNC-45Hz,HSYNC-36kHz ,PCLK-21MHz

[Rudolph R. (rudolph)]

This is not that easy to answer.

If you have a FT81x / BT81x board that is wired correctly and can supply 
the necessary current for the different voltage rails, then this might 
be possible.

I have no idea though if additional configuration of the chip is 
necessary and there is no datasheet for the display itself.
The next question would be which of the three connectors is actually 
populated.
And regardless which one is populated, the SDO pin from the panel is not 
wired on the board, so there is no way to ready anything from the chip.
At least it looks like SPI is configured and not MIPI DBI Type C, this 
makes things a bit less complicated.
My library does not have code to configure individual display chips with 
an additional SPI interface though.

As for the configuration, I would try EVE_EVE2_50, but that depends on 
the EVE chip that is actually used and the PCB for it, EVE_EVE2_50 is 
probably the most generic though.

[Stanley (homer2009)]

OK thank you for the information

[Spyy (Gast)]

Super, danke für eure Hinweise...werde mir einen aussuchen....

Dazu noch eine Frage:
Ich habe ein PoE Modul, welches in den "Stufen" 12V, 5V, 3.3V für die 
Ausgangsspannung zu haben ist: z.B. hier 
https://www.mouser.de/ProductDetail/Silvertel/Ag9705S?qs=OlC7AqGiEDnLRebpRgMQIg%3D%3D
Macht aus PoE über nen Trafo die gewünschte Versorgungsspannung => Toll

So...soweit so gut...ich brauche aber "leider" 5V und 3.3V mit einer 
gesamt Leistungsaufnahme ca. 5 Watt.
Macht es Sinn hier ein 5V PoE Modul zu nehmen, davon die 5V als 
Versorgung zu nutzen und noch über einen Schaltregeler daraus 3.3V zu 
machen?
ODER
Ein PoE Modul mit 12V Ausgangsspannung und daraus über zwei 
Schaltregeler 5V und 3.3V machen?

Grüße und Danke
Torsten

[Rudolph R. (rudolph)]

Mit diesen POE Modulen habe ich keine Erfahrungen.

Was mir spontan nur auffällt, bei 12V Ausgang macht das Teil 12W, bei 5V 
Ausgang "nur" 9W.
Aber wenn Du davon nur 5W brauchst, dann passt das doch mit dem 5V 
Ausgang und noch mal 3,3V Schaltregler dahinter.
Mit 12V Ausgang und zwei Reglern ist das vielleicht universeller 
benutzbar, dafür sind es aber eben auch mehr Teile.

[Bernd (Gast)]

Spyy schrieb:
> Macht es Sinn hier ein 5V PoE Modul zu nehmen, davon die 5V als
> Versorgung zu nutzen und noch über einen Schaltregeler daraus 3.3V zu
> machen?
Wenn die Stromaufnahme bei 3,3 V überschaubar ist, kann man auch einen 
Linearregler nehmen.

[Paul B. (paule201)]

Hallo zusammen,

ich spiele gerade mit einem STM32F303 und einem EVE2 Display von 
NewHeaven rum. (NHD-4.3-480272FT-CSXP-T)
https://newhavendisplay.com/4-3-inch-ips-480x272px-eve2-resistive-tft/

Ich habe die Funktionen spi_transmit und spi_recieve auf die HAL 
Variante umgebaut. SPI Frequenz sind 4.5HMz.

static inline void spi_transmit(uint8_t data)
{
  HAL_SPI_Transmit(&hspi1, &data, 1 , 50);
}
#endif

und

static inline uint8_t spi_receive(uint8_t data)
{
    uint8_t  dain;
    HAL_SPI_TransmitReceive(&hspi1, &data, &dain, 1 , 50);
    return (dain);
}

Ich lese erfolgreich die Chip ID 0x7C = 124. SPI Kommunikation sollte 
also passen. Verbunden sind Display und Platine mit 20cm Flachband 
Kabel.

Im Precpocessor habe ich "EVE_NHD_43" definiert. In der "EVE_config.h" 
sind verschiedene Parameter angegeben, allerdings weniger als im 
Datenblatt.

Das Display flackert immer nur ganz kurz wenn der "PDN Pin" betätigt 
wird. Ansonsten passiert leider nichts.

Hab ich noch was übersehen? Muss ich die anderen Parameter aus dem 
Datenblatt noch mit in die EVE_config schreiben?

@Rudolph: Viel vielen Dank das du diese Lib mit allen teilst, das 
erspart sehr viel Zeit und Frust!

Edit: Ich rufe nur die TFT_init auf, aber die sollte ja zumindest die 
Rechtecke und Kreise anzeigen.

Beste Grüße

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Ich habe die Funktionen spi_transmit und spi_recieve auf die HAL
> Variante umgebaut. SPI Frequenz sind 4.5HMz.

Ok, gab es dafür einen besonderen Grund?
Der einzige Unterschied zu meiner Variante mit LL_SPI_TransmitData8() 
ist ja das dadurch der Code langsamer wird, da mehr an sich überflüssige 
Checks jedes Mal neu durchgeführt werden.
Also kann man sicher machen, ich wundere mich nur.

Paul B. schrieb:
> Im Precpocessor habe ich "EVE_NHD_43" definiert. In der "EVE_config.h"
> sind verschiedene Parameter angegeben, allerdings weniger als im
> Datenblatt.

Nicht wirklich, unter dem Define Resolution_480x272 gibt es am Ende der 
EVE_config.h noch einen ganzen Satz Defines, viele Displays verwenden 
einfach die gleiche Konfiguration und so wird die ganze Datei deutlich 
kompakter.

Paul B. schrieb:
> Das Display flackert immer nur ganz kurz wenn der "PDN Pin" betätigt
> wird. Ansonsten passiert leider nichts.

> Edit: Ich rufe nur die TFT_init auf, aber die sollte ja zumindest die
> Rechtecke und Kreise anzeigen.

Meine TFT_init() aus dem Beispiel zeigt gar nichts an, da wird nur das 
Display initialisiert, so grundsätzlich, dann Backlight, Touch, Bilder 
an EVE schicken und am Ende wird mit initStaticBackground() eine 
Display-Liste generiert und in den Speicher von EVE geschrieben als 
Fragment für spätere Benutzung.
Erst mit der TFT_display() wird was angezeigt, inklusive dem vorher 
generiertem Fragment das ziemlich am Anfang mit EVE_cmd_append_burst() 
in die Liste eingehängt wird.

Also einmal noch TFT_display() hinterher und es sollte was angezeigt 
werden.

Paul B. schrieb:
> @Rudolph: Viel vielen Dank das du diese Lib mit allen teilst, das
> erspart sehr viel Zeit und Frust!

Gerne, ich hatte auch mit den Herausforderungen soweit viel Spaß. :-)
Ich hätte jetzt auch nicht gedacht, dass das Projekt immer noch läuft.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Ok, gab es dafür einen besonderen Grund?

Ich habe die LL Libs auf die schnelle nicht zur Hand gehabt, daher bin 
ich auf die HAL Version umgestiegen. Für die finale Anwendung würde ich 
dann wahrscheinlich auf die LL gehen.

Rudolph R. schrieb:
> Nicht wirklich, unter dem Define Resolution_480x272 gibt es am Ende der
> EVE_config.h noch einen ganzen Satz Defines

Alles klar, soweit unter war ich gar nicht. Danke für die Aufklärung!

Rudolph R. schrieb:
> Meine TFT_init() aus dem Beispiel zeigt gar nichts an

Dann hab ich das falsch verstanden, ich dachte das wäre schon so eine 
Basic Anzeige dabei.

Rudolph R. schrieb:
> Also einmal noch TFT_display() hinterher und es sollte was angezeigt
> werden.

Danke, dass bringt mich schon mal einen Schritt weiter!
Jetzt sehe ich auch die EVE2 Demo mit dem Stern Logo. Leider sehe ich 
sie nur für den Bruchteil einer Sekunde, genau dann wenn der PDN Pin per 
"PDN_Set" auf LOW gesetzt wird. Ich kann das mit dem Debugger auch nicht 
anhalten, es ist genau der Moment wenn er auf low geht wo ich kurz was 
sehe.

Meine while Schleife ist ziemlich simple:

 
 while (1)
  {
    TFT_init();
    HAL_Delay(1000);
    TFT_display();
    HAL_Delay(1000);
}

Ich habe mir alle Spannungen direkt am Display mit dem Oszi angesehen 
(5V und 3,3V), die brechen nicht ein oder ähnliches.

Das Vergrößern des Delays zwischen PDN_SET und PDN CLEAR brachte auch 
nicht.

Hast du noch eine Idee?

Danke für deinen Support!

[Rudolph R. (rudolph_r)]

Die TFT_init() gehört vor die Schleife.

[Paul B. (paule201)]

Das hatte ich zuerst auch probiert, da kam der DEMO Screen genau einmal 
kurz aufgeblitzt (in der TFT_init bei PDN_SET) und auch nur dann wenn 
ich zwischendurch die Spannung nicht weggenommen habe. Fürs Debugging 
hab ich es dann alles in die "while" geschrieben.

Das bedeutet im Umkehrschluss, dass die Übertragung der Daten sauber 
läuft. Beim zweiten durchlauf der TFT_init durch den kurzen Reset nach 
dem Power Down zeigt er alle korrekt an und dann wird es wieder dunkel 
--> er hat die Daten im Speicher und kurz nach dem Reset blitzt eben das 
"letzte Bild" auf.

Auch der "warm start" funktioniert leider nicht. (PDN_SET und CLEAR sind 
dabei auskommentiert)

EVE_cmdWrite(EVE_RST_PULSE,0U);  // reset, only required for warm-start if PowerDown line is not used

So nah dran und doch so fern :D.

[Rudolph R. (rudolph)]

So, jetzt noch mal von zu Hause und nicht vom Handy, aus irgendeinem 
Grund konnte ich nicht "anonym" posten.

Zeig doch mal ein bisschen was von dem was Du da treibst. :-)
Ich weiß auch, dass ich kein STM32 Beispiel habe, zumindest kein 
vollständig lauffähiges, vor allem habe ich bisher keinen Weg gefunden 
den Controller über HAL zu initialisieren um somit das Beispiel für 
mehrere Controller compilieren zu können.
Und generell war das lange Zeit unlustig an STM32 Controll heran zu 
kommen.
Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts 
anfangen, so funktional und ohne AECQ.


Aber, zitiert aus dem hier: 
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_STM32_RiTFT50_PlatformIO/src/main.c

int main(void)
{
    uint8_t display_delay = 0;

    HAL_Init();
//  SystemClock_Config();
    HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/200U); /*Configure the SysTick to have interrupts in 5ms time basis*/

//  EVE_init_spi();
//  EVE_init_dma();

    TFT_init();
    
    while(1)
    {
        if(system_tick)
        {
            system_tick = 0;

            TFT_touch();

            display_delay++;
            if(display_delay > 3)
            {
                display_delay = 0;

                TFT_display();
            }
        }
    }
}

Das Projekt compiliert zumindest so quer durch die Familien:
Environment    Status    Duration
-------------  --------  ------------
STM32L073      SUCCESS   00:00:01.173
STM32F030      SUCCESS   00:00:01.149
STM32F103      SUCCESS   00:00:01.154
STM32F303      SUCCESS   00:00:01.246
STM32F446      SUCCESS   00:00:01.495
STM32G474      SUCCESS   00:00:01.265
STM32G431      SUCCESS   00:00:01.258
nucleo_f439zi  SUCCESS   00:00:01.499
nucleo_h743zi  SUCCESS   00:00:01.686

Damit ist das meiste im Grunde genommen fertig, die ganze Low-Level 
Geschichten mit dem SPI gehen ohne zu Murren durch den Compiler.

Von der Struktur ist das grundsätzlich so wie ein funktionierendes 
Projekt laufen würde.
Allerdings, SystemClock_Config() ist dann sehr speziell.
Aber EVE_init_spi() sowie EVE_init_dma() gibt es immer noch nicht 
richtig, spontan bekommen man das bestenfalls ohne DMA zu laufen wenn 
man zumindest EVE_init_spi() auf das Projekt anpasst oder eben gleich 
eine eigene Funktion verwendet.

Ich plane gerade eine Platine mit STM32G0B1, da wollte ich auch nebenbei 
einen Display-Anschluss dran packen, zumindest die Controller habe ich 
da.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Zeig doch mal ein bisschen was von dem was Du da treibst. :-)

Ich lad das Projekt mal mit hoch, erstellt mit der offiziellen CUBE IDE 
vo STM. Wenn du sowieso mal was mit STM machen willst ist das eventuell 
der Trigger um die CubeIDE mal zu installieren :D.

Rudolph R. schrieb:
> Ich weiß auch, dass ich kein STM32 Beispiel habe, zumindest kein
> vollständig lauffähiges

Du machst das ja auch freiweillig und stellst alles zur Verfügung, da 
erwartet keiner für jede µC Familie ein lauffähiges Beispiel! 95% sind 
der Miete sind ja schon erledigt, dank deiner Lib.

Rudolph R. schrieb:
> Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts
> anfangen, so funktional und ohne AECQ.

Der Vorteil war bei STM32 "damals" die Preisansage. 32bit in LQFP48 für 
1$, dass war damals schon was.
Es gibt für Automotive FuSi Anwendungen auch Controller von STM, aber 
nur gegen Vorlage deiner DNA...ich hatte mal zwei SPC5 von STM in der 
Mache aber Datenblatt und Co gabs nur mit der Firmen Mail Adresse und 
CubeIDE und Co unterstützen die Teile gar nicht. Alles in allem zu viel 
Initialaufwand für Privat. Mit dem U5 könnte es zumindest für FuSi 
Anwendung außerhalb von Automotive wieder interessant werden. Der ist 
auch zu 98% Pin Compatible mit dem F303 ;).

Dein Beispiel Code und mein Code unterscheiden sich nicht viel, ich hab 
extra ein neues Projekt erstellt zum rumspielen mit dem F303 und dem 
Display, daher verwende ich aus Faulheit einfach HAL_DELAY für die 
Wartezeiten.
Sollte aber funktional keinen Unterschied machen zu deinem Beispiel mit 
dem SysTick.

Wenn wir das Ganze zum Laufen bekommen kannst du das Projekt auch gern 
mit hochladen/referenzieren für den STM32. Die Portabilität ist ja dank 
HAL (und deiner cleveren defines) easy.

Viel kann es ja bald nicht mehr sein, ich hab auch noch ein das NHD 3.5 
hier aus der selben Familie, dass zeigt genau das gleiche Verhalten.

Danke für deine Zeit!

[Rudolph R. (rudolph)]

Ich habe die STM32CubeIDE installiert. :-)
Und das Projekt baut auch.
Nur so "trocken" fällt mir da leider gerade nchts dran auf.

Hast Du einen Logic-Analyzer?

Und wie versorgst Du das Display überhaupt?
Nicht, dass der Controller einen Reset macht, weil die 
Hintergrundbeleuchtung so viel Strom zieht, dass der Regler sich 
abschaltet...

Hmm, NHD, irgendeines von denen liegt hier auch irgendwo herum, nach dem 
ersten wollte ich aber keine mehr, das FFC mit 1mm Abständen und dem 
fast kompatiblen Pinout fand ich extrem unlustig.
Ah, habs, NHD-3.5-320240FT-CSVX-CTP - gefällt mir gar nicht.
Aber nun, Newhaven hat das scheinbar aufgegeben, mit BT81x haben die 
nichts.

Paul B. schrieb:
> Rudolph R. schrieb:
>> Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts
>> anfangen, so funktional und ohne AECQ.
>
> Der Vorteil war bei STM32 "damals" die Preisansage. 32bit in LQFP48 für
> 1$, dass war damals schon was.

Tja, nun, ich habe gerade 7,03 Euro ohne Mehrwersteuer für STM32G0B1CET6 
bezahlt, 48 Pins, ab 10 Stück liegen die bei 6,36 Euro.
Das ist auch nur ein Cortex M0+ mit 64MHz, aber Speicher wie ein M4.
Ein ATSAME51J19A-AU ist bei Mouser gerade für 5,76 € gelistet und 
Digikey hat gerade sogar welche für 6,39€ das Stück bei 1 Stück.
Die können deutlich mehr, 64 Pins, haben einen 120MHz M4F, mehr SRAM und 
das ist zwar nicht die AECQ Version, aber es gibt eine.

Paul B. schrieb:
> Es gibt für Automotive FuSi Anwendungen auch Controller von STM

Ja schon, aber eben keine STM32.
SPC5 ist PowerPC, der e200 Core ist schon reichlich angestaubt und von 
Freescale lizenziert. NXP hat die MPC5xx noch weiter geführt aber 
inzwischen sind die bei der S32 Familie für Automotive mit ARM Kernen.
ST10 ist sowas von tot.
Und die Stellar sind zwar ARM aber Cortex M7 und ein eigenes Gemüse.
Ein SPC5 Board habe ich im Büro, bisher habe ich allerdings nicht 
mitbekommen das meine Abteilung was mit dem Controller gemacht hätte.

Ein S32K144 Eval-Board liegt gerade vor mir.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Nur so "trocken" fällt mir da leider gerade nchts dran auf.

Hmm, schade. Ich bau das Ganze jetzt noch mal "on the fly" auf mit einer 
auf F303 umgelöteten BluePill. Ich habe den PORTC, PIN15 im verdacht. Da 
hängt PDN dran und die Pins C13, C14 und C15 sind bei STM schwache 
Sonderlinge.

Rudolph R. schrieb:
> Hast Du einen Logic-Analyzer?

Nein, aber ein DSO mit Dekoder und Protokollfenster. Willst du was 
bestimmtes sehen?

Rudolph R. schrieb:
> Und wie versorgst Du das Display überhaupt?

Versorgt wird es über ein USB C Buchse, das USB Kabel hat offene Enden 
und hängt an einem Labornetzteil mit 3A. Dahinter sitzt ein 400mA LDO 
der auf 3,3V runter regelt. Mit Display zieht das ganze 120mA. Peakstrom 
muss ich noch messen, aber Spannungseinbrüche gab es bisher keine 
(Trigger auf 4.8V auf der 5V Leitung und 3.1V auf der 3,3V Leitung, 
fallende Flanke). Gemessen wurde direkt am Connector des Displays, da 
waren keine Einbrüche feststellbar.

Rudolph R. schrieb:
> mit BT81x haben die
> nichts.

Ist der BT81X so viel besser als der FT81X?

Rudolph R. schrieb:
> Ah, habs, NHD-3.5-320240FT-CSVX-CTP - gefällt mir gar nicht.

Mir gerade auch nicht :D.

Rudolph R. schrieb:
> Die können deutlich mehr, 64 Pins, haben einen 120MHz M4F, mehr SRAM und
> das ist zwar nicht die AECQ Version, aber es gibt eine.

Ich bin mit dem Sprung von 8 auf 32bit von Atmel weg, eventuell wage ich 
noch mal einen Exkurs. Bei STM32 fand ich halt die relative gute 
grafische Konfigurationsoberfläche nett. Für jemanden der das 
professioneller macht wahrscheinlich eher ein KO Kriterium als ein 
Benefit.

Rudolph R. schrieb:
> Ein S32K144 Eval-Board liegt gerade vor mir.

Bei NXP hab ich nach dem 1769 aufgehört, den hatten wir mal in der alten 
Firma und ich musste die Leiterplatte um das Ding designen. Mehr als ein 
Komponententest hab ich für das Ding nie programmiert, es wurden nur 
alle Sensoren kurz mal angetriggert und die Daten per UART 
rausgeschoben.

Ich melde mich wenn ich den neuen Aufbau habe, sag mir gern wenn du 
konkrete Befehle hast die ich mal mitloggen soll.

[Paul B. (paule201)]

Es läuft!

Es lag an PINC 15, einem der Sonderlinge. Ich habe die PINs getauscht 
und jetzt läuft der Kollege.

Vielen Dank für deine Hilfe!

Wenn du noch etwas brauchst für dein git repo oder ähnliches, sag 
einfach bescheid.

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Rudolph R. schrieb:
>> Nur so "trocken" fällt mir da leider gerade nchts dran auf.
>
> Hmm, schade. Ich bau das Ganze jetzt noch mal "on the fly" auf mit einer
> auf F303 umgelöteten BluePill. Ich habe den PORTC, PIN15 im verdacht. Da
> hängt PDN dran und die Pins C13, C14 und C15 sind bei STM schwache
> Sonderlinge.

Interessant.
Vor allem frage ich mich gerade warum PD scheinbar zappelt.

Paul B. schrieb:
> Nein, aber ein DSO mit Dekoder und Protokollfenster. Willst du was
> bestimmtes sehen?

Vorzugsweise den Reset-Event der nicht passieren sollte. :-)


Die Versorgung klingt erstmal stabil, ja.

Paul B. schrieb:
> Ist der BT81X so viel besser als der FT81X?

Ich würde nur noch BT817 benutzen.
ASTC komprimierte Bilder machen einen großen Unterschied im benötigen 
Speicherplatz, statt 16 Bit pro Pixel brauchen z.B. ASTC 8x8 Bilder nur 
2 Bit pro Pixel.
Dann ist der etwas schneller getaktet und die BT817/BT818 haben eine 
zweite PLL mit der man den Pixel-Takt viel feiner einstellen kann.
Das externe Flash ist sehr nett.
Und dann UTF-8 Zeichensätze, endlich Umlaute und Sonderzeichen einfach 
so.

Paul B. schrieb:
> Ich bin mit dem Sprung von 8 auf 32bit von Atmel weg

Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar 
nichts.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Interessant.
> Vor allem frage ich mich gerade warum PD scheinbar zappelt.

Eine gute Frage, auf dem Oszi war nichts auffällig. Und mehr als 3mA 
sollte der PDN vom FT ja nicht ziehen. Aber wie gesagt, die Pins sind 
als Sonderlinge bekannt

Rudolph R. schrieb:
> Vorzugsweise den Reset-Event der nicht passieren sollte. :-)

OK, hier:

;)

Rudolph R. schrieb:
> Ich würde nur noch BT817 benutzen.

Danke, ich werde mich mal umsehen, nur so zum spielen.

Rudolph R. schrieb:
> Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar
> nichts.

Das stimmt, konnte ja damals keiner ahnen was das rennen macht, CAN-FD 
oder Flex Ray. Da hat STM das gleich ganz weggelassen. Musste man dann 
extern machen.


Die Maschine läuft, die Touch Kalibrierung ist auch durchgelaufen und 
reagiert sauber.

Einige Fragen zum Workflow hätte ich noch.

Angenommen du willst ein ansehnliches HMI designen, nutzt du dann auch 
den EVE Screen Designer von FTDI/BT?

Wenn ich mir den aktuellen ESD 4.X ansehe, dann kann ich da meinen FT812 
gar nicht mehr anwählen. Heißt das ich muss auf den ESE, den EVE SCREEN 
EDITOR 3.3 zurückgreifen und bin damit von der neuen Version des ESD 
quasi ausgeschlossen?

Was würdest du empfehlen für das HMI design in zusammenhang mit deiner 
Lib? (semi-professionell, ich mach das als Hobby).
Hast du einen guten Workflow/Toolchain die du weiterempfehlen kannst?

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Rudolph R. schrieb:
>> Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar
>> nichts.
>
> Das stimmt, konnte ja damals keiner ahnen was das rennen macht, CAN-FD
> oder Flex Ray.

Hmm, das habe ich anders in Erinnerung. :-)
Der CAN-FD Standard war Ende 2015 fertig und da gab es FlexRay schon ein 
paar Jahre. Das Datenblatt vom TJA1080 ist zum Beispiel von 2007.
FlexRay war quasi schon tot bevor es CAN-FD gab. :-)

> Angenommen du willst ein ansehnliches HMI designen, nutzt du dann auch
> den EVE Screen Designer von FTDI/BT?

Nein, mit dem habe ich mich bisher nicht anfreunden können.

> Wenn ich mir den aktuellen ESD 4.X ansehe, dann kann ich da meinen FT812
> gar nicht mehr anwählen.

Ich habe gerade ESD 4.15.1 gestartet und konnte da ein Display mit FT812 
auswählen. Nur weiter als das komme ich spontan nicht wirklich.
Und die FT_Eve_Hal Library die da drunter liegt war mal der Grund warum 
ich meine Library angefangen habe. :-)
Wobei die heute anders aussieht, das sieht zum Teil vertrauter aus, wie 
kommt das nur? Breit grins. :-)
Ich muss da mal wieder rein schauen, aber von dem was ich spontan so 
gesehen habe möchte ich dafür meine Library nicht aufgeben.

> Heißt das ich muss auf den ESE, den EVE SCREEN
> EDITOR 3.3 zurückgreifen und bin damit von der neuen Version des ESD
> quasi ausgeschlossen?

Der Screen Editor steht bei 4.4.0.

> Was würdest du empfehlen für das HMI design in zusammenhang mit deiner
> Lib? (semi-professionell, ich mach das als Hobby).
> Hast du einen guten Workflow/Toolchain die du weiterempfehlen kannst?

Nein, ich werde neben meinem Hobby die Lib zu pflegen zwar gelegentlich 
dafür bezahlt ein Projekt mit einem Display zu machen, der Level ist 
allerdings Tools und Proto-Typing. Das heisst ich kann mich da ohne 
formale Anforderungen oder Prozesse dran austoben und es geht oft nur um 
ein einziges Exemplar.
Also der Teil der in der Entwicklung Spaß macht. :-)

Vor Weihnachten hatte ich so ein Projekt, da musste eine Komponente mit 
LIN angesteuert werden ohne offen zu legen wie man das macht.
Statt einer CANoe Simulation mit LDF dazu habe ich das in ein 5" 
"Tablett" gegossen, wobei das "Tablett" ein EVE3-50G in einem 3D 
gedrucktem Gehäuse mit einer Platine von mir ist die 2x CAN-FD und 2x 
LIN hat.
Das HMI besteht da nur aus einem Screen, so mit Firmen-Logo, ein paar 
eigene Buttons, einem Slider und Text.
Das ist vom Code her sehr dicht an meinem Beispiel-Programm und das HMI 
habe ich da entsprechend einfach so runter programmiert.
Die Kollegen waren begeistert wegen der sehr spontanten Umsetzung mit 
wenigen Tagen Vorlauf, der Kunde der damit spielen durfte war 
begeistert, weil es eben "einfach so" lief, so spontan an und ohne 
Noteboook. Und ich hatte Spaß daran das umzusetzen.

Viel Text um zu sagen das ich gar keine HMI Entwicklung in dem Sinne 
mache. :-)

Ein 10.1" habe ich schon im Büro liegen, das wartet noch auf das 
Gehäuse, das HMI dafür werde ich wohl als Skizze auf einer Serviette 
erhalten. :-)

[Paul B. (paule201)]

Eine Frage hätte ich noch zum Thema "CMD_KEYS"

Ich erstelle mir mit

        EVE_cmd_keys_burst(280,100,160,38,28,0,"789");
        EVE_cmd_keys_burst(280,140,160,38,28,0,"456");
        EVE_cmd_keys_burst(280,180,160,38,28,0,"123");
        EVE_cmd_keys_burst(280,220,160,38,28,0,"0.>");

mein Keyboard. Wie bekomme ich jetzt die Info das eine Feld gedrückt 
wurde? Beim Button muss man ja das TAG zuweisen, aber wie läut das hier?

So?

EVE_cmd_dl_burst(DL_TAG+7U);
EVE_cmd_dl_burst(DL_TAG+8U);
EVE_cmd_dl_burst(DL_TAG+9U);
EVE_cmd_keys_burst(280,100,160,38,28,0,"789");

EVE_cmd_dl_burst(DL_TAG+4U);
EVE_cmd_dl_burst(DL_TAG+5U);
EVE_cmd_dl_burst(DL_TAG+6U);
EVE_cmd_keys_burst(280,100,160,38,28,0,"456");

[Rudolph R. (rudolph)]

CMD_KEYS liefert den ASCII Wert als TAG zurück.
Das dürfte auch einer der Gründe sein warum das kein UTF-8 unterstützt.

[Paul B. (paule201)]

Rudolph R. schrieb:
> CMD_KEYS liefert den ASCII Wert als TAG zurück.
> Das dürfte auch einer der Gründe sein warum das kein UTF-8 unterstützt.

Danke für die Info, ich hab gar keine Mail bekommen das du geantwortest 
hast. Komisch. Ich habe es dann über einzelne Buttons gelöst.


Ich hab mal auf deinen Rat gehört und mir ein RVT50HQBNWC00 mit BT817 
gegönnt. Das passende #define habe ich eingebunden (EVE_RVT50H), Chip ID 
lesen klappt auch (124 dec).
Allerdings bleibt der µC in der "EVE_busy()" kleben. "space" wird immer 
mit "0" zurück gegeben. Unregelmäßig kommt auch mal "59823" zurück und 
er führt den Code aus um den CoProcessor wieder ans laufen zu bringen.

Hatte das schon mal jemand bei EVE4?

Vielen Dank!

[Rudolph R. (rudolph)]

Also so grundsätzlich habe ich mit dem RVT50HQBNWC00 soweit keinen 
Stress gehabt, aber ich habe auch keinen STM32F303 mit dem ich das 
testen könnte, der STM32 Teil ist auch ohnehin mal dran überarbeitet zu 
werden.

Ich habe hier einen Prototyp einer Platine mit STM32G0B1 hier auf das 
ich einen Display-Anschluss designed habe, bisheriger Stand ist 
allerdings noch das die LED plausibel blinkt und der externe Oscillator 
so nicht funktionieren kann.
Und am Mittwoch habe ich in Nürnberg noch ein STM32C0 Nucleo 
abgegriffen, also das ist in der Pipeline das ich was damit mache. :-)

Kannst Du das mit irgendeinem anderen Board testen und wenn es ein UNO 
ist?

[Rudolph R. (rudolph)]

Nach zähem Ringen mit den STM32 HAL Funktionen läuft die angehängte 
Software gerade auf meinem erstem eigenen STM32 Board auf dem ein 
STM32G0B1 bestückt ist und einem RVT50HQBNWC00.

Ich habe erstmal mit STM32CubeIDE ein Projekt erstellt und die 
SystemClock_Config(), MX_GPIO_Init() sowie MX_SPI1_Init() in meine 
main.c kopiert.

Und dann habe ich die MX_SPI1_Init() noch um die Konfiguration der SPI 
Pins erweitert die blöderweise nicht mit generiert wird, obwohl die Pins 
eingestellt sind.

Das nutzt jetzt noch nicht den Code aus EVE_target.c, da war ich noch 
nicht dran. Und DMA nutzt das auch nicht.

Die EVE_target_STM32.h hat noch das Problem das sich die Parameter gar 
nicht wie vorgesehen von "Außen" über Defines einstellen lassen.

An meiner EVE Library habe ich jetzt praktisch nichts geändert, in der 
EVE_target.h wird auf "STM32G0" geprüft, in der EVE_target_STM32.h auch 
noch mal.
Und in der EVE_target_STM32.h werden die HAL Includes für das Target 
gezogen.

In der speziellen main.c ist alles drin damit der Controller 
grundsätzlich läuft, so wie das eigentlich sein soll.
Was noch "fehlt" ist einen Timer zu benutzen um die Laufzeit der beiden 
Funktionen in µs zu messen.
Im Logic-Analyzer sehe ich das ein Display-Update gerade 290µs dauert.

Zum Vergleich habe ich die spi_transmit() gerade mal auf 
HAL_SPI_Transmit() umgestellt, damit dauert das exakt gleiche Display 
Update satte 2,332 ms, statt so 3xx ns zwischen den Bytes hat man mit 
HAL_SPI_Transmit() >10µs -> nicht zu empfehlen.

Für heute hatte ich damit aber erstmal genug Spaß. :-)

[Paul B. (paule201)]

Hey Rudolph,

coole Sache das du an der STM Unterstützung dran bist :).

Deine Lib hast du also quasi nicht angefasst, bis auf den G0 Teil.
Komisch, bei mir läuft es immer noch nicht. Ich habe leider kein anderes 
Board da zum testen (es mangelt am Display Anschluss).
SPI Frequenz hab ich auch schon auf unter 1 MHz runter gedreht, ohne 
Erfolg. Ich komme aus der EVE_busy nicht raus. Das Display ist neu, 
glaube kaum das das kaputt ist. Lesen der Chip ID und setzen des 
Backlights klappen problemlos.

Was schickst du in deiner EVE_Init? Auch die 0x46? Ich fand das 
Datenblatt an der Stelle etwas verwirrend.

"2 to 6 times the osc
frequency (i.e., 24 to
72MHz with 12MHz
oscillator)"

#if EVE_GEN > 2
    EVE_cmdWrite(EVE_CLKSEL, 0x46U); /* set clock to 72 MHz */
#endif

Zumal die Clock Frequenz ja kurze Zeit später noch mal ins Register 
geschrieben wird:

/* tell EVE that we changed the frequency from default to 72MHz for BT8xx */
#if EVE_GEN > 2
            EVE_memWrite32(REG_FREQUENCY, 72000000UL);
#endif

Hast du noch eine CLK_FREQ in der config.h mit hinzugefügt? Welche PCKL 
hast du eingestellt? 3?

Danke!

[Rudolph R. (rudolph)]

Paul B. schrieb:
> Deine Lib hast du also quasi nicht angefasst, bis auf den G0 Teil.

Ja, und die Änderungen sind eingecheckt, das Projekt da oben holt sich 
die Library aus Github.
Ich musst nur mal den Cache von PlatformIO löschen damit das neu geladen 
wird.

> SPI Frequenz hab ich auch schon auf unter 1 MHz runter gedreht,

Ich bin auf 8MHz aber ich habe auch meine Adapter-Platine dazwischen.

> Ich komme aus der EVE_busy nicht raus. Das Display ist neu,
> glaube kaum das das kaputt ist. Lesen der Chip ID und setzen des
> Backlights klappen problemlos.

Welchen Rückgabewert liefert EVE_busy?
Eigentlich sollte die Abfrage praktisch immer E_OK, also Null zurück 
liefern.

> Was schickst du in deiner EVE_Init? Auch die 0x46? Ich fand das
> Datenblatt an der Stelle etwas verwirrend.
>
> "2 to 6 times the osc
> frequency (i.e., 24 to
> 72MHz with 12MHz
> oscillator)"
> #if EVE_GEN > 2
>     EVE_cmdWrite(EVE_CLKSEL, 0x46U); /* set clock to 72 MHz */
> #endif

Ja, BT81x setze ich immer von den Default 60MHz auf 72MHz hoch.

> Zumal die Clock Frequenz ja kurze Zeit später noch mal ins Register
> geschrieben wird:/* tell EVE that we changed the frequency from default
> to 72MHz for BT8xx */
> #if EVE_GEN > 2
>             EVE_memWrite32(REG_FREQUENCY, 72000000UL);
> #endif

Das ist um dem Co-Processor mitzuteilen was eingestellt wurde.
Warum auch immer man das tun muss.

> Hast du noch eine CLK_FREQ in der config.h mit hinzugefügt? Welche PCKL
> hast du eingestellt? 3?

Ich habe die Konfiguration nicht verändert.
Ohne EVE_PCLK_FREQ und mit EVE_PCLK auf 3 kommt das Display mit den 
restlichen Parametern auf 59,3 Hz.
Ich hatte zuerst die Konfiguration für das EVE3_50G aktiv, damit lief 
das RVT50H auch grundsätzlich, nur sicher ohne Touch, weil ein anderer 
Touch-Controller konfiguriert wird.

[Paul B. (paule201)]

Rudolph R. schrieb:
> Welchen Rückgabewert liefert EVE_busy?

ich lese den Wert "space" immerm mit "0" zurück, obwohl es "0xffcU" sein 
sollte. Damit springt er dann in den letzten "else" Zweig und liefert:
EVE_IS_BUSY (12) zurück. Damit hänge ich in der while von 
"EVE_excute_cmd" fest:

void EVE_execute_cmd(void)
{
    while (EVE_busy() != E_OK)
    {
    }
}

Rudolph R. schrieb:
> EVE3_50G aktiv, damit lief
> das RVT50H auch grundsätzlich

Hab ich auch probiert, gleiches Ergebnis. Bei dem GEN2 Display was ich 
hier habe (NHD43) klappt das rücklesen von "space" problemlos mit 
0xffcU.

[Rudolph R. (rudolph)]

Hmm, ja, das macht soweit gerade keinen Sinn.
Wie sieht der SPI traffic zu dem EVE_busy() denn aus?

Das müsste so aussehen:
MOSI: 0x30 0x25 0x74 0x00 0x00 0x00
MISO: 0x00 0x4a 0x43 0x42 0xfc 0x0f

Da Du "nur" ein Oszi hast würde ich dazu gerne mal ein paar Bilder 
sehen.

Und wenn das in EVE_execute_cmd() hängt, was wurde dann davor 
ausgeführt?
Hängt das am Ende von EVE_init() oder später?

[Paul B. (paule201)]

Rudolph R. schrieb:
> Wie sieht der SPI traffic zu dem EVE_busy() denn aus?

Kann ich dir leider erst morgen liefern, bin noch unterwegs.


Rudolph R. schrieb:
> Und wenn das in EVE_execute_cmd() hängt, was wurde dann davor
> ausgeführt?

Nur das was in der INIT steht (hab nur den Backlight Wert angepasst, 
damit ich  überhaupt eine Reaktion sehe)


Rudolph R. schrieb:
> Hängt das am Ende von EVE_init() oder später?

Ja, genau da.

[Rudolph R. (rudolph)]

Paul B. schrieb:
>> Hängt das am Ende von EVE_init() oder später?
>
> Ja, genau da.

An der Stelle passiert aber quasi gar nichts, es gab noch kein
Co-Processor Kommando und das Programm kommt da nur an wenn alle 
Einheiten signalisieren, dass sie aus dem Reset sind.
Da steht das praktisch nur pro-forma drin, daher mache ich da auch gar 
keine Fehler-Reaktion.

Was mir noch aufgefallen war, ich habe DELAY_MS() auf HAL_Delay(ms) 
umgebogen und damit etwas zu kämpfen gehabt.
Ich hatte erst einen eigenen SysTick_Handler(), der konnte so aber nicht 
funktionieren.
Dann habe ich das mit der HAL Implementierung probiert, wo auch immer 
die vergraben ist, wollte auch nicht so recht.
Am Ende habe ich das wieder selber implementiert, aber erweitert:

void SysTick_Handler(void)
{
    system_tick = 42;
    HAL_IncTick(); /* needed for HAL_Delay() to work */
}

Das HAL_Delay() braucht HAL_IncTick().
Aus dem Grund musste ich auch meinen "Scheduler" umbauen, von den 5ms 
Ticks die ich sonst benutze auf 1ms Ticks die von HAL_Init() eingestellt 
werden.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

RamDL "mitten drin" beschreiben:
Hallo Fan-Gemeinde. Hat schon mal jemand den RamDl nicht an der 
Startadresse beginnend (30.000) beschrieben, sondern mitten drin?
Hintergrund:
Ich schreibe ein komplettes Bild mit diverser Grafik, was ja je nach 
Umfang doch immerhin beim Schreiben per SPI einige Millisekunden dauern 
kann.
Bei einer zeitkritischen Anwendung kann das stören.

Nun muss das komplette Bild aber nur (nach dem ersten Setzen) immer mit 
2 Messwerten verändert werden. Diese Werte schreibe ich ganz am Ende der 
List. Vorher zähle ich den RamDL mit und springe dann, wenn besagte 
Werte geändert werden sollen an diese Stelle und öffne eine neue List 
mit RamDl = zuletzt benutzte Adresse. Das funktioniert so weit auch 
alles richtig gut! Zur Aktualisierung dieser Werte am Bildschirm 
benötige ich nun nur noch 500µs!

Am Ende schreibe ich natürlich noch in den REG_DLSWAP die 2. Und der 
neue Wert erscheint am Bildschirm. ABER mit jedem REG_DLSWAP springt die 
Anzeige zwischen dem 1. Wert, den ich auf diese Weise geschrieben habe 
und dem neuesten hin und her. Also z.B. 1. Wert = 1, wird angezeigt. 
Dann ist der Wert = 2, Bild springt auf 2, nächster Wert ist 3 aber 
Anzeige springt auf 1. Dann kommt Wert = 4, Anzeige springt auf 4, mit 
nächster Aktualisierung wieder auf 1 ... Erhöhe ich die 
Aktualisierungsfrequenz von eben ca. 100ms auf 5ms SCHEINT es zu 
funktionieren. Da sich die Werte dann aber so extrem schnell ändern, ist 
das nicht ganz klar erkennbar.

Ähnliches Vorgehen hatte ich schon mal bei einem Stellpult mit 
Schiebereglern angewendet. Um das Schieben der Steller flüssig zu 
gestalten, habe ich die gesamte Grafik an den Beginn gesetzt und nur die 
Schieber selbst dann am Ende per Sprung in den RAMDL an zuletzt benutzte 
Position (vor Beginn des Setzens der Schieber) gesetzt. Durch das nun 
sehr schnelle Beschreiben des Bildes, bewegen sich die Schieber 
schneller.
Erst sprang das komplette Bild zwischen dem zuletzt gesetzten Bild und 
der Regler-Ansicht hin und her (natürlich extrem schnell). Erst nachdem 
ich das Bild 3 mal beim ersten Sprung in das Regler-Menü gesetzt hatte, 
funktionierte es auch mit den Schiebereglern.

Mit REG_DLSWAP = 1 hatte ich es auch schon versucht. Ändert sich nichts. 
Mit jedem REG_DLSWAP springt doch der FT813 zwischen seinen 2 
Ringspeichern hin und her und führt immer gerade einen aus, während man 
den anderen "in Ruhe" beschreiben kann. Warum scheint es so, dass in 
diesem Fall, immer nur EIN Ringspeicher beschrieben wird?

[Rudolph R. (rudolph)]

Äh, ich bin nicht sicher was da schief läuft, ich schreibe nie in die 
Display-Liste, ich lasse nur die "Coprocessor Engine" in die Liste 
schreiben.

Auf jeden Fall ist RAM_DL schon mal kein Ring-Speicher, das gilt nur für 
RAM_CMD.
Entsprechend beginnt die Liste immer bei 0x300000 und man kann nicht 
über das Ende hinaus schreiben und automatisch wieder am Anfang landen.

>und öffne eine neue List mit RamDl = zuletzt benutzte Adresse.

Der Part ist mir nicht klar, sowas geht gar nicht in dem Sinne.

Der Bereich RAM_DL ist doppelt vorhanden, die 8kiB die man gerade sehen 
kann sind der inaktive Teil.
Und mit REG_DLSWAP = 2 wird getauscht, die 8kiB die man gerade 
bearbeitet hat sind weg und aktiv, die 8kiB die eben noch für die 
Generierung des Bildes verwendet wurden sind inaktiv und erreichbar.

Also um das zu manipulieren müsste man erstmal die Liste zwei Mal 
schreiben.

Und einfach mal mit dem EVE Screen Editor hingeworfen ergibt zum 
Beispiel
CLEAR(1, 1, 1)
CMD_NUMBER(642, 353, 28, 0, 42)

Das hier:
  Raw  Text
0  0x26000007  CLEAR(1, 1, 1)
1  0x22000000  SAVE_CONTEXT()
2  0x27000002  VERTEX_FORMAT(2)
3  0x0500001c  BITMAP_HANDLE(28)
4  0x1f000001  BEGIN(BITMAPS)
5  0x06000034  CELL(52)
6  0x45040584  VERTEX2F(2568, 1412)
7  0x06000032  CELL(50)
8  0x451c0584  VERTEX2F(2616, 1412)
9  0x23000000  RESTORE_CONTEXT()
10  0x00000000  DISPLAY()

Um die angezeigt Zahl zu ändern müsste man also nur wissen wo die im 
Speicher steht und die 0x34 und 0x32 auf die passenden Werte ändern.
Dann REG_DLSWAP = 2 und man sieht es auf dem Schirm und hat die 
vorherigen Werte im Speicher.

So, jetzt stehen da noch haufenweise Kommandos vor diesem Block die sich 
nie ändern sollen.
Zum Beispiel so im Coprozessor-Format:
CLEAR(1, 1, 1)
POINT_SIZE(100)
BEGIN(POINTS)
VERTEX2F(5760, 3408)
END()
BEGIN(LINES)
VERTEX2F(6112, 5312)
VERTEX2F(7776, 4992)
VERTEX2F(9424, 2656)
VERTEX2F(3888, 5456)
END()
BEGIN(RECTS)
VERTEX2F(10032, 1904)
VERTEX2F(10736, 3600)
VERTEX2F(9088, 4560)
END()
CMD_NUMBER(642, 353, 28, 0, 42)

Dazu lasse mir vom Coprocessor eine Display-Liste erzeugen ab 
POINT_SIZE() bis vor CMD_NUMBER(), kopiere die per CMD_MEMCPY aus RAM_DL 
nach RAM_G und dann lasse ich den Coprocessor dieses Fragment beim 
Generieren der nächsten Display-Liste per CMD_APPEND mit in die neue 
Liste kopieren.

CLEAR(1, 1, 1)
CMD_APPEND(0x12345, 42)
CMD_NUMBER(642, 353, 28, 0, 42)

Das ist in meinem Beispiel-Programm drin, siehe initStaticBackground().
Ich nutze das nicht so aggressiv, da für den Transfer ohnehin meistens 
DMA verwende und ich das Update "nur" alle 20ms machen lasse (darf auch 
nicht zu schnell sein, sonst flackert das).

Der Vorteil ist, dass ich gar nicht wissen muss wo irgendwas in RAM_DL 
landet und trotzdem nicht immer alles neu schicken muss.

https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

Der komische Stern (bzw. natürlich die Kommandos den aus dem Speicher 
anzuzeigen), der Button und die Messwerte werden immer geschickt, der 
Rest nicht.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Sorry, aber mit dem Co_Prozessor komme ich (immer) noch nicht klar. 
Meine eigene Software auf meine Art hat sich seit Jahren bewährt...:):).
Ich öffne die SPI schreibe die Startadresse Hx300000 (natürlich sendet 
man HxB00000 für "Schreiben"). Dann sende ich Befehl für Befehl jeweils 
4 Byte (32 Bit). Die Daten werden automatisch jeweils in die 
nachfolgende Speicherzelle des RamDL geschrieben. Am Ende der 
Befehlsliste wird CS wieder auf High gezogen, um anschl. sofort wieder 
auf Low zu ziehen, um das Register REG_DLSWAP mit 2 zu beschreiben...
OK, ob nun Ringspeicher oder nicht. Richtig, soweit ist mir das auch 
klar, dass es den RamDL 2 x gibt und jeweils mit REG_DLSWAP getauscht 
wird und das ich den natürlich nicht "überschreiben" darf (also über 8kB 
hinaus).

Nach dem Öffnen (SPI) und der Staradresse 30.0000 zähle ich nun jeden 
Befehl mit. Nach 2000 Befehlen wurde also der letzte Befehl in den 
Speicher Hx30.0000 + (Dx2000 x 4), also in 301F3C bis 301F3F 
geschrieben. Also muss Befehl 2001 in den Speicher 301F40 rein, was ja 
nun automatisch passieren würde! Hier startet nun das Setzen meiner zu 
aktualisierenden Werte Messwerte. Setze ich also das gesamte Bild, fahre 
ich hier weiter fort. Wenn ich NUR die Werte aktualisieren möchte ohne 
den ganzen Bildschirm dabei neu schreiben zu müssen, Öffne ich die SPI 
und beginne mit dem Schreiben der Adresse Hx301F40 und den folgenden 
restlichen Befehlen (die Werte auf den Bildschirm bringen), endend mit 
REG_DLSWAP = 2. Das meine ich mit "und öffne eine neue List mit RamDl = 
zuletzt benutzte Adresse".
Warum aber wird nun einer der beiden Speicher nicht überschrieben, 
obwohl ich doch jedes mal mit REG_DLSWAP tausche???

[Rudolph R. (rudolph)]

Bernd I. schrieb:
> Warum aber wird nun einer der beiden Speicher nicht überschrieben,
> obwohl ich doch jedes mal mit REG_DLSWAP tausche???

Mal davon ab, dass in Deiner Beschreibung immer noch fehlt, dass Du die 
Display-Liste initial zwei Mal komplett beschreibst, was Du vermutlich 
aber getan hast, ich sehe gerade keinen Grund, warum das so nicht 
funktionieren sollte.

Das mag zwar umständlich sein, aber durchaus zulässig.

Hmm, ich muss das mal ausprobieren. :-)

[Rudolph R. (rudolph)]

Ich habe das gerade ausprobiert, das Ergebnis hängt an.
Hier läuft gerade von einem Arduino UNO aus ein Punkt über den 
Bildschirm.

Ich schreibe zwei Mal die gleiche Display-Liste:

EVE_memWrite32(EVE_RAM_DL, DL_CLEAR_COLOR_RGB);
EVE_memWrite32(EVE_RAM_DL + 4U, (DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG));
EVE_memWrite32(EVE_RAM_DL + 8U, VERTEX_FORMAT(0U));
EVE_memWrite32(EVE_RAM_DL + 12U, DL_COLOR_RGB + 0xff00ff);
EVE_memWrite32(EVE_RAM_DL + 16U, POINT_SIZE(300U));
EVE_memWrite32(EVE_RAM_DL + 20U, DL_BEGIN + EVE_POINTS);
EVE_memWrite32(EVE_RAM_DL + 24U, VERTEX2F(100, 100));
EVE_memWrite32(EVE_RAM_DL + 28U, DL_DISPLAY);
EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

Und dann schreibe ich alle 20ms die Koordinaten für den Punkt neu:

EVE_memWrite32(EVE_RAM_DL + 24U, VERTEX2F(xc, yc));
EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);

Da ist jetzt nicht ein CoProcessor Kommando drin und das läuft einfach.
Sicher, das Beispiel ist etwas wenig komplex, aber so grundsätzlich tut 
das halt was es soll.

Edit: mir ist gerade noch aufgefallen, das schreibt jedes Kommando für 
sich und nicht nur einmal die Adresse.
Das sollte keinen Unterschied machen, ist nur langsamer.

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Klar scheibe ich das Display zunächst 2 mal, bevor man dann das eine 
Detail am Ende aktualisieren kann. Das Beispiel mit den 2000 Befehlen 
(mal 4 Byte = 8k) war auch unüberlegt. Dann wären wir ja schon über den 
erlaubten 8k. Also nehmen wir mal an, es sind nur 500 Befehle...
Aber ich sehe, Du hast das Prinzip, worum es mir geht, richtig 
verstanden. Und ich verstehe ebenso wie Du nicht, warum das so 
merkwürdig funktioniert.

In Deiner List schreibst Du in Adresse 28 vor dem DL_SWAP noch den 
DL_DISPLAY, wie es sich gehört. So weit , so gut. Aber wenn Du dann die 
Koordinaten des Punktes in Adresse 24 aktualisierst, führst Du anschl. 
NUR den DL_SWAP aus, ohne das DL_DISPLAY davor. Muss ich nachher gleich 
mal ausprobieren, ob sich dadurch etwas ändert!!!

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Hallo Rudi,
Du hast ja soooo Recht!!! Natürlich gibt es keinen vernünftigen Grund, 
warum es nicht funktionieren sollte! Es sei denn...
Ich schreibe die List und setze schon mal den RamDL auf HxB0 00 00. Dann 
zähle ich den RamDL mit jedem Befehl (mal 4) und komme also am 
entscheiden Punkt, wo ich später mal hinspringe, um NUR die letzten 
Daten am Bildschirm zu ändern, wo ich den Wert des RamDL speichere. Für 
die Aktualisierung der letzten Daten öffne ich dann also eine neue List 
und starte die mit RamDL, wie eben gemerkt. Nun hatte ich den blöden 
Fehler gemacht und hier noch einmal Hx80 00 00 dazu addiert, also bei 
JEDEM Sprung Dadurch war bei jeder Aktualisierung das erste Bit 
("Schreiben") mal Low und dann wieder High... So kommt der Wechsel zu 
Stande. Was soll man dazu sagen - Passiert ...

Das ganze ist aber (wenn man es also richtig anstellt) eine sehr gute 
Möglichkeit, einen Bildschirm teilweise zu beschreiben unter 
Beibehaltung aller möglichen Grafiken und kann somit wertvolle Zeit 
sparen, wenn es darauf ankommt. Vielleicht konnte ja jemand mit diesen 
Beiträgen etwas für sich daraus entnehmen ...!
Liebe Grüße, Bernd

[Rudolph R. (rudolph)]

Prima, dass das geklärt ist und der Fehler ist interessant kreativ.
Sowas hätte ich im Logic-Analyzer Trace gesehen. :-)

Ich bin nur bei der Schlussfolgerung nicht ganz bei Dir. :-)

Ein
EVE_cmd_number(100, 200, 28, EVE_OPT_RIGHTX, irgendeinezahl);
ist doch erheblich leichter im Code zu pflegen, rechnet selber aus 
welche Glyphen wo stehen müssen, passt die Anzahl der Stellen 
automatisch an und braucht immer nur 4 32 Bit Worte auf dem SPI.
Oh ja, negative Zahlen und 1-9 Stellen mit führenden Nullen gehen auch.
In Verbindung mit CMD_SETBASE kann man das auch binär, octal und 
hexadezimal ausgeben lassen.

Du hast ja Recht, dass das Update weniger Zeit braucht, dem gegenüber 
steht aber der vielfach höhere Aufwand das umzusetzen und zu pflegen und 
dann darf man die Liste ohnehin nicht häufiger wechseln als die Bildrate 
ist, das bedeutet man hat bei 60Hz mal eben 16,666ms Zeit zwischen zwei 
Aktualisierungen.
Und bei einer vollständigen Aktualisierung, etwa wenn man eine ganz 
andere Bildschirmseite anzeigen möchte, dann muss erheblich mehr über 
den SPI geschickt werden wenn direkt eine Display-Liste geschrieben 
wird, als wenn man das den Kommando Co-Prozessor machen lässt.

Wobei man das ja kombinieren kann, man könnte ja ein Stück Display-Liste 
in den Speicher schreiben und per CMD_APPEND in die Liste einfügen 
lassen.
Dann könnte man den Speicher manipulieren und neu einfügen lassen.
Keine Ahnnug, drei Kreise mit unterschiedlichen Farben für eine Ampel.
Statt das im Speicher zu manipulieren könnte man aber auch so viele 
Varianten anlegen wie man benötigt und jeweils die passende einfügen 
lassen - wenn sich der Aufwand überhaupt lohnt.

[Luky S. (luky)]

Ich habe mit der Bibliothek und einem Riverdi RVT43HLBN (BT817) 
rumexperimentiert, aber ich Frage mich immer noch, was der beste Weg 
ist, ein bildschirmfüllendes Hintergrundbild auf das Display zu 
bekommen. Muss nicht schnell sein, wird nur einmal geladen, aber mit 
welchem Tool konvertiere ich es und in welchem Format? Ist die 4k 
Begrenzung immer noch ein Thema oder inzwischen gefixt?

[Rudolph R. (rudolph)]

Luky S. schrieb:
> Ich habe mit der Bibliothek und einem Riverdi RVT43HLBN (BT817)
> rumexperimentiert,

So eines habe ich noch nicht.

> aber ich Frage mich immer noch, was der beste Weg
> ist, ein bildschirmfüllendes Hintergrundbild auf das Display zu
> bekommen. Muss nicht schnell sein, wird nur einmal geladen, aber mit
> welchem Tool konvertiere ich es und in welchem Format?

Mit dem EVE Asset Builder: https://brtchip.com/toolchains/

Für die BT81x kann ich nur ASTC empfehlen, ASTC 8x8 braucht vor allem 
nur 2 Bit pro Pixel bei voller Farbtiefe mit Alpha.
Das hier könnte hilfreich sein:
https://github.com/RudolphRiedel/FT800-FT813/discussions/83

Wobei es da vor allem darum ging ein Bild direkt aus dem Flash 
anzuzeigen.

> Ist die 4k Begrenzung immer noch ein Thema oder inzwischen gefixt?

Das ist schon lange gefixt, so irgendwann in V4, das betraf ja nur mal 
cmd_inflate und cmd_loadimage.

Für direktes Schreiben hätte ich noch EVE_memWrite_sram_buffer() und 
EVE_memWrite_flash_buffer() anzubieten, wobei die sich nur auf AVR 
Controllern wirklich unterscheiden.

[Luky S. (luky)]

Danke, das Beispielprogramm hat mir schon weitergeholfen, ich habe aber 
glaube ich noch ein grundsätzliches Verständnisproblem mit dem EVEx 
System:
Wie bekomme ich die Bilder ins Flash? Damit ist ja der direkt am BT817 
per QSPI angebundene NOR Flash gemeint, oder?

Ich habe leider nur eine Ansteuerplatine mit einem ATmega328 ohne 
zusätzlichen Speicher drauf.

[Rudolph R. (rudolph)]

Also "normalerweise" soll man das Flash-Image das EAB erzeugt auch mit 
EAB in das NOR-Flash vom Display schreiben, dazu braucht man einen 
USB/SPI Adapter.
https://www.matrixorbital.com/ftdi-eve/eve-bt817-bt818/eve-usb2spi-kit-b
https://www.matrixorbital.com/ftdi-eve/eve-bt815-bt816/eve2-usb2spi-kit-a
https://riverdi.com/blog/hermes-board-spi-usb-bridge-board-2/

Hmm, die Produkt-Seite für das Hermes Board ist nicht mehr da.
Und das "eve-usb2spi-kit-b" würde ich ja gerne kaufen, ich wüsste aber 
nicht wo.
Das "eve-usb2spi-kit-a" gibt es bei DigiKey und Mouser.

Meine Beispiele haben aber auch Code wie man das aus dem Controller 
heraus macht, siehe TFT_init() in tft.c.

Nur braucht man dafür den Speicher im Controller und ein M328 ist dafür 
doch etwas sehr knapp dran.
Wenn das Programm nichts anderes machen soll als Flash Daten zu 
schreiben, dann kommt man mit unter 4kiB für das Programm aus, dann 
bleiben 27kiB für die Daten.
Das Flash wird in 4kiB Happen beschrieben, also 24kiB.
Man könnte ein Flash-Image mit EAB erzeugen, mit irgendeinem Tool in 
24kiB Häppchen teilen, mit EAB die Binär-Happen in ein C-Array umwandeln 
und per extra Programm mit EVE_memWrite_flash_buffer() in RAM_G 
schreiben um dann per EVE_cmd_flashupdate() das RAM_G in das Flash zu 
schreiben.
Sobald der allererste 4kiB Block mit dem "Blob" geschrieben ist kann man 
per EVE_init_flash() den Modus auf "fast" stellen lassen.

Etwas nervig, aber durchführbar.

Wenn man einen dickeren Controller hätte wie einen ESP32 oder Teensy4, 
dann wäre bei der Methode das RAM_G der begrenzende Faktor, das ist halt 
"nur" 1MiB.
Dann müsste man das entweder in Etappen schreiben, oder aber 
EVE_cmd_flashwrite() benutzen.
Das erfordert aber auch, dass das Flash leer ist, also ein 
EVE_cmd_flasherase() braucht man dann auch noch.

In tft.c benutze ich EVE_cmd_inflate() um das Flash-Image vom Controller 
in RAM_G zu entpacken, das macht deshalb Sinn, weil in meinem 
Flash-Image ein UTF-8 Font drin ist und die sind auch in ASTC Format 
noch mal hoch komprimierbar, das könnte an den leeren Glyphen liegen.
Oder generell daran, dass Zeichen mehr Nichts als Pixel sind.

[Luky S. (luky)]

Direkt per USB-SPI Bridge aufs Display laden klingt für mich nach einer 
sinnvollen Variante. Der Eve Asset Builder scheint dafür aber ncith das 
richtige Tool zu sein, der erstellt "nur" passende Dateien in einem 
Ausgabeverzeichnis.
Riverdi macht leider auf mich einen nicht wirklich vertrauenserweckenden 
Eindruck. Das Zeug funktioniert so halb, Dokumentation ist mies bzw. 
unvollständig, eine Menge Links führen ins Nichts, der Support ist 
...langsam.

[Rudolph R. (rudolph)]

Im Reiter "Flash Utilities" gibt es 4 Tabs, Flash Image Generator, Flash 
Programmer, Flash Diagnostic und Sample Code.

Das Hermes Board ist inzwischen etwas älter, vielleicht haben die auch 
was neues in der Pipeline.

Richtige Probleme hatte ich mit deren Dokumentation auch nie, was daran 
soll jetzt bitte mies sein?

Ich finde höchstens, dass das Marketing auf der Homepage etwas neben der 
Spur ist.
"Revolutionary communication protocol"? I2C.
"2x Pixel Mode"? Existiert wie beschrieben nicht.

Aber das sind die ersten EVE4 Displays die man tatsächlich auch hier in 
Europa kaufen kann.
Und IPS, Optical Bonding und Hell gefällt mir ganz gut.
Ich würde gerne auch welche von Matrix Orbital kaufen, nur müsste ich 
die direkt bei denen in Kanada ordern, das ist mir dann doch zu krass 
was den Versand angeht.

[Luky S. (luky)]

Welches Interface verwendest du um die "Blobs" auf das Display zu 
bekommen?
Ich finde, das Riverdi eine Menge Marketing-BlaBla auf der Homepage hat, 
aber kaum harte technische Daten und ich glaube dass ich nicht der 
einzige bin, der sich mit den Tools und dem -wie ich finde- etwas 
merkwürdingen Workflow, nicht wirklich zurechtgefunden hat. "Getting 
Started" oder sowas fehlt mir einfach.

[Rudolph R. (rudolph)]

Ich habe ein eve2-usb2spi-kit-a und ein Hermes Board von Riverdi, ich 
benutze aber auch schon mal den Controller um Daten zu kopieren.
Wobei ich hauptsächlich ATSAME51 mit 512k Flash verwende.

Das hier ist die Produkseite von dem RVT43HLBNWC00:
https://riverdi.com/product/eve4-intelligent-display-rvt43hlbnwc00-4-3-inch-projected-capacitive-touch-panel-air-bonding-uxtouch/

Da gibt es das Datenblatt, eine Zeichnung, die Step-Datei, einen Reiter 
"Description" und einen Reiter "Additional Information".
Und es gibt einen Link auf ein "Getting Started":
https://riverdi.com/support/eve4-getting-started/

Das wird unten sogar zum Download als .pdf angeboten.

Was fehlt Dir da denn jetzt noch?

Die Beispiele sind für Riverdis Library: https://github.com/riverdi

Die Library ist soweit ich weiß dicht an dem was FTDI damals zuerst 
veröffentlich hatte und was man immer noch als Output vom EVE Screen 
Designer bekommt.

Das einzige was Riverdi jetzt nicht veröffentlich sind komplette 
Schaltpläne.

Was die Tools angeht, die kommen ja nicht von Riverdi, die sind von 
Bridgetek, früher mal von FTDI.
Die Chips sind ja auch nicht von Riverdi.

Das Repository von Bridgetek ist übrigens hier:
https://github.com/BRTSG-FOSS

Hilfreich ist dann noch der Programming Guide:
https://brtchip.com/wp-content/uploads/2022/12/BRT_AN_033_BT81X-Series-Programming-Guide.pdf

[Torsten (xpuipc)]

Hi Rudolph,

also ich habe jetzt dieses Display: 
https://www.displaymodule.com/products/3-4-480-x-480-transmissive-tft-lcd-rgb?_pos=8&_fid=10ae58c14&_ss=c

Es hat 480x480 sichtbare Pixel und dieses Timing für 60 Hz (die Werte in 
Klammern verstehe ich als soll:

DCLK frequency FCLK              -- (20) -- MHz
Horizontal Sync. Width hpw         (8)  Clock
Horizontal Sync. Back Porch hbp    (56) Clock
Horizontal Sync. Front Porch hfp   (20) Clock
Vertical Sync. Width vs            (10) Line
Vertical Sync. Back Porch vbp      (60) Line
Vertical Sync. Front Porch vfp     (40) Line

Nun die 1000 Dollar Frage....wie komme ich denn nun zu den Werten für 
den EVE, egal was ich "ausprobiere" ich bekomme kein stabiles Bild. Ich 
komme da nicht weiter.

Anbei mein "Code" geht speziell um die H und V Sync Werte...
#if defined (EVE_EVE4_ISFD_3dot4_Inch)
#define Resolution_480x480

#define EVE_HSIZE  (480L)              // THD; Visible horizontal 
resolution (in PCLKs)
#define EVE_VSIZE  (480L)                 // TVD; Visible vertical 
resolution (in lines)
//  Horizonttal
#define EVE_HSYNC0  (8L)                //  THF; Horizontal Front Porch 
(in PCLK cycles)
#define EVE_HSYNC1  (8L + 8L)              //  THF + THP; Horizontal 
Front Porch plus Hsync Pulse width (in PCLK cycles)
#define EVE_HCYCLE   (EVE_HSIZE + EVE_HSYNC0 + EVE_HSYNC1)    //  TH; 
Total length of line (visible and non-visible) (in PCLKs)
#define EVE_HOFFSET  (8L + 8L + 20L)            //  THF + THP + THB; 
Length of non-visible part of line. Must be < TH - THD (in PCLK cycles)

//  Vertical
#define EVE_VCYCLE  (EVE_VSIZE + 8 + 8 + 2 + 2)      //   TV; Total 
number of lines (visible and non-visible) (in lines)
#define EVE_VSYNC0  (40L)                //  TVF; Vertical Front Porch 
(in lines)
#define EVE_VSYNC1  (40L + 10L)              //  TVF + TVP; Vertical 
Front Porch plus Vsync Pulse width (in lines)
#define EVE_VOFFSET  (40L + 10L + 2)            //  TVF + TVP + TVB; 
Number of non-visible lines. Must be < TV - TVD (in lines)


#define EVE_PCLK  (1L)
#define EVE_PCLKPOL  (0L)                //(1L)
#define EVE_SWIZZLE  (0L)
#define EVE_CSPREAD  (0L)
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_DITHER  (0L)
#define EVE_GEN 4
#define EVE_HAS_CRYSTAL
//#define EVE_PCLK_FREQ  (14500000L)    /* 14.5MHz => 54 Hz value for 
EVE_cmd_pclkfreq */
#define EVE_PCLK_FREQ  (16250000L)    /* 16.25 MHz => 60.5 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (27000000L)    /* 27 MHz => 100 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (22000000L)    /* 22 MHz => 81.75 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (21500000L)    /* 21.5 MHz => 79.5 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (21000000L)    /* 21 MHz => 78.0 Hz value for 
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (19000000L)    /* 19 MHz => 70.5 Hz value for 
EVE_cmd_pclkfreq */

Grüße und vielen Dank
Torsten

[Rudolph R. (rudolph)]

Moin,

das Gefummel ist genau der Grund warum ich die Idee aufgegeben habe 
irgendwelche Displays verwenden zu wollen. :-)
Normalerweise sind die Timing-Daten unvollständig und dann könnn sich 
die Hersteller nicht mal darauf einigen wie sie ihre Parameter benennen.

EVE_PCLK_FREQ benutze ich inzwischen anders, aber um nur ein Bild zu 
haben würde ich erstmal nur den normalen Takt benutzen.

Probier mal das hier:

#if defined(EVE_EVE4_ISFD_3dot4_Inch)
#define EVE_HSIZE (480L)
#define EVE_VSIZE (480L)

#define EVE_VSYNC0 (40L)
#define EVE_VSYNC1 (50L)
#define EVE_VOFFSET (110L)
#define EVE_VCYCLE (592L)
#define EVE_HSYNC0 (20L)
#define EVE_HSYNC1 (28L)
#define EVE_HOFFSET (84L)
#define EVE_HCYCLE (566L)
#define EVE_PCLK (4L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 4
#endif

Das ist natürlich auch nur aufgrund der Daten wild geraten.

Bei dem Display bin ich aber nicht sicher ob man nicht auch den SPI da 
dran braucht um den ST7701S zu konfigurieren.
Das sieht auf jeden Fall schwer danach aus, Pins 9, 10, 11 und 12.

Ich habe dann noch gerade das hier gefunden:
https://github.com/moononournation/Arduino_GFX
Das unterstützt wohl generell solche Displays, also mit ST7701S und 
480x480.
Da sind acht "Types" definiert, vom Timing her passt keiner so 100%.
Such mal nach ST7701 in dem Code, da gibt es zum Beispiel 
st7701_type1_init_operations - das sieht aus als wäre da ein ganzer 
Haufen Daten definiert die per SPI geschrieben werden.

[Torsten (xpuipc)]

Super, Danke!...

Ja für den St7701 braucht man wohl ne Ini Sequenz...die schicke ich per 
SPI an den ST7701s (ich habe zwie getrennte SPI, einen für EVE und einen 
eben für den Controller...
Ich habe allerdings keine Ahnung, ob man das überhaupt machen 
muss...also Reset und "Wecken" ist klar...ggf. Stimmen ja die 
Defaultwerte...oder der Hersteller des Displays hat das ja ggf. Schon 
"vorkonfektioniert"...

Normalen Takt, meinst Du über den "Teiler" aus der Tabelle? Wie benutzt 
Du den PCLK_FREQ jetzt? Ich hatte auch den Eindruck das da was nicht 
stimmt...

Grüße und nochmal Danke

Torsten

[Rudolph R. (rudolph)]

Ja, ob man den ST7701 betüddeln muss - keine Ahnung, sowas hatte ich 
noch nicht und das fände ich auch schwer lästig.

Torsten schrieb:
> Normalen Takt, meinst Du über den "Teiler" aus der Tabelle? Wie benutzt
> Du den PCLK_FREQ jetzt? Ich hatte auch den Eindruck das da was nicht
> stimmt...

Na, ohne die zweite PLL.
Mit EVE_PCLK = 4 ergeben sich 18MHz, das sollte erstmal laufen, falls 
denn der Rest der Parameter passt.
EVE_PCLK_FREQ setze ich wenn benötigt jetzt auf einen vorberechneten 
Wert wie er auch in der Tabelle zu finden ist, wenn das definiert ist 
wird REG_PCLK direkt auf 1 gesetzt.
20MHz gibt es in der Tabelle nicht, das müsste 0x8A3 sein.

[Torsten (xpuipc)]

Okay...werde ich ausprobieren und berichten...

Grüße
Torsten

[Torsten (xpuipc)]

Okay,

man muss nur die richtige Init Sequenz für den ST7701 haben dann geht es 
auch, ist natürlich problematisch, wenn der Hersteller des Displays sie 
erstmal auch nicht hat und mir ca. 10 Stück zur Auswahl schickt und 
keine davon geht. Habe dann Sitronic direkt angeschrieben...die sind 
sehr schweigsam dazu...haben aber versucht zu helfen. Da gibt es einen 
undokumentierten Registerbereich...ist wahrscheinlich nur für Hersteller 
gedacht...
Für ggf. hier anderen ST7701 Nutzer. Entscheidend scheinen die sog. GIP 
Werte zu sein, das Timing scheint gar nicht so kritisch zu sein.
Irgendwann nach erneutem Nachfragen hat er mir dann eine aktualisierte 
Sequenz geschickt, ist jetzt auch auf der Webseite...das Display ist 
wirklich hell, crisp, weiter Sichtwinkel und gut.
Ich habe die Werte die Du vorgeschlagen hast genommen...jetzt geht es 
wunderbar mit 70 Hz Wiederholrate mit 20Mhz Pixelclock...

Grüße und Danke

Torsten

[Rudolph R. (rudolph)]

Vor ein Tagen ist mir das hier aufgefallen:
https://github.com/MatrixOrbital/EVE-Library/blob/main/src/eve/ST7789V.c

Wobei ich weiterhin froh bin, dass mir sowas noch nicht untergekommen 
ist. :-)

[Torsten (xpuipc)]

Rudolph R. schrieb:
> Vor ein Tagen ist mir das hier aufgefallen:
> https://github.com/MatrixOrbital/EVE-Library/blob/main/src/eve/ST7789V.c
>
> Wobei ich weiterhin froh bin, dass mir sowas noch nicht untergekommen
> ist. :-)

Genau so...ich mache das auch mit SPI BitBanging für die 
Initialisierung, da kann man dann jedes SPI Format erzeugen 8 Bit, 9Bit 
und xBit wenn notwendig.
Hier kommt es ja nicht auf Geschwindigkeit an, muss man ja nur einmal 
zum Start machen...

Grüße

[Bernhard B. (berni444)]

Hallo,

ich bin froh hier eine, sogar deutsch sprachige, Community gefunden zu 
haben, die sich mit dem BT8XX beschäftigt.
Ich hab momentan ein Problem und ich denke für euch ist das keines es zu 
lösen.

Zur Hardware:
Riverdi 7" mit EVE4 + eigenes PIC Board.

Ich hab bereits ein großes flash file mit dem EAB erstellt und 
erfolgreich in den externen flash auf dem Riverdi Board geschrieben. 
Erfolgreich deshalb, weil es kein Problem ist eins der darin 
gespeicherten Bilder anzeigen zu lassen. Das funktioniert mit jedem Bild 
soweit gut.
Mein Problem ist nun, dass ich es nicht schaffe mehr als drei Bilder 
gleichzeitig anzeigen zu lassen. Der RAM_G sollte ja eigentlich 1024k 
haben, Meine Bilder im flash haben zusammen über 6000k (es sind aber 
einige hundert). Ich möchte nun einen großen Teil des Displays mit 
Bilder füllen. leider funktioniert das nur bis einer RAM_G Adresse um 
die 50000 und nicht bis 1024000.

Leider verwende ich nicht die Bibliothek von Rudolph, sondern eine 
angepasste von BRT, aber ich denke das Verhalten ist ähnlich.

Hier mein Code:

    Gpu_Hal_WaitCmdfifo_empty(phost);

    Gpu_CoCmd_FlashFast(phost, 0);
    Gpu_CoCmd_Dlstart(phost);

    App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(0));
    Gpu_CoCmd_FlashRead(phost, 0, 5955008, 2240);
    Gpu_CoCmd_SetBitmap(phost, 0, COMPRESSED_RGBA_ASTC_5x5_KHR, 100, 
35);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(400*16, 0));
    App_WrCoCmd_Buffer(phost, END());

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(1));
    Gpu_CoCmd_FlashRead(phost, 2300, 5693888, 46080);
    Gpu_CoCmd_SetBitmap(phost, 2300, COMPRESSED_RGBA_ASTC_5x5_KHR, 180, 
400);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(0, 0));
    App_WrCoCmd_Buffer(phost, END());

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(2));
    Gpu_CoCmd_FlashRead(phost, 49000, 5959488, 1472);
    Gpu_CoCmd_SetBitmap(phost, 49000, COMPRESSED_RGBA_ASTC_5x5_KHR, 65, 
35);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(250*16, 1000));
    App_WrCoCmd_Buffer(phost, END());

Bis hier funktioniert es mit drei Bilder, wird der untere Teil mit 
eingebunden bleibt das Display schwarz oder die Bilder sind zerschossen.

    App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(2));
    Gpu_CoCmd_FlashRead(phost, 51000, 5959488, 1472);
    Gpu_CoCmd_SetBitmap(phost, 51000, COMPRESSED_RGBA_ASTC_5x5_KHR, 65, 
35);
    App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
    App_WrCoCmd_Buffer(phost, VERTEX2F(250*16, 1000));
    App_WrCoCmd_Buffer(phost, END());

Danach kommt noch das:

    App_WrCoCmd_Buffer(&host, DISPLAY());
    //swap the current display list with the new display list
    Gpu_CoCmd_Swap(&host);
    App_Flush_Co_Buffer(&host);
    Gpu_Hal_WaitCmdfifo_empty(&host);


    /* Close all the opened handles */
    App_Common_Close(&host);

Zuerst dachte ich der RAM_G reicht nicht aus aber laut ESE passen die 
Bilder rein.

Ich hoffe Ihr könnt mir dabei helfen.

Viele Grüßen,
Bernhard

[Walter L. (charly2)]

Hallo,

nach einigem Suchen, denke ich, dass ich hier richtig bin.

Ich habe hier seit gefühlten 100 Jahren ein

FT811CB von THAOYU

liegen, das ich jetzt mal in Betrieb nehmen möchte.

Hat jemand einen "Starter-C-code" oder eine Tipp, woher man ihn bekommen 
kann, damit die ersten Schritte schon mal erledigt sind.

Hat jemand einen  Tipp, woher man Infos über das Teil bekommen kann.


Danke für sachdienliche Hinweise und

VG Walter


P.S.:
IC ist der FT5206.
Auf GitHaub habe ich etwas in C++ gefunden, für mich nicht so schön.
Es geht nicht um  die SPI, die habe ich im Griff....

[Rudolph R. (rudolph)]

Moin,

was in dem Post etwas schwer zu finden war, jetzt so in dem Code 
"versteckt" ohne Code Tags, ist was denn überhaupt passiert.

>Gpu_CoCmd_FlashRead(phost, 51000, 5959488, 1472);

Probier mal die ganzen Gpu_CoCmd_FlashRead() da raus zu ziehen.
Die werden ja nur einmal gebraucht und sicher nicht in die Display-Liste 
eingebaut.
Und das BITMAP_HANDLE wird so auch nicht benötigt, auch wenn das nicht 
direkt falsch ist.
Das BITMAP_HANDLE ist ein Set Einstellungen zum Speichern und wieder 
verwenden, wenn man die Bilder nur einmal anzeigen will kann man das 
auch weg lassen, dann wird durch jedes neue SetBitmap das Default 
Bitmap-Handle verändert.

Gpu_CoCmd_FlashFast(phost, 0);
Gpu_CoCmd_FlashRead(phost, 0, 5955008, 2240);
...

Wobei da noch die Frage ist, was die Funktionen überhaupt machen.
Also ob die Rückgabewerte haben, ob gewartet wird und so.

Gpu_Hal_WaitCmdfifo_empty(phost);
Gpu_CoCmd_Dlstart(phost);
App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
Gpu_CoCmd_SetBitmap(phost, 0, COMPRESSED_RGBA_ASTC_5x5_KHR, 100, 35);
App_WrCoCmd_Buffer(phost, VERTEX2F(400*16, 0));
Gpu_CoCmd_SetBitmap(phost, 2300, COMPRESSED_RGBA_ASTC_5x5_KHR, 180,400);
App_WrCoCmd_Buffer(phost, VERTEX2F(0, 0));
...
App_WrCoCmd_Buffer(phost, END());
...

Boah, das ist die Library wegen der ich meine Library angefangen habe. 
:-)

Und ich weiß ja, dass ich keinen PIC Support in meiner Library habe,
den einzubauen sollte aber eher kein Problem sein.
Ich habe nur keine einzige Platine mit PIC drauf und ich müsste zum 
Programmieren MPLAB-X verwenden.
Und MPLAB-X ist einer der Gründe warum ich nicht mal in Erwägung ziehe 
irgendwelche PICs zu verwenden, vor allem nachdem was Microchip mit den 
ATSAM getrieben hat.

[Bernhard B. (berni444)]

Hallo Rudolph,

vielen Dank für deine Antwort. Ich hab nun deine Bibliothek auch ans 
laufen bekommen. Leider stoße ich nun nur etwas später an die Grenze. 
Jetzt funktionieren zumindest schon 7 Bilder je ca. 240x180px.

Ich lade nach dem initialisieren alle Bilder in das RAM_G, danach werden 
die Bilder aufgerufen. Momentan nur einmal beim initialisieren. Ich 
versuche die 7" mit mehreren kleineren Bilder zu füllen.

Hier der Code:

  // Switch Flash to FULL Mode 
  EVE_init_flash();                         // also does a flash_attach() !  
  
    EVE_cmd_flashread( EVE_RAM_G, 4288, 29184 ); 
    EVE_cmd_flashread( (EVE_RAM_G+29184), 33472, 28416 ); 
    EVE_cmd_flashread( (EVE_RAM_G+57600), 61888, 28416 ); 
    EVE_cmd_flashread( (EVE_RAM_G+86016), 90304, 27456 ); 
    EVE_cmd_flashread( (EVE_RAM_G+113472), 117760, 25600 ); 
    EVE_cmd_flashread( (EVE_RAM_G+139072), 143360, 24832 ); 
    EVE_cmd_flashread( (EVE_RAM_G+163904), 168192, 27264 ); 
//    EVE_cmd_flashread( (EVE_RAM_G+191168), 195456, 31488 ); 

  // *** begin of the display list *********************************************
  
  EVE_cmd_dl( CMD_DLSTART );                // start a new display-list
  EVE_cmd_dl( CLEAR( 1, 1, 1 ) );               // clear the display
  
  // *** displays an image loaded from Flash ***********************************
  // Bild1
  EVE_cmd_setbitmap( EVE_RAM_G, COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 190 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 0, 0 ) );
  // Bild2
  EVE_cmd_setbitmap( (EVE_RAM_G+29184), COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 185 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 4180, 0 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+57600), COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 185 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 0, 4180 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+86016), COMPRESSED_RGBA_ASTC_5x5_KHR, 245, 175 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 4180, 4180 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+113472), COMPRESSED_RGBA_ASTC_5x5_KHR, 235, 170 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 8180, 0 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+139072), COMPRESSED_RGBA_ASTC_5x5_KHR, 235, 165 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 8180, 4180 ) );
    
  EVE_cmd_setbitmap( (EVE_RAM_G+163904), COMPRESSED_RGBA_ASTC_5x5_KHR, 230, 185 );
  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
  EVE_cmd_dl( VERTEX2F( 12180, 4180 ) );
//    
//  EVE_cmd_setbitmap( (EVE_RAM_G+191168), COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 205 );
//  EVE_cmd_dl( BEGIN(EVE_BITMAPS) );
//  EVE_cmd_dl( VERTEX2F( 12180, 0 ) );
  // *** displays an image loaded from Flash ***********************************
  
  // *** end of the display list ***********************************************
  EVE_cmd_dl( END() );
  EVE_cmd_dl( DISPLAY() );
  EVE_cmd_dl( CMD_SWAP );                   // tell EVE to use the new display list
//  EVE_execute_cmd();

7 Bilder gehen noch beim 8. bleibt das Display schwarz.
Außerdem bleibt die Funktion EVE_execute_cmd(); hängen, darum ist sieh 
hier auskommentiert. Leider hab ich noch nicht verstanden, was diese 
genau macht.

[Rudolph R. (rudolph)]

Walter L. schrieb:
> Hat jemand einen "Starter-C-code" oder eine Tipp, woher man ihn bekommen
> kann, damit die ersten Schritte schon mal erledigt sind.

Schau mal in meine Library, da sind auch Beispiele dabei,
die Frage wäre nur für welchen Controller und ob Arduino oder nicht.

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

Walter L. schrieb:
> IC ist der FT5206.

Das ist "nur" der Touch-Controller, der Grafik-Chip selber ist ein 
FT811.
Die Dokumentation ist hier:
https://brtchip.com/documents-type/data-sheets/

[Rudolph R. (rudolph)]

Bernhard B. schrieb:
> Ich hab nun deine Bibliothek auch ans laufen bekommen.

Tendenziell hätte ich ja schon Interesse an dem PIC Code um
den für andere zu integrieren. :-)

Ansonsten fällt mir gerade nichts auf das nicht funktionieren sollte.
Es gibt schon noch andere Limits wie die 4kiB im RAM_CMD und die 8kiB in 
der Display-Liste, davon ist das bisschen Code aber sicher noch ganz 
weit weg.

Bernhard B. schrieb:
> Außerdem bleibt die Funktion EVE_execute_cmd(); hängen, darum ist sieh
> hier auskommentiert. Leider hab ich noch nicht verstanden, was diese
> genau macht.

Die wartet eigentlich nur darauf das alle Kommandos im RAM_CMD 
abgearbeitet sind, das sollte so nicht hängen bleiben können.

Lies ein paar ms nach dem CMD_SWAP mal das RAM_ERR_REPORT aus,
siehe Kapitel "5.7 Coprocessor Faults" im Programming Guide.
Vielleicht steckt der Fehler auch in den Bildern.

Anderes Experiment, lad doch mal die ersten paar Bilder die 
funktionieren mehrmals in RAM_G.

Ich hole gleich mal mein RVT70HSBNWC00-B raus und probiere das aus,
das schwierigste dabei wird sein Bilder zu finden, zu konvertieren und 
in das Flash zu brennen.

[Walter L. (charly2)]

Hallo Rudolph,

danke für die INFOs; mit denen komme ich wohl zurecht.

>die Frage wäre nur für welchen Controller und ob Arduino oder nicht

TMSP320F28069 oder MSP430FRxxx.

VG Walter

[Bernhard B. (berni444)]

Hallo Rudolph,

Danke für deine Unterstützung.

Momentan sieht es so aus, dass der CAN Bootloader vom PIC schuld daran 
ist und das mit den Bildern nur eine falsche Fährte war. Scheinbar 
überschreitet das Programm eine gewisse Größe und überschreibt damit die 
Checksumme oder sorgt dafür, dass die Berechnung nicht mehr richtig 
funktioniert. Beim einfügen mehrerer Bilder trat dass dann auf und 
führte dazu, dass der Bootloader die Anwendung garnicht erst startet 
(das war mir die ganze zeit nicht aufgefallen). Mit der Zeile 
EVE_execute_cmd() verhielt es sich scheinbar genauso.

Zum PIC Code, ich möchte die Anwendung noch optimieren und testen, 
außerdem hab ich noch Bilder verwendet, die nicht mir gehören. Das 
möchte ich noch geradeziehen, dann kann ich dir das gerne zuschicken.

Gruß,
Bernhard

[Rudolph R. (rudolph)]

Walter L. schrieb:
>>die Frage wäre nur für welchen Controller und ob Arduino oder nicht
>
> TMSP320F28069 oder MSP430FRxxx.

Jetzt gehts los. :-)
Ist heute Tag der Controller Challenge? :-)

https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_TMS320C28XX.h
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_MSP432.h

Die beiden sind ja vorhanden, wobei ich bei beiden nicht sicher bin wie 
gut die funktionieren, weil ich beide Controller noch nicht auf dem 
Tisch hatte.

Aber da kann man bestimmt drauf aufbauen, die Peripherie sollte ja 
ähnlich sein.
Und wenn man eine neue EVE_target...h macht, dann muss man die noch in 
der EVE_target.h eintragen.

Der TMS320 war seltsam, kennt beine Bytes und ich meine der SPI kann 
auch kein DMA, DMA wäre wohl möglich gewesen mit einem UART im SPI Mode, 
oder so ähnlich, ist eine Weile her das ich mir das angesehen habe.

[Rudolph R. (rudolph)]

Bernhard B. schrieb:
> Momentan sieht es so aus, dass der CAN Bootloader vom PIC schuld daran
> ist und das mit den Bildern nur eine falsche Fährte war. Scheinbar
> überschreitet das Programm eine gewisse Größe und überschreibt damit die
> Checksumme oder sorgt dafür, dass die Berechnung nicht mehr richtig
> funktioniert.

Das muss dann aber schon sehr knapp am Limit sein, die paar Zeilen
kosten doch erstmal nicht viel.

Bernhard B. schrieb:
> Zum PIC Code, ich möchte die Anwendung noch optimieren und testen,
> außerdem hab ich noch Bilder verwendet, die nicht mir gehören. Das
> möchte ich noch geradeziehen, dann kann ich dir das gerne zuschicken.

Klingt gut, wobei ich die Bilder ja eher nicht brauche. :-)

Mein 7" läuft gerade, jetzt mal ein paar Pixel für einen Test aus dem 
Netz fischen. :-)

[Rudolph R. (rudolph)]

Bernhard B. schrieb:
> EVE_cmd_setbitmap( EVE_RAM_G, COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 190 );

Detail am Rande, welche Version ist das?
Ich musste gerade nachschauen, im Dezember 2022 habe ich das auf
EVE_ASTC_5X5 geändert.

[Rudolph R. (rudolph)]

So, ich habe einen Satz Bilder auf 240xwhatever konvertiert, die auf 
ASTC 5x5 konvertiert, ein Flash-Image erstellt, das ins Flash gebrannt.
Wobei ich noch ein Downgrade auf EAB 2.8 machen musste, der EAB 2.9 ist 
ganz schön kaputt.

Jetzt kopiere ich gerade beim Start 12 Stück davon in RAM_G und lasse 50 
Mal pro Sekunde eine Diplay-Liste erstellen die per DMA über den SPI 
geschoben wird.
So zusätzlich in dem Code meines einfachen Beispiel-Codes.

In dem ATSAME51 der an meinem RVT70HSBNWC00-B hängt sind
das insgesamt 20068 Bytes Programm-Speicher, wobei 3597 Bytes für die 
beiden Bilder in dem Beispiel-Code sind.
Das Projekt verwendet keinen Bootloader.

Im Ergebnis sind das 480 Bytes die per Display-Update über den SPI 
verschickt werden und das ergibt eine Display-Liste von 1360 Bytes.

Da ginge noch viel mehr, aber die 1024x600 sind schon gut mit Pixeln 
gefüllt.

#define SPACE22 0UL
#define SPACE01 20736UL
#define SPACE02 41472UL
#define SPACE03 66048UL
#define SPACE04 86784UL
#define SPACE05 111360UL
#define SPACE06 135936UL
#define SPACE07 158976UL
#define SPACE08 179712UL
#define SPACE09 203520UL
#define SPACE10 228096UL
#define SPACE11 262656UL

if (E_OK == EVE_init_flash())
{
    EVE_cmd_flashread(SPACE22, 4096, 20736);
    EVE_cmd_flashread(SPACE01, 24832, 20736);
    EVE_cmd_flashread(SPACE02, 45568, 24576);
    EVE_cmd_flashread(SPACE03, 70144, 20736);
    EVE_cmd_flashread(SPACE04, 90880, 24576);
    EVE_cmd_flashread(SPACE05, 115456, 24576);
    EVE_cmd_flashread(SPACE06, 140032, 23040);
    EVE_cmd_flashread(SPACE07, 163072, 20736);
    EVE_cmd_flashread(SPACE08, 183808, 23808);
    EVE_cmd_flashread(SPACE09, 207616, 24576);
    EVE_cmd_flashread(SPACE10, 232192, 34560);
    EVE_cmd_flashread(SPACE11, 266752, 24576);
}

Tendenziell bevorzuge ich ASTC 8x8, das ist noch mal deutlich kleiner 
und von der Qualität auch noch recht gut.
Bei der Pixel-Dichte von fast 7 RGB Pixel pro mm fallen 
Komressions-Artefakte auch gar nicht so leicht auf.

Oh ja, und ich verwende den aktuellen Stand meiner Library, also nicht 
den Release 5.0.6 vom Mai, den ganz aktuellen Stand.

[Walter L. (charly2)]

Hallo,

ich möchte nochmal rückfragen.

Oben im Bild bei P1 (PINs nicht bezeichnet) liegt der FT5206, ein cap. 
touch controller.
Auf der Rückseite des PCB liegt der FT811 (hab ich kontrolliert).
Der FT811 kann auch cap. touch.

Beide IC's können also cap. touch.

Frage: Warum 2 cap. touch IC's?

Die PIN-Belegung des P1 ist offensichtlich (habe durchgekligelt) vom 
quad. PIN aus gezählt

1  5V,

2  5V,

3   SSEL/SCL PIN22 vom FT5206,

4   MOSI/SDA PIN24 vom FT5206,

5   WAKE PIN27 vom FT5206,

6   INT PIN28 vom FT5206,

7   weiß nicht, geht wahrscheinlich auf die BASIS/GATE eines 
Transistors.


Frage: Kennt jemand die Bedeutung (was macht man damit)?

Frage: Benutzt jemand das Display (nur Display, oder Display und cap. 
Touch)?

Danke für Antworten.

VG Walter

[Rudolph R. (rudolph)]

Der FT811 benutzt den FT5206 als Touch-Sensor per I2C.
Die FT8xx / BT8xx kümmern sich auch um den Touch, man kann zwar auch die 
Koordinaten raus lesen, am einfachsten ist allerdings einem Objekt per 
TAG eine Nummer zuzuweisen und die Touch-Events auszulesen.
Gibt man etwa einem Button die Nummer 10, dann steht im Register 
REG_TOUCH_TAG die 10 wenn man den Button auf dem Bildschirm berührt.
Man muss also nicht selber nachrechnen ob Touch Koordinaten vielleicht 
zu einem Objekt auf dem Bildschirm gehören könnten.
Man kann sogar einer ganzen Gruppe von Objekten einen TAG zuordnen, etwa 
wenn man sich eigene Buttons erstellt mit einem Bild und darüber 
liegendem Text.

FT810, FT812, BT816 und BT818 sind für Resistiv-Touch.
FT811, FT813, BT815 und BT817 sind für Kapazitiv-Touch.

Resistiv-Touch ist als passive Matrix ausgelegt und braucht vier Analaog 
Anschlüsse.
Kapazitiv-Touch braucht eine ganze Menge Anschlüsse und von daher 
dürften die meisten Panels mit integriertem Rasterizer für 
Kapazitiv-Touch den Sensor gleich integriert haben, normalerweise als 
Schaltung auf dem Folien-Leiter.

[Walter L. (charly2)]

Rudolph, danke.

Kommt wohl ne Menge Arbeit....

VG Walter

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

Bescheidene Frage:
Ein simples Symbol mit homogen (weis) Hintergrund soll dargestellt 
werden (siehe Anhang, Beispiel). Dieses Weis des Bildes ist ja quasi der 
Bereich, wo eben nichts ist.
Definiere ich VOR dem Platzieren des Bildes eine Farbe, erscheint das 
Zahnrad mit dem Hintergrund dieser Farbe. Habe ich einen homogenen 
Bildschirm und ich möchte, dass man NUR das Zahnrad sieht und nicht ein 
(farbiges) Rechteck mit Zahnrad darin, so definiere ich zuvor die 
Hintergrundfarbe des Bildschirms und setzte dann das Bitmap. Zahnrad 
erscheint als reines Zahnrad. So weit so gut. Nun habe ich aber einen 
nicht homogenen Hintergrund (z.B. mit CMD_GRADIENT ... einen 
Farbverlauf). Da geht das sooo ja nicht. Warum (oder wie kann man) 
diesen Hintergrund des Bitmap undurchlässig machen, so dass der 
Farbverlauf an dieser Stelle des Bitmap erhalten bleibt und auch hier 
NJUR das Zahnrad zu sehen ist? Geht das?

[Rudolph R. (rudolph)]

Das Bild hat zwar ARGB1555 im Namen, das hat aber dem Alpha-Channel 
überhaupt nicht gesetzt und ist somit auch nicht transparent.

Ok, die Foren-Software vermurkst die Bilder auch gerne mal durch eine 
automatische Konvertierung.
Ich habe Dein Bild gerade mit Paint.net kurz bearbeitet und einen Teil 
transparent gemacht, das Ergebnis ist in dem .zip damit die 
Foren-Software da nicht direkt ran kommt.

Und dann habe ich beide Bilder in den EVE Screen Editor gezogen.
Beide im Format ARGB1555
Dazu noch ein Gradient.

CLEAR(1, 1, 1)

CMD_GRADIENT(158, 109, 0xFF0000, 215, 264, 0x0000FF)

BITMAP_HANDLE(0)
CMD_SETBITMAP(0, ARGB1555, 120, 120)
BEGIN(BITMAPS)
VERTEX2F(3680, 1424)
END()
BITMAP_HANDLE(1)
CMD_SETBITMAP(28800, ARGB1555, 120, 120)
BEGIN(BITMAPS)
VERTEX2F(1840, 3280)
END()

[Bernd I. (Firma: Ickert-Elektronik) (bernd2201)]

so ist es. Es war auch nur ein Beispiel-Bild (vom Kunden vorgegeben). 
Aber Du hast Recht, man kann das Problem nicht mit dem Grafik-Treiber 
lösen, sondern nur mit dem Bild selbst. Habe mal ein paar eigene Bilder 
entworfen, wo ich gleich von vornherein auf Paint den Hintergrund als 
transparent gesetzt habe. Funktioniert einwandfrei. Sorry - hatte mich 
noch nie tiefer mit Paint & Co. beschäftigt, außer den Zeichenbereich zu 
verändern, um die Kunden-Bilder entsprechend anzupassen ... Also vielen 
Dank für die Hilfe.