Assembler Alle Hersteller und Dateiformate von SD Karten in AVR ASSEMBLER auf ATmega128A ?

[MirNachIchFolgeEuch]

Hallo erstmal

Ich habe bezüglich meines Elektrotechnik-Studiums ein Projekt zu bearbeiten.




Die Aufgabe ist,

einen Schreib-Lesezugriff für SD-Karten von beliebigen Herstellern und in möglichst allen für SD Karten verfügbaren Dateiformaten in AVR Assembler für einen ATmega128A zu realisieren.

Ich bin völlig neu in der Assembler Programmierung und muss mich noch an komplexere Aufgabenstellungen (sofern das komplex ist) heranarbeiten.
Es geht mir aber nicht darum irgendein vollständiges Programm einfach zu kopieren damit die Arbeit einfach mehr oder weniger ohne Lerneffekt getan ist!

Ich habe mich schon durch diverse Beiträge in verschiedenen Foren gelesen und würde im Moment eigentlich nur eine Sache gerne wissen:

Ist es möglich bzw hat es schon jemand geschafft, die oben gestellte Aufgabe zu lösen?

Falls ja wäre ich für Tipps bzw Links zu einschlägigen Seiten sehr dankbar
Im Netz habe ich bisher leider wenig dazu gefunden

Beste Grüße

 

[daniel123]

In Assembler nein, in C ja. Spi ist super geeignet. Fertige Bibliothek ist zb die ELM Chan bib, habe die schon erfolgreich getestet. Müsste auch irgendwo noch was eigenes haben, nur wo

Was für seiten suchst du denn? Wo das Prinzip der SD Karte erklärt wird, Beispiele, ...?

 

[LotadaC]

Hi,

die eigentliche Kommunikation sollte nicht das Problem sein - SD sollte über das SPI gehen (bei 3,3V, aber Du kannst den Controller ja auch mit 3,3V betreiben).

Komplett unklar ist, was Du auf die Karten schreiben/lesen willst (also wo die zu schreibenden Daten herkommen, wo die zu lesenden hin sollen).
Wie die "Bedienung" des ganzen realisiert werden soll.

Und das "S" steht ja eigentlich für Secure - ich hab da was mit teuren Lizenzen der Verschlüsselung im Kopf.

Oder gibts irgendwelche öffentlichen Teile, die DIR ausreichen - dann mußt Du Dich erstmal in diesen ganzen Kram reinknien, bevor das in den AVR implementiert werden kann...

AFAIK gabs im Parallelforum aber dazu schon diverse Beiträge (bei microcontroller.net warst Du sicher selbst schon...)

 

[dino03]

Hi und herzlich willkommen im Forum

Ich habe bezüglich meines Elektrotechnik-Studiums ein Projekt zu bearbeiten.

ui ... im Moment häuft sich das wieder
Wieviel Zeit steht denn zur Verfügung?

Die Aufgabe ist,

einen Schreib-Lesezugriff für SD-Karten von beliebigen Herstellern und in möglichst allen für SD Karten verfügbaren Dateiformaten in AVR Assembler für einen ATmega128A zu realisieren.

na das wird ja spaßig.
- SD-Karten
- SDHC-Karten
- SDXC-Karten

- FAT16
- FAT32 / VFAT
- NTFS (gibts auch in verschiedenen Versionen)
- Ext2
- Ext3
- ... usw.

Wieviel Monate hast du denn zur Verfügung? Alleine die Sammlung der Daten für die Dateisysteme wird schon nen Monat dauern. NTFS hat ein paar Jahre benötigt bis die unter Linux halbwegs alles zusammen und lauffähig hatten. Für die ganzen Ansteuermöglichkeiten der SDxxx-Karten wirst du auch einiges an Zeit alleine für die Datensammlung benötigen.

Ich bin völlig neu in der Assembler Programmierung und muss mich noch an komplexere Aufgabenstellungen (sofern das komplex ist) heranarbeiten.

