Adafruit_ILI9341.h einzelnes Zeichen überschreiben

[Daniel E. (everyday_fun69)]

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.

      if (Einer != Old_Einer)                     // Wenn alter und neuer Wert unterschiedlich
        {
        tft.setTextColor(ILI9341_BLACK);          // Farbe wie Hintergrund
        tft.setTextSize(15);                                              
        tft.setCursor(82, 10);
        Befehl für Kästchen?;                      // überschreibe vorherige Zahl mit leerem zeichen
        tft.setTextColor(ILI9341_WHITE);           // Farbe wie Vordergrund
        tft.println(Einer);                        // schreibe neue Zahl
        }

Vielen Dank schon mal

[Falk B. (falk)]

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.

[J. S. (jojos)]

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.

[Daniel E. (everyday_fun69)]

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 !

[Falk B. (falk)]

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!

[Daniel E. (everyday_fun69)]

> 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

[Falk B. (falk)]

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.

  /**********************************************************************/
  /*!
    @brief   Set text font color with transparant background
    @param   c   16-bit 5-6-5 Color to draw text with
    @note    For 'transparent' background, background and foreground
             are set to same color rather than using a separate flag.
  */
  /**********************************************************************/
  void setTextColor(uint16_t c) { textcolor = textbgcolor = c; }

  /**********************************************************************/
  /*!
    @brief   Set text font color with custom background color
    @param   c   16-bit 5-6-5 Color to draw text with
    @param   bg  16-bit 5-6-5 Color to draw background/fill with
  */
  /**********************************************************************/
  void setTextColor(uint16_t c, uint16_t bg) {
    textcolor = c;
    textbgcolor = bg;
  }

Die Funktion ist überladen (C++) und kann in 2 Versionen aufgerufen 
werden.

[J. S. (jojos)]

tft.setTextColor(ILI9341_WHITE, ILI9341_BLACK);
mehr brauchts nicht, nix selber überschreiben.

https://learn.adafruit.com/adafruit-gfx-graphics-library/graphics-primitives

[Falk B. (falk)]

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. (falk)]

if (Einer != Old_Einer) {
    // Farben für Vorder- und Hintergrund setzen
    // dadurch vollständiges Überschreiben der alten Zeichen   
    tft.setTextColor(ILI9341_BLACK, ILI9341_WHITE); 
    tft.setTextSize(15);                                              
    tft.setCursor(82, 10);
    tft.println(Einer);
    Old_Einer = Einer;
}

[Daniel E. (everyday_fun69)]

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.

[Falk B. (falk)]

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!

[Stefan F. (Gast)]

Daniel E. schrieb:
> Befehl für Kästchen?;

writeFillRect()

Verwende dabei die Hintergrundfarbe.

[Falk B. (falk)]

Stefan F. schrieb:
>> Befehl für Kästchen?;
>
> writeFillRect()
>
> Verwende dabei die Hintergrundfarbe.

Noch so ein Blinder! OMG!

[Stefan F. (Gast)]

Könnte am Custom Font scheitern

[J. S. (jojos)]

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.

[Falk B. (falk)]

Ich habe es gerade mal mit meinem ollen 1,8 Zoll TFT getestet. Da gibt 
es einen Fehler in Adafruit_GFX.cpp in

void Adafruit_GFX::text(const char * text, int16_t x, int16_t y) 
{
  if (!useStroke)
    return;
  
  setTextWrap(false);
  //setTextColor(strokeColor);
  setCursor(x, y);
  print(text);
}

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.

[Daniel E. (everyday_fun69)]

Hallo zusammen,

hab mal verschiedene Sachen probiert, Zahl mit selbiger überschreiben 
und Rechteck drüber schreiben.

Alles beides ist shit und für meine Anwendung und als Tacho (große 
Zahlen)/ Km Zähler (kleinere zahlen) völlig ungeeignet.

https://drive.google.com/file/d/1JLWbUT3ZVsdMNp0yrE92ZCNP3V5ijTSA/view?usp=sharing

https://drive.google.com/file/d/126FU2WvVdOqadxrbY1ACWbk_fWM19DjM/view?usp=sharing


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?

Danke

[J. S. (jojos)]

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.

[Falk B. (falk)]

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.

[J. S. (jojos)]

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.

[Falk B. (falk)]

Siehe Anhang! Das hab ich nicht von Aliens runtergeladen!

https://www.arduino.cc/reference/en/libraries/tft/

[J. S. (jojos)]

na supi:
Note: this library was retired and is no longer maintained.

Und selbst da gibt es deine Codezeilen nicht:
https://github.com/adafruit/Adafruit-ST7735-Library/blob/1.0.6/Adafruit_ST7735.cpp

und auch wenn Code von Arduino gepflegt wird heisst es nicht das er 
nicht verbastelt sein kann...

[Falk B. (falk)]

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.

[Daniel E. (everyday_fun69)]

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

[Falk B. (falk)]

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.

[J. S. (jojos)]

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.

[Falk B. (falk)]

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!

[Daniel E. (everyday_fun69)]

@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

[Stefan F. (Gast)]

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.

[J. S. (jojos)]

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.

[J. S. (jojos)]

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.

[Daniel E. (everyday_fun69)]

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

[Stefan F. (Gast)]

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.

[Thomas F. (igel)]

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.

[Ob S. (Firma: 1984now) (observer)]

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?

[Falk B. (falk)]

Thomas F. schrieb:
> Eventuell ist einfach die verwendete Bibliothek nur langsam
> programmiert.

Das ist ein klassisches OSI Layer 8 Problem ;-)

[Daniel E. (everyday_fun69)]

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

[J. S. (jojos)]

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. (falk)]

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

[Daniel E. (everyday_fun69)]

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 !

[Falk B. (falk)]

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?

[Stefan F. (Gast)]

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.

[Stefan F. (Gast)]

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.

[Rolf M. (rmagnus)]

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.

[Falk B. (falk)]

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.

[Falk B. (falk)]

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!

[Stefan F. (Gast)]

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.

[Rolf M. (rmagnus)]

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.

[Stefan F. (Gast)]

Rolf M. schrieb:
> Naja, so richtig elegant ist das aber auch nicht.

Spart immerhin ein Byte.

[Daniel E. (everyday_fun69)]

Guckst hier:

https://drive.google.com/file/d/1hxkgZNgkjiBPyoYnEuoumAc_CV_7xy0B/view?usp=sharing

Läuft flüssiger mit anderer Libary :-)
Großes Zeichen dauert 20 ms und kleines 7 ms.
Long Zahl in EEPROM schreiben dauert 3,3 ms

Danke.

[Falk B. (falk)]

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.

[J. S. (jojos)]

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.

[Daniel E. (everyday_fun69)]

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

[J. S. (jojos)]

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