Ansteuerung von WS2812B LEDs erstaunlich einfach

[Stoer P. (stoerpeak)]

Verwendet habe ich dafür einen 1m langen Streifen mit 30 Stück dieser 
LEDs und einen ATTiny25 mit Pufferelko.

Das recht kurz geratene Programm erzeugt einen über alle LEDs 
durchlaufenden Farbverlauf, also einen wandernden Regenbogen. Dazu wird 
mit Hilfe einer Tabelle jede LED mit Intensitätswerten für die drei 
Farben versorgt. Eine simple Routine gibt die Nullen und Einsen der 8Bit 
Variablen im benötigten Timing aus und diese Variablen werden bei jedem 
Programmdurchlauf mit den folgenden Tabellenwerten geladen.

Der Farbwechsel entsteht pro LED weil ihre drei Farben mit jeweils um 
120° phasenverschobenen Tabellenwerten versorgt werden. Die benachbarten 
LEDs erhalten versetzt dieselben Werte wodurch sich über die gesamte 
Strecke ein Farbverlauf ergibt. Die Wartezeit am Ende der Mainloop 
bestimmt wie schnell die Farben durch den Streifen laufen.

Hier der verwendete Code:

// ATTiny 85 => 30St. WS2812B LEDs
#include <avr/io.h>
#define F_CPU 16000000ul  // Prozessortakt 16MHz PLL Clock

// Pin Definition
#define  Tx    PB4      // Datenausgang

#include <util/delay.h>    // Delay Routinen
#include <avr/pgmspace.h>  // für Flashzugriff

// Funktionsdeklaration
void Transmit(uint8_t data);  // erzeugt 8Bit im WSB2812B Format

// Intensitätswerte
unsigned const Intens[256] PROGMEM = {255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,253,253,250,250,248,245,243,240,238,233,230,225,222,217,212,207,202,197,192,187,182,174,169,164,156,151,144,139,134,126,121,113,108,101,95,90,83,78,73,68,60,55,50,45,42,37,32,29,24,22,19,16,13,11,9,7,6,5,4,3,3,2,2,2,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,2,2,2,3,3,4,5,6,7,9,11,13,16,19,22,24,29,32,37,42,45,50,55,60,68,73,78,83,90,95,101,108,113,121,126,134,139,144,151,156,164,169,174,182,187,192,197,202,207,212,217,222,225,230,233,238,240,243,245,248,250,250,253,253,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255};

uint8_t Tab_Pos= 0;        // Zählvariable für den Aufruf der 255 Tabellenwerte
const uint8_t phase = 85;    // Phasenwinkel zwischen den drei Farben (1/3 von 255)
const uint8_t LED_offset = 8;  // Versatz zwischen den LEDs untereinander (255 / 30 LEDs)
const uint8_t LED_anzahl = 30;  // Anzahl der LEDs

int main(void)
{
  DDRB |= (1 << DDB4);    // PB4 -> Datenausgang
  PLLCSR |= (1 << PLLE);    // PLL Enable

// mainloop    
  while(1)
  {
  // RGB-Intensitäten modulieren
  for (unsigned char LED_Nr = 0; LED_Nr < LED_anzahl; LED_Nr++)
    {
      // RGB Intensitäten modulieren
      uint8_t rot = Tab_Pos + (LED_Nr * LED_offset);
      uint8_t gruen = Tab_Pos + phase + (LED_Nr * LED_offset);
      uint8_t blau = Tab_Pos + phase *2  + (LED_Nr * LED_offset);
      
      // RGB (je 8Bit in der Reihenfolge GRB) ausgeben
      Transmit(pgm_read_byte (&Intens[gruen]));  // grüne LED
      Transmit(pgm_read_byte (&Intens[rot]));    // rote LED
      Transmit(pgm_read_byte (&Intens[blau]));  // blaue LED
    }
    
  Tab_Pos++;  // Laufvariable inkrementieren ( 0 bis 255)
  
  _delay_ms(50);
  }
}

void Transmit(uint8_t data)  // 8 Bit seriell ausgeben
{
  for (unsigned char i = 8; i > 0; i--)  // 8 mal das MSB auf "0" oder "1" prüfen, ausgeben und einmal linksschieben
  {
    if (data & (1 << 7))  // falls das MSB eine "1" ist
    {
      // 700ns langen High Puls erzeugen
      PORTB |= (1 << Tx);    // Datenpin High
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      
      // 600ns langen Low Puls erzeugen
      PORTB &= ~(1 << Tx);  // Datenpin Low
    }
    else  // das MSB ist eine "0"
    {
      // 350ns langen High Puls erzeugen
      PORTB |= (1 << Tx);    // Datenpin High
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      // 800ns langen Low Puls erzeugen
      PORTB &= ~(1 << Tx);  // Datenpin Low
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
      asm volatile ("nop");
    }
    data <<= 1;    // Datenbyte einmal linksschieben und sich selbst zuweisen
  }
}

[Guest (Gast)]

Inline Assambler ist zwar eine nette Angelegenheit aber Bitbangen ist 
jetzt nicht so der effizienteste weg WS2812 anzusteurern.

Da gibt es mittlerweile doch deutlich bessere Verfahren ;)

[Wolfgang (Gast)]

Guest schrieb:
> Inline Assambler ist zwar eine nette Angelegenheit aber Bitbangen ist
> jetzt nicht so der effizienteste weg WS2812 anzusteurern.

Willst den den Tiny zwischendurch schlafen legen,  um bei gesteigerter 
Effizienz Strom zu sparen?
Oder was schlägst du alternativ konkret vor?

[Boris (Gast)]

Guest schrieb:

> Da gibt es mittlerweile doch deutlich bessere Verfahren ;)

Freitagsgeschwätz oder kann du dein AtTiny25-Programm ohne Bitbanging 
posten? Tippe auf das erstere.

[Sebastian R. (sebastian_r569)]

Es ist halt eine sehr einfache Möglichkeit, die Dinger ohne DMA, SPI und 
ähnlichem anzusteuern. Für einfache Aufgaben absolut ausreichend und 
kompakt.


Was mich fasziniert, ist dieses Projekt:
https://cpldcpu.wordpress.com/2014/03/19/%C2%B5-wire-usb-on-an-attiny-10/

WS2812 und VUSB auf einem Attiny10.

