Forum: Projekte & Code FT800 / FT810 Library


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Rudolph (Gast)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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.

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

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?

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Karol (Gast)


Lesenswert?

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

von Karol B. (karol_b135)


Lesenswert?

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

When i use yours example:
1
#define IMG1_ADR  0
2
while(ft800_busy() == 1);
3
ft800_cmd_loadimage(IMG1_ADR, FT_OPT_NODL, jpg4, 2640);
4
ft800_cmd_execute();
5
//then in loop:
6
ft800_cmd_dl(DL_BEGIN | FT_BITMAPS);
7
ft800_cmd_dl(BITMAP_SOURCE(IMG1_ADR));//ft800_cmd_dl(BITMAP_SOURCE(MEM_P 
8
IC1));
9
ft800_cmd_dl(BITMAP_LAYOUT(FT_RGB565,96*2,96));
10
ft800_cmd_dl(BITMAP_SIZE(FT_NEAREST,FT_BORDER,FT_BORDER,96,96));
11
ft800_cmd_dl(VERTEX2II(FT_HSIZE-96-10,FT_VSIZE-96-10,0,0));
12
//ft800_cmd_dl(VERTEX2F((10)*16,30*16));
works fine, but when I try to use
1
ft800_cmd_inflate(RAM_IMAGES_LOGO_2, IMAGES_LOGO_ASUZU_2, sizeof(IMAGES_LOGO_2));
 and the same metod
for display it, it doesn't work at all.

Sometimes, only ft800_cmd_inflate(...) crashed.

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

Regards
Karol

von Rudolph R. (rudolph)


Lesenswert?

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

von Karol B. (karol_b135)


Lesenswert?

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?

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

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.

von Karol B. (karol_b135)


Lesenswert?

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

von Markus S. (Firma: LRP AG) (mastr64)


Lesenswert?

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

von Rudolph (Gast)


Lesenswert?

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.

von Markus S. (Firma: LRP AG) (mastr64)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

Meine Beispiele haben alle den gleichen Code unten drunter.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_Arduino_PlatformIO/src/tft.c
1
void touch_calibrate(void)
2
{
3
/* send pre-recorded touch calibration values, depending on the display the code is compiled for */
4
5
#if defined (EVE_CFAF240400C1_030SC)
6
  EVE_memWrite32(REG_TOUCH_TRANSFORM_A, 0x0000ed11);
7
  EVE_memWrite32(REG_TOUCH_TRANSFORM_B, 0x00001139);
8
  EVE_memWrite32(REG_TOUCH_TRANSFORM_C, 0xfff76809);
9
  EVE_memWrite32(REG_TOUCH_TRANSFORM_D, 0x00000000);
10
  EVE_memWrite32(REG_TOUCH_TRANSFORM_E, 0x00010690);
11
  EVE_memWrite32(REG_TOUCH_TRANSFORM_F, 0xfffadf2e);
12
#endif
13
....
14
15
/* activate this if you are using a module for the first time or if you need to re-calibrate it */
16
/* write down the numbers on the screen and either place them in one of the pre-defined blocks above or make a new block */
17
#if 0
18
  /* calibrate touch and displays values to screen */
19
  EVE_cmd_dl(CMD_DLSTART);
20
  EVE_cmd_dl(DL_CLEAR_RGB | BLACK);
21
...

Das wird am Anfang von TFT_init() aufgerufen.

von Markus S. (Firma: LRP AG) (mastr64)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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?

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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.

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

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.

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

: Bearbeitet durch User
von Alf S. (alfsch)


Lesenswert?

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

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

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

von Alf S. (alfsch)


Lesenswert?

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 !

von Rudolph R. (rudolph)


Lesenswert?

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

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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

von Alf S. (alfsch)


Lesenswert?

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

mit dem Projekt, in der STM32cubeIDE mit HAL lib, ohne jegliche 
Optimierung oder DMA , dauert ein Bild zu übertragen ca. 500us ; daher 
habe ich vorerst den Aufwand mit der DMA sein lassen, weil das die 
CPU-Last natürlich verrringern würde. aber der zu erwartende Gewinn von 
ca. 5% auf 2% runter zu kommen -- keine wirkliche Bedeutung hat.
hier die HAL Aufrufe:
1
 void spi_transmit(uint8_t data)
2
{
3
  HAL_SPI_Transmit(&hspi5, &data, 1 , 5);
4
}
5
6
uint8_t spi_receive(uint8_t data)
7
{
8
  uint8_t  dain;
9
  HAL_SPI_TransmitReceive(&hspi5, &data, &dain, 1 , 5);
10
  return (dain);
11
}
12
13
14
// die Definition für das 7" TFT ist diese:
15
16
#define EVE_EVE2_70G                // neu für :  NHD-7.0-800x480FT-CTXL-T, EVE2
17
#define EVE_HAS_CRYSTAL            // TFT hat 12 MHz extern
18
19
/* Matrix Orbital EVE2 modules EVE2-50G, EVE2-70G : 800x480 5.0" and 7.0" capacitive touch, FT813 */
20
/* Crystalfonts CFAF800480E0-050SC 800x480 5.0" , FT813 capacitive touch */
21
// NewHaven NHD-7.0-800480FT-CSXV-T
22
#if defined (EVE_EVE2_50G) || defined (EVE_EVE2_70G) || defined (EVE_CFAF800480E0_050SC)
23
#define Resolution_800x480
24
#define EVE_PCLK  (2L)
25
#define EVE_PCLKPOL  (1L)
26
#define EVE_SWIZZLE  (0L)
27
#define EVE_CSPREAD  (0L)
28
#define EVE_TOUCH_RZTHRESH (4800L)
29
#define EVE_GEN 2
30
//#define EVE_HAS_GT911  /* special treatment required for out-of-spec touch-controller */
31
#endif

von Rudolph (Gast)


Lesenswert?

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.

von Alf S. (alfsch)


Angehängte Dateien:

Lesenswert?

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)

