Unerklärliche Programmfehler

[damfino]

Anscheinend war es dieser Fehler beim UART, danach hat alles problemlos funktioniert.

Nachdem es funktioniert hat bin auf auf einen 644 umgestiegen, und habe jetzt Probleme mit Tastern und Sensoren: mal lösen sie von selbst aus, dann wieder nicht wenn sie es sollten. Alles mit Pull up.
Kann es sein dass der 644 empfindlicher auf Schwankungen in der Stromversorgung reagiert? Denn es liegt nicht an den Tastern und Sensoren, denn den 32 rein, und schon geht es wieder perfekt.

LG!

[yaro]

Auf welcher Frequenz lässt du ihn laufen?

Gruß, Yaro

[damfino]

Er hat einen 16Mhz Quarz, bei den Fuses ist die längste Start-up Zeit eingestellt.

Es sind alle am Port A angeschlossen:
#define Sensor_re ((PINA &(1 << PINA2)))
#define Sensor_li ((PINA &(1 << PINA3)))
#define Bumper (!(PINA &(1 << PINA4)))
#define Taster_Stop (!(PINA &(1 << PINA6)))
#define Taster_Schwarz (!(PINA &(1 << PINA7)))

am Pin 5 ist der ADC im free running Mode.

Davon funktionieren immer Sensor_re und Taster_Schwarz.
Sensor_li wird praktisch immer ignoriert, am Bumper kommen oft Fehlerauslösungen, am Taster_Stop kommen selten Fehlauslösungen.

Kann es sein dass es mit den ADC zusammenhängt? Sind schließlich die Pins um den verwendeten ADC betroffen.

/* ADC 	*/
	ADMUX |=(1<<REFS1) | (1<<REFS0); // interne 2.56V
	ADMUX |=(1<<MUX2) | (1<<MUX0); // Kanal = PIN 5
	ADCSRA |= (1<<ADEN) | (1<<ADSC) | ( 1 << ADATE ); // ADC ein + starten, free running mode
	ADCSRA |=(1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0); // prescaler 128

Die Sensoren haben Pullup am Sensor selbst, am Bumper habe ich zum internen noch einen externen Pullup angeschlossen, Taster haben nur den internen Pullup.

Stromversorgung kommt vom Akku mit 11,6-13,3V, über Diode, 1000µF C, 100nF C, L7805, 100nF C, und nochmal 100nF am Controller selbst.

LG!

[yaro]

JTAG aus?
AVCC an VCC?

Das SFIOR ist im m644 ADCSRB (name geändert) und etwas andere Funktionen, vielleicht hat es etwas damit zutun.

DIDR0 gibts im m644 aba nicht im m16

Guck da mal ein bisschen, vielleicht ist der Fehler ja schon dabei.

Pin-compatibel heißt nicht gleich Programm-Compatibel. Einige feinheiten gibts immer.

Gruß, Yaro

[damfino]

JTAG ist aus, am PortC ist die Motorsteuerung dran.
AVCC ist an VCC, braucht man ja auch am m32.

SFIOR habe ich nicht verwendet, ich setze die Pins so:
/* Eingänge mit Pullup*/
DDRA &= ~(1 << PA4); PORTA |= (1<<PA4); //Bumper
DDRA &= ~(1 << PA6); PORTA |= (1<<PA6); //Taster rot
DDRA &= ~(1 << PA7); PORTA |= (1<<PA7); //Taster schwarz

DIDR0 ist nicht gesetzt, laut Dok senkt es nur den Stromverbrauch, und der ist da mehr als vernachlässigbar. Aber ich werde es mal damit probieren.

Die anderen Unterschiede bei den Timern, PWM, USART habe ich alle geschafft, und nun schaffen mich simple IO Pins

LG!

[yaro]

Gib mal die Eingänge auf nem LCD aus, ohne irgendwas anderes zu initialisieren. Dann kannst du sehen, obs an den Eingängen liegt, oder ob du iwas im Programm machst, was stört.

Gruß, Yaro

[damfino]

