Atmega8 läuft nur mit internen Quarz, nicht aber mit externen

[Stefan P (Gast)]

hey leutz,

ich hab schon das ganze forum durchforstet aber leider keine Lösung für 
mein Prob gefunden.

Ich hab auf nen Breedboard eine Schaltung mit nem Atmega8 aufgebaut, die 
Temperaturen via One Wire einlesen und auf nem (SED1520) Display 
ausgeben soll.

Mit internen Oszillator funktioniert die Schaltung zumindest so weit das 
dass Display seine Ausgaben macht.
Wenn ich jetzt einen externen Quartz anschließe (3,579 Mhz) funktioniert 
das Programm nicht mehr.

Ich kann aber dennoch die Fuses auslesen, und das Programm flashen.
Der Quarz schwingt auch, ich konnte den Sinus auf dem Oszi darstellen 
und auf die Frequenz zurückrechnen.

Ja, die Fuses sind richtig gesetzt, CKSEL 1111 SUT 11, rest hab ich 
nicht verändert.

Quarz ist gleich direkt an den Mik. Anschlüssen dran, mit 2x 22pf gegen 
masse.

Aus anderen Beiträgen hatten User noch den Tipp AVCC mit anzuschließen, 
das hatt ich dann auch nachgeholt, änderte aber nichts.

Könnte sein , dass der EL Inverter für das Display, irgenwie 
Interferenzen macht ?

Jemand eine Idee ?


Grüße

[Εrnst B. (ernst)]

Du hast dein Programm schon neu kompiliert, mit F_CPU / F_OSC definiert 
auf 3579000 ?

2x 100nF vorhanden (VCC->GND und AVCC->GND)?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> funktioniert das Programm nicht mehr.
Was funktioniert nicht mehr?

Hast du schon mal das Hello-World (blinkende LED) ausprobiert?


BTW:
> Breedboard
Breadboard (mit A)
> Atmega8 läuft nur mit internen Quarz,
Der hat keinen internen Quarz

[Stefan P (Gast)]

das Programm macht nur eine einfache Ausgabe z.B. "Test", ich hab schon 
alles unnötige rausgelassen.

hmm, jaja , ich meinte ja den internen oszillator.

> Hast du schon mal das Hello-World (blinkende LED) ausprobiert?
nein, ist aber auch nen Versuch wert

> Du hast dein Programm schon neu kompiliert, mit F_CPU / F_OSC definiert
auf 3579000 ?

Ja, ich hab das Makfile entsprechend angepasst. Ist aber unkritisch, 
wenn ich die 3,579 Mhz eingestellt habe und die externe Anregung 
ausschalte geht das Programm immer noch. Aber wie gesagt sobald die 
Fuses auf extern gestellt werden geht das Programm nicht mehr. Aber es 
lässt sich ohne Probleme aufspielen und die Fuses kann ich auch 
umstellen, ergo muss die externe Anregung funktionieren.

> 2x 100nF vorhanden (VCC->GND und AVCC->GND)?

nein , hab ich nicht, werde ich heut nachholen, sollte das solche 
Auswirklungen haben  ??

danke für die tipps

[Stefan P (Gast)]

nur nochmal vorwerg, ich hab die 22pf schon getauscht, den Quarz auch 
des öfteren, ja sogar den Mega8....

[Gast (Gast)]

Wenn der Quarz schwingt und du ihn bei eingestelltem Quarz per ISP 
schreiben und lesen kannst dann läuft der Quarz wie er soll. Also kein 
QUarzproblem, eher die restliche Hardware oder deine Software macht 
nicht das was sie soll.

[Karl H. (kbuchegg)]

Stefan P schrieb:

>> Du hast dein Programm schon neu kompiliert, mit F_CPU / F_OSC definiert
> auf 3579000 ?
>
> Ja, ich hab das Makfile entsprechend angepasst. Ist aber unkritisch,
> wenn ich die 3,579 Mhz eingestellt habe und die externe Anregung
> ausschalte geht das Programm immer noch.

Ich wünschte, Hilfesuchende würden sich in diesem Punkt weniger 
kryptisch ausdrücken.

Checkliste zum Abhaken
* Quarz (2,579 Mhz) ist angeschlossen, die beiden Kondensatoren (22pF) 
sind am QUarz drann
* Fueses sind auf Crystal gestellt
* Dem Programm wurde auch mitgeteilt (per #define F_CPU oder Einstellung 
im AVR-Studio), dass es jetzt mit höherer Taktfrequenz abgearbeitet wird

