CNC3018 mit 5.5W Laser nutze ich.
Aber mehr sollte es dann hier im Thread nicht OT werden
Moderator: Co-Administratoren
CNC3018 mit 5.5W Laser nutze ich.
Das klingt ja so als wolltest Du den gravierenden Mangel der Fritte ausgleichen und einen schnell bootenden SNTP Server mit Netzausfallüberbrückung etablieren.deimos hat geschrieben: ↑17.06.2020, 00:08[*] Kabelgebundenes Netzwerk, IP per DHCP oder statisch
[*] MDNS Server um die HB-RF-ETH im lokalen Netzwerk bekannt zu machen
[*] PoE optional möglich
[*] WebUI für die Einstellung der Netzwerkparameter und für das Einspielen von Firmware Updates
[*] Ansteuerung einer RTC, entweder die vom RPI-RF-MOD oder ein optionales DS3231 Modul (wie z.B. https://www.amazon.de/DS3231-Echtzeituh ... ef=sr_1_10)
[*] (S)NTP Server zur Bereitstellung der Zeit im lokalen Netz (ggf. mit RTC Pufferung)
[*] (S)NTP Client zum Abruf der Zeit aus dem Internet
Wozu das? Ein LAN, welches eine piVCCU beinhaltet, wird ja wohl auch immer irgendwie Internetanschluss haben.deimos hat geschrieben: ↑17.06.2020, 00:08[*] DCF77 Empfänger mit optionalem DCF Modul (https://de.elv.com/elv-gehaeuse-fuer-ex ... =842724529)
[/list]
Respekt! Wenn der Prozessor I^2C hat, dann kann man doch ein I^2C EEPROM AT24C256 nehmen. Habe ich an meinem Wasseruhrsensor, war selbst für mich problemlos. Gibts mittlerweile sogar als fertiges breakout board.
Deimos schrieb eingangs mal was von ESP32. Dieser bringt 16k (physischen, nicht gänzlich nutzbaren) NVS mit. Das sollte mehr als genug sein.
ist wohl für ein solches Projekt nicht die beste Wahl.
Auch wenn ich nicht die Fritte im Speziellen im Sinn hatte, grundsätzlich war das der Gedanke.klassisch hat geschrieben: ↑17.06.2020, 00:44Das klingt ja so als wolltest Du den gravierenden Mangel der Fritte ausgleichen und einen schnell bootenden SNTP Server mit Netzausfallüberbrückung etablieren.deimos hat geschrieben: ↑17.06.2020, 00:08[*] Ansteuerung einer RTC, entweder die vom RPI-RF-MOD oder ein optionales DS3231 Modul (wie z.B. https://www.amazon.de/DS3231-Echtzeituh ... ef=sr_1_10)
[*] (S)NTP Server zur Bereitstellung der Zeit im lokalen Netz (ggf. mit RTC Pufferung)
[*] (S)NTP Client zum Abruf der Zeit aus dem Internet
SNTP ist auf UDP Ebene kompatibel mit NTP. So ziemlich alle Implementierungen, welche nur einen Upstream Server nutzen, sind per se "nur" SNTP; NTP definiert da vor allem viel bei der Auswahl der "richtigen" Zeitquelle und wie man bewerten kann, was die "richtige" Zeitquelle ist. Grade die ganzen ESPs können nur SNTP.klassisch hat geschrieben: ↑17.06.2020, 00:44Ich habe kürzlich gesehen, daß einer meiner ESP8266 basierten Sensoren meint, seit epoch uptime zu haben. Der war wohl beim Stromausfall 2018 schneller an Deck als die Fritte und ich habe diesen Zustand noch nicht ordentlich abgefangen. Da wäre so ein Server hilfreich. Und um alles konsistent zu halten, sollte die Fritte dann auch ihre Zeit von dort beziehen. Aber ob die mit einem SNTP zufrieden ist, oder einen NTP verlangt?
Einfach weil ich es kann und es cool fandklassisch hat geschrieben: ↑17.06.2020, 00:44Wozu das? Ein LAN, welches eine piVCCU beinhaltet, wird ja wohl auch immer irgendwie Internetanschluss haben.deimos hat geschrieben: ↑17.06.2020, 00:08[*] DCF77 Empfänger mit optionalem DCF Modul (https://de.elv.com/elv-gehaeuse-fuer-ex ... =842724529)
[/list]
Ich nutze ja den ESP32, der hat genug Flash dafür. Es geht bei dem Punkt nur darum, dass die geänderten Daten von der WebUI in das Flash geschrieben werden müssen. Von dort ausgelesen werden sie schon.
Nur bei Verwendung vom Arduino Core sind das 16k. Der NVS ist einfach eine Partition im Flash, bei Verwendung von esp-idf kann die auch deutlich größer sein als 16k, theoretisch auch mehrere MB. Wobei es bei den größen dann Sinn macht, das nicht per NVS, sondern per SPIFFS zu nutzen.
Der hat noch einige Vorteile mehr:
Bei einem ESP32 oder ESP8266 braucht man kein externes NVM für seltene Konfigurationen. Da nutze ich auch den internen Speicher. Bei meinem Wasserzähler mit dem ESP8266 schreibe ich vorwiegend volumengesteuert den Zählerstand ins EEPROM. Der wurde mittlerweile 34523 mal geschrieben. Das wollte ich dem eingebauten Flash nicht antun. Aber auch das ist nur "Spielerei", denn vorher hatte ich die zwischengespeicherten Daten nach dem Start von der CCU geholt. Das ging auch.
Mir ist es leider nie gelungen, die einzelnen Prozesse frei auf die Cores aufzuteilen. Der WLAN Prozess und mein Anwendungsprozess landeten immer auf dem selben Core. Aber ich habe das auch nur mit der Arduino IDE versucht und das auch nur zu Anfang. Das mag heute oder mit der Espressif-IDF gehen. Vielleicht war ich auch einfach zu ungeschickt und ich habe auch nicht genügend Zeit investiert um das RTOS zu erkunden.
Ja, die Erfahrung habe ich auch schon gemacht.
Das in jedem Fall!
Ja, das ist, wie Deimos schon schrieb, mit der Arduino IDE für den schnellen Einstieg wirklich gut.
Das klingt gut. Könnte man auch nutzen, wenn man den eigentlichen Funkmodul LAN Extender nicht braucht.
könnte eine Fritte von einem ESP die Zeit holen?
Das ist das Schöne bei unseren Freizeitprojekten. Da darf man sowas machen.
EEPROM.h kann das handeln. Allerdings Arduino.
Langfristig lohnt sich das sicher. Wahrscheinlich kann man dann auch die Prozesse den Cores zusteuern.deimos hat geschrieben: ↑17.06.2020, 08:16Ich hatte mit dem Arduino Core angefangen, aber ich bin wirklich froh, dass ich vor zwei Wochen alles auf esp-idf portiert habe, die Arduino Libs abstrahieren sehr viel weg. Das ist gut für Anfänger und schelle Projekte, aber für Spezialanwendungen ist es problematisch. Z.B. kann man mit den Arduino Libs den UART nur pollen, mit esp-idf kann man da Interrupt gesteuert arbeiten, was die Latenz natürlich deutlich verbessert.
Das klingt interessant.
Das ist für mich einer der größten Nachteile des ESP8266. Und wenn ich neben der debug-Schnittstelle eine HWSerial brauche, dann nehme den ESP32. Allerdings nur mit Arduiono IDE.
Oh, alle GPIOs! Das ist schon recht komplex.
Ja, z.B.
Kann ich leider nicht sagen, ich habe keine (mehr). Das Ubiquiti USG macht für den Nerd einfach deutlich mehr Spaß.
Ja, ist nur Arduino. In esp-idf sind das die nvs_set_* Methoden. Das physikalische Speichern ist auch schon fertig, mit fehlt der weg von WebUI per AJAX in meine Settings Klasse. Das ist technisch nicht weltbewegend, es ist einfach nur noch nicht fertiggestellt.
Auch bei Arduino kann man Prozesse auf andere Cores schieben, allerdings sind die internen fix einem Core zugeordnet. Ich versuche mich aber grade von einer Core Affinity zu lösen und dem Task Scheduler zu überlassen, welcher Core genutzt wird. Mit Arduino ist das leider unmöglich.klassisch hat geschrieben: ↑17.06.2020, 09:10Langfristig lohnt sich das sicher. Wahrscheinlich kann man dann auch die Prozesse den Cores zusteuern.deimos hat geschrieben: ↑17.06.2020, 08:16Ich hatte mit dem Arduino Core angefangen, aber ich bin wirklich froh, dass ich vor zwei Wochen alles auf esp-idf portiert habe, die Arduino Libs abstrahieren sehr viel weg. Das ist gut für Anfänger und schelle Projekte, aber für Spezialanwendungen ist es problematisch. Z.B. kann man mit den Arduino Libs den UART nur pollen, mit esp-idf kann man da Interrupt gesteuert arbeiten, was die Latenz natürlich deutlich verbessert.
Multicore-Programmierung bringt beliebig unglaubliche Fehler mit sich, wenn man nicht konsequent darauf achtet seine Variablen bzw. Daten vor Zugriffen aus einem anderen Kontext bzw. Core zur "falschen Zeit" zu schützen. Das ist bei SMP noch schlimmer als bei BMP.deimos hat geschrieben: ↑17.06.2020, 09:58Auch bei Arduino kann man Prozesse auf andere Cores schieben, allerdings sind die internen fix einem Core zugeordnet. Ich versuche mich aber grade von einer Core Affinity zu lösen und dem Task Scheduler zu überlassen, welcher Core genutzt wird. Mit Arduino ist das leider unmöglich.