ESP RGBWW Wifi Led Controller - Firmware vbs

Begonnen von vbs, 18 April 2017, 09:26:13

Vorheriges Thema - Nächstes Thema

vbs

Zitat von: pc1246 am 16 Januar 2019, 20:55:43
Das kommt jetzt irgendwie "unpassend"! Rein theoretisch sind wir kurz davor die Bestellung auszuloesen.
Tut mir leid, hab es mir aber auch nicht ausgesucht. Die Überlegungen dazu entstanden erst jetzt mit den Arbeiten an der neuen Firmware. Sind aber aus meiner Sicht aber auch nur "nice-to-have" und evtl. sogar gar nicht sinnvoll.

Zitat von: pc1246 am 16 Januar 2019, 20:55:43
Was meinst Du mit HW-PWM?
Na beim Hardware-PWM wird das Signal von einem dedizierten Hardware-Bauteil erzeugt. Also entsprechend robust und unabhängig von anderen Abläufen. Beim Software-PWM wird die PWM-Logik in Software nachgebildet (evtl. wie bei uns unterstützt durch Hardware-Timer). Die Software-Variante ist entsprechend belastend für den Prozessor und steht in Konkurrenz zu anderen Abläufen. In Hardware sind dann auch höhere Frequenzen möglich. Google kann es bestimmt auch noch besser erklären als ich jetzt auf die schnelle.

Aber: wie wir wissen klappt das bei uns eigentlich sehr gut mit dem Software-PWM. Das Software-PWM im ESP-SDK hat den Nachteil, dass damit nur 90% Duty-Cycle realisiert werden können. Die LEDs können also nicht voll ausgesteuert werden. Ob man das wirklich sieht? Keine Ahnung.

Gibt aber hier eine alternative Implementierung:
https://github.com/StefanBruens/ESP8266_new_pwm

Habe aber eben festgestellt, dass die (zumindest in unserer HW-Konstellation) das Problem hat, manchmal kaum merklich zu flackern/blitzen. Ist minimal, aber finde ich blöd.

Daher kam der Wunsch nach Hardware-PWM auf, von der ich erwarten würde, ein 100% robustes und unabhängiges PWM-Signal bereitstellen zu können. Natürlich brauchen wir aber unsere 5 Kanäle. Das schöne bei der Software-Variante ist aber, dass man jederzeit volle Kontrolle über Fades, Animationen usw. hat. Evtl. ist das mit einer Hardware-Variante gar nicht so schön möglich wie jetzt bei dem ESP.

Aber wie gesagt: ist erstmal nur laut gedacht. Die PWM in Hardware zu machen ist generell wünschenswert. Kenn mich da hardwaremäßig nicht so aus, was es da gibt. Und evtl. hat man da andere Nachteile wie z.B. weniger Kontrolle.

Zitat von: pc1246 am 16 Januar 2019, 20:55:43
Der Reset, koennte evtl. noch einfliessen (pjakobs?), wenn Du denn auch den Vorteil erklaerst!
Der Grund steckt im vorherigen Post: Beim OTA-Update von einer SDK2- zu einer SDK3-Firmware funktioniert PWM dann erst nach einem echten Powercycle (Soft-Restart reicht nicht). Zwar ist eigentlich OTA-Update für den Fall nicht vorgesehen, aber die Erkenntnis ist, dass Soft-Restart != Hard-Reset. Evtl wäre es daher evtl. mal wünschenswert, die Möglichkeit zu haben einen Hard-Reset per Software auslösen zu können. Just in case. Ist sicherlich ja recht leicht zu realisieren.

Zitat von: ext23 am 16 Januar 2019, 21:48:13
@vbs: Gibt es auch Updates bezüglich ESP32 und LAN?
Tut mir leid, keine Neuigkeit von meiner Seite. Sming unterstützt mW kein ESP32 und auch kein LAN (da aber unsicher):
https://github.com/SmingHub/Sming/issues/1333

Man müsste also die FW auf was anderes portieren... etwas eigenes oder Arduino oder so. Kann aber nicht beurteilen, ob das eine gute Idee ist. Kenne mich da zu wenig aus.

Zitat von: ext23 am 16 Januar 2019, 21:48:13
Das mit dem HW PWM, mhh dann landet man früher oder später doch wieder beim guten alten µC der sowas gelangweilt nebenbei erledigt ^^ Diese ESP sind eben leider keine echten µC durch den ganzen OS kram der da mitläuft.
Ganz genau. Hat eben Vor- und Nachteile. Super wäre es, wenn man evtl. beides kombinieren könnte? Also den ESP für Wifi, Webserver und API und co. und zusätzlich einen kleinen 5-Kanal-PWM-Controller. Aber ganz ehrlich: ich hab da wenig Erfahrung. Ist vlt. auch Quatsch...

pjakobs

