XMEGA: Zeitproblem mit zwei parallel sehr schnell laufenden Timern

[Peter(TOO)]

Hallo Erik,

Mit Interrupts wird das so nichts werden!
Es dauert jedesmal etwas Zeit, biss der laufende Prozess unterbrochen, gesichert und die Interrupt-Routine aufgerufen ist.
Die Verzögerungszeit hängt dabei schon mal vom gerade laufenden Befehl ab, von gesperrten IRQs reden wir mal gar nicht!
Das Problem liegt nicht bei den Timern, sondern in der Software, welche nur endlich schnell ist.

Die einzige Möglichkeit sehe ich darin, dass du das über die DMA machst.

Du baust dir z.B. die Sinustabelle auf.
Dann überträgst du diese Tabelle per DMA zum DAC
Die DMA triggerst du mit dem einen Timer.

Umgekehrt geht's beim ADC.
Hier konfigurierst du alles so, dass die DMA die Messwerte in einer Tabelle, evtl. Ringbuffer. ablegt.
Hier musst du aber sicherstellen, dass die CPU die Daten auch schnell genug verarbeiten kann.

Die DMA "stielt" dir dann nur die paar Takte, welche für das Lesen und Schreiben auf dem Bus nötig sind.

MfG Peter(TOO)

[Besserwessi]

2 so schnelle Aufgaben per Interrupt geht nicht, dafür die die Verzögerungen zu lange. Mit DMA (wenigstens für einen der Aufgaben) gibt es beim Xmega eine elegante Lösung. Möglich wäre sonst noch ein starrer ASM Code der Zyklengenau ausgeklügelt ist - ist aber etwas aufwendig.

[PICture]

Hallo!

@ erik_wolfram

Damit zwei Timer völlig unabhängig voneinander arbeiten könnten, würde ich dafür zwei µC nehmen, was am einfachsten ist. Sonst müsste man nur mit Flagsetzen für Hauptprogramm, also mit gesperrten Unterbrechungen arbeiten (als ASMan habe ich k.A. über "Cäh").

[Crazy Harry]

Ich bin kein C-Programmierer und kann dir auch nichts zu deiner Frage sagen, aber wenn du mehr Power brauchst, warum taktest du den XMega nicht mit 64MHz ?

[Wsk8]

32MHz = 31,25 ns / Takt
1,25 µs = ~40 Takte

Selbst wenn du nur den 1,25 µs Timer laufen lässt, ist das fast nicht möglich. (Bei 40 Takten für eine ISR darfst du im Prinzip gar nichts berechnen um noch mitzukommen)

mfg

[erik_wolfram]

Hallo,

vielen Dank für die vielen Antworten. Ich merke langsam, dass meine Anfoderungen die Rechenleistung des XMEGA's überschreiten. Wenn ich bald keine weitere Möglichkeit sehe bin ich wohl gezwungen einen stärkeren Controller zu verwenden.

Abgesehen davon, konnte ich nun eine Anforderung verringern: es werden nicht mehr 800 ksps sondern 400 ksps benötigt. Die zu messenden Spannungen sollen nun mittels OPV's verrechnet werden.
Damit habe ich wieder einen kleinen Lichtblick, stoße aber wieder auf die Grenzen des XMEGAs.
Als Option habe ich jetzt zwei Einzel-AD-Wandler mit SPI-Schnittstelle erwägt. Diese lassen sich in einer Daisy-Chain verschalten und verringern zu mindest die Komplexität der Ansteuerung und des Aufbaus der Schaltung.
Leider ergibt sich für diese AD-Wandler eine asynchrone zeitliche Ansteuerung, welche das Timing erschwert.

Diese AD-Wandler haben folgendes Verhalten:

Sie benötigen ein Signal für die AD-Wandlung "CONVST" welches über die AD-Wandlung und die Ausgabe erfolgt (high-Zustand) und dann kurz pausieren muss (low-Zustand).
Das lässt sich recht einfach mit einem PWM-Signal realisieren.

Nachdem das CONVST-Signal angelegt wurde benötigt die Wandler 1,4 µs bis zur Ausgabe. Diese erfolgt mittels SPI und beginnt mit dem ansteigenden SCK-Signal des XMEGAS und umfasst 2 x 16-bit also 4 byte.
Das Auslesen dieser Werte ist mit DMA und dem Interrupt Flag des SPI-Moduls kein Problem und ist recht einfach gehalten.
Mehr Probleme macht hier die Erzeugung des SCK-SIgnals indem Dummy-Bytes in das SPI-Data-Register geschoben werden. Um die benötigte Datenrate zu erreichen muss das SPI mit 16 Mhz laufen. Damit wird ein Byte innerhalb von 0,5 µs übertragen. Damit müsste theoretisch alle 16 Clockcylces ein neuer Wert in das Data-Register geschoben werden. Wohl oder Über ist das zu wenig für jeden Timer und muss wohl Quick&Dirty erfolgen.

Das Problem mit den Timern konnte ich eingrenzen. Man muss auf jeden Fall vermeiden, dass zwei Timer gleichzeitig auslösen. Da ich recht grade und bekannte Zeiten habe konnte ich die Timer über das CNT-Register entsprechend vorladen und so verschieben, dass sich Timer mit einem vielfachen zu einem anderen Timer nicht gegenseitig stören.
Die Ursache hierfür liegt wohl in einem Temporären Register welches sich alle Timer teilen. Wird ein Interrupt ausgelöst während ein anderes noch abgearbeitet wird wird der Wert in diesem Register überschrieben.
In Anbetracht dessen finde ich die Priorisierung der Timer mittels der LVL etwas unnütze. Soweit ich mich erinnere konnte man dieses Register in Assembler hierfür kopieren und nach der Interrupt wieder herstellen...


Der DMA für die Erzeugung des Sinus ist kein Problem - hierfür gibt es ausführliche Tutorials von Atmel. So erfolgt die Ausgabe des SInus ohne Rechenleistung. Es dürfen ledigleich keine Timer miteinander kollidieren.

Anbei: der XMEGA ist für maximal 32 Mhz ausgelegt, extern dürfen sogar nur 16 Mhz Quarze angeschlossen werden.

Gruß Erik

[Crazy Harry]

Dann schau dir mal die AppNote 1019 und 1020 von Atmel an. Da steht:

The 32MHz Internal Oscillator can be tuned to run at any frequency between 30MHz and 55MHz

Es soll auch eine weiter AppNote geben in der von 64MHz geschrieben wird. Ich selber betreibe 2 GPS-Tachos mit 64MHz auf XMega256A3U seit einigen Monaten ohne Probleme.