Hallo Forum, Ich möchte 32 LED WS2812 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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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'
:
Bearbeitet durch User
Also ich weiss ja nicht, was du liest, aber ... http://www.atmel.com/Images/Atmel-6500-32-bit-Cortex-M3-Microcontroller-SAM3S4-SAM3S2-SAM3S1_Datasheet.pdf beschreibt im Kapitel 25 den PDC, den Peripheral DMA Controller.
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.
:
Bearbeitet durch User
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.
Nur dass das PWM Modul ebenfalls nicht am DMA angeschlossen ist....wie ich oben schon geschrieben hab...
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.