Blaue Schrift auf blauem Grund - Man bin ich ein blöder Hund.

if (blau != blau):
 read(display)
else:
 error()

hm.
kann man evtl. eine Kontrastfolie in anderer Farbe drüber legen, inder 
Hoffnung dass dann der Kontrast minimal sich ändert ?
versuch wäre es wert.

@uwe

genau aus dem grund hab ich ja noch was hoffnung wenigstens ein bissl 
erkennen zu können ... aber wie sich realität und simulation nun mal 
unterscheiden weiß ich halt nicht ob man wirklich soviel erkennen kann 
wie der simulator zu hoffen gibt.
es würde zumindest ein dunkleres blau geben (laut simulator), aber ob 
dem wirklich so ist ....


vllt auch direkt mal eine frage zur initialisierung. laut simulation des 
fpgas schauts gut aus (also die bits kommen alle so an wie es sein 
sollte (!!)). ich habe lediglich zwischen jedem gesetzten byte einmal 
die cs-leitung deaktiviert (also auf high) und dann wieder auf low.
den beispiel-code den ich mir hier angesehen hab lässt die cs leitung 
ganz außen vor. reicht es da wenn die dauerhaft auf low gesetzt wird ? 
(selbst beim reset ...)

Schieb ein Stück weißes Papier drunter.
Irgendwas wirst du dann schon sehen.

aber noch mal eben ne frage zu der initialisierung.
wäre es ein großes problem (sollte doch eig. nicht so sein) wenn ich 
nach jedem gesenden byte die cs-leitung wieder auf high und vorm 
nächsten senden auf low setze, oder kann das bei der initialisierung zu 
problemen führen ?
ich muß mir mal das timing genau auf dem scope angucken, aber die daten 
werden mit ca 5,5 MHz rausgeclockt (also rein rechnerisch, ich werd das 
noch verifizieren), von dahher sollte es ja eig. keine probleme geben 
oder ?

@michael

schau mal unter :

Beitrag "EA DOGM128 128x64 Grafik Display"

nach. daher hab ich den beispielcode. der bringt mir nur leider nix weil 
ich das ganze in einem fpga machen möchte.
mich würd halt interessieren wie es sich mit der cs-leitung verhält. ob 
es (wie oben schon geschrieben) probleme geben kann wenn diese leitung 
während der initialisierung ständig zw. low und high wechselt (was laut 
datenblatt ja nix machen würde).

kleine info für diejenigen die es interessieren könnte :

selbst mit blauer hintergrundbeleuchtung ist das display ablesbar.
sieht zwar nich so schön aus, aber zumindest kann ich dann schonmal 
loslegen. die initialisierung per fpga funktioniert auch (es klappte 
bisher nur nicht weil ich den reset pin lange [knapp ne ms] auf low 
gehalten hab, aber nach dem loslassen nicht gewartet [also einfach die 
"wartezeiten" vertauscht hatte])
klappt aber nun und nun bin ich mal gespannt wie schnell das display ist 
:-)

hochzufrieden nun ist : denn das display ist echt rattenschnell ...
mußte nur mit dem kontrast was spielen damits auch gleichmäßig aussieht. 
aber ich bin begeistert ...
fehlt nur noch die weiße hintergrundbeleuchtung die wohl denke ich 
morgen eintreffen wird.

danke an alle die mir bei der beantwortung der frage hilfreich gewesen 
sind.

zum abschluß des threads mal ein geschwindigkeitsdemo des displays (mit 
immer noch falscher hintergrundbeleuchtung)

Das ist schnell? Programmiere doch mal eine rotierende Erde und zeige 
das Video.

>Kein Kunststück, die dreht sich ja nur einmal in 24 h um ihre Achse. :-)

;-)

außerdem ging es mir in dem video eher darum zu zeigen wie schnell das 
display ist bzw reagiert und nicht die ansteuerung desselbigen. und ich 
denke schneller als das ursprüngliche crystalfontz-display ist es wohl. 
und es sieht auch noch besser aus (wenn denn mal die richtige 
hintergrundbeleuchtung da ist) :-)

@TheMason:

Du solltest eine Abfallverzögerung in die Auswertung einbauen. Das kann 
sonst kein Mensch richtig ablesen.

@benedikt

war auch mein ursprünglicher gedanke bevor ich das dog-modul bestellt 
hab. das problem war/ist nur das ich die bei reichelt nicht bekommen 
kann (zumindest nicht mit 128x64) und ich nicht extra bei crystalfontz 
bestellen wollte (da haben die die oled als 128x64 wohl da).
aber nem schicken oled display werd ich mich demnächst auch mal 
zuwenden. die dinger sehen einfach schweinegeil aus.

@magnus

kommt noch. aber in der ganzen auswertung ist eh noch ein ganz großer 
fehler drin. es wird bei der berechnung des pegels keine wurzel gezogen 
(schande auf meinem haupt). aber ich hab bisher noch nicht die muße 
gehabt das in den fpga zu gießen. der avr könnte das auch übernehmen. 
mal sehen wer der wurzel-rechenknecht werden wird. hab eh noch genug 
umzusetzen (leider passt das alles nicht mehr in einen 644p rein, und 
die 1284p sind ja noch nicht erhältlich grummel). aber die 
peak-anzeige (mit abfallverzögerung) kommt auf jedenfall noch rein ...