Atmega stürtzt nach ca. 15 min ab

Michael Mayer schrieb:
> Mir ist das Problem bisher nicht aufgefallen
> weil er nie solange am Stück lief.

Du hast ein umfangreiches Programm geschrieben, das im 
Viertelstundentakt Aktivität entwickeln soll, es aber nie auch nur eine 
Viertelstunde lang laufen lassen?

Beeindruckend.

Stacküberlauf?

> Du hast ein umfangreiches Programm geschrieben, das im
> Viertelstundentakt Aktivität entwickeln soll, es aber nie auch nur eine
> Viertelstunde lang laufen lassen?
Ich hab immer nur die erste viertel Stunde abgewartet da ist es nie 
aufgetreten. Und es soll nicht alle 15 minuten etwas tun sonder immer um 
xx:00 xx:15 xx:30 und xx:45 Uhr deshalb auch DCF77. Ich hab mir schlecht 
ausgedrückt.

>Stacküberlauf?
Wie kann ich das testen? Aber dann müsste die Zeit doch auch immer 
gleich sein. Sie schwankt aber zwischen 15 und 20 Minuten.

Gruß Michael

Stefan May schrieb:
> Mein Tip: Versuche das Programm so lesbar zu gestalten, daß Du es selbst
> verstehst. Wenn Du das gemacht hast, dann poste Deinen Code und wir
> können Dir weiterhelfen.
>
> mfg, Stefan.

Ich verstehe mein Porgramm schon. Nur denke ich das es für euch schwer 
werden kann, da ich bestimmt einiges unkonventionell gelöst habe, bin 
noch Anfänger.

Ohne Programmanalyse kann man da so gut wie gar nichts sagen. Der Fehler 
kann überall sein.

Fang ein neues Programm an.
Dort übernimmst du nacheinander Teile aus deinem jetzigen Programm und 
machst nach jeder Übernahme Langzeittests. Ein vorhergehendes Abklappern 
der jeweils zu übernehmenden Programmteile nach offensichtlichen Fehlern 
ist allerdings auf jeden Fall ratsam.

Michael Mayer schrieb:
> Stefan May schrieb:
>> Mein Tip: Versuche das Programm so lesbar zu gestalten, daß Du es selbst
>> verstehst. Wenn Du das gemacht hast, dann poste Deinen Code und wir
>> können Dir weiterhelfen.
>>
>> mfg, Stefan.
>
> Ich verstehe mein Porgramm schon.

Große Worte :-)

> Nur denke ich das es für euch schwer
> werden kann,

Du kannst dir gar nicht vorstellen, mit welchen Programmgrößen und 
abstrusen Ideen die Profis hier Tag für Tag zu tun haben. Mach dir 
deswegen keine Sorgen.
Und wenn, dann zeigen dir die Leute hier schon, wie man die Dinge besser 
lösen kann.

> da ich bestimmt einiges unkonventionell gelöst habe,

und das ist meistens eine schlechte Idee. Vor allem wenn man Anfänger 
ist.

>Große Worte :-)
War vllt. etwas hoch gegriffen. Ich glaube es zu verstehen.

Und hier mal das ganze Programm ich hoffe es ist verständlich. Sonst 
einfach fragen.
Und schon mal danke euch allen das ihr euch so bemüht.

Assembler für ein Projekt dieser Größe? Bist du Masochist?

Na dann viel Spass, wo du ein Register zu pushen/poppen vergessen hast 
bzw. den Stack in Unordnung gebracht hast.

Ich kann leider nichts anderes und wir machen in der Ausbildung und in 
der Schule auch nur ASM.

Den Tipp mit dem neuen Programm werde ich morgen oder übermorgen machen.

Karl Heinz Buchegger schrieb:
> Na dann viel Spass, wo du ein Register zu pushen/poppen vergessen hast
> bzw. den Stack in Unordnung gebracht hast.
Insbesondere, wenn eine Unterroutine wie z.B. der int2_handler zig 
Rücksprünge hat. So ein Assembler-Programm kannst du nur beherrschen, 
wenn du in einer Unterroutine genau 1 Eintritts und 1 Austrittspunkt 
hast. Alles andere mag zwar trickreich, schnell und speichersparend 
sein, es führt garantiert zum Chaos...

Autsch.
Du hast vieles durch endlose hin- und herspring-Orgien gelöst. Das ist 
Spaghetticode erster Sahne und wahnsinnig schwer nachzuvollziehen, wie 
da der Kontrollfluss durch deinen Code läuft, was gerade am Stack liegt, 
welche Register wo gebraucht werden, welche frei sind etc.

Die Dinge wären einfacher, wenn du dir Subroutinen bauen würdest, die 
mittels rcall oder call aufgerufen werden und mittels ret zu ihrer 
Aufrufstelle zurückkehren.

http://www.mikrocontroller.net/articles/Strukturierte_Programmierung_auf_Mikrocontrollern#Modularisierung

Gilt 3x mehr für Assembbler

Nach kurzem Überfliegen fiel mir folgendes direkt auf:

1

wert_aktuell:

2

    in temp, sreg

3

    push temp

4

    push temp1

5

    push temp2

6

    push temp3

7

8

    cpi anzeige, 1

9

    brne loop

Muss jetzt nicht 'der' Fehler sein, aber viele solcher Sprünge hält der 
Stack nicht aus.
Ist wohl auch ein gutes Beispiel, für das, was die Leute vorher meinten 
bzgl. Strukturierung.

Die LCD-Routinen in einer ISR aufrufen ist nicht gerade eine gute 
Lösung, da diese sehr viel Zeit in Anspruch nehmen und du immer noch in 
einer ISR hängst.

Mark

Ein Programm, dass alle 15 min was mache soll braucht einen Timer 
bestenfalls als Zeitbasis, sonst gar nichts. Der Rest erfolgt einfach 
und umkompliziert in der Hauptschleife, siehe Interrupt. Die meiste 
Zeit verbringt der Controller im Sleep Mode.

DFC77 nutzt man nur, um vielleicht einmal am Tag seine interne Uhr zu 
synchronisieren, keinesfalls um dauerhaft eine Zeitbasis daraus 
abzuleiten. Denn dazu ist der Empfang viel zu unberechenbar. Kann auch 
ein Grund für den Absturz sein.

Siehe AVR - Die genaue Sekunde / RTC

> Ich kann leider nichts anderes
> und wir machen in der Ausbildung und in der Schule auch nur ASM.

Hm, ist dieser Programmierstil wirklich das was man so in der Schule 
lehrt und lernt ????   *** schauder ****

@  Wegstaben Verbuchsler (wegstabenverbuchsler)

>Hm, ist dieser Programmierstil wirklich das was man so in der Schule
>lehrt und lernt ????   *** schauder ****

Vielleicht haben die einen italienischen Informatiklehrer?

"Ise programire die Controller so wie meine Mama machte die Spaghetti. . 
."

;-)

@  Michael Mayer (eos400dman)

>    * Main.asm (20.5 KB, 68 Downloads) | Codeansicht
>    * adc2.asm (1.2 KB, 16 Downloads) | Codeansicht
>    * dcf77dec.asm (3.8 KB, 17 Downloads) | Codeansicht
>    * eeprom_logdaten_schreiben.asm (5.4 KB, 17 Downloads) | Codeansicht
>    * EEPROM_routine.asm (1.2 KB, 7 Downloads) | Codeansicht
>    * extrem_wert.asm (5.5 KB, 16 Downloads) | Codeansicht
>    * lcd-routines.asm (8.9 KB, 16 Downloads) | Codeansicht
>    * Messvorgang.asm (2.4 KB, 15 Downloads) | Codeansicht
>    * twi_routine.asm (1.4 KB, 8 Downloads) | Codeansicht