... und ob das komplex ist. Aber man wächst ja mit seinen Aufgaben

Es geht mir aber nicht darum irgendein vollständiges Programm einfach zu kopieren damit die Arbeit einfach mehr oder weniger ohne Lerneffekt getan ist!

Ich habe mich schon durch diverse Beiträge in verschiedenen Foren gelesen und würde im Moment eigentlich nur eine Sache gerne wissen:

Ist es möglich bzw hat es schon jemand geschafft, die oben gestellte Aufgabe zu lösen?

Falls ja wäre ich für Tipps bzw Links zu einschlägigen Seiten sehr dankbar
Im Netz habe ich bisher leider wenig dazu gefunden

Für Bascom gibt es wohl ne Umsetzung für einen FAT-(oder VFAT-?)-Zugriff auf SD-Karten. Wenn ich mich recht entsinne, dann ist aber zwischen SD, SDHC und SDXC auch noch die Ansteuerung der Datenblöcke auf der Karte unterschiedlich.

Ich hab mal ne Diplomarbeit für die EXT3-Erweiterung (das Journaling) für das EXT2-Filesystem im Internet gefunden. Die hat auch schon so einiges an Seiten gehabt

Also in Assembler wirst du da richtig viel Spaß haben
In C wird das eher machbar sein. Ob das aber alles in nen Mega128 reinpaßt kann ich dir nicht sagen
Ein Dateisystem wirst du wohl unterkriegen. Aber mehrere Dateisysteme ... Es muß ja auch noch irgendwas an Applikation dazu. Ein reines Dateisystem mit Ansprache der Karten nur zum Selbstzweck wird nicht wirklich was bringen wenn man mit den Daten die man schreiben und lesen kann nichts anfängt. Und wenn es nur ne Übertragung über die serielle Schnittstelle zum PC ist.

Naja ...
Gruß
Dino

 

[Hemi]

Das ist mal eine krasse Aufgabe und dann auch noch in Assembler, gleich ein Volltreffer.

Also die Anbildung der SD-Karte über SPI ist jetzt nicht so das Problem, auch die "low level Treiber" würden gehen, Pin selektieren, takten, Byte übertragen, ....

Aber der Rest ist heftig. Ich habe FAT16 mal selber implementiert, aus Spaß an der Freude, dann FAT32, aber da habe ich eine fertige Lib verwendet, die FatFS mit RTC. Aber ich habe es auf einem Cortex-M3 (mit richtig Speicher) gemacht und es war keine SD-Karte sondern USB-Stick.

Wieviel Monate hast Du dazu?

 

[MirNachIchFolgeEuch]

Hey,

erstmal vielen Dank für die schnellen Antworten hatte schon vermutet, dass es sehr schwierig wird.

@daniel123

- leider ist C keine Option warum genau ist es nicht möglich das in Assembler zu realisieren?
- Ich suche Seiten, wo Schritt für Schritt erklärt ist, was an an welcher Stelle zu tun hat bzw was passiert. In einer für einen Anfänger halbwegs verständlichen Version. Das Datasheet zu SD Karten bzw ihrer Initialisierung ist keine große Hilfe. Dort steht zwar der Ablauf, aber nichts ist genau (bzw für mich verständlich) erklärt (am Englisch liegt es nicht) und wenn ich mir Programmauszüge anschaue stehen dort Sachen die ich im Datasheet nicht finde.

Sowas wie:

sbi Portb, 0 ;Set CS high--> SD Card inaktiv
ldi temp1,$FF
call sende
call sende
cbi Portb, 0 ;Set CS low--> SD Card aktiv

Transmission: ; Start transmission of data

out SPDR,temp1 ; schreibe Wert in SPI Data Register (SPDR)

Wait_Transmit: ; Wait for transmission complete

sbis SPSR,SPIF ; Transfer abgeschlossen?
jmp Wait_Transmit ; --> SPI Interrupt Flag (SPIF) im SPI Statusregister (SPSR) auf 1


