Posts tagged SD-Karte

Verbesserungsvorschläge

0

Mögliche Verbesserungen wären noch:

- Schreiben der kompletten Software, ohne DSP/BIOS und Treiber vom Hersteller, am besten in Assembler

- Bessere Reaktion auf Fehler, z.B. bei ungültigen Dateien und SD-Karten Leserfehlern

- Auslesen von Parametern wie Kanalanzahl, Samplerate, Bitbreite aus den Dateiheadern

- Implementieren und Erkennen von verschiedenen Dateiformaten, ev. Portierung einer bestehenden Bibliothek für Audio-Dateiformate.

m4ch-block-soft2

Softwareimplementierung

0

Folgendes Diagramm zeigt die Struktur der implementierten Software. Zugrunde liegt das Beispiel MP3-Player-Beispiel von Lars Lotzenburger, baut also auf DSP/BIOS von TI und der FAT lib von ChaN.

Das Programm erstellt einen DSP/BIOS Prozess. Dieser macht eine Tastaturabfrage, liest die benötigten Daten von der SD-Karte, verarbeitet diese und giebt das Resultat an einen Ausgabebuffer weiter. Die Zugriffe auf die Hardware und der Ausgabebuffer laufen ebenfalls über das DSP/BIOS.

Ich habe das MP3-Player Beispiel so modifiziert, dass es anstelle von MP3 WAV/AIFF-Dateien liest, dafür aber mehrere Dateien gleichzeitig abspielen kann. Bis zu 6 Stereo-Spuren sind möglich, dann wird die Wiedergabe hörbar langsamer. Ein Abspielen von mehreren MP3-Dateien bringt den Prozessor bereits bei zwei Dateien an seine Leistungsgrenze.

Zusätzlich habe ich noch eine Tastatursteuerung programmiert.

m4ch-block-hardware

Präsentation 4 Kanal SD-Karten Audioplayer

0

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
20110922-154417.jpg

SampleMachine

0

Diese Anwendung habe ich für eine Ausstellung im Auftrag von Iris Rennert erstellt. Es handelt sich dabei um einen “Teppich” mit Kontaktschaltern/Sensoren, die Audio-Samples ab einer SD-Karte mehrstimmig (polyphon) abspielen.

20110922-154510.jpg

Die Anlage besteht aus einer mehrschichtigen Kunststoffmatte, einer Steuerung und einem Verstärker- / Lautsprechersystem.

20110922-154441.jpg

Mit einem Laptop werden die letzten Programmupdates über USB auf die Steuerung übertragen.

20110922-154603.jpg

Die Steuerung besteht aus einem TMS320C5515 eZdsp USB Stick und dem Prototypen eines I/O Boards.

20110922-154637.jpg

Das I/O-Board ist bestückt mit 3 8-Kanal-CMOS-Multiplexern (4051) und hat 22 Eingänge für Sensoren.

20110922-154714.jpg

Eine Vorgängerversion des I/O-Boards arbeitete mit 4 Analogeingängen und “Analog-DACs” aus Widerstandreihen. Diese Idee habe ich nicht weiter verfolgt, weil die gemessenen Spannungwerte zu ungenau waren um die einzelnen Tastendrucke auseinanderzuhalten.

Verhalten der SPI-Sende-/Empfangsregister

0

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

USBSTK-5515 Inbetriebnahme, SD-Example

0

Folgende Punkte bewegten mich dazu, entgegen vorherigem Entscheid, die SD-Karte doch in Betrieb zu nehmen:

-  Der Onboard-Chip des eZdsp-Sticks hat mit 512kBit eine zu geringe Kapazität und das Development von weiterer Hardware ist vorerst nicht vorgesehen.

- Weitere Erfahrungen mit einer Technologie – auch wenn es sich nicht um die bevorzugte Technologie handelt – erweitern das Wissensspektrum, was zu einem der Hauptziele dieser Arbeit zählt

- Die Implementierung eines USB-Memorysticks erweist sich als aufwändiger als angenommen, da kein entsprechendes Beispiel vorhanden ist (, wie zunächst angenommen wurde).

Bei der Inbetriebnahme des neuen eZdsp USBStick-5515 konnte ich feststellen, dass eine neuere Version der IDE CCS (bisher 4.0, neu 4.1) mitgeliefert wurde. Da ich nicht herausfand, wie ich in der alten CSS Version eine Target Configuration für das neue Board erstellen kann, habe ich kurzerhand die neue Version von CSS in einem Separaten Ordner (…/Texas Instruments2/) installiert.

Erfreulich ist, dass nun die Treiber auch unter Windows 7 (64-Bit) funktionieren. Ich habe auf Anraten der Installationsprozedur die Software nicht unter c:\Programm Files (x86) sondern in ein eigens dafür angelegtes Verzeichnis c:\Texas Instruments installiert.

Das Kompilieren des SD-Beispiels gelang zunächst nicht, da sowohl die spezifischen Include-Dateien für das Board, sowie die Datei usbstk5515bsl.lib nicht gefunden wurden.

Die Include/Lib Dateien waren schnell ausfindig gemacht und unter den Projekt/Properties/C++ Build/C5500 Compiler/Include Options bzw. Linker Options der entsprechende Pfad (Texas Instruments2/cssv4/emulation/boards/usbstk5515_v1/include bzw. lib) hinzugefügt.

