Display ansteuern? Nichts funktioniert :(

[Alexander T. (xronin)]

Hallo zusammen,

ich versuche bereits seit zwei Tagen das Display zum laufen zu bekommen, 
aber nichts funktioniert. Ich könnte noch nicht einmal sagen, ob die 
Anzeige vllt. defekt ist.

So sieht meine Verbindung aus:

ATTiny44A ---- EADOGS102N-6
===========================
PA1 - CS0
PA2 - Reset
PA3 - CD
PA4 (USCK) - SCK
PA5 (MISO) -
PA6 (MOSI) - SDA

Das Display läuft mit 3,3V und wurde mit den angegebenen 3x 1µF 
Kondensatoren
angeschlossen (http://www.lcd-module.de/deu/pdf/grafik/dogs102-6.pdf, 
Seite 4)

Hier der Code zum initialisieren:

#define LCD_CS      1
#define LCD_RST     2
#define LCD_CD      3
#define SPI_SCK     4 
#define SPI_MISO    5        
#define SPI_MOSI    6  
 

void SPI_Init(void) 
{
  DDRA  = (1 << LCD_RST); 
  DDRA  = (1 << LCD_CD);
  DDRA  = (1 << SPI_MOSI);
  DDRA  = (1 << SPI_SCK);

  PORTA &= ~(1 << SPI_MISO); 
  PORTA = (1 << SPI_MISO); 

  USICR = (1 << USIWM0); //Three Wire Mode DO,DI,USCK
  USICR = (1 << USICLK);
  USICR = (1 << USITC);
  USICR = (1 << USICS1);
}

void SPI_Transmit(char cData)
{
  PORTA &= ~(1<<LCD_CS);
  USIDR = cData;
  while(!(USISR & (1<<USISIF)))
  ;
  PORTA |= (1<<LCD_CS);
}

void DISPLAY_Init(void)
{
  SPI_Transmit(0x40);
  SPI_Transmit(0xA1);
  SPI_Transmit(0xC0);
  SPI_Transmit(0xA4);
  SPI_Transmit(0xA6);
  SPI_Transmit(0xA2);
  SPI_Transmit(0x2F);
  SPI_Transmit(0x27);
  SPI_Transmit(0x81);
  SPI_Transmit(0x10);
  SPI_Transmit(0xFA);
  SPI_Transmit(0x90);
  SPI_Transmit(0xAF);
}

int main(void)
{
  SPI_Init();
 _delay_ms(50);

  DISPLAY_Init();
  _delay_ms(50);
}

Man sieht leider überhaupt nichts. Habe ich etwas vergessen?

Danke

[g457 (Gast)]

> Man sieht leider überhaupt nichts. Habe ich etwas vergessen?

∗hüstel∗ ja..

> DDRA  = (1 << LCD_RST);
        ^
> DDRA  = (1 << LCD_CD);
        ^
> DDRA  = (1 << SPI_MOSI);
        ^
..und noch viele andere mehr..

[Alexander T. (xronin)]

Das war nun leider nicht der Fehler :( Keine Änderung

[g457 (Gast)]

> Das war nun leider nicht der Fehler

..dann wars nicht ∗der∗ Fehler sondern ∗einer∗ (von vielen). Aber um 
nochmals darauf herumzureiten: was hast Du denn geändert an den 
markierten Stellen und wo noch überall? Oder anders gesagt: Wie sieht 
der Code jetzt aus?

[Alexander Thies (Gast)]

Aus dem = habe ich ein |= gemacht. Bei allen Zuweisungen der Bits. Die 
aussage, dass dort viele Fehler sind, hilft mir leider auch nicht ;-)

[Marcus W. (marcusaw)]

Die gesamte Routine kannst du in der Pfeife rauchen:

void SPI_Init(void) 
{
  DDRA  = (1 << LCD_RST); 
  DDRA  = (1 << LCD_CD);
  DDRA  = (1 << SPI_MOSI);
  DDRA  = (1 << SPI_SCK);

  PORTA &= ~(1 << SPI_MISO); 
  PORTA = (1 << SPI_MISO); 

  USICR = (1 << USIWM0); //Three Wire Mode DO,DI,USCK
  USICR = (1 << USICLK);
  USICR = (1 << USITC);
  USICR = (1 << USICS1);
}

Wenn hier das Timing nicht stimmt, macht dein Display garnix.

[... (Gast)]

Seit wann ist das Nichtfunktionieren sinnlosen redundanten Codes 
timingabhängig? :-O

[T.roll (Gast)]

>  DDRA  = (1 << LCD_CD);
>Aus dem = habe ich ein |= gemacht.

Pin CD möchte welchen Level für Kommandos? Richtig! Low. Du schaltest 
ihn aber auf High für Daten.

[Karl H. (kbuchegg)]

T.roll schrieb:
>>  DDRA  = (1 << LCD_CD);
>>Aus dem = habe ich ein |= gemacht.
>
> Pin CD möchte welchen Level für Kommandos? Richtig! Low. Du schaltest
> ihn aber auf High für Daten.

eigentlich nicht.
An dieser Stelle wird erst mal nur der Pin auf Ausgang gestellt.

Aber so unrecht hast du nicht, denn in

void SPI_Transmit(char cData)
{
  PORTA &= ~(1<<LCD_CS);
...

wird fleissig an einem Pin LCD_CS rumgeschraubt. Der allerdings ist 
wiederrum nicht auf Ausgang gestellt.

Ach das hat doch keinen Sinn.
Zeig deinen kompletten Code, so wie er jetzt ist. Das muss doch alles 
kontrolliert werden. Da steckt doch noch jede Menge anderes Zeugs 
drinnen. Immer dieses posten von Code-Fitzelchen. Und die Helfer dürfen 
sich dann aus 3 Posts und jeder Menge Phantasie die Einzelteile zusammen 
suchen, wie der Code wohl jetzt aussehen könnte. Du bist der der Hilfe 
will. Also mache es anderen leicht dir zu helfen.

[T.roll (Gast)]

Karl Heinz schrieb:
> eigentlich nicht.
> An dieser Stelle wird erst mal nur der Pin auf Ausgang gestellt.

Da habe ich DDRA mit PORTA vertauscht. Es ist zu spät :)

[spess53 (Gast)]

Hi

>Aus dem = habe ich ein |= gemacht. Bei allen Zuweisungen der Bits. Die
>aussage, dass dort viele Fehler sind, hilft mir leider auch nicht ;-)

