Downloads

0

Mobile 4 channel player.pdf – Semesterarbeit als PDF, gerendert mit Prince

shusha-4-ch

Vorwort

0

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 z1@x21.ch.

Zu sehen ist hier die erwähnte Arbeit der Auftraggeber Joris Stemmle (Studierender Medienkunst) und Damian Fopp (Studierender Industrial Design)

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.

Erreichen der Ziele

0

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.

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
test-visu

Visuelles Debuging der WAV-Player Software

0

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.

 

 

 

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.

20110922-154051.jpg

Atemspiel und Kehlgesang

0

Folgende Anwendung wurde für eine Ausstellung im Auftrag von Iris Rennert erstellt.

20110922-154051.jpg

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.

20110922-154126.jpg

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.

20110922-153116.jpg

KO Messung Tastaturmultiplexer

0

Im Rahmen der Fehlersuche am Tastaturmultiplexer habe ich Messungen mit dem Oszillografen gemacht.

20110922-153116.jpg

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.

20110922-153211.jpg

Auf diesem Bild sind die Signale von zwei Adressleitungen in einer höheren Auflösung abgebildet. Wir erkennen das Verhalten eines digitalen Zählers.

20110922-153148.jpg

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.

20110922-153234.jpg

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.

20110922-153636.jpg

Elektromechanische Probleme beim Tastatur-Decoder

0

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.

20110922-153636.jpg

20110922-153655.jpg

 

WAV File Debug output

0

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

libsndfile auf TMS320 portieren

0

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

Literature Periferials

0

TMS320C5515/14/05/04/VC05/VC04 DSP
Multimedia Card (MMC)/Secure Digital (SD)
Card Controller
Reference Guide

www.ti.com/lit/ug/sprufo6a/sprufo6a.pdf

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

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

TMS320 DSP Algorithm Standard
Rules and Guidelines
User’s Guide

www.ti.com/lit/ug/spru352g/spru352g.pdf

FAT

de.wikipedia.org/wiki/File_Allocation_Table

WAV File Spec

www-mmsp.ece.mcgill.ca/documents/audioformats/wave/wave.html

AIC3204 (Audio Codec Specs)

www.ti.com/lit/ds/symlink/tlv320aic3204.pdf

Ein freies TMS320 MP3-Player Project

0

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.

sourceforge.net/projects/dspdap/

dspdap.git.sourceforge.net/gitroot/dspdap/dspdap

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

pcb1

DAC PCB 1

0

Da die eZdsp-Hardware nur über einen zweikanaligen DAC verfügt, muss ich eine Erweiterungs-Platine (PCB) entwickeln. Hier der erste Entwurf des DAC-PCBs:

 

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;
...

Elektor MP3-Player / DSP-Bios

0

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:

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.

USB Mass Storage

0

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:

www.usb.org/developers/devclass_docs/Mass_Storage_Specification_Overview_v1.4_2-19-2010.pdf

www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf

Es stellen sich nun verschiedene Fragen:

Auf eine weitere Implementierung habe ich vorerst verzichtet, da andere Arbeiten höhere Priorität haben bzw. das Projektziel auch ohne dieses Zusatzfeature erreicht werden kann.

Websites zum Thema

0

Foren

www.dsprelated.com/groups/c55x/1.php

USB-Specs

www.usb.org/developers/devclass_docs/

www.usb.org/developers/devclass_docs/usbmass-ufi10.pdf

www.usb.org/developers/devclass_docs/audio10.pdf

www.usb-by-example.com/FTDI_Book_C.pdf

 

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

DAC Evaluation

0

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

focus.ti.com/docs/prod/folders/print/dac8534.html

focus.ti.com/docs/prod/folders/print/ref02.html

 

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

Einarbeitung TMS320 / eZdsp board

0

Datasheet

TMS320VC5505 Fixed-Point Digital Signal Processor (Rev. B) (PDF 856 KB)

eZdsp Stick

focus.ti.com/docs/toolsw/folders/print/tmdx5505ezdsp.html

support.spectrumdigital.com/boards/usbstk5505/revb/

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

focus.ti.com/lit/ug/sprufm2b/sprufm2b.pdf

- TMS320C674x/OMAP-L1x Processor
Multimedia Card (MMC)/
Secure Digital (SD) Card Controller

Interrupts

blog.21ic.com/uploadfile-/2008-1/51217.78775422.pdf

- “avoid calling other functions from within
the ISR.”

Demo Code

code.google.com/p/sdfatlib/

- läuft unter arduino

code.google.com/p/c5505-ezdsp/

- 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
Go to Top