Moin! Ich habe an der UART meines Atmega8 eine GPS- Maus angeschlossen, dessen Informationen fleissig gelesen und angezeigt werden. Mein Problem: wenn -warumauchimmer- kurz die Verbindung getrennt wird, so bleibt der Atmega stehen. Warum? Vermutung: durch das Abstecken entsteht ein Zeichenwirrwarr, in dem sich eine Folge befindet, die als Was-auch-immer-Befehl interpretiert wird. Gibts da Abhilfe?
ja, das programm auf dem atmel muss fehlerfrei sein.
So Programmieren, das du auf Befehle von der Art "Was auch immer" so reagierst, dass sich ein sicherer Betriebszustand einstellt?
Gibt es denn nicht auch einen "Achtung, Chip, hier kommt ein neues Programm für Dich!"- Befehl?
Was meinst du überhaupt mit "bleibt stehen"? Wird ein Reset durchgeführt? Friert er komplett ein (reagiert auf garnix mehr)?
Ja - Programmieren lernen. Scheinbar verwendest du Code ohne über dessen Funktion zu kennen, sonst hättest du die Frage nicht, oder zumindest nicht so gestellt. Hättest du Ahnung von dem was du tust, wüsstest du erstens welcher Teil des Programms dafür verantwortlich ist und zweitens wie du Fehlinterpretationen abfangen kannst (Stichwort: Timeout). Der AVR interpretiert nämlich ein bisschen gar nichts, höchstens dein Programm. Wenn der AVR selbst abschmiert, hast du Probleme mit der Stromversorgung. mfG Markus
UART dient nur zum Datenaustausch. Diesen Austausch machst du selbst in deinem Programm auf dem Mega. Du kannst also sehr wohl mechanismen einbauen, dass ausgewertet wird, ob die Daten richtig/sinnvoll sind oder nicht. >Gibt es denn nicht auch einen "Achtung, Chip, hier kommt ein neues >Programm für Dich!"- Befehl? Dein Mega bekommt über UART ein neues Programm von der GPS Maus?
Er "kackt so richtig ab". Danach hilft -vergessen zu erwähnen, sorry- nur erneutes Flashen.
Stephan R. schrieb: > Vermutung: durch das Abstecken entsteht ein Zeichenwirrwarr, in dem sich > eine Folge befindet, die als Was-auch-immer-Befehl interpretiert wird. > Gibt es denn nicht auch einen "Achtung, Chip, hier kommt ein neues > Programm für Dich!"- Befehl? Nö. Das was über die UART kommt wird ja nicht als Programmcode interpretiert. Das sind einfach nur Daten, die von deinem Programm weiter verarbeitet werden. Wenn dein Programm aber nicht damit klarkommt, dass über die Schnittstelle etwas anderes hereinkommt als es erwartet, dann kann es schon sein, dass dein Programm sich andere wichtige Daten überschreibt und als Folge davon dann unvorhergesehene Dinge passieren. > Gibts da Abhilfe? Programm fehlerfrei schreiben. Beim Programmieren auch immer ein Auge darauf haben: Was kann an dieser Stelle alles passieren.
Stephan R. schrieb: > Gibt es denn nicht auch einen "Achtung, Chip, hier kommt ein neues > Programm für Dich!"- Befehl? Du solltest doch am besten wissen, was Du in den ATmega8 einprogrammiert hast. Oder ist das Programm garnicht von Dir? Peter
Stephan R. schrieb: > Er "kackt so richtig ab". Danach hilft -vergessen zu erwähnen, sorry- > nur erneutes Flashen. Das ist ziemlich unwahrscheinlich. Wenn ein Druck auf den Reset Knopf nicht hilft, musst du schon sehr unglücklich in deinem Programm zugeschlagen haben. Aber spätestens nach einem Strom Aus / Strom ein, muss wieder alles normal sein. Sofern du die GPS Maus erst nach dem µC startest, natürlich :-) Denn ansonsten steigt der µC schon wieder schräg in eine Übertragung ein und das nächste Abkacken gleich nach dem Hochfahren ist nur eine Frage von Millisekunden.
Dochdoch. Aber mit meinem geschulten Ohr höre ich ganz leise heraus, dass es an meim Programm liegen KÖNNTE. Werd wohl nochmal drüberfliegen. Thx!
Karl heinz Buchegger schrieb: > Aber spätestens nach einem Strom Aus / Strom ein, muss wieder alles > normal sein. der µC kann ich auch sein eigenen Flash überschreiben. Sonst würde es ja keine bootloader geben. Ich halte es zwar hier für unwarscheinlich aber möglich ist es.
>Wenn ein Druck auf den Reset Knopf nicht hilft, musst du schon sehr >unglücklich in deinem Programm zugeschlagen haben. Oder es fehlt der Rest Knopf
Stephan R. schrieb: > Dochdoch. Aber mit meinem geschulten Ohr höre ich ganz leise heraus, > dass es an meim Programm liegen KÖNNTE. Da musste ich wirklich lachen =)
Peter schrieb: > Ich halte es zwar hier für unwarscheinlich aber möglich ist es. So war das auch auf den Fragesteller gemünzt. Ich erinnere mich ja noch, dass er GPS auswerten will und wie üblich keine Ahnung von Stringverarbeitung hat :-) D.h. er hat mit 99% Sicherheit das SRAM niedergebügelt. Höchst wahrscheinlich in der Empfangsschleife (Abfrage auf Buffer voll vergessen). Da müsste er schon sehr viel Pech haben, wenn ein misglückter Return dann ausgerechnet so landet, dass das Flash verändert wird.
> keine Ahnung von Stringverarbeitung hat
Nanana! Während die Kiste dransteckt läuft alles tadellos!
Aber welche Missetaten könnte meinen Chip dazu veranlassen, seinen Flash
zu überschreiben?
Stephan R. schrieb: > Aber mit meinem geschulten Ohr höre ich ganz leise heraus, > dass es an meim Programm liegen KÖNNTE. Benutze lieber dein (hoffentlich ebenfalls) geschultes Gehirn...
Stephan R. schrieb: > Nanana! Während die Kiste dransteckt läuft alles tadellos! so ist es immer, man testet ja nur den normalfall. Der Fehlerfall ist viel spannender. Also mach es jetzt nicht so spannend und zeig uns doch bitte den Quellcode.
Stephan R. schrieb: >> keine Ahnung von Stringverarbeitung hat > > Nanana! Während die Kiste dransteckt läuft alles tadellos! Das ist keine Kunst. Die Kunst in der Programmierung fängt dann an, wenn es gilt auch in Fehlerfällen ein System noch am laufen zu halten. Ein Programm so zu schreiben, dass es nicht durch fehlerhafte Daten aus der Bahn geworfen wird, sondern die ignoriert/korrigiert/was_auch_immer_damit_macht. Aber auf jeden Fall nicht abstürzt. > Aber welche Missetaten könnte meinen Chip dazu veranlassen, seinen Flash > zu überschreiben? Vergiss das fürs erste. Mit an Sicherheit grenzender Wahrscheinlichkeit überschreibst du den Flash nicht. Dazu müsste man noch eine ganze Handvoll Zusatzannahmen treffen, was noch gleichzeitig alles schief gelaufen ist. Occams Messer sagt: Das ist es höchst wahrscheinlich nicht Nicht wenn ich mich so zurückerinnere, welche Schwierigkeiten du bei banalem Stringhandling hattest. Das ist viel wahrscheinlicher die Ursache.
lies einfach mal den Flash-Inhalt zurück nachdem nix mehr geht und vergleiche das mit dem was drinstehen sollte (Hex-Files). Das könnte etwas mehr Aufschluss geben. Jörg
Wird gemacht! Montag. Jetzt ist Wacken! Danke erstmal!
Joerg Wolfram schrieb:
Ich geh davon aus, dass du das vorschlägst, damit er sich davon
überzeugt, das es das nicht ist.
Denn ansonsten lockst du ihn auf eine falsche Fährte.
Und gerade Anfänger neigen gerne dazu allem Möglichen die Schuld zu
geben, nur nicht ihrem Programm. Egal wie unwahrscheinlich die weiteren
Möglichkeiten tatsächlich sind.
Hallo! Karl heinz Buchegger schrieb: > Die Kunst in der Programmierung fängt dann an, wenn es gilt auch in > Fehlerfällen ein System noch am laufen zu halten. Ein Programm so zu > schreiben, dass es nicht durch fehlerhafte Daten aus der Bahn geworfen > wird, sondern die ignoriert/korrigiert/was_auch_immer_damit_macht. Aber > auf jeden Fall nicht abstürzt. Das stimmt, so sollte es immer sein, aber Microsoft hat das bis heute nicht kapiert. Leg mal eine fehlerhafte DVD in dein DVD-Laufwerk ein und das System verabschiedet sich oder du musst eine halbe Ewigkeit warten, bis das System verstanden hat, dass die DVD nicht zu lesen ist ;-) Nun aber Scherz beiseite. Ich selbst hatte mal ein ähnliches Problem. Ich habe eine Platine mit einem FT232BM und einem ATMEGA-Prozessor entworfen. Mein Programm lief recht gut, aber jedes Mal, wenn ich während des Betriebes das USB-Kabel des Computers ansteckte oder absteckte, stürzte der Prozessor ab und nichts tat sich mehr. Nach einem Reset oder Power-UP war trotzdem alles eingefrohren, der Prozessor tat nichts mehr. Nur ein Neuflashen half. Dann ging der Prozessor wieder so lange bis man das USB-Kabel wieder ansteckte oder absteckte. Danach wieder Neuflashen. Es ist schon ein paar Jahre her. Ich arbeitete mit Codevision und verwendete zusätzlich einen Watdog-Timer. Diesen hatte ich per Fuse-Bit standardmäßig eingeschaltet. Der Watdog wurde jeodch früher in der startup.asm standardmäßig abgeschaltet, was mich dazu verleitete eine andere startup einzubinden. Es gibt ja diese Option "User External Startup Initialization File", welche ich auswählte. Im Startup-File schaltete ich die Watdog-Befehle ab und los ging es. Es schien alles zu funktionieren, bis auf das oben geschilderte Problem. Die UART Sende- und Empfangsroutinen waren schon des Öfteren eingesetzt worden und hatten sich bereits fehlerfrei bewährt. Erst nach langem Suchen kam ich dahinter, dass dieses externe Startup-File, welches mit Codevision mitgeliefert wurde, irgendetwas "Böses" macht. Keine Ahnung warum sich das System in diesem Fall so verhielt, aber ein Abschalten der Option half. Das interne Startup-File wurde wieder verwendet und der Fehler trat nie wieder auf. Leider musste ich dann den Watchdog-Timer nach dem Start mit eigenen Befehlen wieder aktivieren. Ich hoffe, ich konnte helfen. Schöne Grüße Emil
Emil schrieb: > Erst nach langem Suchen kam ich dahinter, dass dieses externe > Startup-File, welches mit Codevision mitgeliefert wurde, irgendetwas > "Böses" macht. soetwas macht doch neugierig, hast du nicht mal das ASM angeschaut?
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.