Dann sieh dir das Beispiel vom EA mal an:

http://www.lcd-module.de/fileadmin/downloads/development%20service/DOGS102_UC1701/Init_and_basic_functions_with_EA_DOGS102_MEGA168.zip

MfG Spess

[Sascha E. (baracuss)]

Das Größte Problem ist das es überhaupt keine Warte zeiten zwischen den 
einzelnen schritten gibt. Das heißt das die Pins ständig geändert werden 
aber der Controller des Displays es ganricht mitbekommt.

Du musst aufjedenfall die richtigen Timmings einstellen. Und wie im 
Datenblatt des Displays steht findest du die Timmings im Dattenblatt des 
Diplay Controllers auf Seite 41.

http://www.lcd-module.de/eng/pdf/zubehoer/uc1701.pdf

Stell die Zeiten ruhig ein bisschen länger ein das ist besser als wenn 
sie zu kurtz sind.

[Alexander T. (xronin)]

Erstmal danke für die vielen Antworten.

Mit einem Teil des Beispielcodes von EADOGS konnte ich das Display zum 
blinken bringen. Wenn ich allerdings den gesamten Code ausführe erhalte 
ich einen Overflow im Data Memory??? Ich habe die beiden mitgelieferten 
Fonts gelöscht und sonst auch keine variablem mit progmem 
gekennzeichnet. Woran kann das liegen?

[Karl H. (kbuchegg)]

Daran, dass du ums verrecken deinen Code nicht herzeigen willst.

Ist das wirklich so schwer zu verstehen?
Wir sind doch hier keine Hellseher!
Du hast also ein Programm geschrieben oder modifiziert. UNd das stürzt 
ab. Und wir sollen jetzt irgendwie wissen, was du da für ein Problem 
erzeugt hast.
Wie soll das gehen? Sollen wir Karten legen? Astrologen befragen? Oder 
doch vielleicht die Antwort channeln?

[Uwe (de0508)]

Hallo Alexander,

