Denkbare Möglichkeiten: Prorgamm "spinnt"

Erst einmal danke für die Antwort.

ad 1)
Dürfte ja durch die im roboternetz ausgeführte Variante von mir 
abgeprüft sein.
Lokale Variablen habe ich nicht übermäßig, dass es ins Auge fallen 
würde. Globale volatile deklarierte sind es ein paar, da im Programm 
viele Interrupts vorkommen:
- Timer1 OVF
- Timer 1 CompA
- Timer 1 CompB
- Int0
- ICP


ad 2)
Pointer verwende ich im Programm explizit nicht, es sei denn, Sie sind 
durch vorhandene Bibliotheken eingebunden und werden implizit durch den 
Compiler angewandt.

ad 3)
Leider bereits auch schon versucht (habe die Schaltung hier 5x aufgebaut 
gelötet).

cyblord ---- schrieb:
> Beschreibst du jetzt allen ernstes in Prosa dein Programm, anstatt es zu
> posten? Zeig deinen Code.

einfach erst mal lesen?

> Leider kann/darf ich das Programm
> nicht veröffentlichen

schwer etwas zu sagen wenn von dem code so wenig bekannt ist,
aber mal eine Idee.
Vieleicht ist ja gar nicht der Speicher das Problem, sondern irgend 
welche Timings, die ab einer gewissen menge von eingebundenen Modulen 
nicht mehr eingehalten werden können.

cyblord ---- schrieb:
> Peter II schrieb:cyblord ---- schrieb:Beschreibst du jetzt allen ernstes
> in Prosa dein Programm, anstatt es zu posten? Zeig deinen Code.einfach
> erst mal lesen?Leider kann/darf ich das Programm nicht veröffentlichenJo
> dann kann auch niemand helfen. So einfach ist das.

NIEMAND nicht. Aber vllt. JEMAND ;-)

Titel für ein hermetisches Drama:  Denkbare Möglichkeiten

wenn es wirklich nachvollziehbar ist, sollte man es doch auch debuggen 
können. Einfach schrittweise durchgehen und schauen was in den Variablen 
steht.

cyblord ---- schrieb:
> Alle wahrscheinlichen Ursachen (Stacküberlauf, wilde Pointer usw.)
> werden ja kategorisch ausgeschlossen.

Es ist eben ein fehlerfreies Programm und mich wundert, dass noch 
niemand die Abblockkondensatoren moniert hat oder die Anschlußleitung 
zum LCD, die bestimmt länger als 2cm ist :-)

Im Ernst: eine Woche lang liegen lassen, um noch einmal in Ruhe alles 
durchzutesten oder komplett neu schreiben, was bei klarer Zielsetzung 
und einem ATmega8 kein großes Problem sein sollte.

Daniel Mader schrieb:

> Folgendes Problem:
> Zum Debuggen verwende ich ein LCD. Um auch hier die Frage vorweg zu
> nehmen: Strings sind per PROGMEM im Flash ausgelagert. Je mehr Zeilen
> bzw. Inhalt ich auf dem LCD ausgebe, desto mehr der Programmverbrauch im
> Flash (wegen PROGMEM). Ab einem gewissen Programmgröße (jedoch kleiner
> max. und SRAM bleibt unverändert), bekomme ich auf dem LCD nur wirre
> Zeichen angezeigt von den Strings

Handelt es sich um einen µC mit mehr als 64kByte Flash? Dann ist das mit 
hoher Wahrscheinlichkeit die Ursache des Problems. Sobald eine 
Zeichenkette oder eine im flash abgelegte Tabelle oberhalb der 
64k-Grenze zu liegen kommen, passiert Mist.

Soweit ich weiß, ist das aber in neueren Versionen des avrgcc behoben, 
da braucht man dann auch dieses PROGMEM-Zeuchs nicht mehr.

Überflüssig zu erwähnen, daß es in Assembler nie ein Problem dargestellt 
hat...

Durch Deine Interrupts und Dein sehr großes Programm verursachst Du 
Stack-Überläufe.
Das läßt sich ggf. verhindern, indem Du auf Strings und Arrays 
verzichtest.
- Lade die Zeichen einzeln aus dem EEPROM wenn Du sie ausgibst-
- Überprüfe die Zykluszeiten Deiner Interrups und vermeide Interrups, wo 
immer es geht.
- Sei sparsam mit Variablen. Statt 6 oder 8 zu deklarieren, die alle nur 
1 Mal gebraucht werden, kann man bisweilen mit weniger auskommen, indem 
man kleinere Zwischenergebnisse berechnet und die selben Variablen 
mehrfach verwendet.

