Ich versuche gerade ein 320*240 Grafik LCD mit SED1335 (S1D13305) dazu zu bringen Linien zu zeichnen. So halb funktioniert es auch, Linien sind schon erkennbar, nur etwa alle 8 Pixel hat die Linie eine Unterbrechung und/oder von der Linie aus geht ein kurzer Strich senkrecht nach unten. Die Routine zum Linienzeichnen läuft auf einem anderen LCD problemlos, daher vermute ich, dass es an der set_pixel Routine liegt. Zeichne ich mehrere Pixel mit einer for Schleife mit den Koordinaten (x,x), dann ist die Linie zwar fehlerfrei, aber alle 8 Pixel gibt es unregelmäßige Spitzen nach unten... Um einen Pixel zu setzen, lese ich ein Byte vom LCD, setze ein Bit und schreibe es zurück. Im Datenblatt des SED1335 findet sich bei der Beschreibung des MREAD Befehls (Daten vom LCD lesen) folgender Satz: If the cursor is displayed, the read data will be from two positions ahead of the cursor. Was heißt das jetzt im Klartext ? Muss ich die Daten von Adresse x-2 lesen, den Pixel setzen und dann an Adresse x zurückschreiben ? Hier meine set_pixel Routine: lcd_writecom(0x46); i=(unsigned int)40*y+(x/8)+1200; lcd_writebyte((char)i); lcd_writebyte(i/256); lcd_writecom(0x43); //Read Data c=lcd_readbyte(); lcd_writecom(0x46); lcd_writebyte((char)i); lcd_writebyte(i/256); lcd_writecom(0x42); //Write Data c|=1<<(7-(x&7)); lcd_writebyte(c);
Hat denn echt noch niemand Linien auf einem SED133x gezeichnet ?
Ich glaube zwar nicht, das es daran liegt, aber versuche mal statt mit (7-(x&7) das Pixel an die richtige stelle zu schieben mit einer Invertierung von X AND 7. Also so wie 1 << (X invertieren AND 7). Vielleicht dann so: c|=1<<(X^&7)!?! Behersche kein, C habe aber schon Linien und einiges mehr für den T6963C in ASM gemacht. So, wie es aussieht, ist Deine Routine laut Datenblatt OK, vermute nur einen Fehler bei der Bitposition für den Pixel. MfG Andi
Ach ja, kannst ja noch Deine Linien-Routine zeigen, vielleicht liegt ja dort bei der Berechnung von X und Y der Fehler. In meiner Line-Funktion ermittel ich zuerst über die längeren Achslängen von X oder Y die primäre Richtung. Ist die X-Achse (X2-X1) länger als die Y-Achse (Y2-Y1) ist die primäre Richtung horizontal, also der X-Achse entlang. Mittels subtraktion der Y-Achse von der X-Achse und Unterlauf wird festgestellt, wann die Y-Position um 1 versetzt wird. Habe schon die eine oder andere Art einer Linien-Funktion mit 3-Satz Berechnung gesehen und das ist absoluter Mumpitz. MfG Andi
An der Linienroutien liegt es sicher nicht, die läuft auf einem T6963 einwandfrei. Für den Test habe ich eine Schleife von 0-100 laufen lassen und die Pixel auf (i,i) gesetzt. In der Pixelsetzroutine habe ich jetzt mal nur den Wert gelesen und wieder ausgegeben, ohne ein Bit zu setzen. Ergebnis: siehe Bild Wenn ich die Bits setzte kommt zusätzlich noch die fehlerfreie Linie hinzu
Hi das hier: void gfx_xy(unsigned int x, unsigned int y) { unsigned char pos; unsigned char temp; pos = x % 8; if(gfx_draw_color) pos = 0x80>>pos; else pos = (0x7F>>pos)|(0x7F<<(8-pos)); x /=8; y *=40; SET_CLOCK4; GFX_CMD = GFX_CMD_CSRW; GFX_DAT = (unsigned char)(y + x); GFX_DAT = (GFX_ADR_LAY1>>8)+(unsigned char)((y + x)>>8); GFX_CMD = GFX_CMD_MREAD; temp = GFX_CMD; if(gfx_draw_color) temp = temp | pos; else temp = temp & pos; GFX_CMD = GFX_CMD_CSRW; GFX_DAT = (unsigned char)(y + x); GFX_DAT = (GFX_ADR_LAY1>>8)+(unsigned char)((y + x)>>8); GFX_CMD = GFX_CMD_MWRITE; GFX_DAT = temp; SET_CLOCK; } hat hier funktioniert. Das globale gfx_draw_color hat dabei die Zeichenfarbe (Schwarz oder weiß) angegeben. Matthias
ICh verstehe es echt nicht... Jetzt habe ein anderes LCD, neu geschriebene Pixelroutine, und genau wieder dasselbe Problem: Zeichne ich die Pixel ohne ein Byte vom LCD zu lesen, ist alles OK (nur die Linie eben etwas zerstückelt). Zeichne ich die Pixel ohne die Daten wirklich zu schreiben (also nur Wert vom LCD lesen und wieder ins LCD schreiben, also die OR Verknüpfung weglassen), dann ist auchalles OK (nur die Linie fehlt eben). Mache ich beides gibt es rund um die Linie Streuungen, die sich aufaddieren wenn man die Linie mehrfach zeichnet, so dass am Ende 8 Pixel hohe, komplett gefüllte Blöcke entstehen... LCD Controller diesmal: KS0108 (es ist ein 128x64 LCD mit 2 Controllern) lcd_setadress(x, y/8); temp=lcd_readbyte(1+(x/64)); temp2=(unsigned)(1<<(y&7)); temp=temp2|temp; lcd_setadress(x, y/8); lcd_writebyte(temp,1+(x/64));
Es ist sogar noch merkwürdiger: Zeichne ich die Linie woanderst im Grafikbereich und kopiere die Daten dann an die richtige Stelle, dann ist die kopierte Linie OK, aber bei der woanderst gezeichneten sind Störungen rechts/links der Linie und zwar an Bytepositionen die ich garnicht beschreibe !!! Timingprobleme schließe ich aus, da ich den uC schon runtergetaktet habe, und da der Rest der Routinen funktioniert. lcd_setadress(x, 4+y/8); temp=lcd_readbyte(1+(x/64)); temp2=(unsigned)(1<<(y&7)); temp=temp2|temp; lcd_setadress(x, 4+y/8); lcd_writebyte(temp,1+(x/64)); lcd_setadress(x, 4+y/8); temp=lcd_readbyte(1+(x/64)); lcd_setadress(x, y/8); lcd_writebyte(temp,1+(x/64));
Hi hat der KS0108 nicht diese Merkwürdigkeit das man nach dem Setzen der Displayaddresse einen zusätzlichen Lesezugriff machen mußte bevor die richtigen Daten kommen? Doch, ich glaub der war das. Matthias
Ja, genau das wars ! Steht allerdings nicht im Datenblatt. Scheiß Samsungscheißendreck ! Mit zwei lcd_readbytes (also insgesamt 4 Reads) funktioniert es jetzt super !
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.