Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03586.jsonl.gz/323

Posts tagged SPI
Am 3.4.2011 habe ich folgendes Projektkonzept präsentiert:
Vorgaben
- Spezialangefertigter Audioplayer mit 4 Ausgängen
- 16-Bit Audio-Dateien abspielbar ab SD-Karte
- Kleine Abmessungen
- Sparsam im Stromverbrauch
Auftraggeber
- Zürcher Hochschule der Künste, Vertiefungsrichtung Mediale Künste, Joris Stemmle
- c1Audio.com
- Iris Rennert
Mentor
G. Brügger, HSZ-T
Block-Diagramm Hardware
Block-Diagramm Software
Design Entscheide
Folgende Entscheide haben wir gefällt:
- CPU: TMS-320
- DAC: extern
- Interface: SPI
- MP3/Vorbis-Decoder bei verbleibender Zeit
Beim Versuch, eine DSP/BIOS freie Anwendung unter Verwendung des Beispielcodes zu schreiben, kommt es zu unerwarteten Problemen. Durch zeitraubende Debug-Arbeit finde ich ein Verhalten der SPI-Sende-/Empfangsregister heraus, das dazu führt, dass Bytes verloren gehen, wenn man die Register nicht richtig ausliest.
Dies machte sich im Beispielcode nicht bemerkbar, da dieser lediglich eine Sequenz von Bytes auf die Karte schreibt, wieder liest und dann vergleicht. Weil der Fehler sowohl beim Schreiben wie auch beim Lesen auftritt, wird der Beispielcode-Test fälschlicherweise als “korrekt” erkannt.
Als es konkret darum ging, gezielt Daten von der SD-Karte zu lesen, machte sich dieser Fehler bemerkbar, weil plötzlich Bytes nicht ausgelesen wurden, die jedoch in einem Dump der SD-Karte im Linux-Betriebssystem eindeutig vorhanden waren.
Ich habe beim Lieferanten des Beispielcodes folgendes Ticket eröffnet, das ich dann selbst beantwortet habe:
The answer:
changing:
*data = MMCSD_MMCDRR2;
*data++ = MMCSD_MMCDRR1;
to:
*data++ = MMCSD_MMCDRR1;
*data++ = MMCSD_MMCDRR1;
Now I have the expextet bytes in the output buffer… :-)
The question was:
Hello out there,
I try to use the sd-card example (usbstk5515_v1/tests/sd) to read such a card with an ezdsp5515 board. The issue I experience is, that only every 2nd word got read out of the card. I can confirm this with a hexdump from the card content.
eg.
On the card i have the following sequence according to a hexdump in Linux:
66 77 88 99 AA BB CC DD EE FF
When i read it out with “MMCSD_singleBlkRead”, i get in the output buffer “data”:
66 77 AA BB EE FF
The following code sequence in “MMCSD_readNWords” seemed me a little strange anyway:
*data = MMCSD_MMCDRR2;
*data++ = MMCSD_MMCDRR1;
But when i changed it to:
*data++ = MMCSD_MMCDRR2;
*data++ = MMCSD_MMCDRR1;
I got in the buffer “data”:
66 77 66 77 AA BB AA BB EE FF EE FF
That tells me, that somehow one of the 2 receive register is not working properly, probably due to a configuration.
I am not sure, if you can help, but i hope that out there is some expert who can give me a hint.
Thanks in advance
Ich bin bereits im Besitz einer unter Arduino laufenden Programmbibliothek (SDFATLIB) für den Zugriff auf ein FAT32-Dateisystem auf einer SD-Karte über SPI. Diese besteht im Grunde aus zwei Komponenten:
- Zugriff auf SD-Karte via SPI-Schnittstelle
- Zugriff auf ein FAT-Dateisystem
Davon gibt es eine vereinfachte Version (FAT16LIB). Diese werde ich zuerst portieren, um die Aufgabe etwas zu vereinfachen.
Auf der Seite des TMS320 finde ich einen Beispielcode für den Zugriff auf ein über SPI angeschlossenes ROM (SPIROM).
Es gibt zwei Ansätze, diese auf dem TMS320 zum laufen zu bringen:
- Die SDFATLIB Bibliothek als Gesamtes mit möglichst wenig Codeänderungen für den TMS320 kompilieren.
- Aufbauend auf den Code SPIROM die Bibliothek SDIFAT nachbauen
SDFATLIB als Gesamtes portieren
Um die Bibliothek für den TMS320 zu importieren, müssen folgende Schritte unternommen werden:
- Besorgen und hinzufügen der AVR und Arduino include Dateien. Diese sind in der Arduino IDE beinhaltet.
- Definieren des Types uint8_t in diversen Header-Dateien.
Die darauf folgende Fehlermeldung, es würden keine Arrays von Funktionen unterstützt, konnte ich nicht mehr beheben. Daher habe ich diesen Ansatz vorerst beiseite gelegt und verfolge nun den zweiten Ansatz.
Schlussendlich verwende ich nun die im Elektor-Beispiel bereit implementierte Portierung der FATLIB, die über die Treiber von DSP/BIOS auf die SD-Karte zugreift.
Gemäss funktionierendem Schaltplan von Sparkfun verdrahten wir die eZdsp-Karte mit der SD-Karte. Ein Spannungskonverter von 5V auf 3.3V ist nicht nötig, da eZdsp bereits auf 3.3V läuft. Die Verdrahtung sieht wie folgt aus:
|Host||MicroSDCard||Pin||SDCard||Pin||eZdsp||edgecon|
|–||NC||1|
|CS||CS||2||CS||1||SPI0_CS1||3|
|MOSI||DI||3||DI||2||SPI0_DX||7|
|3.3V||VCC||4||VDD||4||VCC_3.3V||39|
|SCK||SCK||5||SCK||5||SPI0_CLK||5|
|GND||GND||6||VDD||3;6||GND||1;11|
|MISO||DO||7||DO||7||SPI0_RX||9|
|–||RSV||8|
Referenzen
Die Kommunikation zwischen SD-Karte und DSP funktioniert über die SPI-Schnittstelle. Bevor wir die SDFATLIB nachbauen können, versuchen wir, auf einfachste Weise die kommunikation mit der SD-Karte zu testen. Dies beinhaltet folgende Schritte:
- SD-Karte im SPI-Modus initialisieren
- Einen Befehl an die Karte schicken
- Die Antwort der Karte auslesen und überprüfen
Wir orientieren uns dabei an dem Code für die fat16lib (reduzierte SDFATLIB) und SPIROM:
Weiter stehen uns folgende Dokumente mit Spezifikationen zur Verfügung: