Mehrere LEDStrip-Bricklets am gleichen Master-Brick

[Quantasy]

Liebe Tinkerforger

 

Ich habe eine Frage bzgl: LED-Strips

Wenn ich zwei LED-StripBricklets an den gleichen MasterBrick hänge und je 120RGB-LEDS vom Typ WS2811 individuell ansteuern will, dann scheinen sich die zwei Bricklets mit dem RAM in die Quere zu kommen,

 

Ist das denn nicht erlaubt? Die beiden Bricklets sollten doch jeweils separaten Speicher erhalten? Scheint mir grad so, als ob das Speichermanagement der Masterbrick in diesem Fall fehlschlägt (weil beide sich von jeweils einem vermeintlich anderen Port noch RAM 'borgen'?

)?!

 

Anmerkung:

Wenn ich die zwei Bricklets dann an jeweils einen Master hänge, dann läuft dies als gesamt-Stack wunderbar.

 

[borg]

Mh, ja das ist leider so. Der Code des Bricklets kann zwar herausbekommen an welchen Bricklet Ports etwas angeschlossen ist (und sich entsprechend den RAM klauen), allerdings nicht ob sich ein anderes Bricklet bereits den RAM geklaut hat .

[Quantasy]

Aha, danke für das Feedback.

Ist das nun eher ein 'Bug' oder ein 'WONTFIX' weil Design-bedingt?

 

Wir sind eben fleissig am LED-Strips verteilen und so würden wir das Doppelte an Master-Bricks verbauen müssen (vielleicht dann doch eher ein 'Feature' auf der €-Seite ;-)  ), was auch das doppelte an Platz verbraucht.

 

Würde denn ein spezielles Auswählen der Ports auf dem Master-Brick was helfen... Soz. Port A und Prot C o.ä.?

 

[borg]

Aktuell nicht, der Code guckt immer in der Reihenfolge A, B, C, D nach freiem RAM. Dort wäre allerdings der Ansatzpunkt für einen Workaround. Wir müssten immer beim aktuell genutzten Port anfangen nach RAM zu gucken. Dann würde Port A und C funktionieren.

 

Ich schreib es mir auf das so zu implementieren, komme da allerdings nicht vor Ende er Woche zu.

[borg]

Habe mal was gestrickt, die Firmware sucht jetzt immer nach mehr RAM ausgehen vom eigenen Bricklet aus (Anhang).

 

D.h. das sollte jetzt funktioniere wenn ihr Port A/C oder B/D nutzt.

led-strip-bricklet.bin

[Loetkolben]

Nachdem ich den Thread 3 mal gelesen habe, meine ich verstanden zu haben, dass das Problem deshalb aufkommt, da man beim booten nicht weiss wie viele LED am Strip haengen.

 

Da moechte ich nochmals (m)eine alte Idee ins Spiel bringen wo man die Bricklet Firmware customizen kann. Also per Brickviewer die Anzahl der LED mit in die (kompilierte) Firmware, an eine feste Stelle, schreibt.

Damit koennte man auch den Chiptype mit festlegen und den Strip nach dem booten ordentlich initialisieren.

 

BTW: Ebenso koennte man das IO Bricket auf "Out" initialisieren, so dass LEDs nicht leuchten wenn man gebootet hat.

 

 

Der Loetkolben

[Quantasy]

YES!

 

Dieser 'Patch' funktioniert für uns, wir haben es für A/C bzw. B/D mit jeweils 120LEDs pro Port erfolgreich probiert.

@borg: Danke für Deine Strick-Kunst.

 

@Loetkolben: Vielleicht könnte man ja so wie die Kalibrierungsdaten bei der IMU oder beim LoadCell die Werte persistieren?! Das scheint mir wirklich eine gute Idee... Denn normalerweise ändert man den LED-Strip nicht so häufig. (Aber es sollte wie bei der LoadCell mit Hilfe der API gehen... nicht 'nur' per brickv.)

[Quantasy]

Frage:

Habt ihr zufälligerweise den Patch von borg eingepflegt, oder ging der irgendwo verloren (oder ist das eine Regression durch die Einführung von RGBW)?

Phänomen:

Ich wollte heute an einem MasterBrick folgendes laufen lassen:

 

A: 40x2801 (RGB)

C: 160x2812 (RGB)

 

Da gabs aber stets blitze und wilde Flackereien; scheinbar haben sich die zwei ins Memory geschrieben?!

 

Wenn ich die zwei dann auf jeweils einen separaten Master getan habe, gings ohne zu mucken.

 

[borg]

Mh, der Patch sollte in der neuesten Firmware eingepflegt sein. Vielleicht gibt es da irgendwelche Nebeneffekte mit der RGBW Unterstützung. Das muss ich mir dann nochmal angucken.