Hi
Die Aussage "Programm spinnt" find ich gut. Alle wissen, ein Programm 
macht genau das was der Programmierer programmiert hat. Nicht mehr und 
nicht weniger... eben genau das. Soviel zum Thema.
Aber vielleicht hab ich auch was nützliches beizutragen.
Es ist die Rede von "wenigen" globalen Variablen, aber von vielen 
lokalen. Na ja, auch lokale Variablen belasten den SRAm, also auch den 
Bereich Stack. Und wenn verschachtelte Aufrufe den Stack des öfteren 
bemühen, ist es leicht möglich, irgendwann ein paar Zeiger mal zu 
verbiegen. Ob das ein gepushtes Register ist, ein zerschossener Stack 
oder eine unsinnig überschriebene lokalvariable ist da völlig wurscht.
Ach ja, und wil's der Proggrammierer ausschließt, heißt es, das Programm 
spinnt.....
Gruß oldmax

Immer mehr Teile weglassen (auskommentieren). Wenn das Programm dann 
plötzlich wieder geht, dann ist des letzte auskommentierte Teil am 
Fehler beteiligt.


Ansonsten: mit Kupferpyramiden gegen Erdstrahlen sichern.

Ich tippe auf compiler-prob oder unsaubere programmierung. Alle warnings 
anschalten (-Wall), alle Optimierungen aus (-O0) und die compiler/linker 
logs genau durchlesen und alle warnings verstehen und die durch sauberes 
Coding vermeidbaren durch Codeänderung beseitigen.

MfG,

PS:
Posten der Compilerlogs verletzten keine Copyrights des Arbeitsgebers.

PittyJ schrieb:
> Immer mehr Teile weglassen (auskommentieren). Wenn das Programm dann
> plötzlich wieder geht, dann ist des letzte auskommentierte Teil am
> Fehler beteiligt.

so einfach ist das leider nicht. Bei einem Überschreiber im Speicher, 
kann das auskommentieren von variabel das Problem schon verschwinden 
lassen ohne das der Fehler an dieser Stelle ist.

Peter Dannegger schrieb:
> Der AVR kann keine nestet Interrupts.

Das kann er wohl (sei im Interrupt).

Zum Problem:

Sollte ein Bootloader vorhanden sein, ist der nutzbare Flash natürlich 
auch kleiner. Das hört sich für mich noch am logischten an, wenn man 
grobe Programmierfehler ausschließt.

Hi
Eigentlich ist es ja egal, ob das Programm läuft oder nicht... ist ja 
nicht von mir und alles was ich kaufe und nicht funktioniert wird 
reklamiert. Zugegeben, immer nur so ne Montagsproduktion macht keien 
Spaß, aber man kann ja das Produkt wechseln.
Was ich damit sagen will, eigentlich ist's ja schon vielfältig gesagt, 
ein unveränderbarer Teil des Controllers wird ja wohl nicht die Ursache 
sein, also ist der änderbare Teil, (SRAM) maßgeblich dranbeteiligt. Auch 
Register sind veränderbar, sonst könnt der Controller ja gar nix machen. 
Nun kommt die Frage: Anfangs läuft das Programm und irgendwann steigt es 
aus, liefert Müll. Na, immer noch bei Flash-Grenzen?
Wenn der TO lesen kann, dann hat er bestimmt mitbekommen, das gefühlte 
70% den Stack verdächtigen. Auch ohne das Programm zu kennen. Auch ich 
seh da das Problem und an der Aussage, das ja nur lokale Variablen in 
größerer Zahl benutzt werden. Vielleicht ist es nicht angekommen, daher 
noch einmal der Hinweis: Eine Variable ist eine veränderbare 
Speicherzelle, entweder ein Register oder ein Stück SRAM. ( Ich weiß, 
Register sind auch SRAM)
Und die werden bei lokal angelegten variablen auch auf dem Stack 
angelegt. Ein rekursi´ver Aufruf mit lokalen VAriablen füllt sehr wohl 
relativ schnell den Stack. Das muss noch nicht einmal von einem 
Interrupt kommen.
Also, noch viel Spaß beim heiteren Rätselraten.
Gruß oldmax