Nach vielen Versuchen und Anregungen von hier konnte die Probleme lösen:
Sensor: der m644 ist weniger empfindlich am Pin als die 2 m32 die ich hatte, eine LED am Sensor die die Funktion anzeigt entfernt und schon funktioniert es. Lt Datenblatt sind m32 und m644 gleich empfindlich, vielleicht hate ich einfach besonders gute bzw schlechte Exemplare.
Das Problem mit dem Bumper hat sich von selbst erledigt, einerseits nett, andererseits mag ich keine offenen Fragen.
Die letzten Programmfehler sind offenbar gelöst, leider auch ohne die echte Ursache zu kennen. Das Programm hatte zuvor max 9 Ebenen, ich hab es jetzt auf 7 Ebenen reduziert und das hat offenbar geholfen. Aber das bei 9 Ebenen beim m644 der Ram ausgeht halte ich für unwahrscheinlich, dann hätte es mit dem m32 gar nie funktionieren können. Ich konnte die Ursache für die Resets an genau eine Stelle nachvollziehen, ins Timeout bei der Navigation. Hier werden nach 2 Minuten zwei Variablen von 0 auf 1 gesetzt damit die Fahrt als erfolglos abgebrochen und die while Schleife dieser Funktion und damit die Funktion selbst verlassen wird. Die zweite Variable ist dabei eine globale damit auch der Rest der mit der Navigationsfahrt (zB Wegfindung zu weiteren Punkten) zu tun hat abgebrochen wird.
Warum soll das einen Reset auslösen?
Jetzt ist diese Funktion von max Ebene 7 auf max Ebene 5 gerückt, und es geht bisher ohne Reset.

Wenn ich noch herausfinde warum der Attiny Slave nicht will wäre ich so halbwegs zufrieden

LG!

[MichaF]

Warum soll das einen Reset auslösen?

Ich vermute immer noch das du mit dieser Art der Fehlersuche nicht glücklich werden wirst. Auch durch wahllose Änderungen unterdrückst du deine Probleme höchstwahrscheinlich nur. Es ändert sich beispielsweise die Reihenfolge von Variablen im Speicher, und ein irrlaufender Pointer hat gerade zufällig keine Auswirkungen mehr. Gehe deinen gesamten Code noch mal durch. Stück für Stück. Kontrolliere jede Variable auf ihren Wertebereich, und gib insbesondere acht auf Pointer/Arrays. Oder evtl. mal bei einem switch ein break; vergessen? Mir ist klar das so eine Aktion Stunden dauert. Es gibt unzählige Möglichkeiten, aber ich gehe fast jede Wette ein, das dein Problem den Namen Pointer trägt. Und über solche Probleme stolperst du früher oder später wieder wenn du sie nicht richtig beseitigst.

[BurningWave]

Dem stimme ich zu. Ich programmiere gerade ein größeres Programm mit C++ und hatte an den unmöglichsten Stellen Zugriffsverletzungen. Und woran lag es? Weil ich Speicher in der Datei-Lade-Funktion mit der alten C-Funktion malloc() reserviert habe anstatt mit new (was man in C++ benutzt) und malloc() bei komplexen Typen nicht funktioniert. Das wird bei dir sicher nicht das Problem sein, weil du in C programmierst, aber es ist ein gutes Beispiel dafür, dass Fehler auf unterster Ebene im späteren Programmverlauf zu sehr seltsamen Fehlern führen, die sehr schwer zu finden sind, gerade weil sie nicht immer auftreten.

[damfino]

Ich gehe den Code immer wieder auf Fehler durch, man ist aber oft schon blind die gleichen Stellen immer wieder durchzusehen. Der Compiler gibt leider nicht immer Warnungen raus, da gab es schon mal Tippfehler die er hätte melden müssen.
Mit Pointern stehe etwas auf Kriegsfuß und vermeide sie deswegen, denn ein Variablenüberlauf kann meines Erachtens weniger Schaden anrichten als ein fehlgeleiteter Pointer. Das der Code dadurch mehr Speicher braucht nehme ich in Kauf.
Aber man ist ja lernfähig, waren mir Anfangs zB die defines noch suspekt, so werden sie jetzt regelmäßig verwendet, und der Code wird mit jeder Änderung übersichtlicher und besser.

LG!