Hallo Forum,
Ich möchte 32 LEDWS2812 ansteuern. Meine Überlegung war, dass das am
effizientesten mit einem DMA Channel umsetzbar sein müsste. Da die LED's
eine feste Datenrate haben, sind je 4 LED's seriell an einem Pin. Die 32
LED's belegen also 8bits eines Ports.
Das bedeutet, dass ich folgende DMA Channel konfiguration benötige:
288 mal 1Byte mit exakt 0,4µs zwischen den Bytes.
Quelle ist der RAM, Ziel ein GPIO.
Mit einem ATXMega wäre das kein Problem. Im Datenblatt finde ich
sämtliche Angaben zum DMA:
Triggerquelle wäre der Timer mit 0,4µs, SingleShot Mode für ein Byte,
Blockgröße 288, Start und Ziel Pointer sind auch klar.
Ich benötige aber insgesamt etwas mehr Rechenleistung als die ATXMega
haben. Daher wollte ich einen AT32UC3B0512 verwenden.
Nun zu meiner Frage. Bei dem AT32UC3 komme ich aber mit dem Manual zum
DMA nicht zurecht. Mir scheint der DMA von diesem Controller kann viel
weniger?!
Ich sehe keinen Timer als Triggerquelle?! Außerdem ist mir das
Byte-padding nicht klar. Wie kann ich dem DMA beibringen, dass er zum
Beispiel nur Bit8 bis Bit15 von einem Port überschreiben soll? Im Manual
steht, dass alle oberen Bits automatisch null gesetzt werde....das ist
doch dämlich!
Muss ich bei diesem leistungsfähigeren Controller tatsächlich dem DMA
stärker mit CPU Last unter die Arme greifen, als das bei der "8bit
Gurke" der Fall wäre?
F. K. schrieb:> Wie kann ich dem DMA beibringen, dass er zum> Beispiel nur Bit8 bis Bit15 von einem Port überschreiben soll?
Zieladdresse ist dann +1.
Bei modernen 32-Bittern gibt es aus Komplexitätsgründen meistens ein Art
Event-System das Hardware-Ereignisse mit Aktions-Triggern verknüpfen
kann. So kann man einen Timer flexibel z.B. für ADC oder DMA nutzen.
Aber die 32-bittigen AVR würde ich nicht mehr für neue Designs benutzen,
heutzutage nimmt man auch bei Atmel besser Cortex-M3 oder -M4. Die
Umstellung darauf ist nicht wirklich viel aufwändiger, und die Aussicht
in die Zukunft deutlich besser.
Jim M. schrieb:> Aber die 32-bittigen AVR würde ich nicht mehr für neue Designs benutzen,> heutzutage nimmt man auch bei Atmel besser Cortex-M3 oder -M4.
Seh' ich auch so - nachdem Atmel durch Microchip gekauft wurde, wird es
wohl früher oder später eine Abkündigungswelle von Prozessoren geben,
weil zuviele Derivate unterschiedlicher Familien das gleiche
Anwendungsspektrum abdecken - die AVR32-Familie wähne ich unter den
ersten Streichkandidaten.
Dass der Controller AT32UC3 eventuell abgekündigt wird, wäre kein
Problem.
Ich habe mir aber auch das Manual zum SAM3S8 angesehen und stoße auf das
gleiche Problem.
Ein Event wird genausowenig als Trigger für das DMA Modul angegeben, wie
ein Timer. Atmel gibt an, dass der DMA Daten zwischen der Peripherie und
dem Speicher austauschen kann. Und im darauf-folgenden Satz wird dann
aber nur Peripherie aufgezählt, aber kein mit dem RAM als Quelle
nutzbaren Trigger. Irgendwie stehe ich auf dem Schlauch, wie ich beim
RAM als Quelle eine Übertragung ohne CPU Einsatz anstoßen soll.
Interessanterweise finde ich das Event-System bei den 32Bittern gar
nicht. Vom ATXMega kenne ich das ja noch.
Jim M. schrieb:> Zieladdresse ist dann +1
Das habe ich mir schon gedacht. Irritiert hat mich aber, was mit den
Bits oberhalb passiert. In dem Moment, wo ich die Adresse +1 rechne und
dem DMA sage, dass er nur ein Byte übertragen soll, muss er ja seine
Logik umschalten.
Plötzlich muss der DMA statt einfach in eine Adresse zu schreiben auf
Read-Modify-Write wechseln. Kann der das!? Ich hätte gedacht nein, oder
zumindest eine Info dazu im Manual erwartet. Oder arbeitet der DMA
wirklich Byteweise und nicht mit vollen 32bit registern? Auch dazu hätte
ich eine Info im Manual erwartet.
Und was mir gerade noch auffällt: Wie verhindere ich das Inkrementieren
der Zieladresse? Ich muss ja alle 288 Byte an die gleiche GPIO Adresse
schreiben. Das scheint auch nicht zu gehen. Irgendwie wirkt der DMA wie
ein gewaltiger Rückschritt....
Ich muss viel mehr CPU aufwand treiben, als noch beim ATXMega.
F. K. schrieb:> Plötzlich muss der DMA statt einfach in eine Adresse zu schreiben auf> Read-Modify-Write wechseln.
Falsch gedacht. Er schreibt einfach nur ein Byte des breiteren
Registers, und überlässt das restliche Handling dem Peripherial. Wenn
der Hersteller sich nicht komplett selbst in den Fuß geschossen hat dann
funktioniert das auch so.
F. K. schrieb:> Oder arbeitet der DMA> wirklich Byteweise und nicht mit vollen 32bit registern?
Ich war blauäugig davon ausgegangen dass man das individuell einstellen
kann. Nach kurzem Studium eines SAM3S8 bin ich mir aber nicht mehr
sicher - und würde meine Empfehlung von oben fast zurück ziehen.
Offenber hat zumindest der genannte Prozessor kein Event System, sondern
direkt verdrahtete Timer (ADC, PIO).
Ich verwende hier lieber als µC EFM32 und NRF5x (mit BT Low Energy).
Beide haben ein Event System, der NRF5x allerdings kein flexibles DMA.
Für Dein Problem:
F. K. schrieb:> Da die LED's> eine feste Datenrate haben, sind je 4 LED's seriell an einem Pin. Die 32> LED's belegen also 8bits eines Ports.
würde ich auf dem SAM3S8 versuchen die Signale via der PWM Einheiten zu
erzeugen. Die kann nämlich über DMA nachladen.
Das mit der PWM könnte klappen. Ich müsste dann zwar beim Setzen der LED
Daten eine zusätzliche Datenumwandlung durchführen, aber dafür müsste
die Zeit reichen. Mal sehen, was das Manual zu der Idee sagt. :)
Mir will allerdings einfach nicht in den Kopf, dass ein ganzer Teil des
Datenverkehr-Managements zu fehlen scheint.
Der erste Satz im Manual des ATXMega DMA trifft den Nagel auf den Kopf:
"Allows high speed data transfers with minimal CPU intervention
– from data memory to data memory"
Wie lösen die Atmel 32bitter diese elementare Aufgabe, wenn der DMA
"nur" noch für Peripherie ist?
Ich habe gerade mal wieder das Manual zur PWM studiert. Auch die PWM's
sind genauso wie die Timer nicht am DMA angeschlossen. Die ganzen
32bitter scheinen den DMA nicht getimed ansteuern zu können....irgendwie
nen Armutszeugnis...so einen faux pass hatte ich bei Atmel bisher noch
nie...
Naja, vielleicht reichen auch die 32MHz der ATXMega. 'den spitzen
Bleistift raushol'
Na ja, ich lese auf der Atmel Seite was anderes:
... The DMAC can transfer data between memories and peripherals, and
thus off-load these tasks from the CPU. The module supports peripheral
to peripheral, peripheral to memory, memory to peripheral, and memory to
memory transfers. ...
Diesen Satz gibt es beim SAM3 nicht. Der stammt von einer anderen
SAM-Reihe. Ich habe parallel nämlich auch noch mal geschaut. Ich habe
mit dem SAM3 anscheinend den einzigen Cortex rausgepickt, bei dem der
DMA verkümmert ist.
Beim SAM4 oder SAM C usw. kann der DMA wieder das Gleiche wie beim
ATXMega.
Bleibt nur die Frage, ob der SAM C das Bxteweise schreiben des GPIO
hinbekommt. Das Manual liest sich zumindest so.
F. K. schrieb:> Ich habe> mit dem SAM3 anscheinend den einzigen Cortex rausgepickt, bei dem der> DMA verkümmert ist.
Hmmm, verkümmert würde ich nicht sagen. Es gibt einen klassischen DMA
und einen PDC für diverse Peripherals.
Ich habs z. B. beim SAM3U noch einemal nachgelesen.
Der SAM3U hat offensichtlich wieder einen DMA, der SAM3S dagegen
nicht....wie gesagt....der Kunstgriff ins Klo. Den einzigen Cortex
rauszupicken, der keinen DMA hat, ist auch ein Talent.
Aber was solls, ich habe jetzt soviele Datenblätter zu der DMA Funktion
der ganzen Controller zerpflückt, dass ich erstmal Schrauben sortieren
gehe.
Danach fange ich mit dem Abgleich der übrigen design-relevanten
Funktionen des SAM C an. 'Eisbeutel auf den Kopf leg'
Genau, einen Peripheral DMA Controller. Der hat keine Möglichkeit,
timer-getriggert zu werden. Lies noch mal genau nach. :)
Beim SAM3U gibt es ein Extra Kapitel für den normalen DMA und ein
weiteres für den Peripheral DMA.
Jim M. schrieb:> würde ich auf dem SAM3S8 versuchen die Signale via der PWM Einheiten zu> erzeugen. Die kann nämlich über DMA nachladen.
Ich dachte, das sei der Weg.