Der Sendevorgang (Transmission) ist klar, aber was habe ich davon, wenn ich $FF sende, während die Karte inaktiv ist? Vermutlich ist es aber ganz einfach und ich komme nicht drauf


@LotadaC

- Ich wäre zunächst schon sehr glücklich, wenn man es hinkriegen könnte, SD Karten von allen Herstellern nur zu initialisieren. Bisher habe ich noch keinen Beitrag gefunden wo das der Fall war, obwohl es doch eigenlich gehen sollte.

- Das ganze soll später dazu dienen, sowas wie das Datum und die Uhrzeit und diverse Prozessdaten als Dokument z.b. Excel Format auf der Karte zu speichern oder vlcht sogar Programmupdates für den MCU durchzuführen.

Ich wäre im Moment schon glücklich, wenn ich es schaffe, eine Transcent Karte (2GB) Fat 16 zu initialisieren und bei erfolgreicher Initialisierung ein Lämpchen zum blinken zu bringen. Eine über Taster steuerbare Blinkanlage mit Interrupt habe ich schon programiert. Nur mit der Peripherie tue ich mich schwer.
Ich greife folglich zwar weit vor, aber so groß können die Unterschiede zwischen den Herstellern doch nicht sein


@dino03

- Ich bin jetzt einen Monat dran, 5 Tage/Woche, 8 Stunden täglich und habe noch ca 5 Monate. Ich muss dazu sagen, dass ich mich nicht 8 Stunden voll konzentrieren kann und es mir nicht unbedingt leicht fällt, mich in das Thema einzulesen.
Offen gestanden hatte ich es mir auch einfacher vorgestellt, da kannte ich Assembler noch nicht. Hatte vorher nur ein wenig mit C, VHDL und SimaticS7 zu tun.

@Hemi

-Zeit habe ich, wie schon oben erwähnt, noch ca 5 Monate in Vollzeit Stelle. Aber es MUSS in Assembler sein, da man auf die Performance auf keinen Fall verzichten will und ansonsten auch nicht den Speicher zur Verfügung hat.

 

[daniel123]

Aber selbstverständlich kannst du alles was in C möglich ist, auch in Assembler programmieren. Ist nur aufwendiger weil eben noch hardware nähere Sprache.

Für die Vorgehensweise könnten dir, wie gesagt, fertige Bibliotheken helfen, auch die in C. Hangel dich einfach mal Schritt für Schritt durch die Funktionen, mache dir klar, warum dieses oder jenes gemacht wird und vergleiche das mit Datenblättern. elm-chan

Seiten die Schritt für Schritt erklären, wird es glaube ich nicht geben. Probiere erstmal die grundlegenden Operation, initialisieren, Datei öffnen, erstellen, schreiben, ....


Du hast es richtig erkannt, dein Projekt ist extrem ehrgeizig und komplex, gerade in Assembler. Eigentlich müsste dir doch für SD Karten die Fat Formate reichen? FileSize 4Gb dürfte für Mikrocontroller ausreichen. Selbst moderne 4K Videokameras benutzen häufig fat32 und teilen die größeren Datein in kleiner 4Gb parts.

 

[TommyB]

Performance und Speicher wird bei der Aufgabe ohnehin ein Problem.
Die zig verschiedenen Dateisysteme, Partitionstabelle mit all ihren Eigenheiten, die unterschiedlichen Arten der Ansteuerung (grade MicroSD Karten unterstützen den MMC Modus (SPI) nicht immer, daher wird der Code bei solchen Karten auch nicht funktionieren), ...

Aber trotzdem gilt: Nur weil es C / Bascom / LunaAVR ist heißt es noch lange nicht dass es weniger performant ist als Assembler. Wahrscheinlich ist in deinem Fall eher das Gegenteil der Fall. Die fertigen Libs sind häufig schon stark optimiert. Vielleicht nicht 100% optimal, aber bestimmt besser als man es selber machen könnte.

