Arduino Uno, Setup wird dauerhaft wiederholt

Guten Tag Arduino-Forum,

ich wollte heute ein Anwendung schreiben mit der ich einige Bauteile, die am Arduino Uno angeschlossen sind, zu bedienen.
Die Kommunikation soll über die Serielle Schnittstelle erfolgen.

So sieht der Hauptsketch aus:

#include "SMTCommander.h"
#include "SMTInitializer.h"

/* Haupteinstiegspunkt fuer Arduino-Treiber */
SMTInitializer initializer;
SMTCommander commander;
byte message[MSGLEN];

char debugBuffer[80];

#define waiting 5000 //Nur um die Ausgabe nicht so schnell rennen zu lassen für das Beispiel
int debugCounter=0;

void setup()
{
	/* Initialisierung: Leere Nachricht */
	for(int i = 0; i < MSGLEN; ++i)
		message[i] = 0;	

	Serial.begin(9600);
	delay(waiting);
	/* Initialisiert alle Ports angesprochen werden */
	initializer.initBoard();
        Serial.println("Board initialisiert");
	delay(waiting);
	
	/* uebergibt die Konfiguration an den Kommandointerpreter */
	struct _PORTCONFIG tmpConfiguration;
	initializer.getPortConfiguration(&tmpConfiguration);
	commander.setConfiguration(&tmpConfiguration);
	
        Serial.println("Starte Anfangssequenz");
	commander.startUpCommand();
        delay(waiting);
        Serial.println("Anfangssequenz beendet");	
        
        sprintf(debugBuffer, ">> Zaehler %d\n", debugCounter);
        delay(waiting);
        Serial.println(debugCounter);
        Serial.println("Warten");
	
        ++debugCounter;
}

void loop()
{ /* leer , es wird auf ein SerialEvent gewartet */ }

void serialEvent()
{
	if(Serial.available() == 5)
	{
		for(int i = 0; i < MSGLEN; i++)
		{	
			delay(2);
			message[i] = Serial.read();
		}
		if((message[0] == 128) && (message[4] == 127))
		{
			if(commander.validateMessage(message[1], message[2], message[3]))
			{
				commander.doCommand();
				message[0] = 228; message[1] = 0x02; message[2] = 0x06; message[3] = 0x03; message[4] = 227;
				delay(100);
				Serial.write(message,MSGLEN);
			}
		}
		message[0] = 0; message[4] = 0;
	}
}

Ich habe den Sketch sowohl in der Arduino Developer Enviroment hochgeladen als auch im Atmel Studio. Öffne ich nun nach dem Hochladen den Serial Monitor bekomme ich folgende Ausgabe:

Board initialisiert
In PortConfiguration
Starte Anfangssequenz
Anfangssequenz beendet
0
EnöBoard initialisiert
In PortConfiguration
Starte Anfangssequenz
Anfangssequenz beendet
0
EBoard initialisiert
In PortConfiguration
Starte Anfangssequenz
Anfangssequenz beendet
0
En

Vor der Ausgabe “Board initialisiert” wird kein Zeilenumbruch mehr gemacht und die Debugvariable bleibt immer 0.
Die Anfangssequnz-Methode nutzt die Initialisierung die mit der folgende Zeile gesetzt wird:

commander.setConfiguration(&tmpConfiguration);

Die Seuquenz ist in Ordnung und liefert das gewünschte Ergebnis. Folglich nehme ich an, dass die Initialisierung geklappt hat.

Versuchsaufbau: Arduino Uno mit je einer angeschlossenen LEDs an den Pins(3,5,9,11).

Vielleicht habe ich ein Verständnisproblem mit der Schnittstelle zum Computer?

Danke für eure Hilfe.

Wie gross sind die Strombegrenzungs-Widerstände an den LEDs? Wie wird der Arduino mit Strom versorgt? Wo sind die Links zu den verwendeten Bibliotheken?

