Atmega/C: eine Funktion aus einer Funktions heraus aufrufen

[006 (Gast)]

Hallo Zusammen,

Habe ein Software Problem bei einem Mikrocontroller Programm:

Umgebung: AtmelStudio, JTAGICE3, C, ATmega64, 3,3V

Ich habe in meinem Code mehrere Funktionen, die sich alle durch die main 
Funktion aufrufen lassen. So weit funktioniert alles.

ABER: Wenn ich in "main" eine Funktion aufrufe, und aus dieser Funktion 
eine andere Funktion aufrufe, bleibt der Mikrocontroller hängen. Weiß 
jemand wieso? Ist das Problem bekannt?

Funktionen deklariere ich immer folgendermaßen:

void Sende_Ziffer(uint8_t ziffer)
{
  //mein code
}

void Sende_Alle_Ziffern(uint8_t s1,uint8_t s2,uint8_t s3,uint8_t i1,uint8_t i2,uint8_t i3)
{
  //mein code
  Sende_Ziffer(2);
}

int main(void)
{

  //mein code
  
  while(1)
  {
    Sende_alle_Ziffern(1,2,3,4,5,6);
  }
}

Danke und Grüße,
006

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Stacküberlauf

[006 (Gast)]

Andreas Schweigstill schrieb:
> Stacküberlauf

Das heißt? Kann ich das generell nicht bei ATmega Mikrocontrollern?

[M. S. (elpaco)]

Ich weiß nicht, ob dein Code hier nur beispielhaft ist. Jedoch sendest 
du, wenn du "Sende_alle_Ziffern" aufrufst, hier immer nur eine "2". 
Unabhängig davon, mit welchen Argumenten "Sende_alle_Ziffern" aufgerufen 
wird.

[Max B. (theeye)]

006 schrieb:
> Das heißt? Kann ich das generell nicht bei ATmega Mikrocontrollern?

Doch das kannst du natürlich! Hier die gesuchten Infos: 
http://avr.myluna.de/doku.php?id=de:stackueberlaeufe_erkennen

Gruß Max

[006 (Gast)]

Ist nur ein stark reduzierter Beispielcode. Konnte das Problem so weit 
eingrenzen, dass der Controller sich definitiv beim Aufruf der 2 
Funktion verabschiedet

[M. S. (elpaco)]

In dem Fall sind vielleicht sechs Argumente für die Funktion zu viel

[Ingo (Gast)]

006 schrieb:
> void Sende_Ziffer(uint8_t ziffer)
> {
>   //mein code
> }

Was verbirgt sich hinter "mein Code"???

[006 (Gast)]

M. S. schrieb:
> In dem Fall sind vielleicht sechs Argumente für die Funktion zu viel

Werde mal alle Unterfunktionen zu einer einzigen Zusammenfassen. Ist 
zwar häßlich wegen hoher Coderedundanz, scheint mir dafür aber die 
einfachste Lösung. Und ist in der Ausführung sicher auch schneller, da 
weniger Sprungbefehle auftauchen.

[Karl H. (kbuchegg)]

006 schrieb:
> M. S. schrieb:
>> In dem Fall sind vielleicht sechs Argumente für die Funktion zu viel
>
> Werde mal alle Unterfunktionen zu einer einzigen Zusammenfassen.

Das wird dir nicht viel bringen.

Das Problem in deinem Programm lässt sich nicht auf 'die eine Zeile' 
reduzieren. Dein Programm verbraucht, wenn die Ad Hoc Diagnose 
'Stack+berlauf' zutrifft, in seiner Gesamtheit einfach zuviel SRAM. Das 
müsste schon sehr an der Kippe stehen, wenn dir das bischen 
Returnstack-Einsparung durch einen eingesparten Funktionsaufruf die 
Sache rettet. Vor allen Dingen bringt das nur ganz kurze Abhilfe. Bei 
der nächsten Änderung fliegt dir dann wieder alles um die Ohren.

Also: Speicherverbrauch feststellen und nachsehen wo man ein wenig SRAM 
sparen kann.

