www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Allgemeine Tips zum Programmieren von TI DSPs


Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Ich habe da mal eine recht allgemeine Frage: Kennt ihr gute Seiten im 
Internet (oder auch konventionelle Bücher), die sich mit der 
Programmierung von digitalen Signalprozessoren befassen? Ich versuche 
einen DSP von Texas Instruments (F2812) zu programmieren und benutze bis 
jetzt hauptsächlich die Dokumente von der TI Homepage. Da diese aber oft 
ziemlich langatmig zu lesen sind und es oft lange dauert bis man das 
findet was man sucht, würden mich Anleitungen, Tutorials, How-To's etc. 
stark interessieren. Ich hab mit Google leider nicht viel gefunden. 
Insbesondere alles was mit der Migration eines Programmes in den 
Flashspeicher zu tun hat wäre für mich sehr interessant.

Vielen Dank im Vorraus für eure Antworten
Andi

Autor: Tim R. (mugen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also folgende Erfahrungen habe ich gemacht:

- Wenn man eine Baugruppe initialisiert, dann sollte man das gesamte 
Register aus der Dokumentation abtippen. Ich mache das gleich mit 
vollständigem Kommentar und benenne sie als init_XXX, also wie init_SPI, 
init_EPWM, init eQEP usw. Diese Arbeit ist natürlich sehr aufwendig, 
aber man beschäftigt sich mit den Registern und definiert auch jedes. 
Natürlich muss man auf R/W Rechte achten. Wenn das Register aufgebaut 
ist, dann dauerte das Ansprechen der Schnittstelle nie mehr als einen 
Tag, bzw. incl. Verarbeitung. Einzige Ausnahme wäre eCAN, dafür ist das 
Register eindeutig zu groß.

- Grundsätzlich kann man vieles in normalen C /C++ Code schreiben, aber 
es gibt keine Formate wie bool , int8 usw.

- Mit #pragma CODE_SECTION(Funktion, ".weißdergeier");. kann man seine 
Funktionen in einem bestimmten Speicherbereich mappen.

- Sehr wichtig sind die PDF Dateien aus User Guides und die PDF "System 
Control and Interrupts Reference Guide"

- Halte dich nicht lange mit den Examples auf! Bis jetzt habe ich nie 
eine Struktur übernehmen können und hab immer alles selber geschrieben. 
Evtl. können die Registerwerte / Einstellungen übernommen werden.

- Aus leidvolle eigener Erfahrung, bestell dir rechtzeitig DSPs für die 
Produktion/Entwicklung. Ich muss nun 8 Wochen auf meine DSPs warten und 
diese Zeit habe ich eigentlich nicht.

- Arbeite möglichst oft mit Strukturen, die Sache mit Define finde ich 
persönlich später sehr unübersichtlich. Es gibt bestimmt Gründe für 
define, aber bist jetzt habe ich sie sehr selten genutzt.

- GPIOs würde ich nicht mit DAT arbeiten, sondern mit SET. Zwar habe ich 
das Problem noch nicht ganz lokalisiert, aber der DSP verschluckt sich 
mal selten und setzt nicht den Ausgang! Ich denke mit Set kann man 
dieses Problem evtl. umgehen.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Insbesondere alles was mit der Migration eines Programmes in den
> Flashspeicher zu tun hat wäre für mich sehr interessant.
Dafür gibt es eine Application Note (spra958g). Da sind auch passende 
Linker Command Files dabei. Damit geht das Ganze recht einfach.

> - Halte dich nicht lange mit den Examples auf! Bis jetzt habe ich nie eine
>   Struktur übernehmen können und hab immer alles selber geschrieben. Evtl.
>   können die Registerwerte / Einstellungen übernommen werden.
Ich habe immer die Init-Routinen und die Header-Files der "C/C++ Header 
Files and Peripheral Examples" (sprc097) genutzt, dann entfällt das 
Abtippen.

> - Arbeite möglichst oft mit Strukturen, die Sache mit Define finde ich
>   persönlich später sehr unübersichtlich. Es gibt bestimmt Gründe für
>   define, aber bist jetzt habe ich sie sehr selten genutzt.
Strukturen sind effizienter als defines, aber mehr zu schreiben (wenn 
man's selber schreibt, siehe voriger Punkt), werden dafür aber von der 
Auto Complete-Funktion unterstützt.

> - GPIOs würde ich nicht mit DAT arbeiten, sondern mit SET. Zwar habe ich
>   das Problem noch nicht ganz lokalisiert, aber der DSP verschluckt sich
>   mal selten und setzt nicht den Ausgang! Ich denke mit Set kann man
>   dieses Problem evtl. umgehen.
Vielleicht ein "Read-Modify-Write-Problem"?

Autor: Tim R. (mugen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> - GPIOs würde ich nicht mit DAT arbeiten, sondern mit SET. Zwar habe ich
>>   das Problem noch nicht ganz lokalisiert, aber der DSP verschluckt sich
>>   mal selten und setzt nicht den Ausgang! Ich denke mit Set kann man
>>   dieses Problem evtl. umgehen.
> Vielleicht ein "Read-Modify-Write-Problem"?

Ja genau dieses Problem ist es! Dieses Problem kann mit Set und Clear 
entschärft werden, aber dieses Problem ist immer noch vorhanden.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das lernt man aber schnell... ;) Immerhin wird ja im Datenblatt 
ausdrücklich darauf hingewiesen...

Autor: Tim R. (mugen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha wrote:
> Das lernt man aber schnell... ;) Immerhin wird ja im Datenblatt
> ausdrücklich darauf hingewiesen...


Das Problem wird trotzdem nicht damit vollständig gelöst.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Super, vielen Dank für die vielen hilfreichen Antworten!
Habe die obengenannten Dokumente größtenteils gelesen. Hätte gedacht 
dass es evtl eine Seite gibt, wo alles ein wenig Einsteiger-freundlicher 
präsentiert wird. Dann werde ich mich wohl weiterhin durch die 
TI-Dokumente kämpfen :)
Bin auch der Meinung, dass der Registerzugriff über Strukturen 
wesentlich übersichtlicher ist.

Ich hätte da noch eine spezielle Frage zu RTDX:
Ich lasse mir aus einem Simulinkmodell mit dem Real Time Workshop C-Code 
erzeugen, mit dem die Datenübertragung via RTDX gut funktioniert. Sobald 
ich manuell kleinste Änderungen am Code vornehme, verhält sich RTDX sehr 
merkwürdig. Es reicht schon aus dass ich nur eine Variable zusätzlich 
(global) definiere
int counter=0;

void one_step(void)
{
 Code fuer ein Abtastintervall 
...
 RTDX_write(...);
...
}

Dann werden die Channels teilweise nicht mehr beschrieben. Der 
Message-Zähler in CCS zeigt etwas anderes an, wie der Matlab mit dem 
Befehl cc.rtdx.msgcount('ochan1'). Oftmals ist der Messagezähler = 0 
obwohl ich definitiv die Funktion RTDX_write() ausführe. Mal wird ein 
Channel beschrieben und ein anderer nicht, obwohl die Befehle 
RTDX_write(...) für beide Channels ausgeführt werden.
Hat jemand eine Idee, womit dies zusammenhängt?

Viele Grüße
Andi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.