Hallo Forum,
ich habe das o.a. Display in Benutzung und möchte nur die geänderten
neunen Zahlen überschreiben.
Hat jemand eine Idee, wie ich ein entsprechendes volles Kästchen aus den
Pixeln in der jeweilgen Schriftgröße in Hintergrundfarbe (Befehl ist
klar) schreiben kann oder gibt es das schon ? Ich habe zumindest nichts
in der Libary gefunden.
1
if(Einer!=Old_Einer)// Wenn alter und neuer Wert unterschiedlich
2
{
3
tft.setTextColor(ILI9341_BLACK);// Farbe wie Hintergrund
4
tft.setTextSize(15);
5
tft.setCursor(82,10);
6
BefehlfürKästchen?;// überschreibe vorherige Zahl mit leerem zeichen
7
tft.setTextColor(ILI9341_WHITE);// Farbe wie Vordergrund
Daniel E. schrieb:> Hat jemand eine Idee, wie ich ein entsprechendes volles Kästchen aus den> Pixeln in der jeweilgen Schriftgröße in Hintergrundfarbe (Befehl ist> klar) schreiben kann oder gibt es das schon ?
Ein Leerzeichen?
Ich habe zumindest nichts
> in der Libary gefunden.> if (Einer != Old_Einer) // Wenn alter und> neuer Wert unterschiedlich
Apfelmus ist Mus aus Äpfeln. Der Kommentar ist hyperliquide. Siehe
Strukturierte Programmierung auf Mikrocontrollern
Die meisten anderen Kommentare auch.
Gibt es keinen Schreibmodus, welcher die Zeichen vollständig und direkt
überschreibt? Sprich, der Hinter- und Vordergrund neu schreibt.
hier tft.setTextColor(ILI9341_WHITE); noch die Hintergrundfarbe als 2.
Argument angeben, so müsste es gehen. Allerdings nur die fixed Fonts,
nicht für die mit variabler Zeichenbreite.
J. S. schrieb:> hier tft.setTextColor(ILI9341_WHITE); noch die Hintergrundfarbe als 2.> Argument angeben, so müsste es gehen. Allerdings nur die fixed Fonts,> nicht für die mit variabler Zeichenbreite.
Danke für das Feedback. Es sind nur Zahlen in gleicher Größe. Gemäß
meiner Recherche müssten das schon mal die fixed fonts sein.
Könntest du mir bitte das 2. Argument erläutern und was da genau gemacht
wird und wie der Befehl komplett aussieht ? Letztendlich soll ja zum
Beispiel eine 8 mit 1 aktualisiert werden.
Vielen Dank !
Daniel E. schrieb:> Könntest du mir bitte das 2. Argument erläutern und was da genau gemacht> wird und wie der Befehl komplett aussieht ? Letztendlich soll ja zum> Beispiel eine 8 mit 1 aktualisiert werden.
Bitte? Du musst die Zahl nur überschreiben! Kann ja wohl nicht so schwer
sein!
> Ein Leerzeichen?
Hab ich schon probiert und das geht nicht, Leerzeichen = keine Pixel
> Gibt es keinen Schreibmodus, welcher die Zeichen vollständig und direkt> überschreibt? Sprich, der Hinter- und Vordergrund neu schreibt.
Das dauert ewig und ist deutlich sichtbar, warum diesen Weg, wenn in
anderen Posts immer darauf gedrängt wird nur das zu überschreiben was
sich geändert hat ?
Danke
Daniel E. schrieb:> Könntest du mir bitte das 2. Argument erläutern und was da genau gemacht> wird und wie der Befehl komplett aussieht ? Letztendlich soll ja zum> Beispiel eine 8 mit 1 aktualisiert werden.
Bitte? Du musst die Zahl nur überschreiben! Kann ja wohl nicht so schwer
sein!
Wenn man wissen will, wie die Parameter für die Funktionen lauten und
was sie tun, muss man in die Headerfiles der Lib schauen. Hier
Adafruit_GFX.h
Die liegt in deinem Libraries Ordner deiner Arduino-Installation bzw. im
Pfad deines Sketchbooks.
Daniel E. schrieb:>> Gibt es keinen Schreibmodus, welcher die Zeichen vollständig und direkt>> überschreibt? Sprich, der Hinter- und Vordergrund neu schreibt.>> Das dauert ewig
Was soll daran ewig dauern? Natürlich sollen nur die Zeichen geschrieben
werden, welche sich ändern!
> und ist deutlich sichtbar, warum diesen Weg, wenn in> anderen Posts immer darauf gedrängt wird nur das zu überschreiben was> sich geändert hat ?
Das habe ich ja gesagt. Das Problem liegt darin, daß die Lib auch einen
Modus anbietet, welcher mit transparentem Hintergrund schreibt, dabei
wird ein altes Zeichen eben NICHT vollständig überschrieben, im
Gegenteil, man sieht die beiden Zeichen überlagert. Das ist aber mit der
richtigen Einstellung von Vorder- und Hintergrundfarbe lösbar, siehe
oben! Eben OHNE transparenten Hintergrund!
Falk B. schrieb:> Daniel E. schrieb:>> Könntest du mir bitte das 2. Argument erläutern und was da genau gemacht>> wird und wie der Befehl komplett aussieht ? Letztendlich soll ja zum>> Beispiel eine 8 mit 1 aktualisiert werden.>> Bitte? Du musst die Zahl nur überschreiben! Kann ja wohl nicht so schwer> sein!
Gut, da hab ich was missverstanden. Das ist mir klar, muss mir halt nur
den letzten geschriebenen Wert merken
Ich habe aber etwas bedenken, je nachdem wie der Code durchläuft (
Interrupt, Berechnungen) das irgendwann schreib/ Pixelfehler auftreten
und würde daher gern das ganze Feld schreiben.
Was spricht dagegen? der fehlende Schreibbefehl ?
Ich kann ja die Pixelfelder herausfinden und ggf. ein extra Zeichen
kreieren, evtl. gibts ja wie gesagt sowas schon, was mir unbekannt ist.
Daniel E. schrieb:> Ich habe aber etwas bedenken, je nachdem wie der Code durchläuft (> Interrupt, Berechnungen) das irgendwann schreib/ Pixelfehler auftreten> und würde daher gern das ganze Feld schreiben.
Dann tu das doch einfach!
> Was spricht dagegen?
NICHTS!
> der fehlende Schreibbefehl ?
Nö, dein fehlendes Wissen zum Thema.
> Ich kann ja die Pixelfelder herausfinden und ggf. ein extra Zeichen> kreieren,
AUA!
> evtl. gibts ja wie gesagt sowas schon, was mir unbekannt ist.
Liest du auch ab und an die Beiträge anderer Leute?
Das Problem ist längst gelöst!
Der TO schrieb das er die nicht verwendet.
Und wenn doch, dann ist der Text nach dem markierten wichtig. Mit
Rechteck löschen flackert es fürchterlich und man sollte einen Canvas
zum zeichnen nehmen.
Welcher Depp setzt dort nochmal die Farbe so, daß man IMMER mit
transparentem Hintergund schreibt? Man muss die Zeile wie oben
auskommentieren und sein Projekt neu kompilieren, dann geht das
flackerfreie Überschreiben butterweich.
Falk B. schrieb:> Da gibt> es einen Fehler in Adafruit_GFX.cpp in
die Methode 'text' gibt es im original Adafruit-GFX nicht. Woher soll
man wissen welchen verbastelten Fork du benutzt?
Daniel E. schrieb:> Hat jemand noch Ideen wie das anders gelöst werden könnte, so dass mein> Display 3-4x in der Sekunde blitzschnell refreshed werden kann?
Einen geeigneten µC und eine Schnittstelle mit hoher Bandbreite
benutzen.
J. S. schrieb:>> Da gibt>> es einen Fehler in Adafruit_GFX.cpp in>> die Methode 'text' gibt es im original Adafruit-GFX nicht. Woher soll> man wissen welchen verbastelten Fork du benutzt?
Das Ding hab ich vor Jahren mal installiert. Es ist TFT von Adafruit,
1.0.6, gemäß Bibliotheksmanager die neueste Version. Auf dem Ding baut
auch die Lib für das Display vom OP auf!
Ich würde mal vorsichtig behaupten, daß der Fehler hier eher bei dir
liegt. Schau nochmal genau in die Lib.
Das ist ein verbastelter Fork von irgendwem, aber nicht von Adafruit.
Selbst in der ältesten Adafruit-GFX 1.0.0 von 2015 gibt es kein text().
Und Adafruit hat kein Repo names 'TFT', das einzige was ST7735 enthält
ist eine Python Portierung.
J. S. schrieb:> Und selbst da gibt es deine Codezeilen nicht:> https://github.com/adafruit/Adafruit-ST7735-Library/blob/1.0.6/Adafruit_ST7735.cpp
Das ist ja auch die falsche Datei.
> und auch wenn Code von Arduino gepflegt wird heisst es nicht das er> nicht verbastelt sein kann...
Ist halt ne uralte Version. Egal. Der OP sollte dennoch die Methode
testen.
Und ggf. die text-Methode in den Untiefen der Klassenvererbung suchen
und finden und ggf. reparieren.
>> Hat jemand noch Ideen wie das anders gelöst werden könnte, so dass mein>> Display 3-4x in der Sekunde blitzschnell refreshed werden kann?> Einen geeigneten µC und eine Schnittstelle mit hoher Bandbreite> benutzen.
Ein LCD mit 8 Bit Schnittstelle könnte schon ausreichen mit dem Mega
2560 oder ?
Würde ein PIC18F mit dem Adafruit Display auch gehen?
Mir fehlt das bissel die Erfahrung.
Danke
Daniel E. schrieb:> Ein LCD mit 8 Bit Schnittstelle könnte schon ausreichen mit dem Mega> 2560 oder ?
Es geht sogar mit dem ollen 1,8 Zoll TFT und lausigen 4 MHz mit SPI,
also seriell!
> Mir fehlt das bissel die Erfahrung.
Ja, vor allem beim Lesen von Beiträgen.
Da gibt es keine Untiefen der Vererbung. Die Krux sind die verdammten
ZIP Files, Code gehört einfach nicht in zip. Das zip und die git Quellen
stimmen nicht überein, trotz gleicher Versionsnummer.
Ich benutze solche Displays nicht mit AVR oder anderen 8 Bit uC, die
gehören für mich nicht zu ,geeigneten uC‘.
RP2040 mit der Bodmer/TFT_eSPI Lib wäre etwas schnelles.
J. S. schrieb:> Ich benutze solche Displays nicht mit AVR oder anderen 8 Bit uC, die> gehören für mich nicht zu ,geeigneten uC‘.> RP2040 mit der Bodmer/TFT_eSPI Lib wäre etwas schnelles.
Alles nur Gejammer! Der Beweis, daß es SCHNELL und flackerfrei geht,
liegt auf meinem Tisch!
@falk
Du brauchst dich nicht genötigt fühlen antworten zu müssen… das Display
hängt bereits per SPI am Arduino
Schön, wenn du in dieser Angelegenheit es besser weißt als ich… dafür
liegen meine Stärken evtl. an anderer Stelle
Falk B. schrieb:> Welcher Depp setzt dort nochmal die Farbe so, daß man IMMER mit> transparentem Hintergund schreibt?
Auf PC ist das so üblich. Ich nehme an, dass Adafruit hier das default
Verhalten so wenig überraschend wie möglich machen wollte.
Ja ich weiß, dass das es fast alle anderen Bibliotheken aus dem µC
Umfeld anders handhaben. Vermutlich auch fast alle Displays mit
integriertem Zeichengenerator. Das wird Adafruit aber nun wohl nicht
mehr ändern, schließlich hängen viele bestehende Projekte und Produkte
daran.
wenn man so grobpixelige Anzeigen mag und mit dem Retro Look zufrieden
ist, dann geht das vielleicht so. Dann wäre aber ein LED Matrix Display
effizienter.
Eine Alternative wäre noch drawBitmap() zu probieren. Das kann als
Quelle ein 1 BPP in ein 16 BPP Image in das Display zeichnen. Das geht
noch relativ schnell weil 1 Bit nur in 2 SPI Byte übertragen werden
muss. Eine Ziffer in z.B. 128x96 braucht dann 1,2 kB im Flash, 10
Ziffern passen in den Mega2560 rein. Dafür kann man dann beliebig schöne
Fonts verwenden.
Stefan F. schrieb:> Auf PC ist das so üblich. Ich nehme an, dass Adafruit hier das default> Verhalten so wenig überraschend wie möglich machen wollte.
das hat jemand von Arduino geändert, vielleicht weil er den 'Trick' mit
dem bg setzen auch nicht kannte.
Hallo zusammen und danke für das Feedback.
Mit dem Adafruit scheint es ja nicht wie gewünscht zu funktionieren.
Jetzt bin ich wieder beim LCD Display 2x8 oder 2x16 und 9 mm oder 11 mm
Zeichenhöhe, so dass die Anwendungen relativ brauchbar wird.
Sollte eigentlich was mit dem Arduino damit werden oder? Über ein paar
Kommentare dazu würde ich mich freuen.
Danke
Daniel E. schrieb:> Mit dem Adafruit scheint es ja nicht wie gewünscht zu funktionieren.
Wenn man die Bibliothek richtig anwendet, dann geht das durchaus.
Daniel E. schrieb:> Mit dem Adafruit scheint es ja nicht wie gewünscht zu funktionieren.
Das Display mit dem ILI9341 ist auch mit SPI so schnell dass man Zahlen
ohne Flimmern problemlos darstellen kann.
Falk hat es ja bereits gezeigt.
Eventuell ist einfach die verwendete Bibliothek nur langsam
programmiert.
Einfach mal eine andere ausprobieren, auf Github gibt es genügend davon.
Stefan F. schrieb:> Falk B. schrieb:>> Welcher Depp setzt dort nochmal die Farbe so, daß man IMMER mit>> transparentem Hintergund schreibt?>> Auf PC ist das so üblich.
???
"Auf dem PC" ist ja nun doch ein sehr weites Feld. Offensichtlich hast
du nur einen sehr kleinen Teil davon beackert.
Also nein: Es ist im Gegenteil absolut unüblich, Schrift per default mit
transparentem Hintergrund auszugeben. Schon allein deshalb, weil das die
(Rechenzeit-)Kosten der Schriftausgabe aus nachvollziehbaren Gründen
(RMW statt WO) per default massiv in die Höhe treiben würde.
Oder andersum: was auch immer dieses default-Verhalten haben sollte (ich
kenne nichts, was sich so verhält), wäre jedenfalls definitiv ziemlicher
Mist.
Magst du "auf dem PC" vielleicht mal genauer spezifizieren?
> Einfach mal eine andere ausprobieren, auf Github gibt es genügend davon.
Werde ich auch ausprobieren … danke
Hätte nicht gedacht das es so viele verschiedene Library’s gibt und
Adafruit so langsam ist …
Adafruit ist nicht langsam, damit muss es auch gehen.
Zwei Zeichen a 128x96 bei 16 BPP sind ca. 400.000 Bit, @ 4 MHz SPI sind
das 100 ms für die reine Übertragung. Dazu kommt noch das was die CPU
braucht, aber mit den Bitmaps sollte es nicht Zuviel sein. Mit einem
RP2040 wäre SPI min 10x schneller, da sind >10 Hz drin. Gleiches
Display, Arduino Code genauso und der Controller ist billiger als ein
Mega2560.
Falk B. schrieb:> https://youtu.be/U99jaHkLALc>> Daniel E. schrieb:>> Hätte nicht gedacht das es so viele verschiedene Library’s gibt und>> Adafruit so langsam ist …>> Jaja, es sind immer Andere schuld . . .
Sorry, wo hab ich geschrieben das andere Schuld sind?
Nochmal, wenn Du so einen Plan davon hast, müssen das andere nicht
haben und man kann seine Message auch anders rüber bringen. Zumindest
hab ich diese Message nicht "willkommen" aufgenommen.
Danke für deinen Support !
Daniel E. schrieb:>>> Hätte nicht gedacht das es so viele verschiedene Library’s gibt und>>> Adafruit so langsam ist …>>>> Jaja, es sind immer Andere schuld . . .>> Sorry, wo hab ich geschrieben das andere Schuld sind?
"Adafruit so langsam ist"
> Nochmal, wenn Du so einen Plan davon hast, müssen das andere nicht> haben und man kann seine Message auch anders rüber bringen. Zumindest> hab ich diese Message nicht "willkommen" aufgenommen.
Tja, Kritikompetenz ist nicht jedermanns Sache.
https://de.wikipedia.org/wiki/Kritikkompetenz#Passive_Kritikkompetenz> Danke für deinen Support !
Support? Bin ich eine äonische Säule?
Ob S. schrieb:>> Auf PC ist das so üblich.>> ???>> "Auf dem PC" ist ja nun doch ein sehr weites Feld. Offensichtlich hast> du nur einen sehr kleinen Teil davon beackert.>> Also nein: Es ist im Gegenteil absolut unüblich, Schrift per default mit> transparentem Hintergrund auszugeben.
Dann schau dir mal das angehängte Beispiel an. Am Screenshot siehst du,
dass der Text wie mit einem Stift gezeichnet wird. Der Hintergrund wird
nicht automatisch gelöscht.
Das ist der Default unter Linux, Windows und eben auch bei der Adafruit
Bibliothek.
Noch ein Beispiel, dieses mal in Javascript. Wie du siehst haben wir
auch dort das gleiche Default Verhalten.
Ebenso ist es bei GTK und MFC. Ich kenne es im PC Umfeld gar nicht
anders.
Falk B. schrieb:> void setTextColor(uint16_t c) { textcolor = textbgcolor = c; }
Das heißt, wenn man diese Funktion nutzt, wird Vorder- und
Hintergrundfarbe auf den selben Wert gesetzt? Das erscheint mir wenig
zweckmäßig.
Rolf M. schrieb:>> void setTextColor(uint16_t c) { textcolor = textbgcolor = c; }>> Das heißt, wenn man diese Funktion nutzt, wird Vorder- und> Hintergrundfarbe auf den selben Wert gesetzt?
Ja, aber das ist ein Trick, denn praktisch würde damit keinerlei Schrift
sichtbar werden.
> Das erscheint mir wenig> zweckmäßig.
Damit wird der Software mitgeteilt, den Hintergrund transparent zu
halten, d.h. die "weißen" Stellen der Schriftzeichen überschreiben den
Bildschirminhalt NICHT. Das könnte man auch anders lösen, indem man
einen expliziten Farbcode für Transparent erfindet. Hat man aber nicht.
Stefan F. schrieb:> Dann schau dir mal das angehängte Beispiel an. Am Screenshot siehst du,> dass der Text wie mit einem Stift gezeichnet wird. Der Hintergrund wird> nicht automatisch gelöscht.>> Das ist der Default unter Linux, Windows und eben auch bei der Adafruit> Bibliothek.
Das mag ja, sein aber durch die Funktion in der Methode text ist es die
EINZIGE Schreibmöglichkeit! Das nervt!
Rolf M. schrieb:> Das heißt, wenn man diese Funktion nutzt, wird Vorder- und> Hintergrundfarbe auf den selben Wert gesetzt? Das erscheint mir wenig> zweckmäßig.
Einfach mal den Kommentar lesen, der direkt darüber im Quelltext steht:
> For 'transparent' background, background and foreground> are set to same color rather than using a separate flag.
Alles klar? So schwer ist das nicht zu begreifen.
Stefan F. schrieb:> Einfach mal den Kommentar lesen, der direkt darüber im Quelltext steht:
Ach, wer liest schon Kommentare? ;-)
Aber ja, hätte ich lesen können. Bei der zweiten Funktion fehlt diese
Info übrigens, obwohl sie da genauso gilt.
>> For 'transparent' background, background and foreground>> are set to same color rather than using a separate flag.>> Alles klar? So schwer ist das nicht zu begreifen.
Naja, so richtig elegant ist das aber auch nicht.
Daniel E. schrieb:> Guckst hier:>> https://drive.google.com/file/d/1hxkgZNgkjiBPyoYnEuoumAc_CV_7xy0B/view?usp=sharing>> Läuft flüssiger mit anderer Libary :-)
Flüssig genug für die Anwendung und deine persönlichen Wünsche?
> Großes Zeichen dauert 20 ms und kleines 7 ms.
Naja. Ich hab meine TFT-Lib handoptimiert, von erstmal 10ms/Zeichen bei
Zoofaktor 4 auf ca, 4,5ms/Zeichen.
> Long Zahl in EEPROM schreiben dauert 3,3 ms
Hat mit der Anzeige nix zu tun.
Die höhere Geschwindigkeit der anderen Lib dürfte durch eine geringere
Farbtiefe erkauft worden sein. Bei kleineren Zeichen wird die Datenmenge
auch gleich quadratisch kleiner. Und man muss so grobe Klötze in den
Zeichen schön finden…
Aber in diesem Thread ging es ja gerade um einen universellen Pedelec
Controller und die Verwendung des Displays daraus:
Beitrag "Arduino unter Windows stellt sich dumm an"
Die Kingmeter bieten da schon alles, großes Display, (hoffentlich)
wetterfestes Gehäuse und seriell ansteuerbar. Und teuer sind die auch
nicht.
> Flüssig genug für die Anwendung und deine persönlichen Wünsche?>
Ja, reicht vollkommen
>> Großes Zeichen dauert 20 ms und kleines 7 ms.>> Naja. Ich hab meine TFT-Lib handoptimiert, von erstmal 10ms/Zeichen bei> Zoofaktor 4 auf ca, 4,5ms/Zeichen.>
Da bin ich nicht der Spezialist für sowas, Glückwunsch wenn du es drauf
hast, hab mich aber noch nicht damit beschäftigt
>> Long Zahl in EEPROM schreiben dauert 3,3 ms>> Hat mit der Anzeige nix zu tun.
Ist mir vollkommen klar, sollte eher für andere als Information/ Hilfe
sein…
habe mein Testbrett mit dem RPi Pico rausgekramt und das mal mit lvgl
und einem 116 px hohen Font eingebaut, dürfte das gleiche Display sein
(ILI9341 per SPI).