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.
Aus Zeile 42 das "#delay(5000)_chr_trim" entfernen
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
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
Gast
#4308804
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.
Gast
#4308811
> ... 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!
Gast
#4308890
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...
Gast
#4308902
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.
Gast
#4308907
>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 ;-)