Lightweight WS2811/WS2812 Library

[Tim . (cpldcpu)]

Hallo zusammen,

da mir die bisherigen Ansätze zur Ansteuerung der WS2812 RGB-LEDS zu 
umständlich (Timergefrickel), zu speziell (Arduino, 100% ASM, C++) oder 
zu groß waren, habe ich noch einmal von vorne angefangen.

Bisher sieht es recht vielversprechend aus. Mit einem reinen 
Bitbanging-Ansatz lassen sich auch auf einem 8MHz AVR ohne 
Loop-Unrolling die notwendigen Timings erreichen. Die compilierte 
C-Routine ist bisher gerade einmal 34 bytes groß.

Bisher habe ich nur an einer einzelnen LED testen können. Hat jemand 
Lust, den Code auch einmal an einem LED-Streifen zu testen?

Die Nutzung ist ziemlich einfach:
- AVR auf 8Mhz konfigurieren. Sollte auf allen außer XMEGA und Attiny 
4/5/9/10/20/40 laufen.
- Code mit Optimierungen compilieren (Mind. -O1)
- Portaddresse und Pin in die Defines eintragen.
- Der Routine eine Addresse auf ein Farb-Array (3 Bytes pro LED, 
Reihenfolge GRB) sowie die Länge des Arrays übergeben.
- Nach jedem Update mindesten 50µs warten.

Ich habe vor, das ganze als Library zu verpacken und auch noch an andere 
Taktgeschwindigkeiten anzupassen.

/*
  Timing optimized for 8Mhz AVR (excl. XMEGA and reduced instruction set)

  The total length of each bit is 1.25µs (10 cycles @ 8Mhz)
  * At 0µs the dataline is pulled high.  (cycle 4)
  * To send a zero the dataline is pulled low after 0.375µs (4+3=7 cycles).
  * To send a one the dataline is pulled low after 0.625µs (4+5=9 cycles).

  10 cycles can not be reached without loop unrolling, or by using byte
  writes to the ports. However since critical the timing between the rising and 
  falling edge is correct, it seems to be acceptable to slightly increase 
  bit timing
  
  Final timing: 
  * 11 cycles for bits 7-1
  * 17 cycles for bit 0    
*/

#define ws2812_port 0x18  // Number of the data port register
#define ws2812_pin 4    // Number of the data out pin


void ws2812_sendarray_8Mhz(uint8_t *data,uint16_t datlen)
{
  uint8_t curbyte,ctr;
  
  while (datlen--) {
    curbyte=*data++;
    
    asm volatile(
    "    ldi  %0,8    \n\t"   
    "loop%=:lsl  %1      \n\t"   
    "    dec  %0      \n\t"    
    "    sbi  %2,  %3    \n\t"   
  
    "    brcs .+2    \n\t"   
    "    cbi  %2,  %3    \n\t"    
                   
    "    brcc .+2    \n\t"   
    "    cbi  %2,  %3    \n\t"   
    "    brne loop%=    \n\t"   
    :  "=&d" (ctr)
    :  "r" (curbyte), "I" (ws2812_port), "I" (ws2812_pin)
    );
    
    // loop overhead including byte load is 6+1 cycles
  }
}

[Tim . (cpldcpu)]

Hier übrigens die inner-loop mit Taktzyklen. Etwas frickelig war die 
unterschiedliche Laufzeit der Sprungbefehle. So wie es jetzt 
implementiert ist, heben sich die Verzögerungen beider Befehle 
gegenseitig auf.

Bei 8Mhz funktioniert das ganze nur, weil die Dauer der "Low" Periode 
anscheinend relativ unkritisch ist. Theoretisch könnte man durch 
Loop-Unrolling das Timing auch vollständig korrekt umsetzen können - 
aber so lange das nicht notwendig ist...

[code]
        "    ldi  %0,8       \n\t"    // 0

        "loop%=:lsl  %1      \n\t"    // 1     Datenbit ins Carry
        "    dec  %0         \n\t"    // 2     Schleifenzähler in Z-Flag
        "    sbi  %2,  %3    \n\t"    // 4

        "    brcs .+2        \n\t"    // 5l / 6h
        "    cbi  %2,  %3    \n\t"    // 7l / -    Überspringen bei C=1
                                      // 7l / 6h
        "    brcc .+2        \n\t"    // 9l / 7h
        "    cbi  %2,  %3    \n\t"    // -  / 9h   Überspringen bei C=0
        "    brne loop%=     \n\t"    // 11 loop /10nt  Weiter, wenn Z=1
[code]

[Matthias H. (hallamen)]

Die Routine funktioniert bei mir mit 12 Leds einwandfrei, danke dafür!
Ich finde diesen Ansatz ohne Timer ganz praktisch (vor allem, wenn nur 
wenige Leds gesteuert werden sollen).

Ich habe deine Funktion auf 16MHz 'verlängert', vielleicht kanns ja 
jemand brauchen. Diese wurde ebenfalls an 12 Leds getestet.

#define ws2812_port 0x18  // Number of the data port register
#define ws2812_pin 4    // Number of the data out pin

void ws2812_sendarray_16Mhz(uint8_t *data,uint16_t n)
{
  uint8_t curbyte,ctr;
  
  while (n--) {
    curbyte=*data++;
    
    asm volatile(
        "    ldi  %0,8       \n\t"    // 0
        "    nop\n\t"

        "loop%=:lsl  %1      \n\t"    //  1     Datenbit ins Carry
        "    dec  %0         \n\t"    //  2     Schleifenzähler in Z-Flag
        "    sbi  %2,  %3    \n\t"    //  4

        "    nop\n\t"                  //  5 
        "    nop\n\t"                  //  6

        "    brcs .+2        \n\t"    //  7l / 8h
        "    cbi  %2,  %3    \n\t"    //  9l / -    Überspringen bei C=1

        "    nop\n\t"                  // 10l /  9h
        "    nop\n\t"                  // 11l / 10h
        "    nop\n\t"                  // 12l / 11h
        "    nop\n\t"                  // 13l / 12h
 
        "    brcc .+3        \n\t"    // 15l / 13h
        "    cbi  %2,  %3    \n\t"    // -  / 15h   Überspringen bei C=0

        "    nop\n\t"                  // 16 
        "    nop\n\t"                  // 17 
        "    nop\n\t"                  // 18 
        "    nop\n\t"                  // 19 

        "    brne loop%=     \n\t"    // 11 loop /10nt  Weiter, wenn Z=1

    :  "=&d" (ctr)
    :  "r" (curbyte), "I" (ws2812_port), "I" (ws2812_pin)
    );
    
    // loop overhead including byte load is 6+1 cycles
  }
}

[Tim . (cpldcpu)]

Hallo Matthias,

freut mich, dass die Routine für Dich nützlich ist und auch mit mehr als 
einer LED funktioniert. Das hat mich glatt motiviert, den aktuellen 
Stand der Library zu veröffentlichen. Ich habe in der Zwischenzeit den 
Code auch noch für eine Reihe anderer Taktgeschwindigkeiten angepasst.

Download hier: 
https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812

light_ws2812
============

Light wight library to control WS2811/WS2812 based LEDS and LED Strings for 8-Bit AVR microcontrollers.



Description
===========

This is a small Ansi-C library to control WS2811/WS2812 based RGB Leds and strings. Only the 800kHz
high-speed mode is supported. This library uses a bit-banging approach with cycle optimized assembler
innerloops. Some advantages of this approach compared to existing solutions are:

  * Compatible to all AVR MCUs since it does not rely on special periphery.
  * Low hardware footprint: Does not rely on any timer or the USI
  * Low software footprint: Size optimized assembler without unrolled loops (<50 bytes in most cases)
  * No configuration needed
  * Supports reduced core AVR such as Attiny 4/5/9/10
  * Arduino or C++ not required

A disadvantage of this approach is that the code has to be hand optimized for each cpu clock. However,
a number of different routines are provided with support cpu clocks from 8Mhz to 16Mhz (standard AVR)
or 4MHz to 8Mhz (reduced core).

Usage
=====

- Add "light_ws2812.c" and "light_ws2812.h" to your project
- Change ws2812_port and ws2812_pin in the include file according to the I/O pin you are using.
- Uncomment the #define appropiate for your CPU core and clock settings. If you exact clock is
  not supported, try a higher or lower clock setting. The WS2811 controller chip is tolerant to
  some timing inaccuracy.
- Please use at least optimizations settings -O1 to compile.

A simple example is provided as "test_rgb_blinky.c"

Release History
================

v0.3 2013/05/06 - Initial release

Please find updates on https://github.com/cpldcpu/light_ws2812

bug reports etc: [e-mail]

[Fallobst (Gast)]

Ein paar Anmerkungen:

- Was spricht gegen dirketes schreiben auf die Ports? Damit kann das 
Timing ab 8 Mhz ohne Loop-unrolling eingehalten werden 
(Beitrag "Re: C komisches Verhalten"). PWM-Ausgänge und 
andere Peripherie wird durch die Port-Register nicht beeinflusst. 
Interrupts müssen sowieso gesperrt werden. Ich sehe keinen Nachteil 
dabei. Mit dem direkten Schreiben könntest du deine Lib wahrscheinlich 
allgmein noch etwas optimieren.
- mehrere nops kann man zusammenfassen um Speicherplatz zu sparen :
  2xnop = rjmp .+2
  3xnop = lpm (wobei r0 zerstört wird)

[Tim . (cpldcpu)]

Hallo Fallobst,

vielen Dank für die Anmerkungen! Ich habe, basierend auf Deinem Input, 
gleiche eine v0.4 erstellt.

- Code durch rjmp verkürzt.
- Die Interrupts werden jetzt optional gesperrt.

Direktes Schreiben habe ich allerdings noch nicht implementiert. Ein 
Nachteil ist nämlich längerer Code und die Benutzung von mehr Registern. 
Bis 8Mhz funktioniert es noch ohne, auch ohne Loop-Unrolling. Auf den 
reduced core AVR benötigen CBI/SBI nur einen Taktzyklus, so dass man 
dort generell keinen Vorteil hat. Direktes Schreiben hilft m.E. nur bei 
<8Mhz auf den normalen Cores. Dafür werde ich bei Gelegenheit noch eine 
Routine implementieren...

[Tim . (cpldcpu)]

Ach ja - hier ist die v0.4:

https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812

[Tim . (cpldcpu)]

Ich habe noch einen Bug im Timing gefunden, der sich durch die 
Optimierungen mit eingeschlichen hatte. Interessanterweise hat der Code 
trotzdem funktioniert...

v0.5 jetzt hoffentlich wieder fehlerfrei:

https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812

[Tim . (cpldcpu)]

Ich habe eben v0.6 hochgeladen. Die neue Version unterstützt beliebige 
Pins auf einem Port durch Bitmasken. Außerdem wird jetzt 4 Mhz auch auf 
den normalen AVRs unterstützt.

https://github.com/cpldcpu/light_ws2812

  - Major update: Changed all port accesses from SBI/CBI to OUT. This removes
    a timing inconsistency between reduced core AVR and standard AVR,
    avoiding separate implementations for different cores. A disadvantage is
    increased register usage.
  - Added a "ws2813_sendarray_mask" function which allows to pass a bitmask
    for the selected port. This allows controlling up to 8 independent LED
    strips.
  - Removed functions for interrupt handling. Avoiding interference with
    interruprs is now up to the user. 
  - 4 MHz clock speed is now also supported for standard core AVRs.
  - 12 MHz implementation is still untested

[Mario P. (mariopieschel)]

In den Teilen für 8MHz und 12MHz ist ein kleiner Fehler:

Zeile 138 " brvs exit%=  \n\t"  // 14
und
Zeile 191 " brvs exit%= \n\t"  // 11

nicht "brvs" sondern "brcs"
Das Carry-Flag abfrage nicht Overflow.
So benötigt ein Durchlauf 1/2s.

Übrigens geht auch die 9,6MHz-Variante bei 8MHz.

Super Arbeit, hat mir viel Zeit gespart.

[Tim . (cpldcpu)]

Hallo Mario,

ups, guter Punkt. Erstaunlich dass die LEDs das ohne Glitches mitgemacht 
haben. Das Protokoll ist eben doch robuster als man denkt. Habe es 
gleich gefixed und v0.8 hochgeladen.

https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812

- v0.7 2013/05/28
  - Optimized timing and size of 8 and 12 Mhz routines. All routines are within 
    datasheet specs now, except of 9.6 Mhz which is marginally off but works under
    all test conditions.  
- v0.8 2013/06/03
  - 9.6 Mhz implementation now within timing specifications.
  - brvs->brcs. Loops terminate correctly (thanks to Mario Pieschel).

[Tim . (cpldcpu)]

>Übrigens geht auch die 9,6MHz-Variante bei 8MHz.

Ja, es gehen so einige Dinge, die laut Datenblatt nicht erlaubt sind :) 
Aber es kann ja immer sein, dass man mal eine Bauteilecharge erwischt, 
die etwas weniger tolerant ist. Die v0.8 schafft es immerhin jetzt für 
alle Taktgeschwindigkeiten das Timing nach Datenblatt einzuhalten. Das 
ist bei den meisten anderen Lösungen nicht so (FastSPI-lib etc.)

[Nils N. (hagbard)]

Vielen vielen Dank für die Lib!
Hat mir gerade sehr geholfen meine Stripes zu testen.
Es blinkt mit 40 LEDs ohne Probleme auf einem Atmega32 mit 16 MHz :-)
Bei mehr steigt er aus, ob wegen zu viel Strom oder Timing, kann ich 
gerade nicht sagen.

Beitrag "Re: [Mitbestellung] SMD5050 RGB-LED mit integriertem 8-bit PWM Controller"

[Tim . (cpldcpu)]

Hi Nils,

freut mich dass es so gut klappt!

Man kann evtl. recht einfach überprüfen, ob es am Strom liegt: Reduziere 
doch einfach mal die Anzahl der angeschalteten LEDS und die Helligkeit. 
Wenn Du dann mehr ansteuern kannst ist die Situation relativ klar. Eine 
LED zieht bei voller Helligkeit ca 60mA. Pro USB Port sind da eigentlich 
nicht mehr als 10 LEDs drin...

Ansonsten würde ich auch defekte LEDS nicht komplett ausschließen. 
(Damit hatte ich bei meinen handgelöteten Strips zu kämpfen.)

[Nils N. (hagbard)]

Liegt wohl am Strom.
Der 4m Stripe (240 LEDs!) geht, wenn ich z.B. eine LED durchlaufen 
lasse.
Muss aber fürs Schreiben auf die LEDs die Interrupts sperren, sonst hab 
ich Disco...

cli();
ws2812_sendarray(&led[0],3*WS2812_LEDCOUNT);
sei();

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Nils Nachname schrieb:
> Muss aber fürs Schreiben auf die LEDs die Interrupts sperren, sonst hab
> ich Disco...

Wenn du dir das Sperren nicht leisten willst, ist es vllt. besser den 
Library Aufruf selbst in einen (Timer?)Interrupt zu tun. Dann ist sicher 
gestellt, das er nicht unterbrochen wird und Sperren ist unnötig.

[Tim . (cpldcpu)]

Ich habe es mit meinem 4m String auch getestet: Bei niedrigster 
Helligkeit (RGB= {0,0,1}) kann man mit einem USB Port den ganzen 
Streifen mit 240 LEDs betreiben. Bei voller Helligkeit ist nach ca 20 
LEDs Schluss.

[Tim . (cpldcpu)]

Das man Interrupts während des Sendens verhindern muss sollte eigentlich 
klar sein. Etwas "professioneller" geht es mit <util/atomic.h>. Der 
erzeugte Code ist am Ende jedoch der gleiche wie im Beispiel von Nils.

#include <util/atomic.h>

ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
     ws2812_sendarray(..);
}

[Nils N. (hagbard)]

Matthias Sch. schrieb:
[...]
> Wenn du dir das Sperren nicht leisten willst, ist es vllt. besser den
> Library Aufruf selbst in einen (Timer?)Interrupt zu tun. Dann ist sicher
> gestellt, das er nicht unterbrochen wird und Sperren ist unnötig.

Für einen Timerinterrupt ist mir das Senden dann doch zu viel/lang bei 
240 LEDs.
Obwohl ich gerade gar nicht genau weiß, wie lang es eigentlich dauert.

Aber die 4m waren auch nur zum Testen der LEDs... obwohl... man weiß ja 
nie. ;-)

[chris (Gast)]

Sehr schön :-) Das gefällt mir deutlich besser als die FastSPI des 
Arduino.

Nur: vielleicht sollte man den Thread in die Codesammlung schieben, dort 
findet man Codestücke besser.

[Peter K. (peterka2000)]

Bei mir zeigt es an: expected ; before led_buffer. Mein Code:

#define F_CPU 8000000
#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>
#include "light_ws2812.h"

struct CRGB{uint8_t green; uint8_t red; uint8_t blue; };
struct CRGB led_buffer[1];

int main(void){
  
  while(1){
    led_buffer[0].red = 0;
    led_buffer[0].green = 255
    led_buffer[0].blue = 0;
    ws2812_sendarray(&led_buffer[0], 3);
    _delay_ms(300);
  }
  return 0;
}

[Christian H. (ch-hunn)]

Peter K. schrieb:

> Bei mir zeigt es an: expected ; before led_buffer. Mein Code:

> led_buffer[0].green = 255

 Ja logisch, denn dieser Zeile fehlt zum Schluss ein Semikolon ;-)

[Peter K. (peterka2000)]

Wenn man zu blöd ist, sich den Code nochmal anzugucken ...

[Peter K. (peterka2000)]

Wenn ich jetzt aber

#define F_CPU 8000000
#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>
#include "light_ws2812.h"

struct CRGB{uint8_t green; uint8_t red; uint8_t blue; };
struct CRGB led_buffer[1];

int main(void){
  
  DDRD |= (1 << PD6);
  
  while(1){
    led_buffer[0].red = 255;
    led_buffer[0].green = 255;
    led_buffer[0].blue = 255;
    ws2812_sendarray(&led_buffer[0], 3);
    _delay_ms(500);
  }
  return 0;
}

 mache, blitzt die Led nur alle 500 ms auf und geht gleich wieder aus.

[Tim . (cpldcpu)]

Peter K. schrieb:
> mache, blitzt die Led nur alle 500 ms auf und geht gleich wieder aus.

* Stimmt die CPU Taktgeschwindigkeit? Ist in WS2812.h das richtige 
Define gesetzt?

* Hat die LED einen Bypasskondensator? (Die WS2812 sind teilweise 
ziemlich empfindlich)

[Peter K. (peterka2000)]

Tim .  schrieb:
> Peter K. schrieb:
>> mache, blitzt die Led nur alle 500 ms auf und geht gleich wieder aus.
>
> * Stimmt die CPU Taktgeschwindigkeit? Ist in WS2812.h das richtige
> Define gesetzt?
ja, das ist schon OK. Das passiert nur, wenn alle Werter gleich sind.
> * Hat die LED einen Bypasskondensator? (Die WS2812 sind teilweise
> ziemlich empfindlich)
Du meinst nen 100n? Mal probieren.
OK, es liegt tatsächlich daran. Ich hab verbotenerweise auch an den 
Mega8 kein 100n dran. Bitte jetzt nicht hauen.

[Werner (Gast)]

Mal eine Frage zur Helligkeitseinstellung, auch wenn es hier etwas 
Offtopic ist.
Da die LEDs ja RGB Daten erwarten, müsste ich vermutlich für eine 
saubere Helligkeitsänderung ohne Farbwertänderung einen anderen Farbraum 
als Zwischenschritt verwenden, oder wie macht ihr das?
HSV oder L*a*b* wären da vermutlich geeignet, aber evtl. etwas 
rechenaufwändig?

[Tim . (cpldcpu)]

Es gibt ein weiteres Update der Library: Jetzt  mit experimentellen 
Support for ARM Cortex Microcontroller. Bisher habe ich die Library mit 
dem LPC810 getestet.

Video: http://www.youtube.com/watch?v=Uwxt7SuSV7Y
Github Repository: https://github.com/cpldcpu/light_ws2812

[chris (Gast)]

Hier angepasste Version für den Arduino Uno.

[Tim . (cpldcpu)]

chris schrieb:
> Hier angepasste Version für den Arduino Uno.

Vielen dank!

[chris (Gast)]

Gerne geschehen ;-)
Noch ein kleiner Hinweis: In der geposteten Version habe ich die weiter 
oben schon einmal erwähnte Interrupt-Sperre vergessen. Dadurch kommt es 
( sehr selten ) zu einem flackern. Wer das verhinder will, solte also 
"cli() und sei() " um die Sendefunktion bauen.

[Martin S. (drunkenmunky)]

Servus,

versuche gerade den Code zu verstehen. Beschäftige mich nicht mit AVRs, 
will aber so eine Lib für PICs machen.

Vielleicht könnte einer den Assembler Code etwas kommentieren, damit 
man's einfacher versteht?

Danke!

[Tim . (cpldcpu)]

Martin S. schrieb:
> versuche gerade den Code zu verstehen. Beschäftige mich nicht mit AVRs,
> will aber so eine Lib für PICs machen.
>
> Vielleicht könnte einer den Assembler Code etwas kommentieren, damit
> man's einfacher versteht?

Ich habe einen Wiki-Artikel zur WS2812 Ansteuerung geschrieben. 
Vielleicht hilft er Dir weiter...

https://www.mikrocontroller.net/articles/WS2812_Ansteuerung

[Erlang E. (erlang)]

Hey Leute,

ich nutze o.g. Lib. Bis 100 LEDs klappt alles super, danach gibts aber 
(gerade bei unterschiedlichen Farben je LED) Probleme. LEDs hinter 
nummer 100 werden nicht mehr angesprochen. Verwende nen Atmega328 mit 16 
Mhz. Mit der Adafruit Lib klappt alles.
Jemand ähnliche Probleme?
Viele Grüße

[Tim . (cpldcpu)]

Komische Sache, da so etwas nicht durch Timing-Probleme erklärt werden 
kann. Bei mir hat es mit einem kompletten Streifen (240 LEDs) Problemlos 
funktioniert. Ein paar Fragen:

- Welche Taktgeschwindigkeit hat die CPU? Ist die in der Lib richtig 
gesetzt?

- Hat Dein String eine ausreichende Stromversorgung? Probiere doch 
einmal den String mit schwacher Intensität zu beschreiben. Wenn es dann 
geht, wird es an der Stromversorgung liegen.

- Die Lib sperrt im Gegensatz zur Neopixel lib keine Interrupts. Nutzt 
Du intererupts? Funktioniert es, wenn Du diese manuell sperrst? (sei(), 
cli())

[Erlang E. (erlang)]

Hallo Tim,

danke für deine schnelle Antwort. Ich habe das Problem jetzt mal etwas 
weiter untersucht und isoliert, vielleicht finden wir so besser eine 
Lösung bzw. den Fehler in der Lib (falls es einen gibt).

> - Welche Taktgeschwindigkeit hat die CPU? Ist die in der Lib richtig
> gesetzt?


Die CPU läuft auf 16 Mhz. Es ist ein ArduinoNano Klon. Ich verwende die 
Routine die mittels "ws2812_16MHz" aktiviert wird.

> - Hat Dein String eine ausreichende Stromversorgung? Probiere doch
> einmal den String mit schwacher Intensität zu beschreiben. Wenn es dann
> geht, wird es an der Stromversorgung liegen.

Das Netzteil ist recht kräftig. Der Fehler besteht aber unabhängig von 
der Intensität.
(Details siehe unten)


> - Die Lib sperrt im Gegensatz zur Neopixel lib keine Interrupts. Nutzt
> Du intererupts? Funktioniert es, wenn Du diese manuell sperrst? (sei(),
> cli())

Nein ich nutze in diesem Code keine Interrupts. Habe sie aber auch 
sicherheitshalber
gesperrt.

Ich habe mal einen minimal Code zum testen geschrieben. Dieser lässt 
alle LEDs ausgeschaltet und schaltet genau eine (an TARGET_POS) an. Wenn 
TARGET_POS <= 85 ist, funktioniert alles wie zu erwarten. Wenn 
TARGET_POS > 85 ist, dann bleibt die entsprechende LED dunkel. Dafür 
geht eine LED am Anfang des Stripes (in einer anderen Farbe) an.

Ich habe mit genau den gleichen Rahmenbedingungen die NeoPixel Library 
getestet und es gehen alle Positionen problemlos. Vielleicht doch ein 
Timing Problem? Oder irgendwelche Störungen? Ist die NeoPixel library so 
viel robuster umgesetzt?

    // Define and prepare hardware
    #define     COUNT           119
    #define     TARGET_POS      85

    DDRC |= (1 << ws2812_pin);

    cli();

    // Prepare buffer
    uint8_t buf[3 * COUNT];
    memset(buf, 0, 3 * COUNT);

    // Set pixel
    uint8_t bufPos = 3 * TARGET_POS;
    buf[bufPos] = 0;
    buf[bufPos + 1] = 0;
    buf[bufPos + 2] = 255;
    ws2812_sendarray(buf, 3 * COUNT);

Vielen Dank für eure Hilfe,
Erlang

[Erlang E. (erlang)]

Hallo Tim,
vielen Dank für deine Hilfe.

Tim .  schrieb im Beitrag #3312722:
> das sieht soweit alles ok aus. Allerdings werden interrupts mit sei()
> gesperrt und mit cli() wieder freigegeben. Außerdem solltest Du nach dem
> Aufruf von ws2812_sendarray 50us warten. Vielleicht geht es dann?

Habe den Code gerade noch einmal angepasst mit cli() statt sei(). 
Weiterhin gleiches
Verhalten. Nach dem ws2812_sendarray Befehl wechselt mein Testprogramm 
in
eine leere while(True) Schleife, daher warte ich deutlich länger als 
50us ;-).

Interrupts kommen definitiv nicht vor. Sehr seltsam alles.

Tim .  schrieb im Beitrag #3312722:
> Dein Fehler klingt, als wenn die Ausführung des calls
> nach einer gewissen Zeit einfach kurz unterbrochen wird, so dass die
> WS2812 resetten.

Genau. Bis 85 klappt alles. Sobald es dann 86 sind, wird mitten zwischen 
zwei bytes resettet, was dazu führt das eine LED weiter vorne (mit 
"falscher" Farbe) angeht. Mein Testcode ist maximal einfach, aber 
trotzdem klappt es nicht. Mit NeoPixel Lib alles wie gewünscht. Komisch 
komisch...

[Tim . (cpldcpu)]

Hi Phillip,

eigentlich sieht das alles ok aus. Einen Timingfehler kann ich mir kaum 
vorstellen, da das Signal in den LEDs regeneriert wird. Wenn die Erste 
LED funktioniert, sollte es mit allen klappen. Der Fehler, den Du 
beschreibst klingt so, als wenn der String während des Schreibens 
resetted wird. Das kann passieren wenn der Prozessor kurz hängt.

Hast Du die LEDs vor dem schreiben zurückgesetzt? (Pin auf low, 50us 
warten). Passiert der gleiche Fehler, wenn Du zweimal schreibst?

[Tim . (cpldcpu)]

> Habe den Code gerade noch einmal angepasst mit cli() statt sei().
> Weiterhin gleiches
> Verhalten. Nach dem ws2812_sendarray Befehl wechselt mein Testprogramm
> in
> eine leere while(True) Schleife, daher warte ich deutlich länger als
> 50us ;-).
>
> Interrupts kommen definitiv nicht vor. Sehr seltsam alles.

Ok, da warst Du schneller :) Auf dem AVR werden interrupts mit cli() 
gesperrt. Ich hatte das verwechselt, da es auf dem 6502 genau anders 
herum ist. Warum auch immer.

[Icke ®. (49636b65)]

Das liegt m.E. an einem Überlauf. 85 LEDs mal 3 Farben ergeben genau 255 
Byte, die in der Reichweite eines 8-Bit Pointers liegen. Ab der 86. 
kommt der da nicht mehr mit.

[Tim . (cpldcpu)]

Icke ®. schrieb:
> Das liegt m.E. an einem Überlauf. 85 LEDs mal 3 Farben ergeben genau 255
> Byte, die in der Reichweite eines 8-Bit Pointers liegen. Ab der 86.
> kommt der da nicht mehr mit.

Du hast recht. Es ist auch ganz klar, warum:

 uint8_t bufPos = 3 * TARGET_POS;
    buf[bufPos] = 0;
    buf[bufPos + 1] = 0;
    buf[bufPos + 2] = 255;

Richtig wäre:

 uint16_t bufPos ...

Eigentlich müsste der Compiler da auch eine Warnung ausgeben?!

[R. M. (rmax)]

Tim .  schrieb:

> Auf dem AVR werden interrupts mit cli() gesperrt.
> Ich hatte das verwechselt, da es auf dem 6502 genau anders
> herum ist. Warum auch immer.

SEI und CLI setzen bzw. löschen beim AVR das Interrupt-Enable-Flag und 
beim 6502 das Interrupt-Disable-Flag. Deshalb wirken sie genau 
entgegengesetzt.

[Erlang E. (erlang)]

Icke ®. schrieb:
> Das liegt m.E. an einem Überlauf. 85 LEDs mal 3 Farben ergeben genau 255
> Byte, die in der Reichweite eines 8-Bit Pointers liegen. Ab der 86.
> kommt der da nicht mehr mit.

Super. Tausend Dank für den Hinweis. Unglaublich wie blind man manchmal 
ist. Habe auf uint16_t umgestellt und nun läuft es wie gewünscht.

Vielen Dank auch Tim für deine Mühe bei der Fehlersuche und die tolle 
Library. Nun kann der LED Spaß losgehen ;-)

Viele Grüße,
Erlang

[Icke ®. (49636b65)]

Philipp E. schrieb:
> Unglaublich wie blind man manchmal ist.

Manchmal sieht man halt den Wald vor lauter Bäume nicht, da muß erst ein 
Spaziergänger des Weges kommen ;-)

Die Lib finde ich auch Klasse. Muß man erst mal drauf kommen, das 
Datenbit ins Carry zu shiften.. genial.

[Tim . (cpldcpu)]

Ich frage mich jetzt nur, warum der Fehler bei der Neopixel-Lib nicht 
aufgetreten ist? Dann war der code wohl doch nicht der gleiche...

[Erlang E. (erlang)]

Tim .  schrieb:
> Ich frage mich jetzt nur, warum der Fehler bei der Neopixel-Lib nicht
> aufgetreten ist? Dann war der code wohl doch nicht der gleiche...

Bei der NeoPixel Lib ist der Buffer ja bereits in der Lib drin, daher 
habe ich die manuelle Verwaltung von Position im Buffer, etc. dort nicht 
benötigt. Dort habe ich die
Methode strip.setPixelColor(...) verwendet und die Position entsprechend 
übergeben.

Viele Grüße und nochmals vielen Dank

[Icke ®. (49636b65)]

Martin S. schrieb:
> Vielleicht könnte einer den Assembler Code etwas kommentieren, damit
> man's einfacher versteht?

Ich war mal so frech, im Rahmen meiner Möglichkeiten die Routine in 
reinem Assemblercode nachzuempfinden. Geeignet ist er für ATmega8, 
ATmega16, diverse ATtinys sowie weitere kompatible AVRs bei 16 MHz 
Takt. Auf Optimierungen habe ich bewußt verzichtet, da es mir mit den 
NOPs übersichtlicher erscheint. Die Länge der RGB-Tabelle wird 16-bittig 
ausgewertet, sodaß theoretisch bis zu 21845 LEDs damit abgeklappert 
werden können. Praktisch ist die Anzahl jedoch durch den zur Verfügung 
stehenden RAM und andere Gegebenheiten begrenzt. Der Code muß natürlich 
noch an die tatsächlich verwendete Hardware angepaßt werden, also die 
CPU-spezifische Lib inkludieren sowie Port, Pin und Anzahl der LEDs 
definieren. Das Y-Register ist durch ein beliebiges anderes Registerpaar 
ersetzbar. Für das Befüllen der RGB-Tabelle darf jeder seiner Phantasie 
freien Lauf oder es dem Zufall über-lassen.
Testen konnte ich leider nur auf einem 60 LED langen Stripe, was 
längeres habe ich nicht am Lager.
Wenn jemand Fehler findet oder Ideen hat, wie man das besser machen 
kann, bitte posten. Den Code-Virtuosen hier fällt bestimmt noch was 
ein...

;Assembler-Routine für Atmega8, Atmega16 und weitere kompatible AVRs
;zum Ansteuern der RGB-LED WS2812 per Bit-Banging
;für 16 MHz Taktfrequenz ausgelegt
;nur die Senderoutine enthalten, das Füllen der RGB-Tabelle erfordert weiteren Code
;diverse Anpassungen an die Hardware (Port,Pin,Anzahl LEDs) sind im Header vorzunehmen


.EQU  crystal = 16000000          ;Systemtakt in Hz

.DEF  temp = r16              ;temporäres Register
.DEF  loopcounter = r17          ;Schleifenzähler

;Hier Port und Pin festlegen, an denen die WS2812 angeschlossen ist:
.EQU  led_port = PORTx          ;WS2812 relevantes PORT Register
.EQU  led_ddr  = DDRx            ;WS2812 relevantes Data Direction Register
.EQU  led_pin  = PDx             ;WS2812 relevanter I/O Pin

;Hier die Anzahl der LEDs festlegen (theoretisch bis 21845)
.EQU  rgb_count = x            ;Anzahl der LEDs


.DSEG
rgb_table:  .BYTE    rgb_count*3      ;RGB Tabelle im RAM anlegen


.CSEG
.ORG 0x0000

rgb_length:  .DW      rgb_count*3      ;Länge der RGB Tabelle (16-Bit)

    rjmp      main        ;springe zum Hauptprogramm


send_array:
    ldi        ZL,LOW(rgb_table)  ;lade die Adresse der RGB-Tabelle in den Z-Pointer  
    ldi        ZH,HIGH(rgb_table)
outer_loop:    
    ld         temp,Z+        ;lade nächstes Datenbyte
    ldi        loopcounter,8    ;setze Schleifenzähler
inner_loop:
    lsl        temp        ;schiebe nächstes Datenbit ins Carry
    dec        loopcounter      ;dekrementiere Schleifenzähler
    sbi        led_port,led_pin  ;Datenleitung auf H schalten
    nop
    nop
    brcs       PC+2        ;überspringe nächsten Befehl wenn Datenbit = 1
    cbi        led_port,led_pin  ;Datenleitung auf L schalten
    nop
    nop
    nop
    nop
    brcc       PC+2        ;überspringe nächsten Befehl wenn Datenbit = 0
    cbi        led_port,led_pin  ;Datenleitung auf L schalten
    nop
    nop
    nop
    nop
    brne      inner_loop      ;wiederhole die innere Schleife bis Zähler Null ist

    cp        ZL,YL        ;prüfe, ob Ende der RGB-Tabelle erreicht ist
    cpc       ZH,YH
    brne      outer_loop      ;wiederhole äußere Schleife, falls noch nicht

    ret


main:
    ldi       temp, LOW(RAMEND)  ;Stackpointer initialisieren
    out       SPL, temp
    ldi       temp, HIGH(RAMEND)
    out       SPH, temp

    sbi       led_ddr,led_pin    ;I/O-Pin als Ausgang definieren
    cbi       led_port,led_pin  ;Datenleitung auf L schalten

    ldi       YL,LOW(rgb_table)  ;Adresse der RGB-Tabelle ins Y-Register laden
    ldi       YH,HIGH(rgb_table)
    
    ldi       ZL,LOW(rgb_length)  ;Adresse von rgb_length ins Z-Register laden
    ldi       ZH,HIGH(rgb_length)
    lpm       temp,Z+        ;Low-Byte der RGB-Tabellen-Länge in temp laden
    add       YL,temp        ;addiere die Länge der RGB-Tabelle zum Y-Register (Low-Byte)
    lpm       temp,Z        ;High-Byte der RGB-Tabellen-Länge in temp laden
    adc       YH,temp        ;addiere die Länge der RGB-Tabelle zum Y-Register (High-Byte)

    ;fülle die RGB-Tabelle nach Belieben mit deiner eigenen Routine

    cli                  ;Interrupts sperren
    rcall      send_array      ;Daten an WS2812 senden
    sei                  ;Interrupts freigeben

main1:
    rjmp      main1

[Icke ®. (49636b65)]

Icke ®. schrieb:

ldi       ZL,LOW(rgb_length)  ;Adresse von rgb_length ins Z-Register laden
ldi       ZH,HIGH(rgb_length)

Hier hat sich ein kleiner, aber fataler Fehler eingeschlichen, der 
unbemerkt bleibt, solange rgb_length auf Adresse 0x0000 des Codesegments 
liegt. Aufgrund der WORD-Organisation in CSEG muß beim Laden des 
Z-Pointers die Adresse mit 2 multipliziert werden. Richtig lautet es:

ldi       ZL,LOW(rgb_length*2)  ;Adresse von rgb_length ins Z-Register laden
ldi       ZH,HIGH(rgb_length*2)

[Rene (Gast)]

Moin Moin,
ich habe einen vorschlag undzwar das die Lib statt mit RGB mit dem HSV 
fabraum arbeitet.

MFG
Rene

[Icke ®. (49636b65)]

Auch wenn da "rgb_table" steht, die Lib hat mit dem Farbraum nichts zu 
tun. Sie reicht einfach nur die in der Tabelle abgelegten Werte an die 
LEDs durch.

[Tim . (cpldcpu)]

Rene schrieb:
> Moin Moin,
> ich habe einen vorschlag undzwar das die Lib statt mit RGB mit dem HSV
> fabraum arbeitet.

Die LEDs verarbeiten nur RGB. Die Lib übernimmt lediglich die Aufgabe, 
die Daten aus dem Buffer im Speicher in die LEDs zu übertragen.

Um mit HSV-Werten zu arbeiten, müsste man dies vor der Übertragung in 
RGB umwandeln.

[Rene (Gast)]

Okay muss ich mich halt selber drm kümmern, die lib an sich funktioniert 
bei mir. Jetzt habe ich aber noch eine frage bitte nicht hauen. Und zwar 
währe es möglich an die funktion ws2812_sendarray den PORT und dem PIN 
zu übergeben wo er die daten rausschiken soll also sie nicht vorher zu 
definiern. Damit man mehere Stips an einen Controller anzu schließen?

MFG
Rene

[Tim . (cpldcpu)]

Rene schrieb:
> währe es möglich an die funktion ws2812_sendarray den PORT und dem PIN
> zu übergeben wo er die daten rausschiken soll also sie nicht vorher zu
> definiern. Damit man mehere Stips an einen Controller anzu schließen?

Dafür gibt es ws2812_sendarray_mask in den neusten Versionen:

https://github.com/cpldcpu/light_ws2812/tree/master/

Damit kann man den Pin frei wählen. Es müssen aber trotzdem alle Strips 
an den gleichen Port angeschlossen werden.

[Tim . (cpldcpu)]

V1.0! Yay!

https://github.com/cpldcpu/light_ws2812

[Ulrich Radig (Gast)]

Hallo,

Danke für das TOLLE PROJEKT!!

Hier mein bescheidener Beitrag dazu.

Gruß
Uli

[Ulrich Radig (Gast)]

Sorry hatte noch ein Fehler im Source Code drin!

[Martin (Gast)]

Hallo,

erstmal Danke an Tim für das schöne Projekt und den Code.
Danke auch an Ulrich Radig für die HSV-Umrechnung.

Mit dieser habe ich leider ein kleines Problem. Die Farben scheinen 
"Sprünge" zu machen, so als ob bei der Berechnung ein paar Bits verloren 
gehen.

<math.h> habe ich eingebunden und linke mit -lm (falls das überhaupt 
notwendig ist). Leider bin ich im Moment etwas ratlos wo der Fehler 
liegen könnte. Evtl kann mir jemand weiterhelfen?

Danke schon mal,
Martin

[Martin B. (martin_b97)]

Sorry,

habe vorhin vergessen mich anzumelden, daher kann ich den Text jetzt 
nicht mehr ändern. Noch als Ergänzung: Ich verwende EINE WS2812, 
angeschlossen an PORTB0 eines MEGA328P.

Martin

[Martin B. (martin_b97)]

Hallo nochmal,

langsam habe ich den Eindruck, dass der Hund hier begraben ist:

//Berechnung der Dunkelstufe
//v = (englisch value) Wert Dunkelstufe einfacher Dreisatz 0..100%
    *r = (*r / 100) * v;
    *g = (*g / 100) * v;
    *b = (*b / 100) * v;

Ich vermute da wird aufgrund der unsigned chars r,g,b und v irgendwas 
gerundet oder läuft über. Wenn ich den Teile auskommentiere, sind die 
Abstufungen weg, aber man kann halt die Helligkeit nicht mehr 
einstellen.

Grüße,
Martin

[Radig (Gast)]

Hallo,

schaue mal hier:
http://www.ulrichradig.de/home/index.php/projekte/hsv-to-rgb-led

habe den Source Code geändert.

Gruß
Uli

[Tim . (cpldcpu)]

Ulrich Radig schrieb:
> Hier mein bescheidener Beitrag dazu.

Hallo Ulrich,

super Projekt! Ich glaube das solltest Du noch einmal mit Bildern 
posten, so sieht ja niemand, was sich dahinter verbirgt :)

Hat eigentlich schon jemand ein Layout für einen Ring mit 5cm 
Außendurchmesser erstellt? Die würden sich schön preiswert bei den 
Chinesischen PCB-Herstellern liefern lassen.

[Martin B. (martin_b97)]

das gaht auch. Ich hatte mir mittlwerweile mit einem cast auf int bei 
der Berechnung beholfen. Aber so ist es eleganter.

Danke,
Martin

[Tim . (cpldcpu)]

Eine Idee noch: Dir normalisierst Sättigung und Helligkeit auf 100. Wenn 
Du hier auf 64 oder 128 gehen würdest, würde für den AVR deutlich 
kürzerer Code generiert werden.

[Radig (Gast)]

Ich habe mir einen mit innen 52mm und außen mit 72mm erstellt. Dieser 
passt auf den Ring meiner Halogenlampe. Gibt es auch im Download auf 
meiner HP.

Gruß
Uli

[Radig (Gast)]

So würde ich es auch nicht machen:

*g = 4.25 * h;

sondern so:

*g = (425 * h) /100;

es ist aber anders besser verständlich.

Gruß
Uli

[Tim . (cpldcpu)]

Radig schrieb:
> *g = (425 * h) /100;
>
> es ist aber anders besser verständlich.

Ich bin mir nicht ganz sicher ob das als Antwort auf meinen Vorschlag 
gemeint war. Aber wenn Du hier statt dessen

> *g = (425 * h) /256;

Einsezt, bekommst Du deutlich kürzeren Code. Hier gibt es aber noch ein 
paar Fallen mit den richtig Casts. Besser:

> *g = (uint8_t)((425 * h) /256);

und h ist ein int oder uint16_t.

[Ulrich Radig (Gast)]

Ich weiß das eine div  256  128  64  32 besser ist als eine div / 
100. Ist ja dann nur eine schiebe Operation. Es wird halt immer in den 
Beispielen 0 bis 1 oder 0 bis 100% angegeben. Daher auch bei mir nur der 
Wertebereich 0 .. 100 ;-) es dient nur als Beispiel. Sonnst könnte ich 
gleich auch die allgemeine Berechnungsmatrix verwenden.

[Di P. (drpepper)]

Ulrich Radig schrieb:
> Sonnst könnte ich
> gleich auch die allgemeine Berechnungsmatrix verwenden.

Kannst du bitte mal einen Link posten? Meiner ansicht nach ist eine 
Matrix für HSV -> RGB nicht möglich.

Eine interessante Implementierung und auch andere nützliche Farbräume 
sind hier:
http://www.cs.rit.edu/~ncs/color/t_convert.html

[Tim . (cpldcpu)]

Radig schrieb:
> Ich habe mir einen mit innen 52mm und außen mit 72mm erstellt. Dieser
> passt auf den Ring meiner Halogenlampe. Gibt es auch im Download auf
> meiner HP.

Ich hatte an dieses Format gedacht:

http://www.adafruit.com/product/1463

Wenn man unter 50mm Außendurchmesser bleibt, kann man die Platinen für 
<1EUR pro Stück bei den bekannten Chinesen bestellen.

[Mario W. (mario_w)]

Hallo Zusammen,

ich verfolge nun schon eine ganze weile dieses Thema, was mich dazu 
bewegt hat auch so ne Kette zu bestellen.

So wie es aussieht sind die meisten schon über das Testprogramm hinaus.
Ich leider nicht.
Satt dessen werde ich noch Wahnsinnig mit dem Streifen.

Mein größtes Problem an der Sache bin wahrscheinlich ich selbst, da ich 
noch keine wirkliche Programmierleuchte bin, aber das kann ich 
dummerweise nicht vorher ändern, sondern nur an diesem Projekt wachsen.

Aber so wie ich gelesen habe gibt es hier Leute die von dem Ahnung haben 
was sie tun.

Bis jetzt habe ich den Eindruck gewonnen das die Dinger total 
empfindlich sind bezüglich - Wärme und EMV.

Es kommt mir so vor als ob ständig die erste LED hobs geht und dadurch 
der Rest macht was er will.

Blinken, gar nicht Leuchten.............

Habt ihr auch solche Probleme oder wie geht ihr mit dem Streifen/LED's 
um?

Schon mal Danke für eure Bemühungen.

Gruß Mario

[Mario W. (mario_w)]

Meine bisherigen Schadensbilder an mehreren abgeschnittenen LED-Streifen 
mit 2-10 LED's

Bitmuster kommt sauber und richtig an der ersten LED an.
Stromversorgung steht auch.

# Alle LED's aus --> erste LED gibt nur 0 weiter aber in der richtigen 
Anzahl. Deshalb auch alle anderen LED's aus.
# Alle LED's leuchten blau --> vermute default Einstellung. Erste LED 
macht nichts somit alle anderen auch nicht.
# Alle LED's leuchten richtig bis auf die erste --> erste Kaputt gibt 
aber Bit-Muster richtig weiter.
# Alle LED's blinke und die erste sogar wie sie will --> gibt Bit-Muster 
blinkend weiter.
# Alle LED's blinken weiß --> ob wohl blau ausgegeben wird.

Ihr seht ich hab schon fast alles gehabt nur noch keinen voll 
Funktionsfähigen Streifen.

Hat jemand eine Quelle wo man noch an kleine Fetzen vom WS2812 ran 
kommt?
Da ich selbst nicht in der Lage wäre diese Lib für den WS2812B 
umzuschreiben.

Ist es richtig das eine Scene ausgegeben werden kann und der Streifen 
hält diese dann bis eine neue Scene ausgegeben wird?
oder muss kontinuierlich gesendet werden mit Reset dazwischen?

[Tim . (cpldcpu)]

Die Ansteuerung von WS2812 und WS2812B ist identisch. Die Library kann 
beides.

Ich werde aus Deiner Fehlerbeschreibung noch nicht ganz schlau.

Hast Du die Punkte aus der Liste "Troubleshooting" schon alle durch?

https://github.com/cpldcpu/light_ws2812

[Mario W. (mario_w)]

Hi Tim,

auch von mir Danke für das Projekt super Arbeit  :)

Ja das "Troubleshooting" bin ich soweit durch und kann nichts erkennen 
was ich nicht berücksichtigt hab.
Habe gerade ein Oszi dran hängen und dort kann ich auch kein Problem 
feststellen.

Der betriebene Streifen hat 5 LED's, im unten stehenden Programm werden 
nur 3 angesteuert die weiß leuchten sollen.
Habe dein Beispielprogramm genommen und für 3 LED's angepasst.

Ist-Stand --> die drei sind aus und die zwei nicht angesteuerten 
leuchten blau (default).

Oszi sagt: 3x 24bit alles einser mit ca. 650ns high und 650ns low bei 
4,7V
und nach der ersten LED kommen nur noch 0er raus im richtigen Timing und 
Anzahl. Was aber 1er sein sollten.
Somit ist wahrscheinlich wieder die erste LED kaputt.

Hab mittlerweile die EMV Sandalen an und mit 180C° die Litzen dran 
gepappt und trotzdem geht nichts.

Das Programm läuft eigentlich. Ich glaube ich habe 5m Schrott gekauft, 
eine andere Erklärung habe ich momentan nicht :(

Ich habe hier auch ein 10er streifen WS2812B. wenn ich den direkt dran 
hänge tut der leider auch nicht. Oder muss man da noch was umstellen. Da 
laut Datenblatt das Timing anders ist.

Achso Ich verwende ein ATMEGA328P mit 16MHz auf einem Arduino UNO aber 
ohne Bootloader. Programmiere mit AtmelStudio 6.1

#include <util/delay.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include "light_ws2812.h"

int main(void)
{
  uint8_t mask;
  uint8_t test[] = {255,255,255,255,255,255,255,255,255};
  
  #ifdef __AVR_ATtiny10__
  CCP=0xD8;                
  CLKPSR=1;                
  mask=_BV(PB2);
  #else
  CLKPR=_BV(CLKPCE);
  CLKPR=0;                       
  mask=_BV(PB0);
  #endif
  DDRB|=mask;
  
  while(1)
  {
ws2812_sendarray((uint8_t *)&test[0],9);                
_delay_ms(50);                                                             
  }
}

[Tim . (cpldcpu)]

>Oszi sagt: 3x 24bit alles einser mit ca. 650ns high und 650ns low bei
4,7V

Das ist nach meinen neusten Erkenntnissen marginal. Vielleicht hast Du 
wirklich ein abweichenden Fertigungslos erwischt?

Du könntest ja mal die V2 testen. Die ist im Moment noch im Entstehen. 
Der aktuelle Entwicklungsstand liegt hier:

https://github.com/cpldcpu/light_ws2812/tree/testing/light_ws2812_AVR

[Mario W. (mario_w)]

Ha erfolg erfolg.

Habe nach deiner Aussage das die Lib auch für WS2812B funktioniert. Bei 
meinem B Streifen die erste LED abgeschnitten und siehe da.

Alles tut wie es soll :)
Also Programm Top, LED-Stripe aus China flop.
Die V2 werde ich dann auch mal probieren und dir berichten.

Danke für den doch so wichtigen Input.

Gruß und schönen abend.

Mario

[Tim . (cpldcpu)]

Merkwürdig. Ich kann die Geschichte mit der ersten LED immer noch nicht 
so recht glauben, aber von andere Seite gibt es ähnliche Berichte:

Beitrag "WS2812 und WS2812b Qualitätsprobleme!"

[Tim . (cpldcpu)]

Ich habe mich noch einmal etwas genauer mit der WS2812 Ansteuerung 
beschäftigt:

http://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

Teil 2 kommt mit der neuen Version der Library.

Ich würde mich über Kommentare freuen.

[Axel H. (axelh)]

Hi,

Super Seite, interessant zu lesen. Aber eine Frage zum letzten Satz: "A 
'1' can be encoded with pulses of almost arbitrary length as long as 
they are longer than ~625 µs (minimum on WS2812B)."

Das sollen eher 625ns sein, oder?

Axel

[Tim . (cpldcpu)]

Axel Heider schrieb:

> Super Seite, interessant zu lesen. Aber eine Frage zum letzten Satz: "A
> '1' can be encoded with pulses of almost arbitrary length as long as
> they are longer than ~625 µs (minimum on WS2812B)."
>
> Das sollen eher 625ns sein, oder?

Oh ja, danke für den Hinweis!

[Tim . (cpldcpu)]

Hier gibt es ein ziemlich schickes Projekt für WS2812-LEDs:

http://forum.43oh.com/topic/4920-120-led-ring-clock/

Der Autor hat auch die Gerber-Files für den Ring gepostet. Den könnte 
man auch problemlos mit einem AVR betreiben.

Eigentlich wäre auch ein einfacer 60er Ring interessant.

[Tim . (cpldcpu)]

Hier gibt es die Eagle-Dateien für die WS2812-Ringe (Neopixel) von 
Adafruit:

https://github.com/adafruit/Adafruit-NeoPixel-Ring

[Tim . (cpldcpu)]

Es gibt jetzt die Version 2 der Library:

Beitrag "Re: WS2812 Ansteuerung per Bitbanging für AVR und ARM von 4 Mhz-60 Mhz"

Oder direkt zum Download:

https://github.com/cpldcpu/light_ws2812

[rossi (Gast)]

Wollte mich für die Lib bedanken. Hab grad mal eben so auf die schnell 
(keine 10 Minuten) ein Testprogramm für einen Mega8 mit 16MHz an einem 
Stripe mit 150 LEDs geschrieben. Funktioniert super!
Hier zwei Videos: Einmal Vollgas, einmal mit gebremster Animation:

http://www.youtube.com/watch?v=RRk7qi0s3tU

http://www.youtube.com/watch?v=BSlZhNBp98Y

[Tim . (cpldcpu)]

Danke! Schick, so viele LEDs habe ich bisher noch nicht auf einmal 
getested.

[Fuchs (Gast)]

Hi,
leider hatte ich nicht so viel Glück wie mein Vorredner rossi.

Ich versuche schon eine Weile die Lib auf einem ST23L152 (Cortex-M3) zum 
Laufen zu bekommen, aber etwas klappt da nicht.

Ich habe den Assembler-Teil leider nicht ganz verstanden, aber ich denke 
es gibt da ein Problem:

"    sub %[ctr], #1        \n\t"
"    str %[masklo], [%[clr]]    \n\t"
"    beq  end%=          \n\t"

und zwar wird mein Register %[ctr] immer weiter verkleinert, ohne dass 
die Schleife jemals verlassen wird.

Vielleicht ist der Befehl beq hier irgendwie falsch.
Oder liegt das an meiner MCU?

Ich habe die (hoffentlich) aktuelle Lib:
* light weight WS2812 lib - ARM Cortex M0/M0+ version
* Created: 07.07.2013

Es wäre nett, wenn da mal jemand draufschauen könnte.

[Tim . (cpldcpu)]

HI Fuchs,

ich muss darauf hinweisen, dass ich die ARM-Version bisher noch nicht 
auf einem Cortex-M3 getestet habe. Entwickelt wurde sie auf einem M0+.

Gerade bei den größeren Cortexen ist es schwierig, zyklengenaues Timing 
zu ermöglichen. Die Implementation geht davon aus, dass es keine 
Flash-Waitstates gibt. Dein ST hat wahrscheinlich mindestens 1 
Waitstate, so dass das Timing nicht stimmt. Hast Du Dir einmal den 
Ausgang angeschaut? Evtl. kannst Du die CPU-Clock verringern und die 
Waitstates auf 0 setzen?

Die Schleife im ASM-Teil funktioniert übrigens, da "STR" das Z-Register 
nicht setzt.

http://infocenter.arm.com/help/topic/com.arm.doc.dui0497a/BABIHJGA.html

Generell ist es gerade auf den schnelleren Cortexen sinnvoll, auf einen 
Hardware-Ansatz zu setzen. Bei STM32 würde sich eine Kombination aus SPI 
und DMA anbeiten. Im Wiki-Artikel gibt es ein paar Beispiele:

http://www.mikrocontroller.net/articles/WS2812_Ansteuerung

[rossi (Gast)]

Ich muss leider zugeben, dass mich mein Glück mit meinem 150 LED 
Streifen nun auch ein wenig verlassen hat und ich auch Opfer des "erste 
LED hin" Problems geworden bin. Da ich meinen Streifen eh komplett 
zerschneiden will hab ich jetzt erst mal die ersten Teilstreifen 
abgeschnitten und dabei stellte sich heraus, dass nur die erste LED hin 
ist.
Jetzt frage ich mich natürlich - werden jetzt die nächsten ersten LEDs 
auch die Grätsche machen bis alle kaputt sind? Was kann man denn dagegen 
tun, dass die erste LED mit der Zeit kaputt geht? Sind lange Streifen 
mit hohen Einschaltströmen evtl. ein Problem? Versorgt ihr alles aus 
einem Netzteil? Also Prozessor und Streifen? Ich hab ein altes 
AT-Netzteil am Streifen (20A an 5V) und mein STK500 mit dem Prozessor. 
Massen sind verbunden, Signal geht direkt an den Streifen. Sollte man da 
vielleicht einen 1k Widerstand in Reihe zum Eingang des Streifens 
schalten? Und in welcher Reihenfolge sollte man einschalten? Erst den 
Streifen, dann den Controller? Helfen vielleicht dicke Elkos am +/- des 
Streifens? Oder gar einen kleinen Spannungsfilter mit Dorssel & Co. um 
saubere Spannung zuzuführen?

[Fuchs (Gast)]

Hi, danke für die schnelle Antwort.
In meinem Test habe ich 16MHz verwendet und die Waitstates auf 0 
gesetzt. Nach Application Note müsste das klappen bei VCore von 1,8V 
(und mir ist auch nichts abgestürzt).

Mein Problem beginnt eigentlich schon früher als beim Timing des 
Ausgangs.
Und zwar wird (wie erwähnt) die ctr-Schleife im ASM-Teil nie verlassen. 
ctr zählt fröhlich bis beliebig negative Werte weiter...

Wenn ich vor dem BEQ ein "compare mit 0" einfüge (ich weiß, das ändert 
das Timing, ich probiere nur aus...), dann klappt der Sprung, sobald 
ctr=0:

"    sub %[ctr], #1             \n\t"
"    str %[masklo], [%[clr]]    \n\t"
"               cmp %[ctr],#0   \n\t"  //<-- NEU 
"               beq end%=       \n\t"

Ich habe kurz gegoogelt, der ST32L benutzt das THUMB2 instruction set. 
Kann es da evtl. Unterschiede geben?

Ok, also so weit, so gut.
Als nächstes habe ich festegestellt, dass (unabhängig vom übergeben 
Array) immer 0er gesendet werden. Es scheint so, als würde der 
BCS-Befehl nie zuschlagen:

"    bcs one%=                  \n\t"
"    str %[masklo], [%[clr]]    \n\t"
"               one%=:          \n\t"

Ich überlege mir jetzt, ob ich:

- den ASM-Teil so anpasse, dass er auf meiner MCU wie gewünscht läuft 
(ich habe mal gegoogelt und hab was gefunden, wie man angeblich mit 
systick die genaue Anzahl Zyklen messen kann)

- versuche das Timing mit SPI und DMA zu realisieren

Ich tendiere eigentlich eher zum ersten...
In beiden Fällen steckt da für mich noch ein gutes Stück Arbeit drin
(bin noch neu, ist mein erstes "Projekt")

[Tim . (cpldcpu)]

rossi schrieb:
> einem Netzteil? Also Prozessor und Streifen? Ich hab ein altes
> AT-Netzteil am Streifen (20A an 5V) und mein STK500 mit dem Prozessor.
> Massen sind verbunden, Signal geht direkt an den Streifen. Sollte man da
> vielleicht einen 1k Widerstand in Reihe zum Eingang des Streifens
> schalten? Und in welcher Reihenfolge sollte man einschalten? Erst den
> Streifen, dann den Controller? Helfen vielleicht dicke Elkos am +/- des
> Streifens? Oder gar einen kleinen Spannungsfilter mit Dorssel & Co. um
> saubere Spannung zuzuführen?

Hier im Thread gibt es ja schon einige Infos:

Beitrag "WS2812 und WS2812b Qualitätsprobleme!"

Das Minimum sollte wohl eine Serienterminierung am Ausgang des 
Controllers mit 100-150 Ohm sein. 1k ist zuviel.

[Tim . (cpldcpu)]

Fuchs schrieb:
> Ich habe kurz gegoogelt, der ST32L benutzt das THUMB2 instruction set.
> Kann es da evtl. Unterschiede geben?

Der M3 unterstützt gegenüber dem M0 zusätzliche Befehle. Unterschiede 
kann ich mir nur vorstellen, wenn der code anders compiliert wird. Deine 
Beobachtungen sind merkwürdig. Meistens ist es aber nicht so, dass die 
CPU plötzlich ganz anders funktioniert, sondern es woanders Probleme 
gibt :)

Du kannst die Schleife ja mal in C nachprogrammieren, und schauen was 
der Compiler daraus macht?

int i=8;
int data=xx;

while (--i) {
  PORT=HI;
  if (data&128) PORT=LO;
  data<<=1;
  PORT=LO;
}

oder so ähnlich

Fuchs schrieb:
> Ich überlege mir jetzt, ob ich:
>
> - den ASM-Teil so anpasse, dass er auf meiner MCU wie gewünscht läuft
> (ich habe mal gegoogelt und hab was gefunden, wie man angeblich mit
> systick die genaue Anzahl Zyklen messen kann)
>
> - versuche das Timing mit SPI und DMA zu realisieren
>
> Ich tendiere eigentlich eher zum ersten...
> In beiden Fällen steckt da für mich noch ein gutes Stück Arbeit drin
> (bin noch neu, ist mein erstes "Projekt")

Ich würde Dir zum Zweiten raten, da es auf deinem M3 ziemlich schwierig 
sein wird, nachvollziehbares Timing zu generieren, es aber andererseits 
mächtige Peripherie gibt. Im oben verlinkten Artikel gibt es ja schon 
Beispiele.

[Tim . (cpldcpu)]

Es gibt eine neue Version der WS2812 im 8mm Gehäuse. Sieht echt nett 
aus!
Ich werde die mal etwas genauer anschauen.

[Axel H. (axelh)]

Wo hast du die neue Version her?

[Tim . (cpldcpu)]

Im Moment scheint das nur eine Vorserie zu sein. Größere Stückzahlen 
gibt es erst später.

Hier kann man schon kleinere Stückzahlen kaufen:
http://solderingsunday.com/shop/components/pixelbits-bakers-dozen/

Zum Bild oben Links: Der Pinabstand scheint nur 2.5 mm statt 2.54 mm wie 
im Datenblatt zu sein.

[Tim . (cpldcpu)]

Bei der Ansteuerung gab es keine Überraschungen. Witzige Dinger.

http://cpldcpu.wordpress.com/2014/02/18/new-member-of-the-ws2812-family/

[benwilliam (Gast)]

btw, nur so als frage zwischen durch warum versucht man mit einem STM32 
die 150 WS2812b mit bitbanging an zu steuern?
Anstatt einfach den SPI zu benutzen?

[Axel H. (axelh)]

Viele Wege führe nach Rom, und das ist wohl der einfachste und 
portabelste um was um leuchten zu bringen.
Mit einem LPC810 habe ich das hier mit SPI und nachgeschaltetem SCT am 
laufen. Ist halt ein bisschen mehr Aufwand bis das mal läuft.

BTW: Irgendwer Interesse an eine Sammelbestellung der 8mm version? $15 
für den 12er pack und $10 Versand. Und halt noch Zoll.



Axel

[Tim . (cpldcpu)]

Axel Heider schrieb:
> Viele Wege führe nach Rom, und das ist wohl der einfachste und
> portabelste um was um leuchten zu bringen.
> Mit einem LPC810 habe ich das hier mit SPI und nachgeschaltetem SCT am
> laufen. Ist halt ein bisschen mehr Aufwand bis das mal läuft.

Die Version aus dem lpc800 Forum?

Axel Heider schrieb:
> BTW: Irgendwer Interesse an eine Sammelbestellung der 8mm version? $15
> für den 12er pack und $10 Versand. Und halt noch Zoll.

Kam bei mir Zollfrei und EUSt-Frei an, obwohl als Wert $50 deklariert 
war. Sind "Hobby Parts" von der EUSt befreit?

[Axel H. (axelh)]

> Die Version aus dem lpc800 Forum?

Ja, basierend auf der. Prinzipiell funktioniert der Code super und wenn 
man ein paar Kommentare ergänzt, dann ist das sogar verständlich, was da 
gemacht wird.  :)

> Sind "Hobby Parts" von der EUSt befreit?

Laut Zoll Webseite geht alles bis 45 Eur zollfrei als Geschenk durch. Da 
bist du mit den $50 also knapp drunter. Mit dem aktuellen Dollar-Kurs 
sollten also 4 Packungen zollfrei sein ($60 ca. 44 EUR).

Axel

[R. M. (rmax)]

Axel Heider schrieb:

> Laut Zoll Webseite geht alles bis 45 Eur zollfrei als Geschenk durch.

Als Geschenk gilt es aber nur, wenn es von einer Privatperson an eine 
Privatperson geschickt wird. Ich durfte vor ein paar Jahren mal für eine 
Sendung mit Werbegeschenken aus Kanada (CD-ROMs und T-Shirts) im Wert 
von CAD 50 beim Zoll antanzen und Einfuhrabgaben zahlen.

[Axel H. (axelh)]

Auch wenn's jetzt OT ist, hab mal im Wiki die Seite 
Elektronikversender: Zoll und Abgaben ergänzt. Schien dazu bisher 
noch nichts zu geben.

[Tim . (cpldcpu)]

Axel Heider schrieb:
> Auch wenn's jetzt OT ist, hab mal im Wiki die Seite
> Elektronikversender: Zoll und Abgaben ergänzt. Schien dazu bisher
> noch nichts zu geben.

Im China-Bauteile Thread gibt es bestimmt auch einige dazu:

Beitrag "China SUPER Bauteile-Schnäppchen Thread"

[Conny G. (conny_g)]

Axel Heider schrieb:
> BTW: Irgendwer Interesse an eine Sammelbestellung der 8mm version? $15
> für den 12er pack und $10 Versand. Und halt noch Zoll.

Interessiert, abhängig vom Preis!
Würde so für 30 Dollar kaufen, in der Hoffnung, dass bei einer größeren 
Gesamtmenge dann auch 60-100 Stück dafür drin sind...

[Tim . (cpldcpu)]

Lusting, langsam klärt sich auch, woher die LEDs kommen. Ich habe mal 
nachgefragt, ob günstigere Preise für größere Mengen möglich sind. Melde 
mich, wenn es eine Antwort gibt.

[Tim . (cpldcpu)]

Ich habe mit dem Hersteller einen guten Kompromiss zu einer 
Sammelbestellung finden können:

Beitrag ""Sammelbestellung" für 8mm RGB LEDs mit WS2811 chip"

[Axel H. (axelh)]

Cool, Danke!

Axel

[Michael S. (michael_s98)]

Hi,

wirst du deine Library auch für XMegas kompatibel machen?
Ich würde ja gerne aber meine ASM kenntnisse lassen da leider sowas
nicht zu

[Tim . (cpldcpu)]

Eigentlich sollte sie auf XMega funktioniert, oder übersehe ich da 
etwas?

[Michael S. (michael_s98)]

Ich habs leider nicht zum laufen bekommen.
Und deine DMA header file ist ja "noch" leer :)

[Tim . (cpldcpu)]

Michael S. schrieb:
> Ich habs leider nicht zum laufen bekommen.

Was ist denn genau das Problem?

> Und deine DMA header file ist ja "noch" leer :)

Was für ein DMA header File? :)

[Michael S. (michael_s98)]

Beim xMega haben sich die Portregister etwas geändert. Das konnte ich 
auch selbst noch in der Lib aendern. Die Portregister denke ich sind 
aber nicht das Problem, sondern das es bei dem ASM Code ein Fehler gibt 
und meine ASM Kenntnisse nicht vorhanden sind ;P ist es schwierig es zu 
lösen. Ich hab ja nichtmal den Fehler selbst nach googlen nicht 
verstehen können gG

light_ws2812.c: In function ‘ws2812_sendarray_mask’:
light_ws2812.c:108:5: warning: asm operand 2 probably doesn’t match 
constraints [enabled by default]
light_ws2812.c:108:5: error: impossible constraint in ‘asm’
make: *** [obj/light_ws2812.o] Fehler 1

[Tim . (cpldcpu)]

Ah, ich sehe schon. Das Problem scheint zu sein, dass die Portregister 
nicht mehr PORTx und DDRx heissen, sondern OUTx und DIRx.

Versuche mal die Register in light_ws2812.h direkt einzutragen. Dazu 
musst Du diese Zeilen ersetzen:

#define ws2812_PORTREG  CONCAT_EXP(PORT,ws2812_port)
#define ws2812_DDRREG   CONCAT_EXP(DDR,ws2812_port)

durch

#define ws2812_PORTREG  CONCAT_EXP(OUT,ws2812_port)
#define ws2812_DDRREG   CONCAT_EXP(DIR,ws2812_port)

Die Fehlermeldung scheint durch eine ungültige Portregisteraddresse 
verursacht zu sein. Evtl. hast Du auch ein Portregister gewählt, welches 
nicht mehr durch OUT angesteuert werden kann.

[MB (Gast)]

ich möchte die LED-Funktion als Statusanzeige für verschiedene 
Funktionen nutzen, also jede .c-Datei soll eine zugewiesene LED 
ansteuern.

Allerdings habe ich keine Ahnung, wie ich die Daten der

struct cRGB led[..];

mit in andere .c Dateien global übernehmen kann.

Wenn ich

struct cRGB led[..];

 in jeder Datei einfüge, sind die bisherigen RGB-Werte der main.c 
verloren und es wird nur die aktuell genutzte Status-LED angezeigt.

Wer kennt sich damit aus ???

[Di P. (drpepper)]

stichwort: "extern"

steht in deiner (und jeder anderen) C-Referenz.

[Tim . (cpldcpu)]

Wie "Di" Geschrieben hat. Alternativ kannst Du auch auch pointer auf die 
Struktur als Funktionsparameter übergeben. Vom Programmierstil her ist 
das etwas sauberer.

[Di P. (drpepper)]

Tim    schrieb:
> Vom Programmierstil her ist
> das etwas sauberer.

stimmt.

[MB (Gast)]

Mit "extern" hatte ich es vorher auch schon probiert, es hat aber nicht 
geklappt.

Mit Pointer geht es nach einigem basteln.
man lern eben nie aus ;-)

Dankeschön

[Di P. (drpepper)]

MB schrieb:
> Mit "extern" hatte ich es vorher auch schon probiert, es hat aber nicht
> geklappt.

Die richtige Vewendung von "extern" ist dabei natürlich entscheidend ;).
In einer c-Datei muss die Variable deklariert (und ggf. initialisiert) 
werden. In einer von allen anderen c-Dateien eingebundenen header-Datei 
wird diese Variable dann als extern deklariert.
Das bewirkt, dass von allen verteilten Programmteilen auf die selbe 
Speicherstelle zugegriffen wird, wenn der name der Variablen fällt.
"extern" signalisiert dem compiler, dass sich die zu kompilierende 
c-Datei darauf verlassen kann, dass Speicher für diese Variable 
vorhanden sein wird. Wo das ist, macht dann der Linker den einzelnen 
o-Dateien klar.

[MichaelS98 (Gast)]

Hi Tim,

ich habs nun nochmal nach langer Zeit versucht mit dem xMega die 
WS2812er Leds anzusteuern, aber da ich wie gesagt in inline assembler 
nicht wirklich gut bin ;P Hab ichs leider immernoch nicht hinbekommen.

Evtl hast du ja noch eine Idee wie ich das aendern muesste damit das auf 
einem xMega32A4 läuft.

Das ist die aktuelle Funktion von dir die ich versucht habe anzupassen 
;P
Aber er sagt das er einen Fehler in Parameter 2(3) hat, das 
PORTD.OUTSET.

Die Interrupts lass ich bewusst an da ich die Länge des Strips abgreifen 
möchte über einen Interrupt. Was ja alles auf nem ATMega wunderbar 
funktioniert...

Vielen Dank im Vorraus für deine/eure Hilfe

// sends array to ws2812 port
void ws2812_sendarray(uint8_t *data,uint16_t datlen) {
    //irqoff
    uint8_t curbyte, ctr, masklo, maskhi;
    maskhi = PIN0_bm;

    masklo  =~ maskhi & PORTD.OUTSET;
    maskhi |= PORTD.OUTSET;

    while (datlen--) {
        curbyte =* data++;

        asm volatile(
        "       ldi %0,8        \n\t"
        "loop%=:out %2, %3      \n\t"
        "       lsl %1          \n\t"
        "       dec %0          \n\t"
        "       rjmp .+0        \n\t"
        "       brcs .+2        \n\t"
        "       out %2, %4      \n\t"
        "       rjmp .+0        \n\t"
        "       nop             \n\t"
        "       out %2, %4      \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" (curbyte), "I" (PORTD.OUTSET), "r" (maskhi), "r" 
(masklo)
        );
    }
    //irqon
}

[Tim . (cpldcpu)]

MichaelS98 schrieb:
> Evtl hast du ja noch eine Idee wie ich das aendern muesste damit das auf
> einem xMega32A4 läuft.
>
> Das ist die aktuelle Funktion von dir die ich versucht habe anzupassen
> ;P
> Aber er sagt das er einen Fehler in Parameter 2(3) hat, das
> PORTD.OUTSET.

Ich habe leider keinen XMEGA zum testen und kann das Manual nur kurz 
überfliegen. Du solltest Dir die Sektionen zu den I/O Ports genauer 
durchlesen.

 - OUTSET ist der falsche Port. Du benötigst OUT
 - Du musst PORTD auf einen der virtuellen I/O Ports mappen, damit er 
mit dem Befehl "Out" beschrieben werden kann. Steht ab s. 145 im Manual.


> Die Interrupts lass ich bewusst an da ich die Länge des Strips abgreifen
> möchte über einen Interrupt. Was ja alles auf nem ATMega wunderbar
> funktioniert...

Ich verstehe nicht so ganz, was Du damit erreichen willst? Bin aber 
skeptisch dass es sinnvoll ist, während der Routine einen Interrupt 
auszulösen.

[MichaelS98 (Gast)]

Habs mittlerweile hinbekommen :) Kleinen Grundkurs in inline assembler 
und dann gings auch ;P
Das mit den Interrupts ist auch nur bei der Initialisierung der Fall bei 
den weiteren Ausgaben wird der Interrupt auch ausgeschaltet.
Ich nutze nur einen Interrupt der auf Highlevel auslöst und dort ist 
meine "Rückleitung" für die LED Strips (soll heissen der letzte DOUT ist 
dadran)
um dynamisch die Lönge des Strips zu ermitteln.
Klappt auch mittlerweile wunderbar

Vielen Dank nochmal für deine Hilfe Tim :)

Gruß
Michael

[Andreas (Gast)]

Hi, ich habe eine Kette von 42 WS2811 Leds und würde am ende gern noch 
einen Atmega8 hängen um damit 7 high power Led Stromquellen zu steuern. 
Mein erster Ansatz war einfach die Chips dafür zu verwenden leider 
pfeift die Stromquelle bei der PWM-Frequenz der WS2811.

Deswegen meine Frage hat jemand schon mal überlegt eine Lib zu bauen die 
sich komplett wie ein WS2811 verhält also mit ein und ausgang, damit man 
den Transparent in eine kette hängen kann?

Der Grund für das ganze ist einfach ich würde zur Lampe mit den LEDs 
einfach gern nur 3 Kabel legen (+,GND,Din) und nicht noch LAN, USB usw. 
bzw den Steuer µC einfach beim Netzteil etwas entfernt.

Gruß
Andreas

[Tim . (cpldcpu)]

Andreas schrieb:
> Hi, ich habe eine Kette von 42 WS2811 Leds und würde am ende gern noch
> einen Atmega8 hängen um damit 7 high power Led Stromquellen zu steuern.
> Mein erster Ansatz war einfach die Chips dafür zu verwenden leider
> pfeift die Stromquelle bei der PWM-Frequenz der WS2811.

Ist das bei einer PWM-Ansteuerung nicht normal? Was willst Du denn 
sonst?

Andreas schrieb:
> Deswegen meine Frage hat jemand schon mal überlegt eine Lib zu bauen die
> sich komplett wie ein WS2811 verhält also mit ein und ausgang, damit man
> den Transparent in eine kette hängen kann?

Interessante Idee. Prinzipiell ist das relativ einfach. Du müsstest nur 
die steigende Flanke abwarten und dann nach 0.5µs den Eingang noch 
einmal einlesen. Dies ist dann der Bitwert. Siehe auch hier:

http://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

Schwierig ist allerdings, dass bei diesem Ansatz die CPU zu 100% 
beschäftigt ist. Abhilfe könnte hier ein Pin-Change Interrupt schaffen. 
Der muss allerdings sehr genaue getimed sein.

[Icke ®. (49636b65)]

Andreas schrieb:
> Deswegen meine Frage hat jemand schon mal überlegt eine Lib zu bauen die
> sich komplett wie ein WS2811 verhält also mit ein und ausgang, damit man
> den Transparent in eine kette hängen kann?

Bei dem ohnhin schon arschknappen Timing dürfte es schwierig bis 
unmöglich sein, diese Aufgabe mit einem ATmega zu lösen. Dafür brauchts 
schon leistungsfähigere Controller.

[Tim . (cpldcpu)]

Icke ®. schrieb:
> Bei dem ohnhin schon arschknappen Timing dürfte es schwierig bis
> unmöglich sein, diese Aufgabe mit einem ATmega zu lösen. Dafür brauchts
> schon leistungsfähigere Controller.

Unsinn. Das kann auch ein ATtiny. Allerdings macht der Controller dann 
sonst nicht all zu viel.

[Icke ®. (49636b65)]

Tim    schrieb:
> Allerdings macht der Controller dann sonst nicht all zu viel.

Das ist aber der Punkt. Was nützt es, wenn der Controller die Daten zwar 
weiterreichen kann, aber keinen Takt mehr für andere Aufgaben frei hat?

[Tim . (cpldcpu)]

Icke ®. schrieb:
> Das ist aber der Punkt. Was nützt es, wenn der Controller die Daten zwar
> weiterreichen kann, aber keinen Takt mehr für andere Aufgaben frei hat?

Kommt darauf an, was der Controller sonst noch machen soll. Zumindest 
während des Reset-Pulses wäre noch Zeit für Anderes.

[Stefan S. (sschultewolter)]

Hallo Tim,

ich habe ein kleines Problem mit deiner Libary und mir ist gerade nicht 
bewusst, woran das liegt.

Ich poste hier einmal die kurzen Ausschnitte, die wichtig sein können.

/*main.h*/
#define NUM_LEDS 60
struct cRGB leds[NUM_LEDS];

/* Eine kleine Funktion, die das struct beschreibt. Es handelt sich um eine Uhr mit vor/nachlaufenden Leds. Das u.a led == 60 nicht eintritt, eine kurze if Anweisung*/

void setPixel(uint8_t led, uint8_t r, uint8_t g, uint8_t b)
{
  if(led >= 60 && led < 65) led -= 60;
  else if(led <= 255 && led > 255) led = 60 - (255 - led);
  
  leds[led].r = r;
  leds[led].g = g;
  leds[led].b = b;
}

/* wird innerhalb while() aufgerufen, ansonsten läuft nichts nebenbei in der Dauerschleife */
void fadeClock(void)
{
  const uint8_t fade[32] /*PROGMEM*/ =
  {
    7, 15, 23, 31, 39, 47, 55, 63, 71, 79, 87, 95, 103, 111, 119, 127, 135, 143,
    151, 159, 167, 175, 183, 191, 199, 207, 215, 223, 231, 239, 247, 255
  };
  static uint8_t lastIndex;
  uint8_t index = millis() / 63;

  if(index != lastIndex)
  {
    lastIndex = index;
    memset(leds, 0, NUM_LEDS * 3);
    /*
    sets(second() - 2, 0, 0, fade[15-index]);
    sets(second() - 1, 0, 0, fade[31-index]);
    sets(second(), 0, 0, fade[31]);
    sets(second() + 1, 0, 0, fade[16+index]);
    sets(second() + 2, 0, 0, fade[0+index]);

    sets(minute(), 0, 255, 0);
    
    sets(hour() * 5-1, 255, 0, 0);
    sets(hour() * 5, 255, 0, 0);
    sets(hour() * 5+1, 255, 0, 0);
    */
    sets(59, 0, 0, 85);
    
    for(int i = 0; i < NUM_LEDS; i++) ws2812_setleds(leds,i);
  }
}

Die Leds 59 kann jedoch nicht angesteuert werden.

Habe zum testen, ob die Led doch einen abbekommen hat, eben mit dem 
Arduino getestet und der FastLed lib. Dort konnte 59 Problemlos 
angesteuert werden.


Gruß Stefan

[Tim . (cpldcpu)]

 for(int i = 0; i < NUM_LEDS; i++) ws2812_setleds(leds,i);

Was willst Du denn mit dieser Zeile bezwecken? Um das LED-Array auf den 
String zu schreiben reicht folgendes:

   ws2812_setleds(leds,NUM_LEDS);

[Stefan S. (sschultewolter)]

Danke, werde es testen. Hatte jetzt nicht nicht dran gedacht, dass damit 
das komplette Array geschrieben wird. Dann macht es auch sinn, wieso es 
zu Probs kommt, wenn er auf einmal das 60 fache schicken muss.

[Hain (Gast)]

Hallo,

kann es sein, dass die Methode meinen Timer0 beeinflusst?

Ich nutze die Libary für eine Uhr mit 60 Leds. Was ich jetzt bei dem 
ersten Test nicht gemacht habe, ist das Array nur schreiben, wenn sich 
etwas ändert. Derzeit ballert er jeden Durchlauf einmal das Array ab.

Blos wie verhält sich das auf Dauer? Ich habe vor, bis zu 16mal in der 
Sekunde das Array neu zu beschreiben. Ich habe vor, neben der 
gebastelten internen Uhr ebenfalls einen DS3231 einzusetzen, liegt als 
SOIC vor.

Jedoch möchte ich diese nicht jede Stunde mit dem dem Atmega abgleichen. 
Denn ich mache teils ein Fade und das sähe dann unschön aus.

Eine Abweichung von wenigen Sekunden pro Tag fände ich schon recht viel. 
Ich möchte einmal täglich den Wert mit der RTC vergleichen und wenn die 
differenz größer 10sec (evtl. noch geringer) und dann aktualisieren.

Sicherlich, meist bekommt man den Abgleich nicht mit, aber mich stört, 
dass man ihn mitbekommen kann.

So, noch einmal auf den Test zurück. Wie gesagt, ich habe den nun mal 
eine gewisse Zeit laufen lassen. Es waren 52Minuten, welche ich mit 
einer Stoppuhr als Referenz gemessen haben. Man konnte beim umschalten 
schon sheen, dass der Sekundenzeiger keinesfalls schnell arbeitet.

Eine Sekunde auf dem Atmega328P 16MHz brauchte etwa 79% länger als meine
Stoppuhr (01:32:55)

Kann man das ganze errechnen, wie sich das verhält, wenn ich nur 16x die 
Sekunde ein Update machen, wie hoch die Differenz vermutlich sein wird?

time.h

#ifndef TIME_H_
#define TIME_H_

#include <avr/io.h>
#include <avr/interrupt.h>

void time_init(void);
void time_set(uint8_t hour, uint8_t minute, uint8_t second);
uint8_t hour(void);
uint8_t minute(void);
uint8_t second(void);
int16_t millis(void);
uint32_t millis2(void);

#endif /* TIME_H_ */

time.c

#include "time.h"

volatile unsigned int h;
volatile unsigned int min;
volatile unsigned int sec;
volatile unsigned int ms;
volatile unsigned int ms2;

void time_init(void)
{
  TCCR0A = (1<<WGM01);
  TCCR0B |= (1<<CS01 | 1<<CS00);
  OCR0A = 249;
  TIMSK0 |= (1<<OCIE0A);
  sei();
}

ISR (TIMER0_COMPA_vect)
{
  ms++;
  ms2++;
  if(ms == 1000)
  {
    sec++;
    ms = 0;
    if(sec == 60)
    {
      min++;
      sec = 0;
    }
    if(min == 60)
    {
      h++;
      min = 0;
    }
    if(h == 24) h = 0;
  }
}

uint8_t hour(void)
{
  return h;
}

void time_set(uint8_t hour, uint8_t minute, uint8_t second)
{
  h = hour;
  min = minute;
  sec = second;  
}

uint8_t minute(void)
{
  return min;
}

uint8_t second(void)
{
  return sec;
}

int16_t millis(void)
{
  return ms;
}

uint32_t millis2(void)
{
  return ms2;
}

[Hain (Gast)]

So, ich habe noch einmal einen Test über 2h laufen lassen. Diesmal wird 
jede Sekunde einmal das Array neugeschickt.

Nun liegt der Fehler bei ca 1,3% (insgesamt ca 10 Sekunden Differenz). 
Damit kann ich leben, zu mal bei diesem Testprobanten sowieso nur SMD 
Resonator verbaut ist. Das entspricht in etwa der Fehlerquote.

Werde nun noch mal den Test bis morgen früh durchführen, wenn ich nun 
jede Sekunde 16mal den Wert ändere.

[Tim . (cpldcpu)]

Hain schrieb:
> kann es sein, dass die Methode meinen Timer0 beeinflusst?

Den Timer nicht, aber die Interrupts werden natürlich gesperrt. Versuche 
doch einmal, die Interrupt-Frequenz zu verringern. Der Fehler wird immer 
dann auftauschen, wenn während des WS2812 calls zwei interrupts 
aufgerufen werden.

[Tim . (cpldcpu)]

Ich habe mir mal ein paar neue LEDs angeschaut, die APA102:

http://cpldcpu.wordpress.com/2014/08/27/apa102/

Diese LEDs lassen sich per SPI ansteuern. Bin etwas unschlüssig, ob es 
überhaupt Sinn macht, diese auch in der Lib zu unterstützen.

[Di P. (drpepper)]

Sieht sehr interessant aus, danke für die Info.

[Marc V. (Firma: Vescomp) (logarithmus)]

Tim    schrieb:
> Diese LEDs lassen sich per SPI ansteuern. Bin etwas unschlüssig, ob es
> überhaupt Sinn macht, diese auch in der Lib zu unterstützen.

 Ja, aber in DaBla ist von 512KHz und 4 Bytes die Rede. Das ist weniger
 als WS28xx.

[Karol B. (johnpatcher)]

Tim    schrieb:
> Diese LEDs lassen sich per SPI ansteuern. Bin etwas unschlüssig, ob es
> überhaupt Sinn macht, diese auch in der Lib zu unterstützen.

Ich sehe hierfür keine Notwendigkeit, um ehrlich zu sein. SPI 
unterscheidet sich deutlich von dem WS2811/12 "Interface und wird meist 
direkt in Hardware umgesetzt. Neben einer kurzen Initialisierung, 
beschränkt sich das Senden ja dann letztendlich auf das Schreiben in ein 
Register. Bei Controller mit DMA kann das dann sogar vollständig im 
Hintergrund ablaufen. Besser geht es kaum.

Mal sehen, ob sich diese LEDs bzw. entsprechend bestückte Streifen 
durchsetzen werden und ggf. sogar zu ähnlichen Preisen gehandelt werden. 
Wünschenswert wäre es alle Male.

Mit freundlichen Grüßen,
Karol Babioch

[Tim . (cpldcpu)]

Marc Vesely schrieb:
> Ja, aber in DaBla ist von 512KHz und 4 Bytes die Rede. Das ist weniger
>  als WS28xx.

Das scheint mir nur ein Beispiel zu sein. Ich hatte mit 4 MHz noch keine 
Probleme. Ich werde mal nachfragen, ob es so etwas wie eine 
Spezifikation gibt...

Karol Babioch schrieb:
> Mal sehen, ob sich diese LEDs bzw. entsprechend bestückte Streifen
> durchsetzen werden und ggf. sogar zu ähnlichen Preisen gehandelt werden.
> Wünschenswert wäre es alle Male.

Glaube nicht, dass die so schnell günstiger werden. Für das low-price 
Segment hat der Anbeite die APA104, einen WS2812B clone.

[Tim . (cpldcpu)]

Anbei ein Flyer den ich von der Firma bekommen habe. Sie planen auch 
LEDS mit 12 bit, sowie kleine Varianten mit 3.5x3.5 mm. Klingt 
interessant.

[Axel H. (axelh)]

Hi,

Die mcd Werte sind aber niedrig. Oder verwechsel ich da was?

Axel

[BADCABL1E (Gast)]

Hallo
Ich brauch mal ein bisschen Hilfe! Ich nutze ein Atmega320pu und schaffe 
es einfach nicht die LEDs zu laufen zu bringen!
Ich bin mir nicht sicher ob es an meinem Programm liegt oder an dem zu 
heißem  verlöten der LED liegt!
Kann ich bei der Lib von oben etwas richtig falsch machen?
Was müsste ich alles ändern?

Ich wünsche noch eine schöne Woche

[Karol B. (johnpatcher)]

BADCABL1E schrieb:
> Kann ich bei der Lib von oben etwas richtig falsch machen?

Ja.

Falls du aber wirklich konkrete Hilfe möchtest, dann musst du Details 
(Beispielprogramm, Fehlermeldungen, Beschreibung des Fehlverhaltens, was 
hast du überhaupt vor, was sind die Voraussetzungen, usw.) herausrücken. 
Dein Beitrag in seiner aktuellen Form ist ungefähr so nützlich wie die 
Aussage "Mein Auto springt nicht an".

Mit freundlichen Grüßen,
Karol Babioch

[BADCABL1E (Gast)]

Das ist mir ja auch klar. Vielen Dank für die schnelle Antwort!
Leider kann ich nicht viele mehr sagen... Ich bekomme keine 
Fehlermeldung und ein Signal erhalte ich auch. Aber nichts leuchtet.
Ich will die LED nur zum Laufen bringen und dann würde ich weiter 
schauen.

[BADCAB1E (Gast)]

Hallo
Ich versuche es noch einmal nach einigem gebastel.
Mein Atmega328pu läuft mit einem internen 16mhz tackt. Ich nutze den 
Code von  oben (ohne Änderungen) und definiere den PINB1 als Output für 
das Signal. Wenn ich nun das alles anschalte bekomme ich ein Weißes 
Licht (ändern Läst sich das nicht)
Ich entschuldige mich für meine vorherigen Posts und hoffe diese 
Informationen sind hilfreicher ;)
Noch ein schönes Wochenende und vielen Dank!

[Marc V. (Firma: Vescomp) (logarithmus)]

BADCAB1E schrieb:
> Mein Atmega328pu läuft mit einem internen 16mhz tackt. Ich nutze den

 ???

[BADCAB1E (Gast)]

sorry ich meinte, dass ich für die Delay Funktion F_CPU=16000000 
definiert habe

[Tim . (cpldcpu)]

BADCAB1E schrieb:
> Ich nutze den
> Code von  oben (ohne Änderungen) und definiere den PINB1 als Output für
> das Signal. Wenn ich nun das alles anschalte bekomme ich ein Weißes

Welchen Code nutzt Du denn genau?

Die aktuelle Version liegt hier:

https://github.com/cpldcpu/light_ws2812

[BADCAB1E (Gast)]

genau die! Und um Fehler auszuschießen habe das RGB_blinky.c auch schon 
verwendet. Aber ich hab immer weißes Licht.

[Tim . (cpldcpu)]

Hast Du schon die Punkte unter "Troubleshooting" abgearbeitet?

Ansonsten passen vermutlich die tatsächliche Taktfrequenz und die im 
Code einstellte nicht zusammen.

[BADCAB1E (Gast)]

"Troubleshooting" hab ich durchgearbeitet... Das was ich nicht verstehe 
ist, dass ich weißes Licht erhalte --> Das bedeutet doch ich steuere 
R,G,B an?
Ich vermute, da ich ja ein Signal bekomme, dass es an der Frequenz 
liegt.
Wo kann ich die Taktfrequenz einstellen/ Prüfen? Ich habe sie zur Zeit 
in der Toolchain bei Atmel-studio festgelegt.

[Tim . (cpldcpu)]

SO etwas kann passieren, wenn Deine tatsächliche CPU-Clock niedriger als 
der F_CPU wert sind.

Hast Du die Fuses richtig gesetzt?

[BADCAB1E (Gast)]

Mein freund hat ein Oszilloskop (zum Glück) Ich glaube, dass das zu 
schnell ist(Bild)! Wenn das so ist wie kann ich es ändern!
Vielen vielen dank für die schnellen Antworten!

[Tim . (cpldcpu)]

Nö. Ist zu langsam. Jeder Puls sollte 1.25µs haben, bei Dir sind es 
2.5µs.

[BADCAB1E (Gast)]

Also ich hab jetzt die Taktfrequenz auf 8mhz runterkorrigier. Jetzt 
leuchtet die LED Grün! Reicht mir aber immer noch nicht ;) Was könnte 
ich denn anders machen oder noch besser was mache ich denn falsch?
    MfG

[Conny G. (conny_g)]

Ich kenn jetzt das Blinky nicht, aber Deine Frage sagt es ist nicht 
grün, was Du wolltest.
Dein Signal sieht nach 0 255 0 aus. Bei den WS2812 wäre das Rot (GRB als 
Reihenfolge), bei den WS2811 ist es grün (RGB Reihenfolge).

Vielleicht musst Du der Library noch sagen, welchen Chip Du hast?

[Joachim B. (jar)]

Tim    schrieb:
> Nö. Ist zu langsam. Jeder Puls sollte 1.25µs haben, bei Dir sind
> es
> 2.5µs.

ich kam mit dieser und fastLED 1 auch nicht so klar, 100 LEDs brauchten 
300ms.
Jetzt mit fastLED2 bin ich bei 3ms

[Icke ®. (49636b65)]

BADCAB1E schrieb:
> Was könnte ich denn anders machen oder noch besser

Eine halbe Stunde hinsetzen und VERSTEHEN lernen, für was die Routine 
zuständig ist und für was nicht. Ihre Aufgabe ist das Senden der Daten 
zu den WS2812, nicht aber das Bereitstellen der Daten. Ich bezweifle 
auch, daß eine Korrektor des Taktes nach unten hilfreich ist, wenn die 
Pulse ohnehin schon zu lang sind.

[Conny G. (conny_g)]

Icke ®. schrieb:
> BADCAB1E schrieb:
>> Was könnte ich denn anders machen oder noch besser
>
> Eine halbe Stunde hinsetzen und VERSTEHEN lernen, für was die Routine
> zuständig ist und für was nicht. Ihre Aufgabe ist das Senden der Daten
> zu den WS2812, nicht aber das Bereitstellen der Daten. Ich bezweifle
> auch, daß eine Korrektor des Taktes nach unten hilfreich ist, wenn die
> Pulse ohnehin schon zu lang sind.

Er hat nicht den Takt geändert, sondern F_CPU richtig gesetzt.
Das war mit 16 Mhz das doppelte des realen internen Taktes, also sind 
die Delays dann ungewollt doppelt so lang.

[BADCAB1E (Gast)]

Hallo
Ich hab mich heute noch einmal vor den PC gehockt... Nachdem ich den 
Code (ohne Änderung) noch einmal auch den Chip geflasht habe, blinkten 
die LEDS! Ich verstehe zwar nichts, aber wenn es geht ist es mir auch so 
recht;)
Ich bedanke mich herzlichst bei allen die mir geholfen haben!

Mit freundlichen Grüßen
BADCAB1E

Und da ich Icke® nicht ausschließen möchte, bedanke ich mich für den 
sinnlosesten Kommentar den ich gelesen habe! Die Zeit den zu schreiben 
hätte man sicherlich besser nutzen können.

[Icke ®. (49636b65)]

BADCAB1E schrieb:
> Die Zeit den zu schreiben hätte man sicherlich besser nutzen können.

In der Tat Zeitverschwendung. Den Beweis lieferst du gleich mit:

BADCAB1E schrieb:
> Ich verstehe zwar nichts, aber wenn es geht ist es mir auch so
> recht;)

[Tobias N. (silberkristall)]

Oh man oh man.

Selbst ICH habe die lib sofort ans laufen bekommen. Leute gibts :-P

[Joachim B. (jar)]

Tobias N. schrieb:
> Selbst ICH habe die lib sofort ans laufen bekommen. Leute gibts :-P

ich habe es ja auch geschafft, aber warum 100 LEDs 300ms brauchen hat 
mir niemand sagen können. Dann habe ich fastLED probiert, dito, wieder 
nur Sprüche von anderen.

Weitergegoogelt und fastLED2 gefunden und siehe da 3ms für 100 LEDs was 
ziemlich genau passt, ein Bit 1,25µs (bei 16MHz) mal 24 Bit für eine LED 
in RGB = 30µs x 100 LEDs = 3ms

so dachte ich mir das, aber vorher 2 Libs vergebens probiert und selbst 
an mir gezweifelt.

[Di P. (drpepper)]

Joachim B. schrieb:
> selbst an mir gezweifelt.

Der erste Schritt in die richtige Richtung :)

[Joachim B. (jar)]

Di Pi schrieb:
> Der erste Schritt in die richtige Richtung :)

(wieder so ein Kommentar der kein bischen hilft......)
aber trotzdem gelöst, wenn auch nicht mit der ws2811/12 oder fastLED1

fastLED2 läuft wie erwartet, was soll ich da noch nach den anderen oder 
meinen vermeintlichen Fehler suchen falls es den überhaupt gibt.

[Cyblord -. (cyblord)]

Joachim B. schrieb:
> (wieder so ein Kommentar der kein bischen hilft......)
> aber trotzdem gelöst, wenn auch nicht mit der ws2811/12 oder fastLED1
>
> fastLED2 läuft wie erwartet, was soll ich da noch nach den anderen oder
> meinen vermeintlichen Fehler suchen falls es den überhaupt gibt.

Nutze auch die lib von Tim aber ich hab keine Ahnung was dein gelaber 
von wegen fastLED dauernd soll. Was ist das? Was hat das hier mit dem 
Thread zu tun?
Du hast halt irgendwelche Arduino-Probleme. Kannst du damit nicht in 
arduino.cc rumnerven?

[Joachim B. (jar)]

cyblord ---- schrieb:
> ich hab keine Ahnung was dein gelaber
> von wegen fastLED dauernd soll. Was ist das? Was hat das hier mit dem
> Thread zu tun?

OK ich erkläre es dir

zuerst hatte ich die wsLIB vom Tim versucht, auf dem puren AVR 
(Lochraster, nix Arduino!)

lief für 40 LEDs prima und ich hatte keinen Grund am Timing zu zweifeln, 
nicht mal nachgemessen.

Dann wollte ich die wordclock bauen, als ich die 117 LEDs fertig 
bestückt hatte kam der erste Test, alle LEDs im Farbwechsel und ich sah 
wie die Farben von der ersten zur letzten LED durchgereicht wurden und 
habe sagenhafte 300ms gemessen was auch bei den lahmen 800kHz nicht sein 
dürfte.

Ich recherchierte und fand fastLED also diese wahlweise mit #defines 
installiert und beide gegeneinander vermessen. Kein nennenswerter 
Unterschied ca. 5% also im Ergebnis auch zu lahm.

Ich wollte schon des Projekt mit den WS erden und auf LPD umsteigen 
(2MHz clock) und fand dann fastLED2 was das gewünschte Ergebnis bringt.

Mir fehlt einfach der Beweis das mit der WS Lib 100 RGB LEDs in 3ms zu 
schalten sind, das ist kein Gemecker in Richtung Tim, nur meine 
Feststellung und mit euren Komentaren komme ich halt (wie so oft in 
Foren) kein Stück weiter.

Tims LIB funkioniert, Anfänger so wie ich freuen sich über die ersten 
Farbspiele die leicht umzusetzen sind, trotzdem läuft es nicht rund. 
PUNKT

Nichts weiter wollte ich dem TO mitteilen und wo es eventuell klemmt.

[Icke ®. (49636b65)]

Joachim B. schrieb:
> Mir fehlt einfach der Beweis das mit der WS Lib 100 RGB LEDs in 3ms zu
> schalten sind

Der Beweis ergibt sich schon aus der Tatsache, daß die Ansteuerung der 
WS2812 gar nicht funktionieren kann, wenn die Routine grob von dem im 
Datenblatt angegegebenen Timing abweichen würde. Die Übertragung eines 
Bits dauert 1,25µs, macht also bei 24 Bit 30µs pro LED. 100 mal 30µs 
ergeben -tataa- genau 3ms plus ~50µs Reset. Laut Datenblatt kann das 
Timing pro Bit bis zu 300ns abweichen, in der Praxis scheinen sie sogar 
etwas mehr zu vertragen. Wir reden allerdings von Zeiten im Bereich 
einstelliger µs und nicht vom Faktor 100. Wenn bei dir die Übertragung 
300ms für 100 LEDs dauern soll, dann kann das schon theoretisch 
unmöglich sein. Du hast entweder einen Meßfehler oder du mißt etwas 
anderes.

Joachim B. schrieb:
> und ich sah
> wie die Farben von der ersten zur letzten LED durchgereicht wurden

Auch das ist nicht möglich, weil die Farben in der gesamten Kette erst 
nach dem Reset-Puls übernommen werden und zwar nahezu gleichzeitig.

[Cyblord -. (cyblord)]

> Joachim B. schrieb:
>> Mir fehlt einfach der Beweis das mit der WS Lib 100 RGB LEDs in 3ms zu
>> schalten sind

Allein schon wenn man den Code von Tim anschaut, sieht dass hier 
nirgendwo so eine große Verzögerung auftreten kann. Der druchläuft die 
Hauptschleife so schnell wie möglich und somit ergibt sich die Zeit für 
X LEDs automatisch.

Icke ®. schrieb:
> Joachim B. schrieb:
>> und ich sah
>> wie die Farben von der ersten zur letzten LED durchgereicht wurden
>
> Auch das ist nicht möglich, weil die Farben in der gesamten Kette erst
> nach dem Reset-Puls übernommen werden und zwar nahezu gleichzeitig.

Möglich schon. Aber das liegt dann nicht an der lib sondern am Programm 
welches die lib mit Daten füttert. Er hat halt ein Lauflicht 
programmiert ;-)

Ne also Joachim, mal ehrlich, deine Aussagen hier zeugen schon von 
großer Unbedarftheit. In einem solchen Fall sollte man nicht von 
Beweisen schwadronieren und irgendwelche Verzögerungen unterstellen. 
Eigenen Code checken und den fixen wär angesagt. Und nicht so lange libs 
austesten bis es zufällig mal geht.

[Tim . (cpldcpu)]

Joachim B. schrieb:
> Dann wollte ich die wordclock bauen, als ich die 117 LEDs fertig
> bestückt hatte kam der erste Test, alle LEDs im Farbwechsel und ich sah
> wie die Farben von der ersten zur letzten LED durchgereicht wurden und
> habe sagenhafte 300ms gemessen was auch bei den lahmen 800kHz nicht sein
> dürfte.

Klingt, als wenn Du ws2812_setleds in einer Schleife aufgerufen hast. 
Das ist natürlich Unsinn, da der Aufruf das ganze Array auf einmal 
beschreibt. Es wird kein Index, sondern die Länge übergeben. Es gibt 
einfach keine Möglichkeit, die LEDS schnell oder langsam zu beschreiben. 
Die Geschwindigkeit ist immer die gleiche.

Ich muss mich allerdings den Vorrednern anschließen. Du verunsicherst 
mit solchen Kommentaren nur andere Anfänger. Wäre besser, wenn Du Dein 
konkretes Problem beschreiben würdest (mit Code!), anstatt solche 
Statements abzugeben.

[Tim . (cpldcpu)]

Es gibt ein Update zur APA102:

https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/

[Joachim B. (jar)]

Tim    schrieb:
> Klingt, als wenn Du ws2812_setleds in einer Schleife aufgerufen hast.
> Das ist natürlich Unsinn,

hmmm, ist ja Schnee von vorgestern, ich hatte diese LIB und fastLED 
beide auf dem Chip und konnte per #define beide probieren und beide 
haben für 117 LEDs und einen Farbwechsel nicht einzeln aufgerufen 300ms 
mit dem Oszi vermessen. Komischerweise hatte ich mit fastLED2 sofortigen 
Erfolg, damit war bestätigt das die LEDs pro Farbset nur die geschätzten 
30µs (1,5µs x24 bit) brauchen und 100 davon ca. 3ms.

Nun könnt ihr mich alle füür blöd halten, aber warum habe ich das denn 
sofort mit fastLED2 geschafft?

Die einzige Erklärung die ich noch habe, falsche LIB erwischt, falsch 
aufgerufen, was ich aber nicht glaube

ich wollte gerade noch mal nachsehen, aber der Link
Beitrag "Re: Lightweight WS2811/WS2812 Library"

führt zu:
https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812

page not found, in Schelm der Böses dabei denkt..... OK die Vorversionen 
sind alle rausgeschmissen, kann ich verstehen

aber wo sollte mein Fehler sein wenn ich

#define MAXLEDS 117
for(i=0;i<MAXLEDS;i++)
{
  value.b = 255; value.g = 0; value.r = 0; // RGB Value -> Blue
  LED.set_crgb_at(i, value); // Set value at LED found at index 0
}

CONTRL_LED_ON; //macro eine single_LED am anderen Port einschalten
  LED.sync(); // Sends the value to the LED
CONTRL_LED_OFF; //macro single_LED am anderen Port ausschalten

und die T on Time der CONTRL_LED mit dem Osi prüfe?

aber egal, ich hatte 2 LIBs versucht bei der 3ten Erfolg, es ist nun 
müssig zu suchen woran es lag, könnte ich natürlich wiederholen, aber 
mag ich grad nicht.

Vielleicht hatte ich auch nur eine vorvorfinal Version erwischt.

dann tut mir meine Kritik am TO leid.

[Tim . (cpldcpu)]

Joachim B. schrieb:
> führt zu:
> https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812
>
> page not found, in Schelm der Böses dabei denkt..... OK die Vorversionen
> sind alle rausgeschmissen, kann ich verstehen

Hier sind alle alten Versionen zu finden:
https://github.com/cpldcpu/light_ws2812/commits/master

Zum Rest kann ich nicht viel ergänzen. Du hast leider immer noch nicht 
den tatsächlich von Dir benutzten Code gepostet. Allerdings verstärkt 
sich mein Verdacht von oben...

[Joachim B. (jar)]

Tim    schrieb:
> Du hast leider immer noch nicht
> den tatsächlich von Dir benutzten Code gepostet.

mir wurde unterstellt

Tim    schrieb:
> Klingt, als wenn Du ws2812_setleds in einer Schleife aufgerufen hast.

und das hatte ich nicht, du kannst mich für blöd halten aber ich weiss 
was ich getippt hatte:

Joachim B. schrieb:
> for(i=0;i<MAXLEDS;i++)
> {
>   value.b = 255; value.g = 0; value.r = 0; // RGB Value -> Blue
>   LED.set_crgb_at(i, value); // Set value at LED found at index 0
> } // LED set in der Schleife
>
> CONTRL_LED_ON; //macro eine single_LED am anderen Port einschalten
>   LED.sync(); // Sends the value to the LED
> CONTRL_LED_OFF; //macro single_LED am anderen Port ausschalten
// Messung ausserhalb der Schleife

komisch nur, das ich deine erste LIB die ich funktionierend an einem 
puren Atmel auf eine Lochraster selbst gebaut mit einer Arduino LIB aus 
anderer Quelle (ich nehme mal an nicht von dir) am nanoV3 verglichen 
hatte und das beide 300ms für die 100 LEDs benötigten.

> Allerdings verstärkt sich mein Verdacht von oben...

nun ja bleibt dir unbenommen.

ist kein Problem, deine LIB ist ja hier nicht nicht für Arduino, ich 
brenne das noch mal auf die pure AVR Musteplatte s.o.

welche Version ist jetzt aktuell? bitte Link.

[Tim . (cpldcpu)]

Die aktuelle Version ist immer hier:
https://github.com/cpldcpu/light_ws2812

Und hier gibt eine Übersicht der Releases. Ich habe aber nicht den 
Eindruck, dass das Feature von vielen genutzt wird:
https://github.com/cpldcpu/light_ws2812/releases

[Joachim B. (jar)]

Tim    schrieb:
> Klingt, als wenn Du ws2812_setleds in einer Schleife aufgerufen hast.

könnte glatt sein (sorry)

aber dann muss ich ein Verständnisfehler zwischen set_led und send_array 
haben

im blinky.c wurde nirgends send_array aufgerufen und das war die 
Vorlage.

Wie würde es denn in deiner LIB richtig laufen?

also set_led und send_array unabhängig? (dann könnte ich send ja 
vermessen und meine Falschbehauptung selber widerlegen).

dann würde set led nicht einzeln erfolgen sondern wenn fertig mit 
send_array?

tut mir echt leid wenn ich hier falsches geschrieben hatte, aber ohne 
bessere Erklärung wie man das nutzt ist mein Fehler verständlich.

[Tim . (cpldcpu)]

Joachim B. schrieb:
> Tim    schrieb:
>> Klingt, als wenn Du ws2812_setleds in einer Schleife aufgerufen hast.
>
> könnte glatt sein (sorry)

Ok, danke fürs Nachforschen! Eine andere Erklärung hätte mich sehr 
erstaunt.

> aber dann muss ich ein Verständnisfehler zwischen set_led und send_array
> haben
> im blinky.c wurde nirgends send_array aufgerufen und das war die
> Vorlage.

Ja, und warum rufst Du es dann in Deinem Code auf? Weder im Readme, noch 
in dem Beispiel wird diese Funktion erwähnt. Ich sehe aber, woher die 
Verwechslung kam.

"send_array" ist eine interne Funktion, die im Wesentlichen aus 
Kompatibilitätsgründen zur v1.0 vorhanden ist. Grund für das neue 
Interface ist, dass viele die Anzahl der LEDs und Bytes verwechselt 
haben und mit dem Drumherum (INT sperren, delay für reset) nicht zurecht 
kamen.

> Wie würde es denn in deiner LIB richtig laufen?
>
> also set_led und send_array unabhängig? (dann könnte ich send ja
> vermessen und meine Falschbehauptung selber widerlegen).

Die Funktion heisst "set_leds", weil sie mehrere LEDs beschreibt. Die 
LEDS werden im Array übergeben. Es ist überhaupt nur dieser eine 
Funktionsaufruf notwendig.

> tut mir echt leid wenn ich hier falsches geschrieben hatte, aber ohne
> bessere Erklärung wie man das nutzt ist mein Fehler verständlich.

Mir fällt auf, dass ich vielleicht noch ein Beispiel zum Beschreiben 
ganzer Strings hinzufügen sollte. Das sollte einige Missverständnisse 
ausräumen.

[Joachim B. (jar)]

Tim    schrieb:
> Die Funktion heisst "set_leds", weil sie mehrere LEDs beschreibt. Die
> LEDS werden im Array übergeben. Es ist überhaupt nur dieser eine
> Funktionsaufruf notwendig.
>
>> tut mir echt leid wenn ich hier falsches geschrieben hatte, aber ohne
>> bessere Erklärung wie man das nutzt ist mein Fehler verständlich.
>
> Mir fällt auf, dass ich vielleicht noch ein Beispiel zum Beschreiben
> ganzer Strings hinzufügen sollte. Das sollte einige Missverständnisse
> ausräumen.

sorry das verstehe ich grad noch nicht, ich meinte wie setze ich die 
Farben, Helligkeiten einzelner LEDs im Array bevor set_leds aufrufe?

Ich möchte ja für meine Wordclock nur die nötigen LEDs setzen und dann 
komplett abschicken.

[Tim . (cpldcpu)]

Joachim B. schrieb:
> sorry das verstehe ich grad noch nicht, ich meinte wie setze ich die
> Farben, Helligkeiten einzelner LEDs im Array bevor set_leds aufrufe?

Wie man halt Arrays in Ansi-C beschreibt:

   struct cRGB led[16]; // array mit 16 leds reservieren

   led[0].r=255;led[0].g=00;led[0].b=0;    // Write red to led1
   led[1].r=255;led[1].g=00;led[1].b=0;    // Write red to led2
   led[2].r=255;led[2].g=00;led[2].b=0;    // Write red to led3

Alternativ kannst Du auch die ganze Struct (cRGB) gleichzeitig schreiben 
und Dir vorher Farben definieren.

struct cRGB cblack={0x00,0x00,0x00};
struct cRGB cwhite={0xff,0xff,0xff};

led[0]=cblack;
led[1]=cwhite;

[Joachim B. (jar)]

Tim    schrieb:
> Mir fällt auf, dass ich vielleicht noch ein Beispiel zum Beschreiben
> ganzer Strings hinzufügen sollte. Das sollte einige Missverständnisse
> ausräumen.

dazu fällt mir noch ein, ist denn set_led nicht ein "ungünstiger" Name 
für eine Funktion die nur die LED im Array setzen soll?

ich fand

Tim    schrieb:
> "send_array" ist eine interne Funktion, die im Wesentlichen aus
> Kompatibilitätsgründen zur v1.0 vorhanden ist.

doch irgendwie verständlicher,

also LED setzen im Array mit der Funktion set_led und abschicken mit 
send_array.

Da wären alle Missverständnisse doch selbsterklärend ausgeräuumt.

[Tim . (cpldcpu)]

Ja, da hast Du vielleicht recht. Aber es macht wenig Sinn das jetzt zu 
ändern, da es nur noch mehr Verwirrung stiften würde.

[Joachim B. (jar)]

Tim    schrieb:
> Ja, da hast Du vielleicht recht. Aber es macht wenig Sinn das jetzt zu
> ändern, da es nur noch mehr Verwirrung stiften würde.

OK, wenigstens DANKE das du mich nicht für doof hältst

cyblord ---- schrieb:
> Nutze auch die lib von Tim aber ich hab keine Ahnung was dein gelaber
> von wegen fastLED dauernd soll.
Di Pi schrieb:
> Joachim B. schrieb:
>> selbst an mir gezweifelt.
>
> Der erste Schritt in die richtige Richtung :)

[Cyblord -. (cyblord)]

Joachim B. schrieb:
> Tim    schrieb:
>> Ja, da hast Du vielleicht recht. Aber es macht wenig Sinn das jetzt zu
>> ändern, da es nur noch mehr Verwirrung stiften würde.
>
> OK, wenigstens DANKE das du mich nicht für doof hältst
>
> cyblord ---- schrieb:
>> Nutze auch die lib von Tim aber ich hab keine Ahnung was dein gelaber
>> von wegen fastLED dauernd soll.
> Di Pi schrieb:
>> Joachim B. schrieb:
>>> selbst an mir gezweifelt.
>>
>> Der erste Schritt in die richtige Richtung :)

Du hast die lib, wie von uns vermutet, einfach nur falsch benutzt. 
PUNKT.
Ob das nun an angeblich ungünstigen Funktionsnamen liegt, sei 
dahingestellt. Nur lag das Problem eben nicht in der lib, sondern in 
DEINEM Code der die lib nutzt. Trotzdem hast du auf die lib gehauen und 
den Fehler dort hingeschoben.
Also verdreh das jetzt hier nicht.

[Joachim B. (jar)]

cyblord ---- schrieb:
> Du hast die lib, wie von uns vermutet, einfach nur falsch benutzt.
> PUNKT.

ja und?

> Ob das nun an angeblich ungünstigen Funktionsnamen liegt, sei
> dahingestellt.

woran denn sonst, schliesslich kann ich lesen, wenn es led_set gibt muss 
das noch lange nicht led_sync sein, ich kann nämlich unterscheiden 
zwischen setzen und syncen, aber egal, DU sollst RECHT behalten wenn es 
dir dann besser geht.


> Nur lag das Problem eben nicht in der lib, sondern in DEINEM Code der die lib 
nutzt. Trotzdem hast du auf die lib gehauen und
> den Fehler dort hingeschoben.

ich habe 2 verschiedene LIB genutzt und gleiche Ergebnisse bekommen, 
worauf sollte ich es denn sonst schieben?
uns als ich die dritte LIB nutzte klappte es wie erwartet.

> Also verdreh das jetzt hier nicht.
und was motzt du hier rum?
ich verdrehe nix, aber du pöbelst.

[Di P. (drpepper)]

Schluss jetzt!

[Joachim B. (jar)]

ich wollte noch mal ne kleine Rückmeldung geben

ich habe ja einige Platinen hiervon bestellt und schon 2 aufgebaut:
https://github.com/JChristensen/mini1284

vorher arbeitete ich mit der Arduino FastLED Lib am m328p aber am m1284p 
funktionierte die nicht, Timingproblem, alle Farbwerte 24 x 1,5µs = 30 
µs wurden zu langsam übertragen, 33µs und die WS2812b spielten nicht 
mit.

Erst dachte ich an einen Ausreisser, baute den m1284p 2x auf.

Dann wechselte ich dem mit 16 MHz programmierten m1284p den Quarz zu 
18,432MHz und siehe da, Timing passt 30µs WS2812b läuft aber mit der 
Verständigung zur Arduino IDE war es nun aus.

Dann erinnerte ich mich hieran und band die ws2812b LIB ein die es ja 
nun auch vom Tim als Arduino LIB gibt und siehe da es läuft! auch auf 
dem m1284p

Dafür schon mal ein Riesendanke...

nun noch meinen ganzen Code auf WS2812 Lib umstricken.....

mühsam.....

[Ibram G. (ibram)]

Hallo Tim,

Ich nutze Deine Lib auf dem Arduino Uno.
Klappt hervorragend im direkten Aufruf.
Da ich mehrere LED Streifen unterschiedliche Aufgabe, aber gleicher 
Logik beabsichtige (Farbverteilung an Hand von Parametern, Löschen der 
nicht genutzten LEDs), bietet es sich an, die Task in Subroutinen zu 
verpacken und mit dem jeweiligen LED-Objekt und Parametersatz zu rufen.

Ich bin noch nicht ganz fertig damit, aber auch das scheint lässig und 
ohne Verrenkungen möglich zu sein - Prima Design!

Vielen Dank,
Tarik

[Simon (Gast)]

Hallo Tim,

gibt es eine Möglichkeit, die Leds zu Gruppieren, damit das struct/Array 
entsprechend klein sein kann?


Ich habe 100 Leds. Wobei immer 10 Stück hintereinander den gleichen Wert 
haben sollen.

Müsste halt eine externe Variable oder einen weiteren Parameter haben, 
um die Anzahl an gleicher aufeinaderfolgender Leds

Wenn ich das richtig sehe, müsste ich nach dem Entritt in While schleife 
dafür sorgen, dass sich jeweils nach 3 Durchläufen das Muster 
wiederholt, komm da aber noch nicht mit klar. Bin noch recht neu dabei. 
Könnte mir da evtl. jemand die Funktion kurz anpassen?

void inline ws2812_sendarray_mask(uint8_t *data,uint16_t datlen,uint8_t maskhi)
{
  uint8_t curbyte,ctr,masklo;
  uint8_t sreg_prev;

  masklo  =~maskhi&ws2812_PORTREG;
  maskhi |=        ws2812_PORTREG;
  sreg_prev=SREG;
  cli();
  
  while (datlen--) {
    
    curbyte=*data++;
    
    asm volatile(
    "       ldi   %0,8  \n\t"
    "loop%=:            \n\t"
    "       out   %2,%3 \n\t"    //  '1' [01] '0' [01] - re
    #if (w1_nops&1)
    w_nop1
    #endif
    #if (w1_nops&2)
    w_nop2
    #endif
    #if (w1_nops&4)
    w_nop4
    #endif
    #if (w1_nops&8)
    w_nop8
    #endif
    #if (w1_nops&16)
    w_nop16
    #endif
    "       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]
    #if (w2_nops&1)
    w_nop1
    #endif
    #if (w2_nops&2)
    w_nop2
    #endif
    #if (w2_nops&4)
    w_nop4
    #endif
    #if (w2_nops&8)
    w_nop8
    #endif
    #if (w2_nops&16)
    w_nop16
    #endif
    "       out   %2,%4 \n\t"    //  '1' [+1] '0' [+1] - fe-high
    #if (w3_nops&1)
    w_nop1
    #endif
    #if (w3_nops&2)
    w_nop2
    #endif
    #if (w3_nops&4)
    w_nop4
    #endif
    #if (w3_nops&8)
    w_nop8
    #endif
    #if (w3_nops&16)
    w_nop16
    #endif

    "       dec   %0    \n\t"    //  '1' [+2] '0' [+2]
    "       brne  loop%=\n\t"    //  '1' [+3] '0' [+4]
    :  "=&d" (ctr)
    :  "r" (curbyte), "I" (_SFR_IO_ADDR(ws2812_PORTREG)), "r" (maskhi), "r" (masklo)
    );
    //  }
  }
  
  SREG=sreg_prev;
}

[Tim . (cpldcpu)]

Das lässt sich recht einfach realisieren, indem man die Funktion 
mehrmals hintereinander aufruft. Dass funktioniert nur mit dem alten 
Interface, da die neue Funktion bereits den Reset-delay beinhaltet.

Es gibt ein Beispiel im Repository:

https://github.com/cpldcpu/light_ws2812/blob/master/light_ws2812_AVR/Examples/Chained_writes.c

Die Daten werden erst beim Reset (>10µs delay) in die LEDs übernommen. 
So lange zwischen den Schreibzugriffen weniger als 5µs liegen, können 
diese aneinander gereiht werden.

[Simon (Gast)]

Hallo Tim, danke schon einmal für die schnelle Antwort
Habe einmal 8 Leds angeschlossen. Led 1 - 4 soll den gleichen Wert 
zugewiesen bekommen. Genauso bekommt Led 5 - 8 den gleichen Wert.

Leider tut sich so noch nichts.

#include <avr/io.h>
#include <util/delay.h>
#include "light_ws2812.h"

#define NUM_LEDS 2
#define NUM_GROUP 4
struct cRGB ledsRGB[NUM_LEDS];

void group(struct cRGB *rgb, const int16_t leds, uint8_t group)
{
  for(uint8_t a = 0; a < NUM_LEDS; a++)
  {
    for(uint8_t b = 0; b < group; b++)
    {
      ws2812_sendarray((uint8_t*)&rgb[a], 3);
    }
  }
}

int main(void)
{
  ledsRGB[0].r = 255;  // Erste Led Rot
  ledsRGB[1].g = 255; // Zweite Led Blau

  while (1)
  {
    // Die ersten 4 Leds sollen Rot, die anderen 4 sollen Blau sein!
    group(ledsRGB, NUM_LEDS, 4);
    _delay_ms(50);
  }
}

[Tim . (cpldcpu)]

Sieht eigentlich ok aus (auch wenn der Compiler ein paar Warnings 
schmeissen wird...).

Stimmen Taktfrequenz und Portkonfiguration?

[Simon (Gast)]

Klappt nun ;)

[Sascha (Gast)]

Hallo,

ich habe ein Problem bei deiner APA102C Lib.
Möchte das ganze mit dem Attiny841 und HW SPI betreiben.


in /*...*/ steht der orginal Inhalt, was mache ich hier bei der HW SPI 
falsch, dass keine Daten gesendet werden?

inline void SPI_init(void)
{
  // MOSI | SCK
  DDRA |= (1<<PORTA6) | (1<<PORTA4);
  SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0);
  /*
  apa102_DDRREG  |=  _BV(apa102_data);
  apa102_DDRREG  |=  _BV(apa102_clk);
  apa102_PORTREG &= ~_BV(apa102_clk);  // initial state of clk is low
  */
}

// Assumed state before call: SCK- Low, MOSI- High
void SPI_write(uint8_t c) {
  SPDR = c;
  while(!(SPSR & (1<<SPIF)));

  /*uint8_t i;
  for (i=0; i<8 ;i++)
  {
  if (!(c&0x80)) {
  apa102_PORTREG &= ~_BV(apa102_data); // set data low
  } else {
  apa102_PORTREG |=  _BV(apa102_data); // set data high
  }
  
  apa102_PORTREG |= (1<< apa102_clk); // SCK hi , data sampled here

  c<<=1;
  
  nop();  // Stretch clock
  nop();
  
  apa102_PORTREG &= ~_BV(apa102_clk); // clk low
  }
  // State after call: SCK Low, Dat high
  */
}

[holger (Gast)]

>was mache ich hier bei der HW SPI
>falsch, dass keine Daten gesendet werden?

Setze den SS Pin auf Ausgang.

[Sascha (Gast)]

Hab ich gerade selbst schon gemacht, das war das Problem. Trotzdem 
Danke! Nun gehts.

[E. T. (jadeaffenjaeger)]

Hi, ich versuche auch gerade die Library zum Laufen zu bekommen. Leider 
bisher erfolglos... Mein Attiny45 erzeugt zwar ein Signal, die Lows und 
Highs sind aber ca. 10x länger als sie sein sollten. Der Attiny läuft 
auf 8MHz, F_CPU ist entsprechend definiert, die Warteperiode wird auch 
richtig erzeugt, aber mit dem WS2812-Code scheint irgendetwas nicht zu 
stimmen.

Hier der Minimalcode:

    1 #define F_CPU 8000000UL
    2 #include <util/delay.h> 
    3 #include "light_ws2812.h"
    4 
    5 struct cRGB led[10];
    6 
    7 int main (void)
    8 {
    9 
   10         int val = 255;
   11         int i;
   12 
   13         /*CLKPR=_BV(CLKPCE);*/
   14         /*CLKPR=0;*/
   15         while(1)
   16         {
   17                 for(i = 0; i < 10; i++)
   18                 {
   19 
   20                         led[i].r = 255;
   21                         led[i].g = 0;
   22                         led[i].b = 0;
   23                 }
   24 
   25                 ws2812_setleds(led,10);
   26 
   27                 /*val++;*/
   28                 /*if (val == 256) val = 0;*/
   29                 _delay_ms(5);
   30         }
   31 }

Hab auch spaßeshalber mal probiert, F_CPU um den Faktor 10 kleiner zu 
machen, das ändert aber nix. Irgendeine Idee, was ich falsch mache?

Angehängt sind die Logic Analyzer-Screenshots von den erzeugten Takten 
und den 5ms-Warteperioden

[dummy (Gast)]

>Irgendeine Idee, was ich falsch mache?

CKDIV8 Fuse?

[E. T. (jadeaffenjaeger)]

Fuses/Takt sollten mMn stimmen, da die _delay_ms() ja auch vom Takt 
abhängig ist, und mit der angegebenen F_CPU fehlerfrei funktioniert.

[Tim . (cpldcpu)]

>#define F_CPU 8000000UL

Das define muss natürlich global im Makefile gesetzt werden. Sonst sieht 
es die Lib nicht.

[Jojo S. (Gast)]

und was macht:
ws2812_setleds(led, 10*3);

deine unvollständige Ausgabe löscht den Frame vielleicht wieder.

[E. T. (jadeaffenjaeger)]

F_CPU global setzen hat es gefixt. Das war mir nicht klar. Danke fuer 
die schnelle Hilfe!

[c-hater (Gast)]

Icke ®. schrieb:

> Auch das ist nicht möglich, weil die Farben in der gesamten Kette erst
> nach dem Reset-Puls übernommen werden und zwar nahezu gleichzeitig.

Das stimmt leider schlicht nicht, bzw. erst dann, wenn mehr als ca. 256 
LEDs angesteuert werden.

Man sieht das nur nicht, wenn man die Dinger mit einem einzelnen Burst 
füttert und dann einen stabilen Pegel ausgibt (also z.B. Latch/Reset). 
Nach "kurzer" Zeit übernehmen dann zwar alle LEDs den zuletzt an sie 
gesandten Wert, aber eben nicht gleichzeitig, sondern nach einem 
bestimmten Schema verzögert.

Wenn man den Kram nicht nach der Burst-Methode ansteuert, sonder sich 
die Mühe macht, einen Treiber zu programmieren, der zyklisch mit Vmax 
die Dinger füttert, dann kann man dieses Verhalten sehr schön sichtbar 
machen.

Das habe ich (anfangs ungewollt) bei dem Versuch getan, die PWM der LEDs 
um zusätzliche 3Bit in Software zu erweitern. Das Ergebnis sah einfach 
mal Scheisse aus und garnicht so, wie eigentlich erwartet, es zeigten 
sich nämlich "wabernde" Störungen statt gleichmäßig verringerter 
Helligkeit.

Also die 3Bit-Erweiterung zunächst provisorisch auf nur ein Bit 
zurückgebaut und die Sache mal genauer untersucht. Effektiv wird als 
Testmuster also abwechselnd immer ein Frame komplett "weiss" und ein 
Frame komplett "schwarz" rausgeschickt. Ein komplettes Frame meiner 1 
Bit PWM-Erweiterung umfasst hier also 2 Frames des LED-Feeds.

Und obwohl die effektive Framerate (~285Hz bei 60 LEDs) eigentlich 
locker für einen gleichmässigen Helligkeitseindruck reichen sollte, 
zeigte sich ein waberndes Helligkeitsmuster und diesem Wabern sah man 
sofort an, dass es irgendwie regulär ist.

Also, wenn's regular ist, dann sollte sich die Sache besser sichtbar 
machen lassen, wenn man statt 1:1 Duty 1:n verwendet und n eine 
Primzahl-1 sein lässt. Gedacht, getan: bei 1:6 ergab sich dann deutlich 
sichtbar das ganze Ausmass dieser Scheisse.

Womit für's Erste meine Idee der PWM-Erweiterung gestorben ist. Bis zu 
dem Zeitpunkt, wo ich die Gesetzmäßigkeiten der Sache vollständig 
verstanden habe, was bis dato nicht der Fall ist. Nur einige Teilaspekte 
konnte ich aufklären bzw. sind bereits aus dem 1:6-Versuch direkt 
offensichtlich geworden.

Wer Lust hat, kann ja mitknobeln, am Wochenende werde ich mal meine 
bisherigen Ergebnisse aufbereiten und hier posten. Ich werde dafür dann 
einen neuen Thread namens "The secret of WS2812B" eröffnen.

Wer das nachvollziehen will, sollte sich irgendeinen AVR besorgen mit 
SPI-fähiger UART und der Fähigkeit, mit einem 20MHz Quarz zu laufen. Ich 
habe konkret einen Tiny4313 verwendet, es sollte aber auch jeder andere 
gehen, der die genannten Anforderungen erfüllt.