pixelfehler mit T6963 bei pixel setzen

[Fabian (Gast)]

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.

[Emperor_L0ser (Gast)]

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

[Fabian (Gast)]

danke für den tipp werde ich nachher mal ausprobieren - ja die 4MHz sind 
an ihrer Grenze...

[pumpkin (Gast)]

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

[Ralf (Gast)]

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