Library für EA-DOGM Grafikdisplays inkl. Font-Generator

[Jan M. (mueschel)]

Im Anhang findet ihr meine Library zur Ansteuerung der kompakten DOGM 
Grafik Displays sowie einen Font-Generator.

Zur LCD-Library selbst gibt es nicht viel zu sagen:

- Unterstützt beide Grafikdisplays der EA-DOGM Serie: dogm132 mit 132x32 
und dogm128 mit 128x64 Pixel
- Es wird kein zusätzlicher Grafik-RAM im µC verwendet
- Da der LCD-Controller keine Lesezugriffe unterstützt, können nur immer 
8 Pixel auf einmal geändert werden
- Alle LCD-Befehle in Header-Datei enthalten
- Durch wenige Zeilen in dogm-graphic.h an die jeweilige 
Hardwaresituation anpassbar

Der Font-Generator:

- 3 Schriftarten: 8px und 16px Höhe mit variabler Breite sowie 8px mit 
fester Breite
- 2 (kleine) Symbolsätze (z.B. zur Beschriftung von Tastenfunktionen) 
mit 8px bzw. 16px Größe
- Jede Schriftart kann wiederum in vier Arten ausgegeben werden: normal, 
doppelte Breite, doppelte Höhe, doppelte Größe
- Eigene Schriftarten / Zeichen können einfach erstellt werden mit dem 
unten verlinkten Font-Editor
- Generator lässt sich mit jedem Grafikdisplay verwenden, je nach 
Speicherorganisation des Displays ist eventuell noch etwas Zusatzcode 
notwendig

Der benötigte Speicherplatz im µC liegt je nach Zahl der eingebundenen 
Schriften zwischen 2,9kB und 7 kB. Die statische RAM-Belegung sind nur 2 
Byte.

Vielen Dank an Hagen Reddmann für seinen Font-Editor 
(Beitrag "Re: glcd fontcreator aktuell")
sowie Benedikt K. für seine Sammlung LCD-Schriftarten 
(Beitrag "LCD Schriftarten ( Fonts in veschiedenen Größen )")

Kommentare und Anregungen sind natürlich herzlich willkommen!

[Jan M. (mueschel)]

Danke für das Interesse an meiner Bibliothek! Hier kommt ein Update mit 
einigen neuen Funktionen. Einige davon stammen von Oliver Schwaneberg, 
bei dem ich mich herzlich bedanken möchte.

Neue Funktionen in dogm-graphic.c:
- "Chip Select" Pin des Displays wird unterstützt.
- Benutzung von Beleuchtung und Chip Select sind optional und können in 
dogm-graphic.h an- und abgewählt werden
- Funktion lcd_draw_image_P: Zeichnet ein Bild mit x*y Pixeln aus 
Rohdaten im Flash an die aktuelle Cursorposition
- Funktion lcd_draw_image_xy_P: Zeichnet ein Bild mit x*y Pixeln aus 
Rohdaten im Flash an die angegebenen Pixelkoordinaten. Verschiebung is 
pixelgenau möglich.
- Initialisierung von SPI wird von der lcd-init Routine übernommen. Eine 
eigene Funktion mit den nötigen Befehlen kann in dogm-graphic.h 
spezifiziert werden

Neue Funktionen in font.c:
- Text kann auch invertiert dargestellt werden
- Text wird (optional) in die nächste Zeile umgebrochen
- Funktionen zur direkten Ausgabe von int, long int und float 
hinzugefügt. Wegen des großen Platzbedarfs können diese einzeln in 
font.h an-/abgewählt werden
- put_string* und put_char* Funktionen geben die Breite des ausgegebenen 
Texts zurück

[siegmar (Gast)]

Jan M. schrieb:
> Danke für das Interesse an meiner Bibliothek!

Hallo Jan,
Benötige sie zwar gerade nicht, aber möchte doch stellvertretend für 
Viele ein rechtherzliches Dankeschön für das Bereitstellen deiner Arbeit 
aussprechen !!
Noch einen schönen Tag
Gruß
Siegmar

[GG (Gast)]

Hallo Jan,

ich möchte gerne deine DOGM-Lib ausprobieren, komme aber mit der 
Befehlsfolge der  Font-Funktion nicht zurecht. Wäre es möglich, eine 
kleine Abfolge Deiner Befehle hier einzustellen.

Gruß GG

[Jan M. (mueschel)]

Die Funktionen, um einen Buchstaben oder einen String auszugeben sind:

uint16_t lcd_put_string       (FONT_P font, uint8_t style, char* str);
uint16_t lcd_put_string_P     (FONT_P font, uint8_t style, PGM_P str);
uint8_t  lcd_put_char         (FONT_P font, uint8_t style, unsigned char c);

Funktionen mit einem "_P" am Ende laden ihre Daten direkt aus dem Flash, 
die anderen aus dem RAM.

Das erste Argument ist immer die Schriftart. Zur Auswahl stehen 
FONT_FIXED_8, FONT_PROP_8, FONT_PROP_16, sowie zwei kleine Symbolsätze 
FONT_SYMBOL_8 und FONT_SYMBOL_16.
Welche davon eingebunden sind hängt davon ab, welche Zeilen in font.h 
unter "Select which of the available features will be included" nicht 
auskommentiert sind.

Das zweite Argument ist der Stil. Zur Auswahl stehen NORMAL, 
DOUBLE_WIDTH, DOUBLE_HEIGHT, INVERT (weiß auf schwarz) und WRAP (sorgt 
für Zeilenumbrüche in längerem Text). Diese Optionen können natürlich 
miteinander kombiniert werden. ("INVERT | WRAP" würde beispielsweise 
invertierten Text mit Zeilenumbrüchen erzeugen).

Das dritte Argument ist der auszugebende Text, also entweder ein Zeichen 
oder ein Pointer auf einen string im RAM oder Flash.


Ich hoffe, ich konnte dir damit helfen, ansonsten stell doch bitte 
deinen Code hier ein oder versuche genauer zu beschreiben wo du nicht 
weiter kommst.

Jan

[GG (Gast)]

Hallo Jan,

bin erst jetzt zum Testen Deiner DOGM-Lib gekommen. Alles Paletti.
Code funktioniert optimal.

Zusätzlich wollte ich eine printf Funktion oder xitoa(PSTR(" ")) 
einbinden.
Das ging leider in die Hose, da in der Funktion lcd_put_char(FONT_P 
charset, uint8_t style, unsigned char character)  zu viele Parameter zu 
übergeben sind. PRINTF UND XITOA Routinen funktionieren nur mit einer 
Parameterübergabe zum Beispiel char c.

Gruß GG

[Jan M. (mueschel)]

Hallo GG,
für diese Anwendung würde ich dir vorschlagen, die Konfiguration über 
globale Variablen zu machen und einen wrapper die put_* Funktionen mit 
diesen globalen Variablen aufzurufen.

Also z.B. so

FONT_P global_font_select;
uint8_t global_font_style;

void font_set_config(FONT_P font, uint8_t style){
  global_font_select = font;
  global_font_style = style;
}

uint16_t putc_simple(char c) {
 return lcd_put_char(global_font_select,global_font_style,c);
}

[GG (Gast)]

Hall Jan,

Danke für die Antwort.

Bei meinen Bemühungen bin auch fast soweit gekommen , leider bekomm ich 
jedesmal bei der Zuweisung:

void font_set_config(FONT_P font, uint8_t style){

global_font_select = font; <-----  siehe folgende Compiler Meldung

global_font_style = style;
}


dogm_132.c:431: error: assignment of read-only variable 
'global_font_select'


gibt es eine Möglichkeit, die Zuweisung so zu ändern?

Mfg GG

[Jan M. (mueschel)]

Ja, das sehe ich auch gerade. Nimm in font.h einfach das "PROGMEM" aus 
der typedef von FONT_P raus:

>>typedef const struct font_info * FONT_P;

[GG (Gast)]

Servus Jan,

das war das "i-Tüpfelchen!".

Jetzt funktioniert alles. Werde mal ein kleines Program mit Deiner 
Lib(Atxmega32a4, DOGM132, BMP085 (Bosch-Drucksensor)) ins Netz stellen.

Nochmals vielen Dank

Gruß GG

[Thomas B. (escamoteur)]

Wow, super! Läßt sich die Lib auch mit vertretbarem Aufwand an die DOGL 
und DOGXL Displays anpassen?

Grüße
Tom

[GG (Gast)]

Servus Tomas,

DOGXL scheinbar NEIN! Hat einen anderen Controller UC1610.

DOGL ist komapatible.

Gruß GG

[Thomas B. (escamoteur)]

Sollte sich aber wahrscheinlich auch anpassen lassen der DOGXL hat den 
Speicher halt dämlicherweise in 8-Pixel hohe spalten organisiert. wie 
die anderen DOGs das machen weiß ich nicht.
Tom

[Jan M. (mueschel)]

Hallo Thomas,
die DOGM haben auch diese Organisation. Die Beschreibung im Datenblatt 
der DOGL sieht identisch aus - von dieser Seite kein Problem, du musst 
nur die entsprechenden defines aendern.

Fuer die DOGXL sind mehr Aenderungen noetig, der Font-Generator wird 
aber sicher auch funktionieren.

[Jan M. (mueschel)]

@GG:
Kannst du mir deinen Code schicken? Dann wuerde ich ihn mit deiner 
Erlaubnis in die Library einbinden und hier demnaechst wieder hochladen.

[GG (Gast)]

Hallo Jan,

ich werde hier mal den Code veröffentlichen.
Projekt:Atxmega32a4, DOGM128, BMP085 (Bosch-Drucksensor)

Du darfst nach Herzenslust den Code verändern und veröffentlichen!


Gruß GG

[Jürgen (Gast)]

Hallo,

ich habe Probleme mit den Fonts, ich bekomme das einfach nicht hin.

Wenn ich mir die Fonts von Benedikt K. lade und versuche es entsprechend 
anzupassen dann sehe ich nur Mist auf dem LCD.
Vorallem welche muss ich nehmen? MSB oder LSB??

Ich suche eine Schrift die ungefähr doppelt so groß ist als die PROP_16.
Aber ohne die vergrößern Funktion!

Kann mir jemand eine größere Schrift für die Lib erstellen oder genau 
erklären wie ich die Einstellungen von den fertigen Fonts vornehmen 
muss.

Danke

Gruß
Jürgen

[Jan M. (mueschel)]

Hallo Jürgen,
möchtest du eine proportionale oder eine monospaced Schrift?
Eine proportionale müsstest du dir mit Hagens Font-Generator selbst 
erstellen - das ist aber auch kein großer Aufwand.

Ich weiß nicht mehr, welche von Benedikts Font-Varianten die passende 
ist. Um das herauszufinden kannst du einfach die Daten in font_fixed_8px 
mit denen von Benedikts 5x8 Font vergleichen.

Die proportionale Schriftart würde dir einiges an Speicher sparen, 
insbesondere weil du einzelne unbenutzte Zeichen einfach aus dem Font 
entfernen kannst. Die 16x26 Font von Benedikt bräuchte ja schon ungefähr 
13kByte Speicher.

[Jürgen (Gast)]

Hallo Jan,

eigentlich benötige ich nur Zahlen in einer einheitlichen Größe und ein 
einheitliches Leerzeichen.

    File Name           : font_proportional_16px_2.h
    Date                : 10.03.2010
    Font size in bytes  : 0x0408, 1032
    Font width          : 14
    Font height         : 19
    Font first char     : 0x20
    Font last char      : 0x3E
    Font bits per pixel : 2
    Font is compressed  : false

wie muss jetzt mein

const struct font_info font_proportional_16px_2 PROGMEM = {..}

aussehen.

Ich steige da einfach nicht dahinter.
Gruß
Jürgen

[Jan M. (mueschel)]

Eine kleine Beschränkung gibt es noch zu beachten: Die Höhe muss ein 
Vielfaches von 8 sein, da die Software immer komplette Bytes liest und 
ausgibt.

Außerdem wundert mich die Angabe "Font bits per pixel : 2" - die 
Schriftart muss in s/w sein, also mit einem Bit pro Pixel.


Wenn du den Font-Generator benutzt, ändere einfach die font.ini so, dass 
unter Export das template.h aus meinem zip-File angegeben ist, dann 
kuemmert sich die Software von alleine um alle nötigen Werte.

[Jürgen (Gast)]

Hallo Jan,

super du hast mir weitergeholfen, jetzt habe ich eine passende Schrift 
erstellen können.

Vielleicht kannst du mir mit meinem letzten Problem auch noch 
weiterhelfen.
Wie lade ich ein Bitmap aufs Display

Gruß
Jürgen

[Jan M. (mueschel)]

Dazu muss das Bild im selben Format vorliegen wie auch die Schriften, 
d.h. ein 8bit hoher Streifen von rechts nach links, und dann von oben 
nach unten.

In dogm-graphic.h muss  das define LCD_INCLUDE_GRAPHIC_FUNCTIONS gesetzt 
sein, damit lcd_draw_image_P() eingebunden ist.

Dort uebergibst du dann den Pointer auf das Bild im Flash, die Hoehe in 
pages, die Breite in Pixel. Style wirst du normalerweise auf NORMAL 
setzen (oder INVERTED). Das Bild hat die linke obere Ecke dann dort, wo 
der Cursor gerade steht, also dort, wo du vorher mit lcd_moveto_xy() 
hingegangen bist.

lcd_draw_image_xy_P() kannst du zusaetzlich noch die genaue Position auf 
dem Display in Pixeln uebergeben.

[Jürgen (Gast)]

gibt es ein programm das mir die bitmaps konvertiert oder ist hier 
handarbeit angesagt?

hast du mir ein beispiel bitmap?

[Jan M. (mueschel)]

Ich habe die Funktion noch nie wirklich benutzt :-)

Beim Font-Generator ist ein Programm namens convert.exe dabei. Ich kann 
es hier gerade nicht testen, aber das koennte das sein was du suchst.

[Jürgen (Gast)]

also mit convert.exe bekomm ich auch keine verwendbaren Daten hin.

Hat vielleicht jemand schon erfolge mit der draw_image Funktion?
Bzw. ein paar Tipps?

[Jan M. (mueschel)]

Hätte mich gewundert, wenn es hier im Forum keine passende Software 
dafür gäbe. "Laeubi" hat hier das richtige: 
Beitrag "Grafikkonverter Tool für AVR/Mikrocontroller (BMP2C, BMP2ASM, BMP2BASCOM)"
Die Version auf seiner Homepage hat auch direkt die Option um Dateien 
direkt für EA-DOG-Displays exportieren zu können.

[Rolf D. (rolfdegen)]

Jürgen schrieb:
> gibt es ein programm das mir die bitmaps konvertiert oder ist hier
> handarbeit angesagt?
>
> hast du mir ein beispiel bitmap?

Hallöchen..

Hab das ganze etwas anders gelöst. Schau mal hier im CC2-Forum: 
http://www.cczwei-forum.de/cc2/thread.php?postid=50476#post50476

Gruß Rolf

[Christian Sowada (Gast)]

Hallo, ich finde es echt toll, das sich jemand solche Mühe macht.
Leider komme ich nicht so recht vorran. Gibt es für dein Script sowas 
wie ein "Hallo Welt" Beispiel?

Ich habe auch erstmal die Zeile geändert, richtig? Ist ja für UART ?!?!

//#define spi_wait_for_idle() while(! (UCSR1A & _BV(TXC1)));UCSR1A |= _BV(TXC1)
#define spi_wait_for_idle() while(!(SPSR & (1<<SPIF)))

Wie muß ich meiner main.c loslegen? So?

lcd_init();
lcd_put_string(FONT_FIXED_8, NORMAL, "Hallo Welt");

Was ich nicht ganz so durchschaue, ist die leere Funktion .

init_spi_lcd()

 Die muss doch irgendwie mit Leben befüllt werden!?

Vielleicht kann mir ja jemand helfen. Wollte nur ein upgrade von 
Textdisplay nach Grafikdisplay machen.

Ach ja, ich verwende den internen 8Mhz Takt.

Danke

Christian

[Jan M. (mueschel)]

Christian Sowada schrieb:
> Gibt es für dein Script sowas wie ein "Hallo Welt" Beispiel?

Das hast du schon fast komplett zusammen.

> Ich habe auch erstmal die Zeile geändert, richtig? Ist ja für UART ?!?!
>

//#define spi_wait_for_idle() while(! (UCSR1A & _BV(TXC1)));UCSR1A |=
> _BV(TXC1)
> #define spi_wait_for_idle() while(!(SPSR & (1<<SPIF)))

Ja, wenn das Display bei dir an der SPI-Schnittstelle hängt. Bei mir ist 
es die USART eines Atmega324, deswegen der andere Code

>
> Wie muß ich meiner main.c loslegen? So?
>
>

lcd_init();
> lcd_put_string(FONT_FIXED_8, NORMAL, "Hallo Welt");

Ja, das passt. ich würde aber empfehlen, den String in den Flash und 
nicht in den RAM zu packen:

lcd_put_string_P(FONT_FIXED_8, NORMAL, PSTR("Hallo Welt"));

>
> Was ich nicht ganz so durchschaue, ist die leere Funktion
> init_spi_lcd(). Die muss doch irgendwie mit Leben befüllt
> werden!?

Genau, diese Funktion habe ich nicht in der Library, sie hängt ja von 
der Hardware ab. Im wesentlichen sind die Einstellungen: SPI Mode 3 
(Setup (Falling) Sample (Rising)) und Frequenz ~ 1 MHz. Damit die 
Abfrage spi_wait_for_idle() richtig funktioniert, muss man meist zuerst 
eine "dummy"-Übertragung machen, also das Datenregister mit LCD_NOP 
laden.

[Christian Sowada (Gast)]

Ja, danke. Hab es auch gerade zum fliegen gebracht. Nur ist alles 
horizontal gespiegelt!?!?! Ist schon putzig. Da muss ich wohl etwas bei 
der Initialisierung rumspielen.

Aber vielen Dank für deine coole Bibliothek.

[Jan M. (mueschel)]

> Nur ist alles horizontal gespiegelt!?!?!

Der Vollständigkeit halber hier der Link zur Fehlersuche
Beitrag "DOGM132 - Text horizontal gespiegelt."

Lösung: Bei der Initialisierung der seriellen Schnittstelle darf nicht 
eine 0 über SPI übertragen werden - als Dummywert immer LCD_NOP 
verwenden!

[Christian Sowada (Gast)]

Vielen Dank nochmals Jan

Gruß Christian

[Jan M. (mueschel)]

So, es ist Zeit für die nächste Version. Die Änderungen sind:

- Schriftart und -stil können global gesetzt werden, so dass die 
Funktionen lcd_putc, lcd_putstr u.a. nur mit dem auszugebenden Text als 
Parameter aufgerufen werden können.
- Neue Schriftart: 24px hohe / 16px breite Ziffern und Zahlensymbole
- Neuer Schriftstil: Unterstreichung

- Die Library sollte jetzt in der Lage sein, alle DOGS, DOGM und 
DOGL-Module zu initialisieren und anzusprechen. Die Initialisierung des 
DOGS102 konnte ich aber nicht testen mangels Display.

Falls jemand die Ausgabefunktionen für die DOGXL-Displays umzuschreiben 
möchte - ich bin gerne bereit zu helfen.

[KMi (Gast)]

Hallo Jan,

habe mir deinen Archive dogm-graphic-092.zip angeschaut:

gleich beim Start erstes Problem:


Beim compilieren meckert avr gcc mit Fehlern:

Funktion LCD_SELECT()
'UCSR1A' (undeclared:(first use in this function))
'TXC1' (undeclared:(first use in this function))

Funktion spi_write(data)
'UDR1'  (undeclared:(first use in this function))

Fehlt da was oder ist es mein Fehler??

Danke im voraus.

[KMi (Gast)]

Mein Fehler hätte natürlich erst überlegen sollen, dass es sich um einen 
anderen µC handelt....

[Jörg H. (idc-dragon)]

Hallo,

Dieses Code habe ich sozusagen "zu spät" gefunden, bereits was eigenes 
am Laufen. Auf einem (positiven) DOGM132W, soweit keine Probleme.

Dann hatte mich mit einem (negativen) DOGM128S "abgeplagt", der Kontrast 
war notorisch schlecht. Frustriert habe ich das erstmal beiseite gelegt, 
dem invertierten Display die Schuld gegeben, später ein positves 
DOGM128W gekauft, war aber auch flau.

Dann habe ich für eine zweite Meinung diesen Code ausprobiert. 
Funktionierte auch nicht, aber ich habe mich zumindest mal genauer damit 
beschäftigt, jetzt gehts!

Ich glaube, die Initialisierung ist doch noch typabhängiger als bisher 
codiert. Der originale Code liefert für ein DOGM132 ein gutes Bild, auf 
einem DOGM128 sieht man aber nichts.

Die Initialisierung habe ich jetzt beim DOGM128 sinngemäß so:
  LCD_SET_BIAS_RATIO_1_7();       //bias 1/7
  LCD_SET_POWER_CONTROL(7);       //power control mode: all features on
  LCD_SET_BIAS_VOLTAGE(7);        //set voltage regulator R/R
  LCD_SET_VOLUME_MODE(0x06);      //volume mode set


Dank und Gruß
Jörg

[Juppo (Gast)]

Hallo


Läuft die Library auch für die kleinen DOG S 102 Module  ??

So wie ich das sehe haben die einen anderen Controller

Gruß
Juppo

[Jan M. (mueschel)]

Ich habe kein DOGS-Display, konnte es also noch nicht ausprobieren.
Laut Datenblatt sind die beiden Controller aber fast identisch. Mit 
kleinen Anpassungen in der Init-Sequenz sollte der Code laufen.

Wenn du es zum Laufen bringst: Ich würde mich über eine Rückmeldung 
freuen, welche Anpassungen notwendig waren. Dann kann ich sie mit in die 
Library aufnehmen. Die Änderungen von Jörg für das DOGM128 werde ich 
auch demnächst mit einpflegen.

Jan

[Juppo N. (juppo)]

Hallo

Ich habe nun mal ein DOG S angeschlossen.
Als Controller haben ich ein ATMEGA 168

Was sofort auffällt ist das bei lcd_moveto_xy(0,2);

x und y vertauscht sind.

Ich denke das sollte so sein

x für Horizontal
y für Vertikal


lcd_moveto_xy(0,2);
lcd_putc('X');

macht gibt nich definierte Zeichen auf das Display

Ich habe bislang mit den 8051 programmiert und frage mich wie der 168er 
die Fonts Tabellen anspricht,.
Oder müssen die vorher im EEprom bereich geladen werden.


Gruß Juppo

[Juppo N. (juppo)]

Hallo an alle

Habe jetzt fast alles am laufen.
Wunderbar.

Probleme gibt es bei FONT_SYMBOL_16

lcd_put_char(FONT_SYMBOL_16,DOUBLE_SIZE,2);

Da zeigt das Display nur Mull an.




FONT_SYMBOL_8 Zeichen kommen wunderbar.

Gruß Juppo

[Jan M. (mueschel)]

Juppo Nini schrieb:
> lcd_moveto_xy(0,2);
> lcd_putc('X');
>
> macht gibt nich definierte Zeichen auf das Display

Du hast es wohl schon geloest, aber: Hast du vorher mit lcd_set_font() 
die richtigen Einstellungen gemacht?

Juppo Nini schrieb:
> lcd_put_char(FONT_SYMBOL_16,DOUBLE_SIZE,2);
> Da zeigt das Display nur Mull an.

Da muss ich heute abend mal genauer schauen.

[Juppo N. (juppo)]

Hallo
Bin immere noch am testen mit dem DOG S

Läuft alles super und wunderbar schnell.

Nur bei FONT_PROB_16 werden die Leerzeichen nicht auf das Display 
dargestellt.

zB."HALLO WORLD"

hinter HALLO steht nur noch Müll

??
Gruß Juppo

[Jan M. (mueschel)]

Hallo,
hier ist die neuste Version der Library:
- Initialisierung angepasst für DOGM128 (Dank an Jörg H.!)
- Fehler in symbol_16px und font_proportional_16px korrigiert (Dank an 
Juppo!)
- Funktionen zur Ausgabe von long, int und float angepasst - sie 
verwenden nun die globalen Schriftart-Einstellungen und haben somit 2 
Parameter weniger

@Juppo: Ich würde mich freuen, wenn du mir noch deine 
Initialisierungssequenz für das DOGS102 zukommen lassen würdest falls 
sie von der Sequenz in der Library abweicht.

[XMEGA (Gast)]

Servus,

Jan M. schrieb:
> - Funktionen zur Ausgabe von long, int und float angepasst -

in der  font.h wurde folgendes definiert:

#if INCLUDE_FLOAT_OUTPUT == 1
uint16_t lcd_put_float(FONT_P font, uint8_t style, float integer);
#endif


sollte so lauten: uint16_t lcd_put_float (float fvalue)

Ich verwende seit geraumer Zeit deinen Code für die XMEGAS.
Echt Klasse!! Habe die ersten Tests gefahren, alles paletti.

PS eines ist mir noch aufgefallen,
in der dogm-chrapic.h fehlen die (void)

void lcd_init();
static inline uint8_t lcd_get_position_page()
lcd_get_position_column()


Der AVRGCC mekert hier immer.


Gruß XMEGA

[Jan M. (mueschel)]

Danke für den Hinweis!
Im Anhang die korrigierte Version.

[XMEGA (Gast)]

Servus,

ich habe mal das DOGS102 (reflektierend) getestet, ging nicht!

Ein Blick in die Init-Anweisung ergab:

 #if DISPLAY_TYPE == 102
    LCD_SET_BIAS_RATIO_1_9();         //bias 1/9
    LCD_SET_POWER_CONTROL(7);         //power control mode: all features 
on
    LCD_SET_BIAS_VOLTAGE(3);          //set voltage regulator R/R
    LCD_SET_VOLUME_MODE(0x1F);        //volume mode set
    LCD_SET_ADV_PROG_CTRL(LCD_TEMPCOMP_HIGH);

das ist identisch mit dem DOGM132.

Meine Einstellungen durch probieren und Datenblatt ergab:

 #if DISPLAY_TYPE == 102
    LCD_SET_BIAS_RATIO_1_9();         //bias 1/7
    LCD_SET_POWER_CONTROL(0x2F);      //power control mode: all features 
on
    LCD_SET_BIAS_VOLTAGE(7);          //set voltage regulator R/R
    LCD_SET_VOLUME_MODE(0x9);         //volume mode set
    LCD_SET_ADV_PROG_CTRL(LCD_TEMPCOMP_HIGH);

ist da was schief gelaufen?

Mit dieser Einstellung habe ich ein perfektes Display.
Schriftarten funktionieren auch.

Gruß XMEGA

[Jan M. (mueschel)]

Danke für den Test!
Da ich kein DOGS102 habe, konnte ich die Initialisierung auch noch nicht 
testen. Deswegen waren dort bis jetzt auch nur Dummy-Werte vorhanden.
Ich habe deine Einstellungen jetzt übernommen, in der nächsten Version 
sind sie dann auch enthalten.

Btw, bei LCD_SET_POWER_CONTROL() ist deine Einstellung 0x2F identisch zu 
meiner 0x7 - nur die unteren drei Bits sind der Wert, die oberen sind 
der Befehl.

[Jan M. (mueschel)]

Ein kleiner Tipp noch:

Beim DOGM132 sind im Controller nicht nur die pages 0 bis 3 vorhanden, 
sondern auch die normalerweise nicht sichtbaren 4 bis 7. Hier kann man 
z.B. im Hintergrund einen neuen Bildschirminhalt laden, und dann mit 
LCD_SET_FIRST_LINE(32); dorthin wechseln.

Oder mit LCD_SET_FIRST_LINE(4); kann man drei Zeilen Text vertikal 
zentrieren und hat oben und unten noch jeweils 4 Pixel Platz für einen 
schmalen Rahmen.

[XMEGA (Gast)]

Servus,

