Sehr komisches Problem mit while-Schleife

Hello,

also so richtig verstehen tue ich den genauen Ablauf deines Programms 
nicht, hab' aber auch nur flüchtig gelesen.

Aber vielleicht ziehst du mal folgenden Ansatz in Betracht: Wenn das 
EEPROM mit Schreibvorgängen beschäftigt ist, kann/wird eventuell selbst 
ein per Interrupt empfangenes Zeichen verloren gehen. Der Controller 
verhindert nämlich währenddessen ein korrumpiertes Schreiben ins EEPROM 
durch Ignorieren anderer Events.

Ich hatte das Problem bei mehreren Geräten, die seit Jahren zuverlässig 
über RS232 kommunizierten. Nach Einsatz von USB-Konvertern ging dann am 
Ende der Übertragung immer ein Byte verloren. Die Untersuchung des 
Problems hatte dann ergeben, dass durch leichte Änderung des Timings 
durch den Einsatz des USB-Seriell-Konverters, das verlorene Byte immer 
beim Zugriff auf's EEPROM des Controllers (Atmel M128) ankam.

Da kann man sich eventuell den Wolf suchen, bis man das findet! Schau 
doch mal, ob du einen ähnlichen Konstrukt bei dir vorliegen hast und 
spiel mal mit verzögerten Transfers.


Gruss
Gunb

Also zu dem Zeitpunkt wird noch gar nichts geschrieben. Die Variable ist 
in der Datei usart.c als
unsigned char usart_cmd_recv = 0;
am Dateianfang außerhalb jeder Funktion deklariert. In der Datei 
eeprom.c wird sie am Anfang mit
extern unsigned char usart_cmd_recv;
eingebunden, genauso wie in der Datei welche die main Funktion enthält 
und dort läuft alles ohne Probleme.

Die aufgerufene Funktion erwartet auch erst später die zu schreibenden 
Daten weil mit der Funktion der ganze EEPROM beschrieben werden kann. 
Erst kommt das bereits gennante START Kommando was der Funktion 
eigentlich nur sagt das nächste Kommando enthält Daten uns soll ins 
EEPROM geschrieben werden und dann könnten nochmal Daten kommen solange 
bis das Kommando EEPROM_WRITE_END gesendet wird. Die Daten werden in 
32Byte Blöcken gesendet.

Severino hat den wesentlichen Hinweis gegeben: volatile

so,

habe mir die Zeit genommen, noch mal genau zu lesen (sorry, hatte vorher 
ne Baustelle vor der Tür).

Schliesse mich den beiden Vorgängern an. Wäre aber interessant zu 
wissen, ob du Erfolg mit 'volatile' hattest?!

Gruss
Gunb

Jo, also mit volatile funktioniert das, besten Dank. Jedoch versteh ich 
den Grund ehrlich gesgat nicht so genau. Hab nochmal mein C Buch 
rausgekramt, (The C Programming Language von Brain W. Kernighan und 
Dennis M. Ritchie) selbst da steht nur sehr wenig zu volatile ...

>volatile

weist den Compiler an, diese Variable bzw. einen Zugriff darauf nicht 
wegzuoptimieren, wenn er der "Meinung" ist, dass er sie wegoptimieren 
könnte.
Aus seiner Sicht wird sie nicht geändert und ist deswegen "über"...
Dass sie in einer ISR geändert wird (Regelfall für die Verwendung von 
"volatile"), kann er bei der Übersetzung eines anderen Programmteils 
nicht "sehen".

In der Tat ist es so, dass der Compiler zur Compilierzeit den Inhalt der 
Variable noch nicht kennt. Der Zugriff kann also nicht komplett 
wegoptimiert werden. Letztendlich schaut der erzeugte Assemblercode so 
aus, dass das Programm die Variable einmal (wegen Optimierung) in ein 
Register lädt. Anschließend (in der while-Schleife) wartet das Programm 
nur noch auf eine Änderung des Registerinhalts, der natürlich nie 
eintritt, anstatt immer wieder den tatsächlichen Variablenwert zu lesen. 
Das schafft dann aber der Zusatz volatile.