Ich bastel und programmiere ja gerne, aber diese Aufgabe wäre mir zu hoch. Grade wenn man Assembler noch nicht so kann ist das echt hart. 4 Monate wär selbst mir zu wenig.

Wenn du nur z. B. ADC Werte speichern möchtest oder Karten 1zu1 kopieren möchtest bräuchte man noch nicht mal ein Dateisystem einzubinden. Mehr würde ich persönlich auf keinen Fall umsetzen. Ist mir auch zu gefährlich, denn jeden Fehler im Dateisystem können dir deine Dateien sehr übel nehmen


Trotzdem viel Erfolg

 

[dino03]

Hi,

@dino03

- Ich bin jetzt einen Monat dran, 5 Tage/Woche, 8 Stunden täglich und habe noch ca 5 Monate. Ich muss dazu sagen, dass ich mich nicht 8 Stunden voll konzentrieren kann und es mir nicht unbedingt leicht fällt, mich in das Thema einzulesen.
Offen gestanden hatte ich es mir auch einfacher vorgestellt, da kannte ich Assembler noch nicht. Hatte vorher nur ein wenig mit C, VHDL und SimaticS7 zu tun.

@Hemi

-Zeit habe ich, wie schon oben erwähnt, noch ca 5 Monate in Vollzeit Stelle. Aber es MUSS in Assembler sein, da man auf die Performance auf keinen Fall verzichten will und ansonsten auch nicht den Speicher zur Verfügung hat.

ups ... noch nicht viel mit Assembler gemacht und dann schon gleich ein performantes und kompaktes Programm schreiben müssen Also ich drück dir auf jeden Fall die Daumen

Man kann in Assembler sehr viel sehr schnell und kompakt machen wenn man etwas quer denkt und Sachen teilweise auf Bitebene runterbricht. Durch Bitmanipulationen (Set/Clear) und Schiebe oder Rotierbefehle sowie Bit-Tabellen kann man ne Menge Sachen sehr effizient lösen. Wesentlich effizienter als in jeder Hochsprache. Dafür braucht es aber schon ein wenig Einarbeitung.

Dein Ding mit dem $FF senden und warum ... Es gibt Sachen die einfach mal vorher gemacht werden um zB irgendwelche Register von Restmüll zu befreien. Einfach mal $FF auf dem SPI raussenden um zum Beispiel mit nachfolgenden $00-Sendungen rauszubekommen wieviel Byte-Breite Schieberegister da in Reihe geschaltet sind. Wenn das $FF wieder zurückkommt kann man das zB ausrechnen. Ist aber jetzt nur mal ein Beispiel. Soll also nicht heißen das genau das in deinem Programmstück so gemacht wird.

Bei effizienten Assemblerprogrammen sind zB bei Subroutinen mehrere Einsprungpunkte am Anfang. Man baut die Subroutine also Schichtweise auf. Je nachdem wo man reinspringt hat man dann in der Subroutine mehr oder weniger Arbeit erledigt. zB ein Zeichen auf dem Display ausgeben. Man lädt das Zeichen in ein Register und springt etwas weiter hinten in die Subroutine. Dann wird das Zeichen zum Display geschrieben. Weiter vorn in der Subroutine wird zB noch ein Ladebefehl für CRLF eingebaut. Wenn man den Bereich anspringt, bekommt man immer einen Zeilensprung ohne vorher das Register extra immer damit laden zu müssen. Das macht ja bereits die Subroutine durch den etwas nach vorne gezogenen Einsprung. Manche Subroutinen haben auf die Art dann zB 5, 10 oder noch mehr Einsprungpunkte.Teilweise sogar mehrere Aussprungpunkte. Und immer muß man darauf achten den Stack sauber zu hinterlassen. Es wird also zB wenn man vorher rausspringt einfach was nicht mehr benötigtes vom Stack geholt und vernichtet. Manche Programmierer bauen zB über Push-Befehle bei denen 2 Bytes auf den Stack gepackt werden, dynamische Sprungtabellen. Dann wird zB mit Return ein Unterprogramm angesprungen indem die Sprungadresse vom Stack geholt wird. Normalerweise ist Return ja für einen Rücksprung aus einer Subroutine zuständig. Es wird also viel quergedacht. Man kann Befehle also auch zweckentfremden.