Jan M. schrieb:
> Btw, bei LCD_SET_POWER_CONTROL() ist deine Einstellung 0x2F identisch zu
>
> meiner 0x7 - nur die unteren drei Bits sind der Wert, die oberen sind
>
> der Befehl.


alles klar, habe ich mir gedacht.


Gruß XMEGA

[Giuseppe B. (brungi)]

Hallo Leute,

ich versuche auch gerade ein dogm128 display mit einem atmega32 zum 
laufen zu bringen. Dazu muß ich sagen, daß ich mir erst heute ein 
Programmierkabel mit 10-Pol Wannenstecker gebaut habe, damit ich den 
atmega32 über mein mysmartUSB programmieren kann. das Kabel scheint zu 
funktionieren.

Den atmega32 hab ich auf einer anderen Platine als das Display.

Leider hab ich keine Ahnung, ob ich das Display richtig angeschlossen 
habe, bzw ob ich überhaupt die isp des m32 zur datenübertragung auf das 
display benutzen kann ?!?!?

bisher angeschlossen wie folgt:

am spi des atmega32:

1: mosd
2: vcc
3: port C1 ( soll am dogm cs1 sein)
4: gnd
5: reset
6: gnd
7: sck
8: gnd
9: miso
10: gnd

am dogm128:

wannenstecker 10-pol:
1: A0 ( pin 38 am dogm)
2: --- (nicht belegt, da display-platine eigene spannungsversorgung mit 
3,3V hat.)
3: cs1 ( pin 40)
4: gnd
5: reset (pin 39)
6: gnd
7: scl ( pin 37)
8: gnd
9: sdi(si) (pin 36)
10: gnd

Es sind für mich noch viele Fragen offen, wie z.B.

ist das überhaupt machbar ..so ???

was passiert mit dem display, wenn die signale vom uC mit 5V kommen ?

Danke im vorraus

[Oli (Gast)]

Hallo

Wenn ich das richtig verstanden habe, möchtest Du den gleichen Stecker 
sowohl für den Programmer als auch das Display verwenden.

Hier meine Erfahrung:
- Man kann das MOSI Signal nicht für A0 oder CS verwenden (warum weiss 
ich nicht), d.h. Pin 1 deines steckers darf für das Dogm nicht verwendet 
werden.
- Man sollte dringend einen Pegelwandler (HC4050) einbauen oder aber am 
besten alles mit 3.3 Volt aufbauen.
- CS muss per externem pull-up Widerstand am Controller das Display im 
Flashvorgang schützen. Hier hilft der interne pull-up nichts, denn der 
wird beim flashen deaktiviert.

Ein paar schaltungsideen gibt es u.a. hier:
http://code.google.com/p/dogm128/wiki/dogm132_attiny84_hardware

Grüße,
Oli

[Martin E. (mrtnernst)]

Hallo zusammen,

ich bin am überlegen für mei nächstes Projekt mit ATMEGA32 ein DOGM128-6 
Display zu benutzen. Ich wollte mir daher schon einmal vorab die Library 
anschauen die ihr hier erstellt und ergänzt habt. Bei mir im AVR-Studio 
kann ich Sie aber nicht kompilieren. Ich bekommen nur Compilerfehler und 
ich kann diese nicht so ganz verstehen. Muss die Version 0.92 der 
Library, wenn ich die files in ein AVR-Studio-Projekt einbinde ohne 
Fehler compilierbar sein?

Es kommt z.B. folgene Fehlermeldung:

../lcd/dogm-graphic.c:105: error: 'UCSR1A' undeclared (first use in this 
function)

in der Runktion: void lcd_data(uint8_t data)

oder

