C GLCD -> Logo anzeigen..

Janiiix3 · 18. Mai 2017

Wenn ich das jetzt 2 x hintereinander ausführe, passiert nicht das was ich mir erhoffe.
Es werden keine 2 x Balken gezeichnet sondern nur einer? Warum? Es sollten doch eigentlich auf Page 0 & 1 welche gezeichnet werden?

CodeBox C

lcd_sendcmd( 0 | 0xB0 );
lcd_sendcmd(0x10);
lcd_sendcmd(0x00);
for (; Colmn < 128 ; Colmn++)
{
lcd_senddata(0xff);
}

lcd_sendcmd( 1 | 0xB0 );
lcd_sendcmd(0x10);
lcd_sendcmd(0x00);

for (; Colmn < 128 ; Colmn++)
{
lcd_senddata(0xff);
}

Dirk · 18. Mai 2017

Überleg mal wie Colmn bei den for Schleifen initialisiert wird. Also mit welchen Startwert für Colmn die Schleife anfängt.
Und wie oft dann eine Schleife durchlaufen wird.

Janiiix3 · 18. Mai 2017

Mit welchem Tool, Konvertierst du deine Bilder?

Dirk · 18. Mai 2017

Janiiix3 schrieb:
Mit welchem Tool, Konvertierst du deine Bilder?

Ich nutze keine Tools, sondern schreibe mir hierfür Software für Windows, so wie ich sie gerade benötige.

Es gibt bestimmt diverse Programme, die sich ein bisschen konfigurieren lassen.

Janiiix3 · 18. Mai 2017

Das heißt, brauchst du mal ein Bild aufm GLCD programmierst du dir einfach schnell nen Tool was dir dies umwandelt?
Ist es denn richtig, dass jedes Byte im Array nach unten weg gezeichnet wird ?
Habe das Gefühl das diese Tools, die Bytes nach längs weg angeordnet ausgeben..

Hier mal Bildlich was ich meine..

Array[] = {0xff,0xff}

nach unten weg gezeichnet -> |

und die Tools geben das villeicht anders aus -> -- nach längs gezeichnet

LotadaC · 18. Mai 2017

Dein Display hat (in Pixeln) 32 Zeilen und 128 Spalten.
Jeweils 8 Zeilen sind zu einer Page zusammengefaßt - also 4 Pages.

Du adressierst mit dem Kommando 0xBn die Page n
Du adressierst mit den Kommandos 0x1m und 0xl die Spalte 0xml im RAM.
Du sendest ein Datenbyte, welches eben genau an die adressierte Stelle (Page, Spalte) geschrieben wird, also an die acht Pixel von Page n in Spalte ml. Und die liegen untereinander (es sei denn, Du drehst das Display).
Die Spaltenadresse inkrementiert dabei, scheint aber nicht (?) überzulaufen.

Dirk · 18. Mai 2017

Janiiix3 schrieb:
Das heißt, brauchst du mal ein Bild aufm GLCD programmierst du dir einfach schnell nen Tool was dir dies umwandelt?

Ja, dies schreibe ich mir selber.

Janiiix3 schrieb:
Ist es denn richtig, dass jedes Byte im Array nach unten weg gezeichnet wird ?
Habe das Gefühl das diese Tools, die Bytes nach längs weg angeordnet ausgeben..

Hier mal Bildlich was ich meine..

Array[] = {0xff,0xff}

nach unten weg gezeichnet -> |

Ja, das sieht richtig aus. Wenn du ein 0xFF sendest, werden in der Page senkrecht 8bit in einer Zeile gesetzt.

Janiiix3 schrieb:
und die Tools geben das villeicht anders aus -> -- nach längs gezeichnet

Ja, darauf habe ich ja schon hingewiesen. Es gibt x Möglichkeiten, wie die Pixeldaten vom Tool angeordnet sein könnten. Ideal ist es, wenn du die Pixeldaten so erhältst, wie du sie zum Displaycontroller überträgst. Wenn du sie nicht so erhältst, musst du sie zuvor durch deinen Code in dieses Format bringen.
Wenn du garnicht weißt, wie die Daten im Array aufgebaut sind, hmmm dann kannst duch auch ein mp3 übertragen.

Janiiix3 · 18. Mai 2017

Sollte man das Bild Zeilen weise oder Linien weise aufbauen?

Dirk · 18. Mai 2017

Janiiix3 schrieb:
Sollte man das Bild Zeilen weise oder Linien weise aufbauen?

Am besten so, wie du die Daten zum ST7565R überträgst.
Wenn du 8 Pixel in der Reihe zu einem Byte zusammen fügst, dann ist das ungünstig, weil du ja eigentlich 8 Pixel in der Spalte benötigst.

