Ws2812b controller ?

Abend zusammen.

Kennt wer nen Projekt welches einen Controller beinhalten(Arduino,ESP, Standalone AVR o.ä.) welcher als reine Steuerung für WS2812b LEDs agiert und Befehle eines anderen Arduinos empfängt und das zeitkritsche erledigt?

Es geht genauer drum paar Meter stripe anzusteuern, langsam hoch/runter dimmen über paar Minuten, 3 Pixel über 2m Stripe innerhalb von 5h herschieben. Also keine großen Matrizen mit aufwendiger Ausgabe.

Da mein Arduino DUE bereits gut zu tun hat kommt da nur noch Murks aus den LEDs raus. Würde das ganze jetzt gerne auslagern. Habt ihr was ?

Esps, nanos, nen mega, paar avrs liegen hier noch und suchen neue Aufgaben :slight_smile:

langsam hoch/runter dimmen über paar Minuten, 3 Pixel über 2m Stripe innerhalb von 5h herschieben.

Was Du hier beschreibst, erfordert nur niedrigste FPS Raten.

Da mein Arduino DUE bereits gut zu tun hat kommt da nur noch Murks aus den LEDs raus. Würde das ganze jetzt gerne auslagern. Habt ihr was ?

Egal, wieviel der DUE bereits zu tun hat, es fällt mir schwer, zu glauben, dass sich da nicht ein klitzekleines Zeitfenster finden lässt, um auch die LEDs zu updaten. Was Du beschreibst, kann man mit einem Update pro sekunde machen.

Selbst, wenn Du einen zweiten MC als "Grafikkarte" verwendest, musst Du dem ja auch im Programmablauf sagen, was wann passieren soll = Du verschiebst das Problem nur.

Pro WS3212 brauchst Du ca. 30 µs, für angenommene 100 LEDs also 3 ms... bleiben bei 1 FPS folglich noch 997 ms für andere Jobs.

Ich sehe kein Problem, die von Dir geforderten Aufgaben auf einem einzigen MC abzuarbeiten.

Grüße, H.

mpl1337:
Esps, nanos, nen mega, paar avrs liegen hier noch und suchen neue Aufgaben :slight_smile:

Zwei Arduinos können gut per I2C quatschen, also Due-I2C - Levelshifter - Nano-I2C. Eventuell den Nano als I2C-Master verwenden, dann kann der sich Infos holen, wenn er nicht mit WS2812 beschäftigt ist.

Dann mach ich wohl was falsch mit dem ansteuern der LEDs.

Ich hab probeweißer mal sowas probiert

  if ((millis() - LEDTime) > 500) 
  {
    LEDTime = millis();
    
    if (ledv > 255) ledv = 0;
            ledv++;
  }

  //FastLED.showColor(CRGB(ledv, ledv, ledv));

    for (int i = 0; i < NUM_LEDS; i = i + 1) {
    leds[i] = CRGB( ledv, ledv, ledv);
    FastLED.show();
    }

die LEDs werden zwar langsam Heller und geben weiß von sich jedoch blitzen die alle paar sekunden mal stark auf und die erste und letzte led zeigt ab und an mal andere farben an

hatte auch versucht das FastLED.show nur jede sekunde aufzurufen… aber selbe phänomen

Mal abgesehen, dass du den Datentyp von ledv geheim hältst…
(und das spielt in deinem Code eine Rolle)

if (ledv > 255) ledv = 0;
ledv++;

seltsame Reihenfolge, oder willst du tatsächlich den Wertebereich 1 … 256 ?

mpl1337:
... jedoch blitzen die alle paar sekunden mal stark auf und die erste und letzte led zeigt ab und an mal andere farben an ...

Das Problem hat wohl nichts mit dem Sketch zu tun, sondern mit der Verkabelung oder der Spannungsversorgung.

Ein solches Verhalten habe ich das letze Mal gesehen, als Helmuth wollte, daß ich meine APA102 mit 12 MHz "quäle".

int ledv = 0;

aber das ändert auch nichts an dem geblinke :frowning:

wenn ich das ganze standalone auf dem DUE rennen lasse z.b. so:

#include "FastLED.h"

#define NUM_LEDS 81
#define DATA_PIN 12
unsigned long LEDTime;
int ledv = 0;
static bool fadeup = true;
static bool fadedown = false;
CRGB leds[NUM_LEDS];


void setup() {
  Serial.begin(9600);
  FastLED.addLeds<WS2812B, DATA_PIN, GRB>(leds, NUM_LEDS);
}

