Hallo, ich habe hier mal eine kleines Übungs-Projekt gebastelt und wollte das evtl Interresierten nicht vorenthalten. Vielleicht kann der ein oder andere ja Teile davon gebrauchen, vorne weg es ist schlecht bis gar nicht in noch schlechterem englisch dokumentiert, ich habs auf Basis des DE0-nano boards gebastelt, es gibt mit Sicherheit tausend Wege es besser zu machen, aber für mich als Neuling was hardware design angeht bin ich erst mal damit zufrieden das es bis jetzt stabil läuft. Vielleicht hat ja jemand mal die Muße es sich an nem schlecht Wetter Tag an zu schauen und ggf. Verbesserungsvorschläge zu machen und Tipps zu geben :). Ich habe als Anhang nur die relevanten soure files angehängt. Also das Ganze ist ein remote, nur lese- , Zugriff auf eine SD Karte. Die remote Verbindung läuft über seriell (115200 baud) PC <-> FPGA. Die Initialisierung der SD Karte übernimmt der FPGA (card clock: 400KHz während init danach 25MHz, 4 bit SD mode, nur SingleReadBlock(512 bytes). Die c-sharp test Anwendung kann also per serieller Schnittstelle die Sektor-Daten der SD Karte lesen. Der MBR wird gelesen, die Paritions Tabelle wird gelesen, die erste FAT32 Partition wird ausgewählt, die FAT Partitionsdaten werden gelesen und es geht in einen einfachen Terminal Modus in dem man durch die Verzeichnisse "browsen" kann, und sich Dateien im Terminal ausgeben und auch downloaden kann. Das ist soweit auch schon alles. Wie gesagt nix dolles, aber evtl. kann es ja jemand irgendwie gebrauchen. Es ist zu erwähnen im source der c-sharp Anwendung(Program.cs) gibt es: "static string COM = "COM3";" - das ist der zu verwendende COM Port "const bool COMDISABLED = false;" - die Konstante auf true setzen wenn man NICHT "live" mit dem FPGA arbeiten möchte. Die Sektor-Daten werden dann aus Dateien ausgelesen zu Simulationszwecken. des weiteren gibt es: "const string STORAGE_PATH = @".\bin\";" das ist der Pfad an dem sich die Sektor-Daten Dateien befinden und auch abgelegt werden. wer nicht möchte das Sektor-Daten Dateien angelegt werden wenn man "live" mit dem FPGA arbeitet der sollte an denn Stellen im code wo die "ReadSector" Methode aufgerufen wird, den letzten Parameter ", true" entfernen oder in ", false" ändern - ja könnte man auch schöner gestalten. Zum Schluss, ich plane weitere Experimente mit dem sdcard controller (MultiSektorRead und evtl. auch schreiben auf die Karte) aber zu erst fände ich eine Art von cache gut um Zugriffe auf die Karte zu minimieren nur hatte ich da noch keine gute Idee, evtl. reicht es nur eine Teil zu cachen z.B. den der FAT... mal schauen, vielleicht hat jemand von euch eine Idee? ...
Oh ich glaube mir ist da grad ein Fehler aufgefallen, die card clock kann wohl nur 12,5MHz in meinem Beispiel sein und nicht 25MHz, wenn ich mich nicht irre... aber es ist auch schon spät...
Christian G. schrieb: > Oh ich glaube mir ist da grad ein Fehler aufgefallen, die card clock > kann wohl nur 12,5MHz in meinem Beispiel sein und nicht 25MHz, wenn ich > mich nicht irre... aber es ist auch schon spät... ... bzw eher 16 MHz (100 MHz / 6) und CLOCK_DIV_INIT kann man ruhig auf 62 runter setzen dann passts auch wieder mit den 400KHz. oha, wohl doch noch nicht so ganz fertig...
Christian G schrieb: > oha, wohl doch noch nicht so ganz fertig... ... auch wenn's noch nicht ganz fertig ist: ich hab' schon viel Schlechteres gesehen. M.A.n. eine stolze Leistung für einen Anfänger. Sowohl was die Idee als auch was die Umsetzung angeht.
Markus F. schrieb: > ... auch wenn's noch nicht ganz fertig ist: ich hab' schon viel > Schlechteres gesehen. M.A.n. eine stolze Leistung für einen Anfänger. > Sowohl was die Idee als auch was die Umsetzung angeht. Vielen Dank, das macht Mut zu mehr! Ich werde den controller bei genug Freizeit nochmal überarbeiten um auf die 25MHz card clock zu kommen, muss doch zu schaffen sein. Momentan trifft man halt beim setzen und lesen von der command Leitung genau den ich nenne es mal "sweet spot" wenn die card_clock low ist auf der höheren Geschwindigkeit, klappt aber nur wenn ich mir da halt 3 Takte Zeit lasse. Aber fürs experiementieren ist es so schnell genug.
Ohne es jetzt nachgeprüft zu haben: In deinen UART-Modulen (RX/TX) wird die Konstante <prscl_half> definiert als:
1 | prscl_half : integer range 0 to ((clock_speed / baud) - 1) / 2 |
müsste es nicht
1 | prscl_half : integer range 0 to ((clock_speed / baud / 2) - 1) |
sein? --------------------------------------------- MOD: [pre] Tags eingefügt
:
Bearbeitet durch Moderator
Sigi schrieb: > Ohne es jetzt nachgeprüft zu haben: > In deinen UART-Modulen (RX/TX) wird die Konstante > <prscl_half> definiert als: > > prscl_half : integer range 0 to ((clock_speed / baud) - 1) / 2 > > müsste es nicht > > prscl_half : integer range 0 to ((clock_speed baud 2) - 1) > > sein? Ich denke du hast Recht, aber wenn ich mich jetzt nicht selbst verrechnet habe läufts, dadurch das es ein ganzzahliger integer wird, aufs gleiche Ergebniss hinaus. Müsste man einfach mal simulieren um sicher zu gehen.
Christian G schrieb: > aber wenn ich mich jetzt nicht selbst verrechnet habe Es ist das übliche "off by one" Problem, das "nichts ausmacht", so lange die Zahl groß (und mithin der Fehler klein) genug ist ;-) > läufts ... aufs gleiche Ergebniss hinaus. Mit beispeilsweise 255 und 3 kommen mal 42 und mal 41 (abgeschnittene 41,5) raus. Ist ja naheliegend: einmal wird 1 abgezogen und einmal 1/2...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Christian G schrieb: >> aber wenn ich mich jetzt nicht selbst verrechnet habe > Es ist das übliche "off by one" Problem, das "nichts ausmacht", so lange > die Zahl groß (und mithin der Fehler klein) genug ist ;-) > >> läufts ... aufs gleiche Ergebniss hinaus. > Mit beispeilsweise 255 und 3 kommen mal 42 und mal 41 (abgeschnittene > 41,5) raus. Ist ja naheliegend: einmal wird 1 abgezogen und einmal > 1/2... ... hat etwas gedauert aber konnte mich nun erinnern warum ich diese Rechnung gewählt habe... es war einfach ein sehr naiver Gedanke, mit der Rechnung ist im Zweifelsfall die uart clock einen Takt langsamer und das fand ich zu dem Zeitpunkt einfach besser als evtl mal einen Takt zu schnell zu sein.... ja ich merke auch wie sich das nun anhört.... Btw. habe es heute Nacht noch hinbekommen die SD Karte mit der 25MHz clock zu betreiben (command , response läuft, Datentransfer noch nicht getestet), musste dafür aber ein paar Dinge "umbauen" und ob es auch mit einem langsameren Haupttakt als 100MHz läuft ist auch noch fraglich... Ich werde die aktuellen files wenn dann alles wieder läuft bereitstellen.
... im Anhang dann die überarbeitete Version 2.0 jetzt mit Kommentaren und 25MHz SD Karten clock(nur getestet mit 100MHz "System clock")...
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.