> Aber wie gesagt sobald die
> Fuses auf extern gestellt werden geht das Programm nicht mehr.

Lass mal bei deiner 3.579 Mhz Einstellung eine LED blinken. 1 Sekunde 
ein, 1 Sekunde aus.
Wenn dein Programm immer noch auf 1Mhz läuft, dann dauert das Blinken 3 
Sekunden statt 1. Den Unterschied sieht man auch mit freiem Auge.

> Aber es
> lässt sich ohne Probleme aufspielen und die Fuses kann ich auch
> umstellen, ergo muss die externe Anregung funktionieren.

Die Schlussfoglerung ist so nicht so schlecht. Hat nur einen Haken. Wenn 
dein µC immer noch mit internem Oszi läuft, lässt er sich auch noch 
Programmieren.

[Stefan P (Gast)]

> Die Schlussfoglerung ist so nicht so schlecht. Hat nur einen Haken. Wenn
> dein µC immer noch mit internem Oszi läuft, lässt er sich auch noch
> Programmieren.

Also der läuft schon mit den externen 3,579 Mhz, denn wenn ich jetzt den 
Quarz entferne kann ich weder Fuses noch das Programm übertragen.


Mach ich den Quarz wieder ran, kann ich die Fuses wieder umstellen, 
stell ich dann auf Intern, macht das Display sofort ne Ausgabe.


> Ich wünschte, Hilfesuchende würden sich in diesem Punkt weniger
> kryptisch ausdrücken.

Nochmal, wenn ich in meine Programm die F_CPU von 1 Mhz auf 3,56 Mhz 
stelle aber trotzdem den internen Oszi von 1 Mhz verwende funktioniert 
die Ausgabe immer noch, dass meinte ich mit "unkritisch"

[Oliver (Gast)]

>Ja, die Fuses sind richtig gesetzt, CKSEL 1111 SUT 11,

Wenn du die Fuses so setzen und erfolgreich mit diesen Werten wieder 
auslesen kannst, läuft der Prozessor mit dem externen Quarz.

>Könnte sein , dass der EL Inverter für das Display, irgenwie
>Interferenzen macht ?

Nichts ist unmöglich, aber zu 99% ist das ein Softwareproblem (oder der 
Aufruck auf deinem Quarz stimmt nicht)

Daher: Zeig doch mal deinen Code.

Oliver

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Daher: Zeig doch mal deinen Code.
Sowas in der Richtung wollte ich mit meiner Frage erreichen:
>>> funktioniert das Programm nicht mehr.
>> Was funktioniert nicht mehr?

[Stefan P (Gast)]

im prinzip hab ich das programm auf die universal C bib von

http://en.radzio.dxp.pl/sed1520/

reduziert. Ich habs jetzt leider nicht parat , bin in der Arbeit.

Compiler ist der avr-gcc unter windows. Fuses hab ich mit avrdude oder 
alt. mit PonyProg geflasht, wobei ich mit PonyProg schlechte Erfahrungen 
gemacht hab, der hat mir den flash einfach Abgebrochen und der 
Controller war danach kaputt.

Ich werd dann heute abend den El-Inverter abklemmen und die 2 
Koppelkondestoren reinbauen. Dann geb ich Feedback.

[Stefan P (Gast)]

>> Was funktioniert nicht mehr?

die Ausgabe auf dem Display geht nicht mehr! Das ist ja die einzige 
Funktion des Programmes nachdem ich alles andere rausgeschmissen habe.

Also es müsste "Test" auf dem Display stehen. Das tuts wie gesagt nur 
mit dem internen oszi

[Oliver (Gast)]

>Nochmal, wenn ich in meine Programm die F_CPU von 1 Mhz auf 3,56 Mhz
>stelle aber trotzdem den internen Oszi von 1 Mhz verwende funktioniert
>die Ausgabe immer noch, dass meinte ich mit "unkritisch"

Das ist ein logischer und auch praktischer Trugschluß. Das es in die 
eine Richtung funktioniert, beweist nicht, das es auch andersrum gehen 
muß. Und ganz praktisch ist bei der Ansteuerung von LCD's ein zu 
langsames timing gar kein Problem, ein zu schnelles dagegen schon.

Oliver

[Stefan P (Gast)]

