Fehler bei LED_to_Var Thema ist als GELÖST markiert

[PeterVT11]

Hallo,

ich hab den Range von LED_to_Var mit 256 Werten überschritten. Im aktuellen Projekt wird die LED 260 und größer herangezogen. Leider funktioniert das nicht.

In der LEDs_AutoProg.h sieht das so aus:

Beigefügt ist auch mein Projekt. Allerdings benötigt das die P_Schedule (siehe hier).

Nachtrag: MLL -Version 3.4.0b2 mit ESP32 und 7 Kanälen plus virtueller Kanal 8.

[Eckhart]

Hallo Peter!

Hallo,

ich hab den Range von LED_to_Var mit 256 Werten überschritten. Im aktuellen Projekt wird die LED 260 und größer herangezogen. Leider funktioniert das nicht.

Das liegt daran, dass die "_Var" aus der Bezeichnung "LED_to_Var", in der orginalen MobaLedLib, eigentlich gar nicht gibt!

Abgewickelt wird nämlich alles über die sog. "InCh" (steht wohl für "Input Channel"), die für den Nano auf 64 Byte heruntergespart wurden! Darin hat jede Variable 2 Bit und damit ist die Grenze bei 256 Variablen! Übrigens teilen sich die 256 möglichen Variablen auch noch den Bereich mit den möglichen DCC (oder Loconet, oder CAN) Adressen! (nicht mit dem DCC Adressraum, der geht von 1 bis 2048, sondern mit der möglichen Anzahl)

Gruß, Eckhart

PS: Ist ähnlich gelagert, wie die Sache, die wir gerade an anderer Stelle hatten, dass das Gleiche besser das Selbe wäre!

[PeterVT11]

Hallo Eckart,

Du willst mir hier aber nicht einreden, dass bei 256 LEDs Schluss ist? Dann wären ja die ca. 15000 LEDs der Lichtmaschine Pro Makulatur?

Ich denke, da sind einfach die falschen Variablen-Typen definiert. Zwei hab ich gefunden, aber irgendwo klemmt es noch.

Was meinst du mit deinem PS?

[raily74]

Hallo Peter,

im Rahmen unserer Tests rund um die FastLED hatte ich Anfang des Jahres ein Gespräch mit Hardi, indem er mich erstmalig auf die Einschränkungen bzgl. der Variablen hinwies. Er zeigte mir, wo genau die Variablen liegen und erklärte mir, dass die Anzahl der möglichen Variablen nicht besonders groß sei. Ich hatte immer 150 im Kopf, aber sehr wahrscheinlich hat er damals 250 gesagt. Seitdem gehe ich sehr sparsam damit um.

Da meine Anlage noch im Aufbau ist, schalte ich derzeit alles mit einer einzigen Adresse ein. Das wird natürlich nicht so bleiben. Aktuell schalte ich die Kunststoffspritzerei mit vier DCC Adressen bei 26 WS281x. Bei der Burg steuere ich 31 WS281x mit drei DCC Adressen. Ich brauche also weniger Adressen als WS281x. Von daher habe ich in dieser Einschränkung bisher keine Probleme gesehen und mir ehrlich auch keine Gedanken darüber gemacht, ob meine DCC Adressen für die 5.280 Ws281x reichen. Aber ich kann verstehen, dass dich das bei deiner Programmierung aktuell vor Probleme stellt.

Ich befürchte also (begründet), dass Eckhart hier richtig liegt. Aber vielleicht finden wir hier auch eine andere Lösung für die Zukunft. Was müsste man denn da machen? Geht das überhaupt mit einer Software, die Arduino und ESP gleichzeitig bedient?

[PeterVT11]

Hallo miteinander,

ja ich hab das mit 250 (oder 255) Variablen verstanden. Das ist schon eine Einschränkung. Ich gehe davon aus, dass Variablen das sind, was in der Adress-Spalte stehen bzw. in Funktionen erzeugt werden. Davon verwende ich derzeit 158. Der Auszug aus der LEDs_AutoProg.h:

Code: Alles auswählen

#define START_SEND_INPUTS 4     // Start address of all switches/variables
#define TOTAL_SEND_INPUTS 155   // Number of used switches/variables
#define TOTAL_VARIABLES   147   // Number of used variables

Bei den LED's hab ich's überschritten:

Code: Alles auswählen

