Forum: Mikrocontroller und Digitale Elektronik Fragen zum DMA


von mpt (Gast)


Lesenswert?

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
von mpt (Gast)


Lesenswert?

Is anybody out there? xD

von (prx) A. K. (prx)


Lesenswert?

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
von Moritz (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von mpt (Gast)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Dennis S. (dspo)


Lesenswert?

"Wenn ihr eigene Programme oder Anleitungen geschrieben habt könnt ihr 
sie hier posten. Fragen werden gelöscht!"

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

mpt schrieb:
> Is anybody out there? xD

Versuch es das nächste Mal im passenden Unterforum.  In der Codesammlung
schaut niemand nach Fragen.

von Axel S. (a-za-z0-9)


Lesenswert?

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

von Alex (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.