GLCD Display und Atmega 32

[Chris T. (chris0086)]

Hallo Leute ich habe die Bibliothek von Ape 
[link]Beitrag "KS0108 GLCD Routinen"] auch auf 
meinen Atmega32
laufen, nur leider sieht das das Display so aus wie im angehängten Bild.
Hier mal mei n Quellcode vom main.c

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/delay.h>

#include "ks0108.h"
#include "font12x16.h"
#include "font6x8.h"

const char pgmString[] PROGMEM = "http://www.apeTech.de\n\[e-mail]";

int main(void) {
  volatile uint16_t i;
  struct font largeFont, smallFont;

  for(i=0; i<15000; i++);


  largeFont.width = FONT12X16_WIDTH;
  largeFont.height = FONT12X16_HEIGHT;
  largeFont.charData = Font12x16;

  smallFont.width = FONT6X8_WIDTH;
  smallFont.height = FONT6X8_HEIGHT;
  smallFont.charData = Font6x8;

  ks0108Init();

  ks0108GotoXY(20,0);
  ks0108PutString("Ha", largeFont);


  while(1);

habe DB 0-7 an Port A und die Controlleitungen an Port B angeschlossen:
hier der Quellcode:

#include <inttypes.h>
#include <avr/pgmspace.h>

#ifndef  KS0108_H
#define KS0108_H

// Ports
#define LCD_CMD_PORT    PORTB    // Command Output Register
#define LCD_CMD_DIR      DDRB    // Data Direction Register for Command Port

#define LCD_DATA_IN      PINA    // Data Input Register
#define LCD_DATA_OUT    PORTA    // Data Output Register
#define LCD_DATA_DIR    DDRA    // Data Direction Register for Data Port

// Function Parameters
#define INCREMENT_X      0
#define NO_INCREMENT_X    1

// Command Port Bits
#define D_I          0x00    // D/I Bit Number
#define R_W          0x01    // R/W Bit Number
#define EN          0x02    // EN Bit Number
#define CSEL1        0x03    // CS1 Bit Number
#define CSEL2        0x04    // CS2 Bit Number

// Chips
#define CHIP1        0x00
#define CHIP2        0x01

// Commands
#define LCD_ON        0x3F
#define LCD_OFF        0x3E
#define LCD_SET_ADD      0x40
#define LCD_SET_PAGE    0xB8
#define LCD_DISP_START    0xC0

// Fill Modes
#define BLACK        0xFF
#define CLEAR        0x00

// Uncomment for slow drawing
// #define DEBUG

struct displayPos {
  uint8_t x;
  uint8_t y;
  uint8_t page;
};

struct font {
  uint8_t width;
  uint8_t height;
  PGM_P charData;
};

// Function Prototypes
void ks0108Enable(void);
void ks0108Fill(uint8_t mode);
void ks0108GotoXY(uint8_t, uint8_t);
void ks0108Init(void);
void ks0108SetDot(uint8_t, uint8_t);
void ks0108ClearDot(uint8_t, uint8_t);
void ks0108PutChar(char c, struct font font);
void ks0108NewLine(uint8_t fontHeight, uint8_t offset);
void ks0108PutString(char *string, struct font font);
void ks0108PutStringP(PGM_P string, struct font font);
char ks0108ReadData(uint8_t incXAdd);
void ks0108WriteCommand(uint8_t cmd, uint8_t chip);
void ks0108WriteData(uint8_t data);

#endif

Könnt ihr mir sagen warum ich diese weißen Streifen habe?

Kann es ein verkabelungsproblem sein, vielleicht Leitungen vertauscht,
hab eigentlich alles schon 2 mal kontrolliert.
Eigentlich sollte "Ha" da stehen aber es passt nicht so recht.
Wer schön wenn ihr mir helfen könntet.
Hier nochmal das DB vom 
Display:http://www.pollin.de/shop/downloads/D120424D.PDF

[Jens B. (sio2)]

Auf den ersten Blick würde ich sagen, daß Du die Adressen nicht richtig 
hast. Schau mal ins DB, an welcher Adresse die 2. und an welcher die 3. 
Zeile liegen und überprüfe mal ob das im Code auch so gemacht wird.

[Chris T. (chris0086)]

hm... wo steht das im DBß hab da nix gefunden zu. Oder ich bin blind

[Jens B. (sio2)]

In dem DB steht auch nix, ist aber auch kein richtiges. Such mal das 
passende zu dem Chip, da müssen mehr als nur eine Seite sein.

[Oliver (Gast)]

Wenn da ein KS0108 drauf ist, dann ist das ein KS0108, und dann passt 
auch die lib. Der hat keine unterschiedlichen Adressen oder Pins für 
Zeile 2 oder 3.

Dein Bild sieht so aus, als ob falsche Daten aus dem Controller gelesen 
werden (immer nur 0xff). Das nicht alles Weiß wird, liegt vermutlich 
daran, daß deine Buchstaben zufällig genau auf einem Zeilenwechsel 
enden. Dann wird diese Zeile nicht gelesen, sondern gleich 
überschrieben. Das das prinzipiell funktioniert, zeigt schonmal, das die 
Beschaltung nicht ganz verkehrt ist.

Mal den R/W-Pin überprüfen, ob da alles richtig ist.

Ansonsten gleicher Tip wie immer: Timing verlangsamen - in der lib NOP's 
bei den EN's einfügen, sowie die "little delay"-Schleifen (oder so 
ähnlich) deutlich verlängern. Wenn es dann geht, kannst du dich ja 
langsam wieder rückwärts an das Optimum rantasten.

