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...:(
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.
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.
And to get back to Englisch, I just tested the modified display adapter
with an EVE3-50G and the Teensy 4.1 and it works without connecting the
logic
analyzer now.
Interestingly the display for the frequency changed:
7246628x for reading REG_CLOCK every second
72467376 for the reading REG_CLOCK right after init with the delay().
But since frames/s is up a little as well to 74/75 instead of 73/74 it
is possible that the Teensy is running a little fast right now.
Setting the SPI to 21MHz after init works, at 22MHz the display stays
dark.
This is the adapter with the configuration I am using:
https://github.com/RudolphRiedel/EVE_display-adapter/blob/master/L-D5019-01-05/L-D5019-01-05_EVE.PDF
Only the audio part with the speaker is not populated.
I changed R3, R5 and R8 from 10R to 240R and added a 22pF between pin 1
of U2A and GND.
I have a second adapter that is populated to the same configuration as
in the .pdf but with R17 removed and R24 populated.
Ok, and the audio part is not populated on this board either.
I am using this board with the RVT101 and I am supplying it with 9.6V
for the backlight in order to keep the backlight current low.
And next I am changing R3, R5 and R8 to 150R on this one.
Hey, that worked just fine, I have the RVT101 now up and running with
the Teensy 4.1 without the logic analyzer connected.
And with the lower vaule for the resistors of 150R instead of 240R the
SPI works with a higher clock now.
With 26MHz reading from the display still works including the touch.
With 27MHz the number displayed for the Frequency and the Frames/s that
are measured one per second is "0" and the touch is not working anymore.
When I setup the SPI to 30MHz, 40MHz or even 50MHz the display still
works but I doubt that it really is using 40MHz let alone 50MHz.
Back to 20MHz, the display for the frequncy measured once is: 72003052
And for the frequency measured every second: 72002403
No idea why this is different now, maybe the clock on the EVE3-50G is
running a little faster than 12MHz.
The RVT101 is using a crystal and the EVE3-50G is using a resonator,
this is maybe 0,02% to maybe 0.5%.
So like Arnaud reported for the Teensy 3.5, at least my Teensy 4.1
needs a little more series resitance to play nice on the SPI even when
working without a real load since I am using logic buffers.
Now I am glad that I did not optimise-away the 10R/22pF from my board.
:-)
Hmm, I just tried to use the internal oscillator by removing the
"EVE_HAS_CRYSTAL" define from the module configuration.
And there is some issue, this way the display is blinking, measuring the
frequency and frames/s every second does not work and the frequency
measured once only is 38069614.
I look into that.
Oh, big oh, the BT817/BT818 do not have the "internal relaxation
oscillator" anymore or at least this has been removed from the
datasheet.
From chapter 4.2 in the datasheet "System Clock" up to the CLKINT
command.
It's gone, you have a add a crystal, a resonator.
"External Clock Input" also is gone.
But even if this still works somewhat contradicting the datasheet, my
display
is wired for an crystal and not for the internal oscillator like in the
datasheet of the BT815/BT816. This would require X1/Clk to be connected
to GND.
So even if this still works, switching to internal oscillator with a
crystal connected is not a valid experiment.
Edit: and I just posted this with more details from the datasheet to the
BRT forum.
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?
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...:(
I am exclusively using readily available modules so far.
And I am not using 12MHz crystals with my controllers, but 16MHz mostly.
That said I went on to a quick fishing expedition on Digikey and found
CX3225GA12000D0PTVCC ( 1253-1151-1-ND ), if I were to add a 12MHz
crystal and had to make due with what is available I probably would go
for these.
Plus 12pF capacitors.
I prefer the crystals with two pads as I can solder these more easily by
hand.
Since Matrix Orbital is sucessfully using ceramic resonators on their
modules an alternative to a crystal might be a CSTNE12M0GH5L000R0 (
490-17947-1-ND ), I selected these for their better frequency tolerance
of +/- 0.07% compared to the more standard +/- 0.5% for resonators.
Hi there, How can I display an image with new library in old FT 800
series? There no setbitmap command... also, I remember taht "FT80x is
gone" so, what can I do, if I have to use old FT800?
When i use yours example:
#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
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:
and the same metod
for display it, it doesn't work at all.
Sometimes, only ft800_cmd_inflate(...) crashed.
PS. For this case, I am using "Spielplatz_90CAN_FT800.zip " from first
post.
Regards
Karol
Karol B. schrieb:> Hi there, How can I display an image with new library in old FT 800> series? There no setbitmap command... also, I remember taht "FT80x is> gone" so, what can I do, if I have to use old FT800?
Hello,
while my first recommendation is to switch to a newer display, you can
also still use the older version of my library, it's all still there.
https://github.com/RudolphRiedel/FT800-FT813/tree/4.x
And the API is pretty close to the current one with the exception that
V5 additionally has the EVE...._burst() functions to shave off a few
extra cycles from every function by not checking for burst-mode every
time.
That thing I did over five years ago that is attached to the start of
this thread, it is not supported anymore. :-)
Thanks a lot for your quick answer. Could you give me short an example
how to display 2 images, one with load_image and another with
cmd_inflate functions?
It really has been a while since I used a FT800 based display.
I just took the Arduino example from the V4 archive which is displaying
two images.
I modified the display to EVE_VM800B50A in EVE_config.h.
Compiling it showed that the example is not directly compatible with
FT800.
First there is VERTEX_FORMAT that does not exist in FT80x and which
allows to setup the pixel resolution for VERTEX2F.
So VERTEX2F for FT80x always is using 1/16 pixel resolution - which I
really do not miss.
Next is CMD_SETBITMAP which does not exist for FT80x either and needs to
be replaced with a sequence of comands.
EVE_cmd_setbitmap(MEM_LOGO, EVE_L8, 38, 59);
->
EVE_cmd_dl(BITMAP_SOURCE(MEM_LOGO));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_L8,38,59));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,38,59));
And there is a second CMD_SETBITMAP that I changed as well.
EVE_cmd_setbitmap(MEM_PIC1, EVE_RGB565, 100, 100);
->
EVE_cmd_dl(BITMAP_SOURCE(MEM_PIC1));
EVE_cmd_dl(BITMAP_LAYOUT(EVE_RGB565,100*2,100));
EVE_cmd_dl(BITMAP_SIZE(EVE_NEAREST,EVE_BORDER,EVE_BORDER,100,100));
I am not sure if this really works but at least it compiles without
warning now for an Arduino Uno using PlatformIO.
Thanks a lot :) I will try attached example. For now, i have got working
one. Perhaps my mistake was all about PROGMEM attribute after
cmd_inflate. I feel I forgotten read data form flash.
Thanks again, You'ar great :)
Hallo Rudolph
ich habe ein Display von Riverdi mit kapazitivem Touch (RVT50AQBNWC00).
Das Display funktioniert einwandfrei und auch der Touch funktioniert
wenn ich die Kalibrierfunktion am Anfang des Programms aufrufe.
Wenn ich aber die Kalibrierwerte abspeichere und diese dann nach dem
Initialisiseren des Display in die REG_TOUCH_TRANSFORM_A-F Register
schreibe, dann funktioniert der Touch nicht.
Gibt es da noch etwas spezielles zu beachten?
Was mir auch eigenartig erscheint, die Kalibrierwerte für die
REG_TOUCH_TRANSFORM-Register sind nach jeder Kalibrierung komplett
verschieden.
Freundliche Grüsse
Markus
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.
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.
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
Hallo Rudi,
bin mit meinen Versuchen, ein Bitmap darzustellen einen großen Schritt
weiter gekommen! Leider sehe ich am Ende auch nach vielem
Experimentieren nur ein "verkrisseltes" Bild in der Größe ca. 35 x 35
und das stets in der linken oberen Ecke, obwohl ich in VERTEX2II
eindeutig die Koordinaten 100 x 100 (z.B.) eingebe.
Also: FT813! Keine Co-Prozessor-Nutzung!
Benutze den FTDI-EVE-Screen-Editor. Habe mal mein Logo mit "Paint" auf
eine Größe von 100 x 35 Pixel gebracht und als Projekt in den
Screen-Editor als ARGB1555 geladen. Nach dem Speichern des Projekts hat
man die RAWH-Daten. Bei 2 Bytes pro Pixel und genannter Größe sind das
immerhin stolze 7000 Bytes. Die Schreibe ich als erstes in den RAM_G.
Zur Kontrolle habe ich dann erst mal 1 Sekunde später die Daten
ausgelesen und auf den Bildschirm gebracht (zumindest mal die ersten
255) und Verglichen: Alles richtig gemacht!
Dann setze ich:
Bitmap_Handle(0)
Bitmap_Source(0) (habe ja die Daten ab Adresse Null des Ram_G
geschrieben)
Bitmap_Lyout(ARGB1555, 200, 35)
Parameter "Linestride" (200) muss gemäß Anleitung Anzahl Bytes pro Pixel
(2) mal Weite (hier 100) also 200 sein. Der EVE_Screen-Editor spuckt
diesen Wert auch sofort allein aus, wenn ich als Format ARGB1555 setze.
Am Editor kann man auch schön sehen, was passiert, wenn man diesen Wert
ändert (Bild verzerrt sich zunehmend). Und genau so - abgesehen von dem
kleinen Ausschnitt - sieht auch der Teil, den ich bei mir am Display
sehe aus, mega stark verzerrtes Bild, was mit viel Fantasie erahnen
lässt, dass das mein Logo (ein Ausschnitt davon) sein soll.
Dann setze ich natürlich noch:
Bitmap_Size(Nearest,Border,Border,100,35) (Bitmap_Size(0,0,0,100,35))
Zu guter letzt folgt dann natürlich noch Begin_Bitmaps, Vertex2II mit
den X-Y-Koordinaten 100/100, EndList und Display...
Große Frage: Der EVE-Screen-Editor ist zwar für den FT800, aber gemäß
Prorammer-Guide des FT813 sind die einzelnen genannten Befehle genau so.
Kann ich diese Bilddaten (RAWH) hier wirklich benutzen?
Irgendwie steckt in meinem Hinterkopf noch so drin, dass man
"eigentlich" nur Bitmaps mit max. 64 x 64 darstellen kann. Aber
Bitmap_Size sagt ja für Width und Height als erlaubte Werte je 511. Und
wenn ich dann noch Size_H benutze, geht es ja noch größer...!
Habe ich noch etwas ganz wichtiges vergessen?
Vor dem Darstellen des Bitmap setze ich ja z.B. einen Begrüßungstext na
usw. Die RAM_DL-List für das Bitmap ist (zunächst) der letzte Schritt.
Wenn ich hier NICHT Clear(1,1,1) mit CLEAR_COLOR_RGB(0,0,0) setze, wird
das "verkrisselte" Bitmap in der Breite ca. 35 Pixel von oben bis unten
dargestellt. Füge ich CLEAR... ein, so erscheint das 35 x 35 Bild. Gibt
es dafür eine sinnvolle Erklärung?
Außer, dass ich die noch bis vor kurzem nicht benutzten Befehle CLEAR
(mit CLEAR_COLOR_RGB) nun einsetze, habe ich mich auch mit COLOR_A,
sowie SCISSOR beschäftigt und es auch tatsächlich hinbekommen hiermit
Überblend- und Ausblendeffekte zu erzielen.
Was kann ich nun noch Probieren, um ein Bitmap, so wie im Screen-Editor
zu sehen auch real auf mein Display zu bekommen?
Rudolph R. schrieb:> ein paar Sachen die EVE kann> sind dann auch weitgehend an mir vorbei gegangen, vor allem die ganzen> am Rande erwähnten Open_GL Features, Alpha-Blending, Scissors, die> Transformations-Matrix. Auch zum Beispiel wofür EDGE_STRIPs gut sein> sollen.
Das war schon am 4.6.!!!
Kann ich Dir gern erklären, wofür man EDGE_STRIPs benutzt (für mich
unabdingbar!). Und wie schon gesagt: Alpha-Blending und Scissor
beherrsche ich nun auch. Brauchst Du das (noch)???? Dan sag' bescheid.
Moin,
Bernd I. schrieb:> Hallo Rudi,> bin mit meinen Versuchen, ein Bitmap darzustellen einen großen Schritt> weiter gekommen! Leider sehe ich am Ende auch nach vielem> Experimentieren nur ein "verkrisseltes" Bild in der Größe ca. 35 x 35> und das stets in der linken oberen Ecke, obwohl ich in VERTEX2II> eindeutig die Koordinaten 100 x 100 (z.B.) eingebe.
Hmm, seltsam.
> Also: FT813! Keine Co-Prozessor-Nutzung!
Ich verstehe immer noch nicht, warum Du das machst, aber das ist soweit
nicht das Problem.
> Benutze den FTDI-EVE-Screen-Editor. Habe mal mein Logo mit "Paint" auf> eine Größe von 100 x 35 Pixel gebracht und als Projekt in den> Screen-Editor als ARGB1555 geladen. Nach dem Speichern des Projekts hat> man die RAWH-Daten. Bei 2 Bytes pro Pixel und genannter Größe sind das> immerhin stolze 7000 Bytes. Die Schreibe ich als erstes in den RAM_G.
Sowas habe ich auch gerade gemacht. das ESE Projekt hängt an.
> Bitmap_Handle(0)> Bitmap_Source(0)> Bitmap_Lyout(ARGB1555, 200, 35)> Bitmap_Size(Nearest,Border,Border,100,35)> Bitmap_Size(0,0,0,100,35))> Begin_Bitmaps> Vertex2II(100, 100, 0, 0)> END()
Praktisch so habe ich das im ESE drin, mit drei zusätzlichen Zeilen.
CLEAR_COLOR_RGB(255, 255, 255)
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
Also Hintergrund weiß, löschen und Basis-Farbe des Bildes auch weiß.
> Große Frage: Der EVE-Screen-Editor ist zwar für den FT800,
Der EVE-Screen-Editor geht für alle von FT800 bis BT818 und in dem
angehängten Projekt ist ein FT813 ausgewählt mit 480x272.
> Kann ich diese Bilddaten (RAWH) hier wirklich benutzen?
Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem
EVE-Asset-Builder, aber erstmal sieht das plausibel aus.
> Irgendwie steckt in meinem Hinterkopf noch so drin, dass man> "eigentlich" nur Bitmaps mit max. 64 x 64 darstellen kann. Aber> Bitmap_Size sagt ja für Width und Height als erlaubte Werte je 511. Und> wenn ich dann noch Size_H benutze, geht es ja noch größer...!> Habe ich noch etwas ganz wichtiges vergessen?
Das ist total richtig und das sind dann 2048x2048.
Wobei ich mir da normalerweise gar keine Gedanken mache, ich benutze
einfach CMD_SETBITMAP und das erzeugt einfach die notwendige Sequenz.
> Vor dem Darstellen des Bitmap setze ich ja z.B. einen Begrüßungstext na> usw. Die RAM_DL-List für das Bitmap ist (zunächst) der letzte Schritt.> Wenn ich hier NICHT Clear(1,1,1) mit CLEAR_COLOR_RGB(0,0,0) setze, wird> das "verkrisselte" Bitmap in der Breite ca. 35 Pixel von oben bis unten> dargestellt. Füge ich CLEAR... ein, so erscheint das 35 x 35 Bild. Gibt> es dafür eine sinnvolle Erklärung?
So direkt fällt mir dazu nichts ein, mit der Sequenz da oben bekomme ich
im ESE mein 100x35 Pixel Bild angezeigt.
Wobei ich VERTEX2F mit VERTEXT_FORMAT(0) vorziehe.
Eventuell ist das ein Problem mit der vorherigen Liste.
> Außer, dass ich die noch bis vor kurzem nicht benutzten Befehle CLEAR> (mit CLEAR_COLOR_RGB) nun einsetze, habe ich mich auch mit COLOR_A,> sowie SCISSOR beschäftigt und es auch tatsächlich hinbekommen hiermit> Überblend- und Ausblendeffekte zu erzielen.>> Was kann ich nun noch Probieren, um ein Bitmap, so wie im Screen-Editor> zu sehen auch real auf mein Display zu bekommen?
Wie war das? Du nutzt kein C?
Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das
Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt
werden soll.
Das kann entweder für Pulseview oder Saleae Logic 2 sein.
Einfache Logic-Analyzer die mit Pulseview laufen bekommt man schon für
10 Euro, dann sollte man allerdings den SPI-Takt runter setzen, mehr als
24Mhz Abtast-Rate schaffen die nicht, also mehr als 2MHz bis 4Mhz kann
man damit nicht sinnvoll messen.
Bernd I. schrieb:> Kann ich Dir gern erklären, wofür man EDGE_STRIPs benutzt (für mich> unabdingbar!). Und wie schon gesagt: Alpha-Blending und Scissor> beherrsche ich nun auch. Brauchst Du das (noch)???? Dan sag' bescheid.
Danke, ich habe da nur bisher keine Verwendung für gefunden.
Was kann man mit Edge-Strips anfangen? Ich schaue gerade auf die vier
Bilder im Programming-Manual und mir fällt nichts ein für das ich sowas
schon mal hätte verwenden können.
Ein geschichtsträchtiger Morgen:
Mein Logo erscheint auf dem Display!!!
Habe es mal auf 50 x 17 gekürzt. DENNOCH: Es sitzt immer noch in der
Ecke oben links, statt auf 200 x 200 (X , Y). Na den Fehler finden wir
noch...
Rudolph R. schrieb:> Praktisch so habe ich das im ESE drin, mit drei zusätzlichen Zeilen.> CLEAR_COLOR_RGB(255, 255, 255)> CLEAR(1, 1, 1)> COLOR_RGB(255, 255, 255)
Brachte keinen Unterschied. Es hat auch nichts mit dem vorherigen
Bildaufbau zu tun. Habe das mal übersprungen und nun nach dem großen
Erfolg wieder aktiviert: Bleibt alles, wie es ist: Das kleine Logo (50 x
17) steht "sauber" oben links in der Ecke...
Ich vermute mal, dass ich bei den 7000 Bytes irgendwo ein Vielfaches von
32 oder 64 nicht richtig gelesen (geschrieben) habe. Lese die Daten im
Moment vom Flash, da muss man diese Vielfache beachten. Später sollen
die Daten dann als Editor-Datei in einen USB-Stick, der On-Board ist.
Rudolph R. schrieb:> Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das> Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt> werden soll.
??????????????? Um Gottes willen!!!!
Ja, nach wie vor KEIN "C"! Immer noch in Basic. Ich schreibe das nur so
in dieser Form hier, dann weißt Du (und jeder andere) gleich, was
gemeint ist, also in der Form, wie es im Programmer-Guide steht.
Und immer noch kein Co-Prozessor! Alles eins nach dem anderen!
Überblenden von einem Bild zum Anderen mit SCISSOR:
Display 800 x 480
1. Start-Koordinaten in der Mitte des Bildschirms definieren: X=400,
Y=240
2. Start-Größe des aufzublenden Bildes definieren (minimal): Höhe=1,
Breite=2
3. For-Next-Schleife
For Var16 = 0 to 399
Beginn RAM_DL
Bildschirm komplett mit Farbe, Text etc. setzen (Bild VOR dem
Überblenden)
Display(0) 'Bild VOR SCISSOR erscheint
SCISSOR_XY(X,Y)
SCISSOR_SIZE(Breite,Höhe)
clear(1,0,0) 'Ich glaube, das ist wichtig, funktioniert sonst nicht
Beginn RAM_DL
Bild NACH SCISSOR schreiben
Display(0) 'Bild NACH SCISSOR erscheint von Mitte immer größer werdend
Breite = Breite + 2 : Höhe = Höhe + 2 'Bildausschnitt für Bild NACH
SCISSOR langsam vergrößern UND
...
X=X-1 : Y=Y-1 '... schräg nach oben links
wandern
Verzögerung in Millisekunden 'Geschwindigkeit des Überblendens
next 'Nächster Schleifendurchlauf
In die Schleife noch einbauen: Wenn Y=0, dann das "Y=Y-1" natürlich
überspringen.
Das neue Bild erscheint mit der Geschwindigkeit von "Verzögerung" von
Innen nach Aussen über dem alten Bild.
Abblenden mit COLOR_A
Eigentlich wie unter 4.26 (COLOR_A) im Programmer-Guide (FT813) als
Beispiel beschrieben. Um nun ein komplettes Bild abzublenden, wieder
eine For-Next-Schleife ausführen, wobei Alpha von 255 bis gewünschten
Minimum (bestenfalls Null) abwärts zählt
In Basic sieht das so aus:
For Alpha = 255 to 0 Step -1
Beginn RAM_DL
Bild setzen
Display(0)
Color_A(Alpha)
Verzögerung (Geschwindigkeit des Abblendens)
next
ODER auch nur Teile eines Gesamtbildes langsam ausblenden
For Alpha = 255 to 0 Step -1
Beginn RAM_DL
Bild-Teile setzen, die nicht ausgeblendet werden sollen
Color_A(Alpha)
Bild-Teile setzen, die ausgeblendet werden sollen
Display(0)
Verzögerung (Geschwindigkeit des Abblendens)
next
Logo erscheint nun an gewünschter Stelle X,Y. Ich weiß es absolut nicht,
was ich bei VERTEX2II falsch gemacht hatte. Habe lediglich festgestellt,
dass ich das ja schon vor Jahren definiert hatte im Zusammenhang mit
Text schreiben. Nur dass hier eben "Fonts" = "Handle" ist und der ASCI =
"Cell" und beide Werte nun Null sein sollten. Also habe ich diese uralte
Routine aufgerufen und siehe da es geht. Was leider aber trotz aller
Sorgfalt immer noch nicht geht, ist das große Logo 100x35. Gleiche
Erscheinung (nur jetzt auch nicht mehr Ecke oben links, sondern auf
angegebenen Koordinaten), "verkrisseltes" kleines Bild.
Alles ist gegenüber dem Logo 50x17 identisch. Nur eben natürlich mehr
Daten in den RAM_G schreiben und die Parameter LineStride, sowie Height
und Width anpassen.
Was kann hier noch falsch sein ??????????
Noch mal zu Deiner Frage, was soll ich mit EDGE_STRIP:
Wie zeichnest Du ein Parallelogramm oder ein Dreieck? Sicherlich auf
Deine Art (mit Co-Prozessor nehme ich mal an).
Ein Parallelogramm setze ich z.B., indem ich von links nach rechts die
Seiten mit EDGE_STRIP_R setze. Voraussetzung ist allerdings eine
homogene Hintergrund-Farbe.
Setze die 3 Koordinaten der linken Kante mit der gewünschte Füllfarbe
des Parallelogramms. Setze die 3 Koordinaten der rechten Kante mit der
Hintergrund-Farbe (bzw. eben der Farbe, die rechts vom Parallelogramm
erscheinen soll). Ich weiß, jetzt krempeln sich dir alle Fußnägel hoch
:):):).
Aber dafür könnte man es verwenden!!! Und habe es verwendet, z.B. eine
offen stehende Tür, incl. Türschild (Tür-Klinke)...
Nur zur Info:
Logo 100x35 geht jetzt auch. Fehler war eindeutig in meiner Software
beim Generieren der Var32 für das Setzen beim Befehl BITMAP_LAYOUT ...
Bernd I. schrieb:>> Zeichne das doch mal bitte mit dem Logic-Analyzer auf und hänge das>> Protokoll hier an, den ganzen SPI und vom Reset bis das Bild angezeigt>> werden soll.>> ??????????????? Um Gottes willen!!!!> Ja, nach wie vor KEIN "C"! Immer noch in Basic.
Ja nun, genau aus dem Grund die Idee einen Level tiefer anzusetzen.
Ich schaue mir den SPI Output regelmäßig mit dem Logik-Analyzer an, vor
allem wenn ich Support für einen neuen Controller einbaue.
Denn dabei kommt oft genug sowas hier raus:
https://github.com/RudolphRiedel/FT800-FT813/discussions/32
Wenn ich jetzt rein auf das Display schauen würde, dann könnte ich
vorschnell zu dem Ergebnis kommen, dass das nicht nur funktioniert,
sondern auch benutzbar ist.
In dem konkreten Fall ist die unter der Arduino SPI Klasse liegende HAL
so seltsam programmiert, dass der SPI mit angezogener Handbremse läuft.
Ich habe auch die HAL direkt manipulieren können weil die als Quelltext
vorliegt, ich konnte ohne negative Seiteneffekte mehrere Zeilen
auskommentieren und den SPI so beschleunigen.
Und das kommt nicht etwa von irgendwem, das kommt vom Hersteller des
Controllers.
Im Gegensatz zu dem noch seltsameren Verhalten von z.B. ESP32 ist da
nicht mal ein RTOS im Spiel und der Controller hat auch nur einen Kern.
Wenn Du jetzt auf der obersten Ebene alles richtig machst heißt das noch
lange nicht, dass die Daten auf dem SPI auch so raus kommen wie
beabsichtigt.
Bernd I. schrieb:> Noch mal zu Deiner Frage, was soll ich mit EDGE_STRIP:> Wie zeichnest Du ein Parallelogramm oder ein Dreieck?
Gar nicht. :-)
Und das Problem das ich mit dem EDGE_STRIP habe ist, das ist an eine
Kante des Displays gebunden, damit kann man nicht mal eben ein Dreieck
mitten auf den Bildschirm malen.
Und so bleibe ich bei RECT und POINT, zumal man Rechtecken mit der
LINE_WIDTH auch gerundete Ecken verpassen kann.
Ach so, der Punkt ist auch schnell überschritten an dem es sich eher
lohnt eine Grafik zu verwenden, alleine schon weil man damit weniger
über den SPI schicken muss.
Hallo Rudolph,
ich habe deine Lib verwendet, mit einem STM32H7A3 und 7" TFT von
Newhaven, als kleines Test-projekt in der STM32CubeIDE, läuft ohne viel
tamtam ganz fein.
wenn es dich (oder andere..) interessiert, poste ich die wichtigen
Punkte , bzw die source. (oder auf git , wenn das besser ist :-)
die SPI läuft mit 24 Mbit, ein screen update dauert etwa 500us (ohne
jegliche Optimierung oder DMA ), soweit ganz ok. CPU Last liegt somit
bei 5% für Graphik mit maximaler Geschwindigkeit, also mit rund 60Hz
update rate.
könnte auch ein kleines Video von der Demo machen, mit bewegter Graphik
;)
Äh, ok, meinst Du nicht, dass ein 280MHz Cortex-M7 mit 2MB Flash und 100
Pins aufwärts ein klein wenig übertrieben ist? :-)
Ok, machen was geht halt, aber das Monster hat sogar einen eingebauten
Grafik-Controller. :-)
Ich spiele gerade mit einem K32L2B3 rum, nur um das mal gemacht zu
haben.
Das ist ein Cortex M0+ mit 48MHz und Laufen hatte ich den an dem 7" mit
1024x600 zumindest schon.
So grundsätzlichen Support für diverse STM32 Familien habe ich ja schon
eingebaut.
Aber es ist nicht so, als ob man irgendwelche interessanten STM32 gerade
kaufen könnte.
DigiKey hat zum Beispiel gerade nur 17 verschiedene auf Lager, 9 davon
im BGA Gehäuse.
Die restlichen 8 sind nicht geeignet mich von den ATSAMC21 / ATSAME51
abzubringen die ich im Moment verwende.
Und ich weiß ich habe da auch noch nichts fertiges, aber so einen
Controller ohne DMA zu nutzen ist irgendwie verschwendet. :-)
Aus Neugier habe ich gerade mal versucht H7 Support einzufrickeln, so
für ein nucleo_h743zi da PlatformIO kein Board mit dem STM32HA3 zu
kennen scheint.
Das compiliert nur spontan nicht, da es in der H7 LL_SPI HAL Library die
Funktionen LL_SPI_IsActiveFlag_TXE() und LL_SPI_IsActiveFlag_RXNE() wohl
nicht gibt.
Wenn ich die Zeilen auskommentiere baut es durch, "stm32cube", nur fehlt
in meinem "Beispiel" der ganze Code drum herum, also was man so in der
STM32CubeIDE als Grundgerüst generieren würde.
Also wenn Du die notwendigen paar angepassten Zeilen für spi_transmit()
und spi_receive() posten magst, dann füge ich die gerne noch ein.
nu ja, der H7A3 ist nicht unbedingt nötig :)
aber: er war eben noch lieferbar... (neue Zeit, neue Regeln...)
aktuell ist ja fast nix lieferbar.
hier die Demo:
https://youtu.be/f-EG9uTTJ5k
Snoopy lässt grüssen !
Hallo Rudolph,
zunächst mal vorab:
Rudolph R. schrieb:> Und das Problem das ich mit dem EDGE_STRIP habe ist, das ist an eine> Kante des Displays gebunden, damit kann man nicht mal eben ein Dreieck> mitten auf den Bildschirm malen.
Das verstehe ich nicht! Bei EDGE_STRIP setzt Du doch beliebige
Koordinaten, egal wohin!!! So (und nicht anders) setze ich Dreiecke /
Parallelogramme etc. mitten in das Display:
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
LINE_WIDTH(256)
CLEAR(1, 1, 1)
BEGIN(EDGE_STRIP_R)
VERTEX2II(20, 65, 0, 0) 'Linke Ecke des Dreiecks
VERTEX2II(100, 100, 0, 0) 'Spitze Unten
COLOR_RGB(0, 0, 0) 'ab rechter Kante wieder schwarz
VERTEX2II(100, 100, 0, 0) 'Spitze Unten
VERTEX2II(180, 65, 0, 0) 'Rechte Ecke des Dreiecks
END(0)
DISPLAY(0)
Na klar, das geht eben nur, wenn man einen homogenen Hintergrund hat!
Aber da Du das ja sowie so gar nicht nutzt ...
Habe die letzten Tage viel experimentiert.
Danke für den Tip (Bemerkung):
Rudolph R. schrieb:> Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem> EVE-Asset-Builder, aber erstmal sieht das plausibel aus.
Das geht, wenn man eben nur die Bilddaten konvertieren möchte besser
(ist übersichtlicher, einfacher). Zum Experimentieren ist der
EVE-Screen-Editor trotzdem nicht schlecht. Man kann im Vorfeld so
einiges Probieren...
MERWÜRDIG: Ein stichprobenartiger Vergleich der Daten ein und des selben
Bildes, konvertiert einmal mit Screen-Editor und einmal mit
Asses-Builder zeigt recht gravierende Unterschiede!!! Die Darstellung
ist aber dennoch identisch, zumindest fürs menschliche Auge.
Da meine Hardware schon lange vorher fertig war, habe ich nun (nur ein
kleines) Problem: Die Bilddaten schnell genug aus den USB-Stick zu
bekommen.
Da ich mich nicht mit FAT32 und dem ganzen "USB-Gedöhns" auskennen,
nutze ich den VNC1L (von FTDi), jedoch nicht den fertigen VDIP1, sondern
eigentlich die Schaltung, so wie sie auf dem VDIP1 drauf ist, in meine
Applikation komplett integriert. Den "blanken" Chip VNC1L programmiere
ich vor dem Bestücken mit dem VPROG.
Bei der Schaltung nutze ich LEIDER die Kommunikationsart UART, obwohl
dieser VNC1L auch SPI und sogar parallel-FIFO kann, was ja alles viel,
viel schneller ginge. Aber zum Experimentieren ist es erst mal super.
Baudrate habe ich auf 1 Mega-Baud. Da benötigt die Grafik
(Display-Füllend 3,5 Zoll) 320 x 240 eben ca. 6 Sekunden, ehe sie im
RAM-G ist (besser gesagt: Ehe sie vom Stick herunter ist).
Ich hole die Daten ab (kommen ja als 2 ASCI, dann ein Leerzeichen, also
3 Byte pro RAM-Byte), bilde SOFORT aus den ASCI das RAM-Byte und schiebe
es per SPI in den RAM, während das nächste Byte vom VNC1L abgeholt wird.
Dieses parallele Arbeiten (UART // SPI) funktioniert einwandfrei und ich
brauch es nicht blockweise zu machen (erst 256 Bytes abholen, daraus ca.
115 RAM-Bytes bilden, in den RAM schieben, die nächsten abholen, ständig
mitrechnen ...). Und alles mit einem male abholen geht ja eben nicht, da
ich nicht weiß, wohin mit den rund 430.000 Byte, wenn man keinen
zusätzlichen RAM hat, sondern "nur" den PIC mit 128.000 Flash und 3800
RAM.
Eigentlich bin ich nun VORERTS am Ziel meiner Wünsche (nächste Hardware
mit Parallel-FIFO am VNC1L ist schon in Arbeit). Nun gibt es allerdings
ein Phänomen. Ob das jemand kennt? :
Durch einen Zufall (ein Fehler in meiner Software) stellte sich das Bild
nur in 64-Pixel Breite da (volle Höhe 240). Dabei war ein senkrechter
hellgrauer Streifen (ca. 50 breit und mitten in diesen 64 Pixel) absolut
top so dargestellt, wie er sollte. Nachdem ich dann nach
Fehlerbeseitigung das ganze Bild sah, ist dieser Streifen und auch alles
andere rechts neben den 64-Breite nach unten hin immer schwächer. Man
sieht den hellgrauen Streifen unten so gut wie gar nicht mehr. Also habe
ich mal eine Schleife gesetzt und von 64 Breite beginnend alle 100ms das
Bild um einen Pixel wachsen lassen:
BITMAP_SIZE(NEAREST, BORDER, BORDER, 64...320, 240)
Und siehe da: Beginnend mit dem scharf gleichmäßig durchgehenden grauen
Streifen links wurde er allmählich nach unten hin immer schwächer, je
breiter das Bild wurde !!! ????
Den gleichen Versuch auf einem 7 Zoll Display, mal in die Mitte die 320
x 240 gesetzt. Hier ist es nicht so, jedoch sind hier alle hellgrauen
Streifen komplett so gut wie nicht zu sehen. Nur wenn ich mit einem
Blickwinkel von mind. 45° drauf schaue, wird es so, wie das Original...
Beim 3,5 Zoller kann ich schief schauen, so viel ich will. Es bleibt
dabei, dass das Bild nach Unten hin immer schwächer wird. So als wenn
man den ALPHA-Channel nach unten hin immer größer werden lässt.
Hast Du eine Idee, ob man dagegen was unternehmen kann...???
Bernd I. schrieb:> Das verstehe ich nicht! Bei EDGE_STRIP setzt Du doch beliebige> Koordinaten, egal wohin!!! So (und nicht anders) setze ich Dreiecke /> Parallelogramme etc. mitten in das Display:> CLEAR(1, 1, 1)> COLOR_RGB(255, 255, 255)> LINE_WIDTH(256)> CLEAR(1, 1, 1)> BEGIN(EDGE_STRIP_R)> VERTEX2II(20, 65, 0, 0) 'Linke Ecke des Dreiecks> VERTEX2II(100, 100, 0, 0) 'Spitze Unten> COLOR_RGB(0, 0, 0) 'ab rechter Kante wieder schwarz> VERTEX2II(100, 100, 0, 0) 'Spitze Unten> VERTEX2II(180, 65, 0, 0) 'Rechte Ecke des Dreiecks> END(0)> DISPLAY(0)
Das macht zwar ein Dreieck, aber wenn ich nur eine Koordinate verändere
dann nicht mehr:
CLEAR(1, 1, 1)
COLOR_RGB(255, 255, 255)
LINE_WIDTH(256)
CLEAR(1, 1, 1)
BEGIN(EDGE_STRIP_R)
VERTEX2II(20, 65, 0, 0)
VERTEX2II(100, 100, 0, 0)
COLOR_RGB(0, 0, 0)
VERTEX2II(100, 100, 0, 0)
VERTEX2II(180, 75, 0, 0)
END(0)
Das ist jetzt nur der letzte Punkt 10 Pixel weiter runter.
Also mit "beliebige Koordinaten" wird das nichts, eben weil die
Edge-Strips jeweils bis an den Rand gehen.
>> Ich konvertiere Bilder nicht mit dem EVE-Screen-Editor, sondern mit dem>> EVE-Asset-Builder, aber erstmal sieht das plausibel aus.> Das geht, wenn man eben nur die Bilddaten konvertieren möchte besser> (ist übersichtlicher, einfacher). Zum Experimentieren ist der> EVE-Screen-Editor trotzdem nicht schlecht. Man kann im Vorfeld so> einiges Probieren...
Definitiv, das Edgestrip Beispiel habe ich gerade im ESE offen.
Es gab übrigens gerade einen neuen ESE: 4.2.0
> MERWÜRDIG: Ein stichprobenartiger Vergleich der Daten ein und des selben> Bildes, konvertiert einmal mit Screen-Editor und einmal mit> Asses-Builder zeigt recht gravierende Unterschiede!!! Die Darstellung> ist aber dennoch identisch, zumindest fürs menschliche Auge.
Welchen EAB hast Du?
Aber davon mal ab, Zumindest der EVE Asset Builder hat leider per
Default die Option "Dithering" für Bilder an, der überlagert beim
Konvertieren also praktisch die Bilder mit Rauschen.
Und da stehe ich überhaupt nicht drauf, ich fütter das Ding doch nicht
mit PNG Dateien damit das nach dem Konvertieren anders ist.
Außerdem verringert das die Komprimierbarkeit mindestens mit zlib.
> Da meine Hardware schon lange vorher fertig war, habe ich nun (nur ein> kleines) Problem: Die Bilddaten schnell genug aus den USB-Stick zu> bekommen.> Da ich mich nicht mit FAT32 und dem ganzen "USB-Gedöhns" auskennen,> nutze ich den VNC1L (von FTDi),
Mit nichts von dem habe ich hinreichend Erfahrung, aber bis auf das ich
schon mal einen Arduino mini in einem Projekt verwenden musste hatte ich
bisher auch noch keine Probleme mit den Assets.
Wobei zur Zeit, ja, normalerweise benutze ich Controller mit 512k oder
256k Flash, nur jetzt habe ich gerade von denen mit 256k nur welche
bekommen die lediglich 64k haben, was man eben so bekommen kann...
> Baudrate habe ich auf 1 Mega-Baud. Da benötigt die Grafik> (Display-Füllend 3,5 Zoll) 320 x 240 eben ca. 6 Sekunden, ehe sie im> RAM-G ist (besser gesagt: Ehe sie vom Stick herunter ist).
Ugh, Autsch.
> Ich hole die Daten ab (kommen ja als 2 ASCI, dann ein Leerzeichen, also> 3 Byte pro RAM-Byte),
Das ist übel ineffizient.
> bilde SOFORT aus den ASCI das RAM-Byte und schiebe> es per SPI in den RAM, während das nächste Byte vom VNC1L abgeholt wird.> Dieses parallele Arbeiten (UART // SPI) funktioniert einwandfrei und ich> brauch es nicht blockweise zu machen (erst 256 Bytes abholen, daraus ca.> 115 RAM-Bytes bilden, in den RAM schieben, die nächsten abholen, ständig> mitrechnen ...). Und alles mit einem male abholen geht ja eben nicht, da> ich nicht weiß, wohin mit den rund 430.000 Byte, wenn man keinen> zusätzlichen RAM hat, sondern "nur" den PIC mit 128.000 Flash und 3800> RAM.
Warum hast Du die Bilder unkomprimiert auf dem Stick?
Ich habe mir gerade mal ein möglichst chaotisches Bild gesucht, auf
320x240 geschnitten und zu RGB565 konvertiert.
Das sind 153600 Bytes wie erwartet.
Wenn ich das entweder durch den "Asset Compressor" schicke oder beim
Konvertieren den Haken bei "Compressed" drin habe, dann werden das 50574
Bytes.
Gleich noch mal die Probe mit "Dithering" an - Ugh, 81506 Bytes.
Also auf die Hälfte kommt man schon runter, eher wird es noch weniger.
Ich habe gerade mal ein Hintergund Bild aus dem Netz gefischt und
inklusive Watermark drin auf 320x240 konvertiert und bei 80% als .jpg
gespeichert.
Komprimiert hat das 41305 Bytes.
Das sind so 27% und müssten unter gleichen Bedingungen in unter 1,7s
übertragen sein. Auch nicht toll, aber besser als 6s.
Geladen wird das dann mit CMD_INFLATE.
> Durch einen Zufall (ein Fehler in meiner Software) stellte sich das Bild> nur in 64-Pixel Breite da (volle Höhe 240).>......> Hast Du eine Idee, ob man dagegen was unternehmen kann...???
Ich kann nicht behaupten das ich sowas ähnliches schon mal beobachtet
hätte.
Rudolph R. schrieb:> Das macht zwar ein Dreieck, aber wenn ich nur eine Koordinate verändere> dann nicht mehr:>> CLEAR(1, 1, 1)> COLOR_RGB(255, 255, 255)> LINE_WIDTH(256)> CLEAR(1, 1, 1)> BEGIN(EDGE_STRIP_R)> VERTEX2II(20, 65, 0, 0)> VERTEX2II(100, 100, 0, 0)> COLOR_RGB(0, 0, 0)> VERTEX2II(100, 100, 0, 0)> VERTEX2II(180, 75, 0, 0)> END(0)
Das ist korrekt, was Du sagts. Aber um z.B. ein Dreieck zu erhalten,
musst Du eben den letzten Punkt auf die gleiche Höhe setzen. Und man
kann beliebig viele Punkte setzen. Muss aber natürlich dabei wissen, was
man tut. Und soll eine durchgehende Verbindungs- (Zick-Zack-Linie)
beendet und da neben neu gesetzt werden (um ein "Zick-Zack-Rechteck zu
erhalten), muss Du End(0) und wieder Begin(Edge_Strip_R) mit der Farbe
rechts vom Rechteck setzen, da sonst die Linie weiter geführt wird.
Das ist schon interessant, was ich hier von Dir immer wieder so
"nebenbei" herauslese. Ich frage nach einem konkreten Problem, bei dem
Du mir (leider) nicht helfen kannst, aber beschreibts z.B. das
"Dithering". Bei der Suche nach dem beschriebenen Phänomen habe ich
schon mit dem Register "REG_DITHER" experimentiert. Hat nichts gebracht,
ohne zu wissen, was dieses Register wirklich ändert. Denn "Dither" heißt
ja "zittern" und "Dithering" heißt "schwankend". Wie soll man also auf
"Rauschen" kommen, wenn beim Builder das Häkchen gesetzt ist. Das
probiere ich noch aus, ob es hier dann einen Unterschied gibt. Kann das
nicht einfach dann "Noise" heißen ???
Das Thema Kompression ist mir im Moment noch zu schwierig, da ich dann
ja wieder auf den Co-Prozessor zugreifen muss. Ist immer noch kein
Thema. Wie schon gesagt, ist auch nicht wirklich schlimm. Später nutze
ich die schnelle Verbindung vom USB zum RAM-G. Und ein Komprimieren nach
meiner Art kann ich dann auch noch machen und weiß dann auch, wie ich es
beim Auslesen entschlüsseln (dekomprimieren) kann. Viele Bytes sind
nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine
Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche
Bytes", dann eine 17 (17 mal das folgende Byte) und dann ein FF. Also
aus 17 Bytes sind so 3 Bytes geworden. Mit ")" (Hex 29) kündigt man 2
wechselnde Byte an, was auch sehr oft ist, da ja gleiche Pixel bei 2
Byte pro Pixel diesen Wechsel ergeben. z.B. 12 Folgen von dem Wechsel
der beiden Bytes 9C und 67: Hx29 Hx0C Hx9C Hx67. Aus 24 Byte sind 4
geworden ...
Das mache mit einem eigenen "Komprimierer" (wenn es dann mal
erforderlich ist).
So jage ich z.B. auch meine eigenen Update-Dateien, die an Kunden gehen,
vorher durch einen "Verschlüsseler". Die Datei wird dann im Gerät beim
Update wieder von dem Gerät entschlüsselt (da alle meine Update-fähigen
Geräte einen einheitlichen Schlüssel dafür haben).
Einen schönen Abend noch !!!
> Das ist korrekt, was Du sagts. Aber um z.B. ein Dreieck zu erhalten,> musst Du eben den letzten Punkt auf die gleiche Höhe setzen. Und man> kann beliebig viele Punkte setzen. Muss aber natürlich dabei wissen, was> man tut. Und soll eine durchgehende Verbindungs- (Zick-Zack-Linie)> beendet und da neben neu gesetzt werden (um ein "Zick-Zack-Rechteck zu> erhalten), muss Du End(0) und wieder Begin(Edge_Strip_R) mit der Farbe> rechts vom Rechteck setzen, da sonst die Linie weiter geführt wird.
Ja genau, einfach mal so ein Dreieck zu malen ist damit nicht möglich.
:-)
Aber der eigentliche Knackpunkt ist das ich Dreiecke bisher auch nicht
wirklich vermisst habe.
Und was eben wirklich einfach geht sind Rechtecke, auch mit abgerundeten
Ecken.
> Das ist schon interessant, was ich hier von Dir immer wieder so> "nebenbei" herauslese. Ich frage nach einem konkreten Problem, bei dem> Du mir (leider) nicht helfen kannst, aber beschreibts z.B. das> "Dithering". Bei der Suche nach dem beschriebenen Phänomen habe ich> schon mit dem Register "REG_DITHER" experimentiert. Hat nichts gebracht,> ohne zu wissen, was dieses Register wirklich ändert. Denn "Dither" heißt> ja "zittern" und "Dithering" heißt "schwankend". Wie soll man also auf> "Rauschen" kommen, wenn beim Builder das Häkchen gesetzt ist. Das> probiere ich noch aus, ob es hier dann einen Unterschied gibt. Kann das> nicht einfach dann "Noise" heißen ???
REG_DITHER macht was vergleichbares, im Grunde soll es die Ausgabe
verbessern indem harte Übergänge reduziert werden.
Nur während sich REG_DITHER auf die Ausgabe auswirkt, verändert das
Dithering die Bilder bei der Konvertierung was sich wiederrum auf die
Komprimierbarkeit auswirkt.
Das sagt nichts darüber aus ob das resultierende Bild besser oder
schlechter aussieht, es lässt sich nur schlechter komprimieren und die
Pixel die man da rein steckt sind nicht die Pixel die man da raus
bekommt.
Ich habe gerade noch mal aus Jux ein Bild gepixelt, einfach ein paar
Sterne ohne aktiviertes Anti-Aliasing.
Ohne Dithering komprimiert das auf 2661 Bytes, mit auf 3707 Bytes.
Es kann sogar sein, dass dieses Bild mit Dithering besser aussieht.
> Das Thema Kompression ist mir im Moment noch zu schwierig, da ich dann> ja wieder auf den Co-Prozessor zugreifen muss.
Ja, das ist richtig.
> Und ein Komprimieren nach> meiner Art kann ich dann auch noch machen und weiß dann auch, wie ich es> beim Auslesen entschlüsseln (dekomprimieren) kann. Viele Bytes sind> nebeneinander liegend gleich, also kann man statt 17 x ein FF auch eine> Ankündigung z.B. "(" (Hex 28) für "Es folgt eine Verschlüsselung gleiche> Bytes",
Ja, nennt sich Runtime Encoding, damit kommt man aber nicht ganz so weit
wie mit der zlib Kompression die EVE bereits eingebaut hat. :-)
Dabei hatte ich gerade ein C64 Flashback. :-)
Nein, im Ernst, ein großer Vorteil ist ja das die Daten dann komprimiert
über den SPI gehen. Also der Controller muss da gar nichts entpacken.
>Also wenn Du die notwendigen paar angepassten Zeilen für spi_transmit()
und spi_receive() posten magst, dann füge ich die gerne noch ein.
mit dem Projekt, in der STM32cubeIDE mit HAL lib, ohne jegliche
Optimierung oder DMA , dauert ein Bild zu übertragen ca. 500us ; daher
habe ich vorerst den Aufwand mit der DMA sein lassen, weil das die
CPU-Last natürlich verrringern würde. aber der zu erwartende Gewinn von
ca. 5% auf 2% runter zu kommen -- keine wirkliche Bedeutung hat.
hier die HAL Aufrufe:
1
voidspi_transmit(uint8_tdata)
2
{
3
HAL_SPI_Transmit(&hspi5,&data,1,5);
4
}
5
6
uint8_tspi_receive(uint8_tdata)
7
{
8
uint8_tdain;
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 */
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.
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)
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 */
die "ohne viel Nachdenken" Version mit HAL lib: CS setzen..
1
voidEVE_cs_set(void)
2
{
3
HAL_GPIO_WritePin(GPIOF,GPIO_PIN_6,RESET);// set lo manually set chip-select to low */
4
}
5
6
voidEVE_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...
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:
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.
Hi, also wenn schon, dann mit DMA , sonst fehlt ja der Reiz.
(zu sehen, wie schnell das Ding wirklich ist)
Habe mir das ein wenig überlegt und es sollte eigentlich ohne Probleme
mit cache+optimizer gehen, weil es wird ja nur in den buffer geschrieben
und dann zum EVE gesendet, aber nie per DMA zurückgelesen.
wie muss ich das eigentlich machen: mit zusätzlichem " #define H7A3 "
und jeweils in " #if defined (STM32L073xx) ||...." entsprechend
DMA-Kanal usw ändern bzw rein schreiben ?
So, hilft zwar jetzt noch nicht direkt mit STM32, aber ich habe gerade
endlich mal meinen Entwicklungs-Zweig mit dem mit dem 5.x Zweig
synchronisiert.
Da ist jetzt zum einen die STM32H7 "Erweiterung" in EVE_target.h, zum
anderen ist jetzt das STM32 "Beispiel" enthalten.
Dieses Beispiel macht immer noch nichts sinnvolles, da in der main.c
nicht genug drin ist und DMA unterstützt das für STM32 auch immer noch
nicht.
Aber das baut einfach so durch für diverse STM32:
Environment Status Duration
------------- -------- ------------
STM32L073 SUCCESS 00:00:02.775
STM32F030 SUCCESS 00:00:02.468
STM32F103 SUCCESS 00:00:02.587
STM32F303 SUCCESS 00:00:03.115
STM32F446 SUCCESS 00:00:03.946
STM32G474 SUCCESS 00:00:03.678
STM32G431 SUCCESS 00:00:03.499
nucleo_f439zi SUCCESS 00:00:03.888
nucleo_h743zi SUCCESS 00:00:06.119
Damit wird zumindest schon mal der Code in der Library einwandfrei für
STM32 compiliert.
Nun habe ich wochenlang so diverse Bitmaps geladen und dargestellt
(teils zum Üben, aber dann hauptsächlich sinnvoll für bestimmte
Projekte), habe mit diversen Befehlen herumgespielt und es funktioniert
alles tadellos. Dank des EVE Screen Editors (V4.2.0) konnte ich so
manche "Geheimnisse" entschlüsseln bzw. mir im Vorfeld so dieses oder
jenes anschauen, ehe ich mühselig an der realen Platinen mit Koordinaten
und dergleichen herum probiere. Und so habe ich auch einfach mal den
Befehl CMD_GRADIENT im EVE Editor "entschlüsselt". Selbst wenn ich den
Co-Prozessor benutzen würde, müsste man sich den gewünschten Farbverlauf
ohnehin am EVE zurechtschieben und dann die Koordinaten übernehmen. Ich
habe mir dazu eine Bibliothek geschaffen, der ich vor Aufruf die entspr.
Werte für die 2 Farben, für TransformA-F, Source usw. übergebe und
fertig ist mein Wunsch-Farbverlauf, auch ohne Co-Prozessor.
Nun habe ich das erste mal eine Grafik 600 x 480 darstellen wollen. Das
Original (Lageplan ohne Kuller) sieht so aus. Nach dem Experimentieren
mit SIZE_H und SIZE_H (auch mit Hilfe des EVE schnell entschlüsselt) hat
es dann auch geklappt. Jedoch sah das Bild dann so aus
(ARGB1555zuARGB1555). Nach vielen diversen Versuchen mit verschiedenen
Formaten kam ich dann mal auf die glorreiche Idee, das Bild im Format
RGB565 darzustellen. Und siehe da, es sah aus, wie das Original. Also:
konvertiert als ARGB1555, aber dann als RGB565 darstellen !!! Gibt es
dazu eine Erklärung? Das ist mir vorher (mit Bildern < 511 Pixel) nie
passiert. Im Gegenteil: Hier sah das Bild eher so aus, wenn nicht
Konvertierungsformat gleich Darstellung. Nun ja, so geht es zwar, aber
ist doch merkwürdig!!???
Co-Prozessor: Hier fehlt mir jedoch noch eine Kleinigkeit. Schön wäre
es, wenn ich einen Spinner (der sich auch selbst im Hintergrund entspr.
"bewegt") darstellen könnte (z.B. während des Ladens der Grafiken). Ohne
Co-Prozessor hat man dabei (wenn man es "Zu Fuß" als mit DL-Befehlen
macht) sogar noch mehr Gestaltungsmöglichkeiten in Form, Größe, Farbe
... Jedoch bewegt der sich ja nicht. Es reicht hier leider nicht ganz,
die DL-Befehle so einzugeben. Dann entsteht eben nur der "stehende"
Spinner. Hier muss zum Schluss sicher noch ein ganz bestimmtes Register
gesetzt werden ...?????
Hast Du da eine Idee?
Nun möchte ich ja auch gleich wieder noch mehr: Den BT815 testen, um
auch 10 Zoll-Displays beschreiben zu können. Wie für den FT8... gibt es
hier auch diverse Demo-Boards. Jedoch habe ich kein Set mit
10-Zoll-Display gefunden. Im Gegensatz zum VM800, die es ohne und mit (7
Zoll) Display als Set gibt. Kennst Du so ein Set, oder ein passendes
10-Zoll-Display (Belegung des 50-poligen Flachbandkabels !!!) zu einem
entspr. Demo-Board?
Besinnliche Adventzeit !!! Liebe Grüße von der Ostsee.
Die Bildfrage kann man über das Forum eigentlich nicht mal versuchen zu
beantworten, da hier automatisch das Format von PNG Bildern konvertiert
wird, warum auch immer.
Wenn ich das runter lade und zum bearbeiten in Paint.net öffne hat das
schon mal gar keinen Alpha-Channel.
Das kann ja Absicht sein, aber ARGB1555 passt dann nicht wirklich.
Die Animation von dem Spinner dürfte der Co-Prozessor machen, an dem
vorbei dürfte das nicht gehen, da die Display-Liste an sich ja statisch
ist.
Und wenn man direkt die Display-Liste schreibt kann man auch die Daten
über den SPI nicht wirklich optimieren, Stichwort CMD_APPEND.
Die BT815 sind für 10" nicht ernsthaft geeignet, die haben nur eine PLL,
damit ist der Pixel-Takt nur durch feste Werte teilbar.
Bridgetek hatte zwar mal eine Demo, aber 60HZ hat die bei 1024x600 eher
nicht erreicht.
Das ist mit den BT817 viel schicker gelöst.
Das nächste Problem bei 10" ist das die meistens Displays jenseits von
800x480 inzwischen keine RGB Schnittstelle mehr, sondern LVDS haben.
Also muss da zu dem BT817 noch ein RGB/LVDS Converter mit drauf.
Ok, es gibt 1024x600 in 7", aber das fällt quasi unter exotisch.
Ich benutze ja ohnehin nur fertige Module, für den Fall würde sich das
aber denke ich auch zunächst anbieten.
In 10" habe ich ein RVT101HVBNWC00-B mit 1280x800 und in 7" habe ich ein
RVT70HSBNWC00-B mit 1024x600.
Die "-B" Version ist die höchste Variante mit optical bonding.
TME hat noch je 1 Stück, Mouser hat RVT70HSBNWC00.
Mein RVT101HVBNWC00-B habe ich direkt bei Riverdi gekauft, das hat dann
aber etwas mehr gekostet, da kam ordentlich Versand drauf.
Ach so, das RVT70H ist ohne LVDS, das RVT101H mit LVDS.
bei ali
10.1" LCD screen EJ101IA-01G (1280x800)
Kostet zwischen 24-34 EUR
Zum Testen von unterschiedlichen Displays habe ich mir ein paar kleine
Boards zusammengebaut.
1)Konverterplatine TTL-LVDS(50Pin->40Pin)
2)Spannungsversorgung-Platine für das Display
3)BT815/6/7/8 Board (mit BT817 bestückt)
Meistens aber nicht immer:
1024x Displays Benötigen 2) aber nicht 1)
1280x Displays Benötigen 1) 2)
je nach Display sind die Pins an den Flexprintbuchsen umzubelegen oder
umzulöten
Heads-Up: I am currently changing the return values for EVE_busy(),
EVE_init() and EVE_init_flash().
So far these three return an uint8 with a 0 for FALSE and a 1 for TRUE.
However, returning a zero on success is more common and also allows for
more meaningfull values to be returned on failure.
So far I have these:
1
enum
2
{
3
E_OK = 0,
4
E_NOT_OK,
5
EVE_FAIL_CHIPID_TIMEOUT,
6
EVE_FAIL_RESET_TIMEOUT,
7
EVE_FAIL_PCLK_FREQ,
8
EVE_FAIL_FLASH_STATUS_INIT,
9
EVE_FAIL_FLASH_STATUS_DETACHED,
10
EVE_FAIL_FLASHFAST_NOT_SUPPORTED,
11
EVE_FAIL_FLASHFAST_NO_HEADER_DETECTED,
12
EVE_FAIL_FLASHFAST_SECTOR0_FAILED,
13
EVE_FAIL_FLASHFAST_BLOB_MISMATCH,
14
EVE_FAIL_FLASHFAST_SPEED_TEST
15
};
You might wonder about the first two, this is a nod to Autosar
Std_ReturnType.
And I just pushed a small update.
EVE_busy() practically works like always with returning zero for not
busy but no longer 1 for beeing busy but EVE_IS_BUSY which currently has
a value of 12.
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
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...
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
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.
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
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.
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
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
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.
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
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.
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...
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.
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)
Spyy schrieb:> Wie kommt man denn jetzt mit porch vbp=15,vfp=12 und linetime 32µs auf> die Werte für den BT81x ?
Ähm, quasi gar nicht.
Auch wenn man die 60Hz dazu nimmt ist das doch nur raten.
Solche Erfahrungen habe ich mit nackten Panels bisher meistens gemacht,
also nicht praktisch, von den Daten her.
Entweder man findet gleich kein Datenblatt, das Datenblatt ist ein Witz
und enthält keine Timing-Informationen oder der Hersteller gibt die
Timing Informationen in seinem eigenen Format an, möglichst
unvollständig.
Ich habe ein Datenblatt von einem TFT-H040A1PVIST3N40 gefunden.
"Shenzhen Hot Display Technology Co.,Ltd" - ja, genau.
Unter "LCD display initialization code" steht der selbe seltsame Header.
Und ganz viele Daten die man per SPI an den Display-Controller schicken
soll - Schauder.
Nur richtige Timing Informationen gibt es im dem "Datenblatt" gar nicht.
Der Pixel-Clock darf bis 30MHz haben.
Da hilft nur zu versuchen was ähnliches zu finden, raten und
ausprobieren.
Vielleicht bringt es was zu entschlüsseln was dem ST7701S da eigentlich
im Detail alles geschickt wird.
+ für die Display Daten: habe gerade ein Riverdi TFT zum laufen
gebracht,
RVT70AQBFWR00, EVE3 TFT , 7" , 800 x 480 , res.touch (von rs 193-1167 ,
66€ ).
Einstellung (auch mit Werten von riverdi /git driver ) war nicht
korrekt, einige wundersame einzelne Pixel im Bild und eine blaue Linie
rechts am Rand;
so sieht das Bild fehlerfrei aus:
1
/* RVT70xQBxxxxx 800x480 7.0" Riverdi, various options, BT815/BT816 */
2
#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
3
#define EVE_HSIZE (800L) /* Thd Length of visible part of line (in PCLKs) - display width */
4
#define EVE_VSIZE (480L) /* Tvd Number of visible lines (in lines) - display height */
5
6
#define EVE_VSYNC0 (4L) /* 0 Tvf Vertical Front Porch */
7
#define EVE_VSYNC1 (8L) /* 13 10 Tvf + Tvp Vertical Front Porch plus Vsync Pulse width */
8
#define EVE_VOFFSET (13L) /* 23 Tvf + Tvp + Tvb Number of non-visible lines (in lines) */
9
#define EVE_VCYCLE (512L) /* 525 Tv Total number of lines (visible and non-visible) (in lines) */
10
#define EVE_HSYNC0 (0L) /* 0 Thf Horizontal Front Porch */
11
#define EVE_HSYNC1 (4L) /* 10 Thf + Thp Horizontal Front Porch plus Hsync Pulse width */
12
#define EVE_HOFFSET (28L) /*46 Thf + Thp + Thb Length of non-visible part of line (in PCLK cycles) */
13
#define EVE_HCYCLE (856L) // (1056L) /* Th Total length of line (visible and non-visible) (in PCLKs) */
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)
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
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.
>Was steht denn auf dem Aufkleber von wann das ist?
2141 , also vmtl Mitte 2021 hergestellt.
Ich habe in meinem "Testbild" mit den bewegten Dreiecken einen
Hintergrund mit Farbverlauf , der sieht auf dem Newhaven TFT perfekt
aus, auf dem Riverdi TFT sieht man ganz leichte Stufen in der Farbe, als
wäre das RGB zB 3 x 6bit statt 3 x 8bit ; oder gibts da noch was zum
Einstellen ?
+ wenn man "sehr schräg" aufs TFT guckt, sieht das bewegte Dreieck auf
dem Riverdi TFT eher "ruckelnd" aus, die Linien scheinen erst kurz
Schwarz und dann erst Gelb gemalt zu werden und dadurch etwas
"flimmern", beim Newhaven TFT sieht man davon nichts, einfach bewegte
gelbe Linien eben. Oder könnte das am Controller liegen, EVE2 -> EVE3
(im Riverdi TFT)?
+
zu den Widerständen in den Leitungen: die sind zur Vermeidung/Reduktion
von Reflexionen auf der Leitung; das MUSS sein, sobald die Leitung von
kräftig schnellen Treibern angesteuert wird. Das ist bei allen "neueren"
ARM chips so, bei den STM32 sind (im Cube) die Ports in 3 , 4 oder 5
Stufen in der Geschwindigkeit einstellbar; man sollte immer geringste
Geschwindigkeit einstellen, die für die benutzte Taktrate ausreicht, um
möglichst wenig Refexionen zu erzeugen. Ich mache "standardmässig" 51
Ohm in jede Leitung, zB zur SD-Karte (50 Mbit clock) oder zum TFT (SPI
mit 25 Mbit).
ZB mit max.port speed , ohne Widerstände drin, bekommt man gar keine
Verbindung zu einer SD-karte, so, als wäre sie kaputt !
Die Impedanz einer "einsamen" Leitung auf PCB über Massefläche liegt so
bei 50 Ohm, in einem Flachkabel dann her bei 120 ohm, also sollten die R
in der Leitung irgendwo zwischen 33 Ohm (bei USB üblich) und 150 Ohm (in
CD playern typisch) liegen; 50 ...100 sind ein guter Bereich.
zum Anschauen kurz simuliert: 20MHz , 3V Rechteck , auf ---->
10cm freie Leitung (hat etwa 100nH Induktivität), Ende an chip-pin (mit
5pF Streukapazität, angenommen);
(1. bild 2x , man kann es anscheinend nicht löschen...)
1. schneller port, 1ns rise/fall , dünnes Kabel (1 Ohm angenommen)
2. schneller port, 0.5ns , mit 100 Ohm in der Leitung
3. etwas "gebremster" port, 5ns , 1 Ohm
da kann man gleich sehen, warum ein Widerstand rein muss,
wenn die Leitung von schnellem chip angetrieben wird. :)
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
>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.
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.
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
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....
Spyy schrieb:> Noch ne Frage...warum kann man eigentlich "burst" und z.B. mem_read> (z.B. ins G Ram schreiben/lesen) nicht mischen ?
Da musste ich erstmal drüber nachdenken.
Bei den Targets die DMA unterstützen sollte das sogar eigentlich
funktionieren.
Nur auf die Idee gekommen bin ich noch nicht.
> Ich dachte wenn man burst startet und dann eine DL aufbaut macht man ja> erst nur den SPI Buffer voll und erst bei "Burt end" wird das alles per> SPI DMA aus dem Buffer weggeschickt...
Richtig, und Funktionen wie EVE_memRead8() sind in sich abgeschlossen
und kümmern sich auch nicht darum ob nun gerade Burst ist oder nicht.
Man muss nur aufpassen das man nicht direkt nach dem EVE_end_cmd_burst()
wieder was über den SPI schickt, so ohne EVE_busy().
Was anderes ist es wenn man ein Target ohne DMA Support hat, dann kann
man zwar auch EVE_start_cmd_burst() / EVE_end_cmd_burst() benutzen, das
bewirkt aber was ganz anderes, damit wird der SPI-Transfer direkt
gestartet und jedes Kommando schickt nur die Nutz-Daten ohne Adresse
vorweg.
Ein Arduino UNO hat ja zum Beispiel schon mal gar nicht die 4k SRAM die
für den Puffer benötigt werden.
Spyy schrieb:> danke für die Info...tja...was mache ich nun...ich habe ein PCB ohne R> in den SPI Leitungen und eigentlich kein Problem (mehr)...und ich habe> kein so tolles Oszi...und wüsste auch gar nicht so genau wie die Signale> bei 25 Mhz so aussehen müssten...> Die Leitungen vom Teensy zum EVE sind ca.3-4 cm lang....
Nun ja, erstmal ist das ein ganz anderes Problem, ich gehe ja von den
ganzen Eval-Boards mit fliegenden Leitungen weg auf meine
Adapter-Platine und dann hängt da noch das FFC zum Display dran.
Und dann könnstet Du einfach auf Verdacht die Geschwindigkeit der SCK
und MOSI Pins von der Default-Einstellung 7 auf was kleineres ändern,
der kleinste Wert eben der noch ohne Probleme funktioniert.
Und manchmal ist es auch gut den Stuss zu lesen den man selber
geschrieben hat. :-)
Als ich mich hierhin durchgeklickt habe bin ich ganz oben auf der Seite
gelandet und habe gesehen was ich im Juni letzten Jahres geschrieben
hatte.
Ich schrieb da oben, dass ich von 240R auf 150R runter gegangen bin und
dann 26MHz SPI mitsamt Touch benutzen konnte.
Ich schrieb auch, dass ich die Pin-Einstellung selber geändert habe, so
ohne Effekt, aber ich schrieb nicht wie weit ich mit der Einstellung
runter gegangen bin. Jetzt würde ich einen Wert von 3 oder 4 für
plausibel halten, so ohne extra Widerstände.
>dass ich von 240R auf 150R runter gegangen bin und> dann 26MHz SPI mitsamt Touch benutzen konnte
mit 150 R haste ja dann schon einen guten Wert gefunden :)
>ich habe ein PCB ohne R in den SPI Leitungen>Leitungen vom Teensy zum EVE sind ca.3-4 cm lang
da solltest du einfach die drive/speed auf einen kleinen Wert
einstellen, dann sollte das zuverlässig laufen; ich würde beim kleinsten
anfangen, 001, und sehen, ob es mit vollem Takt geht; wenn nicht, eben
010 versuchen.
anbei simu: kurze Leitung 25MHz mit 2mA drive - würde gut aussehen.
btw ein Beispiel: ich hatte mal ein Problem mit der Zuverlässigkeit
eines FPGA, clock 80MHz ; der Entwickler hatte "vorsichtshalber" den
Oszillator direkt neben das FPGA gesetzt, ca. 20mm Leitung, da denkt man
schon, das ist perfekt so. Etwa 50% der Boards liefen, die anderen
hatten diverse "Fehler", manche gingen bei Erwärmung nicht mehr, manche
gar nicht. Da sucht man alles Mögliche als Grund...
bis ich versuchsweise die 20mm Bahn mit Cutter aufgetrennt und nen 100 R
0805 SMD draufgelötet habe; dann liefen auch die "defekten" FPGA alle
problemlos.
(speed Einstellung ändern gabs hier natürlich nicht).
...oder auch - ganz selten - einfach richtig. :)
>>Probier das mal aus:
#if defined (EVE_RiTFT70) || defined (EVE_RiTFT50)
#define Resolution_800x480
#define EVE_PCLK (2L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 3
#endif
habe es versucht. Bild sieht (genauso) ok aus.
nur: compiler motzt ->
musste in EVE_commands das vorerst einfach raus kommentieren: Zeile 1313
// EVE_memWrite16(REG_TOUCH_RZTHRESH, EVE_TOUCH_RZTHRESH); /*
eliminate any false touches */ geht nicht ! undeclared !
touch (resistiv) geht aber gut (wie vorher).
Alf S. schrieb:> habe es versucht. Bild sieht (genauso) ok aus.
Super, danke, dann muss ich mir da mal was zu überlegen.
Alf S. schrieb:> nur: compiler motzt ->> musste in EVE_commands das vorerst einfach raus kommentieren: Zeile 1313
Dann hast Du noch eine alte Version, das habe ich Ende Dezember
umgebaut. :-)
Der Hintergrund ist das die Einstellung für kapazitiv-Touch Displays gar
nicht benötigt wird, stand aber in allen Profilen.
Wenn es nicht definiert ist wird jetzt 1200 geschrieben.
Ist es definiert weil 1200 für manche resistiv-Panels noch zu niedrig
ist, aber eben über die Projekt-Einstellungen, z.B. in der
platformio.ini, dann wird es auch wie gewohnt geschrieben.
Damit kann man das individuell anpassen ohne die EVE_config.h verändern
zu müssen.
nu, bzgl "wieso Reflexionen" bei den aktuellen CPUs auf den Leitungen:
hier mit Magnetfeld-sonde direkt am Flachkabel zum Riverdi TFT gemessen,
mit 51R in allen aktiven Leitungen und reduzierter pin-drive Einstellung
:(medium/low)
immerhin noch ganz ordentlich Oberwellen bis 2 GHz !
genau selbe Einstellung der STM32H7A3 CPU , aber mit dem TFT von
Newhaven, mit ca. 35cm Flachbandkabel dran. ca. 20dB weniger Oberwellen,
also :
vermutlich sind auf dem TFT von Riverdi keine Dämpfungswiderstände in
der SPI Leitung vom EVE chip; daher hat das heftige Abstrahlung, obwohl
von der H7A3 CPU her das Signal eigentlich gedämpft ist. (wie man beim
Newhaven TFT trotz des längeren Kabels ja gut sehen kann).
(btw die Uhrzeit vom Analyzer ist schon 6 Stunden vorne...warum auch
immer)
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...;-)
>also drive strenght runter UND 51R in die SPI Leitungen?
ja + CS auch ; (einfach...aus Prinzip.)
vmtl. sind auf dem TFT von Riverdi keine R in den Leitungen (der EVE
"sendet" ja auch , MOSI -> MISO ) und es sollte daher auch mit Rs nahe
am EVE chip gedämpft werden.
Riverdi bewirbt auf ihrer Seite ja die neuen EVE4 Displays, auch mit EMI
Messung dabei; bei den älteren EVE3 sehe ich davon nix (nur: Not
recommended for new design.)
anscheinend ist ihnen auch aufgefallen, dass die TFTs so einiges an HF
abstrahlen auf der SPI Leitung.
Spyy schrieb:> Ach wenn man doch Ahnung von dem hätte was man so macht...;-)
Ich ahne was, aber ich habe nicht mal ansatzweise die Messtechnik um
sowas aufzuspüren oder hätte die Erfahrung mit der Art von Messtechnik
richtig umzugehen. :-)
Spyy schrieb:> Sagt mal, weiss jemand ob es dann man einen EVE5 geben wird ?
Solange nichts angekündigt ist kann ich da nur hoffen.
Leider wird der Druck auf so ein Produkt immer größer, etwa durch
Mikrocontroller mit eingebautem Grafik-Interface.
Riverdi hat ja auch gerade ein 10.1" mit einem STM32H747XIH6
vorgestellt.
Bei den Preisen legt Riverdi allerdings im Vergleich zu den EVE4 Modulen
noch mal eine ordentliche Schippe drauf.
Für einen BT82x würden mir schon noch ein paar Dinge einfallen. :-)
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...
Nun, die H7 gehen glaube ich bei 280 MHz los und der RT1062 von dem
Teensy hat auch eine Grafik-Einheit.
Sowas Mikrocontroller zu nennen ist ja irgendwie pervers. :-)
In der Kategorie setzt man dann aber auch ein Betriebssystem ein, hat
Dutzende wenn nicht Hunderte Leute in dem Projekt und ein guter Teil der
Zeit geht für Prozesse drauf.
Ich meine ja nur, als FTDI 2013 mit den FT800 an den Start gegangen ist,
da sah die Controller-Landschaft noch anders aus.
Ich kenne auch immer noch keine Produkte die mit einem FT8xx oder BT8xx
im Laden stehen würden, also zumindest keine bei denen man 5 oder 6
stellige Mengen erwarten kann. Ich kenne nicht mal welche die ich nicht
nennen dürfte.
Eigentlich muss es die geben, sonst würde sich das ganze Spiel wohl eher
nicht lohnen, aber mir sind keine bekannt.
Ich weiß auch gar nicht so recht, was ich überhaupt von Bridgetek als
Firma halten soll, mein persönlicher Eindruck ist ja, dass der Laden
eher klein ist.
Dagegen sprechen aber zum Beispiel die ganzen Stellenausschreibungen.
Man versucht ja nicht 19 hauptsächlich Senior Stellen zu besetzen, wenn
man nichts zu tun hat.
Aber nun, Singapur, ich glaube da würde ich mich richtig fremd fühlen.
:-)
Also ich drücke die Daumen, dafür habe ich immer noch zu viel Spaß mit
EVE. :-)
>Ich kenne auch immer noch keine Produkte die mit einem FT8xx oder BT8xx
Ich vermute, die sind auch (wenn überhaupt) eher in ..siehe Bilder.
und bisher wohl einfach wenig bekannt und "zu ungewohnt" für die
Entwickler;
ich bin in der Firma auch der einzige, der ein neues Display dieser
"unbekannten Art" machen will.
und auf dem STM Forum, gehen die meisten lieber den Weg, den LCD
controller im Chip mit externem RAM aufzupeppen und dann mit zig
Leitungen ein RGB-LCD anzudengeln, statt sich mal mit dem EVE Zeugs zu
beschäftigen.
btw ich bin quasi (auch) Erfinder des EVE (eine meiner sinnlosen,
unbekannten Erfindungen...) : vor ca. 23 Jahren hatte ich zu Zeiten mit
den AVR rumgemacht und überlegt, wie man damit ein Farb-LCD ansteuern
könnte, ohne 1MB RAM buffer zu haben; da kam mir die Idee: der Rechner
hat nur ein paar Dinge darzustellen, Linien und paar Buchstaben, die er
live Zeile für Zeile berechnet und zum LCD shiftet. Kein Monster RAM
buffer mehr nötig. Leider natürlich auch (zu der Zeit) von den
verfügbaren CPUs her völlig unmöglich, 10x zu langsam.
gut, dass ich es nicht patentiert habe, hätte nur 10 Jahre Gebühren
bezahlt und kein Schwein hätte es haben wollen. :)
Da habe ich einen Moment Schnapp-Atmung bekommen. :-)
Ja, ich kann auch nur für FTDI/BRT hoffen, dass die EVE in solchen
Produkten verbaut werden.
Bridgetek hat ja auch entsprechende Bilder auf der Homepage.
Nur natürlich und leider werden die nicht ihre Kunden nennen.
Dicke Kaffee-Automaten und andere Luxus Küchengeräte auf Verdacht zum
Zerlegen zu kaufen ist auch nicht durchführbar. :-)
Wobei Automotive eher nicht so, zumindest nicht für ein Infotainment
Panel.
Die EVE sind nicht Automotive qualifiziert.
Wobei es sicher auch Hersteller gibt die sich davon nicht abhalten
lassen.
Immerhin hatte BRT in der Richtung auch schon Demos.
Das kanadische ATV von Theron fand ich spannend.
Aber xxxx Stück werden die davon ja eher auch nicht bauen.
Geil wäre ja mal sowas wie eine Wetterstation zu identifizieren die
einen FT800 drin hat und inzwischen über Pearl oder Pollin verramscht
wird.
AVR und Displays und so, ich erinnern mich da war mal was mit einem
übertaktetem M644 oder so.
Aber das muss dann ja schon später gewesen sein.
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.
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...
...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...
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 ;-)
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.
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)...
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...
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"...:(
Spyy schrieb:> Ich kann zwar die Koordinaten (alles *16) verwenden aber die Zahl> "springt in 16er Schritten"...:(
Da die Fonts am Ende auch Bitmap basiert sind und diese nur Pixelgenau
sind, denke ich geht unter Pixelgenau nix. Auch die ROM-Fonts sind nicht
Vektorbasiert...
Ich habe noch ein anderes interessantes Problem; ich kann tun was ich
will, bei einer langen Display-List fäng bei mir das Bild an zu
glitchen, sprich ich bekomme Artefakte und Ghosting von meinen Bilder
beispielsweise. Die magische Grenze scheinen 600 Kommandos in etwa zu
sein anbei mal ein Bild von meinem Problem (ohne Wurstfinger 560er DL,
mit Wurstfinger 650er DL)... Weiß jemand Rat?
Daniel S. schrieb:> Da die Fonts am Ende auch Bitmap basiert sind und diese nur Pixelgenau> sind, denke ich geht unter Pixelgenau nix. Auch die ROM-Fonts sind nicht> Vektorbasiert...
Das kann natürlich sein das Bilder davon ausgenommen sind, nur wäre dann
erst recht die Frage, warum man die per Default auf 1/16 Pixel
platzieren kann.
Ich habe gerade noch mal den Programming Guide durchsucht und keinen
Hinweis gefunden, dass das bei Bildern nicht funktionieren soll.
Aber auch nicht wirklich anders herum, auch wenn da "pixel precision"
steht.
Interessant fand ich aber noch das hier:
"5.98 CMD_ANIMFRAMERAM
Note: If the pixel precision is not set to 1/16 in current graphics
context, a VERTEX_FOMART(4) is mandatory to precede this command."
Äh, ok? Warum??
Daniel S. schrieb:> Ich habe noch ein anderes interessantes Problem; ich kann tun was ich> will, bei einer langen Display-List fäng bei mir das Bild an zu> glitchen, sprich ich bekomme Artefakte und Ghosting von meinen Bilder> beispielsweise. Die magische Grenze scheinen 600 Kommandos in etwa zu> sein anbei mal ein Bild von meinem Problem (ohne Wurstfinger 560er DL,> mit Wurstfinger 650er DL)... Weiß jemand Rat?
Also das kann ich jetzt nicht bestätigen, aber reize das in der Regel
auch nicht aus.
Bandbreitenprobleme mit dem externen Flash kann ich bestätigen, so etwa
mit großen Fonts aus dem Flash ohne Cache oder dicke Bilder.
Die Anzahl der Kommandos könnte ich auch gerade gar nicht nennen, vor
allem nicht in der Display-Liste, da ich ja über den Co-Prozessor gehe.
Wie viel von den 8k Display-Liste hast Du denn konkret belegt?
Wie viel schickst Du über den SPI bei einem Update und wie lange dauert
das, ist da genug Zeit vor dem nächsten Update?
Ich schicke in meinem aktuellen Projekt gerade 1416 Bytes per Update,
daraus werden zusammen mit dem per CMD_APPEND dazu gepackten Teil dann
2712 Bytes Display-Liste.
So, reichlich Text (interne Fonts), 9 Bilder, 1 Slider, drölf
Farb-Kommandos.
Ich bohre das gleich mal auf indem ich einen der Blöcke kopiere, 8 der
Bilder werden auch noch gedreht, so individuell, das sind jeweils ein
paar Kommandos.
Ach ja, BT815 und die Bilder liegen im RAM.
So, ich habe mal mein Projekt massiv mit Stuss überladen, kein Problem.
:-)
Die Display-Liste ist mit 8016 Bytes gefüllt, über den SPI gehen per
Update 3888 Bytes.
Der "Killer" für Display-Listen sind Buttons, einer in 3D hat mal eben
54 Kommandos, also in der Display-Liste selber, das kann man im EVE
Screen Editor sehen.
Das kann sogar wirklich sein das jedes 32 Bit Wort in der Display-Liste
ein Kommando ist, danach lasse ich gerade 2004 Kommandos laufen.
Alleine die Buttons sind ja schon 864.
Die Blöcke für die 48 Bilder haben jeweils 6 einfache Kommandos und 1
komplexeres Co-Prozessor Kommando, sagen wir halt 7 einfache, das wären
auch noch mal 336.
Das läuft hier die ganze Zeit fröhlich vor sich hin und die Elemente bei
denen ich den Touch auswerte tun auch weiter was sie sollen.
Ach ja, wenn ich zu viel mache bleibt das Display schwarz.
In einer vierten Textzeile oben reicht es nicht mehr für " lazy dog".
Wenn ich jetzt den Slider auf 5-stellige Drehzahl stelle komme ich auf
8188 Bytes in der Display-Liste und 3936 Bytes per Update.
Das Teil ist übrigens ein nebenbei Tool um per LIN angesteuerte Lüfter
auszuprobieren, also schwer Automotive. :-)
Ich habe auch einige Grafiken drin, ein paar Fonts (alles im RAM_G) dazu
arbeite ich viel mit dem Scissor Rectangle, zeichnen von Konturen mit
dem Stencil und dem anschließenden Füllen per Gradient. Arbeite
dahingehend also schon auch mit dem Co-Prozessor...
Es macht keinen Unterschied, ob ich das Bild alle 20 oder 200ms
refreshe. Auch kann ich anstatt alles per burst zu machen, alles polling
machen, das macht aber - außer dass es langsamer wird - keinen
Unterschied.
Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten
auf EVE_busy), per polling circa 20ms.
Edit:
Sorry und ich meinte die Anzahl an Kommandos, nicht die Größe der DL
Daniel S. schrieb:> Es macht keinen Unterschied, ob ich das Bild alle 20 oder 200ms> refreshe.
Also das ist schon mal gut.
> Auch kann ich anstatt alles per burst zu machen, alles polling> machen, das macht aber - außer dass es langsamer wird - keinen> Unterschied.>> Die das Erstellen der Page per Burst dauert circa 3-5ms (am ende warten> auf EVE_busy), per polling circa 20ms.
Was meinst Du jetzt mit Polling?
Jedes Kommando einzeln Plus ein busy()?
Solange man nicht versucht mehr als 4k auf einmal in den FIFO zu
schieben und dazu auch noch bei sehr schnellem SPI, schafft man es nicht
den FIFO überlaufen zu lassen mit einzeln geschickten Kommandos.
Der Unterschied zwischen Burst und einfach so sind nur die 3 Bytes
Adresse die pro Kommando gespart werden, das ist messbar in xx%, aber
nicht Faktor 4+. :-)
Was für einen Controller hast Du eigentlich und wie schnell ist der SPI,
das scheint relativ langsam zu sein.
> Edit:> Sorry und ich meinte die Anzahl an Kommandos, nicht die Größe der DL
Aber wie kommst Du auf die Anzahl der Kommandos?
Was genau meinst Du damit?
In der Display-Liste hat jedes Kommando 32 Bit, da war ich vorhin kurz
verwirrt weil ich nie mit der Display-Liste direkt arbeite, aber es gibt
wirklich keine Kommandos die länger sind.
Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten,
da müsste man schon die Befehle im Quelltext zählen weil die keine
einheitliche Größe haben.
Wie groß wird denn die Display-Liste?
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
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. :-)
Rudolph R. schrieb:> Was meinst Du jetzt mit Polling?> Jedes Kommando einzeln Plus ein busy()?
Jedes Kommando als "nicht-burst" und nach jeder Komponente (also mein
Button / Slider...) ein busy().
Rudolph R. schrieb:> Was für einen Controller hast Du eigentlich und wie schnell ist der SPI,> das scheint relativ langsam zu sein.
Ist ein ESP32 der mit 240MHz rennt. Der SPI Läuft mit 30 MHz
Rudolph R. schrieb:> Aber wie kommst Du auf die Anzahl der Kommandos?> Was genau meinst Du damit?
Sorry, das war einfach schlecht erklärt von mir. Ich habe mir zum testen
in EVE_end_cmd_burst(), EVE_dma_buffer_index ausgeben lassen. Dieser
zählt dann dementsprechend 560 - 650 ungefähr...
Rudolph R. schrieb:> Und für den Co-Prozessor im CMD-FIFO kann man das nicht direkt ableiten,> da müsste man schon die Befehle im Quelltext zählen weil die keine> einheitliche Größe haben.
Das stimmt, aber ist es nicht sogar wahrscheinlich, dass dieser bei ~600
Kommandos die 8k zum überlaufen bringt?
Spyy schrieb:> Wann (vor welchem Befehl) wartest Du mit Eve_busy ? end_burst?
Genau, ich warte auf EVE_busy() nach(!) end_burst.
Spyy schrieb:> Ist das nur wenn Du touch auf dem Screen machst?
Interessante Frage, ich versuch mal die DL so zu verlängern und schau ob
die Glitches auch ohne Touch auftreten.
Spyy schrieb:> wieviel Hz Widerholrate/Kontentupdate hast Du> denn?
Ich hab mich hier bisschen an Rudolphs Beispiel orientiert, lese alle
7ms die Touch Register aus und jedes 5. mal zeichne ich die Seite neu.
Dementsprechend fahre ich circa 28.5 Hz... eigentlich nicht viel. Dafür
sind meine Controls halt ziemlich aufwendig, allein ein so ein
Wippschalter hat knapp 180 Kommandos im worst-case.
ich probier mal bisschen weiter und melde mich :)
Folgendes hab ich probiert (ohne Erfolg):
1. das Display nicht anfassen -> programmatisch die Schalter auf
"touched" setzen. => Glitches sind weiterhin da
2. SPI Speed auf 20MHz runter, Zeichnen der Seite alle 100ms => Glitches
weiterhin da
3. REG_CMDB_SPACE während EVE_dma_busy auslesen nach end_burst -> circa
2k während der Glitches
Gibts was womit man langen text hiden kann? Ich hänge mal meinen code
für den Button an, vielleicht fällt jemandem etwas auf
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.
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. :-)
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.
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:
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. :-)
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". :-)
....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...
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. :-)
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...
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.
...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
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.
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
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.
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.
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
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.
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.
Hallo zusammen,
ich spiele gerade mit einem STM32F303 und einem EVE2 Display von
NewHeaven rum. (NHD-4.3-480272FT-CSXP-T)
https://newhavendisplay.com/4-3-inch-ips-480x272px-eve2-resistive-tft/
Ich habe die Funktionen spi_transmit und spi_recieve auf die HAL
Variante umgebaut. SPI Frequenz sind 4.5HMz.
1
staticinlinevoidspi_transmit(uint8_tdata)
2
{
3
HAL_SPI_Transmit(&hspi1,&data,1,50);
4
}
5
#endif
und
1
staticinlineuint8_tspi_receive(uint8_tdata)
2
{
3
uint8_tdain;
4
HAL_SPI_TransmitReceive(&hspi1,&data,&dain,1,50);
5
return(dain);
6
}
Ich lese erfolgreich die Chip ID 0x7C = 124. SPI Kommunikation sollte
also passen. Verbunden sind Display und Platine mit 20cm Flachband
Kabel.
Im Precpocessor habe ich "EVE_NHD_43" definiert. In der "EVE_config.h"
sind verschiedene Parameter angegeben, allerdings weniger als im
Datenblatt.
Das Display flackert immer nur ganz kurz wenn der "PDN Pin" betätigt
wird. Ansonsten passiert leider nichts.
Hab ich noch was übersehen? Muss ich die anderen Parameter aus dem
Datenblatt noch mit in die EVE_config schreiben?
@Rudolph: Viel vielen Dank das du diese Lib mit allen teilst, das
erspart sehr viel Zeit und Frust!
Edit: Ich rufe nur die TFT_init auf, aber die sollte ja zumindest die
Rechtecke und Kreise anzeigen.
Beste Grüße
Paul B. schrieb:> Ich habe die Funktionen spi_transmit und spi_recieve auf die HAL> Variante umgebaut. SPI Frequenz sind 4.5HMz.
Ok, gab es dafür einen besonderen Grund?
Der einzige Unterschied zu meiner Variante mit LL_SPI_TransmitData8()
ist ja das dadurch der Code langsamer wird, da mehr an sich überflüssige
Checks jedes Mal neu durchgeführt werden.
Also kann man sicher machen, ich wundere mich nur.
Paul B. schrieb:> Im Precpocessor habe ich "EVE_NHD_43" definiert. In der "EVE_config.h"> sind verschiedene Parameter angegeben, allerdings weniger als im> Datenblatt.
Nicht wirklich, unter dem Define Resolution_480x272 gibt es am Ende der
EVE_config.h noch einen ganzen Satz Defines, viele Displays verwenden
einfach die gleiche Konfiguration und so wird die ganze Datei deutlich
kompakter.
Paul B. schrieb:> Das Display flackert immer nur ganz kurz wenn der "PDN Pin" betätigt> wird. Ansonsten passiert leider nichts.> Edit: Ich rufe nur die TFT_init auf, aber die sollte ja zumindest die> Rechtecke und Kreise anzeigen.
Meine TFT_init() aus dem Beispiel zeigt gar nichts an, da wird nur das
Display initialisiert, so grundsätzlich, dann Backlight, Touch, Bilder
an EVE schicken und am Ende wird mit initStaticBackground() eine
Display-Liste generiert und in den Speicher von EVE geschrieben als
Fragment für spätere Benutzung.
Erst mit der TFT_display() wird was angezeigt, inklusive dem vorher
generiertem Fragment das ziemlich am Anfang mit EVE_cmd_append_burst()
in die Liste eingehängt wird.
Also einmal noch TFT_display() hinterher und es sollte was angezeigt
werden.
Paul B. schrieb:> @Rudolph: Viel vielen Dank das du diese Lib mit allen teilst, das> erspart sehr viel Zeit und Frust!
Gerne, ich hatte auch mit den Herausforderungen soweit viel Spaß. :-)
Ich hätte jetzt auch nicht gedacht, dass das Projekt immer noch läuft.
Rudolph R. schrieb:> Ok, gab es dafür einen besonderen Grund?
Ich habe die LL Libs auf die schnelle nicht zur Hand gehabt, daher bin
ich auf die HAL Version umgestiegen. Für die finale Anwendung würde ich
dann wahrscheinlich auf die LL gehen.
Rudolph R. schrieb:> Nicht wirklich, unter dem Define Resolution_480x272 gibt es am Ende der> EVE_config.h noch einen ganzen Satz Defines
Alles klar, soweit unter war ich gar nicht. Danke für die Aufklärung!
Rudolph R. schrieb:> Meine TFT_init() aus dem Beispiel zeigt gar nichts an
Dann hab ich das falsch verstanden, ich dachte das wäre schon so eine
Basic Anzeige dabei.
Rudolph R. schrieb:> Also einmal noch TFT_display() hinterher und es sollte was angezeigt> werden.
Danke, dass bringt mich schon mal einen Schritt weiter!
Jetzt sehe ich auch die EVE2 Demo mit dem Stern Logo. Leider sehe ich
sie nur für den Bruchteil einer Sekunde, genau dann wenn der PDN Pin per
"PDN_Set" auf LOW gesetzt wird. Ich kann das mit dem Debugger auch nicht
anhalten, es ist genau der Moment wenn er auf low geht wo ich kurz was
sehe.
Meine while Schleife ist ziemlich simple:
1
2
while(1)
3
{
4
TFT_init();
5
HAL_Delay(1000);
6
TFT_display();
7
HAL_Delay(1000);
8
}
Ich habe mir alle Spannungen direkt am Display mit dem Oszi angesehen
(5V und 3,3V), die brechen nicht ein oder ähnliches.
Das Vergrößern des Delays zwischen PDN_SET und PDN CLEAR brachte auch
nicht.
Hast du noch eine Idee?
Danke für deinen Support!
Das hatte ich zuerst auch probiert, da kam der DEMO Screen genau einmal
kurz aufgeblitzt (in der TFT_init bei PDN_SET) und auch nur dann wenn
ich zwischendurch die Spannung nicht weggenommen habe. Fürs Debugging
hab ich es dann alles in die "while" geschrieben.
Das bedeutet im Umkehrschluss, dass die Übertragung der Daten sauber
läuft. Beim zweiten durchlauf der TFT_init durch den kurzen Reset nach
dem Power Down zeigt er alle korrekt an und dann wird es wieder dunkel
--> er hat die Daten im Speicher und kurz nach dem Reset blitzt eben das
"letzte Bild" auf.
Auch der "warm start" funktioniert leider nicht. (PDN_SET und CLEAR sind
dabei auskommentiert)
1
EVE_cmdWrite(EVE_RST_PULSE,0U);// reset, only required for warm-start if PowerDown line is not used
So, jetzt noch mal von zu Hause und nicht vom Handy, aus irgendeinem
Grund konnte ich nicht "anonym" posten.
Zeig doch mal ein bisschen was von dem was Du da treibst. :-)
Ich weiß auch, dass ich kein STM32 Beispiel habe, zumindest kein
vollständig lauffähiges, vor allem habe ich bisher keinen Weg gefunden
den Controller über HAL zu initialisieren um somit das Beispiel für
mehrere Controller compilieren zu können.
Und generell war das lange Zeit unlustig an STM32 Controll heran zu
kommen.
Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts
anfangen, so funktional und ohne AECQ.
Aber, zitiert aus dem hier:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_STM32_RiTFT50_PlatformIO/src/main.c
1
int main(void)
2
{
3
uint8_t display_delay = 0;
4
5
HAL_Init();
6
// SystemClock_Config();
7
HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/200U); /*Configure the SysTick to have interrupts in 5ms time basis*/
8
9
// EVE_init_spi();
10
// EVE_init_dma();
11
12
TFT_init();
13
14
while(1)
15
{
16
if(system_tick)
17
{
18
system_tick = 0;
19
20
TFT_touch();
21
22
display_delay++;
23
if(display_delay > 3)
24
{
25
display_delay = 0;
26
27
TFT_display();
28
}
29
}
30
}
31
}
Das Projekt compiliert zumindest so quer durch die Familien:
Environment Status Duration
------------- -------- ------------
STM32L073 SUCCESS 00:00:01.173
STM32F030 SUCCESS 00:00:01.149
STM32F103 SUCCESS 00:00:01.154
STM32F303 SUCCESS 00:00:01.246
STM32F446 SUCCESS 00:00:01.495
STM32G474 SUCCESS 00:00:01.265
STM32G431 SUCCESS 00:00:01.258
nucleo_f439zi SUCCESS 00:00:01.499
nucleo_h743zi SUCCESS 00:00:01.686
Damit ist das meiste im Grunde genommen fertig, die ganze Low-Level
Geschichten mit dem SPI gehen ohne zu Murren durch den Compiler.
Von der Struktur ist das grundsätzlich so wie ein funktionierendes
Projekt laufen würde.
Allerdings, SystemClock_Config() ist dann sehr speziell.
Aber EVE_init_spi() sowie EVE_init_dma() gibt es immer noch nicht
richtig, spontan bekommen man das bestenfalls ohne DMA zu laufen wenn
man zumindest EVE_init_spi() auf das Projekt anpasst oder eben gleich
eine eigene Funktion verwendet.
Ich plane gerade eine Platine mit STM32G0B1, da wollte ich auch nebenbei
einen Display-Anschluss dran packen, zumindest die Controller habe ich
da.
Rudolph R. schrieb:> Zeig doch mal ein bisschen was von dem was Du da treibst. :-)
Ich lad das Projekt mal mit hoch, erstellt mit der offiziellen CUBE IDE
vo STM. Wenn du sowieso mal was mit STM machen willst ist das eventuell
der Trigger um die CubeIDE mal zu installieren :D.
Rudolph R. schrieb:> Ich weiß auch, dass ich kein STM32 Beispiel habe, zumindest kein> vollständig lauffähiges
Du machst das ja auch freiweillig und stellst alles zur Verfügung, da
erwartet keiner für jede µC Familie ein lauffähiges Beispiel! 95% sind
der Miete sind ja schon erledigt, dank deiner Lib.
Rudolph R. schrieb:> Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts> anfangen, so funktional und ohne AECQ.
Der Vorteil war bei STM32 "damals" die Preisansage. 32bit in LQFP48 für
1$, dass war damals schon was.
Es gibt für Automotive FuSi Anwendungen auch Controller von STM, aber
nur gegen Vorlage deiner DNA...ich hatte mal zwei SPC5 von STM in der
Mache aber Datenblatt und Co gabs nur mit der Firmen Mail Adresse und
CubeIDE und Co unterstützen die Teile gar nicht. Alles in allem zu viel
Initialaufwand für Privat. Mit dem U5 könnte es zumindest für FuSi
Anwendung außerhalb von Automotive wieder interessant werden. Der ist
auch zu 98% Pin Compatible mit dem F303 ;).
Dein Beispiel Code und mein Code unterscheiden sich nicht viel, ich hab
extra ein neues Projekt erstellt zum rumspielen mit dem F303 und dem
Display, daher verwende ich aus Faulheit einfach HAL_DELAY für die
Wartezeiten.
Sollte aber funktional keinen Unterschied machen zu deinem Beispiel mit
dem SysTick.
Wenn wir das Ganze zum Laufen bekommen kannst du das Projekt auch gern
mit hochladen/referenzieren für den STM32. Die Portabilität ist ja dank
HAL (und deiner cleveren defines) easy.
Viel kann es ja bald nicht mehr sein, ich hab auch noch ein das NHD 3.5
hier aus der selben Familie, dass zeigt genau das gleiche Verhalten.
Danke für deine Zeit!
Ich habe die STM32CubeIDE installiert. :-)
Und das Projekt baut auch.
Nur so "trocken" fällt mir da leider gerade nchts dran auf.
Hast Du einen Logic-Analyzer?
Und wie versorgst Du das Display überhaupt?
Nicht, dass der Controller einen Reset macht, weil die
Hintergrundbeleuchtung so viel Strom zieht, dass der Regler sich
abschaltet...
Hmm, NHD, irgendeines von denen liegt hier auch irgendwo herum, nach dem
ersten wollte ich aber keine mehr, das FFC mit 1mm Abständen und dem
fast kompatiblen Pinout fand ich extrem unlustig.
Ah, habs, NHD-3.5-320240FT-CSVX-CTP - gefällt mir gar nicht.
Aber nun, Newhaven hat das scheinbar aufgegeben, mit BT81x haben die
nichts.
Paul B. schrieb:> Rudolph R. schrieb:>> Nun, generell betrachtet kann ich mit den meisten STM32 auch nichts>> anfangen, so funktional und ohne AECQ.>> Der Vorteil war bei STM32 "damals" die Preisansage. 32bit in LQFP48 für> 1$, dass war damals schon was.
Tja, nun, ich habe gerade 7,03 Euro ohne Mehrwersteuer für STM32G0B1CET6
bezahlt, 48 Pins, ab 10 Stück liegen die bei 6,36 Euro.
Das ist auch nur ein Cortex M0+ mit 64MHz, aber Speicher wie ein M4.
Ein ATSAME51J19A-AU ist bei Mouser gerade für 5,76 € gelistet und
Digikey hat gerade sogar welche für 6,39€ das Stück bei 1 Stück.
Die können deutlich mehr, 64 Pins, haben einen 120MHz M4F, mehr SRAM und
das ist zwar nicht die AECQ Version, aber es gibt eine.
Paul B. schrieb:> Es gibt für Automotive FuSi Anwendungen auch Controller von STM
Ja schon, aber eben keine STM32.
SPC5 ist PowerPC, der e200 Core ist schon reichlich angestaubt und von
Freescale lizenziert. NXP hat die MPC5xx noch weiter geführt aber
inzwischen sind die bei der S32 Familie für Automotive mit ARM Kernen.
ST10 ist sowas von tot.
Und die Stellar sind zwar ARM aber Cortex M7 und ein eigenes Gemüse.
Ein SPC5 Board habe ich im Büro, bisher habe ich allerdings nicht
mitbekommen das meine Abteilung was mit dem Controller gemacht hätte.
Ein S32K144 Eval-Board liegt gerade vor mir.
Rudolph R. schrieb:> Nur so "trocken" fällt mir da leider gerade nchts dran auf.
Hmm, schade. Ich bau das Ganze jetzt noch mal "on the fly" auf mit einer
auf F303 umgelöteten BluePill. Ich habe den PORTC, PIN15 im verdacht. Da
hängt PDN dran und die Pins C13, C14 und C15 sind bei STM schwache
Sonderlinge.
Rudolph R. schrieb:> Hast Du einen Logic-Analyzer?
Nein, aber ein DSO mit Dekoder und Protokollfenster. Willst du was
bestimmtes sehen?
Rudolph R. schrieb:> Und wie versorgst Du das Display überhaupt?
Versorgt wird es über ein USB C Buchse, das USB Kabel hat offene Enden
und hängt an einem Labornetzteil mit 3A. Dahinter sitzt ein 400mA LDO
der auf 3,3V runter regelt. Mit Display zieht das ganze 120mA. Peakstrom
muss ich noch messen, aber Spannungseinbrüche gab es bisher keine
(Trigger auf 4.8V auf der 5V Leitung und 3.1V auf der 3,3V Leitung,
fallende Flanke). Gemessen wurde direkt am Connector des Displays, da
waren keine Einbrüche feststellbar.
Rudolph R. schrieb:> mit BT81x haben die> nichts.
Ist der BT81X so viel besser als der FT81X?
Rudolph R. schrieb:> Ah, habs, NHD-3.5-320240FT-CSVX-CTP - gefällt mir gar nicht.
Mir gerade auch nicht :D.
Rudolph R. schrieb:> Die können deutlich mehr, 64 Pins, haben einen 120MHz M4F, mehr SRAM und> das ist zwar nicht die AECQ Version, aber es gibt eine.
Ich bin mit dem Sprung von 8 auf 32bit von Atmel weg, eventuell wage ich
noch mal einen Exkurs. Bei STM32 fand ich halt die relative gute
grafische Konfigurationsoberfläche nett. Für jemanden der das
professioneller macht wahrscheinlich eher ein KO Kriterium als ein
Benefit.
Rudolph R. schrieb:> Ein S32K144 Eval-Board liegt gerade vor mir.
Bei NXP hab ich nach dem 1769 aufgehört, den hatten wir mal in der alten
Firma und ich musste die Leiterplatte um das Ding designen. Mehr als ein
Komponententest hab ich für das Ding nie programmiert, es wurden nur
alle Sensoren kurz mal angetriggert und die Daten per UART
rausgeschoben.
Ich melde mich wenn ich den neuen Aufbau habe, sag mir gern wenn du
konkrete Befehle hast die ich mal mitloggen soll.
Es läuft!
Es lag an PINC 15, einem der Sonderlinge. Ich habe die PINs getauscht
und jetzt läuft der Kollege.
Vielen Dank für deine Hilfe!
Wenn du noch etwas brauchst für dein git repo oder ähnliches, sag
einfach bescheid.
Paul B. schrieb:> Rudolph R. schrieb:>> Nur so "trocken" fällt mir da leider gerade nchts dran auf.>> Hmm, schade. Ich bau das Ganze jetzt noch mal "on the fly" auf mit einer> auf F303 umgelöteten BluePill. Ich habe den PORTC, PIN15 im verdacht. Da> hängt PDN dran und die Pins C13, C14 und C15 sind bei STM schwache> Sonderlinge.
Interessant.
Vor allem frage ich mich gerade warum PD scheinbar zappelt.
Paul B. schrieb:> Nein, aber ein DSO mit Dekoder und Protokollfenster. Willst du was> bestimmtes sehen?
Vorzugsweise den Reset-Event der nicht passieren sollte. :-)
Die Versorgung klingt erstmal stabil, ja.
Paul B. schrieb:> Ist der BT81X so viel besser als der FT81X?
Ich würde nur noch BT817 benutzen.
ASTC komprimierte Bilder machen einen großen Unterschied im benötigen
Speicherplatz, statt 16 Bit pro Pixel brauchen z.B. ASTC 8x8 Bilder nur
2 Bit pro Pixel.
Dann ist der etwas schneller getaktet und die BT817/BT818 haben eine
zweite PLL mit der man den Pixel-Takt viel feiner einstellen kann.
Das externe Flash ist sehr nett.
Und dann UTF-8 Zeichensätze, endlich Umlaute und Sonderzeichen einfach
so.
Paul B. schrieb:> Ich bin mit dem Sprung von 8 auf 32bit von Atmel weg
Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar
nichts.
Rudolph R. schrieb:> Interessant.> Vor allem frage ich mich gerade warum PD scheinbar zappelt.
Eine gute Frage, auf dem Oszi war nichts auffällig. Und mehr als 3mA
sollte der PDN vom FT ja nicht ziehen. Aber wie gesagt, die Pins sind
als Sonderlinge bekannt
Rudolph R. schrieb:> Vorzugsweise den Reset-Event der nicht passieren sollte. :-)
OK, hier:
;)
Rudolph R. schrieb:> Ich würde nur noch BT817 benutzen.
Danke, ich werde mich mal umsehen, nur so zum spielen.
Rudolph R. schrieb:> Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar> nichts.
Das stimmt, konnte ja damals keiner ahnen was das rennen macht, CAN-FD
oder Flex Ray. Da hat STM das gleich ganz weggelassen. Musste man dann
extern machen.
Die Maschine läuft, die Touch Kalibrierung ist auch durchgelaufen und
reagiert sauber.
Einige Fragen zum Workflow hätte ich noch.
Angenommen du willst ein ansehnliches HMI designen, nutzt du dann auch
den EVE Screen Designer von FTDI/BT?
Wenn ich mir den aktuellen ESD 4.X ansehe, dann kann ich da meinen FT812
gar nicht mehr anwählen. Heißt das ich muss auf den ESE, den EVE SCREEN
EDITOR 3.3 zurückgreifen und bin damit von der neuen Version des ESD
quasi ausgeschlossen?
Was würdest du empfehlen für das HMI design in zusammenhang mit deiner
Lib? (semi-professionell, ich mach das als Hobby).
Hast du einen guten Workflow/Toolchain die du weiterempfehlen kannst?
Paul B. schrieb:> Rudolph R. schrieb:>> Ich bin mit CAN-FD von AVR 8-Bit weg und da gab es für den STM32 gar>> nichts.>> Das stimmt, konnte ja damals keiner ahnen was das rennen macht, CAN-FD> oder Flex Ray.
Hmm, das habe ich anders in Erinnerung. :-)
Der CAN-FD Standard war Ende 2015 fertig und da gab es FlexRay schon ein
paar Jahre. Das Datenblatt vom TJA1080 ist zum Beispiel von 2007.
FlexRay war quasi schon tot bevor es CAN-FD gab. :-)
> Angenommen du willst ein ansehnliches HMI designen, nutzt du dann auch> den EVE Screen Designer von FTDI/BT?
Nein, mit dem habe ich mich bisher nicht anfreunden können.
> Wenn ich mir den aktuellen ESD 4.X ansehe, dann kann ich da meinen FT812> gar nicht mehr anwählen.
Ich habe gerade ESD 4.15.1 gestartet und konnte da ein Display mit FT812
auswählen. Nur weiter als das komme ich spontan nicht wirklich.
Und die FT_Eve_Hal Library die da drunter liegt war mal der Grund warum
ich meine Library angefangen habe. :-)
Wobei die heute anders aussieht, das sieht zum Teil vertrauter aus, wie
kommt das nur? Breit grins. :-)
Ich muss da mal wieder rein schauen, aber von dem was ich spontan so
gesehen habe möchte ich dafür meine Library nicht aufgeben.
> Heißt das ich muss auf den ESE, den EVE SCREEN> EDITOR 3.3 zurückgreifen und bin damit von der neuen Version des ESD> quasi ausgeschlossen?
Der Screen Editor steht bei 4.4.0.
> Was würdest du empfehlen für das HMI design in zusammenhang mit deiner> Lib? (semi-professionell, ich mach das als Hobby).> Hast du einen guten Workflow/Toolchain die du weiterempfehlen kannst?
Nein, ich werde neben meinem Hobby die Lib zu pflegen zwar gelegentlich
dafür bezahlt ein Projekt mit einem Display zu machen, der Level ist
allerdings Tools und Proto-Typing. Das heisst ich kann mich da ohne
formale Anforderungen oder Prozesse dran austoben und es geht oft nur um
ein einziges Exemplar.
Also der Teil der in der Entwicklung Spaß macht. :-)
Vor Weihnachten hatte ich so ein Projekt, da musste eine Komponente mit
LIN angesteuert werden ohne offen zu legen wie man das macht.
Statt einer CANoe Simulation mit LDF dazu habe ich das in ein 5"
"Tablett" gegossen, wobei das "Tablett" ein EVE3-50G in einem 3D
gedrucktem Gehäuse mit einer Platine von mir ist die 2x CAN-FD und 2x
LIN hat.
Das HMI besteht da nur aus einem Screen, so mit Firmen-Logo, ein paar
eigene Buttons, einem Slider und Text.
Das ist vom Code her sehr dicht an meinem Beispiel-Programm und das HMI
habe ich da entsprechend einfach so runter programmiert.
Die Kollegen waren begeistert wegen der sehr spontanten Umsetzung mit
wenigen Tagen Vorlauf, der Kunde der damit spielen durfte war
begeistert, weil es eben "einfach so" lief, so spontan an und ohne
Noteboook. Und ich hatte Spaß daran das umzusetzen.
Viel Text um zu sagen das ich gar keine HMI Entwicklung in dem Sinne
mache. :-)
Ein 10.1" habe ich schon im Büro liegen, das wartet noch auf das
Gehäuse, das HMI dafür werde ich wohl als Skizze auf einer Serviette
erhalten. :-)
Rudolph R. schrieb:> CMD_KEYS liefert den ASCII Wert als TAG zurück.> Das dürfte auch einer der Gründe sein warum das kein UTF-8 unterstützt.
Danke für die Info, ich hab gar keine Mail bekommen das du geantwortest
hast. Komisch. Ich habe es dann über einzelne Buttons gelöst.
Ich hab mal auf deinen Rat gehört und mir ein RVT50HQBNWC00 mit BT817
gegönnt. Das passende #define habe ich eingebunden (EVE_RVT50H), Chip ID
lesen klappt auch (124 dec).
Allerdings bleibt der µC in der "EVE_busy()" kleben. "space" wird immer
mit "0" zurück gegeben. Unregelmäßig kommt auch mal "59823" zurück und
er führt den Code aus um den CoProcessor wieder ans laufen zu bringen.
Hatte das schon mal jemand bei EVE4?
Vielen Dank!
Also so grundsätzlich habe ich mit dem RVT50HQBNWC00 soweit keinen
Stress gehabt, aber ich habe auch keinen STM32F303 mit dem ich das
testen könnte, der STM32 Teil ist auch ohnehin mal dran überarbeitet zu
werden.
Ich habe hier einen Prototyp einer Platine mit STM32G0B1 hier auf das
ich einen Display-Anschluss designed habe, bisheriger Stand ist
allerdings noch das die LED plausibel blinkt und der externe Oscillator
so nicht funktionieren kann.
Und am Mittwoch habe ich in Nürnberg noch ein STM32C0 Nucleo
abgegriffen, also das ist in der Pipeline das ich was damit mache. :-)
Kannst Du das mit irgendeinem anderen Board testen und wenn es ein UNO
ist?
Nach zähem Ringen mit den STM32 HAL Funktionen läuft die angehängte
Software gerade auf meinem erstem eigenen STM32 Board auf dem ein
STM32G0B1 bestückt ist und einem RVT50HQBNWC00.
Ich habe erstmal mit STM32CubeIDE ein Projekt erstellt und die
SystemClock_Config(), MX_GPIO_Init() sowie MX_SPI1_Init() in meine
main.c kopiert.
Und dann habe ich die MX_SPI1_Init() noch um die Konfiguration der SPI
Pins erweitert die blöderweise nicht mit generiert wird, obwohl die Pins
eingestellt sind.
Das nutzt jetzt noch nicht den Code aus EVE_target.c, da war ich noch
nicht dran. Und DMA nutzt das auch nicht.
Die EVE_target_STM32.h hat noch das Problem das sich die Parameter gar
nicht wie vorgesehen von "Außen" über Defines einstellen lassen.
An meiner EVE Library habe ich jetzt praktisch nichts geändert, in der
EVE_target.h wird auf "STM32G0" geprüft, in der EVE_target_STM32.h auch
noch mal.
Und in der EVE_target_STM32.h werden die HAL Includes für das Target
gezogen.
In der speziellen main.c ist alles drin damit der Controller
grundsätzlich läuft, so wie das eigentlich sein soll.
Was noch "fehlt" ist einen Timer zu benutzen um die Laufzeit der beiden
Funktionen in µs zu messen.
Im Logic-Analyzer sehe ich das ein Display-Update gerade 290µs dauert.
Zum Vergleich habe ich die spi_transmit() gerade mal auf
HAL_SPI_Transmit() umgestellt, damit dauert das exakt gleiche Display
Update satte 2,332 ms, statt so 3xx ns zwischen den Bytes hat man mit
HAL_SPI_Transmit() >10µs -> nicht zu empfehlen.
Für heute hatte ich damit aber erstmal genug Spaß. :-)
Hey Rudolph,
coole Sache das du an der STM Unterstützung dran bist :).
Deine Lib hast du also quasi nicht angefasst, bis auf den G0 Teil.
Komisch, bei mir läuft es immer noch nicht. Ich habe leider kein anderes
Board da zum testen (es mangelt am Display Anschluss).
SPI Frequenz hab ich auch schon auf unter 1 MHz runter gedreht, ohne
Erfolg. Ich komme aus der EVE_busy nicht raus. Das Display ist neu,
glaube kaum das das kaputt ist. Lesen der Chip ID und setzen des
Backlights klappen problemlos.
Was schickst du in deiner EVE_Init? Auch die 0x46? Ich fand das
Datenblatt an der Stelle etwas verwirrend.
"2 to 6 times the osc
frequency (i.e., 24 to
72MHz with 12MHz
oscillator)"
1
#if EVE_GEN > 2
2
EVE_cmdWrite(EVE_CLKSEL,0x46U);/* set clock to 72 MHz */
3
#endif
Zumal die Clock Frequenz ja kurze Zeit später noch mal ins Register
geschrieben wird:
1
/* tell EVE that we changed the frequency from default to 72MHz for BT8xx */
2
#if EVE_GEN > 2
3
EVE_memWrite32(REG_FREQUENCY,72000000UL);
4
#endif
Hast du noch eine CLK_FREQ in der config.h mit hinzugefügt? Welche PCKL
hast du eingestellt? 3?
Danke!
Paul B. schrieb:> Deine Lib hast du also quasi nicht angefasst, bis auf den G0 Teil.
Ja, und die Änderungen sind eingecheckt, das Projekt da oben holt sich
die Library aus Github.
Ich musst nur mal den Cache von PlatformIO löschen damit das neu geladen
wird.
> SPI Frequenz hab ich auch schon auf unter 1 MHz runter gedreht,
Ich bin auf 8MHz aber ich habe auch meine Adapter-Platine dazwischen.
> Ich komme aus der EVE_busy nicht raus. Das Display ist neu,> glaube kaum das das kaputt ist. Lesen der Chip ID und setzen des> Backlights klappen problemlos.
Welchen Rückgabewert liefert EVE_busy?
Eigentlich sollte die Abfrage praktisch immer E_OK, also Null zurück
liefern.
> Was schickst du in deiner EVE_Init? Auch die 0x46? Ich fand das> Datenblatt an der Stelle etwas verwirrend.>> "2 to 6 times the osc> frequency (i.e., 24 to> 72MHz with 12MHz> oscillator)"> #if EVE_GEN > 2> EVE_cmdWrite(EVE_CLKSEL, 0x46U); /* set clock to 72 MHz */> #endif
Ja, BT81x setze ich immer von den Default 60MHz auf 72MHz hoch.
> Zumal die Clock Frequenz ja kurze Zeit später noch mal ins Register> geschrieben wird:/* tell EVE that we changed the frequency from default> to 72MHz for BT8xx */> #if EVE_GEN > 2> EVE_memWrite32(REG_FREQUENCY, 72000000UL);> #endif
Das ist um dem Co-Processor mitzuteilen was eingestellt wurde.
Warum auch immer man das tun muss.
> Hast du noch eine CLK_FREQ in der config.h mit hinzugefügt? Welche PCKL> hast du eingestellt? 3?
Ich habe die Konfiguration nicht verändert.
Ohne EVE_PCLK_FREQ und mit EVE_PCLK auf 3 kommt das Display mit den
restlichen Parametern auf 59,3 Hz.
Ich hatte zuerst die Konfiguration für das EVE3_50G aktiv, damit lief
das RVT50H auch grundsätzlich, nur sicher ohne Touch, weil ein anderer
Touch-Controller konfiguriert wird.
Rudolph R. schrieb:> Welchen Rückgabewert liefert EVE_busy?
ich lese den Wert "space" immerm mit "0" zurück, obwohl es "0xffcU" sein
sollte. Damit springt er dann in den letzten "else" Zweig und liefert:
EVE_IS_BUSY (12) zurück. Damit hänge ich in der while von
"EVE_excute_cmd" fest:
1
voidEVE_execute_cmd(void)
2
{
3
while(EVE_busy()!=E_OK)
4
{
5
}
6
}
Rudolph R. schrieb:> EVE3_50G aktiv, damit lief> das RVT50H auch grundsätzlich
Hab ich auch probiert, gleiches Ergebnis. Bei dem GEN2 Display was ich
hier habe (NHD43) klappt das rücklesen von "space" problemlos mit
0xffcU.
Hmm, ja, das macht soweit gerade keinen Sinn.
Wie sieht der SPI traffic zu dem EVE_busy() denn aus?
Das müsste so aussehen:
MOSI: 0x30 0x25 0x74 0x00 0x00 0x00
MISO: 0x00 0x4a 0x43 0x42 0xfc 0x0f
Da Du "nur" ein Oszi hast würde ich dazu gerne mal ein paar Bilder
sehen.
Und wenn das in EVE_execute_cmd() hängt, was wurde dann davor
ausgeführt?
Hängt das am Ende von EVE_init() oder später?
Rudolph R. schrieb:> Wie sieht der SPI traffic zu dem EVE_busy() denn aus?
Kann ich dir leider erst morgen liefern, bin noch unterwegs.
Rudolph R. schrieb:> Und wenn das in EVE_execute_cmd() hängt, was wurde dann davor> ausgeführt?
Nur das was in der INIT steht (hab nur den Backlight Wert angepasst,
damit ich überhaupt eine Reaktion sehe)
Rudolph R. schrieb:> Hängt das am Ende von EVE_init() oder später?
Ja, genau da.
Paul B. schrieb:>> Hängt das am Ende von EVE_init() oder später?>> Ja, genau da.
An der Stelle passiert aber quasi gar nichts, es gab noch kein
Co-Processor Kommando und das Programm kommt da nur an wenn alle
Einheiten signalisieren, dass sie aus dem Reset sind.
Da steht das praktisch nur pro-forma drin, daher mache ich da auch gar
keine Fehler-Reaktion.
Was mir noch aufgefallen war, ich habe DELAY_MS() auf HAL_Delay(ms)
umgebogen und damit etwas zu kämpfen gehabt.
Ich hatte erst einen eigenen SysTick_Handler(), der konnte so aber nicht
funktionieren.
Dann habe ich das mit der HAL Implementierung probiert, wo auch immer
die vergraben ist, wollte auch nicht so recht.
Am Ende habe ich das wieder selber implementiert, aber erweitert:
void SysTick_Handler(void)
{
system_tick = 42;
HAL_IncTick(); /* needed for HAL_Delay() to work */
}
Das HAL_Delay() braucht HAL_IncTick().
Aus dem Grund musste ich auch meinen "Scheduler" umbauen, von den 5ms
Ticks die ich sonst benutze auf 1ms Ticks die von HAL_Init() eingestellt
werden.
RamDL "mitten drin" beschreiben:
Hallo Fan-Gemeinde. Hat schon mal jemand den RamDl nicht an der
Startadresse beginnend (30.000) beschrieben, sondern mitten drin?
Hintergrund:
Ich schreibe ein komplettes Bild mit diverser Grafik, was ja je nach
Umfang doch immerhin beim Schreiben per SPI einige Millisekunden dauern
kann.
Bei einer zeitkritischen Anwendung kann das stören.
Nun muss das komplette Bild aber nur (nach dem ersten Setzen) immer mit
2 Messwerten verändert werden. Diese Werte schreibe ich ganz am Ende der
List. Vorher zähle ich den RamDL mit und springe dann, wenn besagte
Werte geändert werden sollen an diese Stelle und öffne eine neue List
mit RamDl = zuletzt benutzte Adresse. Das funktioniert so weit auch
alles richtig gut! Zur Aktualisierung dieser Werte am Bildschirm
benötige ich nun nur noch 500µs!
Am Ende schreibe ich natürlich noch in den REG_DLSWAP die 2. Und der
neue Wert erscheint am Bildschirm. ABER mit jedem REG_DLSWAP springt die
Anzeige zwischen dem 1. Wert, den ich auf diese Weise geschrieben habe
und dem neuesten hin und her. Also z.B. 1. Wert = 1, wird angezeigt.
Dann ist der Wert = 2, Bild springt auf 2, nächster Wert ist 3 aber
Anzeige springt auf 1. Dann kommt Wert = 4, Anzeige springt auf 4, mit
nächster Aktualisierung wieder auf 1 ... Erhöhe ich die
Aktualisierungsfrequenz von eben ca. 100ms auf 5ms SCHEINT es zu
funktionieren. Da sich die Werte dann aber so extrem schnell ändern, ist
das nicht ganz klar erkennbar.
Ähnliches Vorgehen hatte ich schon mal bei einem Stellpult mit
Schiebereglern angewendet. Um das Schieben der Steller flüssig zu
gestalten, habe ich die gesamte Grafik an den Beginn gesetzt und nur die
Schieber selbst dann am Ende per Sprung in den RAMDL an zuletzt benutzte
Position (vor Beginn des Setzens der Schieber) gesetzt. Durch das nun
sehr schnelle Beschreiben des Bildes, bewegen sich die Schieber
schneller.
Erst sprang das komplette Bild zwischen dem zuletzt gesetzten Bild und
der Regler-Ansicht hin und her (natürlich extrem schnell). Erst nachdem
ich das Bild 3 mal beim ersten Sprung in das Regler-Menü gesetzt hatte,
funktionierte es auch mit den Schiebereglern.
Mit REG_DLSWAP = 1 hatte ich es auch schon versucht. Ändert sich nichts.
Mit jedem REG_DLSWAP springt doch der FT813 zwischen seinen 2
Ringspeichern hin und her und führt immer gerade einen aus, während man
den anderen "in Ruhe" beschreiben kann. Warum scheint es so, dass in
diesem Fall, immer nur EIN Ringspeicher beschrieben wird?
Äh, ich bin nicht sicher was da schief läuft, ich schreibe nie in die
Display-Liste, ich lasse nur die "Coprocessor Engine" in die Liste
schreiben.
Auf jeden Fall ist RAM_DL schon mal kein Ring-Speicher, das gilt nur für
RAM_CMD.
Entsprechend beginnt die Liste immer bei 0x300000 und man kann nicht
über das Ende hinaus schreiben und automatisch wieder am Anfang landen.
>und öffne eine neue List mit RamDl = zuletzt benutzte Adresse.
Der Part ist mir nicht klar, sowas geht gar nicht in dem Sinne.
Der Bereich RAM_DL ist doppelt vorhanden, die 8kiB die man gerade sehen
kann sind der inaktive Teil.
Und mit REG_DLSWAP = 2 wird getauscht, die 8kiB die man gerade
bearbeitet hat sind weg und aktiv, die 8kiB die eben noch für die
Generierung des Bildes verwendet wurden sind inaktiv und erreichbar.
Also um das zu manipulieren müsste man erstmal die Liste zwei Mal
schreiben.
Und einfach mal mit dem EVE Screen Editor hingeworfen ergibt zum
Beispiel
CLEAR(1, 1, 1)
CMD_NUMBER(642, 353, 28, 0, 42)
Das hier:
Raw Text
0 0x26000007 CLEAR(1, 1, 1)
1 0x22000000 SAVE_CONTEXT()
2 0x27000002 VERTEX_FORMAT(2)
3 0x0500001c BITMAP_HANDLE(28)
4 0x1f000001 BEGIN(BITMAPS)
5 0x06000034 CELL(52)
6 0x45040584 VERTEX2F(2568, 1412)
7 0x06000032 CELL(50)
8 0x451c0584 VERTEX2F(2616, 1412)
9 0x23000000 RESTORE_CONTEXT()
10 0x00000000 DISPLAY()
Um die angezeigt Zahl zu ändern müsste man also nur wissen wo die im
Speicher steht und die 0x34 und 0x32 auf die passenden Werte ändern.
Dann REG_DLSWAP = 2 und man sieht es auf dem Schirm und hat die
vorherigen Werte im Speicher.
So, jetzt stehen da noch haufenweise Kommandos vor diesem Block die sich
nie ändern sollen.
Zum Beispiel so im Coprozessor-Format:
CLEAR(1, 1, 1)
POINT_SIZE(100)
BEGIN(POINTS)
VERTEX2F(5760, 3408)
END()
BEGIN(LINES)
VERTEX2F(6112, 5312)
VERTEX2F(7776, 4992)
VERTEX2F(9424, 2656)
VERTEX2F(3888, 5456)
END()
BEGIN(RECTS)
VERTEX2F(10032, 1904)
VERTEX2F(10736, 3600)
VERTEX2F(9088, 4560)
END()
CMD_NUMBER(642, 353, 28, 0, 42)
Dazu lasse mir vom Coprocessor eine Display-Liste erzeugen ab
POINT_SIZE() bis vor CMD_NUMBER(), kopiere die per CMD_MEMCPY aus RAM_DL
nach RAM_G und dann lasse ich den Coprocessor dieses Fragment beim
Generieren der nächsten Display-Liste per CMD_APPEND mit in die neue
Liste kopieren.
CLEAR(1, 1, 1)
CMD_APPEND(0x12345, 42)
CMD_NUMBER(642, 353, 28, 0, 42)
Das ist in meinem Beispiel-Programm drin, siehe initStaticBackground().
Ich nutze das nicht so aggressiv, da für den Transfer ohnehin meistens
DMA verwende und ich das Update "nur" alle 20ms machen lasse (darf auch
nicht zu schnell sein, sonst flackert das).
Der Vorteil ist, dass ich gar nicht wissen muss wo irgendwas in RAM_DL
landet und trotzdem nicht immer alles neu schicken muss.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg
Der komische Stern (bzw. natürlich die Kommandos den aus dem Speicher
anzuzeigen), der Button und die Messwerte werden immer geschickt, der
Rest nicht.
Sorry, aber mit dem Co_Prozessor komme ich (immer) noch nicht klar.
Meine eigene Software auf meine Art hat sich seit Jahren bewährt...:):).
Ich öffne die SPI schreibe die Startadresse Hx300000 (natürlich sendet
man HxB00000 für "Schreiben"). Dann sende ich Befehl für Befehl jeweils
4 Byte (32 Bit). Die Daten werden automatisch jeweils in die
nachfolgende Speicherzelle des RamDL geschrieben. Am Ende der
Befehlsliste wird CS wieder auf High gezogen, um anschl. sofort wieder
auf Low zu ziehen, um das Register REG_DLSWAP mit 2 zu beschreiben...
OK, ob nun Ringspeicher oder nicht. Richtig, soweit ist mir das auch
klar, dass es den RamDL 2 x gibt und jeweils mit REG_DLSWAP getauscht
wird und das ich den natürlich nicht "überschreiben" darf (also über 8kB
hinaus).
Nach dem Öffnen (SPI) und der Staradresse 30.0000 zähle ich nun jeden
Befehl mit. Nach 2000 Befehlen wurde also der letzte Befehl in den
Speicher Hx30.0000 + (Dx2000 x 4), also in 301F3C bis 301F3F
geschrieben. Also muss Befehl 2001 in den Speicher 301F40 rein, was ja
nun automatisch passieren würde! Hier startet nun das Setzen meiner zu
aktualisierenden Werte Messwerte. Setze ich also das gesamte Bild, fahre
ich hier weiter fort. Wenn ich NUR die Werte aktualisieren möchte ohne
den ganzen Bildschirm dabei neu schreiben zu müssen, Öffne ich die SPI
und beginne mit dem Schreiben der Adresse Hx301F40 und den folgenden
restlichen Befehlen (die Werte auf den Bildschirm bringen), endend mit
REG_DLSWAP = 2. Das meine ich mit "und öffne eine neue List mit RamDl =
zuletzt benutzte Adresse".
Warum aber wird nun einer der beiden Speicher nicht überschrieben,
obwohl ich doch jedes mal mit REG_DLSWAP tausche???
Bernd I. schrieb:> Warum aber wird nun einer der beiden Speicher nicht überschrieben,> obwohl ich doch jedes mal mit REG_DLSWAP tausche???
Mal davon ab, dass in Deiner Beschreibung immer noch fehlt, dass Du die
Display-Liste initial zwei Mal komplett beschreibst, was Du vermutlich
aber getan hast, ich sehe gerade keinen Grund, warum das so nicht
funktionieren sollte.
Das mag zwar umständlich sein, aber durchaus zulässig.
Hmm, ich muss das mal ausprobieren. :-)
Ich habe das gerade ausprobiert, das Ergebnis hängt an.
Hier läuft gerade von einem Arduino UNO aus ein Punkt über den
Bildschirm.
Ich schreibe zwei Mal die gleiche Display-Liste:
Da ist jetzt nicht ein CoProcessor Kommando drin und das läuft einfach.
Sicher, das Beispiel ist etwas wenig komplex, aber so grundsätzlich tut
das halt was es soll.
Edit: mir ist gerade noch aufgefallen, das schreibt jedes Kommando für
sich und nicht nur einmal die Adresse.
Das sollte keinen Unterschied machen, ist nur langsamer.
Klar scheibe ich das Display zunächst 2 mal, bevor man dann das eine
Detail am Ende aktualisieren kann. Das Beispiel mit den 2000 Befehlen
(mal 4 Byte = 8k) war auch unüberlegt. Dann wären wir ja schon über den
erlaubten 8k. Also nehmen wir mal an, es sind nur 500 Befehle...
Aber ich sehe, Du hast das Prinzip, worum es mir geht, richtig
verstanden. Und ich verstehe ebenso wie Du nicht, warum das so
merkwürdig funktioniert.
In Deiner List schreibst Du in Adresse 28 vor dem DL_SWAP noch den
DL_DISPLAY, wie es sich gehört. So weit , so gut. Aber wenn Du dann die
Koordinaten des Punktes in Adresse 24 aktualisierst, führst Du anschl.
NUR den DL_SWAP aus, ohne das DL_DISPLAY davor. Muss ich nachher gleich
mal ausprobieren, ob sich dadurch etwas ändert!!!
Hallo Rudi,
Du hast ja soooo Recht!!! Natürlich gibt es keinen vernünftigen Grund,
warum es nicht funktionieren sollte! Es sei denn...
Ich schreibe die List und setze schon mal den RamDL auf HxB0 00 00. Dann
zähle ich den RamDL mit jedem Befehl (mal 4) und komme also am
entscheiden Punkt, wo ich später mal hinspringe, um NUR die letzten
Daten am Bildschirm zu ändern, wo ich den Wert des RamDL speichere. Für
die Aktualisierung der letzten Daten öffne ich dann also eine neue List
und starte die mit RamDL, wie eben gemerkt. Nun hatte ich den blöden
Fehler gemacht und hier noch einmal Hx80 00 00 dazu addiert, also bei
JEDEM Sprung Dadurch war bei jeder Aktualisierung das erste Bit
("Schreiben") mal Low und dann wieder High... So kommt der Wechsel zu
Stande. Was soll man dazu sagen - Passiert ...
Das ganze ist aber (wenn man es also richtig anstellt) eine sehr gute
Möglichkeit, einen Bildschirm teilweise zu beschreiben unter
Beibehaltung aller möglichen Grafiken und kann somit wertvolle Zeit
sparen, wenn es darauf ankommt. Vielleicht konnte ja jemand mit diesen
Beiträgen etwas für sich daraus entnehmen ...!
Liebe Grüße, Bernd
Prima, dass das geklärt ist und der Fehler ist interessant kreativ.
Sowas hätte ich im Logic-Analyzer Trace gesehen. :-)
Ich bin nur bei der Schlussfolgerung nicht ganz bei Dir. :-)
Ein
EVE_cmd_number(100, 200, 28, EVE_OPT_RIGHTX, irgendeinezahl);
ist doch erheblich leichter im Code zu pflegen, rechnet selber aus
welche Glyphen wo stehen müssen, passt die Anzahl der Stellen
automatisch an und braucht immer nur 4 32 Bit Worte auf dem SPI.
Oh ja, negative Zahlen und 1-9 Stellen mit führenden Nullen gehen auch.
In Verbindung mit CMD_SETBASE kann man das auch binär, octal und
hexadezimal ausgeben lassen.
Du hast ja Recht, dass das Update weniger Zeit braucht, dem gegenüber
steht aber der vielfach höhere Aufwand das umzusetzen und zu pflegen und
dann darf man die Liste ohnehin nicht häufiger wechseln als die Bildrate
ist, das bedeutet man hat bei 60Hz mal eben 16,666ms Zeit zwischen zwei
Aktualisierungen.
Und bei einer vollständigen Aktualisierung, etwa wenn man eine ganz
andere Bildschirmseite anzeigen möchte, dann muss erheblich mehr über
den SPI geschickt werden wenn direkt eine Display-Liste geschrieben
wird, als wenn man das den Kommando Co-Prozessor machen lässt.
Wobei man das ja kombinieren kann, man könnte ja ein Stück Display-Liste
in den Speicher schreiben und per CMD_APPEND in die Liste einfügen
lassen.
Dann könnte man den Speicher manipulieren und neu einfügen lassen.
Keine Ahnnug, drei Kreise mit unterschiedlichen Farben für eine Ampel.
Statt das im Speicher zu manipulieren könnte man aber auch so viele
Varianten anlegen wie man benötigt und jeweils die passende einfügen
lassen - wenn sich der Aufwand überhaupt lohnt.
Ich habe mit der Bibliothek und einem Riverdi RVT43HLBN (BT817)
rumexperimentiert, aber ich Frage mich immer noch, was der beste Weg
ist, ein bildschirmfüllendes Hintergrundbild auf das Display zu
bekommen. Muss nicht schnell sein, wird nur einmal geladen, aber mit
welchem Tool konvertiere ich es und in welchem Format? Ist die 4k
Begrenzung immer noch ein Thema oder inzwischen gefixt?
Luky S. schrieb:> Ich habe mit der Bibliothek und einem Riverdi RVT43HLBN (BT817)> rumexperimentiert,
So eines habe ich noch nicht.
> aber ich Frage mich immer noch, was der beste Weg> ist, ein bildschirmfüllendes Hintergrundbild auf das Display zu> bekommen. Muss nicht schnell sein, wird nur einmal geladen, aber mit> welchem Tool konvertiere ich es und in welchem Format?
Mit dem EVE Asset Builder: https://brtchip.com/toolchains/
Für die BT81x kann ich nur ASTC empfehlen, ASTC 8x8 braucht vor allem
nur 2 Bit pro Pixel bei voller Farbtiefe mit Alpha.
Das hier könnte hilfreich sein:
https://github.com/RudolphRiedel/FT800-FT813/discussions/83
Wobei es da vor allem darum ging ein Bild direkt aus dem Flash
anzuzeigen.
> Ist die 4k Begrenzung immer noch ein Thema oder inzwischen gefixt?
Das ist schon lange gefixt, so irgendwann in V4, das betraf ja nur mal
cmd_inflate und cmd_loadimage.
Für direktes Schreiben hätte ich noch EVE_memWrite_sram_buffer() und
EVE_memWrite_flash_buffer() anzubieten, wobei die sich nur auf AVR
Controllern wirklich unterscheiden.
Danke, das Beispielprogramm hat mir schon weitergeholfen, ich habe aber
glaube ich noch ein grundsätzliches Verständnisproblem mit dem EVEx
System:
Wie bekomme ich die Bilder ins Flash? Damit ist ja der direkt am BT817
per QSPI angebundene NOR Flash gemeint, oder?
Ich habe leider nur eine Ansteuerplatine mit einem ATmega328 ohne
zusätzlichen Speicher drauf.
Also "normalerweise" soll man das Flash-Image das EAB erzeugt auch mit
EAB in das NOR-Flash vom Display schreiben, dazu braucht man einen
USB/SPI Adapter.
https://www.matrixorbital.com/ftdi-eve/eve-bt817-bt818/eve-usb2spi-kit-bhttps://www.matrixorbital.com/ftdi-eve/eve-bt815-bt816/eve2-usb2spi-kit-ahttps://riverdi.com/blog/hermes-board-spi-usb-bridge-board-2/
Hmm, die Produkt-Seite für das Hermes Board ist nicht mehr da.
Und das "eve-usb2spi-kit-b" würde ich ja gerne kaufen, ich wüsste aber
nicht wo.
Das "eve-usb2spi-kit-a" gibt es bei DigiKey und Mouser.
Meine Beispiele haben aber auch Code wie man das aus dem Controller
heraus macht, siehe TFT_init() in tft.c.
Nur braucht man dafür den Speicher im Controller und ein M328 ist dafür
doch etwas sehr knapp dran.
Wenn das Programm nichts anderes machen soll als Flash Daten zu
schreiben, dann kommt man mit unter 4kiB für das Programm aus, dann
bleiben 27kiB für die Daten.
Das Flash wird in 4kiB Happen beschrieben, also 24kiB.
Man könnte ein Flash-Image mit EAB erzeugen, mit irgendeinem Tool in
24kiB Häppchen teilen, mit EAB die Binär-Happen in ein C-Array umwandeln
und per extra Programm mit EVE_memWrite_flash_buffer() in RAM_G
schreiben um dann per EVE_cmd_flashupdate() das RAM_G in das Flash zu
schreiben.
Sobald der allererste 4kiB Block mit dem "Blob" geschrieben ist kann man
per EVE_init_flash() den Modus auf "fast" stellen lassen.
Etwas nervig, aber durchführbar.
Wenn man einen dickeren Controller hätte wie einen ESP32 oder Teensy4,
dann wäre bei der Methode das RAM_G der begrenzende Faktor, das ist halt
"nur" 1MiB.
Dann müsste man das entweder in Etappen schreiben, oder aber
EVE_cmd_flashwrite() benutzen.
Das erfordert aber auch, dass das Flash leer ist, also ein
EVE_cmd_flasherase() braucht man dann auch noch.
In tft.c benutze ich EVE_cmd_inflate() um das Flash-Image vom Controller
in RAM_G zu entpacken, das macht deshalb Sinn, weil in meinem
Flash-Image ein UTF-8 Font drin ist und die sind auch in ASTC Format
noch mal hoch komprimierbar, das könnte an den leeren Glyphen liegen.
Oder generell daran, dass Zeichen mehr Nichts als Pixel sind.
Direkt per USB-SPI Bridge aufs Display laden klingt für mich nach einer
sinnvollen Variante. Der Eve Asset Builder scheint dafür aber ncith das
richtige Tool zu sein, der erstellt "nur" passende Dateien in einem
Ausgabeverzeichnis.
Riverdi macht leider auf mich einen nicht wirklich vertrauenserweckenden
Eindruck. Das Zeug funktioniert so halb, Dokumentation ist mies bzw.
unvollständig, eine Menge Links führen ins Nichts, der Support ist
...langsam.
Im Reiter "Flash Utilities" gibt es 4 Tabs, Flash Image Generator, Flash
Programmer, Flash Diagnostic und Sample Code.
Das Hermes Board ist inzwischen etwas älter, vielleicht haben die auch
was neues in der Pipeline.
Richtige Probleme hatte ich mit deren Dokumentation auch nie, was daran
soll jetzt bitte mies sein?
Ich finde höchstens, dass das Marketing auf der Homepage etwas neben der
Spur ist.
"Revolutionary communication protocol"? I2C.
"2x Pixel Mode"? Existiert wie beschrieben nicht.
Aber das sind die ersten EVE4 Displays die man tatsächlich auch hier in
Europa kaufen kann.
Und IPS, Optical Bonding und Hell gefällt mir ganz gut.
Ich würde gerne auch welche von Matrix Orbital kaufen, nur müsste ich
die direkt bei denen in Kanada ordern, das ist mir dann doch zu krass
was den Versand angeht.
Welches Interface verwendest du um die "Blobs" auf das Display zu
bekommen?
Ich finde, das Riverdi eine Menge Marketing-BlaBla auf der Homepage hat,
aber kaum harte technische Daten und ich glaube dass ich nicht der
einzige bin, der sich mit den Tools und dem -wie ich finde- etwas
merkwürdingen Workflow, nicht wirklich zurechtgefunden hat. "Getting
Started" oder sowas fehlt mir einfach.
Ich habe ein eve2-usb2spi-kit-a und ein Hermes Board von Riverdi, ich
benutze aber auch schon mal den Controller um Daten zu kopieren.
Wobei ich hauptsächlich ATSAME51 mit 512k Flash verwende.
Das hier ist die Produkseite von dem RVT43HLBNWC00:
https://riverdi.com/product/eve4-intelligent-display-rvt43hlbnwc00-4-3-inch-projected-capacitive-touch-panel-air-bonding-uxtouch/
Da gibt es das Datenblatt, eine Zeichnung, die Step-Datei, einen Reiter
"Description" und einen Reiter "Additional Information".
Und es gibt einen Link auf ein "Getting Started":
https://riverdi.com/support/eve4-getting-started/
Das wird unten sogar zum Download als .pdf angeboten.
Was fehlt Dir da denn jetzt noch?
Die Beispiele sind für Riverdis Library: https://github.com/riverdi
Die Library ist soweit ich weiß dicht an dem was FTDI damals zuerst
veröffentlich hatte und was man immer noch als Output vom EVE Screen
Designer bekommt.
Das einzige was Riverdi jetzt nicht veröffentlich sind komplette
Schaltpläne.
Was die Tools angeht, die kommen ja nicht von Riverdi, die sind von
Bridgetek, früher mal von FTDI.
Die Chips sind ja auch nicht von Riverdi.
Das Repository von Bridgetek ist übrigens hier:
https://github.com/BRTSG-FOSS
Hilfreich ist dann noch der Programming Guide:
https://brtchip.com/wp-content/uploads/2022/12/BRT_AN_033_BT81X-Series-Programming-Guide.pdf
Hi Rudolph,
also ich habe jetzt dieses Display:
https://www.displaymodule.com/products/3-4-480-x-480-transmissive-tft-lcd-rgb?_pos=8&_fid=10ae58c14&_ss=c
Es hat 480x480 sichtbare Pixel und dieses Timing für 60 Hz (die Werte in
Klammern verstehe ich als soll:
DCLK frequency FCLK -- (20) -- MHz
Horizontal Sync. Width hpw (8) Clock
Horizontal Sync. Back Porch hbp (56) Clock
Horizontal Sync. Front Porch hfp (20) Clock
Vertical Sync. Width vs (10) Line
Vertical Sync. Back Porch vbp (60) Line
Vertical Sync. Front Porch vfp (40) Line
Nun die 1000 Dollar Frage....wie komme ich denn nun zu den Werten für
den EVE, egal was ich "ausprobiere" ich bekomme kein stabiles Bild. Ich
komme da nicht weiter.
Anbei mein "Code" geht speziell um die H und V Sync Werte...
#if defined (EVE_EVE4_ISFD_3dot4_Inch)
#define Resolution_480x480
#define EVE_HSIZE (480L) // THD; Visible horizontal
resolution (in PCLKs)
#define EVE_VSIZE (480L) // TVD; Visible vertical
resolution (in lines)
// Horizonttal
#define EVE_HSYNC0 (8L) // THF; Horizontal Front Porch
(in PCLK cycles)
#define EVE_HSYNC1 (8L + 8L) // THF + THP; Horizontal
Front Porch plus Hsync Pulse width (in PCLK cycles)
#define EVE_HCYCLE (EVE_HSIZE + EVE_HSYNC0 + EVE_HSYNC1) // TH;
Total length of line (visible and non-visible) (in PCLKs)
#define EVE_HOFFSET (8L + 8L + 20L) // THF + THP + THB;
Length of non-visible part of line. Must be < TH - THD (in PCLK cycles)
// Vertical
#define EVE_VCYCLE (EVE_VSIZE + 8 + 8 + 2 + 2) // TV; Total
number of lines (visible and non-visible) (in lines)
#define EVE_VSYNC0 (40L) // TVF; Vertical Front Porch
(in lines)
#define EVE_VSYNC1 (40L + 10L) // TVF + TVP; Vertical
Front Porch plus Vsync Pulse width (in lines)
#define EVE_VOFFSET (40L + 10L + 2) // TVF + TVP + TVB;
Number of non-visible lines. Must be < TV - TVD (in lines)
#define EVE_PCLK (1L)
#define EVE_PCLKPOL (0L) //(1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_TOUCH_RZTHRESH (1800L)
#define EVE_DITHER (0L)
#define EVE_GEN 4
#define EVE_HAS_CRYSTAL
//#define EVE_PCLK_FREQ (14500000L) /* 14.5MHz => 54 Hz value for
EVE_cmd_pclkfreq */
#define EVE_PCLK_FREQ (16250000L) /* 16.25 MHz => 60.5 Hz value for
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (27000000L) /* 27 MHz => 100 Hz value for
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (22000000L) /* 22 MHz => 81.75 Hz value for
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (21500000L) /* 21.5 MHz => 79.5 Hz value for
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (21000000L) /* 21 MHz => 78.0 Hz value for
EVE_cmd_pclkfreq */
//#define EVE_PCLK_FREQ (19000000L) /* 19 MHz => 70.5 Hz value for
EVE_cmd_pclkfreq */
Grüße und vielen Dank
Torsten
Moin,
das Gefummel ist genau der Grund warum ich die Idee aufgegeben habe
irgendwelche Displays verwenden zu wollen. :-)
Normalerweise sind die Timing-Daten unvollständig und dann könnn sich
die Hersteller nicht mal darauf einigen wie sie ihre Parameter benennen.
EVE_PCLK_FREQ benutze ich inzwischen anders, aber um nur ein Bild zu
haben würde ich erstmal nur den normalen Takt benutzen.
Probier mal das hier:
1
#if defined(EVE_EVE4_ISFD_3dot4_Inch)
2
#define EVE_HSIZE (480L)
3
#define EVE_VSIZE (480L)
4
5
#define EVE_VSYNC0 (40L)
6
#define EVE_VSYNC1 (50L)
7
#define EVE_VOFFSET (110L)
8
#define EVE_VCYCLE (592L)
9
#define EVE_HSYNC0 (20L)
10
#define EVE_HSYNC1 (28L)
11
#define EVE_HOFFSET (84L)
12
#define EVE_HCYCLE (566L)
13
#define EVE_PCLK (4L)
14
#define EVE_PCLKPOL (1L)
15
#define EVE_SWIZZLE (0L)
16
#define EVE_CSPREAD (0L)
17
#define EVE_HAS_CRYSTAL
18
#define EVE_GEN 4
19
#endif
Das ist natürlich auch nur aufgrund der Daten wild geraten.
Bei dem Display bin ich aber nicht sicher ob man nicht auch den SPI da
dran braucht um den ST7701S zu konfigurieren.
Das sieht auf jeden Fall schwer danach aus, Pins 9, 10, 11 und 12.
Ich habe dann noch gerade das hier gefunden:
https://github.com/moononournation/Arduino_GFX
Das unterstützt wohl generell solche Displays, also mit ST7701S und
480x480.
Da sind acht "Types" definiert, vom Timing her passt keiner so 100%.
Such mal nach ST7701 in dem Code, da gibt es zum Beispiel
st7701_type1_init_operations - das sieht aus als wäre da ein ganzer
Haufen Daten definiert die per SPI geschrieben werden.
Super, Danke!...
Ja für den St7701 braucht man wohl ne Ini Sequenz...die schicke ich per
SPI an den ST7701s (ich habe zwie getrennte SPI, einen für EVE und einen
eben für den Controller...
Ich habe allerdings keine Ahnung, ob man das überhaupt machen
muss...also Reset und "Wecken" ist klar...ggf. Stimmen ja die
Defaultwerte...oder der Hersteller des Displays hat das ja ggf. Schon
"vorkonfektioniert"...
Normalen Takt, meinst Du über den "Teiler" aus der Tabelle? Wie benutzt
Du den PCLK_FREQ jetzt? Ich hatte auch den Eindruck das da was nicht
stimmt...
Grüße und nochmal Danke
Torsten
Ja, ob man den ST7701 betüddeln muss - keine Ahnung, sowas hatte ich
noch nicht und das fände ich auch schwer lästig.
Torsten schrieb:> Normalen Takt, meinst Du über den "Teiler" aus der Tabelle? Wie benutzt> Du den PCLK_FREQ jetzt? Ich hatte auch den Eindruck das da was nicht> stimmt...
Na, ohne die zweite PLL.
Mit EVE_PCLK = 4 ergeben sich 18MHz, das sollte erstmal laufen, falls
denn der Rest der Parameter passt.
EVE_PCLK_FREQ setze ich wenn benötigt jetzt auf einen vorberechneten
Wert wie er auch in der Tabelle zu finden ist, wenn das definiert ist
wird REG_PCLK direkt auf 1 gesetzt.
20MHz gibt es in der Tabelle nicht, das müsste 0x8A3 sein.
Okay,
man muss nur die richtige Init Sequenz für den ST7701 haben dann geht es
auch, ist natürlich problematisch, wenn der Hersteller des Displays sie
erstmal auch nicht hat und mir ca. 10 Stück zur Auswahl schickt und
keine davon geht. Habe dann Sitronic direkt angeschrieben...die sind
sehr schweigsam dazu...haben aber versucht zu helfen. Da gibt es einen
undokumentierten Registerbereich...ist wahrscheinlich nur für Hersteller
gedacht...
Für ggf. hier anderen ST7701 Nutzer. Entscheidend scheinen die sog. GIP
Werte zu sein, das Timing scheint gar nicht so kritisch zu sein.
Irgendwann nach erneutem Nachfragen hat er mir dann eine aktualisierte
Sequenz geschickt, ist jetzt auch auf der Webseite...das Display ist
wirklich hell, crisp, weiter Sichtwinkel und gut.
Ich habe die Werte die Du vorgeschlagen hast genommen...jetzt geht es
wunderbar mit 70 Hz Wiederholrate mit 20Mhz Pixelclock...
Grüße und Danke
Torsten
Rudolph R. schrieb:> Vor ein Tagen ist mir das hier aufgefallen:> https://github.com/MatrixOrbital/EVE-Library/blob/main/src/eve/ST7789V.c>> Wobei ich weiterhin froh bin, dass mir sowas noch nicht untergekommen> ist. :-)
Genau so...ich mache das auch mit SPI BitBanging für die
Initialisierung, da kann man dann jedes SPI Format erzeugen 8 Bit, 9Bit
und xBit wenn notwendig.
Hier kommt es ja nicht auf Geschwindigkeit an, muss man ja nur einmal
zum Start machen...
Grüße
Hallo,
ich bin froh hier eine, sogar deutsch sprachige, Community gefunden zu
haben, die sich mit dem BT8XX beschäftigt.
Ich hab momentan ein Problem und ich denke für euch ist das keines es zu
lösen.
Zur Hardware:
Riverdi 7" mit EVE4 + eigenes PIC Board.
Ich hab bereits ein großes flash file mit dem EAB erstellt und
erfolgreich in den externen flash auf dem Riverdi Board geschrieben.
Erfolgreich deshalb, weil es kein Problem ist eins der darin
gespeicherten Bilder anzeigen zu lassen. Das funktioniert mit jedem Bild
soweit gut.
Mein Problem ist nun, dass ich es nicht schaffe mehr als drei Bilder
gleichzeitig anzeigen zu lassen. Der RAM_G sollte ja eigentlich 1024k
haben, Meine Bilder im flash haben zusammen über 6000k (es sind aber
einige hundert). Ich möchte nun einen großen Teil des Displays mit
Bilder füllen. leider funktioniert das nur bis einer RAM_G Adresse um
die 50000 und nicht bis 1024000.
Leider verwende ich nicht die Bibliothek von Rudolph, sondern eine
angepasste von BRT, aber ich denke das Verhalten ist ähnlich.
Hier mein Code:
Gpu_Hal_WaitCmdfifo_empty(phost);
Gpu_CoCmd_FlashFast(phost, 0);
Gpu_CoCmd_Dlstart(phost);
App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(0));
Gpu_CoCmd_FlashRead(phost, 0, 5955008, 2240);
Gpu_CoCmd_SetBitmap(phost, 0, COMPRESSED_RGBA_ASTC_5x5_KHR, 100,
35);
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2F(400*16, 0));
App_WrCoCmd_Buffer(phost, END());
App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(1));
Gpu_CoCmd_FlashRead(phost, 2300, 5693888, 46080);
Gpu_CoCmd_SetBitmap(phost, 2300, COMPRESSED_RGBA_ASTC_5x5_KHR, 180,
400);
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2F(0, 0));
App_WrCoCmd_Buffer(phost, END());
App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(2));
Gpu_CoCmd_FlashRead(phost, 49000, 5959488, 1472);
Gpu_CoCmd_SetBitmap(phost, 49000, COMPRESSED_RGBA_ASTC_5x5_KHR, 65,
35);
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2F(250*16, 1000));
App_WrCoCmd_Buffer(phost, END());
Bis hier funktioniert es mit drei Bilder, wird der untere Teil mit
eingebunden bleibt das Display schwarz oder die Bilder sind zerschossen.
App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(2));
Gpu_CoCmd_FlashRead(phost, 51000, 5959488, 1472);
Gpu_CoCmd_SetBitmap(phost, 51000, COMPRESSED_RGBA_ASTC_5x5_KHR, 65,
35);
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2F(250*16, 1000));
App_WrCoCmd_Buffer(phost, END());
Danach kommt noch das:
App_WrCoCmd_Buffer(&host, DISPLAY());
//swap the current display list with the new display list
Gpu_CoCmd_Swap(&host);
App_Flush_Co_Buffer(&host);
Gpu_Hal_WaitCmdfifo_empty(&host);
/* Close all the opened handles */
App_Common_Close(&host);
Zuerst dachte ich der RAM_G reicht nicht aus aber laut ESE passen die
Bilder rein.
Ich hoffe Ihr könnt mir dabei helfen.
Viele Grüßen,
Bernhard
Hallo,
nach einigem Suchen, denke ich, dass ich hier richtig bin.
Ich habe hier seit gefühlten 100 Jahren ein
FT811CB von THAOYU
liegen, das ich jetzt mal in Betrieb nehmen möchte.
Hat jemand einen "Starter-C-code" oder eine Tipp, woher man ihn bekommen
kann, damit die ersten Schritte schon mal erledigt sind.
Hat jemand einen Tipp, woher man Infos über das Teil bekommen kann.
Danke für sachdienliche Hinweise und
VG Walter
P.S.:
IC ist der FT5206.
Auf GitHaub habe ich etwas in C++ gefunden, für mich nicht so schön.
Es geht nicht um die SPI, die habe ich im Griff....
Moin,
was in dem Post etwas schwer zu finden war, jetzt so in dem Code
"versteckt" ohne Code Tags, ist was denn überhaupt passiert.
>Gpu_CoCmd_FlashRead(phost, 51000, 5959488, 1472);
Probier mal die ganzen Gpu_CoCmd_FlashRead() da raus zu ziehen.
Die werden ja nur einmal gebraucht und sicher nicht in die Display-Liste
eingebaut.
Und das BITMAP_HANDLE wird so auch nicht benötigt, auch wenn das nicht
direkt falsch ist.
Das BITMAP_HANDLE ist ein Set Einstellungen zum Speichern und wieder
verwenden, wenn man die Bilder nur einmal anzeigen will kann man das
auch weg lassen, dann wird durch jedes neue SetBitmap das Default
Bitmap-Handle verändert.
1
Gpu_CoCmd_FlashFast(phost, 0);
2
Gpu_CoCmd_FlashRead(phost, 0, 5955008, 2240);
3
...
Wobei da noch die Frage ist, was die Funktionen überhaupt machen.
Also ob die Rückgabewerte haben, ob gewartet wird und so.
Boah, das ist die Library wegen der ich meine Library angefangen habe.
:-)
Und ich weiß ja, dass ich keinen PIC Support in meiner Library habe,
den einzubauen sollte aber eher kein Problem sein.
Ich habe nur keine einzige Platine mit PIC drauf und ich müsste zum
Programmieren MPLAB-X verwenden.
Und MPLAB-X ist einer der Gründe warum ich nicht mal in Erwägung ziehe
irgendwelche PICs zu verwenden, vor allem nachdem was Microchip mit den
ATSAM getrieben hat.
Hallo Rudolph,
vielen Dank für deine Antwort. Ich hab nun deine Bibliothek auch ans
laufen bekommen. Leider stoße ich nun nur etwas später an die Grenze.
Jetzt funktionieren zumindest schon 7 Bilder je ca. 240x180px.
Ich lade nach dem initialisieren alle Bilder in das RAM_G, danach werden
die Bilder aufgerufen. Momentan nur einmal beim initialisieren. Ich
versuche die 7" mit mehreren kleineren Bilder zu füllen.
Hier der Code:
// *** displays an image loaded from Flash ***********************************
52
53
// *** end of the display list ***********************************************
54
EVE_cmd_dl(END());
55
EVE_cmd_dl(DISPLAY());
56
EVE_cmd_dl(CMD_SWAP);// tell EVE to use the new display list
57
// EVE_execute_cmd();
7 Bilder gehen noch beim 8. bleibt das Display schwarz.
Außerdem bleibt die Funktion EVE_execute_cmd(); hängen, darum ist sieh
hier auskommentiert. Leider hab ich noch nicht verstanden, was diese
genau macht.
Walter L. schrieb:> Hat jemand einen "Starter-C-code" oder eine Tipp, woher man ihn bekommen> kann, damit die ersten Schritte schon mal erledigt sind.
Schau mal in meine Library, da sind auch Beispiele dabei,
die Frage wäre nur für welchen Controller und ob Arduino oder nicht.
https://github.com/RudolphRiedel/FT800-FT813Walter L. schrieb:> IC ist der FT5206.
Das ist "nur" der Touch-Controller, der Grafik-Chip selber ist ein
FT811.
Die Dokumentation ist hier:
https://brtchip.com/documents-type/data-sheets/
Bernhard B. schrieb:> Ich hab nun deine Bibliothek auch ans laufen bekommen.
Tendenziell hätte ich ja schon Interesse an dem PIC Code um
den für andere zu integrieren. :-)
Ansonsten fällt mir gerade nichts auf das nicht funktionieren sollte.
Es gibt schon noch andere Limits wie die 4kiB im RAM_CMD und die 8kiB in
der Display-Liste, davon ist das bisschen Code aber sicher noch ganz
weit weg.
Bernhard B. schrieb:> Außerdem bleibt die Funktion EVE_execute_cmd(); hängen, darum ist sieh> hier auskommentiert. Leider hab ich noch nicht verstanden, was diese> genau macht.
Die wartet eigentlich nur darauf das alle Kommandos im RAM_CMD
abgearbeitet sind, das sollte so nicht hängen bleiben können.
Lies ein paar ms nach dem CMD_SWAP mal das RAM_ERR_REPORT aus,
siehe Kapitel "5.7 Coprocessor Faults" im Programming Guide.
Vielleicht steckt der Fehler auch in den Bildern.
Anderes Experiment, lad doch mal die ersten paar Bilder die
funktionieren mehrmals in RAM_G.
Ich hole gleich mal mein RVT70HSBNWC00-B raus und probiere das aus,
das schwierigste dabei wird sein Bilder zu finden, zu konvertieren und
in das Flash zu brennen.
Hallo Rudolph,
danke für die INFOs; mit denen komme ich wohl zurecht.
>die Frage wäre nur für welchen Controller und ob Arduino oder nicht
TMSP320F28069 oder MSP430FRxxx.
VG Walter
Hallo Rudolph,
Danke für deine Unterstützung.
Momentan sieht es so aus, dass der CAN Bootloader vom PIC schuld daran
ist und das mit den Bildern nur eine falsche Fährte war. Scheinbar
überschreitet das Programm eine gewisse Größe und überschreibt damit die
Checksumme oder sorgt dafür, dass die Berechnung nicht mehr richtig
funktioniert. Beim einfügen mehrerer Bilder trat dass dann auf und
führte dazu, dass der Bootloader die Anwendung garnicht erst startet
(das war mir die ganze zeit nicht aufgefallen). Mit der Zeile
EVE_execute_cmd() verhielt es sich scheinbar genauso.
Zum PIC Code, ich möchte die Anwendung noch optimieren und testen,
außerdem hab ich noch Bilder verwendet, die nicht mir gehören. Das
möchte ich noch geradeziehen, dann kann ich dir das gerne zuschicken.
Gruß,
Bernhard
Walter L. schrieb:>>die Frage wäre nur für welchen Controller und ob Arduino oder nicht>> TMSP320F28069 oder MSP430FRxxx.
Jetzt gehts los. :-)
Ist heute Tag der Controller Challenge? :-)
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_TMS320C28XX.hhttps://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_MSP432.h
Die beiden sind ja vorhanden, wobei ich bei beiden nicht sicher bin wie
gut die funktionieren, weil ich beide Controller noch nicht auf dem
Tisch hatte.
Aber da kann man bestimmt drauf aufbauen, die Peripherie sollte ja
ähnlich sein.
Und wenn man eine neue EVE_target...h macht, dann muss man die noch in
der EVE_target.h eintragen.
Der TMS320 war seltsam, kennt beine Bytes und ich meine der SPI kann
auch kein DMA, DMA wäre wohl möglich gewesen mit einem UART im SPI Mode,
oder so ähnlich, ist eine Weile her das ich mir das angesehen habe.
Bernhard B. schrieb:> Momentan sieht es so aus, dass der CAN Bootloader vom PIC schuld daran> ist und das mit den Bildern nur eine falsche Fährte war. Scheinbar> überschreitet das Programm eine gewisse Größe und überschreibt damit die> Checksumme oder sorgt dafür, dass die Berechnung nicht mehr richtig> funktioniert.
Das muss dann aber schon sehr knapp am Limit sein, die paar Zeilen
kosten doch erstmal nicht viel.
Bernhard B. schrieb:> Zum PIC Code, ich möchte die Anwendung noch optimieren und testen,> außerdem hab ich noch Bilder verwendet, die nicht mir gehören. Das> möchte ich noch geradeziehen, dann kann ich dir das gerne zuschicken.
Klingt gut, wobei ich die Bilder ja eher nicht brauche. :-)
Mein 7" läuft gerade, jetzt mal ein paar Pixel für einen Test aus dem
Netz fischen. :-)
Bernhard B. schrieb:> EVE_cmd_setbitmap( EVE_RAM_G, COMPRESSED_RGBA_ASTC_5x5_KHR, 240, 190 );
Detail am Rande, welche Version ist das?
Ich musste gerade nachschauen, im Dezember 2022 habe ich das auf
EVE_ASTC_5X5 geändert.
So, ich habe einen Satz Bilder auf 240xwhatever konvertiert, die auf
ASTC 5x5 konvertiert, ein Flash-Image erstellt, das ins Flash gebrannt.
Wobei ich noch ein Downgrade auf EAB 2.8 machen musste, der EAB 2.9 ist
ganz schön kaputt.
Jetzt kopiere ich gerade beim Start 12 Stück davon in RAM_G und lasse 50
Mal pro Sekunde eine Diplay-Liste erstellen die per DMA über den SPI
geschoben wird.
So zusätzlich in dem Code meines einfachen Beispiel-Codes.
In dem ATSAME51 der an meinem RVT70HSBNWC00-B hängt sind
das insgesamt 20068 Bytes Programm-Speicher, wobei 3597 Bytes für die
beiden Bilder in dem Beispiel-Code sind.
Das Projekt verwendet keinen Bootloader.
Im Ergebnis sind das 480 Bytes die per Display-Update über den SPI
verschickt werden und das ergibt eine Display-Liste von 1360 Bytes.
Da ginge noch viel mehr, aber die 1024x600 sind schon gut mit Pixeln
gefüllt.
1
#define SPACE22 0UL
2
#define SPACE01 20736UL
3
#define SPACE02 41472UL
4
#define SPACE03 66048UL
5
#define SPACE04 86784UL
6
#define SPACE05 111360UL
7
#define SPACE06 135936UL
8
#define SPACE07 158976UL
9
#define SPACE08 179712UL
10
#define SPACE09 203520UL
11
#define SPACE10 228096UL
12
#define SPACE11 262656UL
13
14
if (E_OK == EVE_init_flash())
15
{
16
EVE_cmd_flashread(SPACE22, 4096, 20736);
17
EVE_cmd_flashread(SPACE01, 24832, 20736);
18
EVE_cmd_flashread(SPACE02, 45568, 24576);
19
EVE_cmd_flashread(SPACE03, 70144, 20736);
20
EVE_cmd_flashread(SPACE04, 90880, 24576);
21
EVE_cmd_flashread(SPACE05, 115456, 24576);
22
EVE_cmd_flashread(SPACE06, 140032, 23040);
23
EVE_cmd_flashread(SPACE07, 163072, 20736);
24
EVE_cmd_flashread(SPACE08, 183808, 23808);
25
EVE_cmd_flashread(SPACE09, 207616, 24576);
26
EVE_cmd_flashread(SPACE10, 232192, 34560);
27
EVE_cmd_flashread(SPACE11, 266752, 24576);
28
}
Tendenziell bevorzuge ich ASTC 8x8, das ist noch mal deutlich kleiner
und von der Qualität auch noch recht gut.
Bei der Pixel-Dichte von fast 7 RGB Pixel pro mm fallen
Komressions-Artefakte auch gar nicht so leicht auf.
Oh ja, und ich verwende den aktuellen Stand meiner Library, also nicht
den Release 5.0.6 vom Mai, den ganz aktuellen Stand.
Hallo,
ich möchte nochmal rückfragen.
Oben im Bild bei P1 (PINs nicht bezeichnet) liegt der FT5206, ein cap.
touch controller.
Auf der Rückseite des PCB liegt der FT811 (hab ich kontrolliert).
Der FT811 kann auch cap. touch.
Beide IC's können also cap. touch.
Frage: Warum 2 cap. touch IC's?
Die PIN-Belegung des P1 ist offensichtlich (habe durchgekligelt) vom
quad. PIN aus gezählt
1 5V,
2 5V,
3 SSEL/SCL PIN22 vom FT5206,
4 MOSI/SDA PIN24 vom FT5206,
5 WAKE PIN27 vom FT5206,
6 INT PIN28 vom FT5206,
7 weiß nicht, geht wahrscheinlich auf die BASIS/GATE eines
Transistors.
Frage: Kennt jemand die Bedeutung (was macht man damit)?
Frage: Benutzt jemand das Display (nur Display, oder Display und cap.
Touch)?
Danke für Antworten.
VG Walter
Der FT811 benutzt den FT5206 als Touch-Sensor per I2C.
Die FT8xx / BT8xx kümmern sich auch um den Touch, man kann zwar auch die
Koordinaten raus lesen, am einfachsten ist allerdings einem Objekt per
TAG eine Nummer zuzuweisen und die Touch-Events auszulesen.
Gibt man etwa einem Button die Nummer 10, dann steht im Register
REG_TOUCH_TAG die 10 wenn man den Button auf dem Bildschirm berührt.
Man muss also nicht selber nachrechnen ob Touch Koordinaten vielleicht
zu einem Objekt auf dem Bildschirm gehören könnten.
Man kann sogar einer ganzen Gruppe von Objekten einen TAG zuordnen, etwa
wenn man sich eigene Buttons erstellt mit einem Bild und darüber
liegendem Text.
FT810, FT812, BT816 und BT818 sind für Resistiv-Touch.
FT811, FT813, BT815 und BT817 sind für Kapazitiv-Touch.
Resistiv-Touch ist als passive Matrix ausgelegt und braucht vier Analaog
Anschlüsse.
Kapazitiv-Touch braucht eine ganze Menge Anschlüsse und von daher
dürften die meisten Panels mit integriertem Rasterizer für
Kapazitiv-Touch den Sensor gleich integriert haben, normalerweise als
Schaltung auf dem Folien-Leiter.