http://www.mikrocontroller.net/articles/Bildformate#Mehrere_Dateien_zusammenfassen

>War vllt. etwas hoch gegriffen. Ich glaube es zu verstehen.

Wer glaubt zu wissen, muß wissen er glaubt.

>Und hier mal das ganze Programm ich hoffe es ist verständlich.

Teils teils.

http://www.mikrocontroller.net/articles/Strukturierte_Programmierung_auf_Mikrocontrollern#Benennung_von_Variablen.2C_Makros.2C_Nutzung_von_Anweisungen

Gerade bei Assembler muss man ausgiebeig kommentieren. Das geht los bei 
einer Funktionsbeschreibeung für JEDE Funktion bis hin zu Kommentaren 
für fast jede Zeile, wenn es eine knifflige Funktion ist.

Der Hammer ist natürlich die Sache mit anzeige1-7. Du schreibst jetz 
100mal in Schönschrift.

"Eine Funktion ist eine Funktion und wird IMMMER mit (R)CALL augerufen 
und RET verlassen!"

Wenn gleich es hier funktioniert, so wirst du dier mit diesem 
Kauderwelsch ganz fix ins Knie schiessen.

Und was macht INT2? Hängt dort ein Taster dran? Mit dem amn die Anzeige 
weiterschalten kann? Die Ausgabe dort ist ganz schlecht, denn 
währenddessen sind dein Ineterrupts gesperrt. Solche langsamen, 
zeitunkritischen, geradezu nebensächlichen Ausgaben macht man in aller 
Ruhe in der Hauptschleife. Ausserdem muss so ein Taster entprellt 
werden, siehe Entprellung. Macht man meist sinnvollerweise in 
Software in einem Timer-Interrupt.

Es ist ja auch sch, dass du versucht Interrupts zu nutzen, aber man kann 
es auch überteiben. Für das bischen Messung braucht man keinen 
ADC-Interrupt, macht die Sache nur unnötig komplex und bringt kaum was. 
Nimm einer normale Funktion.

Vor allem in ASM sollte man mit RJMP sparsam umgehen. Praktisch nur für 
Verzweigungen nach Vergleichen und ähnliches. Ansonsten packt man alles 
in Funktion und nutzt (R)CALL.

MFG
Falk

Falk Brunner schrieb:
> Gerade bei Assembler muss man ausgiebeig kommentieren.
Aber nicht so:

1

   mov   r0,r3         ; kopiere den Inhalt vom Register 3 ins Register 1

2

   clr   wert_h        ; lösche Wert_h

3

   clr   wert_l        ; lösche Wert_h

4

   rcall i2c_start     ; rufe TWI start auf

5

   rcall i2c_write     ; schreibe über TWI

6

   rcall i2c_stop      ; rufe TWI stop auf

Apfelmus ist Mus aus Äpfeln.
;-)

Wegstaben Verbuchsler schrieb:
>> Ich kann leider nichts anderes
>> und wir machen in der Ausbildung und in der Schule auch nur ASM.
>
> Hm, ist dieser Programmierstil wirklich das was man so in der Schule
> lehrt und lernt ????   *** schauder ****

In der Schule lernt man in der Regel gar keinen Programmierstil.

Peter II schrieb:
> und dann auch noch falsch.
Richtig... ;-)

Das ist dir beim

1

   clr   wert_l        ; lösche Wert_h

aber nicht aufgefallen?  :-o

@Simon K. (simon) Benutzerseite

>In der Schule lernt man in der Regel gar keinen Programmierstil.

Naja, würde ich nicht so sagen. Ich hab damals schon ein paar 
grundlegend richtige Programmiertechniken gelernt bekommen, auch wenn 
ich sie nur widerwillig angenommen habe ;-)
Als Basic-Programmierer dann in Pascal plötzlich das geliebte GOTO nicht 
mehr nutzen zu dürfen war schon hart. Aber am Ende hat die Vernunft 
gesiegt.

