Hallo zusammen,
ich benutze die Fat16 lib von Stephan Busker und habe ein mir sich nicht
erklärbares Phänomen:
Es wird ein File auf einer SD Karte beschrieben, die am SPI hängt.
MMC Initialisierung gut, auch erste Schreibversuche gut.
Also mein erstes Programm (Atmega128) so ca. so aus (snippet)
1
intmain(void)
2
{
3
sei();// Interrupt freigeben
4
char*teststring="TEST STRING - TEST STRING\n";
5
mmc_init();
6
InitFat16();
7
FilemyFile;
8
unsignedcharfilewriting_active=0;
9
while(1)
10
{
11
if(~IO_INPUT&(1<<BUTTON1)&&!filewriting_active)
12
{
13
while(~IO_INPUT&(1<<BUTTON1))
14
_delay_ms(100);// warten bis Knopf wieder losgelassen wurde
_delay_ms(100);// warten bis Knopf wieder losgelassen wurde
24
25
filewriting_active=0;
26
fclose_(&myFile);
27
}
28
29
if(filewriting_active)
30
fputs_(&myFile,teststring);
31
32
_delay_ms(100);
33
}
34
35
return(0);
36
}
*********************************************************
Das Funktioniert tadellos.
Wenn ich jetzt allerdings Code hinzufüge, sind ca. 40 Zeilen, so wird
der Ausgabestring in der test.txt gelegentlich verzerrt, sodass Zeilen
geschrieben werden die nicht wir erwartet so:
TEST STRING - TEST STRING
aussehen, sondern (gelegentlich und unregelmäßig) mal so;
TEST STRING - TEST STRING,0TEST STRING - TEST STR0NG
0E,T STRING0 TEST STRING
aussehen.
Jetzt hatt ich schon gedacht, das ich mir den char Zeiger in dem
zusätzlichen Code verbiege und habe das
fputs_(&myFile, teststring);
gegen
fputs_(&myFile, "TEST STRING _ TEST STRING\n");
getauscht, ohne Erfolg mit selbigem Ergebnis.
Compiler meldet, das 12.8% Programmplatz belegt sind und 46.4% Data
Auslastung
Alles mit AVR-GCC und AVR Studio. Keine Compiler Warnungen (was nix
heisst schon klar).
Geht mir da irgendwo der interne Ram abhanden?
Gruß
n.
Funktioniert deine Hardware?
Hast du mal mit dem Oszi deine Pegel auf dem SPI-Bus gemessen?
Hast du da schöne Rechtecke?
> Das Funktioniert tadellos.> Wenn ich jetzt allerdings Code hinzufüge, sind ca. 40 Zeilen,> so wird der Ausgabestring in der test.txt gelegentlich verzerrt
Schön wenn wir wissen, wie es funktioniert. Aber viel interessanter sind
doch die Änderungen, die dazu führen, dass es nicht mehr funktioniert...
Ja, ich geb dir recht, allerdings bin ich grad an der Arbeit und hatte
das aus dem Kopf geschrieben :-)
Ferner dachte ich, dass eine Änderung, egal wie sie aussihet, nichts mit
einem:
fputs_(&myFile,"TEST STRING - TEST STRING\n");
zu tun haben kann.
Ich werde das mal heute Nachmittag nachreichen.
fputs_(&lFile,"TEST STRING - TEST STRING - TEST STRING\n",1);
219
220
if(dataRelease)
221
{
222
DOG_STRING(0,1,gpTime);
223
224
DOG_STRING(0,2,gpDate);
225
226
227
228
if(hasFix)
229
DOG_STRING(9,2,"FIX OK ");
230
else
231
DOG_STRING(9,2,"NOK FIX");
232
233
if(status_record==2)
234
LED_BLINK;
235
236
DOG_STRING(9,1,gpSpeed);
237
238
dataRelease=0;
239
}
240
241
242
243
}
244
}
245
elseif(status_record==1)
246
{
247
DOG_STRING(0,0," Aufnahme aktiv ");
248
status_record=2;
249
}
250
}
Das Programm liest vom UART einkommende Daten von einem Venus6 FLPX,
diese werden dann geprüft auf Korrektheit und wenn Aufnahme aktiv ist,
so soll das auf die SD Karte gehämmert werden.
Wie oben beschrieben, ohne die Prüfroutine geht es, mit Prüfroutine
erscheinen sporadisch "falsche" Zeichen in Output,was aber nicht sein
kann, da ja der gps output geprüft wird, sollte die Prüfunf fehlschlagen
so wird auch nichts geschrieben.
In obigem Code Snippet ist dann die Schreibfunktion auch nur mit dem
"TEST STRING" gedöns ausgeführt, was auch nicht ordentlich funktioniert.
Das erste was ich tun würde:
Den Code in Funktionen unterteilen.
In so einer Monsterwurst findet doch kein Mensch mehr Fehler.
Hast du schon alle Arrayzugriffe überprüft, ob du nicht irgendwo hinten
rausschreibst?
Ich hatte das vorher in Funktionen hab es wieder alles zusammengepackt
weil:
der fputs_ Befehl vor Aufruf der Funktionen gut ging, danach sporadisch
wie beschrieben fehlschlug.
Das erste was ich vermutet hatte war ein Vergleichs Typo, also
incoming[2] = '0' statt incoming[2] == 2
dem war aber nicht so, ausserdem selbst wenn, So wie es jetzt da steht
(ich schreibe ja einen konstanten String weg) muss es gehen, auch wenn
ich Array- und, oder Zeigerfehler hätte.
nOOb schrieb:
> dem war aber nicht so, ausserdem selbst wenn, So wie es jetzt da steht> (ich schreibe ja einen konstanten String weg) muss es gehen, auch wenn> ich Array- und, oder Zeigerfehler hätte.
Nicht unbedingt.
AUch der Text kommt letztendlich aus dem SRAM. Wenn du einen
Amoklaufenden Pointer hast, bzw. einen Arrayzugriff out of bounds,
kannst du dir auch so einen Text zerschiessen.
Ohh, das war mir gar nicht bewusst, aber es ist natürlich absolut
logisch. Speicher ist Speicher und bleibt Speicher :-) Ich Dämelack.
Darauf hin hab ich in das Programm einige Überwachungen reingeschrieben
und auf Array Grenzen explizit geachtet... was soll ich sagen.
Ging dann sofort...
Herzlichen Dank für die Klappse auf den Hinterkopf :-)