sag mal, @VBS, wie aufwendig wäre es eigentlich, für die beiden GPIO 0 und 16 (also PRG und CLR) mqtt topics zu definieren? Ich denke gerade darüber nach, die für die zu produzierende Version vielleicht noch auf einen Header zu bringen. Das hätte den riesen Vorteil, dass man, wenn der Controller in einer Lampe verbaut ist, noch zwei Taster dran hängen und die Lampe, via mqtt und fhem, lokal schalten könnte.

pj

vbs

Zitat von: pjakobs am 04 Februar 2019, 10:22:19
wenn der Controller in einer Lampe verbaut ist, noch zwei Taster dran hängen und die Lampe, via mqtt und fhem, lokal schalten könnte.
Bin nicht sicher, ob ich verstanden habe, was du machen willst. Wie bzw. warum MQTT, wenn man die Lampe lokal schalten will?

pjakobs

Zitat von: vbs am 05 Februar 2019, 22:54:50
Bin nicht sicher, ob ich verstanden habe, was du machen willst. Wie bzw. warum MQTT, wenn man die Lampe lokal schalten will?
Ich will ja nicht festlegen, was passiert, ich fände es praktisch, wenn man einfach eine mqtt message verschickt weil einer der gpios auf gnd gezogen wurde. (es sind übrigens potentiell 0, 2 und 16)
Was der server dann daraus macht is nicht unser ding.

pj

Gesendet von meinem HTC U11 mit Tapatalk


vbs

Hm, ich finde die Idee mit der Bedienung am Gerät generell gut. Bin aber noch nicht überzeugt davon, dass man dafür einen MQTT-Server und ein laufendes FHEM braucht. Empfinde ich für einen Ein/Aus-Schalter am Gerät als etwas Overkill um ehrlich zu sein.
Man könnte ja auch z.B. lokal im Gerät den Ein-Zustand konfigurierbar machen, der eingenommen wird, wenn der lokale Ein-Schalter betätigt wird (ähnlich der Startup-Color). Wäre dann auch ausfallsicher falls FHEM mal streikt. Die MQTT-Message könnte man aber natürlich zusätzlich machen, so dass im Prinzip auch deine Variante möglich wäre. Die damit mögliche Flexibilität ist ja auch super.

lou

#860
aloha community

ich kann mal meine hardwarelösung als inspiration anbieten.

beim ESP8266 ist nicht nur die soft-PWM das problem sondern z.b. auch die undefinierten pin-states (high-z/high-level) während des boots (power on).
beides kann unschönes flackern erzeugen und ist damit bezogen auf die ansteuerung der fets leider sehr "unsauber".
als schulungsexperiment mag das reichen. daher gibts wohl auch überall den soft-PWM ansatz für den ESP.
die grenzbereiche der PWM sind dabei am auffälligsten. (z.b. 0-5% bzw. 95%-100%).
da die helligkeit von leds stark nichtlinear bezogen auf die PWM ist, ist der untere bereich jedoch relevant wenn man z.b. "stark gedimmtes" licht haben will.
der (software) jitter ist immer vorhanden und wirkt sich im grenzbereich einfach massiver aus. (= "sichtbarer")
es gibt zwar PWM ansätze die das problem leicht entschärfen da optimierter code verwendet wird, rein konzeptionell ändert das aber nichts.

zum schematic:
bei der gezeigten lösung ist es nicht nötig ein PCB zu ätzen, da sowieso nur 3 "flightwires" nötig sind.
ich verwende die schaltung in verschiedenen setups mit verschiedenen power-fets - für (analog) LED strips und echte lampen (24V) mit mehreren kanälen.
die firmware des AVR ist ein "10-zeiler". und damit fehlerfrei und robust. (serial clock/data to pwm).
die firmware auf ESP8266-seite wird dadurch auch simpler, da timing-unkritisch.

gruss
lou



vbs

@pjakobs
Kannst du etwas bzgl. des Hard-Reset-Pins aus meinem letzten Post sagen?

ext23

Warum benutzt du ein AVR und nicht ein PWM Chip?

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

lou

#863
Zitat von: ext23 am 06 Februar 2019, 11:41:08
Warum benutzt du ein AVR und nicht ein PWM Chip?
/Daniel
der ATTINY24 ist günstig, DIL (2.54 rastermaß), flexibel und meine schublade ist voll davon :) ("verfügbarkeit").
ausserdem kann man dann das DA/CL interface beliebig (einfach) selbst implementieren. SPI o.ä. ist nicht nötig.
zusätzlich mache ich noch eine linearisierung per mini-lookuptable im avr. die kann somit leuchtenspezifisch sein.
folge: ESP8266 firmware ist immer die selbe und damit sinkt die komplexität auf ESP-seite / web/lan-backend zusätzlich.

ext23

OK ;-)

