Program läuft nach reset nur manchmal wieder an

schaltplan, source.

TLars schrieb:
> im anhang der Schaltplan, habe ich ungefähr so nachgebaut(Led gedreht
> etc.)
ungefähr wertlos...

motor entstört? freilaufioden-dioden? reset-C?

Es wundert mich, dass dein Programm überhaupt (sinnvoll) läuft...
Die wichtigste Funktion scheint _delay_ms() zu sein. Du solltest dir 
unbedingt mal das Thema Zustandsautomaten näher ansehen. Die 
main-Schleife wird immer mit voller Geschwindigkeit durchlaufen, und 
darin abhängig vom aktuellen Zustand der Maschine (mit switch+case) in 
bestimmte Programmteile verzweigt.

>    GICR |= (1<<INT0); // enable Taster
Tastenabfragen gehen üblicherweise anders. Man liest den Taster ein, 
macht eine Entprellung und verarbeitet das dann weiter.

> erkennt er aber immernoch
> mein tasterevent und reagiert indem er den motor beliebig schaltet.
Ich bin mir ziemlich sicher, dass du selber nicht mehr durchblickst, in 
welchem der verschachtelten Zustände dein Programm sich verklemmt hat. 
Mach da doch mal Debugausgaben in Form von LEDs mit rein...

Zur Hardware:
wie hast du das aufgebaut?
Lochraster, Platine (falls ja: wie sieht das Layout aus)?
Wie sieht die Masseführung aus?

Du solltest jetzt erst mal sicherstellen, dass der Motor nicht irgendwie 
den uC durcheinanderbringt. Dazu wäre ein simples und überschaubres 
Testprogramm nötig.


BTW: sowas sollte es grundsätzlich nicht geben:

1

ISR (INT0_vect){

2

  :

3

  _delay_ms (100);

4

  :

5

}

Ein Delay im ms-Bereich hat in einer ISR nichts zu suchen.

BTW2: das ist auch komplett unnötig:

1

   while(1) // drive reverse till on reset position

2

      {

3

      :

4

      if(Adc_value>=TRESHOLD) 

5

          {

6

          :

7

          goto rst_position;

8

          }

9

      }

10

   rst_position:

C != Basic.
Statt goto schreibt man das so:

1

   while(1) // drive reverse till on reset position

2

      {

3

      :

4

      if(Adc_value>=TRESHOLD) 

5

          {

6

          :

7

          break;

8

          }

9

      }

> oder eher ein Problem mit der
> Spannungsversorgung etc.?

Der Vcc-Anschluss des Prozessors ist nicht an Vcc angeschlossen.

Gruß,
Peter

TLars schrieb:

> Allgemein die frage: unabhängig von der schlechten Programmierung des
> codes, wenn ich weiss das der code geht

Die Frage ist: geht der Code überhaupt?

Das alles ist so dermassen unübersichtlich programmiert, dann sich diese 
Frage nicht beantworten lässt

1

ISR (INT0_vect){

2

unsigned char sreg = SREG;

3

  //transmit_str_USART("Int0 \n ");

4

  INT_TASTER=1; // setze Flag

5

  GICR  &= ~(1<<INT0);// disable Int0

6

  _delay_ms (100);

7

  SREG=sreg;

8

  }

lass wenigstens das SREG Register in Ruhe!
Woher kommt blos diese Unsitte, sich in C an den Prozessorregistern zu 
vergreifen? Die gehen dich nichts an! Die stehen unter Verwaltung des 
Compilers und nur der kümmert sich um diese Register. Sonst niemand

> ja der code funktioniert sicher wenn er denn einmal richtig gestartet
> ist.
Wer gestartet? Der Code? Oder deine Maschine?
Und wie schaffst du einen Start, dass er garantiert geht?
Klappt das überhaupt, oder ist jeder Start ein Bangen und Hoffen?

>>> das manchmal der Reset betätigt werden muss um mein
>>> Program wieder in einen calibrierungsmode zu bringen
Ja, sind wir denn bei Windows, dass für eine simple Referenzfahrt schon 
ein Reboot nötig ist?  :-o

Ich bin mir ziemlich sicher, dass du ein Softwareproblem hast. Wer hält 
dagegen?

> Masse trifft sich beim
> HEBW und geht dan von da auf seperaten wegen zu ATmega und L298.
Das mit der Versorung am Pin 7 war noch offen...

Peter Bünger schrieb:
> Der Vcc-Anschluss des Prozessors ist nicht an Vcc angeschlossen.
Wie stehts damit eigentlich?

TLars schrieb:

> ja der code funktioniert sicher wenn er denn einmal
> richtig gestartet ist.

Also funktioniert er nicht :-)


> das mit den sreg war copy und paste aus einen tutorial. und die 100ms
> delay in der ISR ist meine entprellung,

delays macht man nie leichtfertig rein.
Und schon gar nicht in Interrupt Routinen.

> ich weiss ist nicht schick aber
> da eh keine anderen interrups vorhanden sind, dacht ich mir mach ich es
> da rein.

Darum gehts eher weniger.

Wenn ein Interrupt nur einigermassen häufig genug auftritt, dann macht 
dir der delay da drinnen den kompletten µC dicht. Und zwar schon weit 
früher als man das aufgrund der Arbeitsgeschwindigkeit (und ohne delay) 
annehmen könnte.

> ich werd mal das Boden Fuse setzen und schauen was passiert.

BODEN ist sicher gut.
Aber kümmerer dich erst mal um dein Programm. Das ist ja schauderhaft. 
Fang wenigstens damit an, die vielen immer gleichen Programmteile in 
Funktionen auszulagern um die Komplexität runterzubringen und mehr 
Übersicht reinzubringen.

BODEN Anschalten und es läuft? Ich denke der läuft jetzt nur immer 
wieder von vorn los, wenn es übermäßige Spannungseinbrüche gibt.

mf

Dann fängt sich der Pin Störungen ein.
Aber fang jetzt bitte nicht an, den Pin zu entstören...