Hallo liebes Forum
ich bin gerade dabei ein NodeMCU für einen LED Streifen mit WS2812B
Led's zu programmieren. Da das Timing ja schon etwas höhere
Anforderungen an die Prozessorgeschwindigkeit stellt, wollte ich die im
Hintergrund laufenden Tasks "abschalten".
Ich habe daher von https://nodemcu-build.com/ einen Custom Build
erstellen lassen, der nur das Timer und GPIO Modul enthält. Geholfen hat
es allerdings nicht. Der LED Streifen hat immer noch Timing Probleme.
(aufblitzende LEDs die eigentlich dunkel bleiben sollten)
Ich habe daher dieses Testprogramm geschrieben, um die Prozessorlast zu
testen:
1
//
2
#include<FastLED.h>
3
4
#define DATAOUT D1
5
#define LEDCOUNT 144
6
7
// the setup function runs once when you press reset or power the board
// the loop function runs over and over again until power down or reset
15
voidloop(){
16
digitalWrite(DATAOUT,HIGH);
17
digitalWrite(DATAOUT,LOW);
18
//presetLightBar(20, 25);
19
//presetFillingBar(20, 25);
20
//presetWaves(20, 25);
21
}
Das Scope-Bild dazu hängt im Anhang. Es stellt einfach nur den
Ausgangszustand des Pin D1 dar.
Der Prozessor hat am Ende der Mainloop noch immer "ganz schön viel"
zusätzliche Arbeit. Außerdem zeigt es, dass zwischen den "high" zu "low"
Zeilen auch noch "etwas" eingreift.
Meistens dauert die high periode 400ns, immer wieder aber auch mal 10µs.
Jemand eine Idee, was die Firmware da im Hintergrund noch treiben könnte
und wie man ihr das austreibt? :) .....die Interrupts habe ich ja schon
abgeschaltet...denke ich zumindest.
F. K. schrieb:> Jemand eine Idee, was die Firmware da im Hintergrund noch treiben könnte> und wie man ihr das austreibt?
Es ist natürlich deine Sache, aber ich persönlich bin der Meinung das es
immer sinnvoll ist vor dem Loslegen die Dokumentation zu lesen.
Natürlich hat die Firmware diverse Sachen zu tun: Den WIFI-Stack
bedienen, den LUA-Interpreter ausführen und ettliche andere Sachen. Mit
einem LUA-Programm wirst du deshalb nie das nötige Timing hinbekommen.
Dazu ein Tip: Wenn du dir eh schon von https://nodemcu-build.com/ einen
Custom-Build erstellen lässt: Da gibt es auch ein WS2812-Modul. Lass dir
das einbinden, dann werden die WS2812-Routinen Teil der Firmware und mit
der entsprechenden Priorität abgearbeitet.
Edit: Moment. Was mir jetzt erst auffält: Du schreibst du hast dir eine
Custom-Build von https://nodemcu-build.com/ erstellen lassen, aber dein
Beispielcode ist offenbar in C, d.h. du versuchst da zwei völlig
verschiedene Sachen zu vermischen. Die Firmware von
https://nodemcu-build.com/ ist ausschließlich für die Leute gedacht, die
die Nodemcu in LUA programmieren wollen. Wenn du die Arduino-IDE und C++
benutzt, ist die Firmware von https://nodemcu-build.com/ nicht
erforderlich und wird sowieso durch die Arduinokompatible Firmware
überschrieben. Aber auch in dem Fall solltest du eine Vorgefertigte
WS2812-Library benutzen, denn auch unter der Arduino-IDE gibts es
diverse Timings zu beachten, was die Library automatisch macht.
Du kannst das natürlich alles abschalten...dann musst du nur auf Wifi,
Watchdog usw verzichten ;)
Guck dir das native WS28XX Modul der NodeMCU Firmware an wie die Leute
es dort gelöst haben... ein Tipp vorweg...nicht im "Arduino Style" Loop
;)
Das Thema mit der Doku....sprech ich lieber nicht an. Sonst werde ich
noch wegen Schimpfwörtern gebannt....
Natürlich weiß ich, dass die Firmware einiges im Hintergrund tut.
Deshalb habe ich ja auch den Custom Build ohne den ganzen Kram erstellt,
den ich nicht brauche.
Wenn die IDE das Hinterher aber wieder draufbügelt, finde ist das schon
unnötig umständlich undurchsichtig.
Ich hab mich sowieso gewundert, warum der Controller nicht abstürzt,
wenn ich die WiFi Lib verwende, obwohl sie in der Firmware garnicht
enthalten sein sollte.
Na mal schauen was passiert, wenn ich die WS Lib statt von der IDE vom
Custom Build integrieren lasse.
Euren Aussagen nach, dass die IDE eh die Firmware überschreibt, dürfe es
ja keinen positiven Effekte geben.
Klingt so, als hättest du noch immer nicht verstanden, dass der Custom
Build eine entsprechende IDE (für LUA) voraussetzt und die Arduino-IDE
ihr eigenes Ding macht (quasi unabhängig davon was du in den
Custom-Biuld integrierst!)
Zuerst musst du dich entscheiden welchen der beiden Wege du gehst.
Derzeit gehst du den Arduino-IDE Weg, somit ist das was mit dem
Custom-Build gemacht wird überflüssig. Dies scheint die aber nicht
bewusst zu sein.
Weil ich ja nicht erst noch wieder auf eine andere Syntax wechseln will,
bleibe ich natürlich bei c.
Was mich allerdings zu meiner ursprünglichen Frage zurückführt.
Da ich ja nun gelernt habe, dass meine IDE mir ein Bein stellt, kann ich
meine ursprüngliche Frage präzisieren.
Wie bringe ich meinem VisualStudio Arduino Plugin bei, den unbenötigten
Kram auch tatsächlich nicht in den Controller zu pumpen?
Weil man 5 NodeMCU (mit 80MHz) billiger bekommt bzw. dann welche über
hat, als ein neues Embedded Board zu kaufen....die WS2812B brauchen
Dampf unter der Haube.
Ich würde ja statt einem ESP8266 einen ESP32 nehmen.
Hier kümmert sich ein Core über Wifi, usw.
Und den zweiten Core kannst du für deinen Programm nehmen und solltest
keine Aussetzer haben.
Sven B. schrieb:> Ich würde ja statt einem ESP8266 einen ESP32 nehmen.> Hier kümmert sich ein Core über Wifi, usw.
Und der hat echte Hardware drin, nicht bloss Software.
F. K. schrieb:> Weil man 5 NodeMCU (mit 80MHz) billiger bekommt bzw. dann welche über> hat, als ein neues Embedded Board zu kaufen....die WS2812B brauchen> Dampf unter der Haube.
Das erinnert mich an folgenden Witz.
Ein Betrunkener krabbelt in stockfinsterer Nacht um eine Laterne herum.
Fragt ihn ein Passant, was er den suche. Er lallt darauf: "Meine
Schlüssel". Der Passant hilft suchen, findet aber auch nichts und fragt
nach: "Wo haben Sie die denn verloren?", darauf der Betrunkene: "Da
hinten". Fragt der Passant nach: "Und warum suchen Sie dann hier?", der
Betrunkene: "Hier ist das Licht besser."
Nichts für ungut ;)
Ich würde den Schlüssel einfach bei Tageslicht suchen....oder anders
ausgedrückt:
Wenn ich mir ein anderes Board kaufen wollte, würde ich einfach eines
ohne "zwangsaktive Peripherie" nehmen. :)
Das denkst aber nur du...
Man kann zwar mit der Hardware und DMA solch ein Signal erzeugen aber
man muss trotzdem extrem aufpassen. Diese lehrreiche Erfahrung musste
ich machen als ich Encoder abtastete. Also alle 10ms Timer ISR unterster
Priorität das GPIO Register lesen. Das wirkte sich hinterher so aus das
es drop outs im WIFI gab. Teilweise bis 2sec..
Das Ding ist zwar billig aber in vieler Hinsicht Murks.. Da man immer
Gefahr läuft mit der Anwender Task das System durcheinander zu bringen.
Vor allen dann wenn Task blockierend geschrieben wurden. Man muss sich
im klaren sein das man nur ein kleinen Teil der Ressourcen nutzen kann.
Da man die Ressourcen mitbenutzt kann man nie sicher sein was beim
nächsten Firmware Update für seltsame Sachen passieren.
Vor dem Update der IDF lief mein Encoder noch ;) danach stört er irgend
einen Teil im lwip.