Forum: Mikrocontroller und Digitale Elektronik LPC2468: Warum ist DMA so langsam?


von tuppes (Gast)


Lesenswert?

Hallo,

ich arbeite daran, den GP-DMA-Controller vom LPC2468 in Betrieb zu 
nehmen. Was ich bisher habe:

Ein "Spielprogramm" mit Memory-to-Memory-Transfer in dem 
16-KB-RAM-Block, der dem AHB1 zugeordnet ist. Pseudocode:
1
DMAInitialisieren ();
2
while (1)
3
{
4
    TransferKonfigurieren ();
5
    TransferStarten ();
6
    LEDAn();
7
    
8
    while (TransferActive ())
9
    {
10
    }
11
    LEDAus();
12
}

Also noch nix mit Interrupts und so weiter. Die Funktionen machen im 
Prinzip folgendes:

DMAInitialisieren:
GPDMA Power einschalten
DMACConfiguration.Enable setzen

TransferKonfigurieren:
Transfer-Size 1024 (Feldlänge in Bytes),
Transfer-Width 32 Bit,
Burst-Size 4 (4 x 32 Bit ist genau die FIFO-Tiefe des DMA-Controllers)
Keine LinkedList-Items

TransferStarten:
ChannelConfiguration-Register.Enable setzen

TransferActive:
Prüfen, ob ChannelConfiguration.Active auf 1 steht

Richtig funktionieren tut das Ganze, es wird auch kopiert, es ist nur 
deutlich langsamer (etwa Faktor 4) als ein gleichwertiges memcpy mit 
Software, und das hätte ich nicht erwartet. Woran kann das liegen?

Hat hier jemand schon mal was Ähnliches programmiert und kann mir einen 
Tipp geben?

Danke,
Tuppes

von (prx) A. K. (prx)


Lesenswert?

Solches DMA ist nicht erfunden worden um memcpy zu beschleunigen, 
sondern um dem Prozessor verhackstückte I/O-Transfers zu ersparen.

von tuppes (Gast)


Lesenswert?

Danke fürs schnelle Antworten.

Aber wodurch wird denn so viel Zeit verbraten, 4mal so lange ist ja doch 
erheblich.

von Henry (Gast)


Lesenswert?

Ich kenne diesen Kontroller nicht aber bei anderen gibt es ein globales 
Konfigurationsregister in welchem man einstellt aller wie viele Takte 
ein DMA Takt gemacht wird. Bei dem µC den ich gerade vor mir habe ist 
der defaut Wert "jeder vierte Takt für DMA".

von Simon K. (simon) Benutzerseite


Lesenswert?

Eventuell muss über den gleichen Datenbus noch das Programm selber 
(mglw. aus einem Flash) ausgeführt werden. Möglicherweise ist es 
deswegen so langsam? kenne den Chip aber auch nicht.

von Mario P. (mariopieschel)


Lesenswert?

Setze mal Burst-Size auf 256.

von tuppes (Gast)


Lesenswert?

> Setze mal Burst-Size auf 256.

Danke, aber das hab ich schon versucht, keine Auswirkungen. Alle 
Burst-Größen, die größer sind als das GPDMA-interne FIFO (4 x 32 Bit), 
bringen nichts.

Mein aktueller Verdacht ist, dass die ständige Pollerei des 
GPDMA-Controllers (while TransferActive) den Transfer ausbremst. Müsste 
sich vermeiden lassen, indem ich mir stattdessen einen 
Terminal-Count-Interrupt geben lasse. Das wird nächstes Jahr 
ausprobiert.

Trotzdem bin ich weiterhin für Anregungen dankbar.

Gibts eigentlich einen Ort im Netz, oder geeignete Bücher, wo man solche 
spezielleren Dinge nachlesen kann? Die NXP-Seite ist ja, wenns über 
Datenbücher und eher allgemein gehaltene Application-Notes hinausgeht, 
nicht sooo informativ ...

von Werner B. (Gast)


Lesenswert?


von Mario P. (mariopieschel)


Lesenswert?

Das Buch "The Insider's Guide To The NXP LPC2300/2400 Based 
Microcontrollers" ist empfehleswert.

Hier registrieren und runterladen:

http://www.hitex.com/index.php?id=download-insiders-guides

Die Registrierungsdaten werden nicht überprüft :O)

Von NXP gibt es nur das Datenblatt, das Usermanual und das Erratesheet.
Das ist nicht sehr kundenfreundlich. Ich kenne auch keien Hersteller von 
MCs, welcher weniger Infos seinen Kunden zukommen lässt.
Geht wohl mehr in die Richtung: "Sieh zu, wie Du klar kommst!"

von Robert T. (robertteufel)


Lesenswert?

@Mario

> Das Buch "The Insider's Guide To The NXP LPC2300/2400 Based
> Microcontrollers" ist empfehleswert.
da bin ich ganz bei Dir.

> Die Registrierungsdaten werden nicht überprüft :O)
ist richtig, deshalb gibts auch immer weniger solche Angebote, weil 
viele einfach Schrott reinschreiben

>
> Von NXP gibt es nur das Datenblatt, das Usermanual und das Erratesheet.
> Das ist nicht sehr kundenfreundlich. Ich kenne auch keien Hersteller von
> MCs, welcher weniger Infos seinen Kunden zukommen lässt.
Google ist auch Dein Freund. Dieser Link kam bei mir als erstes 
Suchergebnis hoch: 
http://www.standardics.nxp.com/products/lpc2000/lpc24xx/
Auf dieser Seite gibt es eine Menge nuetzlicher Links. Hier anfangen 
bring wahrscheinlich am weitesten.
http://www.standardics.nxp.com/support/microcontrollers/

> Geht wohl mehr in die Richtung: "Sieh zu, wie Du klar kommst!"

Siehe oben, wer da nicht ne ganze Menge Application Notes findet, den 
kann man zumindest nicht als "Such-Genie" bezeichnen.

p.s. ich find auch, dass die NXP Webseite nach wie vor sehr 
verbesserungsfaehig ist, bin aber von falschen Pauschalaussagen noch 
mehr abgestossen als von der Webseite.

Robert

von Mario P. (mariopieschel)


Lesenswert?

Hallo Robert,
ich habe das nicht geschrieben weil ich nicht Google "nxp" eintippen 
kann, sondern weil ich genau das hier bei NXP finde: (Dein erster Link)

    * I2S - USB Audio Demo (Oct 19, 2007)
    * LPC23xx and LPC24xx PLL Parameter Calculator (Jul 10, 2007)
    * μC/OS-II Ports for NXP LPC23xx Microcontrollers (by Micrium)
    * Sample Code Bundle for LPC23xx/LPC24xx Peripherals using Keil's 
μVision, V1.50 (Sep 7, 2007)
    * Write/Erase Security Library V2.00 for LPC23xx, LPC24xx (Apr 19, 
2007)

    * AN10775 NicheLite for LPC Implementation Notes, V1 (Dec 19, 2008)
    * NicheLite Software for LPC with IAR EWB, V1.02 (Feb 13, 2008)
    * NicheLite Software for LPC with Keil MDK, V1.02 (Jul 17, 2007)

... ist ja richtig erschöpfend. Das meiste von Drittanbietern.

Unter Deinem zweiten Link finde ich nach filtern für den entsprechenden 
MC auch nicht mehr. Ohne Filter sieht es ja richtig viel aus.
Und warum soll ich über Google Infos von NXP suchen? Schau Dir mal 
st.com und atmel.com an was die als Infos für ihre MCs anbieten.
Ich beschäftige mich schon eine ganze Weile mit den LPCs (weil ich die 
gut finde), aber die Infos bei NXP könnten mehr sein (viel mehr)!!!

von Mario P. (mariopieschel)


Lesenswert?

Hallo tuppes,
schau Dir mal die Register AHBCFG1 und AHBCFG2 an, da kann man an dem 
Bus-Verhalten schrauben. Setze mal "burst_break" (ist 00) auf 11.
UM10211 ab Seite 30
9. AHB configuration
9.1 AHB Arbiter Configuration register 1 (AHBCFG1 - 0xE01F C188)
9.2 AHB Arbiter Configuration register 2 (AHBCFG2 - 0xE01F C18C)

Im Blockdiagramm im Datasheet kannst Du sehen auf welchen Bus (AHB1 / 
AHB2) Du zugreifst.

Bitte veröffentliche Dein Ergebnis (sourcecode). Danke

von Robert T. (robertteufel)


Lesenswert?

@tuppes

Hab gerade auf http://www.LPC2000.com gesehen, dass es ein neues Users 
Manual gibt fuer die ganzen LPC2400 Familienmitglieder. Hast du diese 
Doku bereits benuetzt? Es war bereits zu meiner Zeit klar, dass die DMA 
Fragen offen lassen wuerde, ich hoffe die ehemaligen Kollegen haben 
einige Zusatzinfo in der neuen Doku untergebracht.

@Mario,

die meisten Codebeispiele fuer die kleineren LPC2xxx laufen auch auf dem 
LPC24xx. Ich war mal der Gruppenleiter Applikation bei NXP und das 
kleine Problemchen ist die (verschwindend geringe) Anzahl der 
Mitarbeiter um Beispielcode zu erzeugen. Als Alternative gab es die 
Win/Win Solution, 3rd Parties, die weit verbreitet sind oder unbedingt 
an den Markt wollen. Also habe ich mich damals entschlossen fuer 
verfuegbares Budget lieber 50 Mannjahre an Software portiert zu haben 
als 1 Mannjahr selbst zu erzeugen. In erster Linie ist von jeder Firma, 
die micros verkauft, natuerlich Software fuer kommerzielle Anwender 
gefragt, denn diese bestimmen den Markterfolg und somit auch 
letztendlich den Preis der Komponenten. Keil ist die weitest verbreitete 
kommerzielle Programmierumgebung bei NXP Kunden, deshalb wurde ein 
Software Paket fuer die uVision gemacht. Das ist C-Code, von NXP 
geschrieben, das Code Bundle kann also jeder portieren auf GCC, IAR oder 
sonstwohin. Was Keil geschrieben hat sind die USB / Ethernet Beispiele, 
die bei uVision mitgeliefert werden. Interniche hat den Niche-lite Stack 
angepasst und der ist frei verfuegbar. Ich bin einfach der Meinung, dass 
Programmierer, die bereits seit Jahren ein Betriebssystem implementieren 
dabei einen besseren Job hinlegen als Programmierer von NXP, die sich 
zwar besser mit dem Chip auskennen aber in OS oder TCP/IP-stacks... 
nicht ganz so erfahren sind. Ganz ehrlich, was ich gesehen habe an Code 
von ST und Atmel hat deutlich gemacht, dass diese Programmierer den 
Baustein gut gekannt haben, allerdings...... (siehe oben).  Damit 
moechte ich nun wirklich die Code Libraries der genannten Firmen nicht 
schlecht machen, sie sind lediglich mit einem anderen Hintergrund 
geschrieben und das ist sichtbar.

So, das war ein kleiner Abstecher in meine Vergangenheit und das "warum" 
manches bei NXP so ist, wie es ist. Allerdings habe ich wirklich, 
ehrlich, absolut nichts mit der Webseite www.nxp.com zu tun, ein Beipiel 
wie eine Webseite nicht gestaltet werden sollte! Die 
www.standardics.nxp.com ist eine geduldete Sub-Seite, die viel mehr Info 
enthaelt ueber die Micros aber von Seiten NXP.com haeufig unter Beschuss 
war. Das ist jedoch eine andere Geschichte, die waere mal bei einem Bier 
angebracht ;-)

Gruss, Robert

von tuppes (Gast)


Lesenswert?

Ich danke euch allen für eure Tipps und werde mich ab morgen damit 
befassen.

Das LPC24xx-UserManual-Update von vor zwei Wochen kannte ich schon, 
finde die Erklärungen allerdings stellenweise zu dürftig.

> Bitte veröffentliche Dein Ergebnis (sourcecode). Danke

Erkenntnisse beschreibe ich gern. Sourcecode geht leider nicht.

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.