von Rudolph (Gast)


Lesenswert?

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.
1
static inline void spi_transmit(uint8_t data)
2
{
3
  LL_SPI_TransmitData8(EVE_SPI, data);
4
  while(!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {};
5
  while(!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {};
6
  LL_SPI_ReceiveData8(EVE_SPI); /* dummy read-access to clear SPI_SR_RXWNE */
7
}
8
9
static inline uint8_t spi_receive(uint8_t data)
10
{
11
  LL_SPI_TransmitData8(EVE_SPI, data);
12
  while(!LL_SPI_IsActiveFlag_TXP(EVE_SPI)) {};
13
  while(!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {};
14
  return LL_SPI_ReceiveData8(EVE_SPI);
15
}

von Alf S. (alfsch)


Lesenswert?

die "ohne viel Nachdenken" Version mit HAL lib: CS setzen..
1
 void EVE_cs_set(void)
2
{
3
  HAL_GPIO_WritePin(GPIOF, GPIO_PIN_6, RESET);                  // set lo manually set chip-select to low */
4
}
5
6
void EVE_cs_clear(void)
7
{
8
  HAL_GPIO_WritePin(GPIOF, GPIO_PIN_6, SET);                  // set hi manually set chip-select to high */
9
}

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

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

: Bearbeitet durch User
von Rudolph (Gast)


Lesenswert?

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:
1
static inline void spi_transmit_burst(uint32_t data)
2
{
3
#if defined (EVE_DMA)
4
EVE_dma_buffer[EVE_dma_buffer_index++] = data;
5
#else
6
spi_transmit_32(data);
7
#endif
8
}

Dieser Puffer wird mit EVE_start_dma_transfer() verschickt.

Die könnte auch so aussehen:
1
 void EVE_start_dma_transfer(uint8_t data)
2
{
3
  EVE_cs_set();
4
  HAL_SPI_Transmit(&hspi5, ((uint8_t *) &EVE_dma_buffer[0])+1, (((EVE_dma_buffer_index)*4)-1) , 5);
5
  EVE_cs_clear();
6
}

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:
1
#if defined (EVE_DMA)
2
extern uint32_t EVE_dma_buffer[1025];
3
extern volatile uint16_t EVE_dma_buffer_index;
4
extern volatile uint8_t EVE_dma_busy;
5
6
void EVE_init_dma(void);
7
void EVE_start_dma_transfer(void);
8
#endif

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

von Alf S. (alfsch)


Lesenswert?

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 ?

von Rudolph R. (rudolph)


Lesenswert?

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.

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Angehängte Dateien:

Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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.

von Holger H. (sachma)


Angehängte Dateien:

Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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

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

So far I have these:
1
enum
2
{
3
    E_OK = 0,
4
    E_NOT_OK,
5
    EVE_FAIL_CHIPID_TIMEOUT,
6
    EVE_FAIL_RESET_TIMEOUT,
7
    EVE_FAIL_PCLK_FREQ,
8
    EVE_FAIL_FLASH_STATUS_INIT,
9
    EVE_FAIL_FLASH_STATUS_DETACHED,
10
    EVE_FAIL_FLASHFAST_NOT_SUPPORTED,
11
    EVE_FAIL_FLASHFAST_NO_HEADER_DETECTED,
12
    EVE_FAIL_FLASHFAST_SECTOR0_FAILED,
13
    EVE_FAIL_FLASHFAST_BLOB_MISMATCH,
14
    EVE_FAIL_FLASHFAST_SPEED_TEST
15
};

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Angehängte Dateien:

Lesenswert?

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
1
  for (uint16_t i = 0; i < sizeof(fontData24_L8); i++)
2
  {
3
    EVE_memWrite8(FONT_FILE_ADDRESS + i, fontData24_L8[i]);
4
  }
wobei FONT_FILE_ADDRESS = RAMG+1000 ist und
fontData24_L8[i] => das Array
dann das hier:
1
   void SetCustomFont(uint32_t fontHandle, uint32_t firstChar)
2
    {
3
        EVE_cmd_setfont2_burst(fontHandle, FONT_FILE_ADDRESS, firstChar);
4
    }
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

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

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.

von Spyy (Gast)


Angehängte Dateien:

Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Rudolph (Gast)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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)
1
/***********************************************************************/
2
/* Panel Name : HSD4.0IPS(HSD040BPN1-A00)                                   
3
/* Resulation : 480x480                                                       
4
/* Inversion  : 2dot                                                          
5
/* Porch      : vbp=15 , vfp=12                                               
6
/* Line Time  : 32us                                                          
7
/* Frame Rate : 60hz                                                          
8
/************************************************************************/
2. Eingestellt (und geht) habe ich das hier:
1
#define Resolution_480x480
2
#define EVE_HSIZE  (480L)
3
#define EVE_VSIZE  (480L)   
4
5
#define EVE_VSYNC0  (8L)        
6
#define EVE_VSYNC1  (8L + 8L)      
7
#define EVE_VOFFSET  (8 + 8 + 2)      
8
#define EVE_VCYCLE  (EVE_VSIZE + 8 + 8 + 2 + 2)  
9
#define EVE_HSYNC0  (8L)        
10
#define EVE_HSYNC1  (8L + 8L)      
11
#define EVE_HOFFSET  (8L + 8L + 20L)      
12
#define EVE_HCYCLE   (EVE_HSIZE + 8 + 8 + 20 + 2)    
13
#define EVE_PCLK  (1L)
14
#define EVE_PCLKPOL  (0L)                
15
#define EVE_SWIZZLE  (0L)                
16
#define EVE_CSPREAD  (0L)                
17
#define EVE_TOUCH_RZTHRESH (1800L)
18
#define EVE_DITHER  (0L)
19
#define EVE_GEN 4
20
#define EVE_HAS_CRYSTAL
21
//#define EVE_PCLK_FREQ (14500000L)  /* 14.5MHz => 54 Hz value for EVE_cmd_pclkfreq */
22
//#define EVE_PCLK_FREQ (27000000L)  /* 27MHz => 100 Hz value for EVE_cmd_pclkfreq */
23
#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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Alf S. (alfsch)


Lesenswert?

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

Einstellung (auch mit Werten von riverdi /git driver ) war nicht 
korrekt, einige wundersame einzelne Pixel im Bild und eine blaue Linie 
rechts am Rand;
 so sieht das Bild fehlerfrei aus:
1
/* RVT70xQBxxxxx 800x480 7.0" Riverdi, various options, BT815/BT816 */
2
#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
3
#define EVE_HSIZE  (800L)  /* Thd Length of visible part of line (in PCLKs) - display width */
4
#define EVE_VSIZE  (480L)  /* Tvd Number of visible lines (in lines) - display height */
5
6
#define EVE_VSYNC0  (4L)  /*  0  Tvf Vertical Front Porch */
7
#define EVE_VSYNC1  (8L)  /* 13  10 Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
8
#define EVE_VOFFSET (13L)  /* 23 Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
9
#define EVE_VCYCLE  (512L)  /* 525 Tv Total number of lines (visible and non-visible) (in lines) */
10
#define EVE_HSYNC0  (0L)  /* 0 Thf Horizontal Front Porch */
11
#define EVE_HSYNC1  (4L)  /* 10 Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
12
#define EVE_HOFFSET (28L)  /*46  Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
13
#define EVE_HCYCLE (856L) //  (1056L)  /* Th Total length of line (visible and non-visible) (in PCLKs) */
14
#define EVE_PCLK  (2L)  /* 72MHz / REG_PCLK = PCLK frequency 30 MHz */
15
#define EVE_PCLKPOL (1L)  /* 1L PCLK polarity (0 = rising edge, 1 = falling edge) */
16
#define EVE_SWIZZLE (0L)  /* Defines the arrangement of the RGB pins of the FT800 */
17
#define EVE_CSPREAD  (0L)  // 1L muss definitiv 0 sein !
18
#define EVE_TOUCH_RZTHRESH (1800L)  /* touch-sensitivity */
19
#define EVE_HAS_CRYSTAL
20
#define EVE_GEN 3
21
#endif

von Rudolph (Gast)


Lesenswert?

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:
1
#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
2
#define Resolution_800x480
3
4
#define EVE_PCLK (2L)
5
#define EVE_PCLKPOL (1L)
6
#define EVE_SWIZZLE (0L)
7
#define EVE_CSPREAD (0L)
8
#define EVE_HAS_CRYSTAL
9
#define EVE_GEN 3
10
#endif

von Spyy (Gast)


Lesenswert?

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

von Rudolph (Gast)


Lesenswert?

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.

von Alf S. (alfsch)


Lesenswert?

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

von Alf S. (alfsch)


Angehängte Dateien:

Lesenswert?

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

von Rudolph (Gast)


Lesenswert?

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

von Alf S. (alfsch)


Angehängte Dateien:

Lesenswert?

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

von Rudolph (Gast)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Alf S. (alfsch)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Alf S. (alfsch)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Alf S. (alfsch)


Angehängte Dateien:

Lesenswert?

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)

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

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

von Alf S. (alfsch)


Lesenswert?

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

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

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

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

von Rudolph R. (rudolph)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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

von Alf S. (alfsch)



Lesenswert?

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

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

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.

von Alf S. (alfsch)


Lesenswert?

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.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Spyy (Gast)


Angehängte Dateien:

Lesenswert?

Anbei, als Bilder...

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Spyy (Gast)


Angehängte Dateien:

Lesenswert?

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"...:(

von Daniel S. (snipod)


Angehängte Dateien:

Lesenswert?

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?

von Rudolph R. (rudolph)


Lesenswert?

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.

von Rudolph R. (rudolph)


Angehängte Dateien:

Lesenswert?

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

von Daniel S. (snipod)


Lesenswert?

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

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

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?

von Spyy (Gast)


Lesenswert?

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

von Rudolph (Gast)


Lesenswert?

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

von Daniel S. (snipod)


Lesenswert?

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

: Bearbeitet durch User
von Daniel S. (snipod)


Lesenswert?

Folgendes hab ich probiert (ohne Erfolg):

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

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

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

Gibts was womit man langen text hiden kann? Ich hänge mal meinen code 
für den Button an, vielleicht fällt jemandem etwas auf
1
EVE_cmd_dl_burst(VERTEX_FORMAT(0));
2
    EVE_cmd_dl_burst(DL_COLOR_RGB | COLOR_RGB(255, 255, 255));
3
    EVE_cmd_dl_burst(COLOR_A(0));
4
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
5
    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
6
7
    // draw outline
8
    // outline radius = _br
9
    // draw the outline with alpha = 0 to set stencil
10
    EVE_cmd_dl_burst(LINE_WIDTH(_br * 16));
11
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
12
    EVE_cmd_dl_burst(VERTEX2F(_x + _br, _y + _br));
13
    EVE_cmd_dl_burst(VERTEX2F(_x + _w - _br, _y + _h - _br));
14
    EVE_cmd_dl_burst(DL_END);
15
16
    // fill the stencil area with the gradient
17
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
18
    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
19
    GradientHelper::Gradient(_x, _y, _w, _h, 0x131314, 0x202428, 0.1405, 0.8529, 318.21, true);
20
    // reset the stencil
21
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
22
23
    // calculate size of the inner area
24
    _brInner = _br - 4;
25
    _xInner = _x + 4;
26
    _yInner = _y + 4;
27
    _wInner = _w - 8;
28
    _hInner = _h - 8;
29
30
    // set scissor rectangle for inner area
31
    EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));