MFG
Falk

Michael Mayer schrieb:
> ich arbeite gerade an einer Wasserstandsmessung für einen Bach.

Da die Aufgabenstellung klar ist und die Lösung im Grunde funktioniert, 
würde ich die Probleme mit ASM als Anlaß nehmen, auf 'C' umzusteigen.

Alles ist viel einfacher und transparenter, kein Vertun mit byte, int, 
long und deren Vergleichsoperationen und bedingten Verzweigungen; kein 
Problem mit der Formulierung irgendwelcher Berechnungen.
Was mit ASM 20 Zeilen brauchte, steht in einer Zeile und ist leicht 
verständlich.
Nach ein bißchen Einarbeitung wirst Du 'C' als Segen empfinden!

@  Frank Q. (franki)

>würde ich die Probleme mit ASM als Anlaß nehmen, auf 'C' umzusteigen.

Ich nicht. Er kann die Grundprinzipien der strukturierten Programmierung 
an diesem Beispiel auch und besonders in ASM umstetzen. Dazu muss er 
nicht den Code wegschmeißen und neu schreiben, aber halt mal gescheit 
strukturieren. Und das halt vor allem durch Nachdenken mit dem berühmten 
Blatt Papier.

>Alles ist viel einfacher und transparenter, kein Vertun mit byte, int,
>long und deren Vergleichsoperationen und bedingten Verzweigungen;

Wenn das mal kein Irrtum ist. Wieviele Leute/Anfänger fallen auf die 
impliziten INT Konstanten rein . . .?

Taufrisch

Beitrag "unsigned long int Berechnung"

Das man mit C sich viel Krümelkram von Hals hält und deutlich höhere 
Komplexitäten mit deutlich weniger Aufwand beherrschen kann steht ausser 
Frage.

MFG
Falk

Falk Brunner schrieb:
> Dass man mit C sich viel Krümelkram von Hals hält und deutlich höhere
> Komplexitäten mit deutlich weniger Aufwand beherrschen kann steht ausser
> Frage.

Und darum geht es doch wohl!

spess53 schrieb:
> Und erzeugt Code wie 50 Zeilen Assembler (musste sein).

Und weil heutige Compiler recht gut optimieren, ist auch die Codegröße 
des fertigen Programmes voll in Ordnung. (mußte auch sein :-)

Mindstens der Pfad hier geht schief, weil mehr gepusht wird als gepopt:
wert_aktuell:  push
loop:
messen_sprung:
messen:        push+pop
extrem_wert:   push+pop
wert_aktuell:  push

Michael Mayer schrieb:
> wir machen in der Ausbildung und in
> der Schule auch nur ASM

Damit hat sich hier wohl die (übliche) Streiterei um C/ASM erübrigt, bzw 
sollte mit dem entsprechenden Lehrer weitergeführt werden. 'C' zu nehmen 
ist hier wohl so ein sinnvoller Vorschlag wie jemandem bei Problemen in 
Algebra ein Stochastik-buch zu empfehlen ;-)

Aber mal konkret zum Thema:
Ich denke(nach Durchsicht des gesamten Codes), außer dem o.g. Fehler in 
'wert_aktuell' sehe ich zumindest keine strukturellen Probleme, auch 
wenn ich jetzt nicht überprüft habe, ob zu jedem push auch das pop 
vorhanden ist.
Nimm die PUSHs und POPs aus der 'wert_aktuell', die sind im Zusammenhang 
überflüssig und das 'brne loop' füllt da es die 'pop's überspringt nach 
und nach den Stack. Wenn ich das richtig sehe, wird 'counter' alle 
256.000 Takte inkrementiert, alle 15-mal landet das in der 
'wert_aktuell'-Routine (ca. 1/sec) und holt dann ggf. 4 bytes nicht vom 
Stack, das Ganze 512-mal und der SRAM ist voll (nachdem alle 
gespeicherten Werte überschrieben wurden).
Ich habe mich nicht genau in den ganzen Programmablauf eingedacht, aber 
die Zeit mit 15-20 Minuten bis Absturz könnte passen. Durch die langen 
ISRs wird ggf. der Timer0ovfl mal übersprungen.

