Guten Abend, ich beschäftige mich derzeit mit DMA und seiner Anwendung und bin nun auf folgende Frage gestoßen: DMA besagt ja, dass die CPU den Systembus an den DMA-Controller abgibt. Dieser kopiert dann die Daten direkt von Speicherort zu Speicherort. Das ganze soll die CPU entlasten, siehe DMA. Was bringt dann aber die Entlastung der CPU, wenn die CPU währenddessen keinen Systembus hat? Sie kann sich doch dann keine neuen Befehle aus dem Speicher holen? Gruß Felix
Felix schrieb: > Was bringt dann aber die Entlastung der CPU, wenn die CPU währenddessen > keinen Systembus hat? Sie gibt ihn nicht auf Dauer ab, sondern zyklenweise, evtl auch für mehrere Zyklen, und zwar bedarfsgesteuert ähnlich Interrupts. Wenn man SPI über DMA betreibt, dann wird alle zig Takte mal ein einzelner DMA-Transfer eingeschoben. Das ist viel günstiger als der gleiche Job per Interrupt (wenn das überhaupt schnell genug ist).
A. K. schrieb: > Sie gibt ihn nicht auf Dauer ab, ok versteh ich, aber die CPU kann doch währenddessen nur sehr eingeschränkt/garnicht? arbeiten? Der Vorteil liegt einfach darin, dass der DMA schneller kopieren kann als die CPU, richtig?
Es gibt auch uC mit extra DMA-Bus, wo die DMA Zugriffe auf Dual Ported RAM erfolgen. Da sind dann gleichzeitige Zugriffe möglich. Außerdem gibt es noch weitere Möglichkeiten, z.B interleaved Zugriffe, falls die CPU den Bus nicht während eines kompletten Zyklusses benötigt, oder CPU mit Cache.
Felix schrieb: > aber die CPU kann doch währenddessen nur sehr eingeschränkt/garnicht? > arbeiten? Warum? Wieviel macht es deiner Ansicht nach aus, wenn auf 100 Buszyklen beispielsweise 2-3 für DMA draufgehen und die übrige Zeit die CPU weiterhin auf Speicher und IO zugreifen kann? > Der Vorteil liegt einfach darin, dass der DMA schneller kopieren kann > als die CPU, richtig? Wenn man für den Transport eines einzelnen Bytes einer seriellen Schnittstelle einen Interrupt verbrät, da sind das gern mal 100 Takte nur für ein einzelnes Byte. Macht man das per DMA, dann kommt der CPU der Speicher mal für 1-3 Takte abhanden und sie muss (vielleicht) entsprechend kurz warten. Für blockweisen Transfer am Stück ist DMA nicht selten langsamer als die CPU.
PS: Controller wie die der Cortex-M3 Klasse aufwärts haben üblicherweise mehrere Busse, Befehle und Daten getrennt, ebenso Flash, RAM und I/O getrennt, mit einer Art Koppelnetzwerk dazwischen. Wenn der DMA Controller aufs RAM zugreift, aber der Controller grad nicht, dann geht das gänzlich verlustfrei ab.
A. K. schrieb: > Felix schrieb: > >> aber die CPU kann doch währenddessen nur sehr eingeschränkt/garnicht? >> arbeiten? > > Warum? Wieviel macht es deiner Ansicht nach aus, wenn auf 100 Buszyklen > beispielsweise 2-3 für DMA draufgehen und die übrige Zeit die CPU > weiterhin auf Speicher und IO zugreifen kann? > Für blockweisen Transfer am Stück ist DMA nicht selten langsamer als die > CPU. Also ist deiner Meinung nach der DMA nur für kleine Datenmengen (z.B Empfanges Byte im Speicher ablegen) zu verwenden?
Felix schrieb: > Also ist deiner Meinung nach der DMA nur für kleine Datenmengen (z.B > Empfanges Byte im Speicher ablegen) zu verwenden? Ich wollte damit ausdrücken, dass es i.d.R. keinen Sinn ergibt, ein programmgesteuertes memcpy von 4KB per DMA zu erledigen und die CPU drauf warten zu lassen. Je nach Controller, I/O-Device und Pufferung kann es aber auch zu DMA-Bursts von beispielsweise einem Dutzend Zyklen kommen. Einzelfall betrachten, die immer gültige goldene Regel gibts da nicht.
DMA ist ja dazu da damit die CPU mit anderen Dingen weitermachen kann. Sie sagt dem Controller schicke diese Daten von A nach B und wenn du fertig bist gib mir Bescheid. Wenn dadurch ein Bus blockiert wird den die CPU braucht ist es schlecht implementiert.
>PS: Controller wie die der Cortex-M3 Klasse aufwärts haben üblicherweise >mehrere Busse, Befehle und Daten getrennt, ebenso Flash, RAM und I/O >getrennt, mit einer Art Koppelnetzwerk dazwischen. Wenn der DMA >Controller aufs RAM zugreift, aber der Controller grad nicht, dann geht >das gänzlich verlustfrei ab. Für diesen Controller stelle ich mir gerade auch die Frage, ob z.B. ein schneller empfang eines UARD Datenstroms (2 Mbit/s) mit fester Datenblocklänge! nur auf diese Art und weise in das RAM kopiert werden kann. D.h. alle anderen Varianten, Empfangsinterrupt für jedes Zeichen oder zyklische Prüfung sind doch bei diesen Datenmengen nicht praktikabel,oder? Eine effektive serielle Kommunikation stelle ich mir so vor! Datenblock im RAM zusammenstellen, start-, ende-zeiger und blockgrösse setzen und dem DMA kontroller initialisieren, dass er nach dem Transfer einen Interrupt auslöst. Einen DMA channel für den Empfangsstream initialisieren, Interrupt auslösen wenn ich einen festen Datenblock empfangen haben. Wird der Bustransfer per Burst durchgeführt? Und ist während dieser Zeit der der RAM zugriff für CPU blockiert?
magic2 schrieb: > Wird der Bustransfer per Burst durchgeführt? Das hängt vom Controller und dessen Einstellung ab. STM32 nein, LPC1700 möglicherweise ja / konfigurierbar. > Und ist während dieser Zeit > der der RAM zugriff für CPU blockiert? Auf das RAM kann pro Zyklus nur einer zugreifen.
A. K. schrieb: > Das hängt vom Controller und dessen Einstellung ab. STM32 nein, LPC1700 > möglicherweise ja / konfigurierbar. Hm, wenn ich mich recht entsinne, nur aus meinem Gedächtniss(nur aus dem Datenblatt gelesen) , sollten burst transfers über Timer und FSMC funktionieren (STM32)! GRUß
Jean Player schrieb: > wenn ich mich recht entsinne, nur aus meinem Gedächtniss(nur aus dem > Datenblatt gelesen) , sollten burst transfers über Timer und FSMC > funktionieren (STM32)! Meine Antwort bezog sich auf sein voriges Szenario mit UART.
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.