> Ist
> zwar häßlich wegen hoher Coderedundanz, scheint mir dafür aber die
> einfachste Lösung.

Mit Sicherheit nicht.

[Max B. (theeye)]

Karl Heinz schrieb:
> Also: Speicherverbrauch feststellen und nachsehen wo man ein wenig SRAM
> sparen kann.

Eventuell Strings oder andere Daten, die sich nicht ändern, in den Flash 
auslagern. Versuche selbst gerade ein Menu bzw. die Strings mit __flash 
dorthin zu bekommen und wieder auszugeben. Mein SRAM ist nämlich auch 
voll ;-)

Gruß Max

[006 (Gast)]

Hier der Quellcode. Ich habe 6 Zahlenwerte und möchte die über 
Schieberegister jeweils auf zwei 7-Segmentanzeigen ausgeben (2stellig 
00-99).

Weiß nicht, was da jetzt für den Speicher kritisch werden sollte... Hat 
jemand eine Idee?

/*
 * Main_64_v01.c
 *
 * Created: 11.09.2014 14:28:26
 *  Author: test1
 */ 
 

//Bibliotheken
#include <avr/io.h>
#include <stdint.h>


// PINOUT - Anzeigemodul
#define SCK  3    //PE3: Speichertakt
#define DATA 4    //PE4: Serielle Datenleitung
#define CLK  5    //PE5: Schiebetakt
#define OE   6    //PE6: Output Enabled
//Board
#define LED  6    //PB6: Status LED auf dem Board


// Funktionen Deklaration

uint8_t Dez_To_7Seg(uint8_t dez) // CHECKED 
{
  // kodiere eine Dezimalzahl für die 7-Segment-Anzeige
  // Input :    Dezimalzahl typ uint8_t
  // Output :    Code für 7-Segment Anzeige
  
  // Pin Zuordnung
  // Qn: Schieberegister Ausgang Nr. n
  // n:  7-Segment-Anzeige Balken Nr. n
  // Q0  ->  nc
  // Q1  ->  6  ->  b
  // Q2  ->  7  ->  a
  // Q3  ->  4  ->  c
  // Q4  ->  2  ->  d
  // Q5  ->  9  ->  f
  // Q6  ->  1  ->  e
  // Q7  ->  10  ->  g
  
  switch(dez) {     //gefdcab-
    case 0: return 0b01111110; break;
    case 1: return 0b00001010; break;
    case 2: return 0b11010110; break;
    case 3: return 0b10011110; break;
    case 4: return 0b10101101; break;
    case 5: return 0b10111100; break;
    case 6: return 0b11111100; break;
    case 7: return 0b00001110; break;
    case 8: return 0b11111110; break;
    case 9: return 0b10111110; break;
    default: return 0b11110100; break; // -> E: Error
  }

}

void Sende_Ziffer(uint8_t ziffer)
{
  
  if ( ziffer & ( 1 << 7 ) ) {  PORTE |= (1 << DATA);  }  //Wenn Bit 7 = High, dann High ausgeben
  else              {  PORTE &= ~(1 << DATA); };  //Wenn Bit 7 = Low, dann Low ausgeben
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 6 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 5 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 4 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 3 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 2 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 1 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
  if ( ziffer & ( 1 << 0 ) ) {  PORTE |= (1 << DATA);  }
  else              {  PORTE &= ~(1 << DATA); };
  PORTE |= (1 << CLK);                    // Datenleitung = HIGH
  PORTE &= ~(1 << CLK);                    // Schiebetakt = HIGH, LOW
}

