Hallo, kann jemand helfen, wo man Tips oder Code-Schnipsel einen Progressbar(Anzeige-Balken) für ein GLCD mit KS0108 finden könnte? Besten Dank im Voraus!
Ahja, auf solche Konstruktivitäten habe ich gelauert. Danke!
naja wer das nicht weiß wie das geht.. bist wohl arduino user? echt eine frechheit .. schimpft sich embedded systems programmieren und verwendet arduino .. lachhaft!
erster Vorschlag: http://community.robo3d.com/index.php?threads/full-graphics-lcd-controller-percent-complete-mod.3835/ ein weiteres Suchwort könnte bar graph sein ...
:) Naja wo ist genau das Problem? Wenn dein Bargraph/Fortschrittsbalken 90% Anzeigen soll lässt Du SetPixel halt 90 mal in einer for-schleife laufen. x oder y von SetPixel mit der Variable ersetzen die in der for-schleife hochgezählt wird. Die Funktion SetPixel hab ich frei erfunden, irgendwas in der Art wirst Du ja schon haben..... Jedenfalls gehe ich mal stark davon aus das Du dir eine Lib irgendwo her kopiert hast, sonst würde deine Frage eher lauten : Wie bekommt man ein GLCD mit KS0108 ans laufen? Codeschnipsel gibt's hier . Wunderbar portabel in win32 asm ;) http://www.winasm.net/forum/index.php?showtopic=4063
Wenn man eine Bibliothek verwendet, die gefüllte Rechtecke darstellen kann.. Links (x) und oben (y) = Startpunkt oben links, Höhe = Balkendicke Breite = skalierter Wert, d.h. wenn der Rohwert z.Bsp 0..2048 sein kann und der Balken auf dem Display nur 64 Pixel breit sein soll, muss gerechnet werden Breite = Rohwert / (max. Rohwert / max._Balkenbreite). Vor dem Zeichnen eines neuen Wertes, sollte ein "Löschbalken" mit max. Breite gezeichnet werden.
BirgerT schrieb: > Vor dem Zeichnen eines neuen Wertes, sollte ein "Löschbalken" mit max. > Breite gezeichnet werden. je nachdem wie oft man den Balken aktualisiert ist es besser immer den "IST"-Bereich zu zeichnen und nur den Restbereich zu löschen. Dann blinkts nicht so lästig. Sascha
Besten Dank erstmal für die Antworten. Alle Gagas mögen aufatmen, das GLCD wird mit einem PIC angesteuert. Also nix Arduino oder so. Und ja, es läuft schon einges und es gibt auch eine Bibliothek. Für jene hatte ich mir mal Fragmente irgendwo hergeholt und das solange geändert und angepaßt, bis es ging. Erstaunlicherweise stellt man später beim Stöbern fest, dass man oft auf die gleichen Ideen kommt, wie andere. Jetzt bin ich dabei, dem Projekt einen Bootlader zu gönnen und da soll die Balkenanzeige laufen. Das Auge isst ja mit. Ein Rechteck zu zeichnen und zu füllen ist auch kein Problem. Das aber beginnt, wenn sich der Balken schnell ändern soll. Den kompletten Balken jedesmal zu löschen und neu zu zeichnen, verbietet sich wegen der Zeitverzögerung des Displays. Es muß demnach eine Art mathematisches Modell her(mal übertrieben ausgedrückt), welches nur die zu ändernden Teile löscht und/oder neu ergänzt. Das traue ich mir auch noch zu. Nur hatte ich gehofft, mit ein klein bißchen der Mühe ersparen könnte, wenn mir am Ende eh ähnliches einfällt, wie anderen.
Suchender schrieb: > Es muß demnach eine Art mathematisches > Modell her(mal übertrieben ausgedrückt), welches nur die zu ändernden > Teile löscht und/oder neu ergänzt. Einfach von links beginnend mit der Vordergrundfarbe zeichnen und dann von rechts beginnend mit der Hintergrundfarbe jeweils bis zur aktuellen Balkenposition.
Suchender schrieb: > Ein Rechteck zu zeichnen und zu füllen ist auch kein Problem. Das aber > beginnt, wenn sich der Balken schnell ändern soll. Eigentlich nicht. Denn die Zeichenroutine braucht den Balken nur dann ändern, wenn sich auch der anzuzeigende Wert signfikant ändert. Damit ist gemeint: Wenn dein Balken 100 Pixel breit ist und deine ansteuernde Routine erhöht die Prozentzahl von 48.8% auf 48.9%, dann kann der graphische Update ausfallen, weil kein Benutzer einen Unterschied sehen würde. Auch macht es keinen Sinn, den Balken pro Sekunde 100 mal mit anderen Werten hinzumalen. Denn kein Benutzer dieser Welt kann da noch irgendeine sinnvolle Information bei diesem Update-Tempo (selbst wenn das LCD da mitkommen würde) entnehmen. Für praktische Zwecke reicht es sogar oft aus, wenn man den Balken nur alle paar Prozent (je nach Länge des Balkens) updated, denn für einen Benutzer ist es ziemlich uninteressant, ob du per UART jetzt 28.5% oder doch schon 30% übertragen hast. Es ist ungefähr 1/3 auf dem µC gelandet und diese Information ist mehr als ausreichend. Manchmal ist das kleben ab zu genauen Zahlenwerten mehr eine Bürde als eine Hilfe (manchmal muss es aber auch genau sein). Sieh einen Fortschrittsbalken als grafische Hilfe an, mit der ein Benutzer eine Relation eines Teiles zum Ganzen herstellen kann. Menschliche Benutzer arbeiten aber gerne 'überschlagsmässig' und nicht auf 2 Nachkommastellen genau. Wir erkennen eine 'Halbe Bier' an der Größe des Glases und nicht daran, dass da exakt 500ml Bier drinnen ist. Für uns ist ein derartiges Glas auch dann noch 'halbvoll', wenn da nur noch 220ml Bier drinnen sind. Mehr Mut zur 'Ungenauigkeit', wenn sich dadurch die zu transportierende Information leichter transportieren lässt! Beobachte dich doch selbst mal, wenn du aus dem Web was downloadest: Interessiert es dich wirklich, dass du 48675 Bytes von 198765 Bytes schon erhalten hast? Ich würde mal sagen: nein, die genauen Zahlen interessieren dich nicht. Du hast 24.48%, also praktish ein Viertel. Dafür musstest du 3 Minuten warten, also kannst du damit rechnen, dass der Rest ca. noch 9 Minuten dauern wird. Das interessiert dich. Aber ob das 48675 oder doch schon 48679 Bytes waren, interessiert nicht. > Den kompletten Balken > jedesmal zu löschen und neu zu zeichnen, verbietet sich wegen der > Zeitverzögerung des Displays. Es reicht völlig, wenn der Balken neu gezeichnet wird, wenn er sich signifikant geändert hat. Signifikant könnte bei dir zb bedeuten: wenn sich die Pixeldarstellung ändert.
:
Bearbeitet durch User
Naja, bei 100% oder Pixel würde ich das Ding eh nur Prozent-weise ändern. Sicher hast Du Recht, dass es sich -im Falle eines schnöden Bootladers erst recht- nicht immer lohnt, das Ding kurzfristig zu ändern. Wenn ich den Balken aber einmal machen, dann hätte ich ihn gerne so, dass ich die Funktion zu anderen Aufgaben nutzen kann. Weiß ich, beispielsweise zur Anzeige eines Mikrofon-Pegels oder so. Da sollte es dann schon recht flott und einigermaßen genau gehen.
Suchender schrieb: > Wenn ich den Balken aber einmal machen, dann hätte ich ihn gerne so, > dass ich die Funktion zu anderen Aufgaben nutzen kann. Niemand hindert dich. > Weiß ich, > beispielsweise zur Anzeige eines Mikrofon-Pegels oder so. Da sollte es > dann schon recht flott und einigermaßen genau gehen. Das ist dann aber kein Progress Bar mehr. An dieser Stelle hast du dann identifiziert, dass es sich wohl lohnen würde/könnte, die Aufgabenstelung etwas aufzuteilen. Auf der einen Seite steht die Funktionalität einen Bar zu zeichnen. Das geht allgemein. Die Aufgabe besteht nur darin, aus dem Minimum/Maximum Wert, dem aktuellen Wert und den Pixelwerten des Bars eine entsprechende graphische Anzeige zu generieren. Das hört sich jetzt mglw. einfacher an als es sein könnte. Denn zur 'Optimierung' kann man sich zb Gedanken darüber machen, was bei einem Update des aktuellen Wertes jetzt schneller geht: den ganzen Bar neu zeichnen oder zu bestimmen, welche Teile des Bars sich ändern und dann nur diese Änderungen graphisch zu implementieren. Da ist noch viel Potential für Zeitsparer. Darauf aufbauend gibt es dann Funktionen für einen Progressbar, die den somit bereits vorhandenem Bar eine gewisse Update Characteristik aufprägt. Und es könnte eine andere Form eines Bars (für Wertanzeige) geben, die nicht ganz so träge reagiert. Vielleicht gelingt es auch, diese 'Trägheit' in eine allgemeine Form zu giessen, die nur durch einen Parameter eingestellt wird.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.