anderst herum hab ichs gar net gemacht, ich hab schon immer ordentlich 
die F_CPU auf die neue Frequenz eingestellt.

[Stefan P (Gast)]

also ich hab das BlinkProgramm getestet. Es läuft mit dem 3 Mhz quarz 
super, wenn ich F_CPU auf 1 Mhz stelle und die delay funktion auf 1 
Sekunde stelle, dann blinkt die LED ca. 3 mal pro Sekunde.

dann muss der Fehler irgendwo im Quelltext stecken,... hier:

#include <avr/io.h>
#include <util/delay.h>
#define SCREEN_WIDTH  122

#define SED1520_DATA_PORT   PORTD
#define SED1520_DATA_DDR   DDRD
#define SED1520_DATA_PIN   PIND

#define SED1520_CONTROL_PORT   PORTC
#define SED1520_CONTROL_DDR   DDRC

#define SED1520_A0 (1 << 0)
#define SED1520_E1 (1 << 2)
#define SED1520_E2 (1 << 1)
#define SED1520_RW (1 << 1)
#define SED1520_RES (1 << 3)
#define F_CPU 3579000UL

extern unsigned char lcd_x, lcd_y;
//-------------------------------------------------------------------------------------------------
//
//-------------------------------------------------------------------------------------------------

void GLCD_InitPorts(void)
{
SED1520_DATA_DDR = 0xFF;

SED1520_CONTROL_DDR |= (SED1520_E2 | SED1520_E1  | SED1520_A0 | SED1520_RES);
DDRB |= (SED1520_RW);
_delay_ms(10);
SED1520_CONTROL_PORT &= ~SED1520_RES;
_delay_ms(100);
SED1520_CONTROL_PORT |= SED1520_RES;  // Reset liegt üblicherweise auf H


}
//-------------------------------------------------------------------------------------------------
//
//-------------------------------------------------------------------------------------------------
void GLCD_WaitForStatus(unsigned char status, unsigned char controller)
{
char tmp;
SED1520_CONTROL_PORT &= ~SED1520_A0; 
PORTB |= SED1520_RW; 
SED1520_DATA_DDR = 0x00; 
do
  {
  if(controller == 0) 
    {
  SED1520_CONTROL_PORT |= SED1520_E1; 
  asm("nop");asm("nop"); 
  tmp = SED1520_DATA_PIN; 
  SED1520_CONTROL_PORT &= ~SED1520_E1; 
  } 
  else 
    {
  SED1520_CONTROL_PORT |= SED1520_E2; 
  asm("nop");asm("nop"); 
  tmp = SED1520_DATA_PIN; 
  SED1520_CONTROL_PORT &= ~SED1520_E2; 
  }
  }while(tmp & status);
SED1520_DATA_DDR = 0xFF; 
}
//-------------------------------------------------------------------------------------------------
// Write command
//-------------------------------------------------------------------------------------------------
void GLCD_WriteCommand(unsigned char commandToWrite,unsigned char ctrl)
{
GLCD_WaitForStatus(0x80, ctrl);

SED1520_CONTROL_PORT &= ~SED1520_A0;
PORTB &= ~SED1520_RW;

SED1520_DATA_PORT = commandToWrite;

if(ctrl)
  {
  SED1520_CONTROL_PORT |= SED1520_E2;
  asm("nop");asm("nop");
  SED1520_CONTROL_PORT &= ~SED1520_E2;
  }
else
  {
  SED1520_CONTROL_PORT |= SED1520_E1;
  asm("nop");asm("nop");
  SED1520_CONTROL_PORT &= ~SED1520_E1;
  }
}
//-------------------------------------------------------------------------------------------------
// Write data
//-------------------------------------------------------------------------------------------------
void GLCD_WriteData(unsigned char dataToWrite)
{
GLCD_WaitForStatus(0x80, 0);
GLCD_WaitForStatus(0x80, 1);
SED1520_CONTROL_PORT |= SED1520_A0; // A0 auf 1, weil Daten
PORTB &= ~SED1520_RW; // W auf 0 weil schreiben
SED1520_DATA_PORT = dataToWrite; 
if(lcd_x < 61) 
  {
  SED1520_CONTROL_PORT |= SED1520_E1;
  asm("nop");asm("nop");
  SED1520_CONTROL_PORT &= ~SED1520_E1;
  }
else
  {
  SED1520_CONTROL_PORT |= SED1520_E2;
  asm("nop");asm("nop");
  SED1520_CONTROL_PORT &= ~SED1520_E2;
  }
lcd_x++;
if(lcd_x >= SCREEN_WIDTH)
  lcd_x = 0;
}
//-------------------------------------------------------------------------------------------------
// Read data
//-------------------------------------------------------------------------------------------------
unsigned char GLCD_ReadData(void)
{
unsigned char tmp;

GLCD_WaitForStatus(0x80, 0); 
GLCD_WaitForStatus(0x80, 1); 
SED1520_CONTROL_PORT |= SED1520_A0; 
PORTB |= SED1520_RW; 
SED1520_DATA_DDR = 0x00; 
SED1520_DATA_PORT = 0xFF;
if(lcd_x < 61)
    {
    SED1520_CONTROL_PORT |= SED1520_E1;
    asm("nop");asm("nop");
    SED1520_CONTROL_PORT &= ~SED1520_E1;
  asm("nop");asm("nop");
  SED1520_CONTROL_PORT |= SED1520_E1; 
  asm("nop");asm("nop");
  tmp = SED1520_DATA_PIN; 
  SED1520_CONTROL_PORT &= ~SED1520_E1; 
  }
else 
    {  
    SED1520_CONTROL_PORT |= SED1520_E2;
    asm("nop");asm("nop");
    SED1520_CONTROL_PORT &= ~SED1520_E2;
  asm("nop");asm("nop");
  SED1520_CONTROL_PORT |= SED1520_E2;
  asm("nop");asm("nop");
  tmp = SED1520_DATA_PIN;  
  SED1520_CONTROL_PORT &= ~SED1520_E2; 
  }
SED1520_DATA_DDR = 0xFF; 
lcd_x++; 
if(lcd_x > 121)
  lcd_x = 0;
return tmp;
}