Ein Programm sollte immer mit einer Debugfunktionalitaet geschrieben 
werden, denn Debugging ist Teil der Entwicklung. Nicht irgednwas, das 
dummerweise in schlechten Fallen noch eingebaut werden muss. Also lieber 
einen naechst groesseren Controller mit einem UART mehr einbauen.

Dasselbe gilt auch fuer Hardware.

Der Rest wurde alles gesagt. Die fehlerhafte Funktionalitaet eingrenzen. 
Was kann man alles weglassen bis der Fehler nicht mehr auftritt.

oldmax schrieb:
> Auch ich
> seh da das Problem und an der Aussage, das ja nur lokale Variablen in
> größerer Zahl benutzt werden.

Danke für alle, die den Blick in die Glaskugel gewagt haben.
Obige Aussage habe ich aber eher umgekehrt getroffen. Es sind 
überschaubar lokale Variablen, aber etwas mehr global volatile 
deklarierte.

Oliver S. schrieb:
> Woher weisst du, ob deine Speicherprüfroutine richtig funktioniert, wenn
> der Rest des Programms Amok läuft?

Irgend eine Macke wird das Programm schon haben, sonst würde da
ja nicht so ein Murks raus kommen. Da bleibt einem doch ohnehin
nichts anderes überig, als das Programm Schritt für Schritt
abzuarbeiten, entweder simuliert, per Debugging oder emulieren
(wegen der IRQs).
Würde da der Einsatz eines STK500/600 nicht was bringen?
(Hab damit leider keine Erfahrung).

Hi
>Danke für alle, die den Blick in die Glaskugel gewagt haben.
>Obige Aussage habe ich aber eher umgekehrt getroffen. Es sind
>überschaubar lokale Variablen, aber etwas mehr global volatile
>deklarierte.
Sorry, hab ich anders gelesen, aber trotzdem, die global deklarierten 
kennst du. Lokal, ist im Prinzip auch klar, es sei denn du hast 
rekursive Aufrufe...... Und dann sind das schon nicht mehr 
"überschaubare". Aber egal, du weißt, es ist ok, wir nicht.
Gruß oldmax

Mir hat mal folgende Methode geholfen:

Ich habe zwei globale Variablen zum Test eingebaut, und sie mit einem 
bestimmten Wert intialisiert. Vor und nach dem Aufruf verdächtiger 
Funktionen habe ich diese Variablen über den seriellen Port ausgegeben:

1

int test1=12345;

2

... andere variablen

3

int test2=11111;

4

5

int main() {

6

  initserial();

7

  int i;

8

  while(1) {

9

    printf("i=%i, 1=%i, 2=%i",i,test1,test2);

10

    verdaechtige_funktion(parameter);

11

    printf("i=%i, 1=%i, 2=%i",i,test1,test2);

12

    i++;

13

  }

14

}

Dazu habe ich eine bewährte Library eingebunden, die den seriellen Port 
an stdout bindet.

Irgendwann nach einer scheinbar zufälligen Anzahl von 
Schleifendurchläufen wurde eine der beiden Test-Variablen unerwartet 
verändert. Also lag die Vermutung nahe, dass irgendein unregeläßiges 
Ereignis den Fehler auslöst. In meinem Fall war ein externer Interrupt. 
Die Interruptroutine war zwar Ok, aber die Vorgänge, die NACH dem 
Interrupt aus der Hauptschleife heraus ausgeführt wurden, brachten den 
Speicher durcheinander.

Nachdem ich nun wusste, welche Funktion innerhalb der Hauptschleife der 
Übeltäter war, konnte ich entsprechende printf Ausgaben in eben diese 
Funktion einbauen.

Die eigentliche Ursache war dann schnell gefunden (es wurden Daten von 
einem externen Chip in ein Array geladen, das zu klein war).

Versuche es mal mit dieser Methode. Falls Du keine serielle Library 
hast, der du vertraust, dann nimm das:

1

#include <stdint.h>

2

#include <stdio.h>

3

#include <avr/io.h>

4

#include <util/setbaud.h>

5

6

// The serial bitrate and CPU clock frequency is usually set in the Makefile

7

// #define BAUD 115200

8

// #define F_CPU 20000000

9

10

static int serial_write(char, FILE *);

11

static FILE serialPort = FDEV_SETUP_STREAM(serial_write, null, _FDEV_SETUP_WRITE);

12

13

// Write a character to the serial port

14

static int serial_write(char c, FILE *f) {

15

    // wait until transmitter is ready

16

    loop_until_bit_is_set(UCSRA, UDRE);

17

    UDR = c;

18

    return 0;

19

}

