Hallo Ich wollte bloß wissen, welchen ATMega ich mindestens nehmen muss, um den Code für nen MP3-Player mit lesen von SD-Karte und der Ansteuerung eines MP3-Decoderchips unterzubringen? Und: welche Taktfrequenz ist mindestens für ein entspanntes Abspielen, im Worst Case von MP3s mit 320kbit/s, nötig? Danke euch
Johannes Hofmann schrieb: > Und: welche Taktfrequenz ist mindestens für ein entspanntes Abspielen, > im Worst Case von MP3s mit 320kbit/s, nötig? also 320kbit/s wirst du wohl kaum schaffen, dafür wird deine FAT-Implantierung auf nem Atmega zu langsam sein.
Ein ganz simples Ding passt auf jeden Fall in einen ATMEga8. Unter 8MHz sollte der für 320kbit/s aber nicht laufen.
>also 320kbit/s wirst du wohl kaum schaffen, dafür wird deine >FAT-Implantierung auf nem Atmega zu langsam sein. Och, das geht schon. Wenn man die FAT nicht zu sehr fragmentiert ist das kein Ding.
Johannes Hofmann schrieb: >also 320kbit/s wirst du wohl kaum schaffen, dafür wird deine >FAT-Implantierung auf nem Atmega zu langsam sein. Schmarn, VS1002 und Atmega32 auf 16Mhz funzt bei mir Einwandfrei mit MP3 auf 320kBit/s, höher habe ich noch nie getestet allerdings.
echt, schafft der das so schnell, der kleine Atmega. ich hab mich immer daran orientiert: Beitrag "Re: MMC/SD-Karte mit FAT16 an AVR" Puffer (B) | Zeit (s) | Geschw. (kb/s) ------------------------------------------ 8 | 13 | 78 16 | 9 | 114 32 | 6 | 171 64 | 5 | 205
Wer von euch hat denn nun recht? Holger meint, es reicht bereits ein mega8, Julian dagegen, die gesamte Mega-Reihe reiche nicht aus. Wenn es mit nem Mega8 klappen würde, wär ich sehr beglückt (Platinengröße). Update: Haha, da wurde in der Zeit, in der ich die Antwort schrieb ja schon was neues gepostet.
Also das hier ist der letzte Benchmark, den ich jetzt von dieser FAT-Implantierung gefunden habe: http://www.roland-riegel.de/sd-reader/benchmarks/ Ausschnitt:
1 | |
2 | Read FAT-16 |
3 | Chunk size (Bytes): 2048 |
4 | Time (s) : 10.0 |
5 | Data rate (kB/s) : 204.8 |
6 | |
7 | Test conditions: ATmega128 at 14.745 MHz, 128 MB SD card, FAT16-only configuration, 2 MB file, FAT16-only configuration, buffered access, without timestamps. |
8 | |
9 | |
10 | Read FAT-32 |
11 | Chunk size (Bytes): 2048 |
12 | Time (s) : 8.5 |
13 | Data rate (kB/s) : 240.9 |
14 | |
15 | Test conditions: ATmega128 at 14.745 MHz, 4 GB SDHC card, FAT32, 2 MB file, buffered access, without timestamps. |
Ups, du hasst ja 320 kbits geschrieben und hier sind die Werte in kbs. Also dürfte es klappen, da 200 kbs in etwa 1600 kbits sind. Edit: Ist hier wohl etwas problematisch, kbit/s fett zu schreiben ;)
Ich möchte ja die Dateien direkt von meiner Muckesammlung auf die SD-Karte ziehen. Aber da benötige ich ja FAT32. Da wird's ja noch enger... Naja, mal ausprobieren.
Johannes Hofmann schrieb: > Ich möchte ja die Dateien direkt von meiner Muckesammlung auf die > SD-Karte ziehen. > Aber da benötige ich ja FAT32. Da wird's ja noch enger... > > Naja, mal ausprobieren. Nö, passt doch. FAT32 ist sogar noch schneller! 320 kbits (Kilobits) entsprechen 40 kbs (Kilobytes). Nach dem Benchmark von Holger schafft seine FAT32-Implantierung bei 14,745 MHZ 240 kbs Das ist etwa 6mal so schnell, wie du für die Wiedergabe von 320 kbits brauchst! Müsste also dicke reichen.
>Wenn es mit nem Mega8 klappen würde, wär ich sehr beglückt >(Platinengröße). Kommt auf deine Sonderwünsche an. Wenn Grafik-LCD mit Menüsteuerung, Fernbedienung, alphabetisches sortieren der Songs, Anzeige ID-Tags, Playlist Support und so weiter gewünscht ist, dann landest du irgendwann bei einem ATMega128 mit 64kB externem RAM. ATMega8: Text LCD für aktuelle Songanzeige plus ein paar Taster zur Bedienung. Keine Menüführung, nix sortieren, keine Playlists. Also ein simples Ding. Vorspulen ist schon fast Luxus ;)
holger schrieb: > ATMega8: Text LCD für aktuelle Songanzeige plus ein paar Taster > zur Bedienung. Keine Menüführung, nix sortieren, keine Playlists. > Also ein simples Ding. Vorspulen ist schon fast Luxus ;) Kann ich so absolut bestätigen: In meinem mp3 Player werkelt ein mega8 @ 8MHz, angeschlossen ist eine SD Karte, ein VS1011, ein Inkrementalgeber mit Taster und ein 2x20 VFD. Nachdem ich die Unterstützung von langen Dateinamen und dem ID3 Tag eingebaut habe, war der Speicher nahezu komplett voll (man kann die Anzahl an freien Bytes an Händen und Füßen abzählen). Song vor, zurück, lauter, leiser und Pause. Mehr brauche ich nicht und mehr gibt es auch nicht. Normale 192kbit/s mp3s spielt er übrigends bei einer nicht fragmentierten Speicherkarte selbst @ 4MHz noch problemlos ab. Da der VS10xx einen 2kByte großen Puffer hat, ist die Datenrate sowie das Dateisystem alles andere als kritisch. Solange man die Taster nicht per Warteschleife entprellt, sollte es da also keine Probleme geben, selbst wenn alles nicht perfekt optimiert ist. Als Software für das Dateisystem kann ich die hier übrigens sehr empfehlen: http://elm-chan.org/fsw/ff/00index_e.html Das ist mit Abstand das am meisten ausgereifte was es so an freier Software gibt.
Hallo, ich habe vor Zeiten mal einen Player mit dem 8515 mit 32k externem Ram gebaut, 8MHz getaktet, Decoder war ein MAS3507D. Quelle eine 2,5"HD 6GB, Filesytem das Amiga FastFileSystem. Einfach, weil es dafür ideal war und ich noch einen Amiga in Betrieb hatte. Ende 2000 habe ich mich wohl nicht mit FAT rumärgern wollen. Display 2x16 Zeichen, unten dynamische Menüanzeige, oben Titeldaten. Angezeigt wurde nur MP3-Tag (der alte), der scrollte auch zur Laufzeit, Steuerung des MAS3507 für Lautstärke, Höhen und Tiefen über I2C auch zur Laufzeit ohne Aussetzer. Geteste allerdings damals nur bis 192kBit. Wirklich kritisch war nur die Buffersteuerung zwischen HD und Ram und MAS. Der Ram diente vor allem zum Preload der Startsektoren der Titel und war Batterie gepuffert. Sonst raspelte nach dem Start des Players die Platte erstmal 1-2 Minuten rum und suchte die Titel zusammen. Die Problemstelle ist wirklich der SD-Karten-Zugriff. es ist auch relativ nutzlos, sich über die maximale Transferrate zu freuen. Kritisch ist die minimale z.B. beim Sektorwechsel, die muß der Buffer und der Decoder 100% sicher überbrücken können, sonst gibt es Aussetzer. Ich würde auch heute erstmal einen AVR auf ein Steckbrett nageln, SD-Karte und MP3-Decoder ran und die Sachen zum Spielen unter allen Umständen bringen. Dabei muß dann genug Rechenzeit für den Rest übrigbleiben. Wenn man z.B. in der Titelliste blättern will, während gespeilt wird, dann muß die im Ram parat liegen. Sonst würde ich da keine reale Chance sehen. Würde mich vermutlich auch heute zum Mega8515 + 32k/64k S-Ram bringen, mir gefällt die Kombination. ;-) Gruß aus Berlin Michael
Noch mal ne rein informative Frage: Wie lange habt ihr denn für den MP3-Player gebraucht. Also Aufbau der Schaltung, Verstehen des FAT-Zugriffs, der Ansteuerung des VS-Chips usw.? Danke
Wenn man alles auf einmal macht und vorher noch nichts auf einem der Teilgebiete davon gemacht hat, und auch wirklich alles verstehen möchte, also nicht nur aus fertigen Libs etwas zusammenbauen möchte, dann Wochen bis Monate. Ich hatte z.B. SD Karten und FAT vorher schon mehrmals verwendet, daher dafür auch fertigen Code. Für meinen mp3 Player habe ich vom Entwurf bis zur ersten abgespielten mp3 rund 1-2 Tage gebraucht. Bis die Software und das Gehäuse usw. fertig war, hat es aber Wochen gedauert, da man immer wieder kleine Fehler beheben muss, die man nur im Betrieb bemerkt. Außerdem kommen immer wieder neue Features hinzu (auslesen der LFN, des ID3 Tag usw.). Der VS ist im Vergleich zur SD Karte und dem Dateisystem aber extrem einfach. Daher würde ich ein fertiges Dateisystem verwenden, das garantiert funktioniert (wie z.B. das von elm-chan). Alternativ kann man eine kurze mp3 auch mal in den Flash packen oder über UART streamen. Zum Testen des VS reicht das.
Ich hab mir schon zig Projekte runtergeladen nur fehlt halt der große Überblick. Bspweise weiß ich nicht, wie ich den fertigen Code, etwa von elmchan in mein Projekt integrierern kann. Explizit, welche Softwareschnittstellen ich ansprechen muss. Z.B. wenn der FAT-Code einen neuen Sektor benötigt, wie ich diesen Befehl der SD-Karten-Routine übergebe. Hab vorher noch gar nichts Derartiges gemacht.
Schau dir mal die Sampleprojects von elm chan an. Da ist fertiger Code für AVRs dabei, also eigentlich alles komplett fertig. Du musst nur die Pinnummern für SPI an deinen µC anpassen. Die Routinen für die MMC Karte stecken in der mmc.c.
Da sind ja auch Schaltpläne dabei. Warum hat er denn die Leitungen zur SD-Karte mit Pullups versehen? Und was bringt der Pulldown-Widerstand für SCK?
An DO der SD Karte muss ein Pullup sein, denn nur dann kann man zwischen Tristate und Low unterscheiden. Ansonsten ist die Init der SD Karte ein Glücksspiel. Ein Pullup am CS Anschluss der SD Karte ist sinnvoll, damit diese z.B. beim Programmieren des AVRs nicht auch Daten auf die SPI Leitungen treibt. Der Pulldown an SCK ist nicht ganz so wichtig.
ok, werd ich alles mit in meine Schaltung mit aufnehmen. Aber wie sieht es denn mit dem anderen Teil meiner Frage aus. Angenommen es befindet sich eine einzige MP3-Datei auf der Karte. Welche Schritte muss ich abarbeiten, um die auslesen zu können?
1 Hardware in Gang bringen 1.1 ATMega 1.2 SD-Karte 1.3 MP3-Decoder 1.4 D/A-Wandler, Verstärker, usw 2 Software in Gang bringen 2.1 Kommunikation Atmega <-> SD Karte 2.2 Kommunikation Atmega <-> MP3-Decoder (ein MP3-Stream könnte für Debugzwecke über Seriell vom PC eingelesen werden) 2.3 FAT-Dateisystem der Karte lesen 2.4 MP3-Datei lesen 2.5 zum Decoder und dann zum Lautsprecher
Hallo Sumynona
Der Ablauf ist klar, nur häng ich halt gerade an der Stelle das
FAT-System der Karte zu lesen.
angenommen auf der Karte liegt ne Datei "Test.mp3", geh ich dann ganz
normal über fopen("Test.mp3"); ?
Welche FAT Routinen verwendest du jetzt? (Davon hängt das ganze ab, wie die Funktion genau aufgerufen wird,) aber im groben ja, so in etwa geht das. Dann kann man (je nach FAT Routine) Block oder Byteweise die Daten lesen.
fopen() gibts nur wenn du ein darunterliegendes Betriebssystem hast, das dir ein Dateihandle zur Verfügung stellt. Haste beim Atmega sehr wahrscheinlich nicht ;-) Also wird dir nix anderes übrig bleiben als mal nach FAT-Treibern für ATMega zu googeln (da gibts schon einige recht gute) oder alles im Alleingang zu programmieren.
Naja, wie gesagt, ich hab jetzt hier den FAT-Unterbau von elmchan "eingebaut". http://elm-chan.org/fsw/ff/00index_e.html Hier gibt's ja die Erläuterungen zu den Funktionen. Und da hat er ein f_open verwendet. Also Datei öffnen und dann Byte-weise den Data-Stream an den VS1001 übergeben, wenn ich das richtig verstanden habe.
Ja, genau. Allerdings ist das Byteweise übertragen sehr ineffizient wie man hier sieht: http://elm-chan.org/fsw/ff/img/rwtest.png Da der VS10xx mindestens 32 Bytes frei hat, solange DREQ aktiv ist, würde ich immer 32Byte Blöcke senden. Das dürfte deutlich effizienter sein. Aber einen Schritt nach dem anderen. Bring das ganze erstmal soweit zum Laufen, dass du dir über f_opendir und f_readdir den Verzeichnisinhalt ausgeben lassen kannst.
Bei den ElmChan-Samples http://elm-chan.org/fsw/ff/ffsample.zip gibt es für den AVR unter Main.c eine IOinit. Doch ich konnte nicht finden, wo der Herr Chan den uC deklariert, bzw. dass in der io.h der richtige uC ausgewählt wird. Auch versteh ich nicht, warum, er in der IOinit gleich mehrere Ports auf "HIGH" setzt. Könnt ihr mir da mal wieder aushelfen?
Johannes Hofmann schrieb: > Doch ich konnte nicht finden, wo der Herr Chan den uC deklariert, bzw. > dass in der io.h der richtige uC ausgewählt wird. Das macht der Compiler automatisch wenn man dem den richtigen µC mitteilt. Darum musst du dich also nicht kümmern. > Auch versteh ich nicht, warum, er in der IOinit gleich mehrere Ports auf > "HIGH" setzt. Das Beispielprogramm verwendet nicht nur die MMC/SD Karte sondern auch noch CF oder IDE. Die haben einen 16bit Datenbus.
Hallo Was mach ich denn mit der Fehlermeldung? Es wurde auch keine .hex-Datei zum Programmieren erstellt. gcc plug-in: Error: Object file not found on expected location C:\User\....\default\MP3.elf Der Code compilierte ohne Probleme.
1 | int main (void){ |
2 | |
3 | FATFS *fs; // Work area (file system object) for logical drives |
4 | FIL fsrc, fdst; // file objects |
5 | BYTE buffer[4096]; // file copy buffer |
6 | FRESULT res; // FatFs function common result code |
7 | UINT br, bw; // File R/W count |
8 | |
9 | |
10 | // Register work area for logical drives
|
11 | f_mount(0, &fs[0]); |
12 | |
13 | |
14 | // Open source file on the drive 1
|
15 | res = f_open(&fsrc, "srcfile.dat", FA_OPEN_EXISTING | FA_READ); |
16 | |
17 | |
18 | |
19 | |
20 | // Close all files
|
21 | f_close(&fsrc); |
22 | |
23 | // Unregister work area before discard it
|
24 | f_mount(0, NULL); |
25 | |
26 | |
27 | |
28 | }
|
Hab mal nen DJ MP3-Player nach dem Vorbild des berühmten CDJ100 von Pioneer in nen Mega32 reingepresst. Mit Cue-Punkt im Titel setzen usw. Hatte außerdem noch so ne lustige 8ter Tastenreihe wo man Jingles drauflegen konnte die bei Knopfdruck abgespielt wurden. Das ganze komplett in ASM geschriebene. FAT16 von SD/MMC Karte und über den gleichen Hardware-SPI wieder raus an den MP3-Decoder. Mit alphabetischem Ordnen in den Verzeichnissen, ID3-Tags, Playtime (+ und -), Display und FAT Schreibroutinen zum speichern der Jingle-Tasten-Belegung waren die 2k RAM fast bis aufs letzte Bit ausgereizt. War schon ne ganzschöne Trickserei. 320kbit hat er aber Problemlos abgespielt. (Ob er das in C programmiert auch geschafft hätte, weiß ich allerdings nicht)
Hallo Kann mir evtl. jemand sagen, welche Funktionen von chan ich weglassen kann? Denn im Moment passt der Code leider nicht mal in nen Atmega32. Mist. Ich will erstmal testen, ob eine Testdatei auf die SD-Karte geschrieben werden kann.
Keine, das geht da anders: Schau mal in der ff.h, da gibt es verschiedenste Einstellungen. Da kannst du z.B. auf nur Lesen einstellen.
Aah, hab ich überhaupt nicht gesehen. Na das nächste Mal geh ich alle Dateien aber Zeile für Zeile durch ;-) Aber wie wird der Compiler denn mit diesen Defines angewiesen, bestimmte Teile des Codes nicht in das Programmierfile mit reinzunehmen?
Dafür gibt es ja #ifdef... und #endif wenn etwas definiert(bei ifdef) ist, wird der code bis #endif Nicht übersprungen ...
Das reicht aber irgendwie noch nicht. DAs hex-File ist mit den für mich wichtigen Optionen 84kB groß. Was kann man denn da noch machen?
>DAs hex-File ist mit den für mich wichtigen Optionen 84kB groß.
Und das sind über den Daumen 28kB Rohdaten.
Was hast du alles eingestellt? Falls du LFN aktiviert hast, deaktiviere das erst mal. Das braucht aufgrund der großen Tabellen sehr viel Speicher.
Ok, LFN war schon mal gut. Aber nun ist das Problem aufgetaucht, dass Chan ja den PORT E nutzt, der ATmega aber gar keinen hat. in der Funktion mmc.c gibt es ein paar Funktionen bezgl. Power on/off/check, die ich aber gar nicht benötige. Auch die rtc.c brauche ich ja nicht. Wie ist da am besten zu verfahren?
Hast du in dem Projekt auch den Code für CF, IDE usw. drin? Alles rund um PortE usw. kannst du entfernen, da dies ja nur für CF/IDE benötigt wird. Die Power Sachen kannst du auch weg lassen, da deine SD Karte vermutlich dauerhaft mit 3,3V versorgt wird.
Ok, jo nur SD und immer mit 3,3V Was ist mit diesem RTC? In ff.c unter _USE_IOCTL stecken ja noch mehrere Aufrufe der Power-Funktionen drin. Kann ich da einfach die betreffenden Zeilen löschen, oder geht das noch komfortabler?
>Kann ich da einfach die betreffenden Zeilen löschen, oder geht das noch >komfortabler? Lass dir von den Powerfunktionen einfach einen festen Wert zurückgeben. Das ist am einfachsten.
Hallo Ich bin jetzt bei Disk_initialize(). Doch irgendwie wird das CS der karte nicht auf LOW gezogen.
1 | #define SELECT() PORTD &= ~(1<<PD4) /* MMC CS = L */ |
2 | #define DESELECT() PORTD |= (1<<PD4) /* MMC CS = H */ |
Aufruf in der Send_CMD-Funktion ist ja
1 | DESELECT(); |
2 | SELECT(); |
Da müsste ja auch mal was passieren. Hab ne LED an CS angeschlossen und die müsste ja dann mal ausgehen, wenn SELECT aktiviert ist. Ist bestimmt ein simpler Fehler, den ich nicht seh...
>Da müsste ja auch mal was passieren. Hab ne LED an CS angeschlossen und >die müsste ja dann mal ausgehen, wenn SELECT aktiviert ist. Besorg dir ein Osci ;) Kleiner Tip: Man sieht es eher das eine LED kurz aufleuchtet als das sie kurz ausgeht.
Ok auf dem SPI tut sich überhaupt nix! Hier ist die Initialisierung, die direkt zu Beginn ausgeführt wird(Das ist aus dem fertig übernommenen Code):
1 | PORTB = 0b10110101; /* Enable drivers */ |
2 | DDRB = 0b11000111; |
3 | SPCR = 0b01010000; /* Initialize SPI port (Mode 0) */ |
4 | SPSR = 0b00000001; |
Ich habe auch mal den Programmer abgeklemmt, der auch am SPI hängt, aber keine Besserung. Muss was Internes sein. Das Fusehäkchen im AVR-Studio-Programmer-Menü ist gesetzt und grau unterlegt mit nem roten Fragezeichen. Es lässt sich auch nicht entfernen. ChipSelect funktioniert.
Du musst DDRB und PORTB entsprechend anpassen, so dass MOSI, SCK und SS Ausgang sind und der Pullup an MISO an ist.
@Johannes Du hast aber ein ziemlich schlechtes Kurzzeitgedächtnis ;) Schon vergessen was ich dir hier gesagt habe? Beitrag "DummyClocks an SPI senden"
Ich dachte die SPI-Zuweisung macht die iom32.h automatisch. Na jedenfalls siehts jetzt mit DDRB = 0b10110000; und PORTB |= (1<<PB6) | (1<<PB4); nicht anders aus... Immer noch kein Wackeln auf dem SPI.
>Ich dachte die SPI-Zuweisung macht die iom32.h automatisch. iom32.h schaltet SPI automatisch aus ;) Resetzustand. >Na jedenfalls siehts jetzt mit DDRB = 0b10110000; > und PORTB |= (1<<PB6) | (1<<PB4); >nicht anders aus... >Immer noch kein Wackeln auf dem SPI. Dann ist der Fehler in Zeile 42.
>Immer noch kein Wackeln auf dem SPI.
Woher weisst du das SPI nicht geht?
Mit dem Osci gemessen?
Aber der SPI ist doch nun über diese Zeile SPCR = 0b01010000; so initialisiert, dass es funktionieren müsste.
>Aber der SPI ist doch nun über diese Zeile SPCR = 0b01010000; >so initialisiert, dass es funktionieren müsste. Das ist alles korrekt so, aber woher weisst du das SPI jetzt nicht geht?
weil ich mein Multimeter drangehängt habe und sich auf keiner Leitung das geringste regt. Ich weiß auch, dass meine SD-Karte funktioniert, da ich sie mit einer Software-SPI-Routine schon mal initialisiert hatte. Aber ich probier die SPI-Frequenz noch mal runter zu setzen.
>weil ich mein Multimeter drangehängt habe und sich auf keiner Leitung >das geringste regt. Bei SPI Vollgas siehst du auf deinem Multimeter gar nichts!
>Aber ich probier die SPI-Frequenz noch mal runter zu setzen.
Gute Idee. Versuch das hier:
SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR1) | (1<<SPR0);
SPSR = 0;
Wie sieht eigentlich deine Schaltung aus?
So im Gegensatz zu voher ist jetzt der SPi Teiler 128 anstatt nur 2. Der uC läuft jetzt auch mit 1 MHz Da seh ich nur an der SCK-Leitung bischen was wackeln. Das krebst so bei 3mV rum. Genau die beiden Zeilen hab ich mir grade von nem Ulrich Radig-Projekt rüberkopiert.
>So im Gegensatz zu voher ist jetzt der SPi Teiler 128 anstatt nur 2. Der >uC läuft jetzt auch mit 1 MHz >Da seh ich nur an der SCK-Leitung bischen was wackeln. Das krebst so bei >3mV rum. SCK läuft dann immer noch mit ca. 8kHz. Da siehst du nix mit dem Multimeter. Wo genau hängt das Programm jetzt? Schaltplan? Schaltplan? Schaltplan? Schaltplan?
Angehängte Dateien:
-
Board.jpg
1,8 MB
Hier ist er endlich ;-) So die Orange Leitung hängt ist MOSI/DI, Grün ist SCK und Blau MISO/D0 Und dann noch paar Dioden, die mir zur Fehlersuche dienen. Abblockkondensatoren an den VCC-Pins des uC hab ich auch dran. Ich hatte wie gesagt die Karte schon mal initialisiert, aber da hatte ich eben Software SPI und da war die Schaltung auch auf ner Lochrasterplatine verlötet. Die Leitungslängen zur SD-Karte waren aber ähnlich lang.
>Hier ist er endlich ;-)
Das ist kein Schaltplan, das ist ein Vogelnest.
Läuft der uC mit 3,3V? Ich sehe keine Pegelwandler.
Jo 3,3V. Ich habe aber auf irgendeiner Homepage schon mal nen ähnlich wüsten Aufbau gesehen und dort funktionierte es auch.
Ich werde mir heute Abend mal ne Schleife bauen, die dann ständig den SPI beansprucht. Und wenn ich da das Multimeter dranstecke, stellt sich entweder ein Mittelwert irgendwo zw. 3,3 und 0V ein oder nicht. Bin sehr gespannt...
So, SPI funktioniert. SCK und MOSI haben nen Spannungsmittelwert von 1,.. Volt, wenn ich ständig sende. Nur die Initialisierung klappt immer noch nicht. habe auch die Kabel vom uC zur Karte noch so kurz wie möglich gemacht. Habe gerade den Pullup an D0 bzw. MISO der Karte nicht dran. Ist das kritisch?
Fällt euch noch was ein, wo der Fehler stecken könnte? Die Software ist ja bereits erfolgreich vom Ersteller gestestet worden, zwar an einem anderen Atmega als meinem, aber das wird's wohl nicht sein. Ich halte mal fest: SPI funktioniert und ist korrekt angeschlossen Ports auch korrekt Spannungsversorgung ist auch i.O. SD-Karte ist auch i.O. der uC funktioniert auch An der Schaltung ist bis auf die etwas längeren Kabelverbindungen auch nix verkehrt. Wenn über SPI ein Byte geschickt wird, dann wird doch bitweise auch das MISO-Register des Slave durchgeschoben oder? Also müsste man auf der Leitung ja auch ein Wackeln sehen, wenn ständig Daten über den SPI geschickt werden, gell?
Ich hab mal ne andere Frage: Wo hast du die Verbinderkabel zum senkrechten rein stecken ins Steckbrett her die "isolierten Drahtbrücken" habe ich auch aber das ist immer etwas friemelig mit dem raus suchen der passenden Länge.
Hierher: http://www.sureelectronics.net/ Die haben auch nen Shop bei Ebay. Alles supergünstig. Trotz Versand aus Fernost.
So, ich hab den Fehler gefunden. Hatte mir ne Schleife gebastelt, die die ganze Zeit CMD0 an die Karte gesendet hat. Bei Erfolg-->LED an. Gestartet. Nix passiert. Aber als ich die SD-Karte rauszog!!, da ging die LED auf einmal an. Es war also ein Kontaktproblem, aaaargh.
Hallo Ich hab hier mal mein Projekt angefügt. Es wäre toll, wenn jemand von euch das mal bei sich reinladen könnte und mir sagen könnte, ob der Code so funktioniert. Ich zweifle nämlich langsam an meinen Fähigkeiten, weil ich diese simple Grütze nicht zum Laufen kriege. Ihr müsst praktisch nur den Ausgangspin für das Chipselect in der mmc.c ändern. Vielen Dank
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.