Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03354.jsonl.gz/1254

Es gibt auf dem Markt eine enorme Auswahl an sehr kleinen Musikwiedergabegeräten. Alle sind jedoch auf Stereo, also zweikanalige Tonausgabe ausgelegt.
Für eine Spezialanfertigung – ein Helm mit 4 Lautsprechern – wurde ich angefragt, einen möglichst kleines, 4-kanaliges Musikwiedergabegerät zu entwerfen. Der Vorschlag vom Auftraggeber war, zwei bestehende Geräte zu kaufen und diese so zu modifizieren, dass sie über die “Play-Buttons” elektromechanisch synchronisiert werden können.
Mein Vorschlag war, ein eigenes Gerät zu bauen. Da ich jedoch noch nichts Ähnliches in der Hand hatte, einigte ich mich mit dem Auftraggeber darauf, einen Versuch zu starten und je nach Resultat die eine oder andere Variante zu realisieren.
Erste Versuche mit einem ATmega168/16MHz zeigten (Arduino Board), dass eine schnellere CPU benötigt wird, denn die 16MHz waren schnell ausgeschöpft, alleine mit dem Hin- und Herladen von Daten. Auf Empfehlung meines Mentors Georg Brügger arbeitete ich mich in die TMS320-Signalprozessortechnologie ein. Ich verwendete eine vorgefertigte Hardware. Hier wurde schnell klar, dass die Herstellung einer eigenen (sechs-schichtigen) Leiterplatte sehr anspruchsvoll ist und im gegebenen Zeitrahmen nicht möglich ist. Daher entschieden wir uns dafür, für den Auftrag die doch etwas weniger elegante Variante mit der elektromechanischen Synchronisation zu realisieren. Ich wollte aber für mich selbst und für zukünftige Anfragen die angefangene Arbeit doch weiterentwickeln.
Es dauerte nicht lange, da bekam ich die Anfrage, im Rahmen der Berner Musikfestwochen mehrere interaktive Klanginstallationen zu realisieren. Diese habe ich termingerecht mit der TMS320-Technologie realisiert und im Folgenden dokumentiert. Ich kann dazu noch sagen, dass diese Installationen zwar nicht über vier, sondern nur über zwei Audiokanäle verfügen, jedoch Funktionalitäten aufweisen, die mit einem regulär käuflichen Gerät beiweitem nicht möglich sind und wo normalerweise ein völlig überdimensionierter Universalcomputer zum Einsatz kommt. Es war zudem eine Anforderung der Auftraggeberin, die Installationen nicht mit einem handelsüblichen Universalcomputer zu realisieren, da dieser zu teuer und zu gross sei.
Ich habe während der ganzen Arbeit sämtliche Notizen in einem “Blog” unter mobile4ch.x21.ch geführt. Das hat den Vorteil, dass ich nicht abhängig von einer Datei auf einer Festplatte bin und meine Notizen immer dabei habe, sofern ein Webbrowser vorhanden ist, z.B. auch auf einem Smartphone. Die Daten habe ich noch etwas überarbeitet, mit CSS3 einige druckspezifische Modifikationen gemacht. Sie, werter Leser, haben das Resultat nun vor sich. Es verfügt teilweise über notizartigen Charakter. Es macht für mich jedoch keinen Sinn, alle Details zu formulieren. Sollten Sie jedoch Fragen dazu haben, können sie mich gerne kontaktieren unter <email-pii>.
Zu sehen ist hier die erwähnte Arbeit der Auftraggeber Joris Stemmle (Studierender Medienkunst) und Damian Fopp (Studierender Industrial Design)
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.
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.
Ich habe die Fähigkeit erlangt, spezialangefertigte Audiofileplayer zu programmieren und Hardwareerweiterungen herzustellen.
Ein Ziel wurde nicht erreicht: Die Herstellung einer Hardware zur vierkanaligen Tonwiedergabe. Momentan ist nur eine zweikanalige Wiedergabe möglich über eine eingekaufte Hardware.
Es sind noch viele Verbesserungen möglich, doch das würde den Zeitrahmen der Semesterarbeit sprengen.
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
Bei den ersten Tests hatte das Ausgangssignal eine hörbare, sehr sonderbar klingende Verzerrung. Eine Ausgabe der von Little auf Big-Endian konvertierten Samplewerte auf dem Terminal und anschliessende Visualisierung der Daten zeigte folgendes: Immer wenn das 8. Bit gesetzt ist, sind alle höherwertigen Bits auch gesetzt.
Besonders deutlich wurde dies sichtbar anhand einer Datei einer sehr tieffrequenten Sägezahnwelle.
Es stellte sich heraus, dass bei der arithmetischen Rechtsschiebeoperation das höchstwertige bzw. 8. Bit immer kopiert wurde. Dies führte zu folgender Codeänderung:
tmp = inBuffer[idx2][idx*2] << 8; tmp |= (inBuffer[idx2][idx*2] >> 8) & 0x00FF;
Durch die Maskierung mit dem Wert 0x00FF werden die fälschlicherweise mitkopierten Bits gelöscht.
Weitere Recherchen haben ergeben, dass es sich bei der Operation um einen arithmetischen, und nicht wie gewünscht um einen logischen Shift handelt. Der arithmetische Shift kommt in der Hochsprache C automatisch dann zum Zuge, wenn er auf mit Vorzeichen behaftete Variablen angewendet wird.
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.
Die Anlage besteht aus einer mehrschichtigen Kunststoffmatte, einer Steuerung und einem Verstärker- / Lautsprechersystem.
Mit einem Laptop werden die letzten Programmupdates über USB auf die Steuerung übertragen.
Die Steuerung besteht aus einem TMS320C5515 eZdsp USB Stick und dem Prototypen eines I/O Boards.
Das I/O-Board ist bestückt mit 3 8-Kanal-CMOS-Multiplexern (4051) und hat 22 Eingänge für Sensoren.
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.
Folgende Anwendung wurde für eine Ausstellung im Auftrag von Iris Rennert erstellt.
Sie besteht aus einer Skulptur aus Kunststoffsäcken, die über eine elektrische Ventilation aufgeblasen werden können. Es sind Lautsprecher integriert, die zur Wiedergabe von Audiodateien dienen.
Gesteuert wird das Ganze von einem eZdsp Board und einem Halbleiterrelais (Sharp S220T01) für den 230V Gebläsemotor. Die Steuerung ermöglicht ein zum Luftgebläse synchrones Abspielen von Audiodateien.
Im Rahmen der Fehlersuche am Tastaturmultiplexer habe ich Messungen mit dem Oszillografen gemacht.
Auf diesem Bild sind die Signale einer Adressleitung und des Multiplexer-Ausgangs zu sehen. Wir erkennen, dass die Ausgangssignale eine längere Zeit brauchen, um auf 0V zurückzukehren, als die Adresssignale.
Auf diesem Bild sind die Signale von zwei Adressleitungen in einer höheren Auflösung abgebildet. Wir erkennen das Verhalten eines digitalen Zählers.
Aus dem vorhergehenden Signal können wir die Frequenz der Zählers ermitteln. Ein Zyklus misst 3 Einheiten, was 0.6 ms entspricht. Demnach ist die Frequenz f=1/0.6ms=1.6kHz.
Bei einer tieferen Auflösung erkennen wir, dass die Adressierung doch nicht ganz einem digitalen Zähler entspricht. Genauer gesagt habe ich zwei 8-Kanal Multiplexer an einen dritten angehängt. Das ergibt insgesamt 22 Eingänge, wobei die Adressierung nicht mehr linear abläuft. Vgl. dazu den Code.
Bei der Inbetriebnahme des Tastaturdecoders (TDC) stellt sich heraus, dass dieser sehr empfindlich ist auf äussere elektromagnetische Störungen, z.B. einen eingeschalteten Lötkolben. Diese Empfindlichkeit wird enorm verstärkt, wenn die Leiterplatte auf einem ungeeignetem Material aufliegt.
Das äussert sich darin, dass die Tasten als gedrückt erscheinen, bzw. der GPIO/Input des TMS320 als “High” erkannt wird, obwohl die Taste nicht gedrückt ist. Das kommt sogar vor, wenn man den Eingang auf dem TDC-Board direkt auf Masse schliesst. Ich vermute, dass Potentialschwankungen auf der Masse des TDC-Boardes vorhanden sind.
Diverse Versuche u.a. mit RC-Filtern am Input und Verlegen weiterer Masse-Leitungen brachten nicht den gewünschten Erfolg.
Etwas Stabilität brachte es, die Leiterplatte auf eine Sichtmappe aus Plastik zu legen.
Es stellte sich schlussendlich heraus, dass die Lötaugen auf der Leiterplatte (PCB) zu fein waren und durch die geringe mechanische Belastung beim Einbau ins Gehäuse abgerissen sind. Auf den unteren Bildern ist zu sehen, wie ich die Übergänge zu der Steckerleiste notbehelfsmässig repariert haben. Für einen Prototypen ist dieses Verfahren akzeptabel, doch für einen produktiven Einsatz muss die PCB verbessert und neu hergestellt werden.
Im Folgenden sind Dateiheaders in Hex zu sehen, wie sie von einem selbstgeschriebenen Testprogramm ausgegeben werden über das jtag basierte CCS-Debug-System mit dem Befehl printf.
Ausgegeben werden Dateien mit Rechteck-/Sägezahn-Wellen, die mit einem freien Audio-Editor (Audacity) erstellt wurden. Diese charakteristischen Wellenformdateien eignen sich gut zu Debug-Zwecken, da darin Spitzenwerte vorkommen.
Stereo Square Wave 4400Hz
W A V E f m t cksize: 1000 0 wFormatTag: 100 nCh: 200 wSamPS: 44ac 0 wBPS: 10b1 200 wBlockAlign: 400 wbPSam: 1000 d a t a chunksize: a0ea 1a00 fe7f ff7f ff7f ff7f ff7f fe7f ff7f fd7f ff7f ff7f ff7f ff7f 80 180 80 180 80 180 80 80 80 180 ff7f ff7f ff7f fd7f ff7f fe7f ff7f ff7f ff7f ff7f 80 80 80 180 80 180 80 280 80 80 ff7f fd7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f 80 180 80 80 180 80 180 80 80 180 ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f 180 80 80 180 80 580 80 480 80 180 ff7f ff7f ff7f ff7f ff7f ff7f ff7f fe7f ff7f fe7f 180 80 80 380 80 380 80 380 80 180 ff7f ff7f ff7f fe7f ff7f ff7f ff7f ff7f ff7f ff7f 80 80 80 80 80 180 80 280 80 280 ff7f fe7f ff7f fc7f ff7f fd7f ff7f fe7f ff7f fe7f 280 80 180 80 80 80 280 80 180 80 ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f ff7f 180 80 280 80 180 80 80 280 80 280 ff7f ff7f ff7f ff7f fe7f ff7f fe7f ff7f ff7f ff7f 80 180 80 180 80 80 180 80 80 280 fd7f ff7f fe7f ff7f fe7f ff7f ff7f ff7f ff7f fe7f 180 80 280 80 480 80 R I F F 3303676416
Stereo Saw Wave 4400Hz
W A V E f m t cksize: 1000 0 wFormatTag: 100 nCh: 200 wSamPS: 44ac 0 wBPS: 10b1 200 wBlockAlign: 400 wbPSam: 1000 d a t a chunksize: a0ea 1a00 100 feff 8d19 8919 1733 1433 a14c 9f4c 2d66 2966 b87f b27f 4499 3e99 cdb2 cab2 57cc 54cc e2e5 e0e5 6cff 6bff f718 f318 8532 7e32 d4c c4c 9465 9965 207f 227f aa98 ae98 34b2 3ab2 becb c3cb 4ce5 4ce5 d7fe d7fe 5f18 6518 ea31 ef31 734b 7b4b fd64 765 887e 907e 1498 1a98 a0b1 a3b1 2dcb 2ccb b8e4 b7e4 42fe 44fe ca17 d117 5231 5d31 df4a e44a 6e64 6a64 fb7d f67d 8497 8297 db1 eb1 97ca 9bca 1fe4 26e4 acfd adfd 3a17 3717 c330 c530 4b4a 504a d663 db63 627d 647d ee96 ec96 7cb0 76b0 6ca 1ca 90e3 8ee3 18fd 1afd a316 a416 2e30 2f30 b949 b949 4463 4463 cf7c cd7c 5d96 5596 e8af e2af 6fc9 70c9 f9e2 f9e2 85fc 85fc e16 1016 992f 9b2f 2349 2649 ae62 b162 387c 3d7c c195 c795 50af 4eaf dcc8 dac8 63e2 68e2 eefb f0fb 7b15 7a15 52f 62f 8f48 9148 1962 1d62 a37b a77b 2f95 3295 b9ae bdae 43c8 47c8 d0e1 d2e1 59fb 5dfb e414 e714 712e 6f2e fe47 f847 8a61 8361 127b 117b 9b94 9d94 24ae 29ae afc7 b3c7 3be1 3ae1 c9fa c5fa 5214 5214 da2d de2d 6547 6847 f160 f260 7c7a 7c7a 894 594 94ad 90ad 1dc7 1dc7 R I F F 3303676416
Die Idee, libsndfile (www.mega-nerd.com/libsndfile/, eine bestehende Bibliothek für das Lesen von Audio-Dateiformaten) auf den TMS320 zu portieren, verwarf ich. Eine Portierung würde den Zeitrahmen sprengen.
Die Bibliothek ist zu umfangreich und abhängig von anderen Bibliotheken, die ebenfalls portiert werden müssten.
Compiler output:
Too many unsatisfiable dependencies for the moment, eg. could not open source file "byteswap.h" MP3DecWithHI/libsndfile sfendian.h line 44 1314180429309 1408 could not open source file "sys/time.h" MP3DecWithHI/libsndfile common.c line 26 1314180429286 1374 * identifier "int64_t" is undefined MP3DecWithHI/libsndfile sndfile.h line 318 1314180429308 1406
TMS320C5515/14/05/04/VC05/VC04 DSP
Multimedia Card (MMC)/Secure Digital (SD)
Card Controller
Reference Guide
TMS320C674x/OMAP-L1x Processor
Multimedia Card (MMC)/
Secure Digital (SD) Card Controller
User’s Guide
SD Specifications
Part 1
Physical Layer
Simplified Specification
Version 2.00
TMS320 DSP Algorithm Standard
Rules and Guidelines
User’s Guide
FAT
WAV File Spec
AIC3204 (Audio Codec Specs)
Ein weiteres, sehr spannendes, (GNU/GPL) freies MP3-Player Projekt für den TMS320C55x liefert auch den Quellcode für den MP3-Decoder, sowie eine Hardwareanleitung mit PCB-Layout für die CPU TMS320 VC5507.
Das Schöne daran ist, dass der VC5507 über ein LQPF Gehäuse mit 114 Pins verfügt, was die Herstellung wesentlich vereinfacht im Gegensatz zum C5515, der sich in einem NFBGA/196-Pin (ball grid array) Gehäuse befindet. Auch sind die Anschaffungskosten der CPU (ca. CHF 20, im Gegensatz dazu C5515: ca. CHF 40) und Herstellungskosten der PCB (weniger Schichten) geringer.
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
Samtec, der Hersteller des PCB-Steckers, der zu der eZdsp-Hardware passt, hat ein Skript zum Design des SMD/PCB-Steckers als Download zur Verfügung gestellt. Das Skript kann im Programm Eagle dazu verwendet werden, um Layoutvorlagen zu erstellen. Ich habe dieses Skript auf die passende Anzahl Pins modifiziert (Ausschnitte aus dem Skript):
# MEC1-130-02-S-D-A.scr # # Library Script # # PCB Matrix SET WIRE_BEND 2; Grid mm; SET COLOR_LAYER 29 3 ... Layer 52 bDocu; Description '<b>PCB Matrix Packages</b><p>\n'; Edit MEC1-130-02-S-D-A.pac; Description '1MM MIN-EDGE CARD ASSEMBLY'; Layer 1; SMD '1' 1.88 0.61 -0 R90 (-9.5 -3.53049993515015); ...
SMD '58' 1.88 0.61 -0 R90 (19.5 3.53049993515015); Change Drill 1.02; ...
Ich konnte den SDcard-MP3-Player aus dem Elektor-Magazin (www.ti.com/ww/eu/university/pdf/Elektor_en_MP3_C5515.pdf) kompilieren und auf dem eZdsp-Board zum Laufen bringen. Probleme bereitete v.a. ein Update von CCS. Alte Projekte liessen sich danach nicht mehr kompilieren, folgende Fehlermeldung:
This project was created for a device-variant that is not currently recognized: TMS320C55XX.TMS320VC5515. Please install the device-variant descriptor, or migrate the project to one of the supported device-variants. MP3Dec project 1313484944829 212
Ich habe die Projekte neu angelegt und alle Dateien aus dem alten Projekt importiert, sowie die include-Pfade ergänzt. Dann funktionierte es wieder.
Der MP3-Player von Elektor basiert auf dem DSP-Bios von TI. Hierbei handelt es sich um einen Kernel, der u.a. Hardware-Treiber und Multithreading (softwarebasierte Nebenläufigkeit) bereitstellt. Hierzu einige Infos auf dem Web:
- DSP/BIOS Real-Time Operating System (RTOS) (focus.ti.com/docs/toolsw/folders/print/dspbios.html)
- DSP/BIOS v5.41 User’s Guide (www.ti.com/litv/pdf/spru423h)
Der in diesem Projekt verwendete MP3 Decoder wird von TI in binärer Form zur Verfügung gestellt. Es ist also kein Quellcode für den Decoder erhältlich. Der Autor des Artikels Lars Lotzenburger ist übrigens Mitarbeiter von TI Germany.
Eine Nebenaufgabe war, die SD-Karte direkt über USB von einem Hostrechner aus beschreiben zu können. Hierzu muss die USB-Hardware des DSP als “USB Mass Storage” konfiguriert werden.
Heute ist es mir gelungen, basierend auf dem USB Demo des C5515 Boards ein eigenes Projekt zu erstellen, dass kompiliert, und sich danach unter Windows 7 als USB MASS STORAGE Device anmeldet. Ich habe hierzu lediglich die USB Deskriptoren leicht modifiziert, gemäss folgender Spezifikationen:
Es stellen sich nun verschiedene Fragen:
- Wie funktioniert der USB-Interrupt-Mechanismus genau? Das Demo definiert keine ISR-Vektoren, sondern loopt lediglich in einer Endlosschleife durch eine pseudo USB-ISR. Hierzu habe ich folgendes Dokument gefunden: Setting up TMS320 DSP interrupts in C (focus.ti.com/lit/an/spra036/spra036.pdf )
- Welchen MASS STORAGE transport Standard soll verwendet werden (bInterfaceSubClass)? Beim Beispiel hat 06h ( SCSI transparent command set) funktioniert, 00h ( SCSI command set not reported ) hat nicht funktioniert.
- Teilweise beantwortet: www.lvr.com/mass_storage_faq.htm
- Die USB-Funktionalität ist spärlich dokumentiert. Auf der Suche nach weiteren Hinweisen habe ich folgende interessanten Dokumente gefunden:
- TI Prozessor Wiki Seiten: processors.wiki.ti.com/index.php/Category:C5000, processors.wiki.ti.com/index.php/C5504/05/14/15_Training
- TI Lernmaterial: www.ti.com/ww/eu/university/roms.html
- Elektor Artikel zum erstellen eines MP3-Players auf meinem Testboard: www.elektor.com/magazines/2011/march/mp3-one-two-three.1706996.lynkx
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
Bei der Evaluation des Testhardware standen folgende Kandidaten in der engeren Auswahl. Es ergab sich eine Rangliste:
- eZDSP TMS320C5515: erste Wahl, verfügt über vielfältige Möglichkeiten, insbesondere programmierbare USB-Schnittstelle und Micro-SD Slot.
- eZDSP TMS320VC5505: Geeignet, aber ohne USB und SD-Karten Unterstützung.
- Beagleboard: wenig Informationen vorhanden, Linux-basiert daher tendenzieller Universalrechner mit hohem Software-Overhead
- Arduino: viel zu langsam
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.
Ausserdem habe ich schon mal die USB2.0-Spezifikationen besorgt:
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
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:
Die noch bevorstehende Entwicklung der 4-kanaligen DAC Hardware setzt die Wahl eines passenden Bauelementes voraus. Es ist von Vorteil, einen Baustein zu verwenden, der bereits 4 DACs beherbergt. Vorausgesetzt wird, dass der Baustein über einen Mechanismus verfügt, der die Synchronisation der einzelnen DACs erleichtert. Zusätzlich wird eine sehr stabile Referenzspannung benötigt.
Folgende Bauteile wurden evaluiert:
TI/BB DAC 8534
plus REF02 (Referenszpannungsregler)
DAC8534IPWG4
LP 16Bit quad 16-TSSOP
Kandidaten:
|TI TLV320AIC3204IRHBT||2xADA||32bit||192khz||I2C||1.26…3.6V||chf24.50||focus.ti.com/lit/ds/symlink/tlv320aic3204.pdf|
|TI PCM2707||2xDA||16bit||48khz||USB / SPI||5V||chf11.40||focus.ti.com/lit/ds/symlink/pcm2912.pdf|
|TI DAC8411IDCKT||1xDA||16bit||225kSpS||SPI||1.8…5.5V||chf10.50||focus.ti.com/docs/prod/folders/print/pcm2705.html|
|ANALOG DEVICES – AD5666BRUZ-1||4xDA||16bit||94kSpS||SPI||2.7…5.5V||chf1||www.analog.com/UploadedFiles/Data_Sheets/AD5666.pdf|
|BurrBrown PCM-63 chips in their best (K-) selection||20 bit||verwendet im DAC von m.heijligers|
Interessante Links zum Thema:
members.chello.nl/~m.heijligers/DAChtml/dactop.htm
Datasheet
eZdsp Stick
Schematics
Board schematics. PDF – 08/06/09
Test Code
Test code and board support library (CCS 4.0) for the TMS320VC5505 DSP USB STICK . ZIP – 09/01/10
- SPIROM test
SD Card Controller
- TMS320C674x/OMAP-L1x Processor
Multimedia Card (MMC)/
Secure Digital (SD) Card Controller
Interrupts
- “avoid calling other functions from within
the ISR.”
Demo Code
- läuft unter arduino
- fft filter demo läuft auf eZdsp
Schätzung Grössenordnung
Min. clock f spi = samplerate * n kanäle * 16 = 44100 * 4 * 16 = 2.8224 MHz
Clock Arduino: 16 Mhz
Clock TMS320: 100MHz
Resultate
FFT-Filter läuft auf TMS320 Testplatform “eZdsp”
Nächste Schritte
- 4h SD-Karte hardwaremässig an eZdsp-Board anschliessen
- 8h sdfatlib auf TMS320 portieren
- 2h DAC Baustein evaluieren
- 8h DAC Board layouten
- 8h DAC Software für TMS320/Arduino schreiben