20

21

// Initialize the serial port

22

void initserial(void) {

23

    // set baudrate

24

    UBRRH = UBRRH_VALUE;

25

    UBRRL = UBRRL_VALUE;

26

    #if USE_2X

27

        UCSRA |= (1 << U2X);

28

    #else

29

        UCSRA &= ~(1 << U2X);

30

    #endif

31

    // framing format 8N1

32

    #ifdef URSEL

33

        UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0);

34

    #else 

35

        UCSRC = (1<<UCSZ1) | (1<<UCSZ0);

36

    #endif

37

    // enable transmitter

38

    UCSRB = (1<<TXEN);

39

    // Bind stdout to the serial port

40

    stdout = &serialPort;

41

}

Dieser Code kommt ohne Interrupts und Pufferspeicher aus. Die 
Warscheinlichkeit, dass die Textausgabe versagt, weil der Speicher 
durcheinander geraten ist, wird so minimiert.
Du must beim Programmstart einmal die Funktion initserial() aufrufen. 
Danach kannst Du mit sämtlichen Ausgabe-Funktionen der standard Library 
arbeiten (printf, puts, putc und so weiter).

printf() auf einen AVR? Wuerd ich mir nie antun. Viel zu klotzig.

Das einfachste und kleinste zum debuggen ist wahrscheinlich ein 
einzelner Pin, den man als ausgang definiert und hoch-runter zieht. Die 
naechst bessere loesung ist ein zweiter Pin, auf den man die Aenderung 
signalisiert. zB auf dessen steigende Flanke sind auf dem ersten pin die 
daten gueltig.

Falls das laeuft kann man den UART in betrieb nehmen. Beim UART muss man 
beachten, dass man nur soviele Daten rausschicken kann wie die Baudrate 
schnell ist.

> Beim UART muss man beachten, dass man nur soviele Daten
> rausschicken kann wie die Baudrate schnell ist.

Wie meinst du das? Darf man bei 9600 Baud nur 9600 Zeichen senden? Und 
was passiert danach?

9600  Baud bedeutet 9600 Bit, inkl. Start, Stop, Parity. Dh sind dann 
max 960 Bytes/sek. Wenn man mehr auf das UART schreibt kommt nur noch 
Muell.

Hi

Stockki schrieb:
> 9600  Baud bedeutet 9600 Bit, inkl. Start, Stop, Parity. Dh sind dann
> max 960 Bytes/sek. Wenn man mehr auf das UART schreibt kommt nur noch
> Muell.

Nun bin auch ich sprachlos...
Leute, lest doch bitte erst mal das was ihr da schreibt. Es soll hier 
Teilnehmer geben, die glauben das dann auch und verkünden es weiter. Und 
wenn das zufällig eine Lehrkraft mit dem Ehrgeiz seinen Schülern 
Mikrocontrollern beizubringen ist, multipliziert sich das Ganze Wissen 
und wir können uns in Zukunft von den Ausflügen Richtung Weltall 
verabschieden.
Gruß oldmax

>Nun bin auch ich sprachlos...

Was stimmt denn nicht?

oldmax schrieb:
> Hi
>
> Stockki schrieb:
>> 9600  Baud bedeutet 9600 Bit, inkl. Start, Stop, Parity. Dh sind dann
>> max 960 Bytes/sek.
>
> Nun bin auch ich sprachlos...
> Leute, lest doch bitte erst mal das was ihr da schreibt. Es soll hier
> Teilnehmer geben, die glauben das dann auch und verkünden es weiter. Und
> wenn das zufällig eine Lehrkraft mit dem Ehrgeiz seinen Schülern
> Mikrocontrollern beizubringen ist, multipliziert sich das Ganze Wissen
> und wir können uns in Zukunft von den Ausflügen Richtung Weltall
> verabschieden.
> Gruß oldmax

Nun, der erste Teil ist ja richtig. Wenn etwas kritikwürdig wäre, dann 
das hier:
>> Wenn man mehr auf das UART schreibt kommt nur noch
>> Muell.

Bei korrekter Programmierung schafft man es auf Seite des µC nicht, mehr 
Bytes pro Sekunde zu schreiben, da kommt dann auch kein Müll.

Der entsteht nur wenn: der Code Murks ist, die Übertragungsraten von 
Sender und Empfänger nicht stimmen, oder der Empfänger beschäftigt ist 
und die Bytes nicht schnell genug abholt.

