Hallo! Ich hätte ein paar Verständnisfragen bezüglich des DMA im atxmega: 1) Hier auf mikrocontroller.net steht, dass das DMA asychron zum CPU läuft. Im Manual A für atxmega steht aber, dass das DMA "kaum" CPU braucht? Wem soll ich jetzt glauben? Wir dmit kaum vielleicht gemeint, dass wenn die CPU gerade auf dem Bus arbeitet, dass der DMA-Controller auf das OK vom CPU warten muss, bis er dran kommt? sozusagen ein aushandeln zwischen den Beiden, wer jetztzt was machen darf? 2)Wie genau funktioniert der Buszugriff überhaupt? Denn die Grafik ohne Text im Manual ist ein bisschen schwer rasu zu lesen :)
:
Verschoben durch Moderator
mpt schrieb: > 1) Hier auf mikrocontroller.net steht, dass das DMA asychron zum CPU > läuft. Im Manual A für atxmega steht aber, dass das DMA "kaum" CPU > braucht? Wo siehst du den Widerspruch? > sozusagen ein aushandeln > zwischen den Beiden, wer jetztzt was machen darf? Ja. Die CPU macht kurz Pause, der DMA Zyklus findet statt, und dann geht es weiter. Der Einfluss auf das Programm ist abhängig davon, wie oft das stattfindet. Ich bin mit dem Xmegas nicht so vertraut, aber nehmen wir mal an, dass 20 Mio interne Buszyklen pro Sekunde stattfinden können. Und alle 10µs ein DMA-Zyklus läuft. Das sind dann 1-2 Buszyklen für DMA (je nach dessen Arbeitsweise) auf 200 Buszyklen. Das ist also üblicherweise nicht wirklich auffällig. Aber bei taktgenau in Assembler zurechtgefieseltem Pin-Timing kann es spürbar werden.
:
Bearbeitet durch User
Moin, Mit der DMA können Daten asynchron und fast ohne Belastung der CPU transportiert werden. D.h. Die CPU muss einmal die DMA initialisieren und kann dann was anderes machen, während die DMA Daten schaufelt. Mach vor allem bei großen Datenmengen Sinn, damit die CPU noch was anders mach kann als ständig nur Daten einlesen/ausgeben und von Speicher zu Speicher zu kopieren. Moritz
Ein beliebtes Missverständnis ist, dass sich DMA gut dafür eigne, Speicherblöcke im RAM von links nach rechts zu schaufeln. Mitnichten. DMA ist für RAM <-> I/O gebaut. Nicht für RAM <-> RAM.
:
Bearbeitet durch User
A. K. schrieb: > Wo siehst du den Widerspruch? Weil auf mikrocontroller.net nichts von kaum stand :) und kaum und Nichts haben einen Unterschied :) Moritz schrieb: > Mit der DMA können Daten asynchron und fast ohne Belastung der CPU > transportiert werden. D.h. Die CPU muss einmal die DMA initialisieren > und kann dann was anderes machen, z.b. bei einem asynchronen Reset, drücke z.b eine Taste und setze beispielsweise einen Zähler auf null. Aber beim DMA transportiere ich Daten und zwar asynchron. Ich kann mir das bildlich ohne einen Takt zu benutzen irgendwie nicht vorstellen. Hat der vllt seinen Takgeber intern?
mpt schrieb: > Hat der vllt seinen Takgeber intern? DMA ist ereignisgesteuert. UART empfängt ein Byte => Signal an DMA Controller => DMA Controller leiht sich von der CPU mal kurz den Bus aus => DMA Buszyklus holt Byte aus UART und schreibt es ins RAM.
mpt schrieb: > 1) Hier auf mikrocontroller.net steht, dass das DMA asychron zum CPU > läuft. Wo steht das eigentlich? Asynchron ist hier ein etwas gewagter Begriff, denn DMA ist üblicherweise sehr wohl taktsynchron. Gemeint ist wohl eher, dass die DMA Zyklen nicht in Verbindung mit der CPU-Aktivität stehen.
:
Bearbeitet durch User
"Wenn ihr eigene Programme oder Anleitungen geschrieben habt könnt ihr sie hier posten. Fragen werden gelöscht!"
mpt schrieb: > Is anybody out there? xD Versuch es das nächste Mal im passenden Unterforum. In der Codesammlung schaut niemand nach Fragen.
Womöglich kommt der "gefühlte Widerspruch" ja daher, daß man "braucht keine CPU" unterschiedlich verstehen kann. Denn zwar tut die CPU nichts zu einem gerade laufenden DMA Transfer, andererseits darf sie dann aber auch nichts anderes tun. Sie wird vom DMAC [1] angehalten, weil CPU und DMAC den gleichen Bus benutzen. Für eine dritte Instanz, sagen wir mal eine CPU-hungrige Funktion, ist die CPU in der Konsequenz trotzdem kurz weg, während der DMA Transfer läuft. Aus deren Sicht macht es keinen Unterschied, ob die CPU gerade fehlt weil der DMAC den Bus braucht, oder ob sie fehlt weil sie gerade selber Daten von A nach B schaufelt. Nächster Punkt: "Die CPU muss einmal die DMA initialisieren und kann dann was anderes machen" ist eine schamlose Übertreibung. Denn während ein DMAC zwar eine Speicheradresse inkrementieren kann, um so z.B. Daten vom I/O in einen RAM-Puffer zu schieben, so ist der RAM doch i.d.R. sehr endlich. Das heißt nach ein paar hundert, spätestens ein paar tausend Einzeltransfers ist der Puffer voll. Und dann muß die CPU sich nicht nur um den Puffer-Inhalt kümmern, sondern auch den DMAC neu konfigurieren, etwa auf den Pufferanfang zurücksetzen oder auf einen anderen Puffer. Drittens: asynchron. Bedeutet natürlich nicht unabhängig vom CPU-Takt, weil der ja gleichzeitig auch der Bustakt ist. Es ist in der gleichen Bedeutung asynchron wie es ein Interrupt ist. Ein DMA Transfer wird typischerweise von einem Hardware-Ereignis ausgelöst (z.B. UART hat ein Byte empfangen). Und das ist halt asynchron zu dem was die CPU gerade tut. Letztens: die Busübernahme. Das war in der guten alten Zeit <tm> in der Tat einfacher zu verstehen, als CPU und DMAC noch getrennte IC waren und der Bus sich in Form von Leitungen quer über die Platine manifestierte. Aber das Grundprinzip ist immer noch das gleiche: der DMAC signalisiert der CPU daß er den Bus braucht. Die CPU prüft dieses Signal am Ende eines Befehlszyklus (also dann wenn der gerade laufende Befehl fertig ist). Wenn das Signal aktiv ist, macht die CPU den Bus frei und signalisiert über ein zweites Signal dem DMAC daß er jetzt darf. Wenn der DMAC fertig ist, setzt er sein Anforderungssignal zurück und die CPU macht da weiter, wo sie angehalten hat. Die Signale hießen früher mal BUSRQ und BUSAK. Wenn es mehrere DMAC gibt, braucht man natürlich noch Prioritätslogik etc. [1] DMAC = DMA Controller XL
Was beim xmega wichtig zu wissen ist: Die CPU hat beim Buszugriff den Vorrang vor der DMA!! Deshalb ist es eventuell notwendig in die Hauptschleife NOPs einzufügen, damit genügend Buslücken vorhanden sind und die DMA rechtzeitig und genügend schnell schaufeln kann. Ich hatte den Fall, dass ich alle 4 DMAs schnell laufen lassen wollte und im Hauptprogramm auch viele RAM-Zugriffe waren, so dass die DMAs einfach nicht hinterherkamen. Mit eingestreuten NOPs lief es dann wie gewünscht.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.