> Flash: 988 of 1024 bytes used (96.4%)
> SRAM: 28 (variables)+2 (stack) of 32 bytes used (93.8%)

[Dieter R. (drei)]

Sebastian R. schrieb:

> Was mich fasziniert, ist dieses Projekt:
> https://cpldcpu.wordpress.com/2014/03/19/%C2%B5-wire-usb-on-an-attiny-10/
>
> WS2812 und VUSB auf einem Attiny10.
>

Scheint bloß fraglich, ob es überhaupt funktioniert, letzter Kommentar 
vom Entwickler:

"I checked, but unfortunately it seems I do not have a known good hex at 
this point."

Frage ist auch, was zeitgemäß wäre angesichts aktueller Preise 
(Microchip, 5k):

ATtiny10  $ 0,24 (1k/32 Byte Flash/SRAM)
ATtiny402 $ 0,29 (4k/256 Byte + viel Peripherie)

[Guest (Gast)]

Boris schrieb:
> Freitagsgeschwätz oder kann du dein AtTiny25-Programm ohne Bitbanging
> posten? Tippe auf das erstere.

Wie wäre es mit einem Timer PWM und Interrupts besitzt der kleine soweit 
ich weiß. :O

[Roland E. (roland0815)]

Guest schrieb:
> Boris schrieb:
>> Freitagsgeschwätz oder kann du dein AtTiny25-Programm ohne Bitbanging
>> posten? Tippe auf das erstere.
>
> Wie wäre es mit einem Timer PWM und Interrupts besitzt der kleine soweit
> ich weiß. :O

Besser machen und vorzeigen.

[Stefan F. (Gast)]

Guest schrieb:
> Bitbangen ist jetzt nicht so der effizienteste weg WS2812 anzusteurern.

Das ist schon Ok, wenn die Anwendung sonst nicht andere zu tun hat.

Es gibt im Netz viele einfache Codefragmente, die alleine funktionieren, 
aber nicht miteinander kombinierbar sind. Das ist jetzt nicht neu.

Andererseits möchte sich wohl kein Anfänger direkt mit der ganzen 
Komplexität eines Multitasking-System auseinander setzen. Darauf kommt 
er schon früh genug von selbst.

[Praktiker (Gast)]

Hallo

an die unfairen "Kritiker" die eigentlich anders genannt werden sollten:

Macht es besser, oder macht es überhaupt erst mal und veröffentlicht es.

Das Programm von Stoer ist zum erlernen und verstehen, bzw. nachdenken 
wie mit Hilfe weiterer Quellen wie Tutorials, den Datenblättern (eben 
nicht  blindes nutzen von fertigen Bibliotheken) solche 
Herausforderungen gelöst werden schön nah dran am µC - hier halt ein 8 
Bit AVR- und dürfte vielen die wirklich daran interessiert sind wie der 
µC das macht und wie man ihn (eigentlich sich selbst) bei bringt eine 
Hardware nur mit hilfe der Datenblätter (und natürlich wissen um die 
Programmiersprache) sehr viel besser als die 1001 Beispiele und 
ausentwickelte Lösungen wo alles mit fertigen Biblotheken (Black Boxes) 
gemacht wird.

Noch "geiler" ;-) wäre natürlich ein gut und tiefgehend Kommetiertes 
Assemblerprogramm - zumindest für die Hardwarefreaks und Leute die 
wirklich verstehen wollen wie ein µC (hier ein 8 Bit AVR) funktioniert 
und genutzt wird - möglichst noch im Verbindung mit einen vollständigen 
AVR Assembler und Hardware (auch allgemeines wie Architektur, woher die 
Begriffe kommen, etwas Gecshichte, Bit, Byte, Word...) Lehrgang der sich 
gerne über 200-300 Seiten ersterecken darf.

Wer natürlich mit Black Boxes zufrieden ist kann sich an die typischen 
fertigen Lösungen daranhängen wie es sie bezüglich des WS281X zu 
hunderten gibt - dagegen ist absolut nichts einzuwenden so lange man 
dann schön geschlossen hält und weder gegen den Arduino als 
Gesamtkonzept oder solchen Leute wie Stoer auch nur ein Wort sagt.

[Boris (Gast)]

Guest schrieb:
> Boris schrieb:
>> Freitagsgeschwätz oder kann du dein AtTiny25-Programm ohne Bitbanging
>> posten? Tippe auf das erstere.
>
> Wie wäre es mit einem Timer PWM und Interrupts besitzt der kleine soweit
> ich weiß. :O

Danke, dass du dich als inkompetenter Schwätzer geoutet hast.

[Stoer P. (stoerpeak)]

Der Sinn dieser Veröffentlichung war einfach nur denen eine kleine Hilfe 
zu geben die ohne Fertiglösungen mit solchen LEDs spielen wollen.
Vom Assembler kommend ist man ja gewohnt Portpins zum richtigen 
Zeitpunkt selbst ein- und auszuschalten.
Und mit dieser Herangehensweise lassen sich die LEDs recht simpel und 
verständlich steuern. Wenn man den Farbwechselteil weg lässt dann wird 
es noch deutlich einfacher. Die Tabelle habe ich mir von einem meiner 
PIC Assembler Farbwechsler Projekte entliehen.

Und natürlich gibt es wie bei den meisten Projekten verschiedene 
Lösungsmöglichkeiten.
Man könnte ja auch einen PC zum steuern nehmen oder einfach nur einen 
optischen Reflexsensor am D_in der LEDs anschließen und durch 
Überstreichen eines "Barcodes" die LEDs mit den nötigen Bitmustern 
versehen....

[Falk B. (falk)]

Stoer p. schrieb:
> Der Sinn dieser Veröffentlichung war einfach nur denen eine kleine Hilfe
> zu geben die ohne Fertiglösungen mit solchen LEDs spielen wollen.

Naja. Zum "Spielen" wird es reichen, für eine gescheite Lösung, auch als 
Beispiel wie man es GUT macht, taugt es nicht. Denn deine Zeiten sind 
durch Probieren hingefummelt und immer wieder abhängig von 
Compilereinstellungen und Versionen. Wenn schon richtig, dann komplett 
in ASM, da hat man ein solides, reproduzierbares Zeitverhalten.

Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