CLEDController& controller0 = FastLED.addLeds<NEOPIXEL, 27>(leds+  0, 74); \
CLEDController& controller1 = FastLED.addLeds<NEOPIXEL, 32>(leds+ 74,  5); \
CLEDController& controller2 = FastLED.addLeds<NEOPIXEL, 16>(leds+ 79, 64); \
CLEDController& controller3 = FastLED.addLeds<NEOPIXEL, 14>(leds+143, 17); \
CLEDController& controller4 = FastLED.addLeds<NEOPIXEL, 18>(leds+160, 69); \
CLEDController& controller5 = FastLED.addLeds<NEOPIXEL, 19>(leds+229, 28); \
CLEDController& controller7 = FastLED.addLeds<NEOPIXEL,  0>(leds+257,  3); 

Damit hab ich 259 LED-Adressen. Gefolgt von 3 virtuellen LED's. Und da kracht es.

Code: Alles auswählen

   {
        // Var name           LED_Nr LED Offset   Typ                Compare value
        { A_Auto,             260,   (0   << 3) | T_GREATER_THAN,    10  },
        { A_Manu,             261,   (0   << 3) | T_GREATER_THAN,    10  },
        { Ein1,               144,   (2   << 3) | T_GREATER_THAN,    29  },
        { Ein2,               144,   (2   << 3) | T_GREATER_THAN,    59  },
        { Ein3,               144,   (2   << 3) | T_GREATER_THAN,    89  },
        { BG_BR0,             262,   (0   << 3) | T_GREATER_THAN,    0   },
        { BG_BL0,             262,   (1   << 3) | T_GREATER_THAN,    0   },
        { BG_In1,             262,   (2   << 3) | T_GREATER_THAN,    0   },
      };

Die LED_to_Var stört sich nicht an der x.ten Variablen sondern an der LED-Adresse.

Ich hoffe, dass das gefixt werden kann. Ich hab 2 Stellen im Sourcecode gefunden, wo die LED-Adresse mit uint8_t definiert sind. Aber irgendwo gibt es da noch weitere Stellen, die ich nicht gefunden habe.

[Eckhart]

Hallo Peter!

Die LED_to_Var stört sich nicht an der x.ten Variablen sondern an der LED-Adresse.

Ich hoffe, dass das gefixt werden kann. Ich hab 2 Stellen im Sourcecode gefunden, wo die LED-Adresse mit uint8_t definiert sind. Aber irgendwo gibt es da noch weitere Stellen, die ich nicht gefunden habe.

Du hast absolut Recht! Ich habe nicht genau genug gelesen und gedacht, dass es um die "InCh", bzw. die Variable, die beeinflusst werden soll geht. Der Fehler, den du gefunden hast, ist aber auch da!

Lass uns doch mal konkret werden!:

Ich vermute (leider hast du es nicht geschrieben), dass du die folgenden beiden Stellen gefunden hast:

1. Die Tabelle:

typedef struct
{
uint8_t Var_Nr;
uint8_t LED_Nr;
uint8_t Offset_and_Typ; // ---oottt Offset: 0..2
uint8_t Val;
} __attribute__ ((packed)) LED2Var_Tab_T;

2. die Funktion:

void Update_LED2Var()
//-------------------
// Uses 194 bytes + 4 bytes per processed LED
{
{
for (uint8_t i = 0; i < sizeof(LED2Var_Tab)/sizeof(LED2Var_Tab_T); i++)
{
const LED2Var_Tab_T *p = &LED2Var_Tab;
uint8_t Var_Nr = pgm_read_byte_near(&p->Var_Nr);
uint8_t LED_Nr = pgm_read_byte_near(&p->LED_Nr);
uint8_t Offset_and_Typ = pgm_read_byte_near(&p->Offset_and_Typ);
uint8_t Val = pgm_read_byte_near(&p->Val);
uint8_t Offset = Offset_and_Typ >> 3;
int8_t Typ = Offset_and_Typ & 0x07;
uint8_t LED_Val = leds[LED_Nr][Offset];

uint8_t Res;
switch (Typ)
{
case T_GREATER_THAN: Res = (LED_Val > Val); break;
case T_LESS_THEN: Res = (LED_Val < Val); break;
default: // 28.11.20: Juergen
case T_EQUAL_THEN: Res = (LED_Val == Val); break;
case T_NOT_EQUAL_THEN: Res = (LED_Val != Val); break;
case T_BIN_MASK: Res = (LED_Val & Val); break;
case T_NOT_BIN_MASK: Res = !(LED_Val & Val); break;
}
MobaLedLib.Set_Input(Var_Nr, Res);
#if 0 // Debug
uint32_t PERIOD = 500;
static uint32_t Disp = PERIOD;
if (millis() >= Disp)
{
char s[40];
sprintf(s, "%3i: V%-3i L%-3i O%i T%i V%-3i Act%-3i R%i", i, Var_Nr, LED_Nr, Offset, Typ, Val, LED_Val, Res);
Serial.println(s);
if (i == sizeof(LED2Var_Tab)/sizeof(LED2Var_Tab_T) - 1) Disp += 1000;
}
#endif
}
}
}

