Hallo, ich verwende seit geraumer Zeit einen abgewandelten Code von Beitrag "Re: SD-Karte Initialisierung Read Write FAT ATmega8 (Assembler)" für einen GPS-Logger. Eigentlich funktioniert auch alles gut, nur habe ich das Problem, daß die Kommunikation mit der Karte in der Regel nicht sofort startet. Ich muß dann bei anliegender Spannung die Karte entfernen und erneut einschieben. Dann funktioniert es problemlos. Woran könnte das liegen?
An einer falschen Initialisierung. Möglicherweise muss man nach dem Reset ein paar hundert Millisekunden warten.
Falk B. schrieb: > An einer falschen Initialisierung. > Möglicherweise muss man nach dem Reset ein paar hundert Millisekunden > warten. Danke für den Hinweis! Leider liegt es daran nicht. Auch eine Pause von 1s hat nicht geholfen. Ich habe jetzt mal detaillierter getestet und festgestellt, daß das Programm hier hängen bleibt:
1 | LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN: |
2 | ;------------------------------------------------------------------------------- |
3 | ; den ENDE-CLUSTER in FAT suchen |
4 | ;------------------------------------------------------------------------------- |
5 | ; INITIALISIEREN auf STARTCLUSTER |
6 | LDS temp1,(adr_DATEI_STARTCLUSTER_L) |
7 | LDS temp2,(adr_DATEI_STARTCLUSTER_H) |
8 | STS (adr_CLUSTER_DATENSATZ_NR_L),temp1 |
9 | STS (adr_CLUSTER_DATENSATZ_NR_H),temp2 |
10 | LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_SCHLEIFE: |
11 | ; FAT EINTRAG auslesen, bis letzter FAT Eintrag (xFF xFF) gefunden wurde |
12 | WDR |
13 | rcall FAT_TABELLE_EINTRAG_AUSLESEN |
14 | ; AUSWERTUNG (ist es der letzte Cluster) |
15 | LDS temp1,(adr_CLUSTER_INHALT_BYTE_L) |
16 | LDS temp2,(adr_CLUSTER_INHALT_BYTE_H) |
17 | cpi temp1,255 |
18 | brne LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_SCHLEIFE_w |
19 | cpi temp2,255 |
20 | brne LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_SCHLEIFE_w |
21 | rjmp LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_GEFUNDEN |
22 | LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_SCHLEIFE_w: |
23 | ; Inhalt übernehmen und erneut FAT einlesen |
24 | LDS temp1,(adr_CLUSTER_INHALT_BYTE_L) |
25 | LDS temp2,(adr_CLUSTER_INHALT_BYTE_H) |
26 | STS (adr_CLUSTER_DATENSATZ_NR_L),temp1 |
27 | STS (adr_CLUSTER_DATENSATZ_NR_H),temp2 |
28 | rjmp LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_SCHLEIFE |
29 | LETZTEN_BESCHRIEBENEN_CLUSTER_DER_DATEI_SUCHEN_GEFUNDEN: |
30 | ; gefunden => speichern |
31 | LDS temp1,(adr_CLUSTER_DATENSATZ_NR_L) |
32 | LDS temp2,(adr_CLUSTER_DATENSATZ_NR_H) |
33 | STS (adr_CLUSTER_ENDECLUSTER_L),temp1 |
34 | STS (adr_CLUSTER_ENDECLUSTER_H),temp2 |
d.h. das Programm sucht eine bestimmte Datei, findet sie auch (obwohl sie gar nicht vorhanden ist) und bleibt dann bei der Suche nach dem letzten beschriebenen Cluster hängen. Evtl. hat es etwas damit zu tun, daß die Datei ja nur als gelöscht gekennzeichnet wird und gar nicht gelöscht.
Solche Sachen mal man nicht mehr in ASM. Das ist wie Freeclimbing. Kann man machen, ist aber wenig sinnvoll. Nimm eine fertige, getestete Lib in C, die läuft. Ich kann die von Elm Chan empfehlen. SD-Card
Bruno M. schrieb: > Leider liegt es daran nicht. Auch eine Pause von 1s hat nicht geholfen. > Ich habe jetzt mal detaillierter getestet und festgestellt, daß das > Programm hier hängen bleibt: [...] > d.h. das Programm sucht eine bestimmte Datei, findet sie auch (obwohl > sie gar nicht vorhanden ist) und bleibt dann bei der Suche nach dem > letzten beschriebenen Cluster hängen. D.h.: Der eigentliche Scheiß passiert bereits lange vor der Stelle, die du hier geposted hast. Wenn der Code eine Datei findet, die auf dem Medium garnicht existiert, dann ist der Code schlicht kaputt. Oder die Strukturen des Filesystems. So einfach ist das. Und wenn die C-Apologeten hier rumtönen, dass das an der Verwendung von Asm liegen würde, ist das natürlich völliger Quatsch. Ganz genau wie in C ist es einfach nötig, fehlerfreien Code zu benutzen und diesen dann auch fehlerfrei zu benutzen. Beispiel: Wie lange hat es doch gleich gedauert, bis der ext4-fs-Treiber für Linux (natürlich vollständig in C geschrieben) so stabil war, daß er auch tatsächlich freiwillig verwendet wurde? Jahre!!! Und der konnte immerhin in weiten Teilen auf gut getesteten Code von ext2 und ext3 zurückgreifen. Also: natürlich kann in dem von dir verwendeten FS noch ein fieser Bug lauern. Aber der ist in Asm weder wahrscheinlicher noch schwerer zu finden oder zu beheben als in C. Nur die wirklich leicht zu findende Bugs sind in Asm deutlich wahrscheinlicher als in C. Der Rest der Lügen über die angeblich höhere Fehlerträchtigkeit von Asm ist reine Propaganda.
> ... die C-Apologeten hier rumtönen ...
Außer dir tönt hier keiner. Du bist der geborenen Großsprecher und
Krakeeler. Das interessante dabei ist, dass vor dir nie eine Lösung
kommt, sondern nur langweilige Beiträge mit Geschwätz.
Bruno M. schrieb: > Woran könnte das liegen? Warum fragst Du nicht Bernhard S. selber? Der ist nach wie vor im Forum aktiv und wird seinen Code und die zugehörige Thematik am besten kennen! Abel schrieb: > Außer dir tönt hier keiner. Du bist der geborenen Großsprecher und > Krakeeler. Das hat Asm doch gar nicht nötig. Dessen Vorteile sind viel zu eindeutig!
Abel schrieb: > Außer dir tönt hier keiner. Dir fällt das nur nicht so auf, weil du bereits hinreichend gehirnamputiert wurdest. > Das interessante dabei ist, dass vor dir nie eine Lösung > kommt Ah ja. Du hast also rein garnichts von dem ganzen Zeug auch nur verstanden, was ich gepostet habe. OK, ich gebe zu, da waren durchaus auch einige Rohrkrepierer dabei. Aber in der überwiegenden Mehrheit war es doch durchaus zielführende Hilfe zur Selbsthilfe. Ja, von mir gibt's fast niemals fertigen Code für's stupide C&P-"Programmieren". Das ist so gewollt. Ich bin im Gegensatz zu den C-Apologeten eben nicht daran interessiert, einen Haufen willfährige Idioten als schleimerisches Fußvolk zu gewinnen. Nein, ich will selbstständig denkende, echte Programmierer aus der Masse der C&P-Vollidioten herausheben. Die sind, weiß Gott, verdammt knapp geworden...
Sicherheitshalber könnte man die SDC auf einer anderen Platform testen. Wenn man experimentiert kann es passieren dass die Karte einen Defekt kriegt manche Sektoren nicht mehr lesbar sind und dann ihre Position ständig verändern. Das Problem deutet sich dann so wie beschrieben an. Erst nach vielfältigen Resets und auch Ausprobieren von verschiedenen Adaptern kriegt man die Karte korrekt ins Laufen. Das wird dann immer schlimmer.
>Dessen Vorteile sind viel zu eindeutig!
Stimmt, man kann damit sehr schnelle Bugs programmieren
die nur schwer zu fangen sind;)
holger schrieb: > Bugs ... > die nur schwer zu fangen sind Aber nur für c-hater schrieb: > C-Apologeten (um nicht gleich den schlimmeren Ausdruck zu verwenden ;-)
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.