Schau dir die FillScreen Funktion an.

... und teste da auch mal mit solchen Mustern wie 0b11100000, 0b00111101 usw. Dann wird dir vielleicht einiges klarer.

Janiiix3 · 18. Mai 2017

Wie ist dein Bild, worüber wir mal per PN geschrieben haben aufgebaut? Linien oder Zeilenweise?

Leute die das schon öfters mal gemacht haben, für die mag das vielleicht direkt einleuchtend sein, für mich leider nicht so.

CodeBox C

const unsigned char image1[] = {
16, // width (bytes)

14, // height (pixels)

0x38,0x07,0xE0,0x0E,
0x07,0xFF,0x0C,0x0F,0xF8,0xFF,0xE1,0xC0,0x00,0x60,
0xE0,0x1C,0x1C,0x0E,0xE0,0x0C,0x07,0xFF,0x8C,0x1F,
0xF8,0xFF,0xF1,0xC0,0x00,0xF0,0x70,0x38,0x0E,0x1C,
0x60,0x1C,0x07,0x01,0xC0,0x38,0x00,0xE0,0x39,0xC0,
0x01,0xF0,0x70,0x70,0x07,0x38,0x70,0x18,0x07,0x01,
0xCC,0x38,0x00,0xE0,0x39,0xC0,0x01,0xB8,0x38,0x60,
0x03,0xF0,0x30,0x38,0x07,0x01,0xCC,0x38,0x00,0xE0,
0x39,0xC0,0x03,0xB8,0x1C,0xE0,0x01,0xE0,0x38,0x30,
0x07,0x01,0xCC,0x38,0x00,0xE0,0x39,0xC0,0x03,0x1C,
0x0F,0xC0,0x00,0xE0,0x18,0x70,0x07,0x01,0xCC,0x1F,
0xF0,0xFF,0xF9,0xC0,0x07,0x1C,0x07,0x80,0x01,0xE0,
0x1C,0x63,0xFF,0x01,0xCC,0x03,0xF8,0xFF,0xF1,0xC0,
0x06,0x0E,0x07,0x00,0x03,0xF0,0x0C,0xE0,0x07,0x01,
0xCC,0x00,0x18,0xE0,0x01,0xC0,0x0F,0xFE,0x03,0x00,
0x07,0x38,0x0E,0xC0,0x07,0x01,0xCC,0x00,0x18,0xE0,
0x01,0xC0,0x0F,0xFF,0x03,0x00,0x0E,0x1C,0x07,0xC0,
0x07,0x01,0xCC,0x00,0x38,0xE0,0x01,0xC0,0x1C,0x07,
0x03,0x00,0x1C,0x0E,0x07,0x80,0x07,0xFF,0xCC,0x3F,
0xF8,0xE0,0x00,0xFF,0xF8,0x03,0x83,0x00,0x38,0x07,
0x03,0x80,0x07,0xFF,0x8C,0x3F,0xF0,0xE0,0x00,0x7F,
0xF8,0x03,0x83,0x00
};

Du schreibst direkt am Anfang die Größe des Images nieder..
Ich bügele jetzt ab Index "0" die Werte senkrecht in den RAM vom Display...
Das ganze mache ich solange bis ich 128 Bytes übertragen habe. Dann ist die erste Page voll..
Nun müsste ich ja in die nächste Page gehen oder?

Dirk · 18. Mai 2017

Janiiix3 schrieb:
Linien oder Zeilenweise?

Du meinst spaltenweise oder zeilenweise. Linien sind es ja irgendwie immer

Die Pixel sind zeilenweise im Array, das passt für dich somit nicht so gut.

Janiiix3 · 18. Mai 2017

Okay... Mein Bild war wirklich gespiegelt. Jetzt sieht es ordentlich aus.
Eine Frage habe ich noch..

CodeBox C

[I]uint16_t[/I] page = 3;
[I]uint16_t[/I] column = 0;



lcd_gotoxy(0,0);
for (column=0;column<sizeof(Grafik1);column++)
{
lcd_senddata(Grafik1[column]);
if ((column%128)==0)
{
lcd_gotoxy(page--, 0);
[B]if (page==-1) page=3;[/B]
}
}

Wieso kann "page" -1 werden? es ist als unsigned deklariert?!

Dirk · 18. Mai 2017

Janiiix3 schrieb:
Wieso kann "page" -1 werden? es ist als unsigned deklariert?!

Kann ich jetzt auch nicht direkt sagen. Das funktioniert bei neg. unter 0. Der Wert müsste hier ja 65535d sein.

Warum fragst du so etwas ab, wenn du bewusst uint verwendest? :hmmmm:

uint16_t wirst du hier nicht benötigen, das ist ja recht groß.

Janiiix3 · 18. Mai 2017

Der Compiler scheint es zu verstehen und ohne funktioniert es nicht.

Dirk · 18. Mai 2017

Janiiix3 schrieb:
und ohne funktioniert es nicht.

-1 als Zweierkomplement entspricht ja 65535 (0b11111111 11111111)
Somit gehts. Aber int und uint "mischen", hmmm.

TommyB · 19. Mai 2017

Das liegt daran dass der Compiler es dann als INT interpretiert, also den Vergleichswert (das -1).
Implizite Typumwandlung. Sprich es wird ein UINT16 mit einem INT verglichen. Bei -1 ist es binär gesehen das selbe (65535 = -1), wie Dirk schon sagte.

In anderen Sprachen muss man das explizit angeben. z. B.:
If Wert = -1US Then
Das würde sofort fehlschlagen, weil -1 in unsigned short (=UINT16) nicht repräsentierbar ist.

Implizite Typumwandlung sollte aber nach Möglichkeit immer vermieden werden, da sonst unnötig hin und her gewandelt wird, und sogar unter ungünstigen Bedienungen schon Compileroptimierungen das Programm komplett durcheinander werfen.

Janiiix3 · 19. Mai 2017

Eine Frage bleibt mir aber noch..
Wenn ich eine "StartLine" zwischen 0-31 wähle, sind davor x beliebige Pixel gesetzt.. Wieso?

Dirk · 19. Mai 2017

Janiiix3 schrieb:
Wenn ich eine "StartLine" zwischen 0-31 wähle, sind davor x beliebige Pixel gesetzt.. Wieso?

Poste bitte einmal den relevanten Code, so kann man schlecht etwas dazu sagen.

Vielleicht liegt es auch einfach nur daran, dass du das Grafik-RAM nach poweron nicht initialisiert hast.

Janiiix3 · 19. Mai 2017

RAM Initalisieren? Habe ich wohl überlesen...
Hier Initalisiere ich das Display

CodeBox C

/* Init. Struct
* @para             -> -none
* @return           -> -none
* @description      -> change for your application
*/
static const uint8_t lcd_config[] =
{
   (CMD_SET_ADC_NORMAL),
   (CMD_DISPLAY_OFF),
   (CMD_SET_COM_NORMAL),
   (CMD_SET_BIAS_9),
   (0x2F),
   (0x21),
   (CMD_SET_VOLUME_FIRST),
   (0x2F), // Contrast
   (CMD_DISPLAY_ON)
};

Und wenn ich eine Reihe nach unten gehen möchte..

CodeBox C

void lcd_row(uint8_t row)
{
   lcd_sendcmd(0x40 | (row));
}

Übrigens hat das mit den Bilder jetzt geklappt. Musste einfach die Bits umdrehen vom Array, dafür habe ich diese Funktion geschrieben (gehts vielleicht noch besser/schneller?)

CodeBox C

/* ONLY FOR INTERNAL OPERATIONAL */
inline uint8_t swapBits(uint8_t byte)
{
   uint8_t tmp = 0;
   if(byte&1<<7) tmp|=1<<0;
   if(byte&1<<6) tmp|=1<<1;
   if(byte&1<<5) tmp|=1<<2;
   if(byte&1<<4) tmp|=1<<3;
   if(byte&1<<3) tmp|=1<<4;
   if(byte&1<<2) tmp|=1<<5;
   if(byte&1<<1) tmp|=1<<6;
   if(byte&1<<0) tmp|=1<<7;
   return tmp;
}

Dirk · 19. Mai 2017

Janiiix3 schrieb:
RAM Initalisieren? Habe ich wohl überlesen...

Das DDRAM solltest du nach der Initialisierung des LCD Controllers ebenfalls noch initialisieren, das heisst mit definierten Werten beschreiben.
Der LCD-Controller macht dies nicht selber.

lcd_clear()

Janiiix3 schrieb:
Musste einfach die Bits umdrehen vom Array, dafür habe ich diese Funktion geschrieben (gehts vielleicht noch besser/schneller?)

Schau zum Beispiel mal hier ...
http://www.avrfreaks.net/forum/reverse-bit-order-byte?page=all

C GLCD -> Logo anzeigen..

Aktives Mitglied

Administrator

Aktives Mitglied

Administrator

Aktives Mitglied

Sehr aktives Mitglied

Administrator

Aktives Mitglied

Administrator

Aktives Mitglied

Administrator

Aktives Mitglied

Administrator

Aktives Mitglied

Administrator

Team Bitschubse

Aktives Mitglied

Administrator

Aktives Mitglied

Administrator