Das kann ich dir gerne alles sagen.
Der Arduino wird über ein USB Kabel mit Strom versorgt. Ich hoffe das dieser Aspekt kein Problem ist mit der Kommunikation.
Ich habe aber auch schon eine Kommunikation aufbauen können. Nur leider funktioniert es seit meinem Problem nicht mehr.
Widerstände sind vor jeder LED je 220 Ohm.
Die Biliotheken habe ich zu Testzwecken selber geschrieben. Ich habe zu diesem Thema etwas in den Arduino Referenzen gelesen. Im Anhang ist mein Projekt zu finden.

Vielleicht noch interessant. Ich sende die Kommandos auf über Applikation in C#. Hatte gestern eine funktionierende Kommunikation aufgebaut, muss meine Änderungen nochmals prüfen.

SMTDriver.zip (3.5 KB)

Sieht so aus als ob der Controller resettet. Das kann passieren wenn man über Array Grenzen schreibt oder auf Null-Pointer zugreift.

Serenifly: Sieht so aus als ob der Controller resettet. Das kann passieren wenn man über Array Grenzen schreibt oder auf Null-Pointer zugreift.

Ohh, danke für den Hinweise. Ich habe neue Strukturen eingeführt. Das kann natürlich ein Problem sein. Werde direkt danach schauen.

Okay, meine alte Version läuft tatsächlich. Habe schon an meinem Arduino gezweifelt. Suche mal den Speicherschreiber, wenn es einen gibt.

Habe ich eine Möglichkeit durch den Quellcode von meinem Bibliotheken zu debuggen, oder muss ich diese dafür in ein separates Projekt einfügen und es dort versuchen?

Nicht in der Arduino IDE

Für VisualMicro gibt es einen kostenpflichtigen Debugger: http://www.visualmicro.com/page/Debugging-for-Arduino.aspx

Serenifly: Nicht in der Arduino IDE

Für VisualMicro gibt es einen kostenpflichtigen Debugger: http://www.visualmicro.com/page/Debugging-for-Arduino.aspx

Das Plugin ist mir bereits ein Begriff. Habe damit aber noch nicht genug Erfahrung. Versuche es nun mal den Fehler zu finden. Der Anhaltspunkt weiter oben war schon eine Möglichkeit.

Ich habe den Fehler gefunden. Vielen dank für den goldrichtigen Hinweise Serenifly. Ich wollte mir ein Array eine Struktur erzeugen und dann mit dem Indexoperator zugreifen. Habe aber nur eine Variable vom Typ dieser Struktur erzeugt und dennoch über den Zugriffsoperator zugegriffen. Nun gehts wie gewünscht. Arduino spinnt nun auch nicht mehr. Schon interessant wie sich der Controller verhalten hat.

Hier die Lösung:

        /* Fehlerhafter Code */
    struct _PORTCONFIG tmpConfiguration;
    initializer.getPortConfiguration(&tmpConfiguration);
    commander.setConfiguration(&tmpConfiguration);
        /* Korrekt */
    struct _PORTCONFIG tmpConfiguration[CONFIGUREDPORTS];
    initializer.getPortConfiguration(tmpConfiguration);
    commander.setConfiguration(tmpConfiguration);

Danke fürs Lesen des Beitrags.

Und dadurch dass nur die Adresse übergeben wird, kann die Funktion damit beliebig Murks machen. Ja, Pointer sind bei sowas gefährlich.

Lesen ist noch nicht so schlimm, aber beim Schreiben überschreibst du den Speicherbereich anderer Variablen. Und das können auch mal Sprungadressen sein. So kommt dann das ganze Programm durcheinander. Dass da ein Reset kommt (oder eventuell auch nur ein bedingter Sprung in den Reset Vektor weil eine Sprungadresse mit 0 überschrieben wurde), ist noch eine gute Sache. Da merkt man wenigstens dass etwas nicht stimmt.