Servus,
ich habe, für mein erstes Projekt nun echt alles alleine hinbekommen,
messen, steuern, regeln, schalten, SD Karte benutzen, Bilder lesen usw.
Nur das mit dem Bargraph bekomme ich nicht so hin wie ich es gerne hätte.
Es soll eine Austeuerungsanzeige sein die sich, recht schnelle ändert.
Wert kommt vom Analog Pin und wird auch dezimal angezeigt.
Wenn ich aber nun einfach ein Rechteck zeichen lasse und das jedesmal wieder lösche, was ich mit einfachem
überschreiben mit der Hintergrundfarbe mach, siehts echt rückelig aus.
Ich habe noch ein Delay von 250ms drin den ich gerne beibehalten würde weil meine Zahlenwerte sonst wie wild
springen.
Aber wie erreiche ich einen horizontalen Bargraph der zu einem schnell ist aber nicht flackert und dabei nicht
zu hektisch zuckt?
Ich hab einen Mega 2560R3 mit 3,2" TFT Touch und UTFT.
Gruß
Chris
Wenn du wirklich delay() verwendest, dann statt dessen millis() nehmen
Du kannst es noch etwas optimieren wenn du nicht das gesamte Rechteck löscht sondern nur die Differenz zwischen altem und neuem.
Ansonsten bekommst du bei sowas ein gewisses Ruckeln nicht weg. Die Displays sind baubedingt langsam. Für jeden Pixel müssen drei Bytes über relative langsame I/Os übertragen werden. Und das nur für die Farbe. Dazu kommen dann noch Dinge wie Steuer-Kommandos, wobei da vielleicht nicht für jeden Pixel eins schicken muss. Aber es ist ein recht hoher Datenumfang da und das dauert.
Wirklich schnelle Displays haben selbst einen Prozessor drauf, der diese Berechnungen übernimmt statt den eigentlichen Prozessor damit zu belasten. Die sind aber teuer.
Wenn du es auch nur annähernd bildschirmfüllend haben willst: vergiss es.
Nen paar Balken dagegen gehn schon, wenn du den Code wirklich so optimierst, wie Serenifly empfahl.
Berechnen geht fix-schreiben dauert. Also: wirklich nur die Pixel schreiben, die sich auch ändern!
Nachtrag: eventuell bist du schneller (ich kenne das Ding nicht, da ich aus Vernunftgründen nur kleinere Displays benutze) wenn du statt Pixeln nen passendes Zeichen benutzt. Kann schneller sein-muss nicht (je nachdem, ob die im Grafikmodus geschrieben werden oder nicht).
Rabenauge:
Nachtrag: eventuell bist du schneller (ich kenne das Ding nicht, da ich aus Vernunftgründen nur kleinere Displays benutze) wenn du statt Pixeln nen passendes Zeichen benutzt.
Text wird genauso Pixel für Pixel geschrieben. Die Displays haben keinerlei Intelligenz. Sowas wie einen Graphikmodus gibt es daher nicht.
Die Displays sind aber nicht so schlecht wie sie von einigen hier verschrien werden. Je nachdem was man damit macht. Für umfangreiche, bewegende Graphiken sind sie nicht so geeignet, aber ich sehe den Zweck in erster Linie als Eingabegerät. Einen Bildschirm mit Knöpfen zum Drücken ist kein Problem. Für das bin ich damit zufrieden.
:*
Langsam bleiben sie dennoch. Bei solchen Intervallen (250ms) sind aber selber LCD16x02 langsam.
Für Messwerte Ausgaben ansonsten aber ganz brauchbar, wenn man >= 1s immer ein Update macht.
Solche Bargraphen kann man auch recht einfach lösen, siehe Vorschlag Serenfly. Ich hatte sowas mal, der mir mehrere Variablen, die ich über Encoder eingestellt habe, darstellt. Hab es da auch so gemacht, dass ich die Werte abgeglichen habe und danach nur die errechneten neuen Zeilen/Spalten beschrieben habe.
Vielen Dank für die Antworten,
ich messe damit ein paar Spannungen, manche zeige ich an, andere werden umgerechnet als Temperatur (NTC), ein wenig Strom messen bis 60A und demnächst noch eine Menüstruktur und ein paar Relais schalten.
Dafür reicht das Display echt locker aus!
Den Balken anzeigen ist ja einfach:
DPA_LCD.fillRect(0, 70, P_Graph, 90);
P_Graph ist eine Spannung die hochgerechnet wird damit aus zb 3V 180 Pixel enstehen.
Nun müsste ich ja aber P_Graph dazu belommen, dass der vorherige Wert noch verfügbar ist.
Eigentlich ein "einfacher" Vergleich:
Wenn P_Graph == P_Graph ist, nix machen
Wenn P_Graph < P_Graph ist dann P_Graph - P_Graph und ein Rechteck mit passender Größe mit Hintergrundfarbe erzeugen,
das wäre dann "löschen" was zuviel an Balken da ist.
Wenn P_Graph > P_Graph dann ausrechnen wieviel Pixel dazu kommen und Rechteck zeichnen.
ABER!
Woher weiß ich denn nun wie hoch der Wert eine Berchnung vorher war als gemessen wurde?
Dazu müsste ich den "alten" Wert doch noch irgendwo behalten?
Gruß
Chris
In dem du deinen letzten Wert in eine statische Variable packst! 
Bavarian:
Dazu müsste ich den "alten" Wert doch noch irgendwo behalten?
Und wo ist da das Problem? Entweder den alten Messwert speichern oder die alte Koordinate.