Außerdem funktioniert dein Programm nur mit einer guten Portion Glück 
mit den richtigen WS2812B, welche WIRKLICH 50us Resetzeit haben! Denn du 
berechnest die Farben für die einzelnen LEDs immer zwischen zwei 
Übertragungen. Das dauert aber ein paar Mikrosekunden, welche für einige 
Exemplare zuviel sind, siehe den Artikel oben. Darum ist eine 
Sendefunktion, welche ein Array von Daten sendet besser als die 
Einzelaufrufe pro Byte.

Alles in Allem nix, was die Welt noch braucht. Schlechten oder 
mittelmäßigen Code gibt es tonnenweise im Internet.

[Johnny B. (johnnyb)]

Guest schrieb:
> Inline Assambler ist zwar eine nette Angelegenheit aber Bitbangen ist
> jetzt nicht so der effizienteste weg WS2812 anzusteurern.
>
> Da gibt es mittlerweile doch deutlich bessere Verfahren ;)

Ja kommt halt immer darauf an, ob oder was der Miktrocontroller sonst 
noch machen soll nebst dem Ansteuern der LED's.
Auf STM32 nutze ich zur Ansteuerung von WS2812 gerne einen Timer in 
PWM-Modus, welcher die Daten per DMA im Hintergrund reingeschaufelt 
bekommt. Die CPU ist so völlig entlastet, jedoch benötigt man pro Bit in 
den LED's ein ganzes Byte RAM, welches die Pulslänge bestimmt.

[F. F. (foldi)]

Stoer p. schrieb:
> Das recht kurz geratene Programm erzeugt einen über alle LEDs
> durchlaufenden Farbverlauf, also einen wandernden Regenbogen.

Super, danke! Wenn ich irgendwann mal WS2812B verwende, habe ich schon 
mal einen Ausgangspunkt, ohne mich gleich wieder bei Adam und Eva 
einlesen zu müssen (was ich aber wahrscheinlich trotzdem mache :-). )

Und die Schwätzer hier, anstatt zu kritisieren, dann doch bitte gleich 
den alternativen Vorschlag hier einstellen. Und zwar direkt in dem 
Beitrag, wo das kritisiert wird.

[Johannes S. (Gast)]

Alternative Vorschläge gibts hier schon lange:
https://www.mikrocontroller.net/articles/WS2812_Ansteuerung
Eine CPU mit Bitbanging auszulasten mag einfach sein, aber ich finde es 
auch nicht gut.

[Dieter R. (drei)]

Johannes S. schrieb:
> Alternative Vorschläge gibts hier schon lange:
> https://www.mikrocontroller.net/articles/WS2812_Ansteuerung
> Eine CPU mit Bitbanging auszulasten mag einfach sein, aber ich finde es
> auch nicht gut.

Und welche Lösung soll das jetzt sein, die besser ist oder weniger 
CPU-Auslastung produziert? Ich sehe nicht, wie der Link weiter hilft, du 
müsstest schon erklären, welche der dort erwähnten ca. ein Dutzend 
Lösungen es denn sein soll.

Außerdem gilt die Annahme einer 100%-CPU-Auslastung nur für die 
Datenübertragung. Für den Rest gilt:

"Die Wartezeit am Ende der Mainloop bestimmt, wie schnell die Farben 
durch den Streifen laufen."

Da könnte man also noch viel anderes machen.

[Tim . (cpldcpu)]

Dieter R. schrieb:
> Scheint bloß fraglich, ob es überhaupt funktioniert, letzter Kommentar
> vom Entwickler:
>
> "I checked, but unfortunately it seems I do not have a known good hex at
> this point."

Natürlich funktionierte die Lösung. Allerdings habe ich es mit den 
neueren Compilerversionen nicht getestet und die Hardware (Steckbrett) 
nicht mehr zur Hand. Mit dem AVR-GCC gab es immer mal wieder 
überraschungen, vor allem beim ATTiny10 support.

> Frage ist auch, was zeitgemäß wäre angesichts aktueller Preise
> (Microchip, 5k):
>
> ATtiny10  $ 0,24 (1k/32 Byte Flash/SRAM)
> ATtiny402 $ 0,29 (4k/256 Byte + viel Peripherie)

Eine MCU zu 100% auszunutzen ist nie sinnvoll. Das ist ein reiner Hack. 
Der Attiny10 war auch damals nicht die günstigste MCU, aber dafür der 
kleinste ATtiny.

Hier gibt es ein WS2812 Beispiel für eine $0.03 MCU:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain/examples/WS2812_blinky

USB werde ich wohl erst einmal sein lassen :)

[Stephan (Gast)]

Praktiker schrieb:
> Noch "geiler" ;-) wäre natürlich ein gut und tiefgehend Kommetiertes
> Assemblerprogramm - zumindest für die Hardwarefreaks und Leute die
> wirklich verstehen wollen wie ein µC (hier ein 8 Bit AVR) funktioniert
> und genutzt wird

Wozu? Die Hardwarefreaks könnten das vermutlich sogar weil sie 
Datenblätter verstehen. Die par Chaoten wie ich, die C einfach nicht 
begreifen, brauchen das nicht weil sie es eh in ASM machen. Also wozu? 
Wie und wohin die Bits und Bytes laufen steht im Datenblatt. Zur 
Geschichte wirst Du bei Wikipedia fündig und Grundkurs gibts im Netz 
genug. Zeige mir EINEN ASM Programmierer der ein "tiefgreifend" 
kommentiertes Programm schreibt! Die meisten von denen sehen ein 
Programm nach 10 Jahren, brauchen 10 Minuten und wissen was sie mal 
"verbockt" haben.

[Guest (Gast)]

Boris schrieb:
> Danke, dass du dich als inkompetenter Schwätzer geoutet hast.

Wie hier Anscheinend gefordert. Behauptungen bitte begründen.

Und ich sehe weder das Problem noch einen Fehler in der Behauptung. Eine 
Lookup Tabel ist ja vorhanden. Das PWM auf die notwendige Frequenz 
einstellen (800khz) und beim Interrupt der beim Timerüberlauf ausgelöst 
wird den DC entsprechend der Tabelle aktualisieren (28% für 0 72% für 1)

Pseudocode kann ich mir hoffentlich sparen ;)

Und nur Mal nebenbei war das keine Kritik lediglich meine persönliche 
Meinung und die darf man hier frei äußern.

[Stoer P. (stoerpeak)]

Falk B. schrieb:
> Zum "Spielen" wird es reichen

genau dafür war es ja auch gedacht. Es sollte denen helfen, die Hilfe 
brauchen
und nicht denen die es besser können.

Falk B. schrieb:
> Außerdem funktioniert dein Programm nur mit einer guten Portion Glück

Dann hatte ich das wohl. Es läuft auch auf zwei verschiedenen LED Ringen 
unterschiedlicher Hersteller mit je 24 LEDs und auf einzelnen Chips  die 
handverdrahtet in Reihe hängen.

Begonnen habe ich wie du vorgeschlagen hast mit einem Array wo ich die 
Intensitätswerte zunächst berechnet und dann gesendet habe. Im Zuge der 
Vereinfachung habe ich das dann aber weggelassen und nutze seitdem die 
"Portion Glück"

[Maxim B. (max182)]

Stoer p. schrieb:
> Ansteuerung von WS2812B LEDs erstaunlich einfach

Einfach nur wenn Mikrocontroller nichts anderes macht. Wenn aber, dann 
zwingt diese komische Interface mit cli() - sei() zu hantieren usw.

Ich denke schon, in einem komplexen Projekt ist es besser, wenn man für 
WS2812B separate ATMega nimmt, die von dem Hauptkontroller Befehle mit 
I2C, USART oder SPI bekommt. ATtiny ist hier kaum eine gute Lösung, da 
dort manche Interface fehlen.

[Stoer P. (stoerpeak)]

Maxim B. schrieb:
> Einfach nur wenn Mikrocontroller nichts anderes macht. Wenn aber, dann
> zwingt diese komische Interface mit cli() - sei() zu hantieren usw.

Da stimme ich dir natürlich zu. Im vorliegenden Beispiel steuert der 
ATTiny nur die LEDs,
was aber nicht lange dauert. Die meiste Zeit langweilt er sich in der 
Warteroutine.
Eine einfache Erweiterung des Codes wäre das Einlesen einer IR- oder 
Funkfernbedienung entweder ohne Rücksicht auf Verluste, d.h. das 
Einlesen der Fernbedienung stört das Schreiben auf die LEDs oder man 
sperrt während des Einlesens das Updaten der LEDs.

Das kann aber jeder mit seiner Wunsch-Hardware und guter, besserer oder 
der allerbesten Softwarelösung so realisieren wie er will.
Weitere einfache Beispiele spare ich mir...

Falk B. schrieb:
> Alles in Allem nix, was die Welt noch braucht. Schlechten oder
> mittelmäßigen Code gibt es tonnenweise im Internet.

[Falk B. (falk)]

Maxim B. schrieb:

> Ich denke schon, in einem komplexen Projekt ist es besser, wenn man für
> WS2812B separate ATMega nimmt,

Nö. Die allerwenigsten Projekte steuern tausende LEDs. Wenn man weiß was 
man tut, kann ein AVR problemlos ein paar Dutzend bis weit über hundert 
LEDs ansteuern, auch mit Bitbangning, und nebenher noch SERH viele Dinge 
machen. Ihr tut ja alle so, als ob das die CPU mordmäßig überfordern 
würde. Dem ist nicht so.

Und mit etwas Hirn 2.0 kann man sogar ECHT zeitkritische Sachen 
miteinander verheiraten.

https://www.mikrocontroller.net/topic/goto_post/5248149

[Wolfgang (Gast)]

Falk B. schrieb:
> Außerdem funktioniert dein Programm nur mit einer guten Portion Glück
> mit den richtigen WS2812B, welche WIRKLICH 50us Resetzeit haben!

Welche WS2812B will schon "WIRKLICH 50µs" Resetzeit. In den 
Datenblättern von Worldsemi steht "Above 50μs".

[Maxim B. (max182)]

> Welche WS2812B will schon "WIRKLICH 50µs" Resetzeit. In den
> Datenblättern von Worldsemi steht "Above 50μs".

Stimmt: 280 us sind auch mehr als 50 us:)

Und das stimmt auch: meine Versuche zeigen, daß mit 250 us noch keine 
Funktion, mit 253 ab und zu schief. 280 us machen sichere Arbeit.

[Wolfgang (Gast)]

Maxim B. schrieb:
> Stimmt: 280 us sind auch mehr als 50 us:)

Von WS2812B-V4 haben weder Falk noch der TO etwas geschrieben.
Man sollte schon ins zugehörige Datenblatt gucken.

[Maxim B. (max182)]

Wolfgang schrieb:
> Von WS2812B-V4 haben weder Falk noch der TO etwas geschrieben.

Wenn man WS2812B in China bestellt, kann alles mögliche kommen. Alles 
beschriftet wie WS2812B. So paßt das Programm nicht für alles, was man 
unter "WS2812B" bekommen kann.

[Dieter R. (drei)]

Nachdem sich hier alle gegenseitig um die Ohren schlagen, dass die 
jeweils anderen keine Ahnung haben, wäre es meiner bescheidenen Ansicht 
nach an der Zeit, dass jemand einen vorgeblich/vermeintlich besseren 
Code zur Diskussion stellt. Dann kann man darüber sachgerecht 
diskutieren.

Bisher gibt es hier allerdings nur den Code des TO. Alles andere ist 
forentypische Besserwisserei. Vielleicht berechtigt, aber unbewiesen.

[Stefan F. (Gast)]

Ich war einer von denen, die den nicht verrissen haben.

Unabhängig davon: Hätte ich einen besseren Vorschlag, würde ich ihn hier 
ganz bestimmt nicht zeigen, weil der dann auch verrissen wird.

Mutmaßungen zur Motivation der Meckerei behalte ich lieber für mich.

Jetzt dürft ihr mich dafür beschimpfen.

[Wolfgang (Gast)]

Dieter R. schrieb:
> Nachdem sich hier alle gegenseitig um die Ohren schlagen, dass die
> jeweils anderen keine Ahnung haben, wäre es meiner bescheidenen Ansicht
> nach an der Zeit, dass jemand einen vorgeblich/vermeintlich besseren
> Code zur Diskussion stellt.

Besserer Code heißt was?
µC besser auslasten, Source Code besser lesbar, Code besser portierbar, 
unabhängig vom LED-Controller besser funktionieren, weniger 
Echtzeitanforderungen stellen, ...

Da gibt es viele Kriterien.

[Dieter R. (drei)]

Wolfgang schrieb:

> Besserer Code heißt was?
> µC besser auslasten, Source Code besser lesbar, Code besser portierbar,
> unabhängig vom LED-Controller besser funktionieren, weniger
> Echtzeitanforderungen stellen, ...
>
> Da gibt es viele Kriterien.

Dann leg doch mal deine Kriterien an! Anregungen dazu gibt es in 
diesem Thread ja genug. Alternativ, wenn du keine besseren Ideen hast, 
kannst du ja dem TO ein Dankeschön aussprechen, kann so bleiben, schönes 
Beispiel.

[F. F. (foldi)]

Stefanus F. schrieb:
> würde ich ihn hier
> ganz bestimmt nicht zeigen, weil der dann auch verrissen wird.

Hier würde ich auch nichts mehr zeigen. Bin ja auch kein 
"Berufsprogrammierer".
Aber es ist ja auch mehr die Art, wie man hier fertig gemacht wird.
Manchmal wäre eine andere Wortwahl und ein Beispiel doch ganz einfach 
und alle würden sich freuen.
Vielleicht so: Hey, versuche dies (Beispielcode) doch einmal, damit 
sollte es besser/schneller/kürzerer Code ... (passendes aussuchen) 
klappen.

Aber statt dessen kommen sinngemäß so Sprüche wie: Eh du Schwachmat, was 
ist das für ein Mist!

Wenn der Code das tut, was der µC ausführen soll, dann ist doch alles 
gut.
Dem Controller kannst du von außen nicht ansehen wie verkorkst der Code 
ist, solange alles funktioniert.

[Bernd K. (prof7bit)]

Maxim B. schrieb:
> Einfach nur wenn Mikrocontroller nichts anderes macht. Wenn aber, dann
> zwingt diese komische Interface mit cli() - sei() zu hantieren usw.

Nur die Länge der High-Pulse ist kritisch. Um eine 0 zu schreiben muss 
der High-Puls kürzer als 500ns sein. High-Pulse die länger als 550ns 
sind werden als 1 erkannt. Die Pausen dazwischen (und auch die Länge des 
1-Pulses) dürfen beliebig lang werden (solange man kürzer als die 
Reset-Pause bleibt). Man muss also nur den kurzen Puls mit cli/sei 
schützen damit er niemals länger als 500ns wird, für alles andere kann 
man sich Zeit lassen.

[Stoer P. (stoerpeak)]

Wolfgang schrieb:
> Besserer Code heißt was?
> µC besser auslasten, Source Code besser lesbar, Code besser portierbar,
> unabhängig vom LED-Controller besser funktionieren, weniger
> Echtzeitanforderungen stellen, ...

Hallo Wolfgang,
das bringt es schon ziemlich genau auf den Punkt.

F. F. schrieb:
> Hier würde ich auch nichts mehr zeigen. Bin ja auch kein
> "Berufsprogrammierer".

Da hier aus den genannten Gründen keiner mehr Bock hat etwas zu 
veröffentlichen was ich einfach hätte verwenden können führt dazu es von 
Grund auf selber zu programmieren.
Das doch recht simple Ergebnis habe ich dann veröffentlicht um anderen 
damit weiter zu helfen
Bin davon ausgegangen das das unter Anderem der Sinn dieses Forums ist.
Wenn man sich mit einem Programmierproblem beschäftigt ist man doch froh 
wenn man Beispiele findet,
selbst wenn man nur eine winzige Idee davon für eigene Projekte 
verwendet.

Ich bin nur froh dass ich zu meinen komplexeren Projekten (siehe 
Youtube) keinen Code veröffentlich habe.
Das hätte man bestimnmt alles viel besser machen können.
Die die so etwas gerne nachgebaut hätte gingen dann halt leider leer 
aus.

Anfragen nach den Quellcodes gab es nach der Veröffentlichung der Clips 
jedenfalls massenweise.
Selbst jetzt nach etlichen Jahren erhalte ich immer noch Anfragen dazu 
aus der ganze Welt.

[Maxim B. (max182)]

Stefanus F. schrieb:
> Hätte ich einen besseren Vorschlag, würde ich ihn hier
> ganz bestimmt nicht zeigen

Hier ist meine FUnktion für WS2812B:

// ws2812.h
#include "spi_intern.h"
#define LEDZAHL  3
#define WS2812B_RESET  280

static __inline__ void ws2812_send_byte(u8 data) __attribute__((__always_inline__));

static void ws2812_send_byte(u8 data){
  u8 ctr;

    asm volatile(
    "ldi %0,8        \n\t"
    "loop%=:        \n\t"

    "sbi %2, %3        \n\t"
    "lsl %1          \n\t"
    "dec %0          \n\t"
    "brcs .+2         \n\t"
    "cbi %2, %3       \n\t"
    "rjmp .+0        \n\t"
    "nop          \n\t"
    "cbi %2, %3        \n\t"
    "breq end%=              \n\t"
    "rjmp .+0               \n\t"
    "rjmp .+0               \n\t"
    "rjmp .+0               \n\t"
    "rjmp loop%=             \n\t"
    "end%=:                 \n\t"
    : "=&d" (ctr)
    : "r" (data), "I" (_SFR_IO_ADDR(SPI_INTERN_E_PORT)), "I" (SPI_INTERN_E)
        );
}

// ws2812.c 
#include "ws2812.h"

static u8 myled[LEDZAHL * 3];

void ws2812_send_led(u8 *data, u8 ledzahl){
  u8 temp_sreg;

  temp_sreg = SREG;
  cli();

  spi_intern_outadr(LED_ADR);
  spi_intern_start();         // = 0
  _delay_us(WS2812B_RESET);

  for(u8 i=0;i<(ledzahl * 3);i++){
    ws2812_send_byte(*data++);
  }
  

  _delay_us(WS2812B_RESET);
  
  spi_intern_stop();       // = 1

  SREG = temp_sreg;
}


void ws2812_send_myled(void){

  ws2812_send_led(myled,(LEDZAHL * 3));
}

void ws2812_set_led(u8 lednummer, u8 ledr, u8 ledg, u8 ledb){
  myled[(lednummer * 3)+1] = ledr;
  myled[lednummer * 3] = ledg;
  myled[(lednummer * 3)+2] = ledb;
}

[Tim . (cpldcpu)]

Ich gebe jetzt mal ein ganz gemeines Statement ab: Jede Variante, die 
bedingte Sprünge für 0 und 1 braucht ist suboptimal.

Das ganze Problem reduziert sich darauf, zu einem Zeitpunkt eine 0 
auszugeben oder nicht. Ist seit ca 6 Jahren auch im Wiki und den 
verlinkten Artikeln erklärt.

https://github.com/cpldcpu/light_ws2812/blob/4894d1cd0e25e7c5f16379a7ca0d8f23370963b0/light_ws2812_AVR/Light_WS2812/light_ws2812.c#L119

asm volatile(
    "       ldi   %0,8  \n\t"
    "loop%=:            \n\t"
    "       out   %2,%3 \n\t"    //  '1' [01] '0' [01] - re
< nops für timing >
    "       sbrs  %1,7  \n\t"    //  '1' [03] '0' [02]
    "       out   %2,%4 \n\t"    //  '1' [--] '0' [03] - fe-low
    "       lsl   %1    \n\t"    //  '1' [04] '0' [04]
< nops für timing >
    "       out   %2,%4 \n\t"    //  '1' [+1] '0' [+1] - fe-high
< nops für timing >
    "       dec   %0    \n\t"    //  '1' [+2] '0' [+2]
    "       brne  loop%=\n\t"    //  '1' [+3] '0' [+4]
    :  "=&d" (ctr)

Auf den Padauk MCUs, die noch einmal fürs bitgefrickle optimiert sind, 
geht es sogar noch einfacher:

https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_WS2812.c

10$:
  sl      _PDK_WS2812_writebyte_PARM_1+0     ;0
  set1   s(WS2812_PORT),#(WS2812_PIN)   ;1
  swapc  s(WS2812_PORT),#(WS2812_PIN)   ;2
  set0   s(WS2812_PORT),#(WS2812_PIN)   ;3  
  dzsn   a                 
  goto    10$                           ;6

[Tim . (cpldcpu)]

Maxim B. schrieb:
> Stefanus F. schrieb:
>> Hätte ich einen besseren Vorschlag, würde ich ihn hier
>> ganz bestimmt nicht zeigen
>
> Hier ist meine FUnktion für WS2812B:
>

>
>

Kommt mir von hier bekannt vor:

https://github.com/cpldcpu/light_ws2812/blob/be6ded82cab67c8c9d136596745200b6ee2ab28f/light_ws2812_AVR/light_ws2812.c#L67

Warum nicht gleich die neue Version nehmen? Die passt sich automatisch 
an F_CPU an. Scheint auch einigermaßen Stabil zu sein, da seit Jahren 
keine echten Bugs mehr reportet wurden.

https://github.com/cpldcpu/light_ws2812

[Maxim B. (max182)]

Statt nops besser rjmp .+0 und lpm. Gleiche Aufwand (2 bytes), aber 
statt 1 Takt bei nop gleich 2 oder 3. So kamm man Flash sparen. lpm wird 
zufällige Inhalt in r0 laden, aber r0 darf man in GCC immer beliebig 
ändern.

Tim  . schrieb:
> Jede Variante, die
> bedingte Sprünge für 0 und 1 braucht ist suboptimal.

Ohne Sprünge kann man cbi und sbi nicht nutzen, nur out. Da aber auf dem 
PORT bestimmt noch andere Dinge hängen, ist out nicht optimal: statt 
einfach sbi oder cbi (ohne Wirkung auf SREG) sollte man dann in - 
register maskieren - out machen.

[Tim . (cpldcpu)]

Maxim B. schrieb:
> Statt nops besser rjmp .+0 und lpm. Gleiche Aufwand (2 bytes), aber

Die Library generiert automatisch die optimale Kombination von rjmp und 
nop

Maxim B. schrieb:
> Ohne Sprünge kann man cbi und sbi nicht nutzen, nur out. Da aber auf dem
> PORT bestimmt noch andere Dinge hängen, ist out nicht optimal: statt

Allerdings es sowieso nicht möglich, während des Schreibens auf den 
WS2812 port etwas Anderes parallel zu bearbeiten. Damit ist es 
eigentlich egal.

[Falk B. (falk)]

Dieter R. schrieb:
> Nachdem sich hier alle gegenseitig um die Ohren schlagen, dass die
> jeweils anderen keine Ahnung haben, wäre es meiner bescheidenen Ansicht
> nach an der Zeit, dass jemand einen vorgeblich/vermeintlich besseren
> Code zur Diskussion stellt. Dann kann man darüber sachgerecht
> diskutieren.
>
> Bisher gibt es hier allerdings nur den Code des TO.

Mit dem sinnerfassenden Lesen hast du es nicht so, oder?

Beitrag "Re: Ansteuerung von WS2812B LEDs erstaunlich einfach"

> Alles andere ist
> forentypische Besserwisserei. Vielleicht berechtigt, aber unbewiesen.

Jaja.

[Falk B. (falk)]

Bernd K. schrieb:
> Nur die Länge der High-Pulse ist kritisch. Um eine 0 zu schreiben muss
> der High-Puls kürzer als 500ns sein. High-Pulse die länger als 550ns
> sind werden als 1 erkannt. Die Pausen dazwischen (und auch die Länge des
> 1-Pulses) dürfen beliebig lang werden (solange man kürzer als die
> Reset-Pause bleibt). Man muss also nur den kurzen Puls mit cli/sei
> schützen damit er niemals länger als 500ns wird, für alles andere kann
> man sich Zeit lassen.

FALSCH!!!

Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

[Maxim B. (max182)]

Tim  . schrieb:
> Damit ist es
> eigentlich egal.

Nicht egal, wenn du andere Portpins änderst, die andere Funktionen 
machen.

[Tim . (cpldcpu)]

Maxim B. schrieb:
> Nicht egal, wenn du andere Portpins änderst, die andere Funktionen
> machen.

Das lässt sich relativ einfach vermeiden. Siehe oben verlinken Code.

[Maxim B. (max182)]

Tim  . schrieb:

> Das lässt sich relativ einfach vermeiden. Siehe oben verlinken Code.

Stell dir vor: an einem anderen Pin ist ein Zünder angeschlossen, und 
beim Schreiben in WS2812 aktivierst du ihn zufällig. ;)

[Tim . (cpldcpu)]

Maxim B. schrieb:
> Tim  . schrieb:
>
>> Das lässt sich relativ einfach vermeiden. Siehe oben verlinken Code.
>
> Stell dir vor: an einem anderen Pin ist ein Zünder angeschlossen, und
> beim Schreiben in WS2812 aktivierst du ihn zufällig. ;)

Dafür sollte man dann besser keinen AVR nehmen, sondern eine MCU, die 
für so etwas geeignet ist :)

Allerdings ist es wirklich kein Problem, damit umzugehen. Man muss das 
Portregister vorher auslesen und daraus entsprechende Masken berechnen.

Dein Code oben stammt vom ersten Release der Light_WS2812 Library. 
Danach ist noch einiges passiert. Seit ca. 3-4 Jahren ist sie aber 
stabil.

[Herr M. (herrmueller)]

Maxim B. schrieb:
> Statt nops besser rjmp .+0 und lpm. Gleiche Aufwand (2 bytes), aber
> statt 1 Takt bei nop gleich 2 oder 3. So kamm man Flash sparen. lpm wird
> zufällige Inhalt in r0 laden, aber r0 darf man in GCC immer beliebig
> ändern.
>
In Assembler mach ich Verzögerungen mit RCALL auf ein RET in der Nähe. 
Das braucht 7 Takte und verändert nichts.

[Maxim B. (max182)]

Herr M. schrieb:
> RCALL auf ein RET in der Nähe.
> Das braucht 7 Takte und verändert nichts.

Und Stack? Das finde ich nicht wünschenswert, mit Stack ohne 
Notwendigkeit zu hantieren. 2 bytes geben 7 Takte. 2x lpm brauchen auch 
2 bytes und geben 6 Takte, dafür weniger gefährlich: rjmp +0 und lpm 
verändern wirklich nichts (da r0 in GCC jederzeit geändert sein darf).

[Bernd K. (prof7bit)]

Falk B. schrieb:

> FALSCH!!!
>
> Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

Was soll falsch sein? Kannst Du das mal konkretisieren anstatt 
kommentarlos auf eine Mauer aus Text zu verlinken? Das was ich schrieb 
ist hab ich mir schließlich nicht zwischen Tür und Angel mal eben aus 
den Fingern gesaugt sondern es beruht auf den Ergebnissen der Arbeit 
anderer: 
https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ 
und ich hab viel Zeit damit verbracht das zu verifizieren, das Timing zu 
verändern um zu sehen ob das der Wahrheit entspricht und das was 
Josh.com sagt ist zu 100% zutreffend. Ich habe es seit mehreren Jahren 
zuverlässig im Einsatz.

[Wolfgang (Gast)]

Maxim B. schrieb:
> Und Stack? Das finde ich nicht wünschenswert, mit Stack ohne
> Notwendigkeit zu hantieren.

Das hat nichts mit wünschenswert zu tun.
Wenn im RAM/Stack sicher noch ausreichend Platz ist und der Flash so 
weit ausgereizt ist, dass es auf 4 eingesparte Bytes an kommt, können 
solche Konstrukte durchaus sinnvoll sein ;-)

[Stefan F. (Gast)]

F. F. schrieb:
> Aber es ist ja auch mehr die Art, wie man hier fertig gemacht wird.

Ja. Ich bin für Verbesserungsvorschläge immer dankbar und gewisse 
Meinungsverschiedenheiten sind legitim. Nur die Art wie hier kritisiert 
wird, bestätigt die "Verrohung", die nicht nur Politker und Forscher 
zunehmend beklagen.

[Stefan F. (Gast)]

Stoer p. schrieb:
> Das doch recht simple Ergebnis habe ich dann veröffentlicht um anderen
> damit weiter zu helfen
> Bin davon ausgegangen das das unter Anderem der Sinn dieses Forums ist.

Ist es auch. Ich freue mich über die fülle frei verfügbarer 
Informationen. Deswegen mache ich dabei im Allgemeinen gerne mit, so wie 
du. Nur in diesem Thread halt nicht mehr.

[Stefan F. (Gast)]

Maxim B. schrieb:
> Hier ist meine Funktion für WS2812B

Danke Maxim. Ich glaube, in dieser Diskussion geht es im Kern darum, 
dass die CPU die ganze Zeit durch Warteschleifen voll ausgelastet ist 
und somit kein Multitasking zulässt.

In deinem Code ist dieser Knackpunkt ebenso enthalten, sehe ich das 
richtig?

[Stefan F. (Gast)]

Tim  . schrieb:
> Allerdings es sowieso nicht möglich, während des Schreibens auf den
> WS2812 port etwas Anderes parallel zu bearbeiten.

Die ESP8266 Bibliotheken kriegen das aber hin - zwangsläufig, denn der 
WLAN Stack würde sonst ausfallen -> Watchdog reset. Soweit ich weiss 
wird dort wahlweise eine UART oder eine I²S Schnittstelle (+DMA) 
missbraucht, um die Signale zu erzeugen.

[Tim . (cpldcpu)]

Stefanus F. schrieb:
> Tim  . schrieb:
>> Allerdings es sowieso nicht möglich, während des Schreibens auf den
>> WS2812 port etwas Anderes parallel zu bearbeiten.
>
> Die ESP8266 Bibliotheken kriegen das aber hin - zwangsläufig, denn der
> WLAN Stack würde sonst ausfallen -> Watchdog reset. Soweit ich weiss

Der Kommentar bezog sich auf AVR. Bei Mikrocontrollern mit DMA ist es 
meist möglich, eine Methode zu finden, die CPU-unabhängig ist.

Mit der CCL (configurable custom logic) in den neuen ATtiny geht es auch 
ohne bitbanging.

[Stefan F. (Gast)]

Tim  . schrieb:
> Der Kommentar bezog sich auf AVR. Bei Mikrocontrollern mit DMA ist es
> meist möglich, eine Methode zu finden, die CPU-unabhängig ist.

Wenn ESP8266 das mit einer UART machen können, dann ein AVR ebenso 
(glaube ich jedenfalls). Deswegen habe ich das geschrieben.

Dass der ESP8266 Code auch die I²S Schmittstelle mit DMA nutzen kann, 
habe ich nur der Vollständigkeit halber erwähnt.

SPI soll auch gehen.

[Maxim B. (max182)]

Stefanus F. schrieb:
> In deinem Code ist dieser Knackpunkt ebenso enthalten, sehe ich das
> richtig?

Das ist leider durch Interface WS2812B bestimmt: zu kleine 
Verzögerungen, um sie mit ISR und Timer zu machen. Und nichts was man 
mit USART oder I2C / SPI erledigen kann (na gut, mit USART vielleicht, 
aber auch nicht ohne...).

Wenn die Bastler aus China auf ihre hauseigene Interface setzen, was 
bleibt uns übrig? Ich sehe nur eine Möglichkeit: eine ATMega extra für 
diese LED zu opfern (ATMega88PA kostet unter 2 €). Dann kann man für 
Kommunikation Interface benutzen, das in System favorisiert ist (z.B. 
SPI oder I2C).

[Wolfgang (Gast)]

Stefanus F. schrieb:
> Wenn ESP8266 das mit einer UART machen können, dann ein AVR ebenso
> (glaube ich jedenfalls).

Und wie sollen Start- und Stopbits des UART-Ausgangs in den Datenstrom 
für die LED-Controller reinpassen?

[Maxim B. (max182)]

Wolfgang schrieb:

> Und wie sollen Start- und Stopbits des UART-Ausgangs in den Datenstrom
> für die LED-Controller reinpassen?

USART sollte dafür natürlich invertiert werden. Auch keine Arbeit mit 
ISR von USART möglich: die Pausen werden zu groß. So gewinnt man mit 
USART praktisch nichts. Dafür wird man an bestimmten Pin gebunden, und 
noch Inversion notwendig.

[Bernd K. (prof7bit)]

Maxim B. schrieb:
> die Pausen werden zu groß

Die Pause zwischen 2 Bits darf nur 5µs nicht übersteigen. Bei 16 MHz 
sind das 80 Zyklen, das wird doch wohl reichen für nen Interrupt der das 
nächste Byte in den UART schreibt? Außerdem darf man das nächste Byte ja 
schon schreiben während das jetzige noch sendet!

[Joachim B. (jar)]

Stefanus F. schrieb:
> Unabhängig davon: Hätte ich einen besseren Vorschlag, würde ich ihn hier
> ganz bestimmt nicht zeigen, weil der dann auch verrissen w

ach komm, du hast schon was hier gezeigt was verrissen wurde (Leitwert 
von Kupfer, Silber), ich übrigens auch (Code).

Aber man lernt auch durch Fehler also ist Zeigen nur ein Mittel um 
besser zu werden, zu seinen Fehler kann man doch stehen!

Da du öfter deine Dienste für 20,-€ pro Stunde anbietest solltest du 
auch Interesse haben besser zu werden für deine Kunden.

[Stefan F. (Gast)]

Joachim B. schrieb:
> ach komm,

Selbst wenn ich wollte, ich habe hier nichts zum Vorzeigen. Aber wie 
gesagt, ich würde es hier nicht veröffentlichen.

[bst (Gast)]

AppNote AN2387

This Application Note describes the use of Core Independent Peripherals 
(CIP), how to use the Configurable Custom Logic (CCL) to filter inputs 
from different sensors, and how to create specific communication 
protocols using a Microchip AVR device, a Passive InfraRed sensor (PIR), 
Ambient Light Sensor, and 16 addressable RGB LEDs.

https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en595063

mfg

[bst (Gast)]

Code Bsp.

WS2812B mit Attiny817 Hardware ansteuern

Beitrag "WS2812B mit Attiny817 Hardware ansteuern"

mfg

[Stefan F. (Gast)]

bei Youtube kann man viele Videos mit 4-Stelligen 7-Sgement Anzeigen 
sehen. Die sind teilweise schon im abgedunkelten Raum gemacht worden.

Dann habe ich noch dieses gefunden: 
https://www.youtube.com/watch?v=jqujSO1Fbsg
Da wurden 8 Anzeigen pro Chip verwendet. Sieht nicht überzeugend aus, 
wenn du mich fragst. Wenn die Sonne zum Fenster rein scheint, sieht man 
vermutlich gar nichts mehr.

[Joachim B. (jar)]

Stefanus F. schrieb:
> ich habe hier nichts zum Vorzeigen. Aber wie
> gesagt, ich würde es hier nicht veröffentlichen

OK zum Teil verstehe ich dich ja, aber du verweist ja immer auf deine 
Homepage, wer also ein Haar in der "Suppe" finden will findet es.
Besser zu werden kann aber nur gelingen wenn mehr Augen auf etwas 
schauen und man daraus lernt, wenn du nun verweigerst schadest du nur 
dir selbst oder evtl. deinen Kunden die dir 20,-€/h zahlen.

[Stefan F. (Gast)]

Kann bitte ein Moderator meinen Obigen Beitrag zur 7-Segment Anzeige 
(Beitrag "Re: Ansteuerung von WS2812B LEDs erstaunlich einfach") löschen? Der ist 
versehentlich im falschen Thread gelandet.
Vielen Dank

[Stefan F. (Gast)]

Joachim B. schrieb:
> Besser zu werden kann aber nur gelingen wenn mehr Augen auf etwas
> schauen und man daraus lernt

Da bin ich total bei Dir. Dafür ist dieses Forum hier einfach nur 
großartig. Man kann hier sehr viel von der Erfahrung anderer lernen und 
es ist wirklich gut, dass die allermeisten Leute hier ihr Wissen gerne 
und bereitwillig teilen.

Ich bin ganz sicher, dass ich hier mehr gelernt habe, als in meiner 
Berufsausbildung. Dafür bin ich sehr dankbar und im Gegenzug bemühe auch 
ich mich zu helfen. Manchmal zu eifrig, das ist mir bewusst und daran 
möchte ich arbeiten.

Es hapert meiner Meinung nach nur an den Umgangsformen. Man muss hier 
schon ein dickes Fell haben.

[bst (Gast)]

> Stefanus F. (Firma: Äppel) (stefanus)
>  .. Es hapert meiner Meinung nach nur an den Umgangsformen ...

bzw krankt an plapperndern waschweibern welche inhalslos threads 
zumüllen .

[Stoer P. (stoerpeak)]

Bei der Veröffentlichung des Codes ging es mir mehr darum,
ein komplettes Programm abzuliefern und nicht nur um die Routine
(deren zig mögliche Varianten hier diskutiert werden) die die 8Bit aus 
dem Portpin herausschiebt.
Das "erstaunlich einfach" im Titel bezieht sich eher auf den recht 
kleinen Aufwand der nötig ist,
um den sich bewegenden Regenbogeneffekt zu erzeugen.

Bleibt nur noch zu erwähnen, dass die Clockselect Fuse auf PLLCLK_... 
zu setzen ist.