SAMD DAC Taktfrequenz?

"The voltage pump uses the asynchronous GCLK_DAC clock, and requires 
that the frequency be at least four times higher than the sampling 
period."

Ich hab mit den Teilen bisher nichts bemacht - so wie ich das verstehe, 
besteht der einzige Grund, den Takt nicht mit Maximalfrequenz laufen zu 
lassen, darin, Strom zu sparen. Ich will aber nicht ausschließen, dass 
es evtl Einfluß auf DMA/Events/etc hat ...

Evtl hier mal nen bisschen stöbern:
http://asf.atmel.com/docs/3.15.0/samd21/html/group__asfdoc__sam0__dac__group.html

"The voltage pump uses the asynchronous GCLK_DAC clock, and requires 
that the frequency be at least four times higher than the sampling 
period."

Ich hab mit den Teilen bisher nichts gemacht - so wie ich das verstehe, 
besteht der einzige Grund, den Takt nicht mit Maximalfrequenz laufen zu 
lassen, darin, Strom zu sparen. Ich will aber nicht ausschließen, dass 
es evtl Einfluß auf DMA/Events/etc hat ...

Evtl hier mal nen bisschen stöbern:
http://asf.atmel.com/docs/3.15.0/samd21/html/group__asfdoc__sam0__dac__group.html

"The voltage pump uses the asynchronous GCLK_DAC clock, and requires
that the frequency be at least four times higher than the sampling
period."
Da der Maximalwert von GCLK_DAC  bei 350 kHz (SAM D21 Datenblatt, Seite 
940) liegt, würde das eine Samplingrate von höchstens 87.5 ksps 
bedeuten. Zum Glück braucht man die Ladungspumpe nur, wenn die 
Betriebsspannung unter 2.5V liegt. Trotzdem scheinen Abtastwerte 
verloren zu gehen, wenn GCLK_DAC = Abtastrate ist. Es scheint so, als ob 
die beworbene Samplingrate von 350 ksps in der Realität nicht annähernd 
erreicht wird.

Das Ganze ist äusserst frustrierend, da ich in meinem Projekt eine 
Abtastrate von ca. 300 kHz benötige und bei der Auswahl des Controllers 
auf die Angaben zur Samplingrate im Datenblatt (Seite 2) und in der 
Werbung vertraut habe. Ich habe nun schon viel Zeit in das Projekt 
investiert, und müsste bei einem Controllerwechsel wieder von vorne 
beginnen.

Hi Mike,

Wie programmierst Du denn ?
ASF 3 ? ASF 4 ? Native ?

Blocked / Non-Blocked bei ASF3?
Async / Sync bei ASF4 ?
Events/Interrupts/Polling bei Native ?

Bring die f_CPU so hoch wie möglich, wenn Du kein DMA machst, sonst 
brauchen die CPU Takte um den neuen Wert abzuhohlen und zu schreiben, zu 
lange.
Gerade bei ASF 3...

Hab das gerade wieder bei spi_write_buffer_wait feststellen müssen:
SPI Clock hat 10 MHz, die einzelnen Bytes kommen schön mit 10Mhz raus 
(den Teil macht ja die Hardware), aber zwischen den Bytes gab es Pausen 
im Bereich 15us. Sprich, ein umstellen der SPI Frequenz 1Mhz, 10Mz, 20Mz 
brachte praktisch nichts. Hier frist das ASF um die 100 Takte. Bei 8 MHz 
f_Cpu um die 15us.

Vielleicht hast Du ja damit hier auch Probleme ?

Also füttere den DAC mal über DMA (hier solltest Du 350kbps 
rausbekommen) und berichte...

Gruß N2

PS : Seite 809 : Auf Kosten der Genauigkeit sollten 1000 ksps zu 
schaffen sein. Ist vermutlich eh sowas wie ein R2R-Netzwerk...

PPS : Der Multiplexer, der VOUT auf Deinen Pin schaltet braucht 
mindestens 2.5V um eine saubere Spannung ausgeben zu können. Wenn VDDANA 
< 2.5V ist wird mit GCLK_DAC die Spannung des Multiplexers von VDDANA 
auf 2.5V gepumt.
Hier wird klar, warum die Samplerate dann so gering sein sollte.

Ist alles eine Frage der Genauigkeit :-)