Naja ich mag die ESP ehe nicht, das sind eben keine echten µC. Im Prinzip müsste man alles auf den AVRs machen, dann würde vieles besser laufen. Und wer unbedingt WLAN oder LAN braucht kann sich ja immer noch ein ESP ran hängen als Brücke zu UART. Aber gut es ist eben wie es ist ja. Übrigens der Tiny macht ja auch 5V, dann könnte man auch gleich bessere MOSFETS nehmen die sauber im Arbeitsbereich liegen und nicht sone 3,3V "Krücken". Zumindest für die interessant die hinten 300W dran haben...
/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

vbs

Wir würdet ihr euch bei so einer AVR-Lösung die Umsetzung einer akkuraten Synchronisierung mehrerer Controller per Wifi vorstellen? Mir geht es da um Fragen bzgl. der genauen Taktung der Controller.

lou

#866
Zitat von: ext23 am 06 Februar 2019, 11:54:05
OK ;-)

Naja ich mag die ESP ehe nicht, das sind eben keine echten µC. Im Prinzip müsste man alles auf den AVRs machen, dann würde vieles besser laufen. Und wer unbedingt WLAN oder LAN braucht kann sich ja immer noch ein ESP ran hängen als Brücke zu UART. Aber gut es ist eben wie es ist ja. Übrigens der Tiny macht ja auch 5V, dann könnte man auch gleich bessere MOSFETS nehmen die sauber im Arbeitsbereich liegen und nicht sone 3,3V "Krücken". Zumindest für die interessant die hinten 300W dran haben...
/Daniel

Einspruch!! :) :) die ESPs sind super :) nur viele verstehen die komplexität hinter wifi z.b. nicht, oder haben noch nie per osci gesehen was alles so passiert wenn der ESP nur "lauscht" im netz :)
will man wirklich timingkritische dinge machen MUSS man sich an SPI und konsorten halten. Das ist dann auch 100% timingstabil.
theoretisch könnte man den ESP 100% "raw/bare" betreiben. dann hat man halt die schönen wifi-libs nicht.. auch blöd ;)

*philosophie-modus-ende* :)

@vbs: kann nicht ganz folgen. was meinst du genau mit sync. bzw controller ? den avr? der wird in der beschriebenen lösung 100% über CK/DA per ESP8266 synchronisert (bei mir z.b. 200us per data-frame + 50ms deadzone, also maximale updaterate grob 50ms...). alles andere per MQTT/websockets o.ä.

ext23

Zitat von: lou am 06 Februar 2019, 12:00:12
Einspruch!! :) :) die ESPs sind super :) nur viele verstehen die komplexität hinter wifi z.b. nicht, oder haben noch nie per osci gesehen was alles so passiert wenn der ESP nur "lauscht" im netz :)
will man wirklich timingkritische dinge machen MUSS man sich an SPI und konsorten halten. Das ist dann auch 100% timingstabil.
theoretisch könnte man den ESP 100% "raw/bare" betreiben. dann hat man halt die schönen wifi-libs nicht.. auch blöd ;)

*philosophie-modus-ende* :)

Wenn du das OS ersetzt ja, aber es ist ein SoC und ein µC, bleib ich bei. Das Ding kann keine echten Counter und nichts, also Grütze. Es ist eben mehr ein raspberryPi... Mit dem Ding kann man nicht mal 800 kHz sauber messen.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Zitat von: vbs am 06 Februar 2019, 11:57:54
Wir würdet ihr euch bei so einer AVR-Lösung die Umsetzung einer akkuraten Synchronisierung mehrerer Controller per Wifi vorstellen? Mir geht es da um Fragen bzgl. der genauen Taktung der Controller.

Sowas kann man auch via 433 MHz oder 868 MHz machen, das sollte auch besser gehen als mit WIFI ^^ Oder aber wenn alles im selben raum ist auch gleich über das Licht.
Aber wie gesagt das ist alles ein komplett neues Thema, hier geht es ja um den ESP, von daher kein Gedanken dran verschwenden.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

lou

#869
Zitat von: ext23 am 06 Februar 2019, 12:04:20
Wenn du das OS ersetzt ja, aber es ist ein SoC und ein µC, bleib ich bei. Das Ding kann keine echten Counter und nichts, also Grütze. Es ist eben mehr ein raspberryPi... Mit dem Ding kann man nicht mal 800 kHz sauber messen.

/Daniel
stimme zu. der ESP ist kein realtimesystem. aber sackrisch schnell gegenüber einem "echten" lowend uC :) espressif hat damit definitiv eine lücke gefüllt. darum der hype.

ach übrigens.. bei mir war mal die hauptmotivation für einen eigenen controller der fakt, das die meisten china-mit-dabei-controller nach kürzester zeit (z.b. ein jahr) spinnen oder hopps gehen (tote fets, schlechte firmware etc). und die einzelnen IR-sender sind auch nicht wirklich elegant.

für echte digitalstrips/matrix (z.b. WS2812b), ist dagegen der ESP8266 ohne zusätzliche fets oder uC perfekt (per SPI).
wer "nur" ledstrips steuern will sollte hier zugreifen. diese strips sind mittlerweile sehr leuchtstark und auch mit hoher leddichte/m sehr günstig.