Oliver

[Oliver (Gast)]

Nachtrag: Nimm zum Testen das mit der lib kommende Beispielprogramm. 
Damit gibt es dann schonmal eine potentielle Fehlerquelle weniger.

Oliver

[Karl H. (kbuchegg)]

Oliver wrote:

> Dein Bild sieht so aus, als ob falsche Daten aus dem Controller gelesen
> werden (immer nur 0xff).

Das glaub ich eigentlich nicht.
Wenn ich mir das Bild ansehe:
Die ersten 8 Pixelzeilen stimmen
Dann kommt ein Gap von 16 Zeilen, in denen nichts stimmt.
Die nächsten 8 Pixelzeilen, sind diejenigen, die eigentlich an die 
ersten 8 anschliessen sollten.

Für mich sieht es so aus, als ob in der 'Page-Adressierung' in der Lib 
was nicht stimmt. Die mag mit dem dort verwendeten Controller 
funktioniert haben, aber mit dem hier stimmts anscheinend nicht.

> Das das prinzipiell funktioniert, zeigt schonmal, das die
> Beschaltung nicht ganz verkehrt ist.

Genau.
Auch das das Display initialisiert ist und was anzeigt zeigt eigentlich 
auch, dass keine Vertauschung der Datenleitungen vorliegt. Ansonsten 
wären die Initialisierungscommandos sicherlich nicht sauber zum Display 
durchgekommen.

Ich denke, dass dieses Display ganz einfach ein anderes Memory Layout 
benutzt, als das welches in der verlinkten Lib benutzt wurde.

> Ansonsten gleicher Tip wie immer: Timing verlangsamen -
> in der lib NOP's bei den EN's einfügen, sowie die "little delay"-
> Schleifen (oder so ähnlich) deutlich verlängern.

Diese Funktion

void ks0108Enable(void) {
  volatile uint8_t i;
  
  LCD_CMD_PORT |= 0x01 << EN;            // EN high level width: min. 450ns
  asm volatile("nop\n\t"
         "nop\n\t"
         "nop\n\t"
         ::);
  LCD_CMD_PORT &= ~(0x01 << EN);
  for(i=0; i<8; i++);                // a little delay loop (faster than reading the busy flag)
}

ist allerdings auch sträflich leichtsinnig geschrieben. Kann man der 
Entstehungszeit der Lib zuschreiben. Aber die sollte schnellstens auf 
solide Füsse gestellt werden:
  Anzahl der NOP aus der Taktfrequenz ableiten
  die 'little delay loop': sorry, aber so geht das gar nicht. Die
  Chancen stehen gut, dass der Compiler die einfach rauswirft.

Ein Indiz, dass auch der OP so einige Schwierigkeiten mit dem Timing 
hatte, ist für mich diese Stelle:

void ks0108SetDot(uint8_t x, uint8_t y) {
  uint8_t data;
  
  ks0108GotoXY(x, y);                // read data from display memory
  data = ks0108ReadData(NO_INCREMENT_X);      // dummy read
  data = ks0108ReadData(NO_INCREMENT_X);      // "real" read

Warum da ein dummy read eingefügt werden muss, ist mir nicht ganz klar. 
Offenbar war der Chip nach dem ks0108GotoXY noch nicht fertig mit 
arbeiten. Der schnelle Fix: Wenns beim ersten mal nicht geklappt hat, 
machen wirs halt nochmal, in der Hoffnung das es dann klappt.

[Chris T. (chris0086)]

Leider komm ich grad nicht ans board um zu schauen was es für ein 
Kontroller ist aber mit Bascom und der Ks lib hats einwandfrei 
funktioniert.

aber danke kbuchegg, ich werd sehen was sich da machen lässt, dachte 
eben das is ne lib auf die ich aufbauen kann und wo ich mich nichtmehr 
mit der Displayansteuerung rumschlagen muss...

Komisch das es bei den vielen anderen einwandfrei funktioniert hat und 
bei mir nicht, hab das ganze übrigens auch mit 4mhz Takt getestet, war 
auch nicht besser

[Karl H. (kbuchegg)]

Christian Hohmann wrote:

> aber danke kbuchegg, ich werd sehen was sich da machen lässt, dachte
> eben das is ne lib auf die ich aufbauen kann und wo ich mich nichtmehr
> mit der Displayansteuerung rumschlagen muss...

Ich hab den Code noch ein wenig überflogen, da sind auch an anderen 
Stellen noch dubiose Warteschleifen drinn.

> Komisch das es bei den vielen anderen einwandfrei funktioniert hat und
> bei mir nicht, hab das ganze übrigens auch mit 4mhz Takt getestet, war
> auch nicht besser

Kann auch Compiler/Versions abhängig sein. Schalte mal den Optimizer vom 
Compiler weg.

[Karl H. (kbuchegg)]

Karl heinz Buchegger wrote:

>   die 'little delay loop': sorry, aber so geht das gar nicht. Die
>   Chancen stehen gut, dass der Compiler die einfach rauswirft.

Hab übersehen, dass die Schleifenvariable volatile ist.
Ist allerdings eine interessante Fragestellung: Kann der Compiler eine 
lokale Variable komplett eliminieren, wenn sie sonst nirgend gebraucht 
wird, selbst wenn sie volatile ist?

[Sascha (Gast)]

Hallo,

@Karl heinz

also das mit dem Dummyread steht sogar im Datenblatt so drin.

Sascha

[Karl H. (kbuchegg)]

Sascha wrote:
> Hallo,
>
> @Karl heinz
>
> also das mit dem Dummyread steht sogar im Datenblatt so drin.

Danke.
Mangels Datenblatt konnte ich das nicht nachsehen. Aber wenns da auch so 
enthalten ist .... ziehe ich den Einwand zurück.
Hat einfach nur seltsam ausgesehen.

[Chris T. (chris0086)]

@Sascha
hast du ein umfangreichers Datenblatt als ich zur verfügung?

[Oliver (Gast)]

Datenblätter zum ks0108 gibt es überall im Netz.

Das mit dem Dummyread ist in der lib nicht ganz optimal implementiert.

Genaugenommen ist das Read-Register gelatcht, beim Lesen wird aber genau 
wie beim schreiben der Adresszeiger automatisch inkrementiert, und auch 
jedesmal das latch nachgeladen. Beim sequentiellen Schreiben eines 
zusammenhängende Blocks in einer Zeile braucht es also eigentlich auch 
nur ein Dummy-Read zu Anfang. Die lib prüft aber nicht auf sequentielles 
Schreiben, sondern gibt grundsätzlich für jedes byte einzeln die Adresse 
neu aus, macht den dummy-Read, und liest dann die Daten. Das bremst 
nicht unerheblich, hat aber mit dem Problem der weissen Streifen nichts 
zu tun.

>aber mit Bascom und der Ks lib hats einwandfrei funktioniert.

Das zeigt ja, das im Prinzip alles richtig ist.

Wenn du die Möglichkeit hast, über uart Daten auszugeben, dann schreib 
mal jede Zeile des Display mit den Werten 0-127 voll, lies das wieder 
aus, und gib das ausgelesene über die uart aus. Dann siehst du gleich, 
was nicht funktioniert.

Oliver

[Sascha (Gast)]

Hallo,

anbei mal das was ich gefunden habe
> bei Reichelt selbiges Display suchen -> Datenblatt -> im PDF ist dann ein Link 
und da hab ich das Datenblatt zum KS0108 gefunden.

also ich habe auch selbiges Display von Pollin am laufen, allerdings 
habe ich mir die C-Routinen aus dem von dir verwendeten Paket in ASM 
umgeschrieben.


Sascha

[Chris T. (chris0086)]

Mit dem Datenblatt versteh ich erstmal welches Signal an DB 0-7 für die 
einzelnen Befehle anliegen muss.
Warum ich nicht selbst drauf gekommen bin ein anderes DB zu suchen...

[Chris T. (chris0086)]

Servus leute sitze jetzt endlich wieder am Board und hab erstmal die 
Kompileroptimierung abgeschaltet: 
http://www.pretty-kunze.de/avroptimum.jpg
Hoffe das ist der richtige Ort zum Abschalten.

Dann wollt ich das ausgeben lassen:

ks0108Init();

  ks0108GotoXY(0,0);
  ks0108PutString("Hallo", smallFont);

  ks0108GotoXY(0,22);
    ks0108PutString("Das ist ein Test", smallFont);

Und raus kam das: was im Anhang steht.

Ich verzweifel noch wo kann ich jetzt suchen oder was kann ich 
probieren???
Ich bin leider noch Anfänger auf dem AVR Gebiet.

[Chris T. (chris0086)]

Leute ich habe den Dataport gewchselt, und es funktioniert, warum auch 
immer...

[Michael U. (amiga)]

Hallo,

AVCC des Mega32 hattest Du aber angeschlossen???

Gruß aus Berlin
Michael

[Chris T. (chris0086)]

ja soweit ich das sehe ist er angschlossen. und auch mit dem kleinen 
Ceko gegen Masse verbunden