void Sende_Alle_Ziffern(uint8_t s1,uint8_t s2,uint8_t s3,uint8_t i1,uint8_t i2,uint8_t i3)
{
  uint8_t buffer;
  
  buffer = s3/10;            //10er ermitteln
  buffer = Dez_To_7Seg(buffer);    //Für die 7-Segmentanzeige codieren
  Sende_Ziffer(buffer);        //an Schieberegister senden

  buffer = s3 % 10;          //1er ermitteln
  buffer = Dez_To_7Seg(buffer);    //Für die 7-Segmentanzeige codieren
  Sende_Ziffer(buffer);        //an Schieberegister senden
  
  buffer = i3/10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);

  buffer = i3 % 10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);
  
  buffer = s2/10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);

  buffer = s2 % 10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);
  
  buffer = i2/10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);

  buffer = i2 % 10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);
  
  buffer = s1/10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);

  buffer = s1 % 10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);
  
  buffer = i1/10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);

  buffer = i1 % 10;
  buffer = Dez_To_7Seg(buffer);
  Sende_Ziffer(buffer);

  PORTE |= (1 << SCK);  //Schiebetakt
  PORTE &= ~(1 << SCK);  //Schiebetakt  
  
  PORTB |= (1 << LED);
}

int main(void)
{
  DDRE = 0b01111001;      //Ausgänge an PortE definieren (Anzeigemodul)
  DDRB = 0b01000000;      //Ausgänge an PortB definieren (Status LED)
  
  
  PORTE &= ~(1 << CLK);    //Alle Signalleitungen zu den Schieberegistern auf 0
  PORTE &= ~(1 << OE);
  PORTE &= ~(1 << SCK);
  PORTE &= ~(1 << DATA);
  
  uint8_t M1_Soll = 88;    //Drei Sollwerte
  uint8_t M2_Soll = 88;
  uint8_t M3_Soll = 88;
  uint8_t M1_Ist = 88;    //Drei Istwerte
  uint8_t M2_Ist = 88;
  uint8_t M3_Ist = 88;
  
          
  while(1)
    {
    Sende_Alle_Ziffern(M1_Soll, M2_Soll, M3_Soll, M1_Ist, M2_Ist, M3_Ist);  //Gebe die Zahlen auf den 7-Segment-Anzeigen aus
    PORTB |= (1 << LED);                          //Status-LED einschalten
    }
}

[Thomas E. (thomase)]

Ein Atmega64 hat 4K RAM. Das dauert schon ein wenig, bis der Stack 
überläuft.

M. S. schrieb:
> Ich weiß nicht, ob dein Code hier nur beispielhaft ist

Jetzt zeig mal ein richtiges Programm, das auch läuft. An dem Extrakt 
oben lässt sich nur die Qualität der Optimierung erkennen.

mfg.

[Karl H. (kbuchegg)]

Da ist auch nichts kritisches (ausser dass man den Code auch um 50% 
kleiner schreiben kann und so die Unübersicht los wird).


Die Funktionsaufrufe sind es jedenfalls nicht.
Was hängt da für ein Schieberegister drann? 74595? Wie ist es 
verdrahtet?

[006 (Gast)]

Karl Heinz schrieb:
> Was hängt da für ein Schieberegister drann? 74595? Wie ist es

74HC595. Läßt sich problemslos ansteuern so lange ich die Befehle 
sequenziell in eine funktion packe... Daher wird die Verdrahtung wohl 
stimmen.

[Karl H. (kbuchegg)]

006 schrieb:
> Karl Heinz schrieb:
>> Was hängt da für ein Schieberegister drann? 74595? Wie ist es
>
> 74HC595. Läßt sich problemslos ansteuern so lange ich die Befehle
> sequenziell in eine funktion packe... Daher wird die Verdrahtung wohl
> stimmen.

Trotzdem ist da was anderes faul.
Hast du in der IDE den korrekten µC-Typ eingstellt?

[Christoph V. (nexttopmodel)]

Der Code sollte so laufen, doch schau mal in der Funktion

uint8_t Dez_To_7Seg(uint8_t dez)

nach, alle return's werden durch den switch erzeugt.
Entferne mal den default und gib das als Standard zurück.

Ich glaube aber auch das es eher die Schaltung ist, z.B 
Spannungseinbruch durch Schalten eines Pins zum Kurzschluss.

Gruß, Christoph

[006 (Gast)]

