Hallo, ich möchte gerne ein Java-Programm auch auf einem ESP8266 ausführen, nur leider kann ich keine JVM finden die diesen explizit unterstützt. Für die ARM µC gibts einiges und für die AVR auch, aber für den ESP finde ich nichts. Und den Umweg Java->C->Binärcode empfinde ich als unsauber, zumal man mir gesagt hat dass wahrscheinlich der C-Code noch an den ESp angepasst werden muss und man spezifische Libraries einbinden. Was genau da gemacht werden müsste und wie viel Aufwand das ist konnte mir bis jetzt niemand sagen. Deswegen suche ich nach einer JVM für den ESP8266. Viele Grüße und vielen Dank!
>ich möchte gerne ein Java-Programm auch auf einem ESP8266 ausführen,
Buhahahhahhhahhaah!
holger schrieb: >>ich möchte gerne ein Java-Programm auch auf einem ESP8266 ausführen, > > Buhahahhahhhahhaah! https://xkcd.com/801/
Ihr tut ja so als ob dies ein abwegiges Anliegen wäre...
Warum muss es eine jvm sein? - weil Du in java programmieren willst? - weil der code interpretiert werden soll und sich dynamisch ändern kann Im ersten Fall, der GCC hat auch ein Java Front end, das erzeugt dann den gleichen Register transfer code und wird dann auf die Ziel Plattform über setzt. Dazu musst du nur die toolchain selbst kompilieren und das Java Frontend einschalten. Wenn du was zum interpretieren willst, nimm lua. Oder wenn du beides unbedingt willst, nimm dir die Zeit und schreibe deine eigene jvm.
Neo schrieb: > Ihr tut ja so als ob dies ein abwegiges Anliegen wäre... Ich wollte zuerst antworten, wie du denn die JVM in die 512Kb Flash bekommen willst. Aber dann habe ich festgestellt, das es tatsächlich Leute gibt die JVMs für Mikrokontroller geschrieben haben, z.B.: http://dmitry.gr/index.php?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM Nur wie du auf der Seite lesen kannst ist das ganze nicht so trivial, da nur sehr begrenzte Resourcen an RAM und Flash zur Verfügung stehen. Wenn du Glück hast kompiliert diese JVM auf dem ESP, aber es sind auf jeden Fall Änderungen erforderlich, mindestens das ICACHE_FLASH_ATTR musst du an alle Funktionen schreiben, sonst passt die JVM auf keinen Fall auf den ESP. Und dann musst du noch irgendwie deine Applikation zu der JVM in den Flash packen, ist die überhaupt kleiner als 512Kb?
Java auf einem UC ist bedeutend mehr Aufwand. Wenn man C oder C++ beherscht, kann man Platformabhängige Teile auf ein minimum redizieren, indem man platformabhängige funktionen wie z.B. LED xy an in eigene c Dateien auslagert, dann ist es für den Platformunabhängigen code egal, wie die LED eingeschaltet werden muss und auf welcher Platform er ist, es muss nurnoch die richtige Implementierung dazugelinkt werden. Bei Java gibt es keine fertigen Funktionen um Pins zu toggeln, etc. Platformabhängiges bleibt dadurch Platformabhängig. Ausserdem hat man mehr overhead, egal ob mit JVM oder ohne und nativ mit GCJ. GCJ hat eine sehr träge Entwicklung, und eine JVM mit vollständuger Runtime wirst du wohl kaum finden. Eine eigene JVM zu schreiben ist nichteinmal alzu kompliziert, aber wenn man die normale Java Runtime Library nutzen will muss man all deren Funktionen implementieren, das dauert ewig, und ob dass dann noch in einen ESP8266 passt wage ich zu bezweifeln. Und dann kommt noch dazu, dass du zu Java auf UCs fast keine Codebeispiele finden wirst.
Java auf so einem Prozessor ist eine Verschwendung von 80% Resourcen um mit den restlichen 20% es sich einfach zu machen und mit Java zu programmieren. Bei einem PC ist die Relation etwas besser, da kann man den Overhead verkraften, bei beim Mikroprozessor ist es einfach nur Unsinn. Naja, für manche ist es eine Challenge, das zu schaffen, das ist aber dann auch schon alles, was sie erreichen wollten.
Ich glaube ich schreibe einfach mal etwas mehr über das Projekt, dann sollte etwas klarer sein,warum ich Java nehmen will: Dieses Jahr im April habe ich angefangen eine künstliche Intelligenz für Strategiespiele zu entwickeln,anfang August stand ein rudimentäres ML-Programm.Realtiv primitiv, die Spielumgebung war auch nur diskret/2D(wie beim Schach),und die KI hätten wohl eher nicht gegen einen Menschen gewonnen(aber das ist die Baustelle für 2017). Diese Basis habe ich die letzten Monate auf kontiuierliche 3D-Welten welche mit OpenGL visualiziert werden und Interaktionsmöglichkeiten bieten erweitert. Jetzt implementiere ich in der Simulation Algorythmen für nichtdeterministe Lokalisierung und Kartenerstellung innerhalb der Simulation mit verrauschten simulierten Sensoren/Aktuatoren für die Agenten innerhalb der Simulation. Ich habe auch einen kleinen Roboter gebaut, aktuell noch ohne Sensorik,aber schon aus dem Programm heraus direkt steuerbar.Will heißen eine Instanz mit graphischer Oberfläche läuft auf dem Laptop mit einfachen Buttons für Steuerbefehle,welche über das Netzwerk and die Instanz welche auf dem µController des Roboters läuft geschickt werden. Der Controller in dem Roboter ist aktuell ein Raspberry PI, welcher mit seinen GPIOS an die Transistoren des Motors geht. So Ende Q1/2016 will ich dann den Simulationsteil mit dem ML-Algorythmen verwenden um den Roboter selbstständig fahren zu lassen.Dabei soll der höherlevelige Gesamt-Überblick auf dem Leistungsfähigerem System berechnet werden (Laptop/Server), und der Roboter nur lokal eine gewisse Intelligenz haben. Dadurch dass beide Instanzen die gleiche Software haben, kann bei Ausfall/Nichterreichbarkeit des Servers der Roboter auch das strategische Aufgaben übernehmen und selbstständig nach bestem Wissen und Gewissen seine weiteren Aktionen/wegpunkte planen.Hierzu muss er natürlich einige Abstriche bei der Qualität der Berechnung machen,also zum Beispiel weniger Partikel bei einem nichtparametrisiertem Lokalisierungsalgorythmus. Und bis Ende 2016 will ich dann die Software so weit haben, dass ein verteiltes System Berechnungen für die Maschinen-Learing Komponenten ausführen kann, das System also auf mehr als nur Zwei Agenten mit klar definierter Hierarchie skaliert. Wozu betreibe ich diesen Aufwand? Nun ja ich möchte dann (Shitty-)Roboterbau Workshops bei uns im Labor anbieten (www.openlab-augsburg.de).Wir machen schon 3D-Drucker Workshops wo Leute dann mit nen selbstgebauten 3D-Drucker nach Hause gehen, aber dass ist halt nichts für jeden und kostet auch etwas mehr(aktuell ca. 650€) Bei dem Roboterworkshop könnte man unter 10€ Materialkosten bleiben. Nen ESP8266 kost ca 2€ ,Motortreiber ca. 1,5€ ,Ultraschallsensor 1€ und Kleinzeugs. Gehäuse würden wir dann improvisiren/Basteln (wir haben hier schon einen Roboter rumfahren der nen Handstaubsauger als Gehäuse hat) oder mit unseren 3D-Druckern fabrizieren. Aber eigentlich wirklich interessant wird dieser Workshop,wenn die Software schon steht. Dann können die Leute sich einfach auf die Mechanik/Elektrik konzentrieren und dann die Java binaries aufspielen. Der Neue Roboter mesht dann mit dem bestehenden und wird so ins Netzwerk aufgenommen und man kann dann schon recht viele Dinge mit machen, sowohl mit direkter Steuerung(was die Software ja jetzt schon bietet) über das Netzwerk, als auch autonom bzw. durch das Netzwerk gesteuert. Das sollte dann eigentlich schon viele Leute begeistern. Soweit der Plan... Und warum jetzt Java? Java stellt in diesem Fall die Ideale Lösung dar, da damit auf einer sehr heterogenen Masse an Agenten (x86 Rechner, Smartphones, diverse Mikrocontroller, sogar ardunio) der gleiche Bytecode installiert werden kann. Ein Roboter mit einem Raspberry PI kann dann einen neuen Roboter direkt mit seinen eigenen Bytecode flashen.Vorausgesetzt natürlich die Zielplattform hat eine JVM installiert, wofür natürlich auch ein initaler Aufwand draufgeht. Aber im Falle eines Softwareupdates muss nur ein neuer Bytecode über das ganze Netzwerk propagiert werden, und nicht für jeder Zielplattform neu gebaut und dutzende Binaries verteilt werden.Profit. Das Java nun langsamer läuft als nativer code ist in dem Fall egal...was juckt es mich wenn etwas "nur" halb so schnell ausgeführt wird wie es theoretisch ausgeführt werden könnte? Die Echtzeitkritischen Abläufe (z.b. Motorsteuerung) verbrauchen kaum Leistung, und die Rechenintensiven ML-Operationen kann ich entweder auf Kosten der genauigkeit runterschrauben (Siehe obiges Beispiel mit Partikelfilter) oder auf Leistungsfähigere Agenten auslagern. Wobei ich behaupten würde dass wenn etwas mit Java so langsam/garnicht läuft dass ich es auslagern muss da der Geschwindigkeitszuwachs durch nativen code auch nichts retten kann, da dann einige Größenordungen zu wenig Rechenleistung vorhanden ist(z.b. Bildverarbeitung auf einem Ardunio). gez. Neo PS: Ursprünglich war das Projekt in C++, aber wir haben nach ein paar wochen auf Java portiert. Neben den oben genannten Gründen für Java kam nämlich auf dass es kein zuverlässiges UML-Round-Trip-Engieering-Tool für C++ gibt. Das war auch wichtig. UML <3 PPS: Ich weiß das ihr hier auf dem Forum Erfahrungen gemacht habt mit Anwendungsentwicklern die nach Java auf µContollers fragen weil sie nur Java können (habe ja die Suche verwendet), und deswegen schon etwas voreingenommen auf die Frage reagiert, aber ich habe schon durchaus auch Assembler programmiert und finde C/C++ auch sehr toll, Java ist für dieses Projekt einfach nur die bessere Wahl.
Du willst keinen ESP8266 verwenden, sondern einen Raspberry Pi. Sorry, aber die Prozessorleistung, die dein Programm benötigt, ist einfach zu groß, um sie auf "kleiner" Embedded-Hardware auszuführen. Nächstes Jahr ist sicher auch der Raspberry Pi Zero in Stückzahlen verfügbar und dadurch einigermaßen kostengünstig zu haben. Damit relativiert sich die Sache wieder etwas.
Lern was vernünftiges Jung und schmeiß das Javazeug in die Ecke. Jede Firma die im Embeddedbereich tätig ist, wird dich nach 1 Woche wieder vor die Tür setzen wenn Du da mit Java ankommst. Jede Minute die Du noch das tote Pferd reitest ist verschwendete Zeit. Selbst im kommerziellen Umfeld ist Jave mittlerweile dabei seinen nicht vorhandenen guten Ruf vollständig zu verderben. Beispiele aus der Praxis: IBM Cognos sollte einen Report aus Datenbanken erstellen: Rödelt 90 sek, und stürtz ab. 2. Versuch: Rödelt 90 sek, und stürtz ab. 3. Versuch: Report wird erstellt. Das hat doch nichts mehr mit deterministischer Programmierung zu tun. Webportal JBoss und Javabasiert: Braucht 8 Stunden um zu starten und erzeugt dabei nebenbei 50 GB an Logdaten voll mit Fehlermeldungen. Unbrauchbar. Tomcat Webserver saugen sämtlichen verfügbaren RAM in sich. Neustart alle 24 Stunden ist unvermeidlich. Mindestens ärgerlich. Weg mit dem Javadreck.
Neo schrieb: > Java stellt in diesem Fall die Ideale Lösung dar, da damit auf einer > sehr heterogenen Masse an Agenten (x86 Rechner, Smartphones, diverse > Mikrocontroller, sogar ardunio) der gleiche Bytecode installiert werden > kann. Nein. Nein nein nein. Nein. Java kennt kein Interface für die IO Geschichten von Embedded Devices weil es, oh Wunder, nicht dafür gemacht ist. Letztendlich wird platformabhängiger Code also, wie bereits geschrieben, auch platformabhängig bleiben. Wenn du das wirklich abstrahieren willst brauchst du ein Betriebssystem (z.B. Embedded Linux) mit Shared Libraries und allem drum und drann. Aber selbst dann, ja SELBST DANN, würde man vermutlich C++ bevorzugen und den Mist halt einmal (cross)compilen, das ist ja genau 0 Aufwand. Insbesondere wenn man es direkt auf dem Ziel-Linux-System compilen kann.
@ Autor: Alta Sagg (Gast) Höre ich aus deinem Beitrag eine leichte Aversion gegen Java?
NibbleViewer schrieb: > Höre ich aus deinem Beitrag eine leichte Aversion gegen Java? Dem könnt' ich mich grad anschließen, aber es ist ja schon alles gesagt ...
Alta Sagg schrieb: > Selbst im kommerziellen Umfeld ist Jave mittlerweile dabei > seinen nicht vorhandenen guten Ruf vollständig zu verderben. > > Beispiele aus der Praxis: > IBM Cognos sollte einen Report aus Datenbanken erstellen: > Rödelt 90 sek, und stürtz ab. > 2. Versuch: Rödelt 90 sek, und stürtz ab. > 3. Versuch: Report wird erstellt. > > Das hat doch nichts mehr mit deterministischer Programmierung zu tun. > > Webportal JBoss und Javabasiert: Braucht 8 Stunden um zu starten > und erzeugt dabei nebenbei 50 GB an Logdaten voll mit > Fehlermeldungen. > > Unbrauchbar. > > Tomcat Webserver saugen sämtlichen verfügbaren RAM in sich. > Neustart alle 24 Stunden ist unvermeidlich. Ich glaube da arbeiten Leute mit Java, die keine Ahnung davon haben. Arbeite seit ca. 10 Jahren damit, v.a. Mit komplexen Frameworks für eCommerce wie Hybris (komplexes Webportal würde hier in Minuten starten) und habe keine Probleme damit. Java ist einfach nur genial. Und die Nutzung steigt, gerade erst vor 2 Wochen gelesen.
> Höre ich aus deinem Beitrag eine leichte Aversion gegen Java? s/leichte// Das für mich beruhigende ist ja, daß der TO das Ganze nie zu einem Ende bringen wird. Schon die nicht vorhandene JVM wird er nicht schreiben können, von dem IO-abhängigen Teil gar nicht zu reden. Enden wird es damit, daß ein Stück völlig überdimensionierte Hardware Dinge tun muss, für die u.U. ein kleiner 8-Bitter oder ein ARM-M0/M0+/M3 gereicht hätte. Im stillen Kämmerlein mag das nicht schlimm sein, aber wenn es andere sehen, wird der TO wie ein Idiot da stehen. Weihnachtliche Grüße an alle mit Javaaversion
Thomas Z. schrieb: > wie du denn die JVM in die 512Kb Flash Viele ESP8266 haben 4MByte Flasch. Auch ein Umbau von 0,5MB auf 4MB ist möglich. Dann stehen fast 1MB für Programm und fast 3MB für sonstige Zwecke zur Verfügung. (ein paar Happen belegt das SDK für Config Dinge) Ob das reicht? Der Raspberry ist da eine ganz andere Nummer. Der Arm da hat einem Java Befehlssatz eingebaut (zumindest die älteren). Das dürfte den Bau einer Java VM deutlich vereinfachen. Und die sie schlanker halten.
Neo schrieb: > Und warum jetzt Java? > > Java stellt in diesem Fall die Ideale Lösung dar, da damit auf einer > sehr heterogenen Masse an Agenten (x86 Rechner, Smartphones, diverse > Mikrocontroller, sogar ardunio) der gleiche Bytecode installiert werden > kann. Ein Roboter mit einem Raspberry PI kann dann einen neuen Roboter > direkt mit seinen eigenen Bytecode flashen.Vorausgesetzt natürlich die > Zielplattform hat eine JVM installiert, wofür natürlich auch ein > initaler Aufwand draufgeht. Aber im Falle eines Softwareupdates muss nur > ein neuer Bytecode über das ganze Netzwerk propagiert werden, und nicht > für jeder Zielplattform neu gebaut und dutzende Binaries verteilt > werden.Profit. Um hier neben dem ganzen Java gebashe mal was produktives beizutragen: Ist zwar kein Java, aber kennst du MicroPython? http://micropython.org/ Das ist ein Pythoninterpreter der auf einem µC läuft. Das original Board ist aber viel zu teuer. Aber du kannst ein ganz normales STM32F4-Discovery nehmen und das da aufspielen. Hab ich auch schon gemacht, läuft super. Dazu noch ein kleines board mit z.B. WIZNET-Chip für Netzwerk und fertig. Wenn da was in den mitgerbachten Libs fehlt, kann man das auch ganz einfach in C/C++ nachschieben. Das Projekt ist öffentlich auf GitHub verfügbar: https://github.com/micropython/micropython Und Python ist super einfach zu lernen. Und du hättest ebenfall nur eine Datei für x86, Rpi, µC... Vielleicht ist das ein möglicher Ansatz für Dich? Grüße
Oh, ich sehe gerade, da scheint auch irgendwas für en ESP8266 drin zu sein ;)
Thomas schrieb >Ich wollte zuerst antworten, wie du denn die JVM in die 512Kb Flash >bekommen willst. Aber dann habe ich festgestellt, das es tatsächlich >Leute gibt die JVMs für Mikrokontroller geschrieben haben, z.B.: >http://dmitry.gr/index.php?r=05.Projects&proj=12.%... Ja, und es geht noch kleiner: http://www.harbaum.org/till/nanovm/index.shtml
Neo schrieb: >Bei dem Roboterworkshop könnte man unter 10€ Materialkosten bleiben. >Nen ESP8266 kost ca 2€ ,Motortreiber ca. 1,5€ ,Ultraschallsensor 1€ und >Kleinzeugs. Im Moment sind wir auch dabei, solche Low-Cost-Roboter zu entwickeln: http://roboterclub-freiburg.de/projekte/freiBot/index.php Mit dem aktuellen Design sind die 10€ aber nicht ganz zu halten, wenn man wirklich alles mit einkalkuliert ( z.B. Klebstoff ). Könntest Du mal eine Kalkulation in Excel machen und hier zeigen? Am Anfang dache ich auch an 10€, aber wenn man alles in einer Liste aufführt ist es dann doch mehr. >Gehäuse würden wir dann improvisiren/Basteln (wir haben hier >schon einen Roboter rumfahren der nen Handstaubsauger als Gehäuse hat) >oder mit unseren 3D-Druckern fabrizieren. Demnächst wird es aber ein kostengünstigers Modell geben Beitrag "Re: 3D Drucker Prusa I3" >Wir machen schon 3D-Drucker Workshops >wo Leute dann mit nen selbstgebauten 3D-Drucker nach Hause gehen, aber >dass ist halt nichts für jeden und kostet auch etwas mehr(aktuell ca. >650€) >Das kommt mir etwas viel vor, den Prusa kann man für 300€ erstehen und in >3 Tagen zusammenbauen: Beitrag "Re: 3D Drucker Prusa I3" Wir werden eventuell demnächst auch vom Arduino-Nano auf den ESP8266 umstellen.
Ist das Projekt weiter gekommen? Ich suche nach real funktionierenden Projekten mit ESP866 Chip, um von deren Erfahrungswerten zu lernen. Bisher habe ich im Groben nur Ganzen nur ferngesteuerte Lichtschalter, Hello-World Beispiele und Anleitungen für Firmware-Upgrades gefunden. Mir scheint es so, dass die allermeisten Anwender nicht weiter gekommen sind, als bis zum "Hello World". Ich hoffe, dass dieser Eindruck falsch ist.
Angehängte Dateien:
-
Steckbrett.jpg
240 KB
Hallo, @Stefan Us: was sind real funktionierende Projekte? 1x Uhr: ESP8266, DBOX-1-Display, Zeit per NTP. 1x Thermometerscala: ESP8266, IN-9,, Spannungswandler reine Temperaturscala, holt als MQTT-Client die Daten von sowieso vorhandenen Sensor. 1x Laufschrift: ESP8266, alte Pearl-Laufschrift, MQTT-Client z.B. für meine Bad-Licht-Warnung, Webserver auf dem ESP um Lauftexte anzuzeigen. 1x Bad-Licht-Erinnerung: ESP8266, Spannungswandler, hängt an den 12V-Halogenlampen, die gern vergesse aus zuschalten. MQTT-Client 1x Steckdose: ESP8266 mit Kondensatornetzteil im Originalgehäuse einer Funksteckdose, MQTT-Client 1x "Spielkiste": ESP8266, RFM12 als Empfänger meiner alten Funksensoren, schickt z.B. die Temperatur für die Anzeige oben. MQTT-Client, Webserver mit Ausgabe der alten Sensoren, RFM12 auch als OOK-Sender für meine normalen Funksteckdosen, 2x 8-stellige 5x7 Display an 2x MCP23S17 am SPI des ESP. 1x Handscanner: ESP8266 mit Wandler an Li-Io-Zelle als MQTT-Client. Schickt eine gescannte EAN, hat im Moment noch keine wirkliche Verwendung, wird aber wohl eine Einkaufserinnerung für selten gebraucht Sachen. Zur Zeit im Test: Sreaming-Client: ESP8255, STA013 (lag noch rum), spielt zur Zeit eine 80er Jahre Stream, fliegt manchmal aus dem WLAN, Bufferverwaltung ist noch nicht so ganz ideal. Alle Sachen laufen teilweise schon seit etlichen Wochen stabil, alle sind per OTA-Update zu programmieren. Das Rausfliegen aus dem WLAN ist auch weniger ein ESP8266-Problem, mehr ein Problem der Auslastung hier am Standort... Meine Erfahrung: es gibt recht wenig wirkliches Interesse, ESP8266 spziell in Verbindung mit der Arduino-IDE ist verpönt, in den Arduino-Foren sind die Leute eher überfordert, deutsche Foren sind ansonsten Fehlanzeige, etliche Informationen muß man recht mühsam zusammensuchen. Möglicherweise kann man eine JavaVM auf den ESP bringen, nur sehe ich da den Sinn der ESP-Hardware eigentlich nicht. Gruß aus Berlin Michael
http://www.lemon64.com/forum/viewtopic.php?t=57035 ist ein WLAN Modem für den c64. Mit eigener Firmware zum Setzen von IP Adresse usw, da der c64 nicht genug Speicher für sowas hat.
Ui, da hast du ja schon eine Menge gemacht. Ich möchte dich etwas fragen: Meine beiden Module haben die AT Firmware 0.9.1. Also schon etwas älter. Ich warte gerade auf Lieferung neuer Module, um mal ein Upgrade zu probieren. Hast du auch das Problem, dass die Module sich häufig teilweise aufhängen? Bei mir fängt es immer damit an, dass das Modul IP Pakete in eine Richtung nicht mehr weiter reicht. Dann irgendwann werden AT Befehle nicht mehr beantwortet. Manchmal trennt es auch die Verbindung zu Access Point (bzw im AP Modus die Verbindung zum Rechner/Smartphone) und verweigert dann einen neuen Verbindungsaufbau. Ich muss meine beiden Module tagsüber ca 2x pro Stunde resetten. Nachts jedoch nur etwa alle 2-4 Stunden. Das passt du deiner Aussage, dass es wohl mit der Auslastung des Netztes zusammen hängt. Egal, ob die Last hoch ist, es darf meiner Meinung nach trotzdem nicht blockieren. Ich habe gelesen, dass diese Probleme sowohl bei der AT Firmware auftreten, als auch bei der LUA Firmware. Dann habe ich noch ein super nerviges Problem: Das Modul lässt vereinzelt IP Pakete verschwinden. So als würde ich alles mit UDP übertragen, aber das passiert bei TCP mit ebenso. Was ja nicht im Sinne des Protokolls ist. Selbst wenn ich nur eine Verbindung offen habe und der PC nur 1 kleines "Hallo" pro Sekunde an das WLAN Modul sendet, geht dort jedes 20. Paket irgendwo verloren. Es sendet aber immer schön brav ein ACK zurück zum PC. Wenn ich mehr als ein Paket pro Sekunde an das WLAN Modul sende, steigt die Anzahl der verloreren Pakete rapide an. Und dann ist mir noch ein Designfehler in der AT Firmware aufgefallen: Wenn mein seriell angebundener µC beginnt, einen AT Befehl abzusetzen, und während dessen ein Paket empfangen wird, kommt die Kommunikation völlig durcheinander. Sende: AT+CIPSE (jetzt kommt gerade was rein) ND,0,3\r\nbla Empfange: +IPD,1,6\r\nHallo\nOK Bei diesem OK weiss ich nicht, ob das zum +IPD gehört, oder zum +CIPSEND. Ich wundere mich sowieso darüber, dass das Ding nach +IPD stets noch ein OK nachschiebt. Was soll ich damit anfangen? Wem will er damit "Ok" mitteilen, sich selbst? Sehr häufig hängt sich das Modul auch einfach auf, wenn es gleichzeitig sendet und empfängt. Also je mehr Daten ich übertrage, umso unzuverlässiger wird es - kann man generell sagen. Hast du auch die Erfahrung gemacht, das man das Modul ständig von außen überwachen muss, um es ggf. zu resetten? Blödes Teil, ich bin von dem Ding echt genervt. Manchmal wünschte ich, man hätte es nie auf den Markt geworfen, dann könnte ich ruhiger schlafen. Aber jetzt kann ich es einfach nicht mehr ignorieren, der Preis ist zu verlockend :-)
Stefan U. schrieb: > Ui, da hast du ja schon eine Menge gemacht. Ich möchte dich etwas > fragen: Naja, eigetnlich sind es alles "proof of concepts"... Mir hat das Modul und der Preis gefallen ohne daß ich eine wirkliche Verwendung dafür hatte. > Meine beiden Module haben die AT Firmware 0.9.1. Also schon etwas älter. Ich ahbe letzte Woche aktuelle -01 Module bekommen, AT-Firmware ist 1.4, 8MBit Flash drauf. Allerdings habe ich mit der AT-Firmware nie wirklich was gemacht > Hast du auch das Problem, dass die Module sich häufig teilweise > aufhängen? Ich habe überall eigene Software drauf. Ein direktes Aufhängen habe ich ich nur am Anfang meiner Programmierübungen gehabt, die Bekanntschaft mit dem Watchdog und Stack-Traces des ESP war manchmal frustrierend. Ungefragte Neustarts machen sie fast garnicht mehr, meine "Spielkiste" schafft es etwa 1-2x pro Woche. Die Antwortet auch manchmal zu langsam für den Mini-Browser auf dem PC, so daß meine Sensorwerte nicht angezeigt werden. Seite neu laden reicht dann aber, es gab auch keinen Neustart, dann wären erstmal die Temperaturwerte weg, die kommen nur alle Minute von den RFM-Modulen. Entweder ein WLAN-Reconnect oder zulange mit sich selbst beschäftigt. Das muß ich mir noch anschauen. Alle obigen Module haben MQTT drauf und senden beim Connect mit dem WLAN ihre IP und die Feldstärke an die Laufschrift, ich würde sehe es also meist auch direkt sehen. Die "Spielkiste" zeigt auf ihrem Display auch alle empfangenen IR-Codes an, die hat bisher auch immer reagiert, wenn ich die Fernbedienung benutze. > Ich habe gelesen, dass diese Probleme sowohl bei der AT Firmware > auftreten, als auch bei der LUA Firmware. LUA und auch die Basic-Firmware habe ich auch nur sehr kurz angeschaut... > Dann habe ich noch ein super nerviges Problem: Das Modul lässt > vereinzelt IP Pakete verschwinden. Ist für mich schwer zu beurteilen. MQTT-Messages sind bisher nicht erkennbar verschwunden, mit meiner Webseite und dem Formulartest drauf kann ich zumindest stabil rumspielen. Also Seite vom ESP anfordern (ist mein eigener kleiner Webserver drauf) mit Textfelder, Radiobutton und Chckboxen. Ausfüllen und per Submit zum ESP. Der schickt dann die Antwort mit den Eingaben. Da tritt kein Fehler auf. Downloads vom ESP machen auch keine Probleme mehr, ein 250kB jpg aus dem SPIFFS wird zwar langsam aber zuverlässig zum Browser geschickt und angezeigt. War auch ein Webservertest, am Anfang crashte er da gern oder brauch die Übertragung ziemlich schnell ab. > Sehr häufig hängt sich das Modul auch einfach auf, wenn es gleichzeitig > sendet und empfängt. Also je mehr Daten ich übertrage, umso > unzuverlässiger wird es - kann man generell sagen. Gleichzeitig ist immer relativ ;) Die Seite mit den Sensordaten wird vom Webserver alle 15s vom PC angefordert, wenn der an ist und der ist immer an, wenn ich zuhause bin. Per MQTT werden die Messages alle 15s an die Thermometeranzeige geschickt, Meldetexte z.B. vom Badlicht an die Anzeige usw. > Hast du auch die Erfahrung gemacht, das man das Modul ständig von außen > überwachen muss, um es ggf. zu resetten? Nein. Die Software muß natürlich aufpassen, WLAN-Reconncts sauber ausösen, falls das Modul ruasfliegt usw. Da ist mir gestern ein Problem aufgefallen, daß ich mit unbedingt ansehen muß: mein WALN-Router steht auf einem festen Kanal. Den habe ich gestern geändert beim Experimetieren mit dem Stream-Client. Keins meiner ESP-Module ist damit klargekommen! Ich durfte zum ersten Mal alle von Hand neustarten... Den Stream-Client habe ich gestern abend auch noch kaputt programmiert, er lief stundenlang stabil bis auf 2 WALN-Reconnects, die er nicht hinbekam. Seit meinen Änderungen gestern Abend spielt er jetzt noch 2 Sekunden, grr... > Blödes Teil, ich bin von dem Ding echt genervt. Manchmal wünschte ich, > man hätte es nie auf den Markt geworfen, dann könnte ich ruhiger > schlafen. Aber jetzt kann ich es einfach nicht mehr ignorieren, der > Preis ist zu verlockend :-) Volle Zustimmung. Es gibt etliche kleine Ungereimtheiten, die zumindest in der AT-Software eigentlich nicht auftreten sollten. Manche Infos sind auch im Espressif-Forum schwer zu finden, einige Sachen sind offenbar noch nicht endgültig im SDK behoben. Ich muß nachher erstmal mein Streaming reparieren... Gruß aus Berlin Michael
Merkwürdiges Java-Gebashe. Ich wette, jeder von den Schreihälsen läuft
mit mehreren Java-VMs und -Applikationen in seiner Brieftasche rum.
Die Java Card Variante von Java ist nämlich ein sehr weit verbreitetes
System für Smartcards, wie Bank- und Kreditkarten, Handy-SIMs, Secure
Elements usw.
> Weg mit dem Javadreck.
Ok, dann schmeiß für den Anfang bitte deine Kreditkarten, deine
Bankkarten und dein Handy auf die Straße.
Das Problem was der Fragesteller hat ist kein technisches, sondern ein
geschäftliches. Im Gegensatz zu Java SE sind gute embedded VMs nicht
kostenlos, und nur schwer als Privatmann zu bekommen.
Genau daran musste ich auch denken. Fast jede popelige Smartcard, NFC-Card usw. nutzt ne kleine JVM. und hier bashen die Leute auf java in embedded systems herum. Klar java mag nicht die Ideallösung sein, aber es definitiv kein NoGo, nur fuer den ESP8266 wird es wohl keine JVM/µJVM geben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.