BTW: ich habe '84 schon Lehrer zur Verzweifelung getrieben wenn ich die 
Aufgaben außer in Pascal auch in Assembler abgegeben habe (der Größen- 
und Geschwindigkeitsvergleich war wohl 'etwas' hart für die Leute)

Mark

Ich die Parameter so aendern, sodass es jede Minute misst, und dann 
schauen wann es abstuerzt...

>'adc2.asm' kann man (getestet) mit weniger als 30 Programmzeilen (gegen
>78) realisieren.
Kannst du das bitte mal hoch laden?? Wäre echt net.


>sondern ein Hinweis darauf, dass derjenige "heiß" darauf ist,
>geile Programme zu hacken und vor großen Aufgaben nicht zurückschreckt
Finde ich auch. Lieber ist es nicht top strukturiert aber ich versuche 
es hinzu bekomme als wenn ich gleich aufgebe und es sein lasse.

ich mach mich jetzt mal an die Umsetzung der Tipps.

Gruß Michael

Danke, hab deinen Code mal eingebaut. Allerdings springt er jetzt falsch 
aus dem ADC Interrupt zurück.

Ganz zum Anfang. Er macht die komplette Initialisierung neu.

Nein, dann muss der Fehler im restlichen Programm liegen.

Guten Abend,
also das Porgramm läuft jetzt seit ca. 14 Stunden am Stück ohne 
Probleme.
Nur sieht meine loop Schleife jetzt so aus:

1

loop:

2

    cpi counter, 5

3

    breq adc_start

4

loop1:

5

    cpi counter, 15

6

    breq messen_sprung

7

loop2:

8

    cpi counter, 16

9

    brsh counter_clear

10

loop2_1:

11

    lds temp1, min

12

    cpi temp1, $00

13

    breq eeprom_write_sprung

14

    cpi temp1, $15

15

    breq eeprom_write_sprung

16

    cpi temp1, $30

17

    breq eeprom_write_sprung

18

    cpi temp1, $45

19

    breq eeprom_write_sprung

20

loop3:

21

    cpi temp1, $05

22

    breq eeprom_flag_clear

23

    cpi temp1, $20

24

    breq eeprom_flag_clear

25

    cpi temp1, $35

26

    breq eeprom_flag_clear

27

    cpi temp1, $50

28

    breq eeprom_flag_clear

29

loop4:

30

    cpi temp1, $05

31

    breq eeprom_tag_flag_clear

32

loop5:

33

    cpi temp1, $05

34

    breq eeprom_woche_flag_clear

35

loop6:

36

    lds temp1, stu

37

    cpi temp1, $00

38

    breq eeprom_tag_clear_sprung

39

loop100: 

40

    lds temp1, wtag

41

    cpi temp1, $00

42

    breq eeprom_woche_clear_sprung

43

loop200:  

44

    cpi anzeige, 1

45

    breq led_an_sprung

46

    cpi anzeige, 2

47

    breq anzeige2_sprung

48

    cpi anzeige, 3

49

    breq anzeige3_sprung

50

    cpi anzeige, 4

51

    breq anzeige4_sprung

52

    cpi anzeige, 5

53

    breq anzeige5_sprung

54

    cpi anzeige, 6

55

    breq anzeige6_sprung

56

    cpi anzeige, 7

57

    breq anzeige7_sprung

58

59

     rjmp loop

Kann ich das auch ohne die ganzen Sprungmarker machen? Mit ret komme ich 
ja nach einer Verzweigung nicht zurück.