32
    EVE_cmd_dl_burst(SCISSOR_SIZE(_wInner, _hInner));
33
    // draw inner area
34
    // draw the inner area with alpha = 0 to set stencil
35
    EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
36
    EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
37
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
38
    EVE_cmd_dl_burst(VERTEX2F(_xInner + _brInner, _yInner + _brInner));
39
    EVE_cmd_dl_burst(VERTEX2F(_xInner + _wInner - _brInner, _yInner + _hInner - _brInner));
40
    EVE_cmd_dl_burst(DL_END);
41
42
    // fill the stencil area with the gradient
43
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
44
    EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
45
    GradientHelper::Gradient(_x, _y, _w, _h, 0x151618, 0x34393F, -0.05, 1.0, 331, true);
46
47
    // reset stencil and stencil function
48
    EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
49
    EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
50
    // Up part is pressed
51
    if (Up)
52
    {
53
        uint16_t xPart = _x + 4;
54
        uint16_t yPart = _y + 4;
55
        uint16_t wPart = _w - 8;
56
        uint16_t hPart = (_h / 2) - 4;
57
        // set scissors to upper part of control
58
        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner));
59
        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));
60
        // setup the stencil for the upper area
61
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
62
        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
63
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
64
        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart + _brInner));
65
        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart + _brInner));
