Hallo,
ich hatte neulich schon eine Frage gepostet (versehentlich bei den=20 Nachbarn in de.sci.ing.elektrotechnik: ).
Ich habe einen ATMega8-16 diesen programmiere ich in C mit dem WinAVR/GCC= =2E
Jetzt habe ich einen =E4hnlichen Fall, n=E4mlich wie kriege ich es hin, d= a=DF=20 der GCC mir das Warten auf einen Tastendruck nicht einfach wegoptimiert:
while(PIND & (1
"Dschen Reinecke" schrieb im Newsbeitrag news: snipped-for-privacy@dschen.de...
Ist es bereits (in den Headerfiles).
Unerwartete ,,Resets'' sind übrigens fast immer ein Zeichen einer fehlenden Interruptbehandlung: der default handler macht schlicht einen JMP 0.
Ansonsten ist eventuell das GCC-Forum von avrfreaks der bessere Platz zum Fragen gerade für derartige Anfängerfragen. Dort gibt's meiner Meinung nach mehr Leute, die da helfen können als hier (weil gerade AVR-GCC-Anfänger hier eher selten sind).
-- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
Stümmt auffällig. Aber der Tipp mit volatile ist schön generisch. Meist hat man dann doch irgendwo vergessen, etwas volatile zu deklarieren und sucht vezweifelt. Schlicht ohne Optimierung zu übersetzen ist ein schneller Test, ob der Fehler da zusuchen ist. Falls das Kompilat dann och in den Prozessor passt ;-)
Naja, die disassemblierte Ausgabe zu nehmen und nachzusehen, was denn nun wirklich passiert ist oft der schnellere Weg. Sobald man sieht, wie es interpretiert wird stösst man schnell auf den dummen Tippfehler oder den nicht beachteten Vorrang der Operatoren. Und eine falsch gesetzte Klammer entzieht sich ja auch beim 25ten draufsehen hartnäckig dem Blick! :-(
un
Wie komme ich daran? Bei der fl=FCchtigen Suche sieht es so aus, als ob=20 mir mein Make-File keins erzeugt...
er m=FCsste
hnlich
Warum nicht gleich den generierten Assemblercode ansehen? avr-gcc -S Ich finde das meist übersichtlicher.
Disassemblieren läßt sich mit avr-objdump -d.
-- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
,=20
und=20
Den Fehler habe ich gefunden: Um Rechenzeit zu sparen erstelle ich mir an Anfang ein Array welches ich =
mit Rechenergebnissen f=FClle, dann mu=DF ich zur Laufzeit diese nicht=20 berechnen. Leider ist dieses mit 210 Chars recht gro=DF und ich habe noch= =20 ein paar andere Variablen...
Wenn ich jetzt auf ein Element zugreife, da=DF scheinbar nicht mehr in da= s=20 RAM passt, resetet sich der =B5C. Erstaunlicherweise nicht beim F=FCllen,= =20 sondern erst beim sp=E4teren Zugriff. Vielleicht wurde es beim=20 Funktionsaufruf vom Stack =FCberschrieben?
Ciao Dschen
--=20 Dschen Reinecke
=3D=3D=3D der mit dem Namen aus China =3D=3D=3D
das=20
n,=20
Wenn der Stack =FCberl=E4uft (oder wenn er gar nicht gesetzt wurde), dann=
gibts auch einen Reset.
Markus
Das ist zumindest atypisch. Der Stack ist als Ringpuffer implementiert, dessen Zeiger beim Ablegen von Daten dekrementiert wird. Also würde ein Überlauf des Stacks doch nur darin bestehen, daß abgelegte Daten überschrieben werden, was dann zu Laufzeitfehlern führt. Wenn ein Übergang des Stackpointers von $0000 nach $ffff zu einem Reset führt, liegt meines Erachtens ein Fehler in der Hardware vor. Einen Interrupt könnte ich mir noch vorstellen, aber gleich ein Reset?
Holger
Es gibt zwar keinen echten Reset aber: Wenn Du Deine Rücksprungadresse auf den Stack legst der gar nicht mehr pysikalisch im RAM liegt dann landest Du bei einem Rücksprung auf 0xffff (rcall/ret irq usw), unterstes Bit wird nicht ausgewertet, die höheren auch nicht, weil der Program Counter ggf. nur so groß ist wie das Flash. Und wenn nicht gerade ein Sprung auskodiert wird (keine Ahnung was
0xffff als Befehl ist) dann ist der nächste Befehl wieder auf Adresse 0 und das ist Reset. Passiert mir auch schon mal wenn der Stack mal wieder überläuft :-) Aber dafür hat man ja seinen Simulator....Gruß Klaus
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.