Was mich weiterhin vermuten lässt:
 * Du programmierst nicht in Assembler, sondern in C
 * Du benutzt ein nicht selbstgeschriebenes Framework (ASF3 oder ASF4)
 * Du hast bisher keine kritischen Programmteile identifiziert
 * Du hast keine Takte gezählt
 * Du hast Dir bisher nicht genug Gedanken zum Thema "Overhead" gemacht


Gruß N2

PPS: Bitte schreib nicht, dass Du Arduino programmierst auf einem 
Zero...

Kurz zur Entwicklungsumgebung: Ich programmiere auf einem Xplained PRO 
Board und nutze Atmel Studio mit dem gcc-Compiler.
Der DAC wird über vom Timer TC1 ausgelöste Events getriggert, das 
Hauptprogramm tut im Moment nichts anderes als das DATABUF-Register mit 
einer austeigenden Zahlenfolge zu beschreiben, sobald das 
EMPTY-Interrupt Flag aktiv und das SYNCBUSY-Bit inaktiv ist.

N2 schrieb:
> Was mich weiterhin vermuten lässt:
>  * Du programmierst nicht in Assembler, sondern in C
Richtig, nicht ganz triviale Projekte auf 32bit-Controllern werden 
üblicherweise in C programmiert.
>  * Du benutzt ein nicht selbstgeschriebenes Framework (ASF3 oder ASF4)
Nein, ich programmiere die Hardware-Register direkt.
>  * Du hast bisher keine kritischen Programmteile identifiziert
Doch, der kritische Part ist das Warten auf das SYNCBUSY-Bit. Bis das 
wieder inaktiv zu wird, trifft anscheinend schon der nächste Event ein, 
jedenfalls ist dann EMPTY längst wieder gesetzt. Offensichtlich dauert 
die Synchronisation länger als der Abstand zwischen zwei Samples. 
Eigentlich auch logisch, denn laut Datasheet dauert die Synchronisation 
mindestens 5 GCLK-Zyklen.
Ich habe es bisher noch nicht mit der DMA probiert. Kann die DMA denn 
den Registersynchronisationsmechanismus umgehen?

Hi,

Ich probiere das die Tage mal aus. Was hast Du denn für Clocks 
eingestellt?

Habe die gleiche Ide und Board.

Gruß N2

Hi,

So, hab mal eben eine Testroutine geschrieben. Ich nutze ASF3.

Wie schon geschrieben, kommt es hier auf die CPU Taktfrequenz an:
Bei 8MHz bin ich bei 65,8kHz
Bei 48MHz komme ich auf 387kHz

Etwa so, wie ich es erwartet habe.

Gruß N2

1

#include <asf.h>

2

3

struct dac_module dac_instance;

4

5

int main (void)

6

{

7

  system_init();

8

9

  struct dac_config config_dac;

10

  struct dac_chan_config config_dac_chan;

11

12

  dac_get_config_defaults(&config_dac);

13

  dac_chan_get_config_defaults(&config_dac_chan);

14

  dac_chan_enable(&dac_instance, DAC_CHANNEL_0);

15

  dac_chan_enable(&dac_instance, DAC_CHANNEL_0);

16

  dac_init(&dac_instance, DAC, &config_dac);

17

  dac_enable(&dac_instance);

18

  while(1)

19

  {

20

    dac_chan_write(&dac_instance, DAC_CHANNEL_0, 0);

21

    dac_chan_write(&dac_instance, DAC_CHANNEL_0, 1023);

22

  }

23

}

Entschuldigung, wenn ich diesen schon etwas angestaubten Thread 
wiederbelebe, aber ich bin erst jetzt dazu gekommen, den DAC ausführlich 
zu testen. Dazu habe ich Sinussignale per DDS mit 320 kHz Samplingrate 
erzeugt und das Ergebnis per FFT untersucht.

Die Angabe im Datenblatt ist offensichtlich falsch. Der DAC funktioniert 
auch dann noch perfekt, wenn er direkt aus dem CPU-Takt von 48 MHz 
versorgt wird.
Bei niedrigen Taktraten tritt ein starker Jitter auf, der im Spektrum zu 
Oberwellen und Störpeaks führt. Mit 350kHz Takt ist das Ergebnis 
unbrauchbar.

Ab etwa 10 MHz ist jedoch das Optimum erreicht, so dass ich den DAC-Takt 
auf 10.24 MHz, also die 32-fache Sampling-Rate eingestellt habe.

Ärgerlicherweise zieht sich der Fehler durch alle Atmel-Datenblätter für 
die SAMD-Familie.