Other Parts Discussed in Thread: TM4C123GH6PM,
I have developed a concept to control LED strips of type WS2812B.
The basis is the TM4C123GH6PM on the evaluation kit EK-TM4C123GXL.
Now I want to optimize this concept.
But before I do that, I wanted to ask you if it can be done even better.
It was important to me that the MCU is not loaded as much as possible to create the data signal.
The periphery is connected as follows:
A timer0A is set as PWM with 800khz.
The MatchRegister is updated with 25 (1-signal) or with 75 (0-signal).
Thus the correct DutyCycle values for the LED data signal can be created.
The challenge was now, that the data signal itself can change in the DutyCycle value.
For this there is the Timer0B which runs parallel with the Timer0A with 800khz.
But here the match register is fixed to 15-20.
This clock is now configured on the GPIO pin.
And then a wire leads it back to another GPIO.
Now you can configure a DMA Channel.
The DMA Channel must be configured as SINGLE REQUEST.
And I couldn't do that with a timer.
Therefore I had to go the detour over a GPIO port.
Now the trigger of the GPIO port must be configured with the DMA.
Source address is the converted LED data. The destination address is the MatchRegister of the Timer0A.
Since the trigger is set from the time after the (1-signal).
The signal can now change independently before a new PWM period begins.
The DMA is in PingPong mode and 16 pixels are transmitted per DMA channel.
So far so good.
But the LED color values must be converted bit by bit.
The LED color values are stored in a byte array [3][1024].
And there the color values are changed byte wise over color effects. (0-255).
These color values must now be converted bit by bit into the matching MatchRegister number.
And I don't like that yet and it costs performance.
I am glad about improvement suggestions.
German Version:
Ich habe ein Konzept entwickelt, mit welchem man LED-Strips vom Typ WS2812B ansteuern kann.
Die Grundlage legt der TM4C123GH6PM auf dem Evaluation Kit EK-TM4C123GXL.
Dieses Konzept möchte ich nun optimieren.
Aber bevor ich das tue, wollte ich euch fragen, ob es noch besser geht.
Mir war wichtig, das die MCU möglichst nicht belastet wird, um das Datensignal zu erstellen.
Die Peripherie ist wie folgt verschaltet:
Ein Timer0A ist als PWM mit 800khz eingestellt.
Das MatchRegister wird mit 25 (1-Signal) oder mit 75 (0-Signal) aktualisiert.
Damit können die korrekten DutyCycle Werte für das LED-Datensignal erstellt werden.
Die Herausforderung war nun, das sich das Datensignal selbst im DutyCycle Wert ändern kann.
Dafür gibt den Timer0B dieser läuft parallel mit dem Timer0A mit 800khz.
Allerding ist hier der Matchregister fest auf 15-20 eingestellt.
Dieser Takt wird nun auf den GPIO Pin konfiguriert.
Und anschließend mit einem Draht wieder zu einem anderen GPIO zurückgeführt.
Nun kann man ein DMA Channel konfigurieren.
Der DMA Channel muss als SINGLE REQUEST konfiguriert werden.
Und das habe ich nicht mit einem Timer hinbekommen.
Deswegen musste ich den Umweg über ein GPIO Port gehen.
Nun muss der Trigger vom GPIO Port mit dem DMA konfiguriert werden.
Quell Adresse sind die konvertierten LED Daten. Die Ziel Adresse ist das MatchRegister des Timers0A.
Da der Trigger vom Zeitpunkt nach dem (1-Signal) gelegt ist.
Kann sich das Signal nun selbständig bevor eine neue PWM Periode beginnt ändern.
Der DMA ist im PingPong mode und es werden 16 Pixel pro DMA Channel übertragen.
Soweit so gut.
Aber die LED-Farbwerte müssen dafür immer Bitweise um konvertiert werden.
Die LED-Farbwerte liegen in einem Byte Array [3][1024].
Und dort werden die Farbwerte byte wise über Farbeffekte geändert. (0-255).
Diese Farbwerte müssen nun Bit für Bit in die dazu passende MatchRegister Zahl umgewandelt werden.
Und das gefällt mir noch nicht und kostet Leistung.
Ich freue mich über Verbesserung Vorschläge.