Etwas anders als in der Anleitung angegeben funktioniert das Übertragen des kompilierten Codes auf das Board. Vergeblich habe ich im Kontext-Menu den Befehl Load Program gesucht. Gefunden habe ich diesen dann im Menu Target, von wo aus ich über die Schaltfläche Workspace die .out-Datei anwählen und laden konnte.

Der erste Test ergab folgenden Output:

EXBUSSEL = 6100
01  Testing SD card...
SD Card Initialization failed
 FAIL... error code 1... quitting

Das war korrekt, denn keine SD-Karte war eingelegt. Nach dem Einlegen einer SD-Karte erhielt ich dann nicht die gewünschte Erfolgsmeldung. D.H. das Programm bleibt beim Initialisieren der SD-Karte hängen.

Es fällt auch auf, dass der eZdsp-Stick jedesmal wieder das geladene Testprogramm verliert. Ich habe herausgefunden, dass ein binäres Programm “programmer.out” vorhanden ist, das es ermöglicht, eine Software fix auf das SPI-EEPROM zu programmieren.

Als nächstes will ich eine WAV-Datei von einem FAT-System lesen. Siehe dazu: de.wikipedia.org/wiki/File_Allocation_Table

Testboard Evaluation

0

Bei der Evaluation des Testhardware standen folgende Kandidaten in der engeren Auswahl. Es ergab sich eine Rangliste:

  1. eZDSP TMS320C5515: erste Wahl, verfügt über vielfältige Möglichkeiten, insbesondere programmierbare USB-Schnittstelle und Micro-SD Slot.
  2. eZDSP TMS320VC5505: Geeignet, aber ohne USB und SD-Karten Unterstützung.
  3. Beagleboard: wenig Informationen vorhanden, Linux-basiert daher tendenzieller Universalrechner mit hohem Software-Overhead
  4. Arduino:  viel zu langsam

Design Frage Speicher (Board/CPU 5505/5515)

0

Wie sich heraus stellt, ist die ursprünglich intuitiv gewählte Speicher-Technologie der SD-Karte nicht frei, d.h. es steht eine Organisation dahinter, die eine Lizenzgebühr für die vollständige Dokumentation und für den Einsatz in Produkten verlangt. Ausserdem wird eine proprietäre Steckverbindung verwendet, die teuer und nicht so einfach erhältlich ist.

Als sinnvolle Alternative dazu bietet sich an, einen Onboard-Flash-Memory Chip zu verwenden. Ein solcher ist auf dem eZdsp-Board vorhanden. Dazu müsste ich eine USB-Anbindung schreiben, so dass unser Board sich als USB-Memory-Stick an einem Host anmelden kann. Diese Technologie zu ergründen und zu beherrschen ist sehr spannend, denn USB ist ein freier und weit verbreiteter Standard.

Aufgrund dieser Erkenntnis verzichte ich auf eine weitere Entwicklung mit der SD-Karte.

In folgendem Archiv findet sich ein USB-Stick Codebeispiel, das allerdings für ein C5515-Board geschrieben ist. Es ist jedoch ein Einstiegspunkt. Ich werde nun versuchen, dieses Beispiel auf unser VC5505-Board zu portieren.

support.spectrumdigital.com/boards/usbstk5515/reva/

Ausserdem habe ich schon mal die USB2.0-Spezifikationen besorgt:

www.usb.org/developers/docs/

Erkenntnisse:

  • USB kann auf dem VC5505-Board nicht getestet werden, da die benötigten Anschlüsse an der CPU gegen Masse verdrahtet sind (Schema Seite 3, Pins G13,J12,H14,G8…). Ausserdem würde ein zusätzliches 12-MHz-Quarz benötigt.
  • Bis auf eine höhere maximale Taktfrequenz (C5515: 120 MHz, VC5505: 100 MHz) sind die beiden CPUs identisch.
  • Die CPUs verfügen über einen SD-Card Controller, der auch im SD-Modus funktioniert
  • VC5505 scheit ein Auslaufmodell zu sein und wird vom Hersteller nicht für Neuentwicklungen empfohlen. Nachfolgermodell wäre C5505, C5515 ist ähnlich

Weiteres Vorgehen: Besorgen des C5515-Testboards: ch.farnell.com/spectrum-digital/c5515-ezdsp-usb-stick/entwicklungsboard-ezdsp-usb-stick/dp/1831928

 

Portierung der SD-Card/FAT Software auf TMS320

0

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.

20111028-094304.jpg

SD-Karte an eZdsp-Board anschliessen

0

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

20111028-094304.jpg

Referenzen

- www.sparkfun.com/datasheets/DevTools/Arduino/microSD_Shield-v13%20Schematic.pdf

- elasticsheep.com/wp-content/uploads/2010/01/sd-card-pinout.png

- www.sdcard.org/developers/howto/

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:

  1. SD-Karte im SPI-Modus initialisieren
  2. Einen Befehl an die Karte schicken
  3. Die Antwort der Karte auslesen und überprüfen

Wir orientieren uns dabei an dem Code für die fat16lib (reduzierte SDFATLIB) und SPIROM:

fat16lib.googlecode.com/files/fat16lib20101009.zip

Weiter stehen uns folgende Dokumente mit Spezifikationen zur Verfügung:

www.sdcard.org/developers/tech/sdcard/pls/Simplified_Physical_Layer_Spec.pdf

Go to Top