Hallo, ein ATXMega128a4u soll per DMA Daten aus einem Array im RAM an einen Port herausschieben. Er läuft mit 32 MHz. Allerdings erhalte ich deutlich weniger als 32 MSps, obwohl die CPU im IDLE-Mode ist. Es sind ca. 8 MSps. Warum? Ich dachte, der RAM und IO sind getrennt, so dass je Zyklus eine Schreib- und gleichzeitig eine Leseoperation ausgeführt werden. Das Adressincrement sollte ja ohne Buszugriff stattfinden. Was kann die Ursache für die geringe Geschwindigkeit sein?
Sicher, dass dieser DMA Controller für Blockdatentransfer direkt vom RAM zum Port ausgelegt ist? Wenn der byteweise getriggert arbeitet und für jedes Byte erst einmal den Bus beantragt, das Byte aus dem RAM liest, auf den Port schreibt und dann den Bus wieder freigibt, dann wären 4 Takte pro Byte völlig in Ordnung. Edit: Mal reingesehen. Der DMA Controller arbeitet offensichtlich mit getrennten und gepufferten Lese- und Schreiboperationen, also nicht direkt vom RAM zum Port. Das wären also schon einmal 2 Takte pro Byte Minimum. Und wenn man mit 1-Byte Bursts arbeitet, dann überträgt er eben 1 Byte pro DMA-Transaktion, wie eben beschrieben.
:
Bearbeitet durch User
Stefan Helmert schrieb: > Ich dachte, der RAM und IO sind getrennt, so dass je Zyklus eine > Schreib- und gleichzeitig eine Leseoperation ausgeführt werden. Was hat das eine mit dem anderen zu tun? Und warum liest du nicht einfach vorher im Datenblatt nach, wieviele Takte ein DMA-Transfer braucht?
"A write to SRAM takes one cycle, and a read from SRAM takes two cycles. For burst read (DMA), new data are available every cycle." (S. 25, http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf ) "Since the data memory is organized as four separate sets of memories, the different bus masters (CPU, DMA controller read and DMA controller write, etc.) can access different memory sections at the same time." (S. 24)
Axel Schwenke schrieb: > Was hat das eine mit dem anderen zu tun? Frühe DMA Controller waren teilweise so gebaut, dass sie mit den Daten selbst nichts zu tun hatten, sondern auf dem Datenbus eine direkte Verbindung zwischen Peripheriedevice und Speicher herstellten. Es also keine getrennten Lese- und Schreibzyklen gab, da beides in einem einzigen Zyklus ablief. Beispiel hierfür ist der antike Intel 8237 im PC, der den Floppy-Controller bedient, so noch vorhanden. Dieses Prinzip ist aber etwas aus der Mode gekommen, auch der Z80 DMA arbeitete schon mit getrennten Zyklen.
:
Bearbeitet durch User
Ich habe gerade selber mal die Datenblätter von Atmel überflogen und muß feststellen, daß sie sich mit Timingangaben beim DMAC sehr zurückhalten. Die oben zitierte Aussage zum Speicher-Timing ist so ziemlich die einzige Quelle. Damit wären je nach Betriebsart (Burstmodus) 1 oder 2 Takte für das Lesen aus dem SRAM nötig, ein weiterer Takt für das Schreiben [1] und der anscheinend 4. verbrauchte Takt dann für das Inkrementieren der Adreßzeiger, Dekrementieren des Blöcklängenzählers und Prüfen der Abbruchbedingung im DMAC. [1] Ich gehe nicht davon aus, daß Atmel da einen echten Crossover zwischen den diversen Busteilnehmern implementiert. Der DMAC wird eher von einem Busteilnehmer lesen (in ein internes Register) und in einem zweiten Buszyklus auf einen anderen schreiben.
Ja, aber er hat ja einen Buffer (der DMAC). Der sollte doch pipelined arbeiten und so das nächste Byte lesen, während er das alte rausschiebt.
Stefan Helmert schrieb: > Ja, aber er hat ja einen Buffer (der DMAC). Der sollte doch pipelined > arbeiten und so das nächste Byte lesen, während er das alte rausschiebt. Weshalb nimmst du das an? Solch ein Verhalten wäre für DMA untypisch. DMA ist zur Entlastung von Hintergrundtransfers vorgesehen. Nicht für Blocktransfers mit maximal möglicher Tranferrate.
A. K. schrieb: > Weshalb nimmst du das an? Naja, weil ich es so konstruieren würde. Mit wenigen % Mehraufwand könnte damit mehr als die doppelte Leistung erreicht werden.
Aus dem oben erwähnten Maual
> A bus arbiter controls when the DMA controller and the AVR CPU can use the bus.
The CPU always has priority, and so as long as the CPU requests access to the bus,
any pending burst transfer must wait. The CPU requests bus access when it executes
an instruction that writes or reads data to
SRAM, I/O memory, EEPROM or the external bus interface.
Wenn dein Programm sehr viel im SRAM macht, dann kommt der DMA
Controller auch seltener dran. Hast du da eine ungeschickte
Warteschleife implementiert?
Also ich komme auf etwa 6 Msp ohne Double Buffering von internen SRAM (256 Byte Transaction) auf einen Port bei 32 MHz FCPU
:
Bearbeitet durch User
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.