Wenn du beides von uint8_t in uint16_t änderst, übersetzt es, aber funktioniert nicht, oder?

Das könnte daran liegen, dass du in der Zeile in der Funktion (nun mit uint16_t) pgm_read_byte_near noch nicht in pgm_read_word_near geändert hast. Ich kann dir leider nicht garantieren, dass es dann funktioniert, denn bei mir läuft die MLL in einer Virtualisierung und ich habe es von "außen" geändert, ohne den Source der MML anzufassen. Aber probieren könntest du es ja mal.

!!!ACHTUNG!!! Das ist nun nicht mehr Nano kompatibel und müsste mit den Definitionen:

// a led nubmer is store in a 16 bit variable
#define ledNr_t uint16_t
// marco for reading the led number from configuration array
// read two bytes
#define pgm_read_led_nr pgm_read_word_near

...so bearbeitet werden, dass es wieder Nano kompatibel ist. Das ist aber "not my cup of tea"

Gruß, Eckhart

[raily74]

Ich gehe davon aus, dass Variablen das sind, was in der Adress-Spalte stehen bzw. in Funktionen erzeugt werden.

Hallo zusammen,

bedeutet das denn jetzt, dass in der Adress-Spalte max. 256 unterschiedliche Befehle enthalten sein dürfen (DCC-Adressen, InCh-Variablen, Push Buttons usw.)? Das kann doch eigentlich nicht sein, oder?

[PeterVT11]

Hallo Eckhart,

vielen Dank für deinen Input. Das war die Lösung für mein Problem. Ich hab das wie folgt umgesetzt:

Im Prog_Generator im Modul M06_Write_Header_LED2Var:

'------------------------------------------------------------------
Public Function Write_Header_File_LED2Var(fp As Integer) As Boolean
'------------------------------------------------------------------
If LED2Var_Tab <> "" Then
Print #fp, "// ----- LED to Var -----"
Print #fp, " #define USE_LED_TO_VAR"
Print #fp, ""
Print #fp, " #define T_EQUAL_THEN 0"
Print #fp, " #define T_NOT_EQUAL_THEN 1"
Print #fp, " #define T_LESS_THEN 2"
Print #fp, " #define T_GREATER_THAN 3"
Print #fp, " #define T_BIN_MASK 4"
Print #fp, " #define T_NOT_BIN_MASK 5"
Print #fp, ""
Print #fp, " typedef struct"
Print #fp, " {"
Print #fp, " uint8_t Var_Nr;"
If Get_BoardTyp() = "ESP32" Then ' 16.07.25 PeterVT11
Print #fp, " uint16_t LED_Nr;"
Else
Print #fp, " uint8_t LED_Nr;"
End If
Print #fp, " uint8_t Offset_and_Typ; // ---oottt Offset: 0..2"
Print #fp, " uint8_t Val;"
Print #fp, " } __attribute__ ((packed)) LED2Var_Tab_T;" ' 05.11.20: Added: __attribute__ ((packed)) to be able to use it on oa 32 Bit platform
Print #fp, ""
Print #fp, "#ifdef CONFIG_ONLY" ' 17.04.22 Juergen: add Simulator Led2Var feature
Print #fp, " const LED2Var_Tab_T LED2Var_Tab[] __attribute__ ((section ("".MLLL2VConfig""))) ="
Print #fp, "#else"
Print #fp, " const PROGMEM LED2Var_Tab_T LED2Var_Tab[] ="
Print #fp, "#endif"
Print #fp, " {"
Print #fp, " // Var name LED_Nr LED Offset Typ Compare value"
Print #fp, DelLast(LED2Var_Tab, 2) ' 26.05.23
Print #fp, " };"
Print #fp, ""
Print #fp, ""
End If
Write_Header_File_LED2Var = True
End Function

