Hallo an alle, ich habe ein Problem und komme nicht weiter. Ich habe angefangen die Application Note AVR446 von Atmel zu implementieren. Ich verwende das Atmel Studio 6 mit dem GCC Compiler. Es lässt sich auch compilieren ohne Fehler. Es gibt allerdings Warnungen. Zugegeben, die habe ich mir noch nicht alle angesehen. Der Controller (Atmega644) lässt sich programmieren und läuft los. An der Ausgabe im Terminal Programm erscheint auch wie erhofft die Ausgabe. Nur die wird endlos ausgegeben. Also der Controller läuft irgendwo ins Nirvana und resetet sich. Ich habe den Eindruck, dass es mit der gepufferten Ausgabe zusammenhängt. Ich denke der Reset kommt, wenn das letzte Zeichen ausgegeben worden ist und die Übertragung dann aber nicht richtig abgebrochen wird. Könnte sich das mal jemand anschauen? Ich finde den Fehler nicht! Gruß, Jens
Jens W. schrieb im Beitrag #3396660: > hast du schlecht geschlafen oder was ist mit dir los? > Wenn du keine Lust hast mir zu helfen, dann lass es, aber deine > Kommentare kannst du dir dann auch sparen! > Ich kenne von Atmel mehr Datenblätter als du vielleicht glaubst. > Ich habe mich durchaus intensiv mit dem Thema beschäftigt. > Ich kann allerdings nicht verstehen, warum du so auf das Datenblatt > schimpfst. Hat es dir was getan? > > Und wie kommst du darauf, dass sich der Controller nicht reseten kann? > Das musst du mir erklären! > > Unglaublich! Ich bin doch nicht im Kindergarten! > > Sonst noch wer, der vielleicht eine Idee hat? > > Grüße an den Rest! machst aber keinen Eindruck als hättest du dich mit der thematik beschäftigt! nicht mal compiler warnings lesen? ein scherz oder? Datenblatt lesen avr gcc tutorial lesen application notes debugger laufen lassen oder simulator und konkrete fragen stellen!
Jens W. schrieb im Beitrag #3396660: > Und wie kommst du darauf, dass sich der Controller nicht reseten kann? > Das musst du mir erklären! Ganz einfach, ein Reset kann nur durch 4 Ereignisse ausgelöst werden: - Power On - Extern - Watchdog - Brown-Out Ergo nicht einfach durch einen Programmfehler. In Software kann er nur durch gezieltes ausnutzen des Watchdog erreicht werden. Schwerlich aus versehen. Wenn du mit Reset den Überlauf oder das Rückstellen auf 0, des Programmcounters (z.B. durch einen Nullpointer) meinst, dann liegst du einfach falsch. Das ist kein Reset. Ein solches Rückspringen an den Programmstart passiert sehr leicht durch falsche Pointer(übergaben), Array-Überläufe) usw. Check dein Programm mal drauf, und führe irgendeine Debugging Möglichkeit ein, die dir erlaubt rauszufinden bis zu welcher Codestelle dein Programm noch läuft, bevor es auf 0 springt. c-hater hat völlig recht. Du hast keine Ahnung und du guckst nicht ins Datenblatt und du liest keine Warnungen. Ändere das. gruß cyblord
Cyblord schrieb: >Du hast keine Ahnung und du guckst nicht ins >Datenblatt und du liest keine Warnungen. Ändere das. Warum sollte er das Datenblatt ändern? Dafür gibt es doch Errata vom Hersteller.
cyblord ---- schrieb:! > Ganz einfach, ein Reset kann nur durch 4 Ereignisse ausgelöst wer > - Power On > - Extern > - Watchdog > - Brown-Out Den entscheidenden Grund hast du leider vergessen: Interrupt ohne ISR. ergibt zwar keinen echten reset, sieht aber gerade für Anfänger genauso aus. Oliver
@cyblord: Da irrst du dich aber! Wenn der Controller eine Sprungadresse in die Mitte des Flashs bekommt und da kein gültiger Opcode steht, dann inkrementiert er den PC bis er am Ende des Flash angekommen ist und beginnt bei 0x0000. Und genau: Was steht da? Der Reset-Vektor. Ich wollte wissen, warum in dem Programm die Abbruchbedingung nicht funktioniert. Hat sich das schon jemand angesehen? Warum sind denn alle heute so gereizt? Grüße, Jens
Hallo Oliver, vielen Dank. Das ist der erste brauchbare Hinweis! Aber die ISR ist da. Es werden ja auch die Zeichen ausgegeben. Nur die Schleife, die da ausgeführt wird, hört nicht auf. Daher glaube ich, dass es daran liegt. Gruß
Jens W. schrieb: > Da irrst du dich aber! Echt? > und beginnt bei 0x0000. Und genau: Was steht da? Der Reset-Vektor. Resetvektor != RESET
@Jens und Oliver: Wenn ihr meinen Post auch GELESEN hättet... Sprung PC=0 ist kein RESET. Egal was wie aussieht. Es ist keiner. Die 4 Resetquellen habe ich mir nicht ausgedacht. Die stehen genauso im Datenblatt. Aber wer liest das schon. Ich finds unglaublich dass Leute die sich nicht auskennen sich dann aber nichts sagen lassen. Hauptsache irgendwas dagegen auch wenns falsch ist. Und dann noch Dummfrech mir eine Irrung zu unterstellen.
:
Bearbeitet durch User
Cyblord schrieb:
>Und dann noch Dummfrech mir eine Irrung zu unterstellen.
Ja, das schlägt dem Faß die Krone in's Gesicht! Ein Frechheit
SondersHausen.
Nun, Jens W., beim jetzigen Zustand werden Sie keinen gelangweilten Fähigen finden, der sich mit dem Problem herumschlagen will. Reduzieren Sie es auf einen 40-Zeiler (dürfen auch 50 sein), und stellen Sie diesen hier direkt vor. Falls das dann überhaupt noch nötig ist und Sie nicht im Zuge der Analyse den Fehler selbst gefunden und obendrein noch eine Menge gelernt haben.
cyblord ---- schrieb: > c-hater hat völlig recht. Keine Ahnung, ob ich recht hatte, so weit ist der Thread ja nie gediehen. Kann sein, muß aber nicht sein. Zumindest ist der dargestellte Sachverhalt eine plausible Möglichkeit zur Erklärung der beobachteten Symptome. Das Problem ist: Leider hat irgendein Zens.. ähem: Moderator meinen Beitrag gelöscht. So konnte der TO den Hinweis möglicherweise garnicht mehr lesen und damit auch nicht umsetzen. In wessen Interesse stehen solche Löschungen? Der TO muß zwar nach der Löschung seine empfindsame Seele nicht den Niederungen harter Worte aussetzen, bekommt aber dafür auch sein Problem nicht gelöst. Ob das wirklich in seinem Interesse ist? Ich glaube nicht...
c-hater schrieb: > Das Problem ist: Leider hat irgendein Zens.. ähem: Moderator meinen > Beitrag gelöscht. So konnte der TO den Hinweis möglicherweise garnicht > mehr lesen und damit auch nicht umsetzen. > > In wessen Interesse stehen solche Löschungen? Das Problem war wohl deine (saumäßige) Wortwahl. Worte wie "verf**kt" und Ähnliches sind schon ein wenig übers Ziel hinausgeschossen.
@c-hater: Den Beitrag habe ich schon gelesen. Ich habe den auch löschen lassen. Und ich finde es immer noch eine absolute Unverschämtheit so auf Leute zuzugehen. Mein Problem hat sich auch erledigt und es hat sich gezeigt, dass die verwendete Entwicklungsumgebung daran schuld war! @cyblord: Mir zu unterstellen ich hätte keine Ahnung, ohne dass man mich kennt, geht gar nicht. Das ist menschlich einfach erbärmlich! Ich habe eine klare Frage gestellt und habe darauf keine Antwort bekommen. Da wurde einfach los geschimpft. Wie so oft hier. Leider! Und bei dem Reset habe ich auch Recht! An Adresse 0x000 steht der Reset vektor. Der wird natürlich nur ausgelöst bei den 4 Reset Quellen (direkter Sprung dahin), aber wenn der PC überläuft und dann auch auf diese Adresse springt, dann gilt das auch. Kurz: Reset wird ausgelöst, wenn PC auf 0x000 steht! Das ist einfach der definierte Programmstart. So und nun Schluss mit den Belehrungen! Ich finde der gesamte Thread gehört gelöscht, da keiner hier einen Nutzen draus ziehen kann! Güße an der Rest!
Hi >Kurz: Reset wird ausgelöst, wenn PC auf 0x000 steht! Das ist einfach der >definierte Programmstart. Das ist aber noch lange kein Reset. Bei einem Reset werden z.B. die IO-Register automatisch mit einem Default-Wert geladen. Bei neueren AVRs auch der Stackpointer initialisiert. In MCUSR wird das Bit der Resetquelle gesetzt. ... Und das passiert alles bevor der Code an Adresse 0x0000 ausgeführt wird. MfG Spess
Jens schrieb: > @cyblord: > Mir zu unterstellen ich hätte keine Ahnung, ohne dass man mich kennt, > geht gar nicht. Das ist menschlich einfach erbärmlich! Nun ich lese was du schreibst und daraus ziehe ich den Schluss. Und die Tatsache dass du jetzt zum bestimmt 3. mal auf deiner völlig falschen Reset-Definition beharrst, zeigt mir dass du nicht nur keine Ahnung hast, sondern dazu auch noch beratungsresistent bist. > Ich habe eine klare Frage gestellt und habe darauf keine Antwort > bekommen. Da wurde einfach los geschimpft. Wie so oft hier. Leider! Weil deine Frage erstmal mit einer völlig falschen Behauptung (Reset) eingeleitet wurde. Bevor man sein Problem nicht mit der korrekten Terminologie beschreiben kann, braucht auch nicht über eine korrekte Antwort nachdenken. Eigentlich wäre das schnell geklärt gewesen, aber du musst natürlich darauf beharren dass du recht hast, und andere sich irren. Pech für dich. > Und bei dem Reset habe ich auch Recht! Nein, aber was kümmert dich das? Eventuell könntest du noch mit dem Fuss aufstampfen um deiner These mehr Nachdruck zu verleihen. > An Adresse 0x000 steht der Reset vektor. Der wird natürlich nur > ausgelöst bei den 4 Reset Quellen (direkter Sprung dahin), aber wenn der > PC überläuft und dann auch auf diese Adresse springt, dann gilt das > auch. > Kurz: Reset wird ausgelöst, wenn PC auf 0x000 steht! Das ist einfach der > definierte Programmstart. Also für dich Knalltüte ein letztes mal: Ein RESET wird durch eine der 4 oben genannten Quellen ausgelöst, und tut eine Reihe von Dingen. z.B. alle Register in ihren Urzustand zu versetzen. Oft wird auch auch de Stackpointer gesetzt. Und nebenbei wird der Programm Counter auf 0 gesetzt. Was dazu führt dass das Programm bei 0 startet. Das Ding heißt Reset-Vektor, weil hier NACH einem Reset hingesprungen wird. Nicht weil dadurch ein Reset ausgelöst wird. D.h. ein hinspringne zu PC=0 bewirkt natürlich keinen Reset. Aber bei jedem Reset wird auf PC=0 gesprungen. Also ein Reset tut viel viel mehr, als nur an den Reset-Vektor zu springen. > So und nun Schluss mit den Belehrungen! Genau, du weißt doch schon alles. Am Ende erzählt noch jemand was wahres. Wer will das schon. > Ich finde der gesamte Thread > gehört gelöscht, da keiner hier einen Nutzen draus ziehen kann! Ich finde der Thread ist ein Paradebeispiel für den Spruch: > Der Horizont mancher Menschen ist ein Kreis mit Radius null, und das > nennen sie dann ihren Standpunkt. gruß cyblord
:
Bearbeitet durch User
Und warum wirst du gleich persönlich? Du bist der Einzige, der sich mit seiner Sprache outet! Nur weil du am Lautesten schreist hast du nicht gleich Recht! Du schreibst außerdem, dass meine Frage mit einer völlig falschen Behauptung eingeleitet wurde. Wie kommst du nur auf so etwas? So wie sich das Problem dargestellt hat ist die Schlussfolgerung das Problem einzugrenzen nicht so abwägig. Natürlich könnte ich auch damit falsch liegen. Wenn ich das wüsste, dann müsste ich mich nicht an ein Forum wenden. Nur schade, dass sich da solche Leute wie du ihren Frust von der Seele schreiben. Hilfreich wäre ein Tip gewesen, wie man das Problem weiter eingrenzen kann. Und da gehört auch nicht das Datenblatt dazu, da es sich eher um die Entwicklungsumgebung dreht. Kein einziger hat was dazu geschrieben, was die Schleife wie tut, um die es mir ging! Also was soll ich mit solchen Aussagen sonst anfangen. Ich will keine Belehrungen wie oft ich das Datenblatt lesen soll oder eine Abschätzung was ich kann und was nicht. Das weiss ich selber. Ich habe eine Frage gestellt. Sonst nichts. Wenn du meinst, dass sei der falsche Weg den ich einschlage, dann kannst du das freundlich mitteilen. Ist doch mein Problem, wenn ich damit nicht weiter komme und nicht deines. Und wenn ich unbelehrbar bin ist das auch mein Problem. Das alles zusammen ist aber immer noch kein Grund menschen persönlich anzugreifen! Du Knalltüte!
Jens W. schrieb: > Hilfreich wäre ein Tip gewesen, wie man das Problem weiter eingrenzen > kann. Hab ich dir auch geschrieben. Lies meinen ersten Post. Auf solche Tips gehst du gar nicht ein, Infos liest du nicht, Korrekturen nimmst du nicht an. Du bist absolut bildungsresistent. Und ja da werd ich dann irgendwann persönlich, vor allem wenn Ahnungslose wie DU mir dann auch unterstellen ich würde falsche Behauptungen aufstellen. Und dass dein Problem nun an der Entwicklungsumgebung gelegen haben soll ist auch mehr als abstrus. Aber ich hab keine Lust mehr hier gegen eine Wand zu reden. Mach deinen Quatsch doch alleine. Mit bockigen Kindern will ich mich nicht rumärgern. gruß cyblord
Jens W. schrieb: > Kein einziger hat was dazu geschrieben, was die Schleife wie tut, um die > es mir ging! Die Schleife ist aber auch gar nicht das Problem. Du hast einen Interrupt freigegeben für den du keine ISR hast. Die Standardantwort darauf ist: "so etwas wird mit einem Reset bestraft", auch wenn den meisten klar ist, dass es sich dabei nicht um einen richtigen Reset im strengen Sinne des Wortes handelt, da es sich für gcc-Programmierer praktisch gesehen so gut wie gleich auswirkt.
:
Bearbeitet durch User
Hallo Karl Heinz, genau darum geht es. Die ISR ist aber da. Also es funktioniert auch. Erst bei erreichen des Endes des Text Strings tritt der fehler auf. Daher hatte ich vermutet, dass er nicht abbricht in der Schleife und dann falsch aus der ISR zurück springt. Und das Verhalten ist nicht definiert. Das Problem hat sich aber nach erneuter Installation der Entwicklungsumgebung gelöst. Ich hatte mich noch gewundert, dass ich die Debug Session nicht starte konnte. Das lag aber an der Umgebung. Atmel Studio 6.0 ist eben nicht fehlerfrei. Gruß
Jens W. schrieb: > Hallo Karl Heinz, > > genau darum geht es. Die ISR ist aber da. Wo soll das sein?
1 | UCSR0B |= (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0)|(1<<TXCIE0); |
Wo ist die 'Transmit Complete'-ISR, die du mit dem TXCIE0 freigibst?
Du hast eine ISR für den Data Register Empty Interrupt. Aber eine
entsprechende für den TXC sehe ich nicht.
> Also es funktioniert auch
Offensichtlich aber nicht.
Aus dem Datenblatt zum Thema 'Transmit COmplete Interrupt' - Bit1 | Bit 6 – TXCn: USART Transmit Complete |
2 | This flag bit is set when the entire frame in the Transmit Shift |
3 | Register has been shifted out and there are no new data currently |
4 | present in the transmit buffer (UDRn). |
Na, passt doch wunderbar. Solange der "Data Register Empty" Interrupt auftritt, behandelst du ihn und schiebst laufend Daten ins UDR nach. Damit ist die Teilbedingung 2 "and there are no new data currently present in the transmit buffer (UDRn)" nicht erfüllt. Erst wenn dein Text soweit draussen ist, dass es momentan nichts mehr ins UDR nachzuschieben gibt, ist auch diese Teilbedingung erfüllt. Dann wird der Transmit Complete Interrupt ausgelöst, nachdem das letzte Byte auf den Weg gebracht wurde - für den du aber keinen Handler hast. Und schon nimmt das Unheil seinen Lauf.
:
Bearbeitet durch User
Kann es sein, dass dir bei deinen Datenblatt, bzw. AppNote, bzw. Fremdcode - Studien entgangen ist, dass es 2(!) für den Transmitter zuständige Interrupts gibt? Der eine wird ausgelöst, salopp gesagt, wenn das UDR wieder aufnahmebereit für das nächste Byte ist. Der andere wird ausgelöst, salopp gesagt, wenn das Byte komplett aus der UART draussen ist und die UART so gesehen keine Arbeit mehr hat. Bisschen schleissig deine Studien, wenn du das nicht bemerkt hast.
:
Bearbeitet durch User
Da hast du natürlich Recht! Ist natürlich für mich dann die Frage was an meiner jetzigen Version doch anders ist, so dass es doch tut... Da schau ich nochmal nach. Danke dir! Gruß, jens
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.