Moin.
Bin gerade dabei, ein Handy-Display an nem AVR zum laufen zu kriegen. Geht soweit auch fast.
Um ein Pixel darzustellen, werden 2 Byte = 16 Bit benötigt, wobei die Anzahl der Bits pro Farbe Rot:Grün:Blau = 5:6:5 ist.
Da die Eingabewerte aus dem 3-Byte-System kommen (also pro Farbe 0-255), habe ich eine Funktion, die die Werte entsprechend anpassen soll:
R, G1, G2, B1, ColorData1, ColorData2 jeweils Byte; SendData = Funktion zur Ausgabe der Daten.
Dabei soll das erste Byte (ColorData1) aus den 5 höherwertigsten roten Bits und den 3 höherwertigsten grünen Bits bestehen.
Das zweite Byte (ColorData2) soll aus den Grünbits 4-6 sowie den höherwertigsten blauen Bits bestehen.
Bei einem Testbild klappen die Farben Rot (Setpixel 255,0,0), Gelb (Setpixel 255,255,0) und grün (Setpixel 0,255,0) problemlos.
Nur blau geht irgendwo verloren. Wenn ich mit Setpixel 0,0,255 blau erzeugen möchte, erscheint der Bereich schwarz; gleiches mit weiss (255,255,255): erscheint als gelb.
Schreibe ich statt "SendData ColorData2" gleich "SendData &B00011111" (also alle Blaubits auf 1), dann wird korrekt ein blauer Bereich erzeugt.Code:Sub SETPIXEL(RED AS BYTE , GREEN AS BYTE , BLUE AS BYTE) If ColorMode = MODE_16Bit Then R = RED AND &b11111000 G1 = GREEN AND &B11100000 G2 = GREEN AND &B00000111 B1 = BLUE AND &B11111000 SHIFT G1 , right , 5 SHIFT G2 , left , 5 SHIFT B1 , right , 3 ColorData1 = R OR G1 ColorData2 = G2 OR B1 SendData ColorData1 SendData ColorData2 EndIf End Sub
In dem Codeteil muss also irgendwo die Information für Blau verlorengehen. Nur find ich nicht wo...
Sieht jemand den Fehler?
MfG
schau mal in 9.5 ten zeile.
da steckt ein rosaroter panther und malt immer über die blaue farbe drüber
ne - mal im ernst:
erst mal muss es heisen
G2 = GREEN AND &B00011100
sollen ja die zwei niedrigsten bits unter den tisch fallen, oder?
dann muss da sein
SHIFT G2 , left , 3
Bist du denn sicher, das BLUE richtig übergeben wird?
Wenn da nichts kommt, kannst du viel hin und herschieben.
Gruß
Rolf
ups... stimmt... hab da die falschen 3 Bits erwischt; sollen tatsächlich die mittleren 3 sein, nicht die letzten... hätte sich wohl auch nur bei "Zwischenfarbstufen" mit grün ausgewirkt;
Der blaue Bereich bleibt aber weiterhin schwarz...
Wenn ich beim Initialisieren des LCD die Befehlsfolge von RGB auf BGR "umdrehe", dann gibts das gleiche Problem, nur eben mit rot; es scheint also so, als wäre ColorData2 immer 0 (was aber nach Simulator nicht der Fall ist)
Nachtrag: der Wert für BLUE wird korrekt übergeben (zumindest lt. Simulator)
also wenn colordata2 mit > 0 an senddata übergeben wird, dann brauchen wir in obigem code nicht weiter nach fehlern zu suchen!
kann man denn die 16bit wirklich in 2 bytes an das display schicken, oder muss das womöglich in einem rutsch erfolgen (ist der zeitliche abstand zwischen den beiden senddata zu groß)?
womöglich irgendwas am display nicht richtig für die communikation eingestellt?
womöglich ein hardwareproblem (timing bei datenübergabe) ?
was für ein display ist es denn?
ich hab auch mal drüber nachgedacht ein hdy-display zu benutzen.
jemand meinte, die seien schwierig zu kontaktieren, weil die anschlüsse so klein sind.
In dem Codestück find ich ja auch keine Fehler, darum hab ichs ja hier mal reingestellt, ob ja doch einer drin ist.
Dass es in einem Durchgang sein muss, glaub ich nicht, da es ja funktioniert, wenn ich statt dem ColorData2 direkt &B00011111 sende. (oder direkt &B11111111, dann hat das blau nen leichten Grünstich), die Kommunikation an sich klappt, da ja die anderen Farben soweit fehlerfrei arbeiten.
Das Display selbst ist von nem Nokia 6100; Programmvorlage stammt von thomaspfeifer.net; wurde von C nach Bascom übersetzt. Und da isses eigentlich auch so. (Nur werden da vom grünen Wert tatsächlich die letzten 3 Bits verwendet, wie bei dem hier geposteten Code von mir)
Das Problem mit dem Kontaktieren hatt ich auch; mit ner Adapterplatine auf 2,54mm-Raster gehts aber problemlos.
*ratlos*
Scheint wirklich so, als würde das Programm im AVR was anderes machen als im Simulator...
wenn es mit senddata &B00011111 geht, dann kannst du nur noch die einzelnen zwischenwerte davor kontrollieren.
wenn das alles stimmt, dann könnts natürlich ein compilerfehler sein.
aber das ist nun wirklich sehr unwahrscheinlich (aber nicht unmöglich)
gibts da vielleicht irgendwelche optimierungsoptionen?
die können schon mal dafür sorgen, das der resultierende maschinencode nicht mehr dem hochsprachencode entspricht.
mir ist noch aufgefallen das du einmal &B00xxx und einmal &b00xxx schreibst. aber das ist vermutlich egal, oder?
Gross/Kleinschreibung ist bei Bascom (u.a. auch VBasic, QBasic) im Gegensatz zu C egal.
Aber hab das Problem jetzt umgangen; ich hab mir die Funktion umgebaut, so dass ich die Farbe als HTML-Farbcode-String ("FF00FF" für Magenta z.B.) abspeicher und in der Funktion dann zerlege.
Also die Hex-Anteile in 3 Bytes umwandeln, da dann die gleiche Bit-Schieberei wie im ersten Versuch... und siehe da: So klappts.
Code:
Code:... 'Aufruf: ColorString = "FFFF00":SetPixelHex ... Sub SetPixelHex StrRed = mid(ColorString , 1 , 2) StrGreen = mid(ColorString , 3 , 2) StrBlue = mid(ColorString , 5 , 2) BRed = hexVal(StrRed) BGreen = hexVAL(StrGreen) BBlue = hexVAL(StrBlue) R = BRed AND &B11111000 G1 = BGREEN AND &B11100000 G2 = BGREEN AND &B00011100 B1 = BBLue AND &B11111000 SHIFT G1 , right , 5 SHIFT G2 , left , 3 SHIFT B1 , right , 3 ColorData1 = R OR G1 ColorData2 = B1 OR G2 SendData ColorData1 SendData ColorData2 End Sub
prima, dann weißt du jetzt, das vermutlich mit der parameterübergabe etwas nicht in ordnung war.
würde sich womöglich lohnen dem problem trotzdem weiter nachzugehen - für künftige programme.
wie ist denn der zusammenhang zwischen logischem UND und bitweise UND beim bascom?
in C gibts ja unterschiedliche operatoren, die u.a. das höchste bit/vorzeichen unterschiedlich behandeln. bei bitoperationen muss man sich solche details immer genau anschauen.
ebenso beim shift. das kann man logisch oder bitweise interpretieren (mit unterschiedlichem ergebnis)
Also lt. Simulator wurden die Parameter davor ja auch übergeben... aber lt. Hardware dann doch nicht. Wo genau da dann was veroren ging, wird sich wohl nie herausstellen.
Soweit ich das in Bascom kenn, sind logisches und bitweises Und der gleiche Befehl (AND), je nach Kontext.
"x = 8 AND 4" liefert x = 0; aber es geht auch "IF x>2 AND x<10"
Beim Shift isses auch so, dass da die Bits verschoben werden, wobei dass dann halt nicht nur bei Byte-Variablen sondern auch z.B. Word geht.
(Anders als bei "Rotate" gehen bei "Shift" die rausgeschobenen Bits verloren)
Naja mit der Technik gehts jetzt; was halt jetzt noch ansteht, ist ne Optimierung, da der Bildaufbau mit 6 sec doch noch etwas lang dauert.
Lt. Datenblatt kann der Controller nen Clock-Schaltabstand von 60ns, in Bascom kann ich aber nur bis 10µs runter, noch kürzere Abstände kann das Display dann doch nicht mehr.
Angenommen ich würde nun ohne Pausen die Ports nacheinander direkt setzen, und dazu würde man nur einen Takt brauchen, dann würde ein Takt bzw. Schaltvorgang bei 8 MHz nur 125 ns dauern, sollte also ohne Pausen auch ausreichen. Aber erst ab Pausen von 10µs reagiert das Display darauf. (Befehl waitus 10 bzw. Sprung in ne Sub mit ein paar NOP drin)
Berechtigungen
Zitieren
Lesezeichen