Neopixel Funktion mit Millis

International Deutsch
#1

Hallo Leudeee,

hab mal im Internet ne echt coole Neopixel Funktion gefunden, genannt Meteor :slight_smile:

void Meteor( byte meteorSize, byte meteorTrailDecay, boolean meteorRandomDecay, int SpeedDelay) {

    for (int i = 0; i < Anzahl_Pixel + Anzahl_Pixel; i++) {
      // fade brightness all LEDs one step
      for (int j = 0; j < Anzahl_Pixel; j++) {
      if ( (!meteorRandomDecay) || (random(10) > 5) ) {
        fadeToBlack(j, meteorTrailDecay );
      }
      }
      // draw meteor
      for (int j = 0; j < meteorSize; j++) {
        if ( ( i - j < Anzahl_Pixel) && (i - j >= 0) ) {
          strip.setPixelColor(i - j, 255, 0, 0);
        }
      }
      strip.show();
      delay(SpeedDelay);
  }
}

void fadeToBlack(int ledNo, byte fadeValue) {
#ifdef ADAFRUIT_NEOPIXEL_H
  // NeoPixel
  uint32_t oldColor;
  uint8_t r, g, b;
  int value;

  oldColor = strip.getPixelColor(ledNo);
  r = (oldColor & 0x00ff0000UL) >> 16;
  g = (oldColor & 0x0000ff00UL) >> 8;
  b = (oldColor & 0x000000ffUL);

  r = (r <= 10) ? 0 : (int) r - (r * fadeValue / 256);
  g = (g <= 10) ? 0 : (int) g - (g * fadeValue / 256);
  b = (b <= 10) ? 0 : (int) b - (b * fadeValue / 256);

  strip.setPixelColor(ledNo, r, g, b);
#endif
#ifndef ADAFRUIT_NEOPIXEL_H
  // FastLED
  leds[ledNo].fadeToBlackBy( fadeValue );
#endif
}

Hab die mal auf meinen Code zugeschnitten und finde die mega schön.
Nur gibts ein Problem, die läuft über Delay und das ist ein killer für mich, da ich neben dieser Funktion weitere Sachen im Hintergrund ausführen muss. Daher muss Millis() rein…

Hab schon vieles Ausprobiert, doch alles verändert die schöne Funktion…

Mein aktueller Code ist das hier… das kommt am nächsten an die Ursprüngliche Funktion ran, jedoch Blitzt das so komisch jeden Durchgang.

Kann mir jemand Tipps geben dazu ?

void Meteor(byte meteorSize, byte meteorTrailDecay, boolean meteorRandomDecay, int SpeedDelay) {

  unsigned long currentMillisMeteor = millis();
  static unsigned long previousMillisMeteor = 0;
  static byte j = 0;
  
  if ((currentMillisMeteor - previousMillisMeteor) >= 200) {
        previousMillisMeteor = currentMillisMeteor;

    for (int i = 0; i < Anzahl_Pixel + Anzahl_Pixel; i++) {
      // fade brightness all LEDs one step
      for (int j = 0; j < Anzahl_Pixel; j++) {
      if ( (!meteorRandomDecay) || (random(10) > 5) ) {
        fadeToBlack(j, meteorTrailDecay );
      }
      }
      // draw meteor
      for (int j = 0; j < meteorSize; j++) {
        if ( ( i - j < Anzahl_Pixel) && (i - j >= 0) ) {
          strip.setPixelColor(i - j, R, G, B);
        }
      }
      strip.show();
       j++;
      //delay(SpeedDelay);
    } 
  }
}

Danke im Voraus

Gruß Franz

#2

Hi

Das delay ist in der i-FOR-Schleife enthalten.
Also breche die FOR in Einzelaufrufe auf.

void Meteor(byte meteorSize, byte meteorTrailDecay, boolean meteorRandomDecay, int SpeedDelay) {
  unsigned long currentMillisMeteor = millis();
  static unsigned long previousMillisMeteor = 0;
  static byte j = 0;  //<-- warum static? j wird überall mit 0 initialisiert
  if ((currentMillisMeteor - previousMillisMeteor) >= 200) {
    previousMillisMeteor = currentMillisMeteor;

    //for (int i = 0; i < Anzahl_Pixel + Anzahl_Pixel; i++) {
    static uint16_t i=0;
    i++;
      // fade brightness all LEDs one step
      for (int j = 0; j < Anzahl_Pixel; j++) {
        if ( (!meteorRandomDecay) || (random(10) > 5) ) {
          fadeToBlack(j, meteorTrailDecay );
        }
      }
      // draw meteor
      for (int j = 0; j < meteorSize; j++) {
        if ( ( i - j < Anzahl_Pixel) && (i - j >= 0) ) {
          strip.setPixelColor(i - j, R, G, B);
        }
      }
      strip.show();
      j++;  //<-- was macht das j++ hier? j wird überall mit 0 neu initialisiert
      //delay(SpeedDelay);
      if (i>= Anzahl_Pixel + Anzahl_Pixel)i=0;
    //} //Ende FOR i
  }
}

Warum Da an jeder Ecke INT benutzt wird, erschließt sich mir nicht - es wird wohl weder negative Pixel-Zahlen geben, wie auch keine negativen Wartezeiten.
Auch ergibt das static für j, wie das j++ am Ende, in meinen Augen keinen Sinn.

Sprechende Variablennamen … weshalb byte j außerhalb und int j innerhalb … kA, was das j Außen soll - da sehe ich auch keinen Grund für, daß es j dort überhaupt gibt - oder was sehe ich nicht?

Kompilieren tut der Kram bei mir nicht, da mir ein/zwei … Dutzend … Kleinigkeiten fehlen, Die wohl im Produktiv-Sketch gegeben sind.

MfG

#3

Hi,

danke dir für die schnelle Antwort und den Code.
Dieser Funktioniert EINWANDFREI !!! :slight_smile:

Hätte nicht gedacht, dass es so einfach ist.

Habe jetzt die int alle zu byte gewechselt, hast ja recht.

Tja, was ich da genau gemacht habe ist mir auch nicht sooo klar, bin noch relativ neu mit solchen Schleifen und wie diese genau miteinander agieren. Aber man lernt und testet :slight_smile:

Danke nochmals !

#4

Hi

Byte geht nur bis 255, dort gibt es keine negativen Zahlen.
Bei meinen Stripes wäre Byte etwas klein :wink:
Ich würde aber eben kein INT nehmen - da ich keine negativen Nummern brauche, also uint16_t (entspricht unsigned int - finde die Arduino-Schreibweise aber nicht so toll - bei uint16_t sieht man, um was Es sich dreht - U->kein Vorzeichen, also nur positive Zahlen (mit Ausnahme der Null, Die ist Nix) - int → nur Ganzzahlen (also keine Kommas) - 16 → Breite des Typ - hier 16 Bit, ergibt 0…65535 an Wertebereich (als signed, also int16_t, würde -32768…32767 abgedeckt) - _t → ist wohl ein Überbleibsel aus grauer Vorzeit)

MfG

#5

postmaster-ino:
… bei uint16_t sieht man, um was Es sich dreht …

Und es funktioniert auf 8-Bit- ebenso wie auf 32-Bit-µCs.

#6

Hi,

danke euch für die Erklärung, hilft sehr bei der Verständnis :smiley:

#7