66
        EVE_cmd_dl_burst(DL_END);
67
68
        // fill the stencil area with the gradient
69
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
70
        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
71
        GradientHelper::Gradient(_x, _y, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);
72
73
        // reset stencil and stencil function
74
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
75
        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
76
    }
77
78
    // Down part is pressed
79
    if (Down)
80
    {
81
        uint16_t xPart = _x + 4;
82
        uint16_t yPart = _y + (_h / 2);
83
        uint16_t wPart = _w - 8;
84
        uint16_t hPart = (_h / 2) - 4;
85
        // set scissors to upper part of control
86
        EVE_cmd_dl_burst(SCISSOR_XY(_xInner, _yInner + (_h / 2) - 4));
87
        EVE_cmd_dl_burst(SCISSOR_SIZE(wPart, hPart));
88
        // setup the stencil for the upper area
89
        EVE_cmd_dl_burst(STENCIL_OP(EVE_INCR, EVE_INCR));
90
        EVE_cmd_dl_burst(LINE_WIDTH(_brInner * 16));
91
        EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
92
        EVE_cmd_dl_burst(VERTEX2F(xPart + _brInner, yPart - _brInner));
93
        EVE_cmd_dl_burst(VERTEX2F(xPart + wPart - _brInner, yPart + hPart - _brInner));
94
        EVE_cmd_dl_burst(DL_END);
95
96
        // fill the stencil area with the gradient
97
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_EQUAL, 1, 255));
98
        EVE_cmd_dl_burst(STENCIL_OP(EVE_KEEP, EVE_KEEP));
