Hi, ich habe folgendes Problem: Ich stelle auf meinem Display (T6963) 2 Balken da, die sich relativ schnell aktualisieren (increase, decrease) (VU Meter). Mein Problem ist nun, dass ich dabei vereinzelt Pixelfehler habe, d.h. einzelne pixel im balken werden nicht gesetzt, bzw nicht wieder gelöscht, sind zwar relativ wenig, aber sieht halt doch "löchrig" aus... meine Frage... hat jmd. ein ähnliches Problem und / oder hat jemand eine Lösung? Ich verwende zum Setzen der Pixel eine selbst geschriebene Assemblerfunktion, die von dem pixel einzeln setzen gebrauch macht, d.h. für jedes Pixel muss ein byte übertragen werden... ich denke mal das ist sehr uneffektiv und könnte die fehler verursachen. Macht es Sinn das ganze auf den anderen Grafikmodus abzuändern, bei dem ich den ADP setze und dann mit einem byte 8 pixel ändern kann? Der Balken rast in der vertikale umher, d.h. ich müsste dann für die Pixel ganz rechts auch wieder erst ausrechnen, wieviel pixel in der letzten Spalte, in der der Balken sich noch befindet, gesetzt werden müssen.
mit dem T6963 habe ich noch nicht gearbeitet, aber ich könnte mir vorstellen, das der controller selbst auch nicht der schnellste ist. also ähnlich wie ein textdisplay eine weile brauch, bis ein befehl verarbeitet ist, wenn du jetzt sehr hart an der geschwindigkeits grenze arbeitest. kann es da immer mal wieder zu fehlern bei der verarbeitung kommen, also ein befehl einfach nicht ausgeführt wird. probier doch mal aus, wenn du ein "nop" oder eventuell auch mehrere nop's nach dem setzen eines pixels im controller machst. mfg Emperor_L0ser
danke für den tipp werde ich nachher mal ausprobieren - ja die 4MHz sind an ihrer Grenze...
moin jungs, das problem hatte nich nicht auf meinem sharp mit diesem toshiba-controller. wartest du auch wirklich immer auf 'ready' vom controller. hört sich so an als wenn du den toshiba in seiner operation unterbrichst (was mir schleierhaft ist, da er eigentlich stur wie ein panzer ist wenn er ackert). ich kann mich gerade nicht so recht erinnern, aber die pixel schubst man im graphic-array, richtig? pumpkin
Wie bereits erwähnt, wie prüfst du, ob der T6963C ein neues Kommando empfangen darf? Per Wartezeit, oder korrektes abfragen des Status-Bytes? Desweiteren kommts drauf an, wie deine Balken aussehen. Wenn sie z.B. nicht breiter als 8 Pixel sind, und innerhalb eines Bytes liegen (also keine Überschneidung mit dem nächsten Byte) bietet es sich an, eine komplettes Byte zu setzen. Das entsprechende Muster musst du ja nur einmal berechnen, genauso wie die Startposition, denn die nächste Pixelzeile erhältst du, wenn du einfach die Länge einer Zeile draufaddierst. Geht natürlich auch mit breiteren Balken, und auch nicht viel aufwendiger... Ralf
Bitte 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.