Sowie in der LEDs_AutoProg.ini die Funktion Update_LED2Var geändert:

//-------------------
void Update_LED2Var()
//-------------------
// Uses 194 bytes + 4 bytes per processed LED
{
{
for (uint8_t i = 0; i < sizeof(LED2Var_Tab)/sizeof(LED2Var_Tab_T); i++)
{
const LED2Var_Tab_T *p = &LED2Var_Tab;
uint8_t Var_Nr = pgm_read_byte_near(&p->Var_Nr);
#ifdef ESP32 // 16.07.25 PeterVT11
uint16_t LED_Nr = pgm_read_word_near(&p->LED_Nr);
#else
uint8_t LED_Nr = pgm_read_byte_near(&p->LED_Nr);
#endif // ESP32
uint8_t Offset_and_Typ = pgm_read_byte_near(&p->Offset_and_Typ);
uint8_t Val = pgm_read_byte_near(&p->Val);
uint8_t Offset = Offset_and_Typ >> 3;
int8_t Typ = Offset_and_Typ & 0x07;
uint8_t LED_Val = leds[LED_Nr][Offset];
uint8_t Res;
switch (Typ)
{
case T_GREATER_THAN: Res = (LED_Val > Val); break;
case T_LESS_THEN: Res = (LED_Val < Val); break;
default: // 28.11.20: Juergen
case T_EQUAL_THEN: Res = (LED_Val == Val); break;
case T_NOT_EQUAL_THEN: Res = (LED_Val != Val); break;
case T_BIN_MASK: Res = (LED_Val & Val); break;
case T_NOT_BIN_MASK: Res = !(LED_Val & Val); break;
}
MobaLedLib.Set_Input(Var_Nr, Res);
#if 0 // Debug
uint32_t PERIOD = 500;
static uint32_t Disp = PERIOD;
if (millis() >= Disp)
{
char s[40];
sprintf(s, "%3i: V%-3i L%-3i O%i T%i V%-3i Act%-3i R%i", i, Var_Nr, LED_Nr, Offset, Typ, Val, LED_Val, Res);
Serial.println(s);
if (i == sizeof(LED2Var_Tab)/sizeof(LED2Var_Tab_T) - 1) Disp += 1000;
}
#endif
}
}
}


Damit funktioniert es mit dem Nano und dem ESP32. Ob und wie der RP20 rein muss, kann ich im Moment nicht beurteilen. Ich denke, er verhält sich hier wie ein ESP32.
Vielleicht kann Jürgen (@jueff ) das in die nächste Beta einbauen. Vielleicht weiß er auch noch eine bessere Lösung.

[PeterVT11]

Hallo Michael,

bedeutet das denn jetzt, dass in der Adress-Spalte max. 256

ich fürchte, das weiß ausser Jürgen (@jueff ) oder Hardi (@Hardi ) keiner. Soweit hat das wohl noch keiner ausgetestet. Ich denke, wir werden noch öfter an die derzeitigen Systemgrenzen stoßen. Ich hab vor längerer Zeit mal mit Hardi darüber gesprochen und er meinte, da muss man einiges umschreiben. Leider kam es bis jetzt nicht dazu.

[Eckhart]

Hallo Peter!

Mir ist gerade eingefallen, dass ich dir noch die Antwort hierauf schuldig bin ("das selbe", versus "das gleiche"):

Was meinst du mit deinem PS?

Bei Dominik 2 hatte sich ja ein Fehler in der Zugriffsfunktion des Pattern-Configurator auf den ESP32 herausgestellt. Das war nur möglich, weil die Zugriffsfunktion zwei Mal vorhandenen war (also nur "gleiche" Funktionen) Hätte man eine einzige Bibliotheksfunktion kreiert, die sowohl für den Programm-Generator, als auch für den Pattern-Configurator genutzt wird (also die "selbe" Funktion), hätte nach der Anpassung für den Programm-Generator, der Fehler beim Pattern-Configurator nicht auftreten können!

imho hat Harold es, für den Python PG/PC, so implementiert.

Gruß, Eckhart

PS: Evtl. ist, statt der Bedingungen für den ESP32, die Verwendung von ledNr_t statt uint8_t/uint16_t und pgm_read_led_nr statt pgm_red_byte_near/pgm_read_word_near möglich. Doch ich durchblicke nicht, ob die Label an den Stellen auch durch #includes wirklich zur Verfügung stehen.