99
        GradientHelper::Gradient(_x, _y + _h / 2, _w, _h / 2, 0x151618, 0x34393F, -0.0234, 1.3314, 83.02);
100
101
        // reset stencil and stencil function
102
        EVE_cmd_dl_burst(STENCIL_FUNC(EVE_ALWAYS, 1, 255));
103
        EVE_cmd_dl_burst(DL_CLEAR | CLR_STN);
104
    }
105
    // draw the center line
106
    EVE_cmd_dl_burst(SCISSOR_XY(_x + 4, _y + (_h / 2) - 2));
107
    EVE_cmd_dl_burst(SCISSOR_SIZE(72, 4));
108
    EVE_cmd_gradient_burst(_x + 5, _y + 86, 0x202428, _x + 76, _y + 74, 0x151618);
109
110
    // scissor rectangle for indicator
111
    EVE_cmd_dl_burst(SCISSOR_XY(_x, _y - 14));
112
    EVE_cmd_dl_burst(SCISSOR_SIZE(_w, 10));
113
    EVE_cmd_dl_burst(COLOR_A(255));
114
    // draw the activity indicator
115
    if (Up || Down)
116
    {
117
        // draw the border
118
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x202020);
119
120
        EVE_cmd_dl_burst(LINE_WIDTH(2 * 16));
121
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
122
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
123
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
124
        EVE_cmd_dl_burst(DL_END);
125
        // draw the indicator line
126
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xC02825);
127
        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
128
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
129
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
130
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
131
        EVE_cmd_dl_burst(DL_END);
132
133
        EVE_cmd_dl_burst(COLOR_A(255));
134
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);
135
    }
136
    else
137
    {
138
        // draw the inactive line
139
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0x161A1D);
140
        EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
141
        EVE_cmd_dl_burst(DL_BEGIN | EVE_LINES);
142
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w - 40) / 2, _y - 9));
143
        EVE_cmd_dl_burst(VERTEX2F(_x + (_w + 40) / 2, _y - 9));