Solche Tricks sieht man in alten Dokus zB vom Sinclair ZX81-ROM oder ZX-Spectrum-ROM oder anderen alten 8Bit-Heimcomputern. Da gibt es Bücher mit dem Hexcode, den Mnemonics (Befehlen) daneben und dann den entsprechenden Dokuzeilen was die da warum gemacht haben. Ein 8k-ROM kann da als Buch schon ein paar hundert Seiten lang sein.

Das wichtigste ist auf jeden Fall im Moment erstmal das du die Aufgaben in kleine Module zerhackst die du dann versuchst in Programmcode umzusetzen. Wenn das nicht geht, dann sind die Module evtl noch zu groß und du mußt kleiner hacken.

Gruß
Dino

 

[unilein]

Hi,


Solche Tricks sieht man in alten Dokus zB vom Sinclair ZX81-ROM oder ZX-Spectrum-ROM oder anderen alten 8Bit-Heimcomputern. Da gibt es Bücher mit dem Hexcode, den Mnemonics (Befehlen) daneben und dann den entsprechenden Dokuzeilen was die da warum gemacht haben. Ein 8k-ROM kann da als Buch schon ein paar hundert Seiten lang sein.

Ja, so ein sogenannte ROM-Listing habe ich vom VZ200 (aber auch Laser 210/Laser 310, alle von Video Technology, heute VTech) als Buch. Sehr interessant! Und wirklich einfallsreich umgesetzt. So wie es Dino schon beschreibt, werden Routinen auf unterschiedliche Art und Weise angesprungen und auch unterschiedlich "aufgeladen" um die Effizienz zu steigern. Für mich heute noch inspirierend.

Mich würde ja jetzt mal interessieren, was aus dem Projekt von MirNachIchFolgeEuch geworden ist. Die Zeit ist ja inzwischen um.

Gruß
Uni

 

[dino03]

Hi,

Mich würde ja jetzt mal interessieren, was aus dem Projekt von MirNachIchFolgeEuch geworden ist. Die Zeit ist ja inzwischen um.

ich tippe mal ...

- Pflichtenheft stark zusammengestrichen ... oder
- SD-Karte rausfallen lassen ... oder
- in anderem Forum weitergemacht ... oder
- ganzes Projekt über den Haufen geschmissen ... oder
- ... ???

Da wird wohl wie üblich keine Antwort rüberkommen. Mal wieder ein offenes Ende ...

Gruß
Dino

 

[TommyB]

Da wird wohl wie üblich keine Antwort rüberkommen. Mal wieder ein offenes Ende ...

Das findet man leider überall. Nur die wenigsten denken daran wenn etwas funktioniert (oder aufgegeben wird) Bescheid zu sagen. Schade sowas.

 

[LotadaC]

...
ich tippe mal ...

- Pflichtenheft stark zusammengestrichen ... oder
- SD-Karte rausfallen lassen ... oder
- in anderem Forum weitergemacht ... oder
- ganzes Projekt über den Haufen geschmissen ... oder
- ... ???

Ich hätte ja beinahe dieselbe Liste gepostet - allerdings waren da statt der Fragezeichen noch die etwas weniger negativen Punkte:
- aufgrund irgend'ner supertollen Erfindung etc. keine Notwendigkeit mehr (gabs hier nichtmal wen, der so'n "Fernseher-Wecker" vermarkten wollte, dieweil jeder sowas braucht/will...)
- als HiWi mit anderen Projekten ausgelastet