Hat jemand mal den in einigen SAMD-Controllern eingebauten DAC benutzt? Mit welcher Taktfrequenz GCLK_DAC muss ich ihn versorgen? Das Datenblatt macht dazu leider keine Aussage. Ist Taktrate = Abtastrate sinnvoll oder kann GCLK höher oder niedriger sein?
Mike schrieb: > Das Datenblatt macht dazu leider keine Aussage. Ich kenne die Dinger nicht, aber das halte ich für sehr unwahrscheinlich
"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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.