144
        EVE_cmd_dl_burst(DL_END);
145
        EVE_cmd_dl_burst(DL_COLOR_RGB | 0xFFFFFF);
146
    }
147
    EVE_cmd_dl_burst(SCISSOR_XY(0, 0));
148
    EVE_cmd_dl_burst(SCISSOR_SIZE(480, 800));
149
150
    // draw the arrows
151
    EVE_cmd_setbitmap_burst(UpArrowAsset::GetInstance()->currentMemoryAddress, UpArrowAsset::GetInstance()->GetFormat(), UpArrowAsset::GetInstance()->GetWidth(), UpArrowAsset::GetInstance()->GetHeight());
152
    EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
153
    EVE_cmd_dl_burst(VERTEX2F(
154
        _x + (_w - UpArrowAsset::GetInstance()->GetWidth()) / 2,
155
        _y + (_h / 4) - (UpArrowAsset::GetInstance()->GetHeight() / 2)));
156
    EVE_cmd_dl_burst(DL_END);
157
    EVE_cmd_setbitmap_burst(DownArrowAsset::GetInstance()->currentMemoryAddress, DownArrowAsset::GetInstance()->GetFormat(), DownArrowAsset::GetInstance()->GetWidth(), DownArrowAsset::GetInstance()->GetHeight());
158
    EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
159
    EVE_cmd_dl_burst(VERTEX2F(
160
        _x + (_w - DownArrowAsset::GetInstance()->GetWidth()) / 2,
161
        _y + 3 * (_h / 4) - (DownArrowAsset::GetInstance()->GetHeight() / 2)));
162
    EVE_cmd_dl_burst(DL_END);
163
164
    // draw the label
165
    if (_posLabel != NULL)
166
        EVE_cmd_text_burst(_x + (_w / 2), _y - 26, GothamMedium18_FontHandle, EVE_OPT_CENTER, _posLabel);
167
168
    // draw the touch area
169
    EVE_cmd_dl_burst(COLOR_A(0));
170
    EVE_cmd_dl_burst(LINE_WIDTH(1 * 16));
171
    // touch area for UP
172
    EVE_cmd_dl_burst(TAG(_tag));
173
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
174
    EVE_cmd_dl_burst(VERTEX2F(_x, _y));
175
    EVE_cmd_dl_burst(VERTEX2F(_x + _w, _y + _h / 2));
176
    EVE_cmd_dl_burst(DL_END);
177
    // touch area for DOWN
178
    EVE_cmd_dl_burst(TAG(_secondaryTag));
179
    EVE_cmd_dl_burst(DL_BEGIN | EVE_RECTS);
180
    EVE_cmd_dl_burst(VERTEX2F(_x, _y + _h / 2));
181
    EVE_cmd_dl_burst(VERTEX2F(_x + _w, _y + _h));
182
    EVE_cmd_dl_burst(DL_END);
183
    EVE_cmd_dl_burst(COLOR_A(255));
184
    EVE_cmd_dl_burst(TAG(0));

von Rudolph (Gast)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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

: Bearbeitet durch User
von Spyy (Gast)


Lesenswert?

Wow danke...

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

:)

von Rudolph R. (rudolph)


Lesenswert?

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

Das sieht dann so aus:
1
void EVE_cmd_dl(uint32_t command)
2
{
3
    if(cmd_burst)
4
    {
5
        spi_transmit_burst(command);
6
    }
7
    else
8
    {
9
        eve_begin_cmd(command);
10
        EVE_cs_clear();
11
    }
12
}
13
14
15
void EVE_cmd_dl_burst(uint32_t command)
16
{
17
    spi_transmit_burst(command);
18
}

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.

von Rudolph R. (rudolph)


Lesenswert?

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:
1
EVE_start_cmd_burst();
2
EVE_cmd_dl(CMD_DLSTART);
3
EVE_cmd_dl(DL_CLEAR_RGB | WHITE);
4
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
5
EVE_cmd_dl(TAG(0));
6
EVE_cmd_append(MEM_DL_STATIC, num_dl_static);
7
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
8
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. :-)

von Rudolph R. (rudolph)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Bernd I. (Firma: Ickert-Elektronik) (bernd2201)


Lesenswert?

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

von Stanley (homer2009)


Angehängte Dateien:

Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Stanley (homer2009)


Lesenswert?

OK thank you for the information

von Spyy (Gast)


Lesenswert?

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

von Rudolph R. (rudolph)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.