Ob dieser kleine Fehler es verdient hat, mit dem Geschwurbel über den 
Untergang des Abendlandes beantwortet zu werden, darf bezweifelt werden.

Außerdem, wenn Du schon im belehrenden Tonfall loslegst, dann schreib' 
halt hin, was Deiner Meinung nach richtig wäre, damit Zillionen anderer 
Schüler nicht irre gehen.

Hi

MWS schrieb:
> Nun, der erste Teil ist ja richtig. Wenn etwas kritikwürdig wäre, dann
> das hier:
>>> Wenn man mehr auf das UART schreibt kommt nur noch
>>> Muell.
>
> Bei korrekter Programmierung schafft man es auf Seite des µC nicht, mehr
> Bytes pro Sekunde zu schreiben, da kommt dann auch kein Müll.

Es mag sein, das der erste Teil der Aussage richtig ist und dennoch ist 
die Antwort schlichtweg falsch. Auch deine Antwort hinkt gewaltig. Wie 
bitteschön sieht denn eine unkorrekte Programmierung aus, die einen mit 
9600 Byte betriebenen UART in die Lage versetzt, mehr als 960 Bytes in 
der Sekunde zu senden? Sicherlich ist es durchaus machbar, mehr als 960 
Bytes in einer Sekunde in einem Sendepuffer abzulegen. Na und, dann 
dauert die Übertragung eben mehr als eine Sekunde. Wenn der Puffer groß 
genug und nach einer Sendung entsprechen Zeit bis zur nächsten Datenflut 
ist, kommt da auch nix durcheinander.
Mir braucht ihr über Datentransfer keine Belehrung zukommen lassen, ich 
weiß wie's funktioniert, aber der TO hat ein Problem mit ganz anderen 
Ursachen. Nun kommt hier noch tief fundierte die Diskussion über UART 
hinzu. Bravo
Gruß oldmax

oldmax schrieb:
> Wie bitteschön sieht denn eine unkorrekte Programmierung aus

In's UDR schreiben, ohne zu überprüfen ob's leer ist.

> die einen mit
> 9600 Byte betriebenen UART in die Lage versetzt, mehr als 960 Bytes in
> der Sekunde zu senden?

Diese Vermutung hat niemand in den Raum gestellt, außer Dir jetzt 
vielleicht. Denn so lautete das ursprünglich:

Stockki schrieb:
> Wenn man mehr auf das UART schreibt kommt nur noch
> Muell.

Das trifft bei falschem Code, s.o. zu, welche Form "Muell" wurde nicht 
näher definiert.

oldmax schrieb:
> Mir braucht ihr über Datentransfer keine Belehrung zukommen lassen, ich
> weiß wie's funktioniert

Den Eindruck hatte ich nicht. Hättest Du's gewusst, wäre es Dir ein 
Leichtes gewesen, den Fehler in einem Satz zu berichtigen, statt in drei 
Sätzen und mit vielen Worten das vermeintliche Nichtwissen des 
Schreibers im Rundumschlag zu kritisieren.

oldmax schrieb:
> wir können uns in Zukunft von den Ausflügen Richtung Weltall
> verabschieden.

M.E. bist Du da der Einzige, der auf der Erde sitzenbleibt. :D

oldmax schrieb:
> Nun kommt hier noch tief fundierte die Diskussion über UART
> hinzu. Bravo

Ist doch egal, Threads hier haben durchaus den Reiz, dass die mal 
abdriften, deswegen sind sie nicht weniger interessant. Das Ansinnen des 
TEs per Glaskugel in Ferndiagnose eine Lösung seines Problems zu 
erhalten, ist eh' nicht machbar. Eine Diskussion über UART ändert daran 
nichts und kann deshalb auch nicht schaden.

Hi alle,
ihr seid mir zuvor gekommen. Ich musste mich erstmal im stillen 
kämmerlein abregen.

Mein primitiver Beispiel-Code sendet Zeichen so:

1

static int serial_write(char c, FILE *f) {

2

    // wait until transmitter is ready

3

    loop_until_bit_is_set(UCSRA, UDRE);

4

    UDR = c;

5

    return 0;

6

}

Ich habe also bereit vor Wolfis Kommentar gezeigt, wie man es richtig 
macht. Abgesehen davon sind die entsprechenden Erlärungen im Datenblatt 
meiner Meinugn nach nicht zu übersehen.