Christoph Vogel schrieb:
> Ich glaube aber auch das es eher die Schaltung ist, z.B
> Spannungseinbruch durch Schalten eines Pins zum Kurzschluss.

Also habe die Funktionen jetzt zu einer mit relativ hoher Coderedundanz 
zusammengeführt. Läuft fehlerfrei!

Ist halt nur häßlich...

[Karl H. (kbuchegg)]

006 schrieb:
> Christoph Vogel schrieb:
>> Ich glaube aber auch das es eher die Schaltung ist, z.B
>> Spannungseinbruch durch Schalten eines Pins zum Kurzschluss.
>
> Also habe die Funktionen jetzt zu einer mit relativ hoher Coderedundanz
> zusammengeführt. Läuft fehlerfrei!

Bis zum nächsten Fehler.
Dein Code ist an sich in Ordnung. Da ist irgendwas faul, was wir hier 
nicht sehen können. An den Funktionsaufrufen hängt es ganz sicher nicht.

>
> Ist halt nur häßlich...

Und unwartbar

[Stefan E. (sternst)]

Zustand der M103C-Fuse?

[Thomas E. (thomase)]

Karl Heinz schrieb:
> Dein Code ist an sich in Ordnung. Da ist irgendwas faul, was wir hier
> nicht sehen können. An den Funktionsaufrufen hängt es ganz sicher nicht.

Hat eigentlich schon jemand den Klassiker ins Spiel gebracht?

100nF an JEDEM 595er.

006 schrieb:
> Ist halt nur häßlich...

Das ist der ursprüngliche Code aber auch. Funktionieren sollte er 
trotzdem.

Karl Heinz schrieb:
> Bis zum nächsten Fehler.

Und der wird nicht lange auf sich warten lassen.

mfg.

[Karl H. (kbuchegg)]

Thomas Eckmann schrieb:
> Karl Heinz schrieb:
>> Dein Code ist an sich in Ordnung. Da ist irgendwas faul, was wir hier
>> nicht sehen können. An den Funktionsaufrufen hängt es ganz sicher nicht.
>
> Hat eigentlich schon jemand den Klassiker ins Spiel gebracht?
>

nicht das ich wüsste. Sollte man aber mal klären.

006. Teste mal diesen Code. Das ist wichtig, dass wir das jetzt ein für 
alle mal hinkriegen. Du kannst nicht vernünftig weiterarbeiten, wenn 
nicht klargestellt ist, was da in deinem System los ist.

#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>


// PINOUT - Anzeigemodul
#define SCK  3    //PE3: Speichertakt
#define DATA 4    //PE4: Serielle Datenleitung
#define CLK  5    //PE5: Schiebetakt
#define OE   6    //PE6: Output Enabled
//Board
#define LED  6    //PB6: Status LED auf dem Board


  // Q0  ->  nc
  // Q1  ->  6  ->  b
  // Q2  ->  7  ->  a
  // Q3  ->  4  ->  c
  // Q4  ->  2  ->  d
  // Q5  ->  9  ->  f
  // Q6  ->  1  ->  e
  // Q7  ->  10  ->  g

uint8_t digitPattern[] = {
          0b01111110,
          0b00001010,
          0b11010110,
          0b10011110,
          0b10101101,
          0b10111100,
          0b11111100,
          0b00001110,
          0b11111110,
          0b10111110,
          0b11110100     // -> E: Error
};

uint8_t Dez_To_7Seg( uint8_t dez )
{
  if( dez < 10 )
    return digitPattern[dez];

  return digitPattern[10];
}

void DisplayDigit( uint8_t digit )
{
  uint8_t i;
  uint8_t pattern = Dez_To_7Seg( digit );

  for( i = 0; i < 8; i++ ) {
    if( pattern & 0x80 )
      PORTE |= ( 1 << DATA );
    else
      PORTE &= ~( 1 << DATA );

    PORTE |= (1 << CLK);
    PORTE &= ~(1 << CLK);

    pattern <<= 1;
  }
}

