Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03499.jsonl.gz/2178

3.3 Software
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.
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
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
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
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.