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


von Andi (Gast)


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

von Tim R. (mugen)


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.

von Micha (Gast)


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"?

von Tim R. (mugen)


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.

von Micha (Gast)


Lesenswert?

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

von Tim R. (mugen)


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.

von Andi (Gast)


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
1
int counter=0;
2
3
void one_step(void)
4
{
5
 Code fuer ein Abtastintervall 
6
...
7
 RTDX_write(...);
8
...
9
}

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.