void DisplayNumber( uint8_t number )
{
  DisplayDigit( number / 10 );
  DisplayDigit( number % 10 );
}

void Sende_Alle_Ziffern(uint8_t s1,uint8_t s2,uint8_t s3,uint8_t i1,uint8_t i2,uint8_t i3)
{
  DisplayNumber( s3 );
  DisplayNumber( i3 );
  DisplayNumber( s2 );
  DisplayNumber( i2 );
  DisplayNumber( s1 );
  DisplayNumber( i1 );

  PORTE |= (1 << SCK);
  PORTE &= ~(1 << SCK);  
}

int main(void)
{
  DDRE = (1<<SCK) | (1<<DATA) | (1<<CLK) | (1<<OE);
  DDRB = (1<<LED);
  
  
  PORTE &= ~(1 << CLK);
  PORTE &= ~(1 << SCK);
  PORTE &= ~(1 << DATA);
  PORTE &= ~(1 << OE);
  
  uint8_t M1_Soll = 88;    //Drei Sollwerte
  uint8_t M2_Soll = 88;
  uint8_t M3_Soll = 88;
  uint8_t M1_Ist = 88;    //Drei Istwerte
  uint8_t M2_Ist = 88;
  uint8_t M3_Ist = 88;
  
  // eindeutige Blinkerei an der LED, damit man erkennt
  // ob es einen ungewollten Prozessorreset gibt
  PORTB &= ~(1<<LED);
  _delay_ms( 1000 );
  PORTB |= (1 << LED);
  _delay_ms( 1000 );
  PORTB &= ~(1<<LED);
  _delay_ms( 1000 );
  PORTB |= (1 << LED);
          
  while(1)
  {
    Sende_Alle_Ziffern(M1_Soll, M2_Soll, M3_Soll, M1_Ist, M2_Ist, M3_Ist);  //Gebe die Zahlen auf den 7-Segment-Anzeigen aus
  }
}

[Thomas E. (thomase)]

Karl Heinz schrieb:
>> Hat eigentlich schon jemand den Klassiker ins Spiel gebracht?
>>
>
> nicht das ich wüsste. Sollte man aber mal klären.

Das war auch eher eine rhetorische Frage.
Ich würde mich auch zu einer Wette hinreissen lassen.

mfg.

[Marc V. (Firma: Vescomp) (logarithmus)]

Karl Heinz schrieb:
> // eindeutige Blinkerei an der LED, damit man erkennt
>   // ob es einen ungewollten Prozessorreset gibt
>   PORTB &= ~(1<<LED);
>   _delay_ms( 1000 );
>   PORTB |= (1 << LED);
>   _delay_ms( 1000 );
>   PORTB &= ~(1<<LED);
>   _delay_ms( 1000 );
>   PORTB |= (1 << LED);

 Kürzer ?

  for( i = 0; i < 2; i++ ) {
    PINB |= (1<<LED);
    _delay_ms( 1000 );
  }

[Route_66 H. (route_66)]

Marc Vesely schrieb:
> Kürzer ?
>   for( i = 0; i < 2; i++ ) {
>     PINB |= (1<<LED);
>     _delay_ms( 1000 );
>   }

Was nützt es Dir, in einer Schleife die LED dauernd einzuschalten? So 
entsteht kein BLINKEN!

[Marc V. (Firma: Vescomp) (logarithmus)]

Route 66 schrieb:
> Was nützt es Dir, in einer Schleife die LED dauernd einzuschalten? So
> entsteht kein BLINKEN!

 Warum schreist du den ?
 Und bist du sicher, dass es dauernd eingeschaltet wird ?

[Karl H. (kbuchegg)]

Marc Vesely schrieb:
> Route 66 schrieb:
>> Was nützt es Dir, in einer Schleife die LED dauernd einzuschalten? So
>> entsteht kein BLINKEN!
>
>  Warum schreist du den ?
>  Und bist du sicher, dass es dauernd eingeschaltet wird ?

