Mir war aufgefallen das die Neopixel Anzeige bei Modus Bluetooth-Lautsprecher nur eine Pause signalisiert, also die LEDs nur blau rotieren. Habe das etwas erweitert, der Neopixel zeigt jetzt diese Zustände an:
Noch nicht verbunden: LED rotieren Blau-violett (Genauso wie bei BT-Kopfhörer)
Pairing hergestellt: LED wechseln zu Blau
Audio gestartet: LED leuchten genauso wie im Webradio-Modus, nur eben blau
Lautstärke Änderungen der Quelle z.B. am Handy werden genauso wie in allen anderen Modi visualisiert
Die Änderungen sind minimal, evt. könnt Ihr Euch das mal anschauen und eine Meinung dazu abgeben?
Punkt 1:
Den Else-Zweig in Led.cpp rausziehen und mit dem if überschreiben. Das führt zu einer Branch Optimierung mit der Annahme, dass Bluetooth normalerweise nicht aktiv ist.
Punkt 2:
CRGB::Blue und CRGB::BlueViolet in static constexpr CRGB::HTMLColorCode Variablen raus ziehen, die verwenden wir schon recht oft, das würde eine Änderung des Farbschemas erleichtern.
@laszloh Danke für’s rüberschauen!
Leider hat die Einführung von constexpr dazu geführt das der DEV-Branch nicht mehr mit Arduino 1.0.6 kompiliert, wir hatten das lange ermöglicht. Aber OK, dann ist so…
Welchen Vorteil bringt das eigentlich? Spart das Speicher? Kann der Compiler besser optimieren?
Hm… das ist nervig, der Absturz ist bei if constexpr([...]), das kennt c++11 natürlich nicht. Ich hatte hier mal beschrieben, was genau das macht (forciert den Compiler zur Optimierung der Verzweigung zur Compile-Zeit). Ist aber ein std++17 Feature und der gcc von Arduino 1.0 spricht leider nur c++11…
Aber wenn ich das repariere, tun sich einige andere Problemstellen auf (zB ESP_ARDUINO_VERSION_VAL ist undefined, std::clamp gibt es nicht, etc.).
Ich denke das sollten wir generell in der Dev-Branch ansprechen, ob Rückwärtskompatibilität zu Arduino 1.0 gewünscht ist.
Vorteil ist dass der Code pflegeleichter wird, wenn wir die Farben in globale Variablen raus ziehen. Und wenn jemand ein anderes Farbschema hat, kann er es einfach an einer Stelle ändern und das ändert dann alle relevanten Teile des Codes (da wir zB für die Playlist ja auch die Farbe Blau verwenden wäre diese auch von search&replace betroffen)
constexpr ist grundsätzlich eine Variable, dessen Wert zur Zeitpunkt des compilierens bekannt ist (gegenüber zB einem const, der zur Laufzeit 1x gesetzt wird). Das erlaubt es dem gcc diese Variable zu optimieren und bringt einiges an Vorteilen gegenüber einem Makro. zB Sichtbarkeit (#define ist im ganzen Code gültig über namespaces hinaus), Sicherheit bei einer Zuweisung.
Ein weiterer großer Punkt ist, dass constexpr dich zwingt sauberen C++ Code zu schreiben. ZB:
#define begin() x=4
#define end() x=17
[...] // viele Zeilen code
void x(){
int x = 33;
begin(); // begin verändert x ohne dass der Programmierer davon __hier__ etwas mitbekommt
printf("%d", x);
end();
}
// mit constexpr
constexpr int begin() {
return 4;
}
void x(){
int x = 33;
begin(); // hier hat begin keine Auswirkung auf x
[...]
}
@laszloh Punkt 1 ist umgesetzt. Zu Punkt 2:
Die Intention dazu kann ich nachvollziehen, allerdings geht das über das eigentliche Thema etwas hinaus. Ziehe ich jetzt die Bluetooth Farbe Blau als Farbschema heraus müsste ich das eigentluch für alle Farbdefinitionen machen. Es ist ja jetzt keine neue Farbe hinzugekommen sondern lediglich das bestehende BT-Source auf BT-Sink übernommen. Ich habe mich hier an den bestehenden Code gehalten.
Vorschlag: Wir übernehmen das so zunächst & sobald jemand das Farbschema anfassen möchte dann macht der das dann
Farbschema sehe ich auch eher für die Weboberfläche (Darkmodus ist der heiße Sch…). beim Neopixel eher weniger, Kapitän Blauzahn leuchtet eben immer blau…