gleich kommen die Antworten, alles einzustellen was da ist, Bilder, der 
aktuelle Schaltplan und der gesamte CODE.

So wird das nichts, und Karl-Heinz hätte dir sicherlich gerne bis zum 
Erfolg geholfen.

Du musst immer bedenken, wir sitzen nicht für der Hardware, noch sehen 
wir den gesamten Code oder kennen die erwarteten und unerwarteten 
Reaktionen des Programms.

Ein Helfer, kann nur ein Helfer sein, wenn er/sie alles von dir erfährt, 
auf Nachfragen musst Du dann gewissenhaft und vollständig antworten.

Sprichwort:
"So wir ein Schuh daraus!"

[Patrick (Gast)]

Karl Heinz schrieb:
> Ist das wirklich so schwer zu verstehen?
> Wir sind doch hier keine Hellseher!
> Sollen wir Karten legen? Astrologen befragen? Oder
> doch vielleicht die Antwort channeln?

Ruhig Blut, Karl Heinz. Deine Antworten sind immer von herausragender 
Qualität, und - ich weiß nicht, wie Du das machst - Du schaffst es 
nahezu immer, erstaunlich lange die Ruhe zu bewahren. Lass Dich daher 
nicht ärgern - auch ich weiß, wie (sehr) frustrierend es ist, zu 
versuchen, Anfängern irgendetwas erklären zu wollen, wenn diese eine 
bestimmte, vorgefasste Meinung haben und glauben, diese sei korrekt und 
nur so ginge es... Da hilft leider nur das Konzept des "Lernens durch 
Schmerz" (ein in der Erwachsenenerziehung durchaus anerkanntes 
Instrument) - soll heißen, entweder gar nicht antworten oder die 
Qualität der Antwort an die Frage anpassen - soll heißen: Genauso 
schwammig und "mysteriös" antworten, wie die Frage formuliert ist...

Alexander Thies schrieb:
> Overflow im Data Memory
> keine variablem mit progmem

Die .data-Section liegt im RAM und nicht im FLASH, daher hilft Dir 
progmem hier wenig (sofern es das ist, was Du meinst)...

[Alexander T. (xronin)]

Entschuldigt bitte! Ich freue mich ja über jede Hilfe. Der Code sieht 
jetzt nur genauso aus, wie der Beispielcode aus dem EADogs Archiv weiter 
oben. Die Einzige Ausnahme sind die Änderungen der jeweiligen Pins zur 
Anpassung an meinen Versuchsaufbau. Ich poste es aber gerne trotzdem.


main.c
===========================

#include "main.h"

//////////////////////////////////////////////////////////////////////////
///////  Sleep function
//////////////////////////////////////////////////////////////////////////
void Sleep(unsigned int ms)
{
  for(; ms>0; ms--) 
  {
    _delay_ms(1);
  }
}

//////////////////////////////////////////////////////////////////////////
///////  Main program routine
//////////////////////////////////////////////////////////////////////////
int main(void)
{
  spi_init() ;
    sei();

   lcd_init();
   _delay_ms(1000);
  
  lcd_string(0,5,"EA DOGS102-6!", ptr_font_6x8, INVERS); //Printing a line in big fonts, inverted
  lcd_string(0,5 + pgm_read_byte(ptr_font_8x16 + 5), "this is next line", ptr_font_6x8, DELETE); //Printing next line small fonts, normal

    while(1)
    {

    }
}

main.h
============

#ifndef _MAIN_H
#define _MAIN_H

#define XPIXEL 102
#define YPIXEL 64
#define XMAX XPIXEL-1
#define YMAX YPIXEL-1

//Meine pins
#define LCD_CS      1
#define LCD_RST     2
#define LCD_CD      3
#define SPI_SCK     4
#define SPI_MISO    5
#define SPI_MOSI    6

#include <stdint.h>
#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>

#include "lcd.h"
#include "spi.h"
#include "font_6x8.h"
#include "font_8x16.h"

#ifndef F_CPU
#define F_CPU 1000000UL
#endif

#include <util/delay.h>


#endif

spi.c
============

#include "main.h"

void spi_init(void)
{
        volatile uint8_t IOReg;

    // set PB3(MOSI), PB5(SCK), PB2(SS) CS, PB1(CD) as output
        DDRA    |= (1<<SPI_MOSI)|(1<<SPI_SCK)|(1<<LCD_CS)|(1<<LCD_CD);

    // enable SPI in Master Mode with SCK = CK/4, CPHA = 1
        //USICR    = (1<<SPE)|(1<<MSTR)|(1<<CPHA)|(1<<CPOL);
    USICR |= (1 << USIWM0); //Three Wire Mode DO,DI,USCK
    USICR |= (1 << USICLK);
    USICR |= (1 << USITC);
    USICR |= (1 << USICS1);
  
        IOReg   = USISR;         //clear SPIF bit in SPSR
        IOReg   = USIDR;      //clear receive buffer
    PORTB |= (1<<LCD_CD);    //SS high
    PORTB |= (1<<LCD_CD);    //CD high
}

uint8_t spi_byte (uint8_t data)
{

  USIDR = data; //send data
  while (!(USISR & (1<<USISIF)));    // wait until byte is sent and received

  return USIDR; //return received data (not used with EA DOGS102-6,
         //but you have to read out, because ATMega needs it
}

spi.h
============

#ifndef _SPI_H
#define _SPI_H

//----------------- Functions ------------
void spi_init(void);
uint8_t spi_byte (uint8_t data);


#endif

lcd.c (rest wie im archiv)
============

#include "main.h"

unsigned char lcd_buffer[XPIXEL][YPIXEL/8];  //Buffer to store display data. The buffer organization is equal to
                       // the one of the display


void lcd_init(void)
{
  DDRA |= (1<<LCD_RST); //Set display reset as output

  PORTA|=(1<<LCD_RST);  //Set display reset to high -> LCD is running now

  //Initialize bottom view 3.3V (booster on) 8Bit SPI
  lcd_send_command(0x40); //Startline 0
  lcd_send_command(0xA1); //SEG reverse
  lcd_send_command(0xC0); //Set COM direction (COM0-COM63)
  lcd_send_command(0xA4); //Set all Pixel to on
  lcd_send_command(0xA6); //Display inverse off
  lcd_send_command(0xA2); //Set bias 1/9
  lcd_send_command(0x2F); //Booster, regulator, follower on
  lcd_send_command(0x27); //Set contrast
  lcd_send_command(0x81); //Set contrast
  lcd_send_command(0x10); //Set contrast
  lcd_send_command(0xFA); //Temperature compensation
  lcd_send_command(0x90); //Temperature compensation
  lcd_send_command(0xAF); //Display on

  lcd_clear_all(); //Clear display and set display buffer to 0

}


void lcd_send(uint8_t data, uint8_t cd)
{
  PORTA&=~(1<<LCD_CS);      //Slave select (DCS to gnd)
  if (cd == 0)
    PORTA&=~(1<<LCD_CD);  //Send command (DCD to 0)
  else
    PORTA|=(1<<LCD_CD);  //Send data (DCD to 1)

  spi_byte(data);      //Send data

}

lcd.h
============

#ifndef _LCD_H
#define _LCD_H

//----------------- Definitions -----------
#define DELETE 0
#define ADD  1
#define INVERS 2

//-------------- Global varibales ----------
extern unsigned char lcd_buffer[XPIXEL][YPIXEL/8];

//--------------- Macrofuncitons ----------
#define lcd_send_command(data) lcd_send(data, 0)
#define lcd_send_data(data) lcd_send(data, 1)
#define lcd_clear_all() lcd_clear(0,0,XPIXEL-1,YPIXEL-1)
#define lcd_fill_all() lcd_fill(0,0,XPIXEL-1,YPIXEL-1)

//----------------- Functions ------------
void lcd_init(void);
void lcd_send(uint8_t data, uint8_t cd);
void lcd_clear(uint8_t xs, uint8_t ys, uint8_t xe, uint8_t ye);
void lcd_fill(uint8_t xs, uint8_t ys, uint8_t xe, uint8_t ye);
void lcd_line(uint8_t xs, uint8_t ys, uint8_t xe, uint8_t ye);
void lcd_rect(uint8_t xs, uint8_t ys, uint8_t xe, uint8_t ye);
void lcd_char(uint8_t x, uint8_t y, uint8_t data, uint8_t *font, uint8_t linkmode);
void lcd_string(uint8_t x, uint8_t y, char *data, uint8_t *font, uint8_t linkmode );


#endif
//----------------- EOF lcd.h ------------

[Uwe (de0508)]

Hi,

beim schnellen durchblättern entdeckt, ich kommentiere es nicht weiter:

 PORTB |= (1<<LCD_CD);    //SS high
    PORTB |= (1<<LCD_CD);    //CD high

Noch eine Frage, gibt es dazu ein Makefile ?

Oder anders gefragt: wie werden die Dateien übersetzt und gelinkt ?

[Uwe (de0508)]

Hallo,

das könnte noch interessant sein für das Zeitverhalten:

https://code.google.com/p/u8glib/issues/detail?id=201

[Alexander T. (xronin)]

Schaue ich mir direkt mal an! Das Problem ist gerade immer noch die 
Fehlermeldung mit dem Memory Overflow.

Program Memory Usage : 7076 bytes   172,8 % Full (Memory Overflow)
Data Memory Usage : 848 bytes   331,3 % Full (Memory Overflow)

[Karl H. (kbuchegg)]

Alexander Thies schrieb:
> Schaue ich mir direkt mal an! Das Problem ist gerade immer noch die
> Fehlermeldung mit dem Memory Overflow.
>
>

> Program Memory Usage : 7076 bytes   172,8 % Full (Memory Overflow)
> Data Memory Usage : 848 bytes   331,3 % Full (Memory Overflow)
>

Das Teil ist schlicht und ergreifend zu groß für einen Tiny44.
4K Flash - damit kann man schon was anfangen.
Aber 256 Bytes SRAM íst nun mal nicht viel.

[Karl H. (kbuchegg)]

#include "font_6x8.h"
#include "font_8x16.h"

beide Fonts im Flash.
Die verbrauchen schon jede Menge Platz im Flash.

Die könnte man noch leswerden.
Kritischer sind aber die 256 Byte SRAM.
Da heisst es sparsam mit globalen Variablen umgehen, bzw. alle Strings 
ins Flash verbannen (nachdem es von einem Font leergeräumt wurde)

[Karl H. (kbuchegg)]

Und da, in lcd.h

unsigned char lcd_buffer[XPIXEL][YPIXEL/8];

ist der andere Speicherfresser.
Den wirst du aber so leicht nicht los.

[Alexander T. (xronin)]

Wenn ich die Fonts weglasse sieht es wie folgt aus:

Program Memory Usage : 608 bytes   14,8 % Full
Data Memory Usage : 816 bytes   318,8 % Full  (Memory Overflow)

Es scheint als wäre der Display Buffer zu groß

unsigned char lcd_buffer[XPIXEL][YPIXEL/8];

Das sind genau die 816 Byte :(

[Uwe (de0508)]

Hallo Alexander,

wie so "scheint" das nur so ?

Dass kannst Du doch ausrechnen !

[Alexander T. (xronin)]

Uwe S. schrieb:
> Hallo Alexander,
>
> wie so "scheint" das nur so ?
>
> Dass kannst Du doch ausrechnen !

Hab ich doch. Es sind 816 Byte.

[Karl H. (kbuchegg)]

An alle die dieses LCD kennen.
Seh ich das richtig, dass laut Datenblatt
http://www.lcd-module.de/deu/pdf/grafik/dogs102-6.pdf
es kein "Read Data Byte" Kommando gibt?


Denn sorry, Alexander.
In diesem Fall ist dieses LCD im Zusammenhang mit deinem Tiny44 
gestorben.
Wenn es ein derartiges Kommando gäbe, dann könnte man auf Kosten der 
Laufzeit noch etwas retten. Aber ohne dieses Kommandos bleibt dir nun 
mal nichts anderes übrig, als im Speicher eine binäre Repräsentierung 
der Pixel vorzuhalten, um korrekt zeichnen zu können.
Wer Grafik mit einem unintelligentem DIsplay machen will, braucht nun 
mal in erster Linie eines: Speicher, Speicher, Speicher.
Und genau den hat dein Tiny44 nicht.

[Alexander T. (xronin)]

Ok das ist natürlich scheiße...
Also heißt das für mich...anderer Controller oder besser anderes 
Display?

[Karl H. (kbuchegg)]

In dem Fall würde ich erst mal auf anderen Controller plädieren.

Nichts gegen den Tiny44. Aber mit 256 Bytes SRAM gewinnt man nun mal 
keinen Blumentopf.
Diese Speichermenge reicht, wenn man ein fertiges Projekt hat, welches 
diese Menge oder weniger benötigt und man sich fragt, welchen µC man 
jetzt in der Massenproduktion einsetzt. Dann ist der Tiny44 ein 
Kandidat.

Aber als allgemeines Entwicklungssystem ist das nun mal zu wenig. Ein 
bisschen 'rühren' muss man sich schon können, ohne gleich an allen Ecken 
und Enden an die Limits zu stossen.

[Alexander T. (xronin)]

Als würde ein ATMega für meine Zwecke besser sein? Welchen würdet ihr 
dann empfehlen. 1024Byte EEPROM sind für dieses Display dann wohl zu 
schmal bemessen...

[Karl H. (kbuchegg)]

Alexander Thies schrieb:
> Als würde ein ATMega für meine Zwecke besser sein? Welchen würdet ihr
> dann empfehlen. 1024Byte EEPROM sind für dieses Display dann wohl zu
> schmal bemessen...

SRAM, guter Mann.
Du brauchst SRAM

Such dir einen aus. Aber einen von den moderneren. Nicht gerade die alte 
Gurke Mega8, auch wenn die überall in den Tutorien vorkommt.

[MWS (Gast)]

Karl Heinz schrieb:
> In diesem Fall ist dieses LCD im Zusammenhang mit deinem Tiny44
> gestorben.

Warum? Das größere SRam benötigt er nur, wenn er Pixel einzeln setzen 
und löschen will. Für schlichte (überschreibende) Grafikausgaben oder 
Text würd' der Tiny44 noch reichen.

Vielleicht sollte man hier mit dem Vorhandenen erstmal ein 
Erfolgserlebnis produzieren, statt wegen anderer Gründe die Flinte ins's 
Korn zu werfen.

Ansteuerbar ist das Display (mit eingeschränkten Features), lediglich 
baut der TE zu viele Fehler, wozu auch die Verwendung nicht vorhandenem 
SRams gehört. Deswegen geht's nicht. Fehler wird er jedoch auf einem 
XMega genauso bauen.

Soll er sich 'nen anderen Code irgendwoher kopieren, denn selbst 
geschrieben ist das wohl nicht. Wer das selbst geschrieben und somit 
verstanden hätte, wäre frühzeitig zum Schluss gekommen, dass 816 Bytes 
nicht in 256 Bytes rein passen. Und auch dass EEProm zwar zur 
Bereithaltung von Bitmaps verwendbar ist, aber nicht als Bildspeicher 
zur Pixeladressierung taugt.

Da mangelt's einfach an den Grundlagen, ein größerer µC macht lediglich 
bestimmten copy/paste Code direkt verwendbar, verstehen wird er deswegen 
auch nicht mehr.

[Uwe (de0508)]

Hallo Alexander,

So ein ATmega644 hat 4kByte SRAM:
http://www.atmel.com/devices/atmega644.aspx?tab=parameters

ein ATmega328 kann mit 2kByte SRAM dienen:
http://www.atmel.com/devices/atmega328.aspx?tab=parameters

Daneben gibt es die verschiedensten Atmel AVR µC.

Interessant kann auch der atmega32u4 sein:
https://www.ehajo.de/themes/kategorie/detail.php?artikelid=152

[Alexander T. (xronin)]

Danke für eure Hilfe! Leider läuft das Display immer noch nicht.
Ich habe jetzt schon diverse Szenarien durchprobiert und folgendes 
notiert.
Im Anhang sind noch ein paar Bilder.

Display mit 3,23V (über Spannungsteiler):

                 Nach Start              Nach Knopfdruck (Erreichen BP)
========================================================================
Debug Modus:     Erst 3 schwarze Streifen,| Wieder weiß mit 3 Streifen
                 dann langsam komplett      dann langsam wieder schwarz
                 schwarz

Normaler Start:  Weißer Bildschirm          Weißer Bildschirm






Display mit 3,35V (über Spannungswandler):

                 Nach Start              Nach Knopfdruck (Erreichen BP)
========================================================================
Debug Modus:     Erst schwarz dann langsam,| Erst weiß, dann wieder wie
                 verblassend                 links

Normaler Start:  Weißer Bildschirm          Weißer Bildschirm


Hier einmal die Anschlüsse des Displays:

15 VLCD: über 1µF Elko an GND
16 VB1- über 1µF Elko an VB1+
17 VB0- über 1µF Elko an VB0+
18 VB0+ s.o.
19 VB1+ s.o.
20 VSS an 3,3V
21 VSS an 3,3V
22 VDD2/3 GND
23 VDD1 GND
24 SDA/MOSI an PA5/DO
25 SCK an PA4/USCK
26 CD an PA3
27 RST an PA2
28 CS0 an PA1

[spess53 (Gast)]

Hi

>15 VLCD: über 1µF Elko an GND
>16 VB1- über 1µF Elko an VB1+
>17 VB0- über 1µF Elko an VB0+

Die Elkos solltest du durch Keramikkondensatoren ersetzen.

Welche Spannung misst du an VLCD?

MfG Spess

[spess53 (Gast)]

Hi

>        IOReg   = USISR;         //clear SPIF bit in SPSR

Das löscht kein Interruptflag. Dazu müsste ein

          USISR = IOReg;

folgen.

MfG Spess

[Martin H. (marrtn)]

Alexander Thies schrieb:
> Display mit 3,23V (über Spannungsteiler):

Woher stammen die 3,23 V? Ausgerechnet oder gemessen (mit oder ohne 
Display)?
Ein Spannungsteiler alleine taugt nur zur Stromversorgung, wenn man 
wirklich weiß, was man tut. Wenn Dein Display keine konstante 
Stromaufnahme hat, wackeln Deine 3,23V lustig umher...

[Alexander T. (xronin)]

> Welche Spannung misst du an VLCD?
>
> MfG Spess

0V messe ich, aber das ist ja auch nicht verwunderlich. Der Elko hängt 
doch in Reihe hinter VLCD an GND.



> Woher stammen die 3,23 V? Ausgerechnet oder gemessen (mit oder ohne
> Display)?
> Ein Spannungsteiler alleine taugt nur zur Stromversorgung, wenn man
> wirklich weiß, was man tut. Wenn Dein Display keine konstante
> Stromaufnahme hat, wackeln Deine 3,23V lustig umher...

Wenn ich den Spannungswandler benutze liegen über dem Display die 3,3V 
an.

Wenn ich es an den Spannungsteiler (3,23V) anschließe, kann ich über dem 
Display noch 1,04V an. Der Spannungsteiler war nur zum Experimentieren 
da. Ich hatte die Vermutung, dass vllt. der DCDC Spannungswandler defekt 
ist. Das scheint aber nicht der Fall zu sein.

[spess53 (Gast)]

Hi

>0V messe ich, aber das ist ja auch nicht verwunderlich. Der Elko hängt
>doch in Reihe hinter VLCD an GND.

Selbstverständlich ist das verwunderlich. VLCD ist der Ausgang für die 
LCD-Spannung (>VCC). Der Kondensator dort dient der Glättung. Bei einem 
ordentlich initialisiertem Display sollten dort 5..10V anliegen.

MfG Spess

[Alexander T. (xronin)]

Ich habe gerade nochmal nachgemessen. Zwischen Vlcd und gnd sind es 
jetzt 1,4V?? Die Initialisierung des Displays habe ich wie im Handbuch 
beschrieben gemacht.

[spess53 (Gast)]

Hi

>Ich habe gerade nochmal nachgemessen. Zwischen Vlcd und gnd sind es
>jetzt 1,4V??

Bei meinem USB-Testboard liegen bei einen funktionierenden DOGS102 9,3V 
an VLCD.

Entweder klappt deine Initialisierung nicht oder es liegt an deinen 
Kondensatoren. Ich setze generell Keramik-Cs ein und hatte bisher nie 
Probleme. Ist auch eine Empfehlung von EA.

MfG Spess

[Alexander T. (xronin)]

Aber kann das wirklich an den falschen Kondensatoren liegen, ist es 
nicht egal ob 1uF mit Elko oder Kerko? Ich werde mir die kerkos dann 
bestellen und hoffe, dass es besser wird :-)