Auf einem Mega64 gibt es die Toggle-Funktionalität mittels PINx Register 
noch nicht. Wenn schon, dann hätte man es so schreiben können.

  for( i = 0; i < 4; i++ ) {
    PORTB ^= (1<<LED);
    _delay_ms( 1000 );
  }

4 Umschaltungen mach ich deshalb, weil ich nicht weiß, wie seine LED 
angebunden ist. Bei 4 mal ergibt das auf jeden Fall irgendetwas 
unmissverständlich sichtbares.

Aber: in meinen Augen ist das jetzt ehrlich gesagt ein Streit um des 
Kaisers Bart, ob man da eine Schleife nimmt, oder per Copy&Paste 
programmiert. Man muss nicht päpstlicher als der Papst sein. Der Zweck 
ist auf jeden Fall so oder so erfüllt und im fertigen Programm kommts 
dann sowieso wieder raus.

[006 (Gast)]

Karl Heinz schrieb:
> 006. Teste mal diesen Code. Das ist wichtig, dass wir das jetzt ein für
> alle mal hinkriegen. Du kannst nicht vernünftig weiterarbeiten, wenn
> nicht klargestellt ist, was da in deinem System los ist.

Hallo Karl Heinz,
habe deinen Code probiert.
Eine Warnung:
Warning  1  #warning "F_CPU not defined for <util/delay.h>" [-Wcpp] 
c:\program files (x86)\atmel\atmel toolchain\avr8 
gcc\native\3.4.1056\avr8-gnu-toolchain\avr\include\util\delay.h  90  3 
GccApplication2

Programm ließ sich kompilieren und übertragen. Die 7-Segment-Anzeigen 
zeigen weiterhin alte Ziffern, die noch im Latch der Schieberegister 
hingen.

Die Status LED leuchtet kurz auf (t>0.2s) bleibt dann ca. 1s aus 
leuchtet dann ca. 1s auf und bleibt wieder eine 1s aus. Dann wiederholt 
sich das Spiel.

[Karl H. (kbuchegg)]

006 schrieb:

> Die Status LED leuchtet kurz auf (t>0.2s) bleibt dann ca. 1s aus
> leuchtet dann ca. 1s auf und bleibt wieder eine 1s aus. Dann wiederholt
> sich das Spiel.

Wie?
Die LED blinkt immer wieder?


Dann stürzt dein Prozessor laufend ab und der Verdacht, das es sich um 
ein  elektrisches Problem handelt verdichtet sich. Poste mal deinen 
Schaltplan oder häng gleich mal prophylaktisch 100nF Kondensatoren an 
die Versorgungsspannung des Prozessors und der 595 (jeder IC kriegt 
seinen eigenen Kondensator, möglichst dicht ans Gehäuse des IC)

[006 (Gast)]

006 schrieb:
> Die Status LED leuchtet kurz auf (t>0.2s) bleibt dann ca. 1s aus
> leuchtet dann ca. 1s auf und bleibt wieder eine 1s aus. Dann wiederholt
> sich das Spiel.

Ich meinte <0,2s. Wirklich nur kaum wahrnehmbar

[Marc V. (Firma: Vescomp) (logarithmus)]

Karl Heinz schrieb:
> Auf einem Mega64 gibt es die Toggle-Funktionalität mittels PINx Register

 Das wusste ich nicht.

[Stefan E. (sternst)]

Auch auf die Gefahr hin, wieder ignoriert zu werden:
Wie ist der Zustand der M103C-Fuse?

[Karl H. (kbuchegg)]

Stefan Ernst schrieb:
> Auch auf die Gefahr hin, wieder ignoriert zu werden:
> Wie ist der Zustand der M103C-Fuse?

Guter Einwand. Wusste gar nicht, dass der Mega64 die auch hat (so wie 
der 128).
Und Atmel hat (in meinen Augen) denselben Mist gemacht, wie beim 128-er. 
Default ist die Fuse 'programmed', sprich man muss erst mal an die Fuse 
ran, ehe man dann tatsächlich einen M64 vor sich hat.