void loop() {
  if ((millis() - LEDTime) > 50)
  {
    LEDTime = millis();

    if (fadeup == true)
    {
      ledv++;
      if (ledv >= 255)
      {
        fadeup = false;
        fadedown = true;
        ledv = 255;
      }

      for (int i = 0; i < NUM_LEDS; i = i + 1) {
        leds[i] = CRGB( ledv, ledv, ledv);
        FastLED.show();
      }
    }

    if (fadedown == true)
    {
      ledv--;
      if (ledv <= 0)
      {
        fadeup = true;
        fadedown = false;
        ledv = 0;
      }

      for (int i = 0; i < NUM_LEDS; i = i + 1) {
        leds[i] = CRGB( ledv, ledv, ledv);
        FastLED.show();
      }
    }
  }
}

dann läuft das ganze sauber hoch/runter ohne zu blinken oder faxen zu machen.

Verkabelung oder der Spannungsversorgung.

das hätte sich damit auch geklärt.

Es sind 81 LEDS. Data ist per 120Ohm widerstand an pin 12.

5V kommen aus nem 5A Labornetzteil. Gnd zwischen Arduino und LEDs ist auch verbunden.

3cm vor der einspeißung hängt noch nen 470uF Elko.

Verkabelung und versorgung sind sauber da das ganze standalone eben funzt.

jedoch mein Vollgepackter DUE schafft das dann doch nicht mehr

mpl1337:
das hätte sich damit auch geklärt.

Stimmt.

Dann schalte mal vor FastLED.show(); die Interrupts aus und danach wieder ein, nur mal zum Eingrenzen.

Auch so flackert es weiter :frowning: zwar weniger aber immernoch deutlich merkbar

Ich denke das mein Projekt inzwischen zuviel Speicher und CPU fressende zeilen hat

noInterrupts();
FastLED.show();
interrupts();

Ich werde es wahrscheinlich jetzt doch auf nen ESP auslagern. Hab ne hand voll noch da…

terra.zip (28.5 KB)

mpl1337:
Ich denke das mein Projekt inzwischen zuviel Speicher und CPU fressende zeilen hat

Das kann natürlich sein und zusätzlich mag es möglicherweise nicht optimal programmiert sein, das unterstelle ich einfach mal. Wenn Du dann beispielsweise beobachten würdest, das Faden sei ruckelig, so würde ich ein umfangreiches Programm als Grund gelten lassen.

"Blinken und faxen machen" gehört aber nicht in diese Kategorie. Die LEDs halten ihre Farbe, auch wenn Du den µC anhalten würdest, kannst Du mittels delay() probieren. Wenn es während FastLED.show(); keine Unterbrechungen durch Interrupts gibt, dann werden die LEDs in einem Rutsch mit neuen Informationen versorgt. Da kann auch nichts blinken und wieviel restliches Programm noch im Speicher ist, spielt keine Rolle. Ein großes Programm kann langsam sein, aber keine LEDs zum Blinken bringen. Falsch deklarierte Variablen könnten sich gegenseitig überschreiben und zu unerklärlichen Zuständen führen. Ich hoffe mal, dies ausschließen zu können!?

Ich behaupte daher, ein großes Programm kann nicht die Ursache für die von Dir beschriebenen Fehler sein.

Natürlich kannst Du den Fehler unerforscht lassen und ihn mittels zweitem µC umgehen. Irgendwann möchte man mal ein Ergebnis haben, da hast Du mein Verständnis :slight_smile:

mpl1337:
Data ist per 120Ohm widerstand an pin 12.

Der Due hat doch 3,3 V, da fehlt ein Levelshifter auf 5 V, oder? Nimm aber den richtigen, Teensy mit I2C-Levelshifter und WS2812 habe ich probiert, war keine gute Idee von mir.

anpassung an 5V kann ich ja noch probieren... aber auf dem DUE als standalone läuft das ganze stabil mit 3.3V

langt dafür der ? http://www.ebay.de/itm/4-Kanal-Pegelwandler-5V-3-3V-4-Channel-Level-Shifter-Converter-bidirektional-/201450662471?hash=item2ee7652a47:g:km8AAOSwo4pYIGFj

hab davon noch einen da :slight_smile: (jaja, Ebay Hamsterkäufe in China :))

Ein 74LS245 wäre besser.

Der Level Shifter von Deinem Hamsterkauf ist für einen Bus ausgelegt und schaltet nur gegen GND. Mit einem genügend kleinen PullUp-Widerstand (1k ??) habe ich aber auch WS2812B zum Leuchten gebracht. Ein Blick mit dem Oszi hat geholfen, ein verschliffenes Rechtecksignal reicht.