Atmega "kackt ab" wenn UART gesteckt/ entfernt wird

So Programmieren, das du auf Befehle von der Art "Was auch immer" so 
reagierst, dass sich ein sicherer Betriebszustand einstellt?

Nicht per UART...

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?

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.

>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.

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

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.