[006 (Gast)]

Stefan Ernst schrieb:
> Wie ist der Zustand der M103C-Fuse?

Heißt das bei mir anders? Ein Bild ist im Anhang

[Stefan E. (sternst)]

006 schrieb:
> Heißt das bei mir anders? Ein Bild ist im Anhang

Vermutlich "CompMode".

[006 (Gast)]

Karl Heinz schrieb:
> Dann stürzt dein Prozessor laufend ab und der Verdacht, das es sich um
> ein  elektrisches Problem handelt verdichtet sich. Poste mal deinen
> Schaltplan oder häng gleich mal prophylaktisch 100nF Kondensatoren an
> die Versorgungsspannung des Prozessors und der 595 (jeder IC kriegt
> seinen eigenen Kondensator, möglichst dicht ans Gehäuse des IC)

Ich seh grade dass ich einen Vcc Eingang des Controllers nicht mit 100nF 
entstört habe. Die Spannung schwangt hier un ca. 50mV. Mal sehen ob ich 
noch einen einlöten kann.

[Karl H. (kbuchegg)]

006 schrieb:
> Karl Heinz schrieb:
>> Dann stürzt dein Prozessor laufend ab und der Verdacht, das es sich um
>> ein  elektrisches Problem handelt verdichtet sich. Poste mal deinen
>> Schaltplan oder häng gleich mal prophylaktisch 100nF Kondensatoren an
>> die Versorgungsspannung des Prozessors und der 595 (jeder IC kriegt
>> seinen eigenen Kondensator, möglichst dicht ans Gehäuse des IC)
>
> Ich seh grade dass ich einen Vcc Eingang des Controllers nicht mit 100nF
> entstört habe. Die Spannung schwangt hier un ca. 50mV. Mal sehen ob ich
> noch einen einlöten kann.

Hast du dich um die Fuse gekümmert? Die Abblockkondensatoren sind 
natürlich wichtig, helfen aber bei aktiviertem Kompatibilitätsmodus 
nichts.
Solange der eingeschaltet ist, hast du keinen Mega64 vor dir sondern 
einen Mega-103. Und der hat eine andere Speicherbelegung, was ganz 
zwanglos die Abstürze erklären würde.
Um es ganz klar zu sagen: Du KANNST diese Thematik nicht ignorieren!

(Und dem Mann, der sich bei Atmel den Unsinn ausgedacht hat, dass diese 
µC mit aktiviertem 103-Modus ausgeliefert werden, würde ich am liebsten 
den Hals umdrehen)

[Paul (Gast)]

Karl Heinz schrieb:
> Und der hat eine andere Speicherbelegung, was ganz
> zwanglos die Abstürze erklären würde.

Ich würde eher sagen:
..., was ganz zwangsweise die Abstürze erklären würde.

Hab ich schon erlebt, nur wusste ich nicht, dass der M64 die auch hat. 
Ist ja n Ding.

[006 (Gast)]

Karl Heinz schrieb:
> Hast du dich um die Fuse gekümmert? Die Abblockkondensatoren sind
> natürlich wichtig, helfen aber bei aktiviertem Kompatibilitätsmodus
> nichts.

Hey, das war genau der Fehler. Das Progamm von Karl Heinz läuft jetzt!!! 
:) Vielen Dank euch allen für die schnelle und freundliche Hilfe.

[Karl H. (kbuchegg)]

006 schrieb:

> Hey, das war genau der Fehler. Das Progamm von Karl Heinz läuft jetzt!!!
> :) Vielen Dank euch allen für die schnelle und freundliche Hilfe.

Stefan gebührt die Ehre.

Da muss ich wohl in meinem persönlichen 
Fehlermöglichkeiten-Gedächtnis-Ordner einen neuen Punkt für den M64 
einfügen. Beim M128 hat man sich ja schon daran gewöhnt, dass das 
Fehlerbild 'Absturz beim Funktionsreturn' auf eine fehlerhafte 
Kompatibilitätsfuse hinweist.