../lcd/dogm-graphic.c:105: error: (Each undeclared identifier is 
reported only once

Ich weiß solche Ferndiagnosen sind schwer zu beantworten. Ich muss dazu 
sagen mit Displays und SPI habe ich noch nicht viel bisher gemacht. Was 
könnte das sein? Fehlen da Dateien? Wie gesagt soll alles bei einem 
ATMEGA 32 später eventuell laufen.

Martin

[Jan M. (mueschel)]

Hallo Martin,
dein Fehler kommt daher, dass die Library für einen Atmega324 und dessen 
USART-Schnittstelle geschrieben ist und bei deinem Atmega32 die Register 
anders heißen. Du musst einfach diese Zeilen in dogm-graphic.h an deinen 
Controller anpassen:

//Define a function that waits until SPI interface is idle
#define spi_wait_for_idle() while(! (UCSR1A & _BV(TXC1)));UCSR1A |= _BV(TXC1)

//Define how to write to SPI data register
#define spi_write(i) UDR1 = i

Christian Sowada hat weiter oben schon seine Variante gepostet, die 
sollte es bei dir auch tun, wenn du die SPI-Schnittstelle benutzt:

#define spi_wait_for_idle() while(!(SPSR & (1<<SPIF)))
#define spi_write(i) SPDR = i

[Martin E. (mrtnernst)]

Vielen Dank!

Ich hatte mir inzwischen soetwas gedacht. Das heißt im Klartext ich muss 
den ganzen Treiber durchgehen und an den SP1-Stellen abändern. Falls ich 
Probleme dabei bekomme melde ich mich wieder. Ich versuche mal so die 
Compilermeldungen loszuwerden.

Martin

[Jan M. (mueschel)]

Alle Stellen die du ändern musst, sind im "Config Block" in 
dogm-graphic.h zusammengefasst.

Außerdem musst du noch die Funktion spi_init() schreiben, die dafür 
sorgt, dass die SPI-Schnittstelle richtig eingestellt ist.
Das Beispiel aus dogm-graphic.h ab Zeile 65 wirst du für den Atmega32 
gerade übernehmen können.

Btw: Es gibt auch noch Version 0.93 mit einigen kleinen Änderungen:
Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator"

[Martin E. (mrtnernst)]

So jetzt habe ich meiner Meinung nach eigentlich alle Dinge angepasst, 
aber jetzt mekert er über eine Referenz zur main. Was ist das nun schon 
wieder? ich komme nich dahinter. Muss ich alles neu anlegen, ich meine 
in einem neuen Prjekt?

Fehlermeldung:

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/crt 
m32.o:(.init9+0x0):  undefined reference to `main'
make: *** [Temperaturdatenlogger.elf] Error 1


Mar

[Martin E. (mrtnernst)]

Hi,

ich habe nun den referenc fehler beseitigt, aber jetzt kommt ständig ein 
weiterer Fehler, dass ich die init_spi_lcd mehrfach definiert habe. Hast 
du einen Tipp für mich als noch unerfahrenen Programmierer?

Martin

Compilerauszug!

D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
dogm-graphic.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font_fixed_8px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font_proportional_8px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font_proportional_16px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
symbols_8px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
symbols_16px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
template_simplefont.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
make: *** [logger.elf] Error 1

[Martin E. (mrtnernst)]

Hi ,

ich möchte eigentlich nur einen funktionierenden Treiber für den Atmega 
32 und das Display. Kann ich dir mein Projekt mal mailen und du schaust 
mal darüber? Es ist bis jetzt nur eine unsinnige main und halt der 
Treiber, den ich für den Atmega 32 veruscht habe anzupassen, was mir 
irgendwie nicht gelingt, weil ich wohl Tomaten auf den Augen habe.


martin

[Jan M. (mueschel)]

Hallo,
das klingt so, als hättest du die Funktion init_spi_lcd() in 
dogm_graphic.h definiert. In header-Dateien steht aber üblicherweise nur 
die Deklaration, nicht die Definition (die gehört in eine .c).

Btw.: Hierbei handelt es sich um ein spezifisches Problem mit deinem 
Projekt, nicht um ein generelles mit der Library. Daher würde ich 
vorschlagen, du machst zur Fehlersuche einen eigenen Thread auf. Dort 
ist dann auch die Wahrscheinlichkeit auf Antworten deutlich höher, da 
ich auch nicht jeden Tag hier ins Forum schaue.

[Ralph (Gast)]

Hallo,

@Jan M.
erst mal vielen Dank für deine tolle Library.
Ich möchte Ziffern mit 48px Höhe darstellen.
Dafür habe ich mit Hagen Reddmann's Fonteditor einen entsprechenden 
Zeichensatz generiert, komm aber auf keinen grünen Zweig, nur 
Zeichensalat.
Mit den beiligenden Zeichensätzen funktioniert alles prima.
Nach langem probieren, habe ich herausgefunden, daß es wohl ein Problem 
mit der Breite der Zeichen gibt. Selbst innerhalb eines Zeichensatzes, 
werden Zeichen <= 20px Breite korrekt dargestellt ab 21px Breite gibt's 
Zeichensalat.
Den beiligenden 24px Font in doppelter Größe darstellen, ist auch keine 
Lösung, da viel zu grobpixelig.

Ist dir das problem bekannt, gibt's ne Lösung dafür?

Gruß
Ralph

[Jan M. (mueschel)]

Hallo Ralph,
diesen Fehler kenne ich noch nicht - das mag aber vor allem daran 
liegen, dass ich bis jetzt noch keine so großen Schriften benutzt habe.

Spontan tippe ich auf einen Überlauf bei irgendeinem int8_t, ab 21 Pixel 
Breite bist du ja bei mehr als 128 Byte pro Zeichen. Ich werde mir den 
Code heute abend mal genauer anschauen.

Kannst du mir deinen Zeichensatz schicken, dann kann ich es direkt damit 
ausprobieren?


Gruß, Jan

[Ralph (Gast)]

Hallo Jan,

danke für die rasche Antwort.
Anbei der Zeichensatz.

Gruß
Ralph

[Jan M. (mueschel)]

Hallo Ralph,
ich habe leider gerade keine Zeit für einen ausführlichen Test, aber 
schau mal bitte in font.c (ungefähr Zeile 180):

/******************************************************************************
 * Outputs a character on the display, using the given font and style
 */
uint8_t lcd_put_char(FONT_P font, uint8_t style, char character) {
  int8_t  i;

i ist der relative Pointer auf die einzelnen Bytes eines Characters. 
Ändere mal die Definition von i in uint16_t, dann sollte das auch mit 
sehr großen Schriften passen.

[Ralph (Gast)]

Hallo Jan,

das war's schon, jetzt gehts einwandfrei.
Vielen Dank.

Gruß
Ralph

[Ralph (Gast)]

Hallo Jan,

hab einen Fehler gefunden

void lcd_clear_area_xy(uint8_t pages, uint8_t columns, uint8_t style, uint8_t col, uint8_t page) {
  lcd_moveto_xy(col,page);
  lcd_clear_area(pages,columns,style);
  }

beim Aufruf lcd_moveto_xy sind die beiden Parameter vertauscht.

Gruß
Ralph

[Duke Scarring (Gast)]

Nette Bibliothek, etwas unübersichtlich zu lesen...

Bei der Initialisierung des EADOGS102 sind die folgenden Werte auch ganz 
gut:

    LCD_SET_BIAS_VOLTAGE(5);            //set voltage regulator R/R
    LCD_SET_VOLUME_MODE(29);            //volume mode set

Durch das Spannungsverhältnis von 5 kann man den gesamten Bereich von 
electric volume nutzen (0..63), ohne das die Kontrastspannung 11.5 V 
übersteigt. Leider muß für jedes Display die Kalibrierung neu gemacht 
werden.

Duke

[Markus (Gast)]

Hi,

ich verwende die V0.93 mit Anpassung der Init Sequenz mit einem DOGM102 
Display. Ich schaffe es nicht, mit lcd_clear_area(8,101,NORMAL) das 
Display vollständig zu löschen. Es bleibt immer die letzte Pixelspalte 
stehen, was sehr lästig ist.

Ich hab das schonmal im Code versucht nachzuvollziehen, und auch 
schonmal 102 oder 103 als Parameter übergeben (das wird abgefangen, 
leider aber nicht wie gewünscht). (102 müsste imho sogar der "richtige" 
Parameter sein)

Irgendwer eine Idee woran das liegt?

Cursor habe ich jeweils vorher mit lcd_moveto_xy(0,0); auf Home gesetzt.

Wenn das noch gefixt würde, wäre die lib perfekt.

Markus

[Jan M. (mueschel)]

Hallo Markus,
ich habe hier ein DOGM132 und kann gerade keinen Fehler feststellen, bei 
mir wird über die gesamte Breite gelöscht. Für dich sollte die richtige 
Einstellung definitiv diese sein:
lcd_clear_area(8,102,NORMAL)


Irgendwie war ich mir sicher, ich hätte hier vor kurzem noch einen Post 
geschrieben - sorry für die späte Antwort an die vorherigen Poster:

@Ralph: Ist in der nächsten Version korrigiert.

@Duke:
>Nette Bibliothek, etwas unübersichtlich zu lesen...
Kannst du das etwas erläutern? Ich bin für Verbesserungsvorschläge 
offen.

[XMEGA (Gast)]

Hallo,

> Nette Bibliothek, etwas unübersichtlich zu lesen...

die Lib funktioniert super,

Die Graphik-Geschichte schaut super aus, mir ist aber bis heute nicht 
klar für was man das braucht? Und ob es überhaupt Sinn macht die 
Graphik-Lib weiter einzubinden. Vielwichtiger wäre ein Lib die 
Linien,Kreise und diverse andere graphische Möglichkeiten ausgeben kann.



Gruß XMEGA

[Markus (Gast)]

Jan M. schrieb:
> Hallo Markus,
> ich habe hier ein DOGM132 und kann gerade keinen Fehler feststellen, bei
> mir wird über die gesamte Breite gelöscht. Für dich sollte die richtige
> Einstellung definitiv diese sein:
> lcd_clear_area(8,102,NORMAL)

Hatte ich probiert, geht wie gesagt nicht. Ich mach mal ein Foto und lad 
das hoch, es ist schwer zu beschreiben was passiert (sieht komisch aus). 
Evtl. hat das auch was mit dem Wrap Around für Text zu tun.

Mal was Anderes, hast Du noch das Template File für den Fonteditor für 
GLCD? Ich hab mir da aus dem anderen Thread die neueste Version besorgt, 
aber da fällt das falsche Headerfile raus weil das Template anders ist.

Idealerweise hast Du noch die Kombination aus Fonteditor mit 
Templatefile?

Markus

[Jan M. (mueschel)]

Markus schrieb:
> Hatte ich probiert, geht wie gesagt nicht. Ich mach mal ein Foto und lad
> das hoch, es ist schwer zu beschreiben was passiert (sieht komisch aus).
> Evtl. hat das auch was mit dem Wrap Around für Text zu tun.

Ein Bild wäre gut, dann kann ich das bei mir nochmal mit verschiedenen 
Einstellungen testen. Wie hast du den wrap-around eingestellt im 
header-file?


> Mal was Anderes, hast Du noch das Template File für den Fonteditor für
> GLCD? Ich hab mir da aus dem anderen Thread die neueste Version besorgt,
> aber da fällt das falsche Headerfile raus weil das Template anders ist.
>
> Idealerweise hast Du noch die Kombination aus Fonteditor mit
> Templatefile?

Das template müsste im Archiv mit enthalten sein, template*.h. Dann 
musst du nur noch die *.ini vom Fonteditor anpassen damit er dieses 
template benutzt. Wenn das nicht geht, kann ich dir morgen auch noch mal 
das komplette Paket schicken.
Wenn du neue Schriften generierst, vielleicht kannst du mir diese 
schicken, dann kann ich sie in die Library mit aufnehmen.


@XMEGA:
Grafikfunktionen sind mit dieser Library leider etwas schwer umsetzbar. 
Dafür müsste man zuerst einen Grafik-RAM im uC anlegen, da das Display 
ja keine pixelweisen Zugriffe erlaubt.

[Markus (Gast)]

Jan M. schrieb:
> Ein Bild wäre gut, dann kann ich das bei mir nochmal mit verschiedenen
> Einstellungen testen. Wie hast du den wrap-around eingestellt im
> header-file?

Hatte beide Versionen getestet, steht auf 1 bei mir zur Zeit.

> Das template müsste im Archiv mit enthalten sein, template*.h. Dann
> musst du nur noch die *.ini vom Fonteditor anpassen damit er dieses
> template benutzt. Wenn das nicht geht, kann ich dir morgen auch noch mal
> das komplette Paket schicken.

Schau ich nach, hab ich vermutlich beim "Aufräumen" vom Projekt mit 
entsorgt weil ich damals nichts damit anzufangen wusste :-)

> Wenn du neue Schriften generierst, vielleicht kannst du mir diese
> schicken, dann kann ich sie in die Library mit aufnehmen.

Wird eine Bibliothek mit Batteriesysmbolen als Ladezustandsanzeige (mit 
10 Bargraphsegmenten). Mit dem Fonteditor arbeitet es sich leichter, 
momentan hab ich das als einzelne Bitmaps exportiert, das ist bisschen 
lästig wenn man viel ändern muss.

Ist also kein Font im eigentlichen Sinne.

Falls Interesse besteht, kann ich das Zeugs natürlich gerne zur 
Verfügung stellen.

Markus

[AleX A. (highfly3r)]

Hallo an alle da draußen,

wer kann mir mit Grafikfehler helfen???

Die Lib ist echt klasse. Nach 3 Tagen (SS-PIN der SPI-Schnittstelle war 
nicht HIGH bzw. Output) probieren klimperte mein DOG-L schon einmal paar 
Zeichen auf das Display. Allerdings mit komischer Pixel-Leiste am 
rechten Rand des Displays. Dabei ist es egal, welche Funktion zur 
Textausgabe verwendet wird.

Ich benutze ein Mega644 mit 20MHz auf selbst erstelltem Testboard. 
Programmierumgebung AVR-Studio 4 (aktuellste Ver.). Hardwarefehler kann 
ich ausschließen, da die Lib von U. Radig diese Fehler nicht produziert.

Schaut euch bitte mal das Bild an, vll. hat jemand eine Idee dazu.

Dank schon mal im voraus...

lg

[Guest (Gast)]

Sieht so aus, als würde die Ansteuerung nicht ganz sauber sein (Clock 
und Daten nicht syncron).

[Jan M. (mueschel)]

Hallo Alexander,
spontan weiß ich keinen Grund warum das passiert. Das Display hat 128x64 
Auflösung?
Ich nehme an, du benutzt die Init-Routine aus der Library die am Anfang 
das gesamte Display löscht?
Wenn du keinen Text ausgibst, sind die vier Pixelspalten dann auch zu 
sehen?
Was passiert, wenn dein Text um ein paar Pixel breiter ist und bis in 
diese Spalte hineinreicht?
Und mit einer anderen Schriftart (nicht, das an dem Zeichensatz etwas 
kaputt ist)?

@Guest: Gegen einen grundsätzlichen Timinfehler spricht aber, dass der 
Text ohne Fehler ausgegeben ist.

[AleX A. (highfly3r)]

Hallo,

sry, dass ich mich erst jetzt mit meinem Problem zurück melde.

Ich denke dass eine komplette Verschiebung um 4 Pixel in x-Richtung 
statt findet.
@ Jan: Ich benutze deine Lib 093 hier aus dem Forum und ich muss 
unabhängig der Fonts bei

lcd_moveto_xy(0,x)

für das x mindestens 4 angeben, damit ich in der ersten Pixelspalte 
meinen ersten Buchstaben setzen kann.
P.S. ist das Absicht, dass hier x und y vertauscht sind???

Probiert habe ich jeweils ein EA-DOGM und DOGL. Beide 128 x 64 Pixel.

Schreibe ich über die Zeile hinaus (WRAP=0) überschreibt er auch das 
Pixelmuster in der jeweiligen Zeile. Lösche ich das komplette LCD 
bleiben die letzten vier Pixelspalten mit dem letzten Inhalt über. Rest 
wird sauber gelöscht. Setze ich in der "Löschroutine" das max. x auf 132 
anstatt auf "LCD_WIDTH" löscht er auch alles.

Also meiner Meinung nach keine Probleme mit der Initialisierung des LCDs 
oder Probleme mit der SPI-Schnittstelle.

[Jan M. (mueschel)]

Ach klar, jetzt sehe ich es auf dem Foto. Du benutzt das Display ja im 
Top-View Modus. Dort gehen die Adressen von 4 bis 131 (siehe Datenblatt 
Seite 7 oben links). Das berücksichtigt meine Library im Augenblick 
nicht.

Ich versuche das in der nächsten Version einzubauen, kann dir aber nicht 
sagen, wann es soweit ist. Bis dahin musst du dir leider einen 
Work-Around basteln. Sorry!

[AleX A. (highfly3r)]

Ahh, ok danke!

Ich hab aber leider noch ein viel bescheideneres Problem...
Ich betreibe den µC mit 5V. Zum LCD hin ein 74HC5040 Pegelwandler um auf 
die 3,3V für das LCD zu kommen.
Nun das Problem: näher ich mich mit meiner Hand dem Pegelwandler, 
"stürzt" das Display ab. Erst durch µC-reset wieder OK. Hab schon vers. 
SPI-Geschwindigkeiten getestet (prescaler min bis max), ohne Erfolg. 
Dabei ist es egal, ob ich den Programmer gesteckt lasse oder nicht. 
Anderes Phänomen ist, wenn ich das Experimentierboard über eine gewisse 
Zeit nicht mit Spannung versorge und dann wieder Spannung anschalte, das 
Lcd auch nichts anzeigt, sondern erst noch µC-reset.
Was könnte dafür die Ursache sein?

Ich benutze für die Ansteuerung des LCD ausschließlich den PORTB den ich 
vor der Display-Init auf Ausgang setze.

[Fabian F. (grottenolm)]

Hi Zusammen,

ich setze mich gerade mit dem EA-DOG XL Display auseinander und bin 
dabei auf deine Software gestoßen. Ich versuche diese jetzt gerade an 
das Display anzupassen. Die Displayinitialisierung klappt jetzt soweit 
und ich wollte jetzt versuchen ein paar Buchstaben auf das Display zu 
bringen.Einzelne Pixel  kann ich schon mit lcd_data() setzen.
Wenn ich nun Versuche die Funktion:
lcd_put_string_P(FONT_FIXED_8,NORMAL,PSTR("hello"));
aufzurufen, bekomme ich die folgende Fehlermeldung:
Error  2  undefined reference to `font_fixed_8px'

Die Definition ist ok, nachdem &font_fixed_8px den selben Fehler 
liefert. Ich habe an der Font.h und font.c nichts geändert, außer die 
auskommentierten Funktionen wieder einzufügen(z.94-101) (Nachdem ich 
sonst mit Fehlern überhäuft werde).
Außerdem habe ich noch die Zeile 215 in font.c auskommentiert, da die 
funtion     double_bits((row&1),tmp); diese Fehlermeldung hervorruft:
Error  2  undefined reference to `double_bits'

Ich benutze AVR Studio 5 und einen At90CAN (Was aber dafür wohl nichts 
zur Sache tun sollte).
Mein C ist eher rudimentär, weswegen ich mitt:
#ifdef FONTS_INCLUDE_font_fixed_8px
  extern const struct font_info font_fixed_8px PROGMEM ;
  #define FONT_FIXED_8 &font_fixed_8px
#endif
nicht viel anfangen kann. Wird hier die Datei mit den Fonts aufgerufen? 
Wieso kann ich nirgendwo einen Pfad finden?
Im Anhang ist das ganze Projekt.

Gruß, Olm

[Jan M. (mueschel)]

Hallo,
das Problem scheint einfach nur zu sein, dass du vergessen hast, alle .c 
und .h Dateien aus meinem Archiv in dein Projekt mit aufzunehmen (Die 
font*.c müssen im Unterverzeichnis Fonts liegen bleiben, da dort das 
#include relative Pfade benutzt).


Zu deiner zweiten Frage:

>#ifdef FONTS_INCLUDE_font_fixed_8px
Wenn oben FONTS_INCLUDE_font... definiert wurde, du dich also 
entschieden hast, diesen Font zu benutzen...
>  extern const struct font_info font_fixed_8px PROGMEM ;
... dann existiert irgendwo (= in einem anderen File in deinem Projekt) 
ein struct mit den Definitionen.
>  #define FONT_FIXED_8 &font_fixed_8px
... und dann definieren wir uns noch einen Namen um uns das &xyz 
Konstrukt sparen zu können.
>#endif
Feierabend.
Automatisch eingebunden wird damit nichts, der Compiler bekommt nur 
mitgeteilt, dass diese Variablen außerhalb der momentanen Datei 
existieren und der Linker sie später finden wird.

[Fabian F. (grottenolm)]

Cool, danke für die schnelle Antwort. Das einbinden der Dateien wars was 
gefehlt hat. Hab dann auch gleich mal ein paar versuche gemacht, kriege 
aber etwas merkwürdige Schriftbilder. Bei den Zahlen kann man es am 
besten sehen (Bild). Scheinbar verrutscht jede neue Zeile um eine 
Font-Breite (Eingentlich steht da "4444").
Die Diagonale und den Quader hab ich da mit lcd_data() hingeschrieben. 
Offenbar inkrementiert das Dispaly von Links nach Rechts, was auch 
logisch erscheint. Die 4er sehen aber irgendwie aus, als würde es zu 
weit zählen, bzw. in der neuen Zeile nicht bei 0 anfangen. Irgendwelche 
Ideen was dahintersteckt?

Auszug aus Programm:
init_spi_lcd();
  lcd_init();
  lcd_moveto_xy(0,0);
  lcd_data(0b11000000);
  lcd_data(0b00110000);
  lcd_data(0b00001100);
  lcd_data(0b00000011);
  lcd_data(0b00000000);  //Diagonale Line
  lcd_data(0xFF);
  lcd_data(0xFF);
  lcd_data(0xFF);
  lcd_data(0xFF);    //4x4Block

  lcd_moveto_xy(2,20);
  lcd_put_int (FONT_DIGITS_24,NORMAL,4444);

[Jan M. (mueschel)]

Interessant... auf meinem DOGM habe ich dieses Problem noch nicht 
gesehen, ein DOGXL hatte ich aber auch noch nicht in den Händen.

Auf jeden Fall musst du den Text mit DOUBLE_HEIGHT ausgeben - damit 
berücksichtigst du dass das XL zwei Bits pro Pixel verwendet (bei dir 
fehlt jedes zweite vertikale Pixel und die Höhe sind nur 12px). Meine 
Library hat dafür noch keine automatische Funktion.

Die Verschiebung von Zeile zu Zeile (und das auch noch nach links) kann 
ich im Augenblick nicht verstehen, da werde ich morgen nochmal drüber 
nachdenken müssen.

Aber trotzdem schön zu sehen, dass das auch mit dem DOGXL auf Anhieb 
zumindest halbwegs läuft. Spricht auch für die Qualität des Datenblatts, 
dass man sich blind auf die Beispiel-Initialisierungen verlassen kann.

[Fabian F. (grottenolm)]

Hi,
ich hab mal noch mit der Autoincrement-Richtung rumgespielt, was aber 
nichts geändert hat.
Im bild noch mal ein besseres Beispiel. Die Striche oben sind je im 
Abstand von 10 Pixel.
Die "7" sollte in auf (2,0) sein(Stimmt wohl). Jede weitere Zeile ist um 
eine Font-Breite nach links verschoben, auch wenn Line-wrapping des 
Displays aus ist.
Von da würde ich mal vermuten, dass etwas mit der Wrap-funktion in 
kombination mit der neuen Displaygröße nicht stimmt (Z.B. hat die 
Page-adressierung nun 5 bits(26 Pages/Zeilen).

Der Display Controller ist hier der UC1610. Das Display hat 
160Pixelx26Zeilen á 4 Pixel(104).

Hier der relevante Code für das Bild:
  uint8_t gap;
  while(gap<=16){
    lcd_data(0b11111111);
    lcd_move_xy(0,10);
    gap++;
  }
  lcd_data(0b11111111);
  lcd_moveto_xy(2,0);
  lcd_put_int (FONT_DIGITS_24,DOUBLE_HEIGHT,7);

[Jan M. (mueschel)]

Ich habe gerade noch einmal in deinen Code geschaut - du scheinst an 
einigen Stelle die Kommandos umdefiniert zu haben um den Code an den 
Controller des DOGXL anzupassen. Das macht es für mich jetzt natürlich 
sehr schwierig den Grund für die falsche Darstellung zu finden.

Meine Vorgehensweise wäre, zunächst die Library so zu erweitern, dass 
das DOGXL direkt unterstützt wird und zu schauen ob der Fehler dann 
immer noch auftritt. Leider sind dazu einige größere Änderungen nötig, 
für die ich alleine im Augenblick keine Zeit finde. Wenn du willst, 
können wir das aber auch gemeinsam angehen.

[Fabian F. (grottenolm)]

Die Änderungen beschänken sich weitgehend auf die Initialisierung, 
nachdem diese für das XL anders abläuft, und auch teilweise andere 
Befehle hat. Alle meine Änderungen erkannt man aber eigenltich daran, 
dass ich Befehle in Binärform schreibe(Hex ist mir ein Graus).
Wie man dem Bild entnehmen kann, habe ich auch beim Schriftbild 
Fortschritte gemacht. Nachdem ich den Fehler auf die Put_char-Funktion 
eingegrenzt habe, hab ich einfach willkürlich Variablen verändert um zu 
schaun was sich ändert (Nachdem ich die Funktion nicht 100% 
durchsteige). Als ich an LCD_MOVE rumgefingert habe(Setzt den cursor um 
die Breite des Fonts zurück und eine Zeile tiefer oder?) fiel mir auf, 
dass das Problem an "-char_final_width" liegen muss. Mit den Parametern 
LCD_MOVE(1,0) klappts. Dann blieb noch das Problem, dass die Zahlen von 
Rechts nach links geschrieben wurden(Offenbar benutzt dieses Display ein 
gegenüber den kleineren Hunden ein inverses Koordinatensystem.
LCD_MOVE(-char_final_height,+char_final_width); statt
LCD_MOVE(-char_final_height,-char_final_width);
löste auch diesen Problem.

Was noch bleibt sind die obstrusen Leerzeichen und die Tatsache, dass
lcd_put_string_P() nicht funktioniert
lcd_put_string() aber schon. Was ist denn da der Unterschied?

Hast du auch eine Mail(PM)? Dann kann ic dir den veränderten Code mal 
schicken.

[Jan M. (mueschel)]

> lcd_put_string_P()
Diese Funktion holt sich den string aus dem ROM.

Das Problem mit den Leerzeichen war ein Bug in Version 0.92. 0.93 vom 
06.09.2010 ist korrigiert.

> Offenbar benutzt dieses Display ein
>gegenüber den kleineren Hunden ein inverses Koordinatensystem

Das schreiben von rechts nach links ist konsistent mit dem Phänomen der 
zerhackten Buchstaben.
Gegen ein invertiertes Koordinatensystem spricht, dass die Buchstaben ja 
nicht spiegelverkehrt erscheinen. Allerdings hat dieser Kontroller ja 
auch einige Funktionen um das auto-inkrement der Adressen an die eigenen 
Bedürfnisse anzupassen. Vielleicht ist bei diesen Einstellungen etwas 
durcheinandergekommen?

Die Buchstaben werden Zeile für Zeile jeweils von links nach rechts 
geschrieben. In den Zeilen verlasse ich mich auf das auto-inkrement der 
Spaltenadresse, das weiterschalten um eine Zeile und zurückgehen an den 
linken Rand des Buchstabens mache ich manuell.

Ansonsten widerspricht das irgendwie jeder Logik, dass man einfach Pixel 
für Pixel von links nach rechts schreibt und bei einem Zeilenwechsel 
nicht wieder nach links zurückgehen muss... Vielleicht ist es aber auch 
nur ein Feature a la "wenn die page Adresse geändert wird, wird die 
column wieder auf den Wert zurückgesetzt der zuletzt geschrieben wurde" 
- das habe ich im Controller-Datenblatt aber noch nicht gesehen.

[Jörg H. (idc-dragon)]

Wie ich schonmal schrieb verwende ich diese Lib leider nicht, weil ich 
sie zu spät "gefunden" habe, da hatte ich schon was Eigenes, ist im 
Prinzip ähnlich.

Ich hatte just am Wochenende das "Problem" das mir noch gute, große 
Zeichensätze fehlten. Als alter Rockbox-Mitentwickler erinnerte ich 
mich, das dort die Pixel dem LCD-Layout folgend auch in 8er-Reihen 
senkrecht geschrieben werden, bzw. mittlerweile wurden. Und das es dort 
ein Konverter-Tool gibt, was den Zeichensatz als C-Arrays ausgiebt. Das 
konnte ich zweckentfremden. Für den Fall das hier auch Bedarf besteht 
verrate ich gern wie:

Eine schöne Übersicht über die Fonts gibt es hier (wenn auch nicht 
alle):
http://rasher.dk/rockbox/fonts/
Wir brauchen als Ausgangspunkt eine .bdf-Datei, die sind dort leider 
nicht.

Falls man sich einen X.Org-Font ausgesucht hat findet man die zugehörige 
.bdf-Datei hier:
http://webcvs.freedesktop.org/xorg/xc/fonts/bdf/

Das Tool für die Konvertierung von .bdf in C-Code Arrays ist hier:
http://svn.rockbox.org/viewvc.cgi/trunk/tools/convbdf.c?view=log
Das muß man selbst kompilieren, für die senkrechten Spalten #define 
ROTATE auskommentieren um das alte Format zu erzwingen.
Beim Aufruf gibt es nützliche Kommandozeilenparameter um nur einen 
Ausschnitt des Zeichensatzes rauszuschreiben (z.B. von ASCII 32 bis 127) 
und um oben und unten was abzuschneiden. Die Standardzeichen passen 
häufig in einen kleineren Bereich.

[Orko (Gast)]

Hey Leute,

wollte mal fragen ob mir jemand mal erklären kann wie ich Bilder 
darstellen kann ich mein vom Prinzip her schon klar mit 
"lcd_draw_image_xy_P" aber wie binde ich die Bilddaten ein? Hab das 
Programm was Jan M. aufgezeigt hat verwendet das dass Bild umwandelt und 
ab dem Punkt komme ich leider nicht weiter. 
"LCD_INCLUDE_GRAPHIC_FUNCTIONS  1" sollte ja so auch stimmen.

Ich nehme an das dass erstellte C File mit ins Projekt muss .? Bin 
leider neu in C und noch nicht ganz angekommen.

[Fabian F. (grottenolm)]

Auf welchem Display?

[Orko (Gast)]

Ach so ja hab ich ganz vergessen zu erwähnen auf das "EA DOGM132".

[Jan M. (mueschel)]

Hallo Orko,
ja, das c-file muss mit ins Projekt. Am einfachsten kopierst du den 
generierten Code direkt in deinen Quellcode hinein.
Oder du bindest die neu erstellte Datei zusätzlich ein, dann musst du 
die Variable aber mittels "extern" deinem Code bekannt machen.

Dann kannst du einfach
> lcd_draw_image_P(data_demo_image,(Höhe/8),Breite,NORMAL);
aufrufen.




@Fabian: Ich bin noch dabei die Library für das DOGXL vorzubereiten, 
nächste Woche sollte es soweit sein. Es wäre schön, wenn du das dann 
testen könntest.

[AleX A. (highfly3r)]

@orko

in headerdatei z.b.: "bitmap.h"

static uint8_t PFEIL_LINKS[] PROGMEM = {
// 2 pages x 8 columns
0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0xAA,
0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xAA
};

aufruf dann mit:

lcd_moveto_xy(0,0);
lcd_draw_image_P(PFEIL_LINKS,2,8,NORMAL);

Bild wird hier an die obere, linke Bildschirmecke gezeichnet (0,0) und 
es muss die Größe des Bildes mit an die Funktion übergeben werden (8 
Pixel breit und 2 pages hoch, was 2*8 Pixel entspricht)

Bilder müssen leider eine Höhe von einem vielfachen von 8 haben (8px, 
16px,...) und was auch schade ist, dass diese in y-Richtung nicht 
Pixelgenau gesetzt werden können (nur in x-Richtung)

AleX

[Jan M. (mueschel)]

AleX A. schrieb:
> Bilder müssen leider eine Höhe von einem vielfachen von 8 haben (8px,
> 16px,...) und was auch schade ist, dass diese in y-Richtung nicht
> Pixelgenau gesetzt werden können (nur in x-Richtung)

Zumindest zweiteres stimmt nicht:
Mit lcd_draw_image_xy_P kannst du das Bild pixelgenau plazieren, musst 
allerdings beachten, dass die "restlichen" Pixel einer Page dann 
gelöscht werden.
Ohne lesbaren Grafik-Speicher ist halt leider nicht mehr drin.

[AleX A. (highfly3r)]

Hallo Jan,

könnte man nicht einen temporären Zwischenspeicher im µC realisieren, in 
dem geschrieben und gelesen werden kann? Änderungen im Zwischenspeicher 
natürlich an das Display schreiben. Ich würde mir als Zwischenspeicher 
ein unsigned char Array mit 128x8 Zellen vorstellen. Würde dann 
natürlich 1024 Bytes vom Speicher (SRAM???) dafür flöten gehen.

Das als Grundlage. Damit würden dann auch keine Pixel einer Page 
gelöscht werden, die schon vorhanden waren. Wenn das dann für Bilder 
funktioniert, sollte es doch auch für die Fonts funktionieren!?

Wird wahrscheinlich eine abartige Bit-Schieberei und zulasten der 
Geschwindigkeit gehen.

[Jan M. (mueschel)]

Ja klar, das geht. Der Aufwand dürfte sich in Grenzen halten. Im 
wesentlichen muss nur die Ausgaberoutine geändert werden, so dass sie 
neben den Daten auch eine Maske der zu ändernden Bits bekommt und vor 
dem Schreiben zum Display mit den Daten im RAM überlagert. Dazu dann 
(später) noch die Anpassung aller schreibenden Funktionen um 
pixelgenaues Verschieben zu ermöglichen.


Allerdings sind 1 kB ja doch eine ganze Menge Speicher für einen kleinen 
atmega. Aber zumindest in der 64* Serie mit 4kB kann man sicher darüber 
nachdenken - oder eben gleich einen externen RAM benutzen.

Dann kann man sicher auch über Grafik-Funktionen nachdenken, also z.B. 
Kreise zeichnen. Das ist dann aber am Ende schon sehr viel mehr als das 
für das diese Library ursprünglich gedacht war.

Zur Performance - das müsste man mal nachmessen, wie lange 
lcd_draw_image_P und lcd_draw_image_xy_P im Vergleich brauchen. Dabei 
muss man aber einrechnen, dass durch das Verschieben eine Page mehr 
geschrieben werden muss.

[Peter Buttgereit (Gast)]

Hallo Jan,

auch von mir ein herzliches Bravo für die Bibliothek.

Bei meinen ersten Gehversuchen mit dem DOGL an einem ATmega128 (8 MHz), 
angeschlossen an Hardware-SPI (Initialisierung wie im Beispiel), gab es 
Probleme mit der Initialisierung: Das Display blieb hartnäckig 
spiegelverkehrt und zeigte die oben schon erwähnten Fransen am 
Bildschirmrand.

Abhilfe schafften eingefügte Pausen in lcd_init():
[Version 0.93]

//[...]
LCD_RESET();
//Load settings
_delay_ms(100);
LCD_ORIENTATION_NORMAL();
 _delay_ms(20);
LCD_SET_BOTTOM_VIEW();
_delay_ms(20);
LCD_SET_FIRST_LINE(0);        
//[...]

Jetzt läuft es prima.

Mit Dank + Gruß,

Peter

[Andreas Müller (Gast)]

Hallo Jan und Fabian!

Da ich momentan in meinem Projekt ebenfalls ein DOGXL160-7 einsetze 
wollte ich wissen, wie weit ihr mit der Portierung für dieses Display 
vorangeschritten seid. Ich habe das Beispiel Projekt der EA Seite 
laufen, das Funktioniert sehr gut! Jetzt wollte ich nun verschiedene 
Schriftgrößen Testen und das ist mit dem Beispielprojekt noch nicht 
möglich!

@Fabian:

Wäre es möglich, dass du mal dein Projekt hochlädst, du hast da ja 
scheinbar schon einiges mit verschiendene Schriftgrößen am laufen!

Werde mich jetzt parallel mit der Version vom 06.09.2010 auseinander 
setzen!

Vielen Dank!
Mit freundlichem Gruß,
Andreas Müller

[Fabian (Gast)]

Moin,

ich hab das Displayprojekt inzwischen an meinen Programmiersklaven 
abgeben. Ich werd ihn mal fragen was er mir gegen kann.

Schönen Gruß

[Jan M. (mueschel)]

Hallo Andreas,
Bis jetzt habe ich auch nur angefangen mit der Portierung, bin aber noch 
nicht fertig. Wenn nichts dazwischenkommt werde ich am nächsten Montag 
die grundlegenden Dinge  fertig machen,  dann kann ich dir den Code 
schicken.

Jan

[J. S. (harry_2)]

Hallo zusammen,
ich glaube bei euch bin ich genau richtig. Ich versuche auch ein
EA-DOGM128-6 zum laufen zu bekommen. Also, das ist jetzt etwas
übertrieben, ich habe ehrlich gesagt im Moment nicht die Zeit mich
richtig damit zu befassen wie ich es gerne möchte. Ich brauche
eigentlich Hilfe dabei das Teil zu testen. Es soll irgend etwas anzeigen
das ich weis, es geht. Wenn ich damit warte bis ich so weit bin,
und das Ding ist kaputt, kann ich es nicht mehr zurück schicken.
Mein Problem ist weiter, ich kann kein C, Assembler wäre echt
toll. Ich hoffe nicht, das sich durch meine Anfrage jemand auf den
Schlipps getreten fühlt, von wegen, "der lässt sich hier im Forum
bedienen". Vieles kann ich einfach noch nicht, da ich mich noch im
Selbststudium mit der ganzen Materie befinde. In Hardware kann ich
richtig helfen wenn es benötigt wird, aber hierbei, blutiger
Anfänger. Also auf meinem Testbord sitzt ein Mega88 und wie gesagt
Assembler ist das meine.

Gruß an alle

[Jan M. (mueschel)]

Hallo,
hier ist die aktuelle Version (0.94) meiner DOG-Library. Aktuelle 
Änderungen:

- Reihenfolge der Argumente von lcd_clear_area_xy() korrigiert
- Befehle für DOGXL160 hinzugefügt (siehe unten)

- Einzelne Zeichen dürfen jetzt größer sein als 128 Byte
- 32 Pixel hohe Ziffern hinzugefügt, Breite so, dass 4 Ziffern plus 
Doppelpunkt in 128 Pixel Breite passen.


Zur Unterstützung des DOGXL habe ich alle Befehle aus dem Datenblatt 
eingebunden, die Initialisierung nach Datenblatt eingebaut. Testen kann 
ich das leider mangels Display nicht, ich kann nur soviel sagen: Es 
kompiliert...
Ich hoffe, dass sich einer der Interessenten von vorher findet, der ein 
XL hat und das ganze testen kann.

[Gerhard G. (xmega)]

Hallo Jan M.,


Jan M. schrieb:
> der ein XL hat und das ganze testen kann

ich habe deinen Code mit einem DOGXL160 getestet.

Das Display zeigt bis gut über die Hälfte des Displays alles ordentlich 
an. Der Rest ist Pixelsalt.

Habe das Ganze auch auf einen Xmega32a4 getestet und da trat der selbe 
Fehler auf.

Habe den Code kurz überflogen, aber keinen Fehler gefunden.




Gruß xmega

[Jan M. (mueschel)]

Hallo,
vielen Dank für deinen Test - da scheint ja schon einmal einiges zu 
funktionieren.

Zeile 238 in dogm_graphic.h ist das Problem:

#define LCD_SET_PAGE_ADDR(i)          lcd_command(LCD_PAGE_ADDRESS | ((i) & 0x1F))

Die Maske stand auf 0x0F, muss aber natürlich 0x1F sein um alle 26 Pages 
addressieren zu können.

[Gerhard G. (xmega)]

Hallo,

alles klar, funktioniert bestens.



Danke!!!


Gruß xmega

[Gerhard G. (xmega)]

Hallo Jan M.,

musste noch folgende Zeile ändern:


#define LCD_GOTO_ADDRESS(page,col)    lcd_command(LCD_PAGE_ADDRESS | 
((page) & 0x1F)); \

Erst dann war alles ok!

Gruß xmega

[Gerhard G. (xmega)]

Hallo Jan M.,

ich habe mal die neueste Version für Atxmega und Amega644 hier 
eingestellt:


http://www.basteln-mit-avr.de/


Gruß xmega

[Gerhard G. (xmega)]

Hallo,

an alle die mit einem DOGXL160 und der Lib von Jan M. experimentieren!

EA DOGXL160 im I2C/TWI Betrieb mit einem Atxmega32A4.

I2C/TWI Takt: 4 Mhz

Geht richtig flott!

Näheres: http://www.basteln-mit-avr.de/atxmega32a4.html


Gruß Xmega

[Orko (Gast)]

Hi ho Leute,

wollte mal fragen ob mir jemand erklären kann woran es liegen kann das 
mein µC von Zeit zu Zeit einfach mitten in der darstellung eines Bildes 
oder auch Text stehen bleibt und nichts mehr von sich gibt. Ich hab 
einen ATmega16 mit 16MHz und das Display ist ein 132er. Könnte das vlt. 
am Stack liegen? Hab aber auch eigentlich keine weiternen Unterprogramme 
geschrieben die den Stack füllen könnten. Spannungsversorgung hab ich 
auch schon mit dem Oszi. überprüft und hat nichts ergeben. Mein Reset 
Port hab ainfach mit einem 100k Widerstand gegen 5V versehen. Was auch 
schon seltsam ist ist das der µC beim Einschalten der Versorgunsspannung 
ohne Programmieradapter auch schon nicht von alleine los legt.

[Krabby (Gast)]

Hey danke für deine Mühe und diese tolle Library.

Bekomme Sie leider nicht zum laufen. Er zeigt mir einen Haufen von 
undefined reference Fehler an. Unter anderem init_spi_lcd, 
font_fixed_8px usw usw.

Habe die dogm-graphic.c/.h und die font.c/.h eingebunden. Muss ich die 
einzelnen Fonts auch in das Projekt einbinden? AVR STudio 5 kopiert dann 
die dateien in den Hauptordner was ja auch nicht Sinn der Sache ist.

Habe die Änderungen vorgenommen:

#define spi_wait_for_idle() while(!(SPSR & (1<<SPIF)))
#define spi_write(i) SPDR = i


Konnte dadurch fehler minimieren aber habe immernoch ca 20 Fehler...

Wie kann das sein?

[Krabby (Gast)]

Ah, ich habe vergessen die init_spi_lcd zu aktivieren indem ich die 
Kommentierung entfernt habe ...

Aber jetzt sagt er mir immernoch LCD_NOP undeclared first use in this 
function.

[André R. (andr_r23)]

Hat irgendjemand ein Funktionierendes Beispiel für DOGM/DOGL da über SPI 
mit einem Atmega?

Habe einige Probleme die ich mir nicht erklären kann. Kann ohne Fehler 
Kompilieren aber bekomme NICHTS auf dem Display angezeigt. Habe die 
Ports richtig angepasst und die SPI initialisiert wie es hier schon 
gezeigt wurde.

Bei:

  lcd_init();
  lcd_moveto_xy(2,20);
  lcd_put_string(FONT_FIXED_8, NORMAL, "Hallo Welt");

Passiert einfach garnichts auf dem Display.

Bei:
        lcd_moveto_xy(2,0);
  lcd_put_int (FONT_DIGITS_32,NORMAL,4444);

Kann ich nicht Kompilieren und er beschwert sich:


Error  3  expected 'int16_t' but argument is of type 'const struct 
font_info *'

Error  4  too many arguments to function 'lcd_put_int'

Warning  2  passing argument 1 of 'lcd_put_int' makes integer from 
pointer without a cast


Ich musste auch tmp = double_bits((row&1),tmp);  ausklammern da er immer 
gemeckert hat über undefined reference zu double_bits.

Hat jemand eine Idee oder kann mir jemand bitte sein funktionierendes 
Programm hochladen? (Mit SPI bei einem DOGM/DOGL und Atmega)

Mit der Bibliothek von Ulrich Radig funktioniert es aber die Lib ist bei 
weitem nicht so umfangreich und toll geschrieben wie diese hier.

Vielen Dank

[Gerhard G. (xmega)]

Hallo,

schau ma hier:

http://www.basteln-mit-avr.de/

Gruß Xmega

[André R. (andr_r23)]

Danke für den Link.

Ist leider mit dem Xmega und das dann abzuändern ist ja relativ 
aufwendig oder? Habe davon keinerlei Ahnung.

du hast eine datei spic eingebunden. Brauch ich die auch? Ich habe nur 3 
Pins angeschlossen. CS ist an PortB4, Reset an PortB3, A0 an PortB2 
mehr habe ich nicht angeschlossen.

Nutze einen Atmega16. Mit der Lib vom Radig reichen die Anschlüsse auch 
da lass ich sogar noch den CS weg da brauch ich nur 2 Pins anschliessen 
und es läuft.

Was hast du gemacht mit SPI_MOSI, SPI_MISO, SPI_SCK ? Wo soll ich die 
anschliessen? PIN 24/25 wie du sie benutzt hast sind bei mir mit 
Kondensatoren belegt.

Danke ^^

[Gerhard G. (xmega)]

Hallo


Hier gibt es auch eienen Code füt Atmega644, der ist kompatible zu fast 
allen Atmegas.

SPI musst du natürlich komplett einbinden.

Schau dir das mal in Ruhe an, und melde dich dann nochmals!

Gruß Xmega

[André R. (andr_r23)]

Ich habe jetzt exakt das was du auf dem Mega644 gemacht hast auf meinen 
Mega16 gepresst. Habe alle Anschlüsse gleich auch die MOSI und SCK 
anschlüsse. Hab im AVR STudio den Mega 16 eingestellt und kompiliert und 
geflasht.. resultat ist ein leeres Display. ?!?!?

[Gerhard G. (xmega)]

Hallo,

- Wichtig -> Die Geschichte funktioniert mit 3,3 Volt, Datenblatt lesen


- Wichtig -> LCD_CS 10K Widerstand nach 3,3V!!


In der  dogm.graphic.h

Select the display type: DOGS102: 102, DOGM128/DOGL128: 128, DOGM132: 
132

#define DISPLAY_TYPE  160

- dein Display-Typ einstellen

Gruß Xmega

[André R. (andr_r23)]

Habe ich alles gemacht Display trotzdem leer. Target Voltage auf dem 
stk500 ist auf 3,3V eingestellt. Der 10k Widerstand ist vom CS auf 3.3V. 
Das Richtige Display habe ich ausgewählt habe 128 für das DOGL 
ausgewählt.

Kriege mit AVR Studio 4 ne Warnung:

gcc plug-in: No AVR Toolchain installation found. The AVR GCC plug-in 
can still be used if you set up your own build tools.


Im AVR Studio 5 kann ich obwohl ich alles eingebunden habe nichteinmal 
kompilieren. da zeigt er mir viele Fehler in der font.c an und dazu halt 
immernoch der Fehler mit den double_bits.

Woran kann das liegen das 1. das Display komplett leer bleibt. Und 
wodran kann es liegen, dass ich in AVR Studio 4 Kompilieren kann und im 
5er nicht? Obwohl die gleichen Dateien eingebunden sind.

[André R. (andr_r23)]

Hab im makefile mcu name auf atmega16 geändert. Nun kriege ich keine 
Fehlermeldung mehr im AVR Studio 4 aber auch keinerlei Ausgabe.

[André R. (andr_r23)]

Display läuft nun mit deinem Beispiel. Warum verstehe ich nicht. Aber 
egal es läuft nun ohne das ich etwas gemacht habe.

Wie kann ich mit lcd_moveto_xy(x,y) die x position auf den Pixel genau 
festlegen? Die ist ja jetzt Zeilenweise gemacht will aber an eine ganz 
genaue Position einen Text oder Zahl ausgeben.

[Jan M. (mueschel)]

>Und wodran kann es liegen, dass ich in AVR Studio 4 Kompilieren kann und im
>5er nicht? Obwohl die gleichen Dateien eingebunden sind.
Vorsicht beim Einbinden im AVRStudio 5. Dateien werden standardmäßig 
alle in ein Verzeichnis kopiert und damit stimmen dann natürlich alle 
relativen Links zu header-files nicht mehr. Also beim Einbinden immer 
nur verlinken und nicht kopieren!

>Wie kann ich mit lcd_moveto_xy(x,y) die x position auf den Pixel genau
>festlegen? Die ist ja jetzt Zeilenweise gemacht will aber an eine ganz
>genaue Position einen Text oder Zahl ausgeben.

Das unterstützt das Display nicht. Der Speicher lässt sich nur 
page-weise ansprechen. Um Text genauer zu platzieren ohne umgebende 
Teile zu überschreiben müsste man im uC einen internen Bildspeicher 
implementieren, aber das braucht natürlich sehr viel RAM.

[Gerhard G. (xmega)]

Hallo,

André R. schrieb:
> Wie kann ich mit lcd_moveto_xy(x,y) die x position auf den Pixel genau
>
> festlegen? Die ist ja jetzt Zeilenweise gemacht will aber an eine ganz
> > genaue Position einen Text oder Zahl ausgeben.

Dann solltest du diese Version nehmen. Siehe Dateianhang!

Gruß Xmega

[André R. (andr_r23)]

Habe mit dem Font Editor neue Zeichen zu der datei symbols_8px 
hinzugefügt. Einmal nur zum testen bei 0x23 (#) ein ausgefülltes 
Rechteck 5x8 Pixel.

Habe danach abgespeichert/exportiert und den ganzen Block an Hexwerten 
in die bestehende Datei kopiert.

Wenn ich jetzt hingehe und folgendes mache:
 lcd_set_font(FONT_SYMBOL_8, NORMAL);
  lcd_moveto_xy(1,0);
  printf("####");

Dann erwarte ich ja eigtl. das dort abgespeicherte Rechteck aber es 
kommt nen verkrüppeltes Zeichen bei raus ?!?. Was habe ich falsch 
gemacht?

[Jochen H. (jth184)]

Hallo zusammen!

Erstmal vielen Dank für die schöne Lib! Ich bin gerade dabei, mein 
DOGM128 in Betrieb zu nehmen und komme nicht weiter.
Ich wollte ein Bild anzeigen und habe versucht, es so zu machen wie Alex 
A. es oben beschrieben hatte:

in headerdatei z.b.: "bitmap.h"

static uint8_t PFEIL_LINKS[] PROGMEM = {
// 2 pages x 8 columns
0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0xAA,
0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xAA
};

aufruf dann mit:

lcd_moveto_xy(0,0);
lcd_draw_image_P(PFEIL_LINKS,2,8,NORMAL);

Beim Kompilieren bringt AVR Studio 4 mir eine Warnung:

../Lib94.c:42:3: warning: pointer targets in passing argument 1 of 
'lcd_draw_image_P' differ in signedness
../dogm-graphic.h:100:8: note: expected 'const prog_char *' but argument 
is of type 'uint8_t *'

Das Display zeigt nichts an. Mit dem Testprogramm von Gerhard G. kann 
ich zumindest Text anzeigen. Das Display selber arbeitet also. Daher 
vermute ich,dass es mit der Warnung zusammenhängt.
Was mache ich falsch?
Ich verwende übrigens einen Atmega 8 mit 16MHz.

Gruß,

Jochen

[Jan M. (mueschel)]

Hallo Jochen,

Jochen H. schrieb:
> in headerdatei z.b.: "bitmap.h"
> static uint8_t PFEIL_LINKS[] PROGMEM = {
> // 2 pages x 8 columns
> 0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0xAA,
> 0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xAA
> };
Variablendefinitionen gehören üblicherweise in .c, nicht in .h Dateien. 
Das ist so kein echter Fehler aber zumindest Konvention.

> Beim Kompilieren bringt AVR Studio 4 mir eine Warnung:
> ../Lib94.c:42:3: warning: pointer targets in passing argument 1 of
> 'lcd_draw_image_P' differ in signedness
> ../dogm-graphic.h:100:8: note: expected 'const prog_char *' but argument
> is of type 'uint8_t *'
Ja, das ist richtig. Wenn du das erste Argument von lcd_draw_image_P von 
PGM_P auf PGM_VOID_P änderst, bist du diese Warnungen los.


> Das Display zeigt nichts an. Mit dem Testprogramm von Gerhard G. kann
> ich zumindest Text anzeigen. Das Display selber arbeitet also. Daher
> vermute ich,dass es mit der Warnung zusammenhängt.
> Was mache ich falsch?

Deine geposteten Zeilen Code funktionieren bei mir ohne Probleme (auch 
wenn "PFEIL_LINKS" nicht der passende Name für das Bild ist).
Hast du schon probiert einfach einen Text mit meiner Library auszugeben?
Die SPI-Routine und Pin-Definitionen sind an deinen µC / dein Board 
angepasst?

[Jan M. (mueschel)]

Hallo André,
ich habe deinen Beitrag wohl übersehen... sorry.
Hast du das Problem inzwischen gelöst?
Wenn nein, funktionieren die anderen Symbole aus deiner neu generierten 
font*.c noch? Wenn nicht, ist wahrscheinlich eine Einstellung im 
Font-Editor falsch. Schau mal nach, ob die Zeichenhöhe noch 8 Pixel ist 
und Kompression abgeschaltet ist.

[Jochen H. (jth184)]

Hallo Jan,

vielen Dank für deine Hilfe!
Habe eben nochmal mein Testprogramm durchgeschaut und den Fehler 
gefunden. Nun wird die Grafik dargestellt.
Habe das PGM_P auf PGM_VOID_P geändert; die eine Warnung ist nun weg, 
dafür kommen zwei andere :-):

../dogm-graphic.c:187:16: warning: dereferencing 'void *' pointer
../dogm-graphic.c:189:13: warning: dereferencing 'void *' pointer

Bekomme ich die auch weg?

[Jan M. (mueschel)]

Kein Problem: Einfach die Array-Schreibweise ("warum hatte ich das 
damals so geschrieben???") in den beiden angekreideten Zeilen ersetzen 
durch normale Pointerarithmetik:

data = pgm_read_byte(progmem_image+j*columns + i) << offset;
data |= pgm_read_byte(progmem_image+(j-1)*columns + i) >> (8-offset);

[André R. (andr_r23)]

Hat jemand ein Schaltungsbeispiel oder ähnliches, damit ich das Display 
auch an 5V betreiben kann?

Habe mit Pegelwandlern noch nicht gearbeitet sollte damit aber gehen 
oder gibt es da eine einfachere Variante?

[Juppo N. (juppo)]

Hallo

Wie Verdrehe ich das Display um 180 GraD
SET SEG direction auf 0xA0
SET COM direction auf 0xC8

geht ,aber die zeichen sind nich t auf x,y 0,0

Da muss noch was bei den Set Column Adresse "+30" gesetzt werden.

Das will nicht klappen.
Ich benutze die LCD-Library von Jan.

hat da jemand ne Idee ?

[Jan M. (mueschel)]

Das kommt auf das Display an, das du benutzt. Wenn es ein DOGM oder -L 
mit 128 Pixel sind, musst du alle column-Adressen um 4 erhöhen.

PS: In der nächsten Version (auf meinem Rechner, bin nur noch nicht dazu 
gekommen sie zu finalisieren & hochzuladen), kannst du die Drehung über 
ein #define einstellen, dann brauchst du dir um die Adressen und 
Registereinstellungen keine Gedanken mehr zu machen.

[Juppo N. (juppo)]

DOG S 102

[Jan M. (mueschel)]

In dem Fall dann wie du schon geschrieben hast die Spaltenadresse um 30 
erhöhen. Das musst du im Augenblick noch von Hand machen, der 
automatische Zeilenumbruch bei längeren Texten geht mit v0.94 auch noch 
nicht.

Ich kann die neue Version heute Abend hochladen, dann kannst du das 
ausprobieren wenn du willst.

[Juppo N. (juppo)]

Ja das wäre nett.

Gruss Juppo

[Markus C. (ljmarkus)]

Hallo,

versuche schon den halben Tag mein 132x32 blau neg. ans laufen 
zubekommen.

Atmega644 int. 8Mhz

Laut Oszi werden auch keine SPI Daten gesendet.
Meine SPI Init schaut so aus:

#define SPI_MOSI   PB5
#define SPI_SCK    PB7
#define  SPI_MISO  PB6

DDRB  = (1 << SPI_MOSI) | (1 << SPI_SCK); 
PORTB &=~(1<<SPI_MISO);

Im Anhang auch mal das ganze Projekt.

Ich hoffe ihr könnt mir helfen.

Danke, Markus

[Markus C. (ljmarkus)]

Sorry,

falsche Anhang. jetzt koriegiert.

#define SPI_MOSI   PB5
#define SPI_SCK    PB7
#define  SPI_MISO  PB6

DDRB  = (1 << SPI_MOSI) | (1 << SPI_SCK); 
PORTB &=~(1<<SPI_MISO);

SPCR = (1 << SPE) | (1 << MSTR) | (0 << SPR1) | (0 << SPR0);   
SPSR = 0;

_delay_ms(2);

lg, markus

[Jan M. (mueschel)]

Hallo Markus,
schau dir mal das Beispiel aus dogm_graphic.h an:

  SPCR = 0 << SPIE | 1 << SPE | 0 << DORD | 1 << MSTR | 1 << CPOL | 1 << CPHA | 0 << SPR1 | 0 << SPR0;
  SPSR = 1 << SPI2X;
  SPDR = LCD_NOP; //Do not use 0 here, only LCD_NOP is allowed!

SPI-Mode ist 3, also müssen CPOL und CPHA gesetzt sein.
Das letzte Schreiben auf SPDR ist notwendig, damit das TX-ready Signal 
initalisiert wird.

[Markus C. (ljmarkus)]

Hallo Jan,

dann bekomme ich dieses:
dogm-graphic.c:61: error: 'LCD_NOP' undeclared (first use in this 
function)

lg, markus

[Jan M. (mueschel)]

Stimmt, da ist das Beispiel nicht mehr up-to-date. Es muss LCD_NO_OP 
heißen.

[Markus C. (ljmarkus)]

Ok.

nun she ich aufm Oszi auch das was geht. Nur leider Streikt das Display, 
ich passiert nix.

[Markus C. (ljmarkus)]

Hallo Jan,

so jetzt geht es..

Nur das Hallo Welt wird so dargestellt:
- fängt rechts an
- Spiegelschrift

lg, markus

[Markus C. (ljmarkus)]

So,

- fängt rechts an
- Spiegelschrift

habe ich rausgefunden.

Nur was ich ned hinbekomme ist ein Bild von 132x32

wenn ich

lcd_moveto_xy(0,0);
lcd_draw_image_P(data_DOG132_bmp,4,132,NORMAL);

dann habe ich in Zeile 2 und 4 nix stehen.

Als Bild verwende ich das DOG132.

lg, markus

[vaid (Gast)]

Jan M. schrieb:
> Hallo,
> hier ist die neuste Version der Library:
> [...]
> - Fehler in symbol_16px und font_proportional_16px korrigiert (Dank an
> Juppo!)

Hi!

Habe ein Problem mit deiner library...
Die von dir eingebundenen Schriftarten funktionieren gut. Wenn ich 
jedoch selbst welche einbaue kriege ich auch das Problem mit den 
Leerzeichen.
Wie hast du das in der obigen Version behoben?
Hab mal die font_proportional_16px.c aus der 0.92 und 0.93 verglichen, 
da wurde im Array aber zu viel geändert als das es nachvollziehbar ist.

Außerdem habe ich so meine Probleme mit dem Fontgenerator. Wie kann ich 
die Höhe der Schriftart anpassen? Da gibt es zwar eine Checkbox "adjust 
font height" aber ich erkenne da keine Auswirkung. Manche Schriftarten 
lassen sich beim Importieren nicht in das Muster n*8 pressen...

Vielen Dank und Gruß

vaid

[vaid (Gast)]

vaid schrieb:
> Außerdem habe ich so meine Probleme mit dem Fontgenerator. Wie kann ich
> die Höhe der Schriftart anpassen? Da gibt es zwar eine Checkbox "adjust
> font height" aber ich erkenne da keine Auswirkung. Manche Schriftarten
> lassen sich beim Importieren nicht in das Muster n*8 pressen...

Das hab ich nun herausgefunden.... größere Zeichen löschen und er passt 
die Höhe an ;-)

[vaid (Gast)]

Sorry dass ich das hier so zuspamme...

Wenn ich nur meine eigene Schriftart einbinde klappt es.
Sobald ich noch eine der voreingestellten Schriftarten nehme z.B. 
FONT_PROP_8
dann macht er aus den Leerzeichen von der selbst erstellten Schriftart 
Pixelmatsche.

[Jan M. (mueschel)]

Hallo vaid,
der unterschied zwischen mit/ohne zusätzlichen zeichensätzen ist 
reinzufällig: Es wird einfach der Inhalt an irgendeiner Stelle im RAM 
angezeigt. Damit Leerzeichen funktionieren muss die Schriftart  das 
Zeichen 0x20 enthalten, sonst kommt der Zeichengenerator durcheinander - 
das muss ich auch bei Gelegenheit mal korigieren.

Gruß, Jan

[Jan M. (mueschel)]

Hallo Markus,
danke für den Hinweis. Wenn das Bild bis an den rechten Rand geht 
pfuscht mir der Zeilenumbruch in die Cursor-Bewegung rein. Probier bitte 
mal folgendes:
Ersetze in lcd_draw_image_P() (dogm_graphic.c) ungefähr Zeile 156:

    if(++j != pages)
      lcd_move_xy(1,-columns);

durch

    if(++j != pages && lcd_get_position_column != 0)
      lcd_move_xy(1,-columns);

[vaid (Gast)]

Jan M. schrieb:
> Hallo vaid,
> der unterschied zwischen mit/ohne zusätzlichen zeichensätzen ist
> reinzufällig: Es wird einfach der Inhalt an irgendeiner Stelle im RAM
> angezeigt. Damit Leerzeichen funktionieren muss die Schriftart  das
> Zeichen 0x20 enthalten, sonst kommt der Zeichengenerator durcheinander -
> das muss ich auch bei Gelegenheit mal korigieren.
>
> Gruß, Jan

Ah, danke für den Hinweis!

Leider steh ich auf dem Schlauch was du mit dem Zeichen 0x20 meinst.
Wie müsste ich die angehängte Datei modifizieren?

[vaid (Gast)]

vaid schrieb:
> Leider steh ich auf dem Schlauch was du mit dem Zeichen 0x20 meinst.
> Wie müsste ich die angehängte Datei modifizieren?

Hilfe zur Selbsthilfe... ;-)

Es ging um das Zeichen 20 oben links im Fonteditor. Wenn man das einbaut 
klappt es.

Gruß und vielen Dank

vaid

[Tobias W. (wintertime)]

Hallo

Ich Habe einen uC ATMEGA644 und ein EA-DOGL 128

Für ein Projekt gebe ich Temperaturwerte aufs Display aus, habe mir die 
Datei von Jan geladen, habe jedoch keine Ahnung wie ich die einbinden 
soll und was ich mit den x.font Dateien machen muss.

Arbeite mit AVR Studio 5

Hätte jemand eventuel ne kleine Anleitung parrat fürs programmieren 
eines Displays?

[Gerhard G. (g_g)]

Hallo,


http://www.basteln-mit-avr.de/

AVR Studio 5 Vers: Atmega 644 SPI

In der dogm.graphic.h ist das Display bereits definiert!

G.G.

[Jochen (Gast)]

Guten Tag,
ich habe die Version dogm-094  runtergeladen.
Ich verwende AVR Studio 5.x und das myAVR Board MK3 PLUS 
(www.myavr.info/download/produkte/myavr_board_mk3/techb_myavr-board-mk3_ 
de_en.pdf)
das Display ist an Port C+A angeschlossen. Ich möchte einen einfach Text 
ausgeben. Mein Code sieht noch relativ leer aus. Könnt ihr mir sagen 
inc. Includes, was zu tun ist um "Hello Word" anzuzeigen?
Bisher (nur)

#include <avr/io.h>

int main(void)
{
    while(1)
    {
        DDRC=0xFF;
 DDRA=0xFF;
           
    }
}}

Schönen Dank,
jo

[Gerhard G. (g_g)]

Hallo,

das wird mit dieser Version nicht funktionieren, das hier arbeitet mit
einem 4-line SPI Interface. Dein Board arbeitet mit dem 6800 
Interfaceals (8 Bit parallel)


Siehe Datenblatt: http://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf

Das Ganze auf parallel umzuschreiben ist sicherlich kein Problem, aber 
du solltes dir mal deine Schaltung anschauen, da befinden sich einige 
Logik-Bausteine am Eingang deines Displays. Also Adressen- und Datenbus 
beachten.


Gruß G.G.

[Anton A. (bingo_)]

Hi zusammen,

Dieser Treiber ist absolut klasse!
Habe mir das Beispiel von http://www.basteln-mit-avr.de Beispiel: 
"Atmega 644 SPI" genommen, angepasst auf meinen Atmega128 und fertig -> 
läuft super, so soll es sein!

Das einzige ist, die Hintergrundbeleuchtung tut bei mir nicht, ich habe 
alles angepasst (bei mir PD7) und die Einstellungen von 1 und 2 
ausprobiert (low-active und high-active), gehen leider beide nicht.
Wenn ich den Port "per Hand" einschalte geht es.

Hat einer eine Idee?

Und DANKE nochmals für den super Treiber, so macht LCD spass.

PS: Ist die Version 0.94 die in dem Bsp. verwendet wird.

[Jan M. (mueschel)]

Hallo Anton,
wenn du die vier defines in dogm_graphic.h richtig gesetzt hast:

  #define LCD_USE_BACKLIGHT   1
...
  #define PORT_LED PORTD
  #define DDR_LED  DDRD
  #define PIN_LED  7

kannst du nach dem lcd_init() die Makros BACKLIGHT_ON() und 
BACKLIGHT_OFF() benutzen. high_active und low_active vertauschen nur die 
beiden Makros. Zusammen passiert da nichts anderes als das, was du von 
Hand machst. Schau doch nochmal die Einstellungen durch, vielleicht hast 
du ja etwas übersehen.

Jan

[Anton A. (bingo_)]

ja passt, hatte das falsch verstanden, dachte das geht irgendwie an wenn 
man Text aus gibt.. aber das geht ja gar nicht wie blöd von mir :(

[Schlaflos (Gast)]

Hallo,

die Library hat noch einen kleinen Fehler, wenn man sich gerade in Page 
0 befindet und sich zurück bewegt. (Tritt bei dogxl 160-7 auf, wenn man 
in den Letzten beiden Pages Text schreiben lassen möchte)

Verhindern kann man das ganze in der Funktion

uint8_t lcd_inc_page(int8_t s)

indem man die Zeile

  p += s;

durch folgende

  p += LCD_RAM_PAGES + s;

ersetzt.

Vielen dank für die tolle Library!

[Stefan F. (stefan1987)]

Hallo,

erstmal vielen Dank für diese super library an Jan M. und  Gerhard G. 
für die Portierung auf Xmega.

Habe sie heute auf meinem Xmega 256 und einem dog XL getestet. 
Funktioniert wirklich sehr gut :)

Ich habe nur eine Frage was die delay routinen in der library betrifft.
Wenn ich zum Beispiel nach dem ausgeben von dem Text ein paar LED's 
blinken lassen will (1 Sekunde an 1 Sekunde aus) ist mir aufgefallen das 
die LED's ca 30 mal so schnell blinken (bei _delay_ms(1000)).Musste den 
Wert von _delay_ms auf 30000 setzen um ca 1 Sekunde zu haben. Habe ich 
mit dem Oszi getestet. Beim Compilieren habe ich bei der optimization Os 
eigestellt wie es in der delay routine gefordert ist.

Hab ich da was übersehen bei der Definition von CPU clock oder so ?
Mein System läuft mit 32 Mhz.

Hoffe Ihr könnt mir helfen, ansonsten nochmals vielen Dank für diese 
tolle library.

Gruß
Stefan

[Gerhard G. (g_g)]

Hallo,

arbeitest du im Debug oder im Release Modus?


Im Toolchain muss dann für beide Modi folgendes eingetragen werden:

Symbols-> F_CPU=32000000UL, oder halt deine F_CPU= "Geschwindigkeit"

#define F_CPU 32000000 braucht dann in deiner Anwendung nicht mehr 
erscheinen.

Ansonsten stimmt das bei mir mit dem Takt haargenau.


Gruß G.G.

[Stefan F. (stefan1987)]

Vielen Dank für die Antwort.
Das war das Problem, ich war im Debug Modus und da war das Symbol gesezt 
im Release aber nicht.

Funktioniert nun einwandtfrei.

Grüße Stefan

[Werner1 (Gast)]

Hallo
Habe das Testprogramm von http://www.basteln-mit-avr.de/atxmega32a4.html
(Projekt: Atxmega32A4 und DOGXL160 I2C/TWI ) und in meinem eigenen 
angelegten Projekt kopiert(Programmcode und die Headerdateien ). Nun 
habe ich mehrere Fehlermeldungen. Ist noch etwas dabei zu beachten, wenn 
ich das Projekt in meinem eigenen einfüge.

[Gerhard G. (g_g)]

Hallo,

was für eine Software verwendest du?

AVR Studio 4 oder 5.

Generell würde ich dir vorschlagen, das lauffähige Programm 
runterzuladen und in ein Verzeichnis auf deinem Lfw zu entpacken. 
Projekt öffnen und testen. Hardware mitinbegriffen!! Sollte alles OK 
sein kannst du Stück für Stück in dein Programm einfließen lassen.


Zwei Projekte mischen ist nicht! Die Grundlagen um ein solches Projekt 
zu starten sollten schon vorhanden sein.

Gruß G.G.

[Gerhard G. (g_g)]

Hallo,


> was für eine Software verwendest du?
> AVR Studio 4 oder 5.

Aus  Kompatibilitätsgründen  habe ich noch eine neue Version
(AVR Studio 6) hochgeladen.

http://www.basteln-mit-avr.de/atxmega32a4.html#dogxl160



Gruß G.G.

[Rik (Gast)]

Hallo,

wie sollte die initialisierung aussehen, wenn man Jan's Library mit 
einem Soft-SPI auf einem Atmega 32 betreibt.

Viele Grüße

[Julius K. (Gast)]

Hallo,

Ich benutze die Version dogm-094  mit ARDUINO und ARDUINO IDE.
Musste einiges ändern.
Meine Frage:
Wie kann ich in der Library (font.cpp - musste Endung ändern) abfragen, 
welcher Font gewählt wurde, "if(font == FONT_FIXED_8)" fuktioniert 
nicht?

  Mfg Julius

[Acer (Gast)]

Hallo zusammen,
ich würde die Library gerne für meinen LPCXpresso 1769 übernehmen.
Leider finde ich garkeine Informationen dazu, was ich in meine SPI 
Funktionen eintragen kann, oder wo ich überhaupt die Ausgabepins für die 
Signale an mein DOGS102 Display deklariere.
Kann mir jemand einen Tip für meine weitere Suche oder eine Hilfe zu 
meinem Problem beitragen?

MfG Henrik

[Gerhard G. (g_g)]

Hallo,

die SPI- und Port-Zuweisungen findest du in der dogm-graphic.c
Leider ist die Umsetzung in Richtung ARM etwas schwierig, da die 
ARM-IDE's
keine pgm_read_byte(..) Anweisungen kennen.

Vielleicht gibt es hier im Forum ein paar Leute, die das schon gemacht 
haben.
Die Hardware, sprich SPI/PORT ist dagegen leicht anzupassen.

Ich verwende darum für meine LPC1769 Anwendung folgende Software:

http://www.basteln-mit-avr.de/LPCXpresso_1769.html

Das Anpassen an das Display DOGS102 ist auch nicht so kompliziert.
Man braucht nur die Init. ändern.

Gruß G.G.

[Jan W. (gaffel-k)]

Erst mal auch von mir ein riesen dankeschön an Jan für die Hammer Lib! 
hat bis jetzt top funktioniert.

Bilder bekomme ich mittlerweile auch dargestellt, nur eine frage hätte 
ich noch zu bildern:

wenn ich ein bild darstellen möchte, das genau so groß wie das display 
ist, also 128*32 pixel, wie viele bytes habe ich dann pro reihe? 
zufällig 16?
oder sind das immer 8 bytes pro reihe.
ich benutze den konverter von laeubi-soft, hab das DOGM128 display.

vielen dank schon mal

Jan

[Jan W. (gaffel-k)]

...außerdem habe ich festgestellt, dass wenn ich zwei 64x64 pixel bilder 
direkt nebeneinander darstellen will, dass das zweite, also das rechte 
bild, nciht richtig dargestellt wird. Es fehlen zeilen und es flackert 
viel.

Kann mir da vielleicht einer helfen?

vielen dank schon mal

Jan

[Jan W. (gaffel-k)]

...ncoh was rausgefunden:

das problem mit den beiden bildern liegt darin, dass das zweite bild bis 
zum rechten rand gezeichnet wird, das gleich Problem dass Markus auch 
hat mit den Zeilen 2,4,... die fehlen.

JanM, Deine Lösung, die Zeile 165 zu ändern hat leider nciht geholfen.

Hättest du noch eine weitere Lösung für uns?

(Sorry für so viele Postings...)

Jan

[Klong (Gast)]

Hallo Jan Wmann,

hier ein kleiner Hinweis:

Das Problem ist, dass DOGXL160-7 2 Bit für Graustufen benötigt
und somit 1 Byte nur 4 Pixel beschreibt, daher 26 pages a 4 Pix = 104

2-Bit Graustufen
00 leer
01 hellgrau
10 mittelgrau
11 schwarz

also für s/w Bitmap 11 reinschreiben.

Code für eine Ganzseiten Bitmap 160X104 - DOGXL160-7:

in mit Jan's Lib 0.94 zu verwenden.



uint8_t dog_4to8[16] = { 0x00, 0x03, 0x0c, 0x0f, 0x30, 0x33, 0x3c, 0x3f, 
0xc0, 0xc3, 0xcc, 0xcf, 0xf0, 0xf3, 0xfc, 0xff };

void draw_fullpic(PGM_P progmem_image)
{
  uint8_t k, p, c;
  uint8_t LcdData[2];  // Pointer auf beide Pages einer Spalte
  uint8_t HI = 0x00;
  uint8_t LO = 0x00;

  for (k = 0; k < 13; k++) // 26 x 4 Pixel => 104 Pixel
  {
  for ( c = 0; c < 160; c++)
  {
    LO = (pgm_read_byte(&progmem_image[160 * k+c ]) & 0x0F); /* 4 LSB -> 
L */
      HI = (pgm_read_byte(&progmem_image[160 * k+c ]) & 0xF0); /* 4 MSB 
-> H */
      HI = (HI >> 4 ); /* schiebe 4 mal rechts */
      LcdData [ 0 ] = dog_4to8[LO];
      LcdData [ 1 ] = dog_4to8[HI];
    for( p = 0; p <2; p++ )
    {
        lcd_moveto_xy((2*k)+p,c);
      lcd_data(LcdData[p]);
    }
  }
  }
}

[Jan W. (gaffel-k)]

Hallo Klong,

vielen dank für deine antwort und den code, nur leider benutze ich das 
DOGM128. man könnte den code ja bestimmt umändern für dieses glcd.

ich bräuchte aber eher einen code, um ein bild von 64x64 pixel ganz nach 
rechts an den rand zu zeichnen.

kann mir da jemand helfen?

Jan

[Gerhard G. (g_g)]

Hallo,


Klong schrieb:
> Code für eine Ganzseiten Bitmap 160X104 - DOGXL160-7:

habe mal deinen Code eingebunden und das Ergebnis als Anhang


Benutzt du auch  den Konverter von Laeubi-soft?

Meine Versuche sind erstmal gescheitert.


Gruß G.G.

[Klong (Gast)]

Hallo G. G.

Nein, ich benutze den Konverter vom GLCD-Hersteller

ELECTRONIC ASSEMBLY GmbH
Zeppelinstr. 19
D-82205 Gilching bei München

http://www.lcd-module.de

Der Bitmap Konverter ist in folgendem Paket enthalten:

http://www.lcd-module.de/fileadmin/downloads/Setup%20LCD-Tools%20Portable%2042.exe

Hinweis: Die ersten beiden Byte enthalten die Abmessung der Grafik.
Diese habe ich in meinem einfachen Beispiel einfach gelöscht.

Man kann diese jedoch auch für kleinere Bitmaps in der Ausgabe
Routine auswerten, was einen Offset von 2 Byte bei der Grafik
nach sich zieht.

Die Ausgabe des Bitmap Konverters ist wie folgt.

------------------------------------------------------------------
/* File 'F:\ELECTRONIC ASSEMBLY LCD-Tools Portable\Data\eDIP -
intelligent graphic displays\BITMAPS\monochrome\ICON.BMP' as include

 the array starts with a 2 byte header:
  1th Byte: Width of image in dots
  2th Byte: Height of image in dots
  After that image data will follow */

#define Image_ICON_BMP_LEN  1026

unsigned char Image_ICON_BMP[Image_ICON_BMP_LEN] =
{
  128, 64,
  255,255,255,255,255,243,243,  3,  3,243,243,255,255, 63, 31,159,
...usw.
------------------------------------------------------------------

dann die Grafik einbinden

#include "ICON_BMP.h"

fertig.

beachte, dass in der Konstanten  Image_ICON_BMP_LEN die Anzahl
der Bytes enthält.

Kann man für Schleifenende in derAusgaberoutine verwenden.

Die beiden werte (hier 128, 64) kann man dann als schleifenvariablen
k und c verwenden.

z.B.:
uint8_t maxK, maxC;

maxK = pgm_read_byte(&progmem_image[0]); // erstes Byte = Spalten
maxC = pgm_read_byte(&progmem_image[1]); // zweites Byte = Zeilen

die Startposition jetzt noch mit zwei Parametern mitgeben, so wie
es Jan's Lib macht.

Werde das heute mal ausarbeiten und mich wieder melden.

Desweiteren empfehle ich folgende Downloads:

http://www.lcd-module.de/deu/pdf/grafik/dogxl160-7.pdf
http://www.lcd-module.de/eng/pdf/zubehoer/uc1610.pdf

[Klong (Gast)]

Das sollte helfen:

#include "ICON_BMP.h"


Aufruf:

draw_partialpic((uint8_t*)Image_ICON_BMP,16,20);

Zeichnet die Bitmap in die Mitte des GLCD.

die ersten beiden Byte der Grafik representieren die Abmessungen.
(Siehe letzten Beitrag)

Eine Falle gibt es noch, falls du den Konverter von ea verwenden willst:

ggf. einfügen von "static" und "PROGMEM" für winavr.

die Längenkonstante brauchst du nicht. (WinAvr Compiler)

static uint8_t Image_ICON_BMP[] PROGMEM =
{
  128, 64,
  255,255,255,255,255,243,243,  3,  3,243,243,255,255, 63, 31,159,
...usw
}


Funktion in dogm_graphic.c einfzuügen:

void draw_partialpic(PGM_P progmem_image, uint8_t xPos, uint8_t yPos)
{
  uint8_t k, p, c, y;
  uint8_t height, width;
  uint8_t LcdData[2];  // Pointer auf beide Pages einer Spalte
  uint8_t HI = 0x00;
  uint8_t LO = 0x00;

  width  = pgm_read_byte(&progmem_image[0]);
  height = (pgm_read_byte(&progmem_image[1])/4); // pages = 4 Dots

  y = yPos/4;

  for (k = 0; k < height/2; k++)
  {
  for ( c = 0; c < width; c++)
  {
    LO = (pgm_read_byte(&progmem_image[width * k+c+2 ]) & 0x0F); // 4 
LSB -> LO
      HI = (pgm_read_byte(&progmem_image[width * k+c+2 ]) & 0xF0); // 4 
MSB -> HI
      HI = (HI >> 4 ); // schiebe 4 mal rechts
      LcdData [ 0 ] = dog_4to8[LO];
      LcdData [ 1 ] = dog_4to8[HI];
    for( p = 0; p <2; p++ )
    {
        lcd_moveto_xy((2*k)+p+y,c+xPos);
      lcd_data(LcdData[p]);
    }
  }
  }
}

Denke daran yPos nur in 4er Schritten anzugeben und nicht über die
Ränder hinaus zu malen! (sonst wird die Bitmap auf der anderen Seite 
weitergezeichnet)

Diese Aufgabe überlasse ich dir ;)

Rückmeldung wäre erwünscht!

[Gerhard G. (g_g)]

Hallo Klong,

Klong schrieb:
> Rückmeldung wäre erwünscht!

es funktioniert alles bestens! Habe die Routine wie vorgesehen zu den 
bestehenden Funktionen in dogm_graphic.c gepackt.



Danke für deinen Beitrag.



Gruß G.G.


Bild *.jpg wurde versehentlich hochgeladen

[Jan W. (gaffel-k)]

Hallo Klong, kann ich deinen code auch bei einem DOGM128 LCD verwenden?

Danke schon mal

Jan

[Klong (Gast)]

Hallo Jan Wmann,

leider habe ich momentan kein DOGM128

hab mir mal das Datenblatt des DOGM128 von EA angesehen.

http://www.lcd-module.de/pdf/grafik/dogm128.pdf
http://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf

Auf Seite 6 rechts unten kann man
entnehmen, dass DOGM128 8 Dots je Byte
beschreibt. Also kannst du dir das zerlegen
eines Bytes in 2 Nibble sparen.
Ansonsten gilt das gleiche wie für G. G.

Ohne Gewähr da ich nicht testen kann, auf die Schnelle etwa so:

void draw_partialpic(PGM_P progmem_image, uint8_t xPos, uint8_t yPos)
{
  uint8_t k, c, y;
  uint8_t height, width;
  uint8_t dta = 0x00;

  width  = pgm_read_byte(&progmem_image[0]);
  height = (pgm_read_byte(&progmem_image[1])/8);

  y = yPos/8;

  for (k = 0; k < height; k++)
  {
    for ( c = 0; c < width; c++)
    {
      dta = pgm_read_byte(&progmem_image[width * k+c+2 ]);
      lcd_moveto_xy(k+y,c+xPos);
      lcd_data(dta);
    }
  }
}
 Gruss Klong

[Jan W. (gaffel-k)]

Hallo Klong,

vielen dank für den Code, aber leider funktioniert er nicht. Er wird 
einfach nichts dargestellt.

Die Bitmap-daten sind ja die selben wie bei Jan M.'s bitmap-codes oder?

Jan

[Gerhard G. (g_g)]

Hallo Jan Wmann,

ich habe mal das Ganze auf ein DOGM128 ausgegeben.

Es funktioniert astrein! Die Grafik ist etwas zu groß, konnte sie aber 
nicht in der Schnelle umkovertieren.

Also der gelieferte Code für das DOGM128 ist richtig.

Kann dir leider den Code nicht zur Verfügung stellen, da ich mit 
Atxmega.. arbeite.

Gruß G.G.

[Walter T. (nicolas)]

Hey, die Piktogramme sind schön! Gibt es die irgendwo als Bitmap? 
Insbesondere Stopschild, Thermometer und Bleistift sind ja allgemein 
verwendbar.

Viele Grüße
Nicolas

[Gerhard G. (g_g)]

Hallo,

Nicolas S. schrieb:

> Hey, die Piktogramme sind schön! Gibt es die irgendwo als Bitmap?
> Insbesondere Stopschild, Thermometer und Bleistift sind ja allgemein
> verwendbar.

http://www.lcd-module.de/fileadmin/downloads/Setup%20LCD-Tools%20Portable%2042.exe

[Klong (Gast)]

Guten Abend G. G.

Die Grafik ist genau so groß wie das DOGM128

also Offset xPos yPos auf 0,0 setzen oder kleinere Grafik verwenden!

Viele Grüsse Klong ;)

[Walter T. (nicolas)]

Danke!

[Gerhard G. (g_g)]

Hallo Jan Wmann,

nochmal ein Bild, hier habe ich etliche klein Bildchen auf dem Display 
verteilt. Es funktioniert hier alles!

Endlich mal eine Grafikanwendung die nachvollziehbar ist.


Gruß G.G.

[Klong (Gast)]

Halo G. G.

Na also, freut mich!

Gruss Klong

[Jan W. (gaffel-k)]

Ich komme im Moment nicht zum testen, mache ich die tage aber mal. Melde 
mich sobald ich was weiß.

Jan

[Jan W. (gaffel-k)]

Also ich bekomme draw_partialpic auf meinem DOGM128 nicht zum laufen, 
hier auch mal mein code, vll findet ja einer einen fehler, ich bin da 
seit zwei tagen dran! Jan M.'s Code funktioniert einwandfrei.

ich hab deinen code Klong, in die dogm-graphic.c eingefügt.

hier meine "bmp.h"

unsigned char const MASKE[] PROGMEM = {
  
  0xFF, 0x01, 0xF9, 0x05, 0x05, 0x05, 0xF9, 0x01,
  0xE1, 0x51, 0x51, 0x61, 0x01, 0xFD, 0x01, 0xFF,
  0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
  .....
  0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
  0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
  0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
  0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
  0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0xFF

};

und im anhang meine .c datei. ich programmiere in AVR-Studio 6.0 mit 
einem Dogm128 GLCD.

Es wäre super wenn sich den code ma jemand angucken könnte, vielen dank 
schon mal.

Jan

[Gerhard G. (g_g)]

Hallo Jan,

Jan Wmann schrieb:

> Es wäre super wenn sich den code ma jemand angucken könnte, vielen dank
> schon mal.

stell mal hier deine bmp.h komplett ein. Ich könnte dann mal die Grafik 
testen.  Solltest du nicht den Code-Generator von EA verwenden, ist 
eigentlich das Problem gelöst! Mit anderer Software funktioniert die 
Funktion nicht. Habe es selbst erlebt.

Eigentlich ist die Klong Routine absolut funktionsfähig! Was spricht 
deine Error List(Warnungen auch anschauen)? Ist da was mit Pointern oder 
anderen Dingen die nicht laufen?


Gruß G.G.

[Jan W. (gaffel-k)]

Hier meine bmp.h.

beim kompilieren geht alles ohne fehler durch. keine warungen die auf 
pointer der bitmap hinweisen.

ich habe die bitmaps mit dem tool von laeubi-soft konvertiert. habe das 
ea-tool aber schon installiert. wie sehen denn deine bitmap-daten aus?

Jan

[Gerhard G. (g_g)]

Hallo Jan,

keine Chance, deine bmp.h funktioniert nicht!

siehst du die ersten zwei Zeichen (25,32) im unteren Code der 
funktioniert?
Die braucht die Funktion für die Länge/Breite. Das wird im EA 
Code-Generator erzeugt. Unten wie geasagt, eine Uhr als Grafik. Teste 
mal das Gebilde.


Jan Wmann schrieb:
> wie sehen denn deine bitmap-daten aus

// Uhr
const uint8_t uhr_bmp[] PROGMEM = {

   25, 32,
   0,128,224,112, 56, 28, 12,  6,  6,  3,  3,  3, 59,  3,  3,  3,
   6,134,204, 28, 56,112,224,128,  0,254,255,  1, 16, 16, 16,  0,
   0,  0,  6, 12, 24, 48, 24, 12,  6,  3,  1,  0, 16, 16, 16,  1,
   255,254,  0,  3, 15, 28, 56,112, 96,192,192,128,128,128,184,128,
   128,128,192,192, 96,112, 56, 28, 15,  3,  0,  0,  0,  0,  0,  0,
   0,  0,  0,  0,  1,  1,  1,  1,  1,  1,  1,  0,  0,  0,  0,  0,
   0,  0,  0,  0
};

So wird es bei mir aufgerufen:

draw_partialpic((char*)uhr_bmp, 0, 25); //DOGM128


Gruß G.G.

[Jan W. (gaffel-k)]

Super danke dir. Bin gerade auf Arbeit angekommen und kannden Code erst 
morgen testen. Aber vielen dank schon mal, bin gespannt :-)

[Jan W. (gaffel-k)]

So noch mal getestet heute, und es funktioniert! vielen dank euch beiden 
für eure hilfe, habt mir echt gut weitergeholfen mich langsam in C 
zurechtzufinden...

aber wo ich schon mal dabei bin fragen zu stellen :-), gibt es ne 
möglichkeit, schriften in der höhe pixelgenau auszurichten? oder geht 
das nur page-weise?

danke noch mal,

Jan

[Klong (Gast)]

Hallo JanWmann,

prinzipiell ja, aber ich wünsche dir viel Spaß beim Bits verschieben 
usw.

Ich meinerseits werde dieses Thema nicht anfassen, da es richtig 
kompliziert wird.

Mein Rat: Finde dich in deinem Fall damit ab, dass du nur 8 Bit-weise in 
y-Richtung arbeiten kannst.

Bin natürlich gespannt, ob das einer macht.

Resultate sind stets willkommen. (an G. G.)

Gruss
Klong

[Jan W. (gaffel-k)]

ja das habe ich mir schon gedacht, aber ok, muss ich mir halt was 
überlegen...aber vielen dank noch mal für deinen code klong und g.g. für 
die hilfe.


Jan

[EGS_TI (Gast)]

Hallo,

ich besitze selber das DOG S 102-6, aber benutze bisher meine eigenen 
Routinen.

In der hier vorgestellten Bibliothek gibt es keine Routine der man einen 
String übergeben kann, welchen sie dann auf dem Display ausgibt.

Wäre nicht auch so eine Funktion sinnvoll, oder ist das zuviel Arbeit?

Wie wird sowas denn von den Profis gehandhabt?

[Gerhard G. (g_g)]

Hallo,

schaust du in die Font.c /Font.h

uint16_t lcd_putstr(char* str)

[EGS_TI (Gast)]

Hi,

danke :D

[EGS_TI (Gast)]

Hat jemand die Library schon für PICs angepasst?

[Daniel Held (Gast)]

Hallo,
ich habe die lib auch probiert, aber leider zeigt mein dogl 128W-6 gar 
nichts an :-(

Als Versorgung nutze ich nur 3,3V und habe die 9x 1uF Kondensatoren, wie 
im Datenblatt beschrieben, angelötet. Am Pin Vout messe ich nur 6,6V DC 
- ist das nicht zu wenig? Laut Datenblatt sollten dort bei der Variante 
mit 2 Spannugsquellen 10,5...13,5V anliegen.
Ich habe doch da bestimmt einen Fehler in der Konfiguration drin - kann 
mir da jemand auf die Sprünge helfen?

Getestet habe ich V0.94 und davon das beigefügte Beispiel 
"atxmega_eadog" auf einen xmega 128a1. Die Einstellungen habe ich alle 
so belassen, mit Ausnahme der Umstellung auf 128 x 64 Pixel in der 
dogm-graphik.h

#define DISPLAY_TYPE  128

//Should chip select (CS) be used?
#define LCD_USE_CHIPSELECT  1

//Use Backlight?  (0: no backlight, 1: backlight (on when pin is high), 2: backlight (on when pin is low))
#define LCD_USE_BACKLIGHT   0

#define PORT_A0  PORTC_OUT
#define DDR_A0   PORTC_DIR
#define PIN_A0   3

//Reset Port
#define PORT_RST PORTC_OUT
#define DDR_RST  PORTC_DIR
#define PIN_RST  2

//Backlight Port
#if LCD_USE_BACKLIGHT != 0
  #define PORT_LED PORTC_OUT
  #define DDR_LED  PORTC_DIR
  #define PIN_LED  1
#endif

//Chip select
#if LCD_USE_CHIPSELECT == 1
  #define PORT_CS  PORTC_OUT
  #define DDR_CS   PORTC_DIR
  #define PIN_CS   4
#endif

Danke schon im Vorraus :-)

[Gerhard G. (g_g)]

Hallo,

die Lib ist 100% lauffähig!

Eigentlich braucht man nur in der dogm-graphik.h
das Display auswählen. Das wird aber nicht das Problem sein.

Vermutlich hast du einen Fehler in der Beschaltung. Die Zuführung zum 
Display ist nicht richtig ausgeführt? Schau dir mal die Sache mit der 
SPI/Pin Konfiguration an. Stimmen die Ports?

// Atxmega128a1                     DOGM128
//-------------------------------------
// LCD_A0      PC2     PIN 38
// LCD_RST     PC3     PIN 39
// LCD_CS      PC4     PIN 40
// MOSI        PC5     PIN 37
// MISO
// SCK         PC7     PIN 36

[Daniel Held (Gast)]

Hallo G.G.,

Der Fehler war in der Verschaltung eines Kondensators.
Jetzt scheint es perfekt zu funktionieren :-)

Danke für die Hilfe und die Super- Lib.

[EGS_TI (Gast)]

Durch was muss ich denn diese "pgm_read_byte" und "pgm_read_word" 
ersetzen, damit das auch auf meinem PIC läuft?

Habe mal versucht es einfach wegzulassen, aber damit bekomme ich nicht 
die gewünschte Anzeige. =(

[EGS_TI (Gast)]

Wenn ich ein 'A' ausgeben möchte erhalte ich das hier.

[Gerhard G. (g_g)]

Hallo,


EGS_TI schrieb:
> Durch was muss ich denn diese "pgm_read_byte" und "pgm_read_word"
> ersetzen, damit das auch auf meinem PIC läuft?
>
> Habe mal versucht es einfach wegzulassen, aber damit bekomme ich nicht
> die gewünschte Anzeige. =(

du musst  bei den Fonts das PROGMEM entfernen

mit:

const uint8_t font_proportional_8px_data[] PROGMEM = {
0x02, 0x01, 0x03, 0x05, 0x05, 0x07, 0x05, 0x01, 0x03....

ohne:
const uint8_t font_proportional_8px_data[] = {
0x02, 0x01, 0x03, 0x05, 0x05, 0x07, 0x05, 0x01, 0x03....


dann pgm_read_byte  und das "&" Zeichen entfernen.


Ob es dann funktioniert ist zweifelhaft, da manche Programmroutinen halt 
auf das PROGMEM-Verfahren abgestützt sind. Das aber auf den ersten Blick 
zu erkennbar, ist für einen Einsteiger schwierig.

[EGS_TI (Gast)]

Danke für deine Antwort. Das hab ich schon alles erkannt und gemacht. 
Schließlich habe ich es ja zum Laufen gebracht. :)
Möchte mich aber eigentlich nicht so sehr mit AVR typischen 
Angelegenheiten herumschlagen.

Vermutlich liegt es an den "pgm_read_word" Makros in den folgenden 
beiden Funktionen aus der "font.c"-Datei:

/******************************************************************************
 * Helper Functions to find, retrieve and display characters
 *****************************************************************************/

/******************************************************************************
 * Loads the pointer to the selected fonts data
 */
inline PGM_P font_data(FONT_P font) {
  PGM_P tmp;
  if (sizeof(tmp) == 2)
    tmp = (PGM_P)pgm_read_word(&(font->data));
  else
    memcpy_P((char*)&tmp,&(font->data),sizeof(tmp));
  return tmp;
  }


/******************************************************************************
 * Loads the pointer to the width table for the selected font
 */
inline PGM_P font_widthtable(FONT_P font) {
  PGM_P tmp;
  if (sizeof(tmp) == 2)
    tmp = (PGM_P)pgm_read_word(&(font->widthtable));
  else
    memcpy_P((char*)&tmp,&(font->widthtable),sizeof(tmp));
  return tmp;
  }

Mein Compiler speichert Variablen automatisch im Flash, wenn diese mit 
"const" deklariert/definiert werden. Auslesen kann man sie dann auch 
wieder ganz normal, als ob sie im RAM stünden.

Ich hab aus den Funktionen einfach mal auf gut Glück folgendes draus 
gemacht:

/******************************************************************************
 * Helper Functions to find, retrieve and display characters
 *****************************************************************************/

/******************************************************************************
 * Loads the pointer to the selected fonts data
 */
inline PGM_P font_data(FONT_P font) {
  PGM_P tmp;
  
    tmp = ((font->data));

  return tmp;
  }


/******************************************************************************
 * Loads the pointer to the width table for the selected font
 */
inline PGM_P font_widthtable(FONT_P font) {
  PGM_P tmp;
  
    tmp = ((font->widthtable));
 

  return tmp;
  }

[EGS_TI (Gast)]

Ich möchte immer noch das 'A' auf Position Page 1 und Column 1 ausgeben 
und es erscheint jetzt diese Anzeige.

Die Nullen und Doppelpunkte werden durch meine eigenen Funkionen 
dargestellt.

[EGS_TI (Gast)]

/******************************************************************************
 * Helper Functions to find, retrieve and display characters
 *****************************************************************************/

/******************************************************************************
 * Loads the pointer to the selected fonts data
 */
inline PGM_P font_data(FONT_P font) {
  PGM_P tmp;
  if (sizeof(tmp) == 2)
    tmp = (PGM_P)pgm_read_word(&(font->data));
  else
    memcpy_P((char*)&tmp,&(font->data),sizeof(tmp));
  return tmp;
  }

Wieso wird hier auf "sizeof(tmp)" verglichen?

 
tmp = (PGM_P)pgm_read_word(&(font->data));

Steht jetzt in tmp eine Adresse drin oder die Daten? oO

Wieso können die Displayhersteller denn nicht einfach ihre eigenen 
plattformunabhängigen Bibliotheken erstellen?? :(

[Jan M. (mueschel)]

Hallo,
>Wieso wird hier auf "sizeof(tmp)" verglichen?
Das ist nur eine Auswahl um den Programmcode zu optimieren. Ist der 
Pointer genau 2 Byte groß, kann pgm_read_word verwendet werden, 
ansonsten muss das deutlich aufwendigere memcpy_P herhalten.
Das gleiche gilt für font_width(), gleich unterhalb im Code.

>Steht jetzt in tmp eine Adresse drin oder die Daten?
Wie der Kommentar über der Funktion sagt: Es ist der Pointer auf die 
Daten. Schau dir auch mal die Definition von struct font_info ganz am 
Ende von font.h an. FONT_P ist nämlich genau ein Pointer auf solch eine 
Struktur.

[EGS_TI (Gast)]

Jap, genau. Danke nochmal für die Bestätigung.

[EGS_TI (Gast)]

/******************************************************************************
 * Helper Functions to find, retrieve and display characters
 *****************************************************************************/

/******************************************************************************
 * Loads the pointer to the selected fonts data
 */
inline PGM_P font_data(FONT_P font) {
  PGM_P tmp;
  
    tmp = ((font->data));

  return tmp;
  }

Dann müsste das ja so stimmen, oder?

[Jan M. (mueschel)]

Ja, wenn PGM_P bei dir ein const char * ist.

[EGS_TI (Gast)]

Jop, ist es. Leider funktionierts dennoch nicht.

[EGS_TI (Gast)]

Falls mal jemand mal Zeit und Lust hat mir zu helfen, hier mal die 
Dateien die ich verwende.

Die Daten werden einfach durch ein "const" im Flash abgelegt.


Meine main:

void main(void)
{


  
  InitSPI();
  InitLCD();
  LCD_clear();

  
  lcd_set_font    (FONT_FIXED_8, NORMAL);
  lcd_put_char_xy      (FONT_FIXED_8, NORMAL, 'B', 3, 32);
  //lcd_put_string       (FONT_FIXED_8, NORMAL, "Hallo Welt");
  

  while (1)
  {
    
    
    
  }



}

[EGS_TI (Gast)]

Sorry, ich verwende ja die "FONT_FIXED_8" Font und nicht die 
PROPORTIONAL.

[Floxx (Gast)]

Hallo,
ich habe mir Jans Lib auch gesaugt und implementiert. Nachdem es 
nirgendwo dokumentiert ist wollte ich fragen, wie denn die Befehlsfolge 
abläuft.
Ich habe eine init_spi_lcd() erstellt, wie es im Beispiel steht 
allerdings frage ich mich, was das

SPDR = LCD_NOP;

 sein soll. Da wirfts bei mir immer einen Fehler.
Durch etwas Suchen bin ich dann draufgekommen, dass

#define LCD_NOP()                     lcd_command(LCD_NO_OP)

allerdings, wenn ich es in meiner SPI Init ausbessere, die übrigens so 
aussieht:

void init_spi_lcd() {
  SPCR = 1 << SPE | 1 << MSTR | 1 << CPOL | 1 << CPHA;
  SPDR = LCD_NOP(); //Do not use 0 here, only LCD_NOP is allowed!
}

 kommt folgender error: "void value not ignored as it ought to be"

Kann jemand bitte die minimale Befehlsfolge posten, sodass mit dieser 
Lib überhaupt irgendwas einmal am DOGM dargestellt wird?

Danke.

[Gerhard G. (g_g)]

Hallo,

eine Beschreibung im weitersten Sinne gibt es nicht.

Zuerst zu deinem Problem:

Floxx schrieb:
> LCD_NOP;

Du musst in die dogm-graphic.h schauen!

#define LCD_NOP()                     lcd_command(LCD_NO_OP)

#if DISPLAY_TYPE == 128 || DISPLAY_TYPE == 132 || DISPLAY_TYPE == 102
#define LCD_NO_OP          0xE3  //22: NOP command


Der Fehler entsteht dadurch, dass dieser Befehl nur bei einem DOGM128 
gültig ist. Du musst in der dogm-graphic.h das Display definieren.
#define DISPLAY_TYPE  128


Verwendest du ein anderes Display, so führt der Befehl unweigerlich zu 
einem Fehler.


SPDR = LCD_NOP;

kannst du getrost weglassen, der Befehl bewirkt sowie so nichts.

[Floxx (Gast)]

Hallo G. G.!
Danke, aber das habe ich bereits alles schon durchprobiert. Ich habe 
auch SPDR = 0xE3 gesendet, sowie alle nötigen Einstellungen gemacht, 
jedoch bleibt der Bildschirm schwarz.
Ich werde mich am Dienstag nochmals dahinter klemmen.

Danke so far!

[Jan M. (mueschel)]

Hallo,
Das schreiben in SPDR bewirkt zwar nichts am Display, aber es setzt das 
TX-ready Bit, ohne das die Routine, die die Daten ans Display sendet, 
nicht arbeiten kann.
Es müsste reichen LCD_NOP durch LCD_NO_OP bzw. Den entsprechenden 
no-operation Befehl für das Display zu ersetzen.

[Gerhard G. (g_g)]

Hallo Jan,

Jan M. schrieb:
> Das schreiben in SPDR bewirkt zwar nichts am Display, aber es setzt das
> TX-ready Bit, ohne das die Routine, die die Daten ans Display sendet,

da hast du schon recht, aber SPDR = 0 hat sich bei meinen SPI-Routinen 
stets bewährt.

[Dirk (Gast)]

Jan M. schrieb:
> Ach klar, jetzt sehe ich es auf dem Foto. Du benutzt das Display ja im
> Top-View Modus. Dort gehen die Adressen von 4 bis 131 (siehe Datenblatt
> Seite 7 oben links). Das berücksichtigt meine Library im Augenblick
> nicht.
>
> Ich versuche das in der nächsten Version einzubauen, kann dir aber nicht
> sagen, wann es soweit ist. Bis dahin musst du dir leider einen
> Work-Around basteln. Sorry!

Hallo,

erstmal Kompliment für die Lib - somit konnte ich schon mal schnell ein 
paar Zeichen auf's Display zaubern.

Aber nun noch ein paar Anmerkungen:
Zitat siehe oben: ich arbeite mit V.94 - da ist der Offset von 4 Pixeln 
noch nich implementiert - gibt es bereits eine neuere Version?

Bei Schriftart: FONT_FIXED_8 bekomme ich die Fehlermeldung "FONT_FIXED_8 
undeclared..."

eine kleine main.c mit der Inititalisierung als "ready-to-use"-Lib würde 
den Einstieg vereinfachen und sicher einige Fragen überflüssig machen.

Wie hier schon erwähnt wurde, wären Funktionen um Linien oder sogar 
Kreise zu zeichnen ganz nett. Gibt es da etwas kompatibles?

Gruß Dirk

[Daniel Held (Gast)]

Hallo,
die lib funktioniert wirklich super, jetzt habe ich nur ein Problem bei 
der Nutzung des Displays im 12 o'clock mode bei "lcd_clear_area".
Den Offset in den für die Columns ist korrekt, nur beim löschen bleiben 
die letzten columns stehen.
Gibt es dafür Abhilfe?

Danke schonmal.

[Daniel Held (Gast)]

Hatte noch Keiner dieses Problem?

[Gerhard G. (g_g)]

Hallo,


Daniel Held schrieb:
> Hatte noch Keiner dieses Problem?


Schlaflos schrieb:
> die Library hat noch einen kleinen Fehler, wenn man sich gerade in Page0
> befindet und sich zurück bewegt. (Tritt bei dogxl 160-7 auf, wenn man
> in den Letzten beiden Pages Text schreiben lassen möchte)


hat das was mit dem zu tun?

Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator"




Gruß G.G.

[Daniel Held (Gast)]

Hallo G. G.,
das war leider nicht das Problem :-(
Es hängt vermutlich mit dem Offset bei der 12Uhr Darstellung zusammen...

Wenn einer noch Ideen hat, immer her damit :-)

[Jan M. (mueschel)]

>bei der Nutzung des Displays im 12 o'clock mode bei "lcd_clear_area".
>Den Offset in den für die Columns ist korrekt, nur beim löschen bleiben
>die letzten columns stehen.

Hallo Daniel,
um welches Display geht es denn? Hast du den Offset "von Hand" 
eingefügt?
Ich habe hier auch noch eine neue Lib, die das automatisch macht, muss 
sie nur noch fertig testen.

[Daniel Held (Gast)]

Hallo Jan,

ich nutze ein DOGM128-6 und ich habe den Offset als Displayparameter in 
der dogm-graphic.h eingefügt.

#if DISPLAY_TYPE == 128
  #define LCD_WIDTH          128 //width of the LCD
  #define LCD_HEIGHT         64  //height of the LCD
  #define LCD_RAM_PAGES      8   //size of LCD RAM
  #define LCD_PIXEL_PER_BYTE 8   //using single pixels
  #define LCD_COL_OFFSET   4   //Offset of columns if 12 o;clock mode is used  
#endif

[Jan M. (mueschel)]

Dann musst du uns aber noch verraten, wie du das LCD_COL_OFFSET im 
restlichen Code eingebaut hast.

[Daniel Held (Gast)]

Das habe ich vorerst nur "händisch" eingebaut, z.B.: so

lcd_moveto_xy(0,LCD_COL_OFFSET + 0);

Im Moment will ich das in Deine Funktionen integrieren, aber scheitere 
schon beim Löschen des Displays :-(

Ich denke beim Line Wrap sollte das so funktionieren?

#if LCD_WRAP_AROUND == 1
 // while (c >= LCD_WIDTH) {
    while (c >= (LCD_COL_OFFSET + LCD_WIDTH)) {
    if (s > 0) lcd_inc_page(1);
    else       lcd_inc_page(-1);
    if (s > 0) c -= LCD_WIDTH;
    else       c += LCD_WIDTH;
    }
...

[Jan M. (mueschel)]

lcd_clear_area fragt die Breite des Displays aber auch noch einmal ab, 
die draw-Funktionen ebenso.

[Daniel Held (Gast)]

Ich weiß, aber soweit war ich noch nicht vorgedrungen :-)
Bei Clear_Area hatte ich es mir so gedacht:

 if(columns > (max = (LCD_COL_OFFSET + LCD_WIDTH) - lcd_get_position_column()))

Das funktioniert auch beim löschen einzelner pages, aber nicht bei 
mehreren...

[Jan M. (mueschel)]

Hier ist die neuste Version der Library. Die einzige wesentliche 
Änderung ist die Unterstützung des topview-Modus (siehe Definition in 
dogm-graphic.h Zeile 18) inklusive automatischer Berücksichtigung der 
verschobenen Column-Adressen. Ich konnte diese Änderung nicht selbst 
testen mangels Displays, habe aber gehört, dass sie funktioniert.

[Daniel Held (Gast)]

Hallo Jan,
ich habe die neue Version auf einem DOGM128-6 getestet und was soll ich 
sagen - es ist perfekt.

Super Lib und vielen Dank für die Hilfe hier.

VG Daniel

[EGS_TI (Gast)]

Hats mittlerweile vielleicht jemand auf die PIC16F portiert? :)

[Florian (Gast)]

Hallo,

ich nutze zur Zeit das DOG-M 3x16 Textdisplay und wollte jetzt auf ein 
Grafikdisplay umsteigen, da ich gerne auch später Grafiken/Logos 
darstellen möchte.

Beim Textdisplay gebe ich ja Text im Arduino so aus:

....
lcd.setCursor(0, 0);
lcd.print("Text:");
....
....

wie sieht das bei einem Grafikdisplay wie dem EA DOGS102N-6 aus. Hat da 
jemand einen kurzen Beispielcode?


VG
Florian

[EGS_TI (Gast)]

Na mit Hilfe dieser Library siehts da ähnlich aus.

[EGS_TI (Gast)]

Hi, ich nochmal...

Habe mir mal den Programmspeicher in der IDE angeguckt siehe mein Bild.

Könnte es sein, dass der RETLW Befehl dort irgendwelche Probleme macht?


Vielen Dank für Eure Hilfe!!

[Jan M. (mueschel)]

Hallo EGS_TI,
das ist kein Problem, das sind ja einfach nur Daten und kein 
Programmcode der jemals augeführt wird. Dass der Disassembler dort meint 
einen Befehl zu erkennen liegt nur daran, dass er keine Möglichkeit hat, 
Code und Daten zu unterscheiden.

[EGS_TI (Gast)]

Ja, is ja klar, dass das nicht ausgeführt wird, aber ich schreibe doch 
eigentlich an die jeweilige Adresse nur das was im Font-Array drin 
steht. Und da steht doch nicht überall eine 34 davor.

Ohjeee, der Programmspeicher des PIC ist 14 Bit breit.. Das könnte 
eventuell das Problem sein. :(

[EGS_TI (Gast)]

Hallo liebe Freunde,

ich komme mit der Library einfach nicht weiter. Irgendetwas scheint 
nicht zu stimmen (ach nee...).

Hat vielleicht jemand einen Tipp für mich, wie ich das ganze etwas 
systematischer angehen kann?

Diese scheiß Microchip IDEs kann man ja auch alle getrost in der Pfeiffe 
rauchen. Der Kacksimulator tut auch nicht was er soll und... ach zum 
Verzweifeln...

Gute Nacht

[EGS_TI (Gast)]

Hallo LCD Freunde,

endlich habe ich es geschafft, dass Display mit dieser Library etwas 
sinnvolles anzeigen zu lassen.

Als ich vorhin begann das hier zu schreiben, hat das Display nur einen 
einzigen Buchstaben eines Strings angezeigt. Und zwar immer nur den 
letzten.
Ich vermutete, dass irgendetwas in der "lcd_put_char"-Routine nicht 
stimmte. Bevor ich hier also irgendwelche oberflächlichen Vermutungen 
anstellen wollte und ich nicht wusste wo ich ansetzen sollte habe ich 
mein Projekt nochmal geöffnet und mit den original Library Daten 
verglichen.

Dabei ist mir dann aufgefallen, dass ich in meiner eigenen 
lcd_data-Routine das "lcd_inc_column(1);" am Ende vergessen hatte.
Siehe original Routine:

void lcd_data(uint8_t data) {
  LCD_SELECT();
  LCD_DRAM();
  spi_write(data);
  LCD_UNSELECT();

  lcd_inc_column(1);
  }

Nachdem ich meine Routine ergänzte zeigte mein Display nun alle bis auf 
das Erste Zeichen an. Die Position an dem das erste Zeichen erscheinen 
müsste ist "weiß".

Hat vielleicht jemand eine Idee woran das liegen kann?

[EGS_TI (Gast)]

Soo,

mit einem "LCD_MOVE(0,0)" vor der Stringausgabe funktioniert es. :))

[Jens (Gast)]

Moin zusammen, ich habe gestern für ein neues Projekt ein Dog128-L an 
einen XMega128A3 angebunden. War durch die Lib total einfach. Danke für 
die tolle Arbeit. Mir ist dabei aber aufgefallen, dass das Löschen des 
ganzen Displays (was ja auch in der lcd-init() mit durchlaufen wird) 
nicht sauber funktioniert. Es wird nur die erste der acht Pages des 
Displays gelöscht. Bemerkt hab ich das, weil das Display aufgrund meiner 
falschen Power_Control Einstellung kurzfristig nur Müll angezeigt hat 
und dieser nur in den ersten acht Zeilen (1. Page) gelöscht wurde. Das 
Problem steckt m.E. hier:

lcd_move_xy((lcd_get_position_column()?1:0),-columns);

Ich denke hier soll abgefangen werden, dass nach einem Wraparound 
(Column==0) schon automatisch auf die nächste Page hochgezählt wurde. 
Der Columns-Wert wird durch diesen Aufruf dann aber negativ und daher 
automatisch die Page wieder zurückgezählt. Daher bleibt der Löschbereich 
immer in der ersten Page, wenn die letze Column das Ende des angegebenen 
Löschbereichs ist

Könnt ihr das Problem nachvollziehen?

Viele Grüße aus Hamburg

[Jan M. (mueschel)]

Hallo Jens,
wenn ich mir diese Zeile gerade anschauen weiß ich gar nicht mehr, warum 
diese Abfrage da drin ist - ich komme gerade auf keinen Fall wo "0" 
richtig wäre, aber vielleicht übersehe ich auch nur etwas. Irgendeinen 
Grund muss es gehabt haben.
Im Augenblick würde ich sagen: Schmeiß die Abfrage raus und schreibe fix 
eine 1 hin.

[Jens (Gast)]

Moin Jan, danke für die superschnelle Antwort nach ein paar Minuten. So 
schnell hatte ich gar nicht damit gerechnet. Habs schon genauso gemacht. 
In älteren Versionen deiner Lib steht auch nur die 1 drin.
Thx, Jens

[Daniel Held (Gast)]

Hallo,
ich hatte die lib an einen xmega 128A3 angebunden und was soll ich sagen 
- funktioniert super.
Jetzt habe ich nur ein Problem mit den Umlauten, mit lcd_putstr() wird 
mir bei den Umlauten nur Mist angezeigt. Komischerweise ist das aber 
erst seitdem ich auf das AS6 umgestellt habe, auch mit lcd_putc(252) "ü" 
funktioniert das nicht.
Hat da einer eine Idee? Vielleicht wurde nur ein Header der toolchain 
nicht richtig eingebunden?

Danke schon mal.

[Jan M. (mueschel)]

Hallo Daniel,
'ü' ist in ASCII character 129, nicht 252 - das wäre die 
Microsoft-Variante iso-1252.

[Daniel Held (Gast)]

Hallo Jan,
danke für die Info, aber das Ergebnis ist das gleiche :-(
Selbst wenn ich z.B. lcd_putstr("Übung") benutze, bekomme ich "Mist" 
gefolgt von "bung" angezeigt.
Hast Du noch eine Idee?

[Daniel Held (Gast)]

ich habe mir die Sache nochmal im Debugger angeschaut:
Aufruf:
lcd_putc(129);

in der Funktion:
uint8_t  lcd_putc(char c) {
  return lcd_put_char(global_font_select, global_font_style, c);
  }
hat "c" einen Wert von -127

Ich bin ratlos...

[Jan M. (mueschel)]

-127 (signed) ist ja 129 (unsigned), soweit stimmt das. Ich arbeite 
üblicherweise mit unsigned char, und du (zumindest im Debugger) mit 
signed char als Standard. Stell deinen Compiler mal auf unsigned um - es 
kann gut sein, dass irgendeine Rechnung schiefläuft wenn mit Vorzeichen 
gerechnet wird. Zum Umstellen gibt's irgendwo einen Button bzw. die 
compiler Option -funsigned_char.

[Daniel Held (Gast)]

Hallo Jan,
danke für den Tipp :-)
Ich hatte bisher auch alle Projekte mit unsigned als Standard, das war 
hier leider nicht so.
Jetzt läuft es auf jeden Fall - Super Support kann ich da nur sagen.

Noch eine Frage hätte ich aber:
Ist es möglich einzelne Zeichen des Font umzugestalten, z.B. in Symbole? 
Das geht doch bestimmt nicht mit dem Fontcreator, oder?

[Daniel Held (Gast)]

Das scheint doch mit dem Creator zu funktionieren.
Also, ich danke Dir noch einmal.

[Jan M. (mueschel)]

Daniel Held schrieb:
> Ist es möglich einzelne Zeichen des Font umzugestalten, z.B. in Symbole?
> Das geht doch bestimmt nicht mit dem Fontcreator, oder?
Doch, das ist kein (großes) Problem. Die *.font kannst du im Fontcreator 
öffnen und beliebig editieren. Du musst nur darauf achten, dass sich die 
Höhe nicht ändert und unkomprimiert gespeichert wird. Vorher noch die 
.ini anpassen und das template aus dem Archiv eintragen damit das Format 
beim exportieren stimmt.
Ich würde aber empfehlen, einen der schon existierenden Symbol-Fonts zu 
erweitern oder einen neuen zu erstellen. Und wenn du fertig bist darfst 
du das Ergebnis natürlich auch gerne hier hochladen :-)

[Daniel Held (Gast)]

OK, gute Idee.
Als Template meinst Du die "template_simplefont.c" nehme ich an.
Muss ich damit in der *.ini die "template.c" unter export_unused 
ersetzen?

[Jan M. (mueschel)]

Hier einfach ersetzen:

[export]
0=template.h

durch

[export]
0=template_simplefont.c

[Daniel Held (Gast)]

Danke.

[Daniel Held (Gast)]

Hier, wie versprochen, die symbols8px mit noch einigen eingefügten 
Symbolen für Anzeige des Batteriestandes und Ladung.

[Jan M. (mueschel)]

Danke! Kannst du noch die .font hochladen, damit man die Symbole weiter 
editieren kann? Und darf ich sie in meinen Quellcode hinzufügen und mit 
der nächsten Version hochladen?

[Daniel Held (Gast)]

Sicher.
Anbei beide Dateien gezippt.

[Rolf D. (rolfdegen)]

Hallo zusammen

Eigentlich will ich hier im Trade nicht über die Entwicklung an meinem 
AVR-Synthesizer schreiben. Das kann man ausführlich im CC2-Forum tun 
wenn man Lust verspürt und Interesse an Musikelektronik hat :).

Link zu meinem Synthesizer-Projekt im CC2-Forum: 
http://www.cczwei-forum.de/cc2/thread.php?postid=81924#post81924

Aber weshalb ich hier poste ist die Tatsache, das ich für die 
Menüsteuerung in meinem Synthesizer ein DOGXL160W-7 Display verwende und 
einen Teil der EADOGM-Library 0.94 hier aus dem Forum. Besten Dank an 
die Entwickler :=)

Ich habe davor ein anderes Grafik Display eDIP160W-7 verwendet, das ich 
wegen der schlechten Performance gegen ein neues Display vom Typ 
DOGXL160W-7 ausgewechselt habe. Den Neukauf hätte ich mir allerdings 
sparen können. Denn bei genauer Betrachtung des alten Displays (siehe 
Bild 1) ist mir aufgefallen, das im Inneren das gleiche Display 
verwendet wird, nur mit einer Platine davor, auf der ein ATMega128 mit 
12MHz für die Displayansteuerung sitzt. Da ich das neue Display direkt 
über die SPI-Schnittstelle meines Xmega-Controller mit 8MHz ansteuern 
kann, ist die Darstellung von Text und Grafik wesentlich schneller als 
beim alten Display.

Im Vergleich zum alten eDIP160W-7 Display (weises LED-Backlight), ist 
die Ansteuerung des neuen Displays (günes LED-Backlight) etwas 
aufwendiger. Aber das ganze ist kein Hexenwerk und im Internet gibts 
eine Menge freie AVR-Library's für die DOG-Displays. Mein nächster 
Schritt ist jetzt die Implementierung von einfachen Grafikfunktionen um 
Wellenformen und Linien dazustellen. Mal schaun wie ich das wieder 
hinbekomme.

Im Anhang ein paar Pics vom alten und neuen Display. Zusätzlich eine 
Plot-Funktion die einen Punkt setzt (nur für DOGXL160 geeignet). Die 
Routine ist noch nicht optimiert. Reicht aber aus um eine Wellenform aus 
dem Programmspeicher dazustellen.

Gruß Rolf

Anhang: Plot-Funktion
---------------------

//-------------------------------------------------------------------------
// draw point to screen
//
void LCD_Set_Point(uint8_t x, uint8_t y)
{
  // X-Position setzen
  xpos = x;
  y = 103 -y;
  
  // Pixelposition im Byte berechnen
  uint8_t byte_pos;
  byte_pos = (y/8)*2;
  ypos = byte_pos;
  
  // Datenbyte für Punkt
  uint8_t disp_data;
  disp_data = 0x00000001;
  
  // Punktposition im Datenbyte berechnen
  uint8_t pix_pos;
  pix_pos = y % 8;
  disp_data = disp_data << pix_pos;
  
  
  // disp_data in 2 Byte zerlegen
  uint16_t disp_data1 = 0;
  for (uint8_t j=0; j<=8; j++)
  {
    uint16_t bit1 = disp_data & (1<<j);
    disp_data1 += (bit1 << j);
  }
  uint16_t disp_data2 = (disp_data1<<1);
  disp_data1 += disp_data2;
  uint8_t disp_data_h = (disp_data1>>8);
  uint8_t disp_data_l = (disp_data1&0b11111111);
  
  // High und Low Byte ans Display senden
  lcd_moveto_xy(ypos,xpos);
  lcd_data(disp_data_l);
  lcd_moveto_xy(++ypos,xpos);
  lcd_data(disp_data_h);
}

[Rolf D. (rolfdegen)]

Hallo..

Hab gerade noch von einem guten Freund aus dem CC2-Forum einen Link 
bezüglich Grafikfunktionen für ein Display bekommen. Möchte ich euch 
nicht vorenthalten. Werde es die Tage mal versuchen auf meinem Display 
umzusetzen.

Link Bresenham-Algorithmus: 
http://de.wikipedia.org/wiki/Bresenham-Algorithmus

Gruß Rolf

[Mathias (Gast)]

Hallo,

ich habe ein Problem mit der Display Orientation. 1 zeigt Blickwinkel 12 
Uhr, soweit alles OK. Setzte ich ORIENTATION_UPSIDEDOWN 0 wird alles 
gespiegelt angezeigt. Woran kann das liegen?

Library v0.95
Display: EA-DOGL128

Vielen Dank für Eure Hilfe!

[Rolf D. (rolfdegen)]

*) Bitte beachten Sie, dass für die 6:00 Darstellung ADC auf „reverse“ 
gesetzt werden muss (gespiegeltes Layout) !

(bottom view 6:00)
ADC set = $A1
Common output mode select = $C0

(Top View 12:00)
ADC set = $A0
Common output mode select = $C8

Gruß Rolf

[Jan M. (mueschel)]

Hallo Mathias,
das kann ich dir nicht erklären - wie du in der init-Routine siehst, 
werden zwei Register leicht anders beschrieben (spiegeln in x-Richtung 
und spiegeln in y-Richtung werden getrennt gesetzt und ergeben zusammen 
die 180°-Drehung). Spiel doch mal mit diesen Befehlen beim init etwas 
herum, vielleicht erkennst du ein Muster und findest so heraus, was 
genau schiefläuft.



Hallo Rolf,
einige Vektorgrafik-Routinen für Linien, Kreise und so weiter sind 
einfach zu programmieren - der Grund warum sie in meiner Library fehlen 
ist nicht der Aufwand, sondern der Umstand, dass man bei den 
DOG-Displays nur ganze Bytes schreiben aber nicht wieder lesen kann. So 
lassen sich immer nur 8 Pixel gleichzeitig setzen und kann keine Objekte 
übereinander / direkt nebeneinander zeichnen. Man bräuchte dafür einen 
eigenen Video-RAM im Controller, aber damit sind die meisten kleinen 
Atmega ja überfordert - Deswegen gibt's bei mir keine Grafikfunktionen, 
aber ich freue mich, dass das mit deinem Display so schön funktioniert.

[Rolf D. (rolfdegen)]

Hallo Jan,

Bei der Programmierung der Grafik-Routinen für das DOGXL160W-7 Display 
tue ich mich etwas schwer.Ich benötige eigentlich nur eine Punkt- und 
Linien-Funktion. Ich habe es jetzt irgendwie hinbekommen, einfache 
Linien mit dem Bresenham-Algorithmus zu zeichnen. Aber das ganze läuft 
noch nicht so rund. Beim zeichenen treten noch Pixel-Fehler auf. Ich 
benutze für das setzen der einzelnen Punkte ein 160*13 Byte großen 
Speicherbereich im Xmega128A1. Da ich für die Wellenform-Darstellung von 
links nach rechts zeichne, müsste es möglich sein, den Speicherbedarf 
auf maximal 13+1 Byte zu reduzieren. Die Idee: Wird für einen Pixel eine 
neue X-Position berechnet, lösche ich die 13 Bytes für die alten 
Y-Positionen (104 Zeilen/8),speicher den neuen Y-Wert in das 1.Byte und 
übertrage es zum Display. So spare ich Zeit und komme ohne großen 
Speicherbedarf aus. Soweit die Theorie.. Mal schaun obs klappt :=).

Gruß Rolf

[Rolf D. (rolfdegen)]

Nachtrag: Hier zwei Funktionen fürs zeichnen einer Linie mit 
implementierter Bresenham-Algorithmus. Nur fürs DOGXL160W-7 geeignet.

Diese Funktion verwendet für die Pixel-Darstellung auf dem DOGXL160W-7 
einen 2080 Byte großen Speicherbereich im XMega. Wie im letzten Beitrag 
schon erwähnt, versuche den Speicherbedarf noch zu reduzieren.

//-------------------------------------------------------------------------
// draw a point
//
void LCD_Plot_Point(uint8_t x, uint8_t y,uint8_t y_dots)
{
  // set Beginn X-Position (Display-Top)
  xpos = x;
  ypos = (y/8)*2;
  uint8_t disp_data = y_dots;
  
  // make 2 Bytes from disp_data
  uint16_t disp_data1 = 0;
  for (uint8_t j=0; j<=8; j++)
  {
    uint16_t bit1 = disp_data & (1<<j);
    disp_data1 += (bit1 << j);
  }
  uint16_t disp_data2 = (disp_data1<<1);
  disp_data1 += disp_data2;
  uint8_t disp_data_h = (disp_data1>>8);
  uint8_t disp_data_l = (disp_data1&0b11111111);
  
  // High und Low Byte ans Display senden
  lcd_moveto_xy(ypos,xpos);
  lcd_data(disp_data_l);
  lcd_moveto_xy(++ypos,xpos);
  lcd_data(disp_data_h);
}

//-------------------------------------------------------------------------
// Draw a line (Bresenham-Algorithmus)
//
void LCD_Plot_Line(int x0, int y0, int x1, int y1)
{
  int dx =  abs(x1-x0), sx = x0<x1 ? 1 : -1;
  int dy = -abs(y1-y0), sy = y0<y1 ? 1 : -1;
  int err = dx+dy, e2; // error value e_xy
    
  // clr grafic buffer
  for (uint16_t i = 0; i < 2080;i++)
  {
    lcd_buffer[i]= 0;
  }
  
    for(;;){  // loop 
    
    // Bitposition im Datenbyte berechnen
    uint8_t pix_pos;
    uint8_t data=0b00000001;
    pix_pos = y0 % 8;
    data = data << pix_pos;
    
    uint8_t y_dots;
    uint16_t buf_adr;
    
    // Grafic Buffer-Adresse berechnen
    buf_adr=((x0+1)*((y0/8)+1));
    
    // alte Y-Dots lesen
    y_dots=lcd_buffer[buf_adr];
    
    // alte und neue Y-Dot verknüpfen und speichern
    y_dots = y_dots | data;
    lcd_buffer[buf_adr]=y_dots;
    
    // Punkt zeichen        
    LCD_Plot_Point(x0,y0,y_dots);
    
    // Abbruch wenn Linienende erreicht
    if (x0==x1 && y0==y1) break;
    
    // Berechnungen     
    e2 = 2*err;
    if (e2 > dy) { err += dy; x0 += sx; } // e_xy+e_x > 0 
    if (e2 < dx) { err += dx; y0 += sy; } // e_xy+e_y < 0 
  }

}

Gruß Rolf

[Rolf D. (rolfdegen)]

Hallo

Hier noch ein paar Pics. Gut zu erkennen die Pixel-Fehler. Im Anhang die 
kompletten C-Funktionen fürs zeichnen einer Wellenform auf dem 
DOGXL160W-7.

Gruß Rolf

[Rolf D. (rolfdegen)]

Hallo

Der Fehler in der Pixeldarstellung habe ich zwar noch nicht gefunden, 
aber ich konnte die C-Funktion fürs Zeichnen einer Linie jetzt so 
abändern, das sie nur noch 13 Byte im Ram benötigt (siehe Anhang).

Gruß Rolf

[Rolf D. (rolfdegen)]

Hallo zusammen..

Ich habe den Fehler gefunden. Die Pixelfehler wurden durch die 
Zeichenrichtung von Unten nach Oben verursacht wenn x1 > x2 war.

Jetzt habe ich eine if-Abfrage implementiert, die die Zeichenrichtung in 
Y-Richtung ändert, wenn x1 > x2 ist.

Funktion zum zeichnen einer Wellenform auf dem Display.

wave_adr = wave_index *256;
    for (uint8_t i = 0; i < 128; i++)
    {
        yplot = pgm_read_byte (&(avrx_bank00[wave_adr]));
        yplot = 255-yplot;
        yplot = (yplot/6)+22;
        x1=i+15;y1=yplot;
        if (x1 < x2)                            // if x1 < X2 draw from up to down
        {
             LCD_Plot_Line(x1,y1,x2,y2);        
        }
        else LCD_Plot_Line(x2,y2,x1,y1);        // else draw form down to up
        
        // next sample_adr.
        xplot++;
        wave_adr = wave_adr + adr_offset;
        x2=x1;y2=y1;
    }

Die Buffergröße für die Zeichenfunktion konnte ich stark reduzieren. 
Jetzt werden für das zeichnen einer Wellenform nur noch 13 Bytes im Ram 
benötigt. Darin werden die Y-Pixel für einen Samplewert gespeichert und 
wieder gelöscht, wenn x1 um eins erhöht wird. Die kompletten Routinen im 
Anhang.

Gruß Rolf

[Rolf D. (rolfdegen)]

Kleiner Fehler im Beitragstext. Muss heißen:  wenn x1 < x2

Gruß Rolf

[Rolf D. (rolfdegen)]

Hallo.. ich schon wieder :)

Wer gerne mit der 2080 Byte großen Buffer-Version für das Zeichenen von 
Linien und Punkten arbeiten möchte, Vorteil Objekte können direkt neben- 
und überanander gezeichnet werden, für den habe ich im Anhang die 
gleichen Routinen nur mit großem Display-Buffer hinterlegt.

Info: In der Funktion "void LCD_Plot_Wave(uint8_t wave_index)" habe ich 
für Testzwecke einen Timer mitlaufen, der mir die benötigte Zeit für das 
Zeichnen einer Wellenform-Line anzeigt.

Gruß Rolf

[Rolf D. (rolfdegen)]

Hallo

Im Anhang noch drei weitere Funktionen zum zeichnen eines Rechtecks 
(Rahmen oder gefüllt), einer vertikalen und horizontalen Linie. Die 
Funktion zum Zeichnen eines gefüllten Rechtecks ist hier allerdings noch 
sehr langsam, da jeder Pixel einzeln gesetzt wird. Ich denke das man 
dies noch optimieren kann, indem man direkt 4 Pixel in eine 
Speicheradresse schreibt bzw ausliest. Momentan wird jeder Pixel einzeln 
mit dem Inhalt einer Speicheradresse (4 Pixel) maskiert und 
abgespeichert. Eine Speicheradresse beinhaltet 4 Pixel (Y-Richtung) und 
4Bit für die Grauwerte.

Gruß Rolf

[Rolf D. (rolfdegen)]

Hallo zusammen..

Da ich gerade an einer Scope-Funktion für den AVR-Synth "bastle" habe 
ich mal schnell ein Video davon gemacht.

http://www.youtube.com/watch?v=_IJ8TA7NLr0

Die Scope-Funktion bekommt später eine eigene Menü-Seite im AVR-Synth. 
Im Moment funktioniert sie sobald eine Taste auf dem Keyboard gedrückt 
wird. Meine Idee ist es, im Osc-Menü oben rechts ein kleines 
Mini-Fenster anzuordnen, in dem das Audiosignal vom Ausgang angezeigt 
wird. So kann man direkt sehen welchen Einfluss die ausgewählte 
Oszilator-Wellenform auf das Ausgangssignal hat.

Gruß Rolf

[Axel R. (Gast)]

Ich bekomms mit den Schriften nicht hin und ersuche um Hilfe:(
Ich verwende die 095er Version der Lib.

im makefile:

# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c dogm-graphic.c font.c fonts/font_fixed_8px.c

in der main.c:

  init_spi_lcd();
  lcd_init() ;
  sei();
  lcd_put_string(font_fixed_8px,NORMAL, ("Hallo Welt"));

Ausgabe vom gcc/make:

main.c: In function 'main':
main.c:174: error: incompatible type for argument 1 of 'lcd_put_string'
make.exe: *** [main.o] Error 1

Ist bite jemand so nett und stellt nochmal einen dreizeiler rein, wie 
man das mit den Schriften nun macht?

Ich sehe nicht durch: der Ordner "Fonts" wird im Makefile mit angegeben? 
wenn ja - wie und wo?

Ziel sollte es sein, kleine und große Schriften verwenden zu können...

In der Font.h habe ich ersteinmal nur den einen fixen font "eingestellt"

//#define FONTS_INCLUDE_font_proportional_8px     font_proportional_8px   
#define FONTS_INCLUDE_font_fixed_8px            font_fixed_8px
//#define FONTS_INCLUDE_symbols_8px               symbols_8px

Vielen Dank einsteweilen.
Das Display ansich funktioiniert, Logo konnte ich darstellen. 
Bottom/Topview geht auch.

Viele Grüße und danke
Axelr.

[Axel R. (Gast)]

ich habe google benutzt und bin hierüber gestoplert:
http://stackoverflow.com/questions/11546076/error-incompatible-type-for-argument

ich habe nun ein "&" vor den Fontbezeichner gesetzt und alles 
funktioniert tadellos.

lcd_put_string(&font_proportional_16px,NORMAL, "Hallo Welt");

im Makefile habe ich die entsprechende Fontdatei mit hinzugefügt und un 
der font.h die passende Zeile einkommentiert.

Aber muss das so?? Habe ich da etwas überlesen oder ist das alles 
richitg jetzt? Ich sehe es mir einfach nocheinmal an... ( Vorerst geht's 
ja ;) )

Axelr.

[Jan M. (mueschel)]

Axel R. schrieb:
> Aber muss das so?? Habe ich da etwas überlesen oder ist das alles
> richitg jetzt?

Das ist so richtig, gedacht ist es etwas anders. In font.h gibt es ein 
define, das "schönere" Namen definiert:

#define FONT_PROP_16 &font_proportional_16px

Dann geht:

lcd_put_string(FONT_PROP_16,NORMAL, "Hallo Welt");

Ich würde allerdings empfehlen, die Funktion lcd_put_string_P zu 
benutzen, dann liegt der String im Flash und nicht im (meist wertvollen) 
RAM:

lcd_put_string_P(FONT_PROP_16,NORMAL, PSTR("Hallo Welt"));

[Axel R. (Gast)]

Vielen Dank für den Hinweis!
Wie blind muss man sein? ;)
Beim Beispiel war der 8ter fixed Font ausgewählt. Da fiehl das, der 
84komma615%tigen Namensgleichheit zum define geschuldet, nicht auf.
Anfangs hatte es funktioniert, bis ich dann (irgentwann) nicht mehr
"FONT_FIXED_8" angab, sondern aus Unachtsamkeit "font_fixed_8px"...

Nochmals vielen Dank für die Erklärung.

Axelr.

BTW: wer hier nur Hobbyprogrammierer ist, hat es mit den ...zig 
verschachtelten #defines sehr schwer, durchzublicken.
Trotz alledem bzw. gerade daher: Großen Respekt und vielen Dank für die 
geleistete Arbeit Dir und allen Beteiligten.

[Rolf D. (rolfdegen)]

Hallo zusammen..

Hier ein kleiner Einblick in meine Entwicklungsarbeit (DIY Synthesizer) 
mit dem DOGXL 160-7 Display. Für die Ansteuerung des Displays verwende 
ich einen Xmega128A1 und SPI-Interface. Grundlage für die Ansteuerung 
des Displays waren die C-Routinen von Jan Michel 
(Beitrag "Re: glcd fontcreator aktuell"). Aufbauend auf diese 
Routinen werden bei mir die Display-Daten in einen 2K Byte großen SRAM 
Buffer im Xmega zwischengespeichert und nach Bedarf zum Display 
gesendet.

Youtube: http://www.youtube.com/watch?v=DceCkckwcMI&feature=youtu.be

Mein Projekt: 
http://www.cczwei-forum.de/cc2/thread.php?threadid=5878&threadview=0&hilight=&hilightuser=0&page=17

Gruß Rolf

[Jan M. (mueschel)]

Hallo,
kurzes Update:
Die aktuelle Code-Version gibt es ab sofort auf github:
https://github.com/mueschel/lcdlib

Neu dabei sind:
- 16 Pixel hoher Font mit fixer Breite
- eine kleine Library für ein 240x320 Farb-LCD mit SPI inklusive der 
Anbindung an den vorhandenen Font-Generator. Grafik-Funktionen gibt es 
noch nicht, aber das kann sich ja auch noch ändern.


@Rolf: Schickes Design!

[Christoph K. (Gast)]

Hallo,
erstmal möchte ich ein ganz großes Dankeschön vorausschicken an Jan und 
alle anderen, die zu der Bibliothek beigetragen haben.
Ich habe ein kleines Problem.

Kurzform:
Ich nutze die Bibliothek zum Ansteuern eines DOGS102 und habe heute nach 
langer Pause das Projekt wieder aufgenommen.

lcd_clear_area_xy(8,102,NORMAL,0,0)

hat nicht mehr richtig funktioniert (vorher ohne Probleme) und ich 
musste

#define LCD_WIDTH

 von 102 auf 103 setzen. Nun scheint alles wieder zu funktionieren. Was 
ist da los?

Langform:
Ich wollte gestern, nach ca. 1,5 Jahren Pause, endlich mal an einem 
Projekt weiterarbeiten. Es nutzt diese Bibliothek um ein DOGS102 
anzusteuern.
Ich war damals bereits so weit gekommen, dass ich eine einfache 
Menüstruktur umgesetzt hatte.
Also Projekt mit make kompiliert und übertragen - nichts ging!
Nach einigem herumprobieren habe ich ein anderes Projekt genommen, 
nicht neu kompiliert und übertragen - und siehe da, es funktionierte. 
Dann habe ich es neu kompiliert und den gleichen Fehler bekommen.

Ich konnte den Fehler dann auf die Funktion lcd_clear_area_xy() 
eingrenzen.
Mit

lcd_clear_area_xy(8,102,NORMAL,0,0)

 wurde nur die erste Zeile gelöscht. Mit

lcd_clear_area_xy(8,101,NORMAL,0,0)

 wurde dann das ganze Display außer die letzte Spalte gelöscht. Ich 
vermutete ein Problem mit dem Zeilenumbruch und habe

#define LCD_WIDTH

 auf 103 gesetzt und seitdem scheint alles zu funktionieren...

Alles schön und gut aber jetzt wüsste ich doch gerne warum?
Ich bin, was das Programmieren angeht nicht besonders bewandert, aber 
ich vermute mal das ist ein Problem mit dem Kompiler, oder? Nun ist die 
Frage, ob es große Änderungen im gcc-Kompiler gab (hab mir gestern den 
neuen heruntergeladen), oder ich irgendeine Einstellung ändern muss.
Wie gesagt, die Programme haben alle schon einmal funktioniert.

Viele Grüße
Christoph

[Gerhard G. (g_g)]

Hallo Jan M.

habe dein Library für ein 240x320 Farb-LCD getestet.

Hintergrund und Vordergrund kann ich einstellen und funktioniert 
bestens.
Ebenso die Cursor-Steuerung lcd_set_pixel_xy()

Aber die eigentliche Ausgabe für Text:

void lcd_write_font_byte(uint8_t b)
{
usw..
}

funktioniert nicht!

Hier fehlt mir irgendwie der Zusammenhang mit der Font-Geschichte!

Vielleicht kannst du mir da weiterhelfen.

Danke

G.G.

[Jan M. (mueschel)]

Hallo Gerhard,
lcd_write_font_byte() ist eine Hilfsfunktion für die Font-Library.
Diese nutzt ein #define in font.h, das eine Funktion festlegt, die die 
Daten ans LCD schickt:
https://github.com/mueschel/lcdlib/blob/master/font.h#L115

#define LCD_WRITE(x)       lcd_data((x))

Dort muss dann lcd_write_font_byte() angegeben werden anstelle von 
lcd_data().

[Gerhard G. (g_g)]

Hallo Jan,

funktioniert bestens!!

Habe ein TFT-1.8" (ST7735) Display genommen. Das Display hat die selbe 
Adressierung und die Register stimmen auch.

Noch ein Vorteil: die ganze Sache funktioniert auch mit printf(),
was bei den meisten TFT-Lib's nicht der Fall ist. Das komplette 
Überschreiben von Text ist auch möglich.

Werde die nächsten Tage mal den Code (Atxmega..) hier einstellen!

Vielen Dank nochmals

G.G.

[Ersi (cell85)]

wie macht ihr denn die schönen grafiken auf dem display?

Wo gibts denn diesen Fonteditor ? Ich mag auch smileys haben.

[Gerhard G. (g_g)]

Hallo,

Electronic Assembly

Hauptseite: http://www.lcd-module.de/

Zeichenprogramm:

http://www.lcd-module.de/fileadmin/downloads/Setup%20LCD-Tools%20Portable%2045.exe



Gruß G.G.

[roblue (Gast)]

Hallo,

ich möchte mir ein DOGXL240W-7 zulegen und habe folgenden Text in einem 
Onlineshop gelesen:

Diese neue Displayserie wurde speziell für low-power Handheld 
Applikationen entwickelt. Erstmals ist der Betrieb eines 
Standard-Displays direkt an 3,3V möglich! Ein 5V Betrieb ist bei den 
Textdisplays ebenso möglich. Auch die optional erhältlichen 
LED-Beleuchtungen laufen in der Regel mit 3,3V oder 5V.

Habe hier aber etwas von Pegelwandler mit 5V Controller gelesen und im 
Datenblatt steht ebenfalls Supply 3.3V. Das Display soll bei mir an 
einen PIC18 mit 5V Versorgungsspannung. Funktioniert das Display da 
direkt an 5V?

LG

[Jan M. (mueschel)]

Hallo,
das entscheidende Wort im Werbetext ist "*Text*display" - die reinen 
Text-LCD können mit 5V betrieben werden, die Grafikdisplays nicht. Diese 
brauchen in jedem Fall eine 3.3V Versorgungsspannung und entsprechende 
Pegel an den Logikeingängen.

Gruß, Jan

[roblue (Gast)]

Danke für die schnelle Antwort!

[André L. (a_a)]

Hallo Zusammen,

ich dachte mir ich schreibe hier mal direkt weiter, nachdem auf dieses 
doch etwas längere Thema gestoßen bin.

Ich selbst verbaue gerade in einem Projekt ein DOGXL240-7 
(http://www.reichelt.de/EA-DOGXL240S-7/3/index.html?&ACTION=3&LA=446&ARTICLE=140444&artnr=EA+DOGXL240S-7&SEARCH=dogxl240). 
Ich selbst befasse mich jetzt schon etwas länger mit Mikrocontroller und 
benutze aktuell den Atmega1284P, welchen ich in C programmiere. 
Vorgesehen ist die Ansteuerung des Displays in I²C, da ich dann ja auch 
Daten lesen kann und das einige Vorteile zu bringen scheint ?

Ich bin dabei auf dieses Thema hier gestoßen, welches mir beim ersten 
Kontakt mit grafischen Displays wohl ziehmlich helfen wird. Vielen Dank 
hier schonmal an die Autoren. Meine Frage ist nun, ob ich die aktuellste 
Version einfach auf ein 240er anpassen kann oder ob ich auf etwas mehr 
achten muss ? Mir scheint es so, dass ich lediglich die Tabellen des 
Datenblatt mit dem bereits programmierten vergleichen und abändern muss 
!?!? Wäre dann ja ziemlich "einfach" (so die Theorie).

Liebe Grüße

André

[Jan M. (mueschel)]

Hallo André,
viele Änderungen werden nicht nötig sein. Anscheinend ist ein anderer 
Controller verbaut als bei den restlichen LCDs, d.h. du musst die 
Befehlsliste in dogm-graphic.h anpassen. Die Initialisierungssequenz 
muss natürlich auch angepasst werden, aber dann sollte alles zunächst 
einmal laufen.
Wenn du I2C verwenden willst, dann musst du auch nur die Ausgaberoutine 
entsprechend anpassen. Das Lesen von Displayinhalten wird dann zwar noch 
nicht unterstützt. Das ist eigentlich auch nur bei der Darstellung von 
kleinen Grafiken (Linien, Kreisen...) nötig, und diese sind bei meiner 
Lib ja auch noch nicht enthalten.

Die aktuelle Version liegt wie gehabt auf github: 
https://github.com/mueschel/lcdlib .
Ich würde mich freuen, wenn wir deine Erweiterungen dann später mit in 
das Repository aufnehmen könnten.

Gruß, Jan

[André L. (a_a)]

Hallo Jan,

wie du richtig erkannt hast ist hier der UC1611s verbaut, ist jedoch 
ähnlich zu den anderen. Ich werde mal schauen, dass ich die Tage alles 
anpasse und anschließe und melde mich dann entweder mit Erfolg oder 
Problemen erneut.

Vielen Dank schonmal für die schnelle Antwort und die Erweiterungen 
dürfen dann natürlich gern ins Repository aufgenommen werden.

Gruß André

[Daniel Held (Gast)]

Hallo Jan,

vorerst vielen Dank für die lib.
Ich habe jetzt aber doch ein Problem - seit der Umstellung auf Atmel 
Studio 6.2 werden die Umlaute nicht mehr korrekt dargestellt, es wird 
dann immer anstelle des Umlautes ein relativ langer String angezeigt.
Ich habe 2 Projekte und nutze bei beiden eine ATXmega das mit dem AS6 
kompilierte läuft perfekt und bei dem mit AS6.2 tritt der Fehler auf.

Hast Du evtl. eine Idee an was das liegen könnte?

Vielen Dank
Daniel

[Daniel Held (Gast)]

Mittlerweile bin ich etwas weiter gekommen, konnte das Problem aber noch 
nicht lösen :-(

Die Funktion "font_get_char_width(font,character);" gibt eine falsche 
Länge zurück - im Beispiel von"ü" -> 57 normal wäre da 7

Ich stehe voll auf dem Schlauch...

[Jan M. (mueschel)]

Hallo Daniel,
das klingt nach einem encoding Problem. Wenn du literale Umlaute hast, 
muss der String im Quellcode als ASCII gespeichert werden, nicht als 
UTF-8. Wie man AVR Studio das beibringt weiß ich nicht.
Probiere einfach mal statt dem 'ü' ein \x81 in den String zu packen, 
dann steht wirkliche ein ü im String im uC.

[Daniel Held (Gast)]

Hallo Jan,
Danke für die Unterstützung :-)

Leider bringt "\x81" ein ähnliches Ergebnis. Im Debugger wird in der 
Fkt. lcd_put_char der korrekte Wert für den Character angezeigt (0x81), 
aber die Länge aus der Fkt. font_get_char_width ergibt immer noch 57 
(0x39). Ich vermute evtl. ein Problem bei den pgm_read_.. Funktionen?

VG Daniel

[Daniel Held (Gast)]

Hallo Jan,
es handelt sich wohl nur um ein Vorzeichenproblem. Ich habe das jetzt 
vorerst durch einige casts gelöst.

Vielen Dank für die Hilfe
VG
Daniel

/*********************************************************************** 
*******
 * Get the number of the character in the given font
 */
inline int16_t font_get_char_number(FONT_P font, char character) {
  FONT_P tmp = font;
  if ((unsigned char)character > pgm_read_byte(&tmp->lastchar))
    return -1;
  uint8_t first = pgm_read_byte(&tmp->firstchar);
  if ((unsigned char)character < first)
    return -1;
  return (unsigned char)character - first;
  }

[Hive_live (Gast)]

Hallo Forum,

ich wollte mal von BASCOM weg und AVR Studio verwenden. Ich möchte mir 
einem ATmega8 das DOGm132 ansteuern. Da ich sehr lange nicht mehr 
richtig Programmiert habe stehe ich gerade vor einem riesen 
Fragezeichen.

Ich benötige eine Kurze Einweisung.
Ich habe die Library Heruntergelden.
in mein Programm eingepflegt. Und wollte folgendes Kompilieren

#include "C:\Users\tci\Desktop\Includes\dogm-graphic.c"
#include "C:\Users\tci\Desktop\Includes\font.c"
#include <avr/io.h>
#define F_CPU 1000000UL

int main(void)
{
    while(1)
    {
       init_spi_lcd();
       lcd_init() ;
       lcd_put_string_P(FONT_PROP_16,NORMAL, PSTR("Hallo Welt"));
    }
}

Ich bekomme einige Fehlermeldungen

TXC1 undeclared(first use in this function)
UDR1 " " " " " "
UCSR1A " " " " " "

Ich mache anscheindend Grundsätzlich einige dinge Falsch. Ein hinweis 
oder Links wie es richtig geht wären nett.

[Daniel Held (Gast)]

Hallo Hive_Live,
binde mal nicht die *.c Dateien ein sondern die *.h Dateien.
In den so genannten Header-Files (*.h) werden dann auch die 
entsprechenden Defines zugewiesen. Die musst Du dann natürlich noch an 
Deine Hardware anpassen.
...und der richtige Befehl um einen String zu "drucken" wäre 
lcd_putstr("Hier der String");

[Thomas B. (ewi)]

Im Datenblatt (Stand 1.2009, Seite 6) und in den Source Code Beispielen 
zum DOGM132-5 LCD wird der Static Indicator Off mit einem 2 Byte Befehl 
initialisiert:
0xAC Static Indicator Command mit Indicator Off
0x00 Static Indicator Register Set Command mit Flashing Mode Off

Und genau so wird es zur Zeit auch in dieser Lib gemacht. Ich vermute, 
dass das falsch ist. Im Datenblatt (V1.5, 2006/03/10) des für das EA 
DOGM132-5 verwendeten LCD Drivers ST7565R, steht nämlich auf Seite 46, 
dass der Static Indicator Off Befehl im Gegensatz zum On Befehl ein 
'single byte command' ist und demnach nur aus einem
0xAC Static Indicator Command mit Indicator Off
besteht.

Die 0x00 aus obiger Initialisierung wird deswegen als neuer Befehl 
interpretiert und, da es diesen nicht gibt, hoffentlich ohne 
Nebenwirkungen verworfen.

Wenn man im Netz sucht, finden sich sowohl Beispiele mit falscher 2 Byte 
Initialisierung, als auch richtiger 1 Byte Initialisierung für den 
Static Indicator Off Zustand. In dem Projekt, für das ich seit längerem 
diverse Updates mache (OBD2-Analyser NG aus Elektor 09/2009), war es 
auch falsch. Deswegen ist es mir überhaupt aufgefallen.

Um zu zeigen, dass der Static Indicator Off Befehl tatsächlich ein 1 
Byte Befehl ist, ohne auf die FR und FRS Pins des ST7565R, auf die 
dieser Befehl Auswirkungen hat, zuzugreifen, habe ich mir folgende 
Sequenz überlegt und erfolgreich mit einem EA DOGM132-5 LCD getestet:

Ausgangszustand: Display ist On.

0xAE Display Off Befehl
Pause 1s
0xAC Static Indicator Off Befehl (1 Byte Befehl)
0xAF Display On Befehl -> Display geht an

Erwartet: Display geht aus und nach einer Sekunde wieder an
Getestet: OK, das ist so

Wäre es ein 2 Byte Befehl, würde sich der ST7565R nach dem ersten Byte 
vom Static Indicator Off Befehl im Zustand 'Warte auf Static Indicator 
Register Set' befinden. Und im nächsten gesendeten Byte nur auf die 
Flashing Mode Werte 00, 01, 10 oder 11 in Bit 0..1 achten.
Der Display On Befehl 0xAF würde dann als Flashing Mode 11 für Bit 0..1 
für den Static Indicator Register Set Befehl interpretiert und das 
Display bliebe dunkel. Das Display geht aber wieder an, wie erwartet.

Gegenprobe:

Ausgangszustand: Display ist On.

0xAE Display Off Befehl
0xAD Static Indicator On Befehl (2 Byte Befehl)
0xAF Display On Befehl -> Display bleibt aus, trotz On Befehl
Warte auf Taste
0xAF Display On Befehl -> Display geht an, wie erwartet

Erwartet: Display bleibt bis zum Tastendruck aus, da 0xAF als Flashing 
Mode 11 in Bit 0..1 für Static Indicator Register Set interpretiert wird 
und geht erst nach Tastendruck nach dem nächsten 0xAF wieder an
Getestet: OK, das ist so

Fragt mich jetzt aber nicht, was beim 2 Byte Befehl 0xAD Static 
Indicator On + 0x00 Static Indicator Register Set = Off, rauskommt. Ich 
vermute mal, dass das identisch ist zum 1 Byte Befehl 0xAC Static 
Indicator Off.

Eine andere Variante, die ich im Netz gesehen habe, ist, den Static 
Indicator gar nicht explizit zu initialisieren, sondern auf den über 
/RES ausgelösten Resetzustand (Static Indicator Off) zu vertrauen ;-)

Ich habe zu dem Thema auch den Hersteller EA des LC Displays 
angeschrieben. Sollte er antworten, stelle ich hier das Ergebnis rein.

[Hive_live (Gast)]

Hallo Forum,

Danke ich hatte die includes nicht im Program aktiviert.
Ich habe jetzt keine Fehler mehr und kann den µC Programmieren.

Trozdem bleibt das Display tot. Das Display ist richtig angeschlossen 
das hab ich mehrfach Kontolliert.

Ich verwende einen ATmega8

Mein Oszi zeigt mir
B0 => Signal
B1 => H
B2 => Signal
B3 => GND
B4 => GND
B5 => GND

Setzte ich in der dogm-graphic.h LCD_USR_CHIPSELECT 0 liegt bis auf an 
B1 => H  GND an?

Meine Konfig in spi.c ist
#define LCD_A0     2
#define LCD_RST    1
#define LCD_CS     0
#define SPI_MOSI   3
#define SPI_MISO   4
#define SPI_SCK    5

Meine Konfig in dogm-graphic.h ist
//A0 Port (CD on DOGS & DOGXL)
#define PORT_A0  PORTB
#define DDR_A0   DDRB
#define PIN_A0   2

//Reset Port
#define PORT_RST PORTB
#define DDR_RST  DDRB
#define PIN_RST  1

//Backlight Port
#if LCD_USE_BACKLIGHT != 0
  #define PORT_LED PORTD
  #define DDR_LED  DDRD
  #define PIN_LED  2
#endif

//Chip select
#if LCD_USE_CHIPSELECT == 1
  #define PORT_CS  PORTB
  #define DDR_CS   DDRB
  #define PIN_CS   0
#endif

Ich weiss das solche Fragen nerven. Trozdem würde ich mich um eine 
Antwort freuen.

[Hive_live (Gast)]

Sorry für die blöde Frage. Ich depp habe immer wieder die gleiche HEX 
geladen.

[Hive Live (Gast)]

Hallo,

ich versuche seit mehreren Stunden eine Grafik auf dem Display 
auszugeben. Leider ohne Erfolg!

Jetzt möchte ich einfach nur eine Linie Anzeigen.

µC: Atmega8
Display: Dogm 132


int8_t Balken[] PROGMEM = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};
lcd_moveto_xy(0,0);
lcd_draw_image_P(Balken,1,8,NORMAL);

bei diesem code sehe ich folgendes:
 X0-
Y0 oooooooo
|  oooooooo
   oooooooo
   oxoooooo
   oxooxoox
   oxooxoox
   ooooxoox

[DominikW (Gast)]

Hallo zusammen,

danke für die Library. Ich habe sie erfolgreich mit meinem DOGM128 
getestet.

Allerdings musste ich LCD_WIDTH auf 129 ändern. Sonst kann ich Pixel 128 
nicht löschen. Komisch...

Gruss

[Jan M. (mueschel)]

Hallo Dominik,
etwas ähnliches hat Christoph K anfang des Jahres auch bemerkt.
Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator"
Ich muss aber gestehen, mich noch nicht darum gekümmert zu haben. :-(

[Jan M. (mueschel)]

Inzwischen habe ich mir das Problem mit dem lcd_clear_area angeschaut. 
Mit einer kleinen Änderung funktioniert es jetzt wie gewünscht. Mir ist 
kein Fall aufgefallen, bei dem es nach dieser Änderung jetzt Probleme 
geben sollte - falls doch, bitte einfach melden.

Die aktuelle Version liegt wie gehabt auf
https://github.com/mueschel/lcdlib

[hive live (Gast)]

Hallo

Ich habe jetzt das dogm128 am laufen aber die Grafiken werden noch immer 
wie im Post oben dargestellt.

Ich bin für jede Hilfe dankbar

[Gerhard G. (g_g)]

Hallo,


int8_t Balken[] PROGMEM = {
0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1,
};

versuch es hiermit.

[hive liver (Gast)]

Hallo

die Ausgabe auf dem Display bleibt die gleiche. Ich weis nicht was ich 
noch probieren kann. Ich habe das Display von DOGM132 auf DOGM128 
gewechselt. Ich habe auf die neuste Version der Lib gewechselt. Ich weis 
nicht mehr wie oft ich den ganzen Verlauf hier gelesen habe um das 
Problem zu beheben.
Ich habe unterschiedlichste Bilder Konvertiert aber die Ausgabe war fast 
immer dieses Streifenmuster oder ein vielfaches davon. Ich habe jetzt 
~20Std in dieses Problem investiert. Ich bin für jede Hilfe oder 
hinweise dankbar.
Die Ausgabe von Buchstaben funktioniert aber Tadellos.

[Gerhard G. (g_g)]

Hallo,


probiere es mal mit "const"

const int8_t Balken[] PROGMEM = {
0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1,
};


Gruß G.G

[Andreas (Gast)]

Hallo, funktioniert die LIB auch auf einem Arduino Due(ARM Cortex-M3)?
Danke und Gruss
Andreas

[Ersi (cell85)]

ich hab noch 10 DOGM Displays mit Background light.  wer mag der kann.

[Gerhard G. (g_g)]

Hallo,

in der Lib werden die Fonts mit "PROGMEM" im Flash-Speicher abgelegt! 
Das ist nicht kompatible mit dem ARM Cortex-M3.
Die Lesebefehle dazu pgm_read_byte() müssten alle angepasst werden.

[Jan M. (mueschel)]

Genau wie Gerhard schreibt: Einige Befehle sind recht spezifisch und 
werden deinem Compiler nicht gefallen. Aber außer diesen Lesebefehlen 
aus dem Flash sowie der Initialisierung von Ports und SPI sollte nicht 
viel zu machen sein, der eigentliche Programmcode hat da keine 
Abhängigkeiten.

[Andreas D. (aadd2000)]

Hallo und Danke für die Antwort.

Gruß Andreas

[Marten M. (mcgonahy148)]

Hallo,

EGS_TI (guest) hatte mal wegen der Ansteuerung des LCDs mit einem PIC 
angefragt.

Wollte fragen, ob nun er oder wer anderes eine Lib für einen PIC hat?


Gruß,
Marten

[EGS T. (egs_ti)]

Hi,

guck mal ob du damit was anfangen kannst. Das kann ich dir auf die 
Schnelle anbieten.

[Ben K. (Gast)]

Hallo Forum

die Library fkt super. Nur eigene Fonts erstellen bekomme ich nicht hin. 
Ich bekomme nur Zeichensalat.

Wenn ich eine font wie Digit_24px oder font_proportional_8px im font 
Editor öffne nichts verändere und die font wieder Speicher bekomme ich 
nur Zeichensalat. Die compress fkt ist ausgeschaltet adjust font height 
ein und ausgeschaltet versucht. Immer Zeichensalat.

Mein Vorgehen.
- ich lade eine *.font in den Editor.
- ich verändere nichts und speichere die *.font in einem Extra 
Verzeichnis/oder wieder im includierten font Ordner(kein unterschied)
- ich exportiere die *.h Datei
- Ich öffne die *.h Datei kopiere alle HEX werte und speichere Sie in 
die includierte *.c Datei

Das habe ich mit der prop_8 und Digit_24 getan.

Was mache ich falsch. Ich beiß gleich in einen Bleistift

[Jan M. (mueschel)]

Hallo Ben,
Hast du das template in die .ini-Datei vom Editor eingetragen?
Ansonsten lade einfach mal eine deiner generierten Dateien hoch, damit 
wir vergleich können.

[Ben K. (Gast)]

Hallo Jan,

ich habe das template nicht in die .ini Datei eingetragen.

Ich werde das morgen früh mal probieren. Damit ich nicht zig mal 
nachharken muss.

[export]
0=template_simplefont.c          //wie oben erwähnt

Ich habe aber im Tool Ordner nur template.asm-.c-.h.. Trotzdem?

Ist das vorgehen das ich oben beschrieben habe denn richtig?

Vielen dank das du dich noch immer um den thread kümmerst!!

[Jan M. (mueschel)]

Das template_simplefont.c musst du dann noch in den Ordner vom Tool 
kopieren damit es gefunden wird.

>Vielen dank das du dich noch immer um den thread kümmerst!!
Ich bastel ja auch immer noch an der Lib rum ;-)

[Frank X. (matrixx200x)]

Hi Jan,

ich habe mir gerade die neusten Dateien von deinem git runter geladen.

Und habe jetzt das Problem wenn die Funktion

lcd_draw_image_xy_P((char*)Image_xxx_BMP, 0, 0, 8, 128,0 );

so aufrufe das das Bild nicht auf Position 0,0 startet sondern auf der x 
= 1
und somit ein 128x64 Bild um 1 nach rechts verschoben ist.

Liegt der Fehler bei mir oder ist ein Fehler im Code.?

Mit der Lib 094 von Gerhard und der

draw_partialpic_dogm128((char*)Image_xxx_BMP,0,0);

Funktion hatte das alles ohne Probleme funktioniert.

Danke im voraus.

Floh

[Jan M. (mueschel)]

Hallo Florian,
ein Überlauf über die Größe des Displays wird nicht so behandelt wie es 
für Bilder notwendig wäre - dann geht es je nach Einstellung am Anfang 
der nächsten oder derselben Zeile weiter. Im Prinzip muss in die 
draw_image Funktion nur noch eine Abfrage rein, die überprüft, ob er am 
Ende des Displays angekommen ist und dann richtig auf die nächste Zeile 
schaltet.

Jan

[Frank H. (Gast)]

Habe auch ein DOGM128 am laufen. zur Zeit mit der Lib von Ulrich Radig, 
da sie etwas übersichtlicher ist.
Problem: egal was ich ausgebe, ich bekomm den Cursor nicht wieder an den 
Anfang gestellt (sollte ja mit display_clear() gehen). Jeder 
display_write() Befehl schiebt den Cursor weiter nach rechts, und dann 
irgendwann aus dem Bild raus.
Jemand eine idee wie ich ihn wieder an den Anfang setze?

[Frank H. (Gast)]

OK, es ist kein Text Display, deswegen wird es so eine Funktion nicht 
geben. Man übergibt ja den kompletten Bildschirm-Inhalt. Also müsste man 
eher bei dem Daten-Feld den man übergibt, den Cursor zurücksetzen.
Ich übergebe einen string an eine Funktion mittels Pointer.
zB
display_write("test1");
display_write("test2");

Was rauskommt ist
test1test2

Dabei soll der letzte Textr den vorhergehenden überschreiben.
Mehr als den String neu zu übergeben kann ich doch nicht machen oder wie 
versteht man das? Man müsste den Pointer zurückstellen, was anscheinend 
nicht gemacht wird.

[Frank H. (Gast)]

hat sich erledigt.

Bitte meine 2 letzten Fragen löschen!

[Jack (Gast)]

Hallo zusammen,

ich versuche jetzt seit mehreren Wochen dieses Display zum laufen zu 
bringen, leider ohne Erfolg.

- Atmega328p
- Dogm128-6
- 3.3V Betriebsspannung

bei mir wird das Display beim flashen kurz schwarz und geht dann aus.

ich bin mir nicht sicher ob das mit der Init bei mir richtig ist, vor 
allem mit dem CS / SS PIN
Ich habe den SS PIN (PB2) einfach als Ausgang definiert.
in dogm-grpahic.h folgende config:

//Should chip select (CS) be used?
#define LCD_USE_CHIPSELECT  1

//Chip select
#if LCD_USE_CHIPSELECT == 1
  #define PORT_CS  PORTC
  #define DDR_CS   DDRC
  #define PIN_CS   PORTC1
#endif
auf PC1 ist CS von dem Display aufgelegt.

hier ist die init von der SPI:

#define SPI_SS                PB2
#define SPI_MOSI        PB3
#define SPI_MISO        PB4
#define SPI_SCK                PB5

 void init_spi_lcd() {

        DDRB  = (1 << SPI_MOSI) | (1 << SPI_SCK) | (1 << SPI_SS);
        PORTB &=~(1<<SPI_MISO);

        SPCR = 0 << SPIE | 1 << SPE | 0 << DORD | 1 << MSTR | 1 << CPOL 
| 1 << CPHA | 0 << SPR1 | 0 << SPR0;
        SPSR = 1 << SPI2X;
        SPDR = LCD_NO_OP; //Do not use 0 here, only LCD_NOP is allowed!
 }

und hier noch die main:

int main(void)
{
        init_spi_lcd();
        lcd_init();


    while(1)
    {
                lcd_move_xy(0,0);
                lcd_put_string_P(FONT_FIXED_8, NORMAL, PSTR("Hallo 
Welt"));
    }
}

eigentlich gibt es da nicht all zu viel zum falsch machen oder?

[Jack (Gast)]

Hallo zusammen,

ich versuche jetzt seit mehreren Wochen dieses Display zum laufen zu 
bringen, leider ohne Erfolg.

- Atmega328p
- Dogm128-6
- 3.3V Betriebsspannung

bei mir wird das Display beim flashen kurz schwarz und geht dann aus.

ich bin mir nicht sicher ob das mit der Init bei mir richtig ist, vor 
allem mit dem CS / SS PIN
Ich habe den SS PIN (PB2) einfach als Ausgang definiert.
in dogm-grpahic.h folgende config:

//Should chip select (CS) be used?
#define LCD_USE_CHIPSELECT  1

//Chip select
#if LCD_USE_CHIPSELECT == 1
  #define PORT_CS  PORTC
  #define DDR_CS   DDRC
  #define PIN_CS   PORTC1
#endif
auf PC1 ist CS von dem Display aufgelegt.

hier ist die init von der SPI:

#define SPI_SS    PB2
#define SPI_MOSI  PB3
#define SPI_MISO  PB4
#define SPI_SCK    PB5

 void init_spi_lcd() {

  DDRB  = (1 << SPI_MOSI) | (1 << SPI_SCK) | (1 << SPI_SS);
  PORTB &=~(1<<SPI_MISO);

  SPCR = 0 << SPIE | 1 << SPE | 0 << DORD | 1 << MSTR | 1 << CPOL | 1 << 
CPHA | 0 << SPR1 | 0 << SPR0;
  SPSR = 1 << SPI2X;
  SPDR = LCD_NO_OP; //Do not use 0 here, only LCD_NOP is allowed!
 }

und hier noch die main:

int main(void)
{
  init_spi_lcd();
  lcd_init();


    while(1)
    {
    lcd_move_xy(0,0);
    lcd_put_string_P(FONT_FIXED_8, NORMAL, PSTR("Hallo Welt"));
    }
}

eigentlich gibt es da nicht all zu viel zum falsch machen oder?

Danke für eure Hilfe

[Jch (Gast)]

Hallo,
wird das DOGM240-6 auch demnächst unterstützt?

Grüße

[Jan M. (mueschel)]

Hallo Jch,
ich habe im Moment keine Pläne mit diesem großen Display.
Es sollte aber kein großes Problem sein: Aus dem Datenblatt des 
Controllers müssen die wesentlichen Befehle in die dogm-graphic.h 
übertragen werden - nach Möglichkeit mit den gleichen Namen wie bei den 
anderen Displays.
Dann muss in dogm-graphic.c noch die init-Sequenz geschrieben werden und 
schon sollte es funktionieren.

[Richard (Gast)]

Vielen Dank, super Projekt:)

[Rainer (Gast)]

Ich möchte das Display mit einem MSP430F1232W betreiben.
Hat das schon jemand gemacht?
Wurde die Library schon mal auf einen MSP portiert?

[JR (Gast)]

Hallo zusammen,

ich habe vor längerer Zeit das DOGM132-5 in Betrieb genommen und habe 
immer wieder das Problem, dass die Anzeige um mehrere Zeilen verschoben 
ist (im angehängten Bild um etwa 15 Zeilen nach oben).
Teilweise verschiebt sich die Anzeige auch während des Betriebs, mal 
nach oben, mal nach unten. Teilweise ist auch gar nichts mehr zu 
erkennen.
Und das obwohl die Startzeile bei der Initialisierung auf 0 festgelegt 
wird und anschließend nur doch die Pages entsprechend beschrieben 
werden. Rein vom Code sollte es eigentlich keine Verschiebung geben, sie 
tritt aber immer mal wieder auf. Teilweise läuft das Display tagelang 
ohne Probleme, teilweise ist die fehlerhafte Anzeige auch schon nach ein 
paar Stunden da.
Hatte irgendjemand von euch schon mal ähnliche Probleme?

Viele Grüße
Jürgen

[Jan M. (mueschel)]

Nach langer Zeit ein kleines Update:

Es gibt jetzt auch eine Variante der Lib, die mit Arduino verwendet 
werden kann, hier im Foto ein ILI9341 TFT (240x320px), angesteuert mit 
einem ESP8266 Modul.

Zu finden wie immer auf github:

https://github.com/mueschel/lcdlib   (EA DOG LCD & ILI9341 für AVR)
https://github.com/mueschel/lcdlib-arduino  (ILI9341 mit Arduino)

[Tho S. (thoso805)]

Hallo,

ist hier jemand noch aktiv und könnte mir helfen?

Ich versuche mit der Bib ein EA-DOG-XL 204-7 zum laufen zu kriegen.
Das ganze soll über 4-Bit-SPI laufen.

Ich habe vorher noch nie mit einem Graphicdisplay gearbeitet, sondern 
nur mit einem Charackter Display.


Die Initalisierungen sowieso SPI-PORT Konfigurationen habe ich 
verstanden.

Jedoch verstehe ich nicht wie ich eine Ausgabefunktion verwenden kann.

Mir würde es reichen wenn mir jemand kurz erklären kann wie man einfach 
nur irgendeinen Buchstaben irgendwo auf dem Display darstellen kann.


Gruß
Thomas

[Tho S. (thoso805)]

Hallo,

anscheinend ist hier niemand mehr.

Ich habs zum laufen bekommen. Jedoch funktionieren nur die kleinen 
Schriftarten...

[Jan M. (mueschel)]

Hallo Thomas,
klar schaue ich hier noch rein, aber nicht jeden Tag.

So ungefähr sieht ein Minimalbeispiel aus, um zwei unterschiedliche 
Texte auszugeben:

  lcd_init();
  lcd_clear_area(0,240,0,320);
  
  lcd_moveto_xy(6,0);
  lcd_set_font(FONT_PROP_16,NORMAL | WRAP);
  lcd_putstr("A long text that might warp around to the next line");

  lcd_moveto_xy(15,80);
  lcd_set_font(FONT_DIGITS_32,NORMAL);
  lcd_putstr("1:0");

Wegen der verschiedenen Schriftarten: Hast du auch alle Schriftarten 
eingebunden? In font.h kann man die jeweiligen #define (ab etwa Zeile 
20) ein- und auskommentieren um Speicher zu sparen.

[Tho S. (thoso805)]

Hallo Jan,

ich habe schon vieles geschafft in der Zeit, jedoch wird mir sobald ich 
eine der großen Schriftarten auswähle immernoch Murx angezeigt.

Ich habe bemerkt dass in der lcd_put_char Funktion ein paar Sachen 
auskommentiert wurden. Ich schätze mal es liegt daran. Ich verstehe die 
Funktion leider nicht komplett. Sie ist schon etwas komplexer für meine 
Erfahrung.

/*********************************************************************** 
*******
 * Outputs a character on the display, using the given font and style
 */
uint8_t lcd_put_char(FONT_P font, uint8_t style, char character) {
  uint16_t  i;
  uint8_t row  = 0;                             //current row of char
  #ifdef LCD_DOUBLE_PIXEL
    uint8_t hc   = 1;                           //height forced
  #else
    uint8_t hc   = (style & DOUBLE_HEIGHT)?1:0; //height changed
  #endif
  uint8_t wc   = (style & DOUBLE_WIDTH)?1:0;    //width changed
  uint8_t ul   = (style & UNDERLINE)?0x80:0x00; //underline
  uint8_t inv  = (style & INVERT)?0xFF:0;       //inverted
  uint8_t spc  = (style & SPACING)?3:1;         //spacing
  uint8_t tmp;

  //load information about character
   uint8_t char_width    = font_get_char_width(font,character);
   uint8_t font_height   = font_get_height_bytes(font);
   uint8_t free_space    = font_get_add_space(font,character)*spc;
   PGM_P   tableposition = font_get_char_position(font,character);

  //final size of character
  uint8_t char_final_width  = (uint8_t)(char_width+free_space) << wc;
  uint8_t char_final_height = (uint8_t)font_height << hc;

  /*//check for avail. space on display

  if ((style & WRAP) && (LCD_CURRENT_COL() + char_final_width > 
LCD_WIDTH)) {
    LCD_MOVE_TO(LCD_CURRENT_PAGE()+char_final_height,0);
    if (character == ' ') return 0;
    }
*/
  //write chracter
  do {
    for(i=(row>>hc); i<char_width*font_height; i+=font_height) {
      tmp = pgm_read_byte(tableposition+i);
      if(row == char_final_height-1)
        tmp |= ul;
      if(hc)
        tmp = double_bits((row&1),tmp);
      if(inv)
        tmp = ~tmp;
      lcd_dat(tmp);
      if(wc)
        lcd_dat(tmp);
      }
    if (free_space) {
      uint8_t c = inv;
      if(row == char_final_height-1) {
        c ^= ul;
        if(hc)
          c ^= ul>>1;
          }
      for(uint8_t x = free_space; x>0;x--) {
        lcd_dat(c);
        }
      }
  // move_yx(1,-char_final_width);
    } while (++row < char_final_height);

  //move cursor to upper right corner of character
  //move_yx(-char_final_height,char_final_width);
  return char_final_width;
  }

[Jan M. (mueschel)]

Lade dir doch mal die aktuelle Code-Version runter (*) und mache diese 
Änderungen bei dir rückgängig.

(*)https://github.com/mueschel/lcdlib

[Klaus (Gast)]

Hallo Jan
bist du noch mit dem DOG XL160 aktiv dran?
Versuche ebenfalls das Display zum laufen zu bekommen. Habe die oben 
angegeben Datein geladen und versuch es in den Griff zu bekommen. Klappt 
leider nicht. Du hast 2 Datein mit fonts drin stehen und 2 Datein mit 
dogm-graphig (c) und (h). Ist die main schon dabei oder muss man die 
selber schreiben? Wo steht bei deinen Datein die init für das Display?

LG Klaus

[Jan M. (mueschel)]

Hallo Klaus,
das XL160 habe ich nie selbst benutzt, es ist in der Library enthalten, 
weil die Unterschiede zu den anderen Displays doch eher gering sind.

ein main-Funktion musst du dir selbst schreiben, ich weiß ja nicht, was 
du auf deinem Display anzeigen willst.

Die init-Funktion findest du recht weit unten in dogm-graphic.c 
(lcd_init).

[achim (Gast)]

Hallo Jan
Ich möchte das Display XL160 mit dem I2C Bus verwenden. Der Hersteller 
EA erlaubt ja beide Versionen für das Display. Deine Dateien arbeiten 
mit SPI. a kein Anbindung zum Bus besteht funktioniert es nicht. Was 
muss genau dazu geändert werden? Hat es schon mal jemand gemacht?


achim

[Achim S. (achims)]

Habe ein kleines Stück zum testen geschrieben. Damit erfolgt bereits das 
init (teilweise). Eine Schrift oder ähnliches konnte ich nicht ausgeben.

#include <stdbool.h>
#include <avr/pgmspace.h>
#include "main.h"
#include "i2cmaster.h"
#include "avr/io.h"
#include "util/delay.h"
#include "avr/interrupt.h"
#include <stdlib.h>
#include "string.h"

// Adressen für XL160 0x7a
#define Write_Command  0x78
#define Read_Status    0x79
#define Write_Data    0x7A
#define Read_Data    0x7B
/*
// Adressen für XL160 0x7e
#define Write_Command  0x7C
#define Read_Status    0x7D
#define Write_Data    0x7E
#define Read_Data    0x7F
*/

int main (void) 
  {
    i2c_init();
    i2c_start(Write_Command);          // set device address and write mode
    i2c_write(0xF1);                   // Set last COM electrode to 103 (number of COM electrodes - 1)
  i2c_write(0x67);                        //
  i2c_write(0xC0);                        // SEG (column) and COM (row) normal
  i2c_write(0x40);                        // Set Display Startline to 0
  i2c_write(0x50);                        //
  i2c_write(0x2B);                        // Set Panelloading to 28..38nF
  i2c_write(0xEB);                        // Set Bias to 1/12
  i2c_write(0x81);                        // Set Contrast
  i2c_write(0x5F);                        //
  i2c_write(0x89);                        // Set Auto-Increment
  i2c_write(0xAF);                        // Display on
  i2c_stop();                             // set stop conditon = release bus

  while
  {

    //i2c_start_wait(Write_Data);          // set device address and write mode
    //i2c_write(0xFF);                        // Set last COM electrode to 103 (number of COM electrodes - 1)
    //i2c_stop();                             // set stop conditon = release bus

  } while (1);

  return 0;
}

Mit diesem Code erfolgt die korrekte Angabe der Adresse und der 
Parameter. Das Teil innerhalb der while Schleife hat nichts zu sagen. 
Sind noch überreste eines anderen Programmes.
Das Display wird damit angesprochen und es erscheint bereits eine 
sinnlose Angabe von Punkten.
Wie kann ich dein Programm anpsaasem um die ganzen voids zu nutzen?

achim

[Achim S. (achims)]

Habe einen Fehler gefunden.
Du verwendest bei init für das Display 160 die folgenden Zeilen:

#define LCD_LINE_RATE         0xA0  //15: Set line rate
     #define LCD_ALL_PIXEL         0xA4  //16: show all points
     #define LCD_INVERSE           0xA6  //17: Inverse display
     #define LCD_DISPLAY_ENABLE    0xAE  //18: Display enable
     #define LCD_MAPPING_CTRL      0xC0  // ist dabei   //19: LCD mapping control
     #define LCD_GRAY_SHADE        0xD0  //20: LCD gray shade
     #define LCD_RESET_CMD         0xE2  //21: System reset
     #define LCD_NO_OP             0xE3  //22: NOP

s geht dabei um diese Zeile:

#define LCD_DISPLAY_ENABLE    0xAE  //18: Display enable

müsste es nicht 0xAF sein?

[Jan M. (mueschel)]

Achim S. schrieb:
> #define LCD_DISPLAY_ENABLE    0xAE  //18: Display enable
> müsste es nicht 0xAF sein?

Nein, der Befehl ist 0xAE, wobei das untere Bit dann auswählt, ob man 
an- oder abschalten will. Weiter unten findest du die zugehörigen 
Befehle:

#define LCD_SWITCH_ON()               lcd_command(LCD_DISPLAY_ENABLE | 1)
#define LCD_SWITCH_OFF() lcd_command(LCD_DISPLAY_ENABLE | 0)

[Achim S. (achims)]

Habe in einem anderen Zip von dir gefunden:

//1: Display on/off
#define LCD_DISPLAY_ON       0xAF  //switch display on
#define LCD_DISPLAY_OFF      0xAE  //switch display off

Zum löschen des Displays habe ich das gefunden:

/******************************************************************************
 * This function clears an area of the screen
 * pages         - height of area in pages
 * columns       - width of area in pixels
 * style         - Bit2: sets inverse mode
 * Cursor is moved to start of area after clear
 
 * Diese Funktion löscht einen Bereich des Bildschirms.
 * Seiten - Höhe der Fläche in Seiten
 * Spalten - Breite des Bereichs in Pixel
 * style - Bit2: setzt Inversmodus
 * Der Cursor wird nach dem Löschen an den Anfang des Bereichs bewegt.
 */
void lcd_clear_area(uint8_t pages, uint8_t columns, uint8_t style) 
  {
    uint8_t i,j,max;
    uint8_t inv = (style & INVERT_BIT)?0xFF:0;
    if(pages > (max = LCD_RAM_PAGES - lcd_get_position_page()))   
      pages = max;
    if(columns > (max = LCD_WIDTH - lcd_get_position_column()))   
      columns = max;
    for(j=0; j<pages; j++) 
    {
        for(i=0; i<columns; i++) 
      {
            lcd_data(inv);
          }
        lcd_move_xy(1,-columns);
      }
    lcd_move_xy(-pages,0);
  }

/******************************************************************************
 * This function clears an area of the screen starting at the given coordinates
 * pages         - height of area in pages
 * columns       - width of area in pixels
 * style         - style modifier
 * col           - column of upper left corner
 * page          - page of upper left corner
 * Cursor is moved to start of area after clear
 
 * Diese Funktion löscht einen Bereich des Bildschirms ab den angegebenen Koordinaten.
 * Seiten - Höhe der Fläche in Seiten
 * Spalten - Breite des Bereichs in Pixel
 * Stil - Stil Modifikator
 * col - Spalte der linken oberen Ecke
 * Seite - Seite der linken oberen Ecke
 * Der Cursor wird nach dem Löschen an den Anfang des Bereichs bewegt.
 */
void lcd_clear_area_xy(uint8_t pages, uint8_t columns, uint8_t style, uint8_t page, uint8_t col) {
  lcd_moveto_xy(page,col);
  lcd_clear_area(pages,columns,style);
  }

Damit kann Bereich oder Teile löschen. Gibt es so was für das ganze 
Display oder Aus und wieder einschalten?

[Achim S. (achims)]

Habe weiter gemacht mit dem I2C Bus. Wahrscheinlich kann ich die Befehle 
von Jan kaum nutzen. Da ich jedes Pixel über den Bus einstellen muss, 
ist der Ablauf auch anders.

Hat keiner Idee oder so was schon mal gemacht?

achim

[Gerhard G. (xmega)]

Hallo,

habe mal vor ein paar Jahren folgende Dateien verfasst.

Atmega644 und DOGXL160/I2C

//LCD_RST  PC2  Display RST  PIN 29
//SDA       PC1  Display SSA  PIN 31   4,7K an 3,3V
//SCL      PC0  Display SCK  PIN 32  4,7K an 3,3V

//              Display D6      PIN 26  an 3,3V
//              Display BM0     PIN 30   an 3,3V
//              Display CD  PIN 27  an GND
//              Display A2  PIN 28   an GND


Siehe Anhang ZIP

Gruß G.G.

[Achim S. (achims)]

Hallo Gerhard
danke für deine Hilfe. Bin schon dabei es anzuschauen. Hat der Code auf 
dem AT644 funktioniert?
achim

[GG (Gast)]

Ich habe das für Atxmega.. programmiert.
Anschließend nach Atmega644 umgesetzt.
Mußte auch die I2C Lib wechseln.
Stelle heute Abend mal ein Bild mit der Displaydarstellung ein.

[Gerhard G. (xmega)]

Hier mal die Anzeige auf dem Display.
Hat wunderbar funktioniert!

Gruß G.G.

[Achim S. (achims)]

Sieht richtig gut aus, besonders mit der Uhr. Bin gespannt ob ich das 
auch so schaffe

[Achim S. (achims)]

Hallo
habe die ersten Pixel auf dem Display zum Leben erweckt. Bin gerade an 
den Parametern dran, halt was wie geht.
Habe wieder was gefunden was ich so nicht verstehe.

- wie bekommst du die Uhr auf den Schirm?
- wie kann ich Text einstellen?
- kann ich einen Strich von A nach B ziehen?
- kann ich z.B. ein Quadrat zeichen oder andere Figur?

achim

[Gerhard G. (xmega)]

Servus Achim,

lcd_set_font(FONT_PROP_16, NORMAL); // FONT_PROP_16
lcd_moveto_xy(0,0); printf("Atmega644 11059200 Mhz");

while (1)
{

lcd_set_font(FONT_PROP_16, NORMAL);// FONT_PROP_16
lcd_moveto_xy(0,0); printf("Atmega644 11059200 Mhz");
lcd_moveto_xy(4,0); printf("DOGXL160 mit I2C");

lcd_set_font(FONT_PROP_8, NORMAL);// FONT_PROP_8
lcd_moveto_xy(10,0); printf("I2C/TWI Takt: 400 KHz");
lcd_moveto_xy(12,0); printf("Lib von Jan Michel");
lcd_moveto_xy(14,0); printf("Atmel AVR Studio 6");
lcd_moveto_xy(16,0); printf("Version 6.1");
draw_partialpic_dogxl160((char*)uhr_bmp,10, 76);
// UHR-Bmp  ELECTRONIC ASSEMBLY LCD-Tools (grafik.c)

}

in der ATMEGA644_DOG_160.c findest du alle Befehle die am Display 
angezeigt werden.
z.B. schreiben: printf("Atmega644 11059200 Mhz");

Sollte das nicht funktionieren, ist die Pixeldarstellung von der du 
immer schreibst fehlerhaft.

[Hans (Gast)]

Habe das Projekt ebenfalls auf einem DOG XL160 umgesetzt. Beim Probelauf 
sind mir ein paar Sachen aufgefallen.

- die Graphik für Uhr und Sanduhr sind gleich
- die Einstelleung der I2C Bus Adresse ist doch recht versteckt
- Angabe der Quarzfrequenz muss 2 mal erfolgen sonst util nicht warum?

Kennt jemand noch andere Graphik Zeichen?

LG Hans

[Stefan (Gast)]

Hallo,
ich habe Probleme, die Library einzubinden, bzw. das Beispielprogramm 
von der Arduino-Library auf meinen Arduino Micro zu programmieren.

Ich bekomme immer beim Programmiervorgang folgende Fehlermeldung, mit 
der ich nicht wirklich etwas anfangen kann:
In file included from 
C:\Users\Stefan\Documents\Arduino\libraries\lcdlib-arduino-master\lcdlib 
-arduino\lcdlib-arduino.ino:7:0:
C:\Users\Stefan\Documents\Arduino\libraries\lcdlib-arduino-master/font.h 
:4:10:  fatal error: pgmspace.h: No such file or directory
 #include <pgmspace.h>
          ^~~~~~~~~~~~
compilation terminated.
exit status 1
Fehler beim Kompilieren für das Board Arduino Micro.


Bitte zerreißt mich nicht in der Luft, da meine Kenntnisse nicht 
sonderlich groß sind.

Ich möchte die Schrift auf meinem DOGL128 gerne invertiert darstellen 
und bin auf diese Library gestoßen, da die Standard-Library von EA das 
ja scheinbar nicht kann(?)

Ich würde mich freuen, evtl. einen Tipp zu bekommen, wo ich ansetzen 
kann.
Ein Bespiel-Sketch wäre evtl. auch sehr schön.

Liebe Grüße
Stefan

[Schorschi (Gast)]

Hallo,
ich habe da auch ein Problem mit dem Umgang mit der Library bzw. als 
Umsteiger ein Verständnisproblem.

Ich habe ein EA DOGM128 an einem ATMega324P und vor Jahren noch mit 
Bascom und einer Software SPI ans laufen gebracht.

Nun habe ich das Display an einem ATMega1284P per Hardware SPI 
angeschaltet. Natürlich mit Pegelwandler usw....
Da ich eine vorhandene Hardware für die ersten Tests nutzen möchte und 
nun auch schon ein paar Versuche ohne Ergebnis habe abbrechen müssen, 
die alles bewegende Frage.
Am ATMega1284p liegt die SPI an PortB. Kann man die drei anderen 
steuernden Pins an einen anderen Port legen z.B. an PortC ?

Probiert habe ich das schon bekomme es allerdings nicht zum laufen, es 
bricht immer bei der LCD Initialisierung ab und der ATMEga startet 
einfach neu durch den Watchdog.

PS: Ach ja die Library ist die von Gerhard, die von Jan lässt sich bei 
mir nur mit Fehlern compilieren bzw. bricht mit einer Fehlermeldung ab.

[Schorschi (Gast)]

Hallo zusammen,
habs gelöst...... mit allen Pins an PortB ging es mit Gerhard Lip 
sofort.

[Lötlackl *. (pappnase)]

Ich weiß, ich wühle hier ne Leiche raus, ist aber aus gegebenem Anlass.

Ich beziehe mich auf die Version, die ich auf github gefunden habe.
In der Datei "dogm-graphic.c" in Zeile 282 heißt es:

   #if ORIENTATION_UPSIDEDOWN = 0

Das wirft natürlich einen Fehler. Es sollte wohl lauten:

   #if ORIENTATION_UPSIDEDOWN == 0

mfg Lötlackl

[Jan M. (mueschel)]

Hallo Lötlackl,
das steht da tatsächlich seit 8 Jahren drin. Ist mir nie aufgefallen, 
weil ich nie ein 160-px-Display hatte und diesen Teil somit nie 
kompiliert habe.
Möchtest du das im git ändern oder soll ich das gerade machen?

[Lötlackl *. (pappnase)]

Jan M. schrieb:
> Möchtest du das im git ändern oder soll ich das gerade machen?

Mache Du das mal, ich habe bezüglich Github keine Ahnung (sollte ich 
vielleicht mal ändern).