ich hab schon die asm("nop") 3 mal kopiert und eingefügt, um die zeit zu 
verlängern, aber das Display mach immer noch keinen Mucks.

Was mich auch iritiert ist, das die Einstellung von F_CPU im Makefile 
ignoriert wurde. erst nachdem ich es als #define F_CPU im Code engefügt 
hat, hat er es übernommen.

[Jan H. (linklon)]

ich denke die initialisierung des Displays könnte ein problem sein...
wie steuerst du dein Display an? 4 oder 8 bit?

Bei 4 bit arbeitest du mit vielen waits, wenn die nicht stimmen => tot
Bei den 8 bit hängt der Prozessor wenn er kein ok zurückbekommt...

Initialisiert sich dein Display korrekt?

[Benedikt K. (benedikt)]

Jan Herzog schrieb:
> ich denke die initialisierung des Displays könnte ein problem sein...
> wie steuerst du dein Display an? 4 oder 8 bit?

Nicht jedes Display ist ein 44780 kompatibles Display mit 4 oder 8 bit 
Modus.

[holger (Gast)]

@linklon

>ich denke die initialisierung des Displays könnte ein problem sein...
>wie steuerst du dein Display an? 4 oder 8 bit?

Es gibt auch noch andere LCD Controller als du
gerade im Kopf hattest ;)

@Stefan
#define F_CPU 3579000UL

gehört VOR

#include <util/delay.h>

[Läubi .. (laeubi)]

Wenn du den Takt verdreifachst solltest du testweise auch mal alle 
"nops" verdreifachen.

[Stefan P (Gast)]

Stefan P:
> ich hab schon die asm("nop") 3 mal kopiert und eingefügt, um die zeit zu
> verlängern, aber das Display mach immer noch keinen Mucks.


jo die nops hab ich schon verdreifacht

> #define F_CPU 3579000UL

> gehört VOR

> #include <util/delay.h>


ok, das define hab ich jetzt vorgeschoben, aber das Display macht immer 
noch keine Ausgabe.


Ich steuer das Display mit einer 8 Bit an. Der Controller ist ein 
SED1520

[Stefan P (Gast)]

so ich hatte gestern auch noch die asm("nop") komplett rausgeschmissen 
und mit _delay_ms(10) getauscht, aber es bringt auch nichts,... hmm 
schön langsam gehen mir die ideen aus....

[Klaus D. (kolisson)]

das klingt ja nach einem sehr merkwürdigem problem.

wie läuft es denn, wenn du den internen takt auf 4 mhz stellst ?
wenns dann auch nicht läuft gibts vielleich ein problem mit dem layout 
oder sowas.

gruss klaus

[Stefan P (Gast)]

hmm aso, ich dachte der einezige interne Takt ist der mit 1 Mhz,
blick ins Datenblatt:

CKSEL laut datenblatt für intern CKSEL = 0001 und SUT = 10  = 1 Mhz
ich stells dann mal auf  CKSEL 0100 müsste 4 Mhz sein


Gute Idee, probier ich gleich heut abend !

[Stefan P (Gast)]

ups verschaut 0011  ist 4 Mhz

[Oliver (Gast)]

Bau mal überall vor dem Setzten des Enable-pins noch ein delay ein, so 
wie hier:

SED1520_DATA_PORT = dataToWrite; 
_delay_ms(1); // <======================================
if(lcd_x < 61) 
  {
  SED1520_CONTROL_PORT |= SED1520_E1;
...

Oliver

[Stefan P (Gast)]

wer ich dann auch heut abend probieren, ich geb dann feedback

[Stefan P (Gast)]

void GLCD_WaitForStatus(unsigned char status, unsigned char controller)
{
char tmp;
SED1520_CONTROL_PORT &= ~SED1520_A0; 
PORTB |= SED1520_RW; 
SED1520_DATA_DDR = 0x00; 
do
  {
  if(controller == 0) 
    {
  _delay_ms(1);
  SED1520_CONTROL_PORT |= SED1520_E1; 
  asm("nop");asm("nop");
  asm("nop");asm("nop");
  asm("nop");asm("nop");
  tmp = SED1520_DATA_PIN; 
  SED1520_CONTROL_PORT &= ~SED1520_E1; 
  } 
  else 
    {
  _delay_ms(1);
  SED1520_CONTROL_PORT |= SED1520_E2; 
  asm("nop");asm("nop");
  asm("nop");asm("nop");
  asm("nop");asm("nop");
  tmp = SED1520_DATA_PIN; 
  SED1520_CONTROL_PORT &= ~SED1520_E2; 
  }
  }while(tmp & status);
SED1520_DATA_DDR = 0xFF; 
}

hey oliver, danke für den tipp, ich habs jetzt aber in der 
GLCD_WaitForStatus eingebaut. JETZT GEHTS

Ich halte fest,... Problem war: ich musste die nops verdreifachen und 
bei der GLCD_WaitForStatus funktion vor Zugriff auf E1 bzw E2 ein delay 
einbauen

Nur versteh ich jetzt nicht genau warum es nötig ist da noch ein delay 
reinzumachen !


Vielen Dank für die rege Hilfe.

gruße

[Stefan P (Gast)]

hat von euch jemand nen plan , warum das ganze ohne das _delay_ms(1)
nicht funktioniert, ist zwar schön dass es jetzt geht, aber so lang ich 
des net versteh müss ich ständig grübeln,.....

[Karl H. (kbuchegg)]

Versuch doch mal die 1 ms zu drücken und kürzer zu machen.

> warum das ganze ohne das _delay_ms(1)
> nicht funktioniert,

Kann nur vermuten.
Am LCD läuft ja auch ein Prozessor. Der braucht auch ein bischen Zeit um 
nach der Bearbeitung eines Kommandos wieder aufnahmefähig für das 
nächste Kommando zu sein. Deine Abfrageschleife ist ziemlich dicht, soll 
heissen: ohne den _delay_ms kommt da Abfrage auf Abfrage ohne viel Zeit 
dazwischen.

In deinem Fall würde ich auch mal so probieren:
Die erste Abfrage würde ich ohne Zeitverzögerung machen. Erst dannn, 
wenn weitere Abfragen notwendig sind, kommt da eine kleine Verzögerung 
rein.
Damit musst du nicht lange warten, wenn das Display beim Eintritt in die 
Funktion schon ready ist.

Ungefähr so

void GLCD_WaitForStatus(unsigned char status, unsigned char controller)
{
  char tmp;

  SED1520_CONTROL_PORT &= ~SED1520_A0; 
  PORTB |= SED1520_RW; 
  SED1520_DATA_DDR = 0x00; 

  do
  {
    SED1520_CONTROL_PORT |= ( controller == 0 ? SED1520_E1 : SED1520_E2 ); 
    asm("nop");asm("nop");
    asm("nop");asm("nop");
    asm("nop");asm("nop");
    tmp = SED1520_DATA_PIN; 
    SED1520_CONTROL_PORT &= ~ ( controller == 0 ? SED1520_E1 : SED1520_E2 ); 

    if( ! ( tmp & status ) )  // noch eine Runde fällig? dann ein bischen warten
      _delay_ms( 1 );

  } while(tmp & status);

  SED1520_DATA_DDR = 0xFF; 
}

[Oliver (Gast)]

>hat von euch jemand nen plan ,

Der Plan heisst Datenblatt. Ich habe zwar keins vorliegen, aber 
üblicherweise haben solche Bausteine u.a. auch eine definierte 
Mindestzeit, die die Daten anliegen müssen, bevor das Taktsignal kommem 
darf.

Und ansonsten gilt bei solchen Problemen immer: Es liegt am Timing.

Oliver

[Stefan P (Gast)]

> Der Plan heisst Datenblatt. Ich habe zwar keins vorliegen, aber
> üblicherweise haben solche Bausteine u.a. auch eine definierte
> Mindestzeit, die die Daten anliegen müssen, bevor das Taktsignal kommem
> darf.

Ich leg ja keine Daten an, bevor ich daten anlege ruf ich die Funktion 
GLCD_WaitForStatus auf, und frag das Busy Flag ab, also status = 0x80, 
so lange das busyflag auf 1 ist, dreht das Programm seine runden in der 
Schleife, also müsste dieses delay doch dann unnötig sein ?!?


> Versuch doch mal die 1 ms zu drücken und kürzer zu machen.

hab ich schon versucht, aber die 1 ms braucht er schon ungefähr, wenn 
ichs kürzer mach dann verwehrt mir das Display die Ausgabe

dein Code sieht auf jeden Fall gut aus, den werd ich übernehmen, schon 
weil er übersichtlicher und kürzer ist.

[Stefan P (Gast)]

Ich hab im Datenblatt was gefunden S38, 39

Parameter Symbol           Signal       Min  Typ    Max    Unit
System cycle time tCYC6 *1 A0, CS       1000  —      —     ns

Wenn meine CPU mit 4 Mhz taktet kann se im Schnitt einen Befehl in 250ns 
abarbeiten.

Wenn ich die Funktion GLCD_Wait_For_Status 2mal hintereiander aufrufe um 
zB beide Controller abzufragen, dann dürfte das vom Timing her eng 
werden.
Ich werd dann den Aufruf mal abändern.

GLCD_WaitForStatus(0x80, 0);
_delay_ms(1); 
GLCD_WaitForStatus(0x80, 1); 

denn wenn die Funktion endet mit:
SED1520_CONTROL_PORT &= ~SED1520_E2;

könnte ich mir vorstellen, dass E2 noch gar nicht zurückgesetzt wird und 
dann schon wieder versucht wird E1 zu setzen, deswegen würde das delay 
hier die nötige zeit bringen.

[Stefan P (Gast)]

also ich meinte die 1000 ns zwischen den zugriffen auf das CS nicht 
eingehalten werden

[Oliver (Gast)]

>hab ich schon versucht, aber die 1 ms braucht er schon ungefähr,

das ist allerdings seltsam. Ich hatte die 1 ms eiggentlich nur als 
Extremwert dahingeschrieben, um zu sehen, ob es überhaupt was ausmacht. 
Üblicherweise liegen die einzuhaltenden Timings im Bereich 20 bis 500 
ns, da geht es um ein paar nops mehr oder weniger.


Hier,
http://www.lcd-module.de/eng/pdf/zubehoer/sed1520.pdf
auf Seite 36, stehen die relevanten timings. Das ist bei 3,7MHz 
Prozessortakt alles unkritisch, vorausgesetzt, dein Display hält sich 
auch an das Datenblatt.

Oliver

[Klaus D. (kolisson)]

also Stefan P (Gast):

eventuell solltest du mal die portpins, die du für das display 
verwendest
mal per software durchtoggeln und mal den rüssel (ossi) daufhalten. ein 
schlechtes layout oder schlechte kabel könnten nämlich dazu führen, dass 
die signale so verschliffen werden, das nix mehr geht, es sei denn, man 
baut einen haufen waits ein.

gruss klaus

[Stefan P (Gast)]

hmm, könnte sein, ich hab ja alles ein wenig wüst auf nem Breadboard 
zusammengenagelt,....