Ich habe hier so ein Modul: http://www.amazon.de/ESP8266EX-herausgef%C3%BChrt-praktisches-einfachen-Breadboard-Gr%C3%BCn/dp/B00RD1M2HS Nun wäre es interessant herauszubekommen welche Grösse der Flash-Speicher hat, nur wie? Im espressif-Forum wurde auf diese Frage bislang nicht wirklich eingegangen, da hiess es jeweils nur man solle halt deren Flash-Tool nehmen und auf AutoSPI stellen, dann läuft alles automatisch. Das ist aber nicht hilfreich da die neueren Firmwares >1MB verlangen, und genau darum wäre es nett zu wissen wie gross der Speicher ist um überhaupt die richtige Firmware und natürlich auch die korrekten Speicheradressen zu wissen. Das Flashen ist bei den Dingern ja eine Wissenschaft für sich... Und hat jemand eine halbwegs aktuelle AT-Firmware bei der sich die Baudrate nicht nur verstellen sondern auch speichern lässt? Im dortigen Forum gibt es Beiträge dass die Einstellung nach RST wieder auf Default = 115200Bd steht...genau so auch bei meinem Modul. Es liegt ein wenig der Verdacht nahe dass auch hier die 'alten' 512k-Module betroffen sind, im Forum wirds vom Betreiber leider nur mit 'können wir hier nicht nachvollziehen' abgetan. Aktuell habe ich eine alte Version 9.2.2 von Ai-Thinker drauf, die ist aber zu instabil als dass es sich lohnt damit grossartig weiterzumachen. Danke!
Paul P. schrieb: > Nun wäre es interessant herauszubekommen welche Grösse der > Flash-Speicher hat, nur wie? Platine genau ansehen. Da ist ein 8-Beiner drauf. Das ist der Flash-Speicher. Typenbezeichnung in Internetsuchmaschine Deiner Wahl eingeben, Datenblatt studieren -- fertig. Betrachtet man Deinen Amazon-Link, findet man u.a. dieses Bild: http://ecx.images-amazon.com/images/I/711JyLX4sPL._SL1500_.jpg Das ist gut genug, um die Beschriftung lesen zu können: Winbond 25Q40BWN ... https://www.winbond.com/resource-files/w25q40bw%20revf%20101113.pdf Also 4 MBit, was 512 kByte sind.
Hallo, das Tool liest die Flashdaten und damit auch die Größe aus. Mit der AT-Software habe ich nicht viel gemacht, ich programmieren im Moment die ESP8266 lieber gleich aus der ArduinoIDE. Im Moment werden allgemein maximal 1MB genutzt, der Rest wird als Filesystem angelegt. Eine andere Aufteilung gibt es nur bei Firmware-Update per WLAN (FOTA), habe ich aber auch noch nicht mit rumgespielt. Gruß aus Berlin Michael
Ein 4 MByte Chip kostet 35 Cent beim freundlichen Chinesen. Ist vom Gehäuse etwas größer, aber bekommt man drauf.
> Winbond 25Q40BWN ... Also 4 MBit, was 512 kByte sind.
Ahh, alles klar, das hatte ich nicht geschnallt - danke!
Bliebe die Frage nach der AT-Firmware, mit Arduino habe ich nix am Hut.
Und LUA klingt zwar interessant, ich habe aber derzeit echt keinen Nerv
mich in noch eine Sprache einzulesen. Ich will nur ein paar Byte hin-
und herschubsen, da langt AT.
Paul P. schrieb: > Bliebe die Frage .. Ausgabe 6/15 http://www.heise.de/make/meldung/Make-Ausgabe-6-15-jetzt-im-heise-shop-bestellbar-3041402.html "In der Ausgabe 6/15 erfüllen wir auch einen häufig geäußerten Wunsch unserer Leser – wir haben uns intensiv mit dem ESP8266 beschäftigt, einem winzigen WLAN-Modul für fünf Euro, der jeden Mikrocontroller fit macht fürs Internet der Dinge. Der niedrige Preis geht allerdings auf Kosten der Einsteigerfreundlichkeit. Mit unserem ausführlichen Artikel zum ESP8266 ..." Na dann ..
Ich würde dir zur NodeMCU firmware raten. LUA hat man innerhalb von 1h verstanden und kann ein paar bytes rumjonglieren. Außerdem kann man einfach ein init script hochladen, dass beim systemstart die baudrate etc setzt. Frustfrei geht das ganze mit dem NodeMCU-Tool (über npm). Da kannst du die scripte einfach in den flash hochladen und brauchst nichts neu zu compilieren
Paul P. schrieb: > mit Arduino habe ich nix am Hut Dieser Aussage kann ich zustimmen, jedenfalls wenn es um avr und co geht. Beim Esp8266 sehe ich das aber anders. Der Arduino-Port ist nicht schlecht gemacht. Vor allem da man auf dem ESP kaum debuggen kann und selbst das kleinste User-Programm relativ lange zum Flashen braucht. Das macht den gesamten Workflow ziemlich träge. Jedenfalls im Vergleich zum Workflow bei einem Cortex Mx. Da die Anzahl von Pins am Esp sowieso beschränkt ist, werden sich die Projekte wohl auch ehr in Grenzen halten. Man muss ja nicht die Arduino-IDE benutzen und das mache ich auch nicht. Ich finde, man kann die Arduino-API auf dem ESP sehr gut nutzen und von der Arbeit der Leute dahinter partizipieren ohne sich irgendwas zu verbauen. Das ist bei NodeMCU anders. Da zieht mit LUA wieder eine neue Sprache ein, die erst mal gelernt werden muss, auch wenn sie nicht besonders schwer ist. Wenn dann aber etwas gebraucht wird was die LUA-Leute nicht vorgesehen haben, ist das Ende der Sackgasse erreicht.
temp schrieb: > [...] Der Arduino-Port ist nicht > schlecht gemacht. [...] Dies will ich nicht in Zweifel ziehen. > Ich finde, man kann die Arduino-API auf dem ESP sehr gut > nutzen und von der Arbeit der Leute dahinter partizipieren ohne sich > irgendwas zu verbauen. Wenn man mit der Arduinomilieu nichts am Hut hat und auch nie hatte, relativiert sich das aber. Und bei dem Folgenden muß ich widersprechen. > Das ist bei NodeMCU anders. Da zieht mit LUA > wieder eine neue Sprache ein, die erst mal gelernt werden muss, auch > wenn sie nicht besonders schwer ist. Wenn dann aber etwas gebraucht wird > was die LUA-Leute nicht vorgesehen haben, ist das Ende der Sackgasse > erreicht. Meine Erfahrung ist anders. Die NodeMCU-Firmware läßt sich ziemlich einfach erweitern. Ich kenne den ESP8266 erst seit ein paar Wochenenden, in denen ich die verschiedenen Möglichkeiten durchprobiert habe, die sich da bieten. Auch Lua kenne ich zwar im Prinzip von CHDK her (http://chdk.wikia.com/wiki/CHDK), hatte dort aber nie einen Grund, von dem früher verfügbaren µBasic zu Lua zu wechseln. Die Schwierigkeiten beim Gebrauch von CHDK liegen nicht in der Wahl der Programmiersprache, sondern in den unterschiedlichen Verhaltensweisen verschiedener Kameramodelle. Jedenfalls hat es mich nicht mehr als ein paar Stunden gekostet, IRMP in die vorhandene NodeMCU-Firmware als weiteres Modul einzubauen (Beitrag "Re: IRMP mit ESP8266"). Sofern man sich also den nicht unerheblichen RAM- und Flashverbrauch durch die Lua-Firmware leisten kann, erscheint mir das Modell, den Kern einer Anwendung in C als Lua-Modul zu schreiben, das Customizing aber wahlweise nachher in Lua implementieren zu können, nicht unattraktiv. Kannst Du evtl. ein paar Takte dazu schreiben, wie sich dies für jemanden darstellte, für den das Arduino-Biotop Neuland darstellt und der davon eigentlich auch nur gerade so viel erfahren will, wie für den Gebrauch des Ports auf den ESP8266 nötig ist? Welche Toolchain braucht man, welche Dokumentation muß man lesen?
e-d schrieb: > .. und weiter dann hier: > http://www.esp8266.com/viewforum.php?f=25 Vielen Dank, aber eine Suchmaschine bedienen kann ich selber. Ich hatte die Hoffnung, daß sich die gestellte Frage auch direkt beantworten ließe. Vielleicht sollte ich sie etwas spezifischer bzw. ausführlicher stellen. Mein Ansatz bei der Benutzung der NodeMCU-Firmware ist i.W. esp-open-sdk in einer VM installieren, d.h. einen Build mit dem bei GitHub gehosteten Build-Script durchführen - zeitaufwendig, aber nur ein mal nötig. NodeMCU-Firmware von GitHub holen, mit dem esp-open-sdk übersetzen und dann dem verfügbaren ESP-8266-Board testen. Ich verwende dafür das originale esptool.py. Lua-Modul schreiben, dazu eines der vorhandenen Module als Vorlage bzw. Ideenlieferant nehmen. Die Firmware erneut übersetzen, flashen, testen. Das in C geschriebene Lua-Modul wird so Bestandteil der neuen Firmware und steht in dort ablaufenden Lua-Scripts zusätzlich zur Verfügung. Es kann durchaus eine i.W. vollständige Anwendung darstellen, bei der Lua dann nur noch für Kosmetik verwendet wird, muß aber nicht. Die vorhanden Module sind, soweit ich das angeschaut habe, nur Treiber für div. Peripherie (Sensoren, LED-Streifen, ...). Man hat die Wahl. Wie sieht das bei Verwendung der Arduino-IDE aus, nachdem man das ESP8266-Plugin installiert hat? Wirft die dann ein komplett zusammengebundenes Binary aus? Welche Runtime-Komponenten enthält dieses? Offenbar ja eine Umsetzung des Arduino-API auf den Espressif-SDK (auch der esp-open-sdk ist ja i.W. auch nur ein Wrapper). Ist da aber noch mehr, mehr Funktionalität, eine Script-Sprache? Zusammengefasst, was brächte mir die Verwendung des Arduino-Ports in Vergleich zur Erweiterung der NodeMCU-Firmware, wenn ich nicht auf Vorkenntnisse des Arduino-Biotops zurückgreifen kann?
Wolfgang S. schrieb: > Kannst Du evtl. ein paar Takte dazu schreiben, wie sich dies für > jemanden darstellte, für den das Arduino-Biotop Neuland darstellt und > der davon eigentlich auch nur gerade so viel erfahren will, wie für den > Gebrauch des Ports auf den ESP8266 nötig ist? Welche Toolchain braucht > man, welche Dokumentation muß man lesen? Ich hatte das hier mal beschrieben wie man sich die Toolchain ohne Arduino-IDE zusammenbaut. Das was da mit esp8266-2.0.0-rc1 beschrieben ist kann man jetzt mit esp8266-2.0.0 ersetzen, die Zeit bleibt ja nicht stehen. Beitrag "Re: Bestes Tutorial für ESP8266" Die Arduino API ist zeimlich einfach gestrick, da spuckt die Suchmaschine deiner Wahl mehr aus als man je im Leben lesen will. Mir reichen dafür die Header. Wenn jemand von 0 anfängt kommt er mit LUA sicher weiter, aber darum geht es mir nicht. Meine Aussage zielt auf die, die sonst auch mit C/C++ auf Controllern zu Hause sind. Also die, die nicht das ESP-Sdk in allen Einzelheiten kennen lernen wollen, andererseits aber auch nicht noch eine neue Interpretersprache nur aus diesem Grund anfassen wollen. Es hat beides seine Berechtigung und jeder kann es nach seinem Bedarf einsetzen. Für den, dem die Hürden sich eine lauffähige Umgebung einzurichten schon zu hoch sind, ist der NodeMCU-Ansatz der bessere. Jedenfalls solange wie nicht mit einem guten JavaScript-Interpreter und der passenden Umgebung dazu NodeMCU links überholt wird.
Ein Lua-Modul kannst Du auch in Lua schreiben. Oder habe ich Dein Problem nicht richtig verstanden? Also, nodemcu Firmware laden und Lua-Skripte schreiben. Da muss nix kompiliert werden.
Hallo, ich habe da nicht in Details reingeschaut, will im Moment auch nicht so tief einsteigen. Die ArduinoIDE bindet das SDK ein ist ansonsten auch mehr ein Wrapper, der die Funktionalität des ESP abbildet. Vorteil ist für mich zur Zeit, daß ich vorhandene Bibliothen (meist mit wenigen Anpassungen) direkt nutzen kann. Ich habe nichtmal nachgeschaut, was im Hintergrund passiert. Flashen geht direkt nach dem compilieren automatisch bei NodeMCU bzw. nachdem man per Taster den ESP in den Flash-Mode gebracht hat. Über Sinn und Zweck von Arduinos wird genug diskutiert, AVR wird bei meist heute noch in ASM programmiert. Es sind kleine Projekte oder Spielereien und Arduino ist mir jetzt erst begegnet, weil es diverses Zubhör billig aus China gibt. Die kann man eben auch an die I/Os des ESP8266 stecken und so passte das für mich zusammen. Ich habe hier das ESP-SDK auch unter Eclipse drauf, ist aber für mich "alten" Herren wohl im Moment nicht die richtige Spielwiese. Gruß aus Berlin Michael
Wolfgang S. schrieb: > Zusammengefasst, was brächte mir die Verwendung des Arduino-Ports in > Vergleich zur Erweiterung der NodeMCU-Firmware, wenn ich nicht auf > Vorkenntnisse des Arduino-Biotops zurückgreifen kann? Kleines Beispiel. Ich hatte hier die Anforderung 8 Universen Artnet mit je 512 Byte zu verarbeiten und dann mit 4Mbit über die 2. Uart und einem Gpio-Pin zur Syncronisation an einen Cortex M zu übertragen. Das ganze mit 25Frames/s. Wäre das mit LUA gegangen ohne noch eine Zeile C zu schreiben? Mit der Arduino API und ohne jemals was mit Arduino gemacht zu haben waren dazu knapp 300 Zeilen Code nötig incl. Ringbuffer für die Artnet-Udp-Packete. Und vor allem in der Sprache in der ich zu Hause bin. Eine Scriptsprache für diese Anwendung wäre weder hilfreich noch sinnvoll.
Pete K. schrieb: > Ein Lua-Modul kannst Du auch in Lua schreiben. Oder habe ich Dein > Problem nicht richtig verstanden? > > Also, nodemcu Firmware laden und Lua-Skripte schreiben. Da muss nix > kompiliert werden. Das was Wolfgang da gemacht hat: Wolfgang S. schrieb: > Jedenfalls hat es mich nicht mehr als ein paar Stunden gekostet, IRMP in > die vorhandene NodeMCU-Firmware als weiteres Modul einzubauen > (Beitrag "Re: IRMP mit ESP8266"). würde als Lua-Modul in Lua geschrieben entweder an Timing Problemen komplett scheitern oder ein Man-Jahre langes Unterfangen werden. Da müsste in Lua erst mal alles das nachgeholt werden, was die Leute hinter IRMP schon geleistet haben.
Wolfgang S. schrieb: > Zusammengefasst, was brächte mir die Verwendung des Arduino-Ports in > Vergleich zur Erweiterung der NodeMCU-Firmware, wenn ich nicht auf > Vorkenntnisse des Arduino-Biotops zurückgreifen kann? Zwei Erkenntnisse: - ein "leerer" *.ino - sketch benötigt für die Routinen bereits 45% des Programmspeichers (gen.ESP) und 39% RAM; - du brauchst keinen (immer auch zeitkostenden) Interpreter (LUA,BASIC,Forth,Javascript uva. ); - und nochmals, falls du es übersehen hast: http://www.esp8266.com/index.php?sid=5e0a3582a39e95df2aeb585913f5a88d Mit dem Arduino-Biotop kommst du garnicht in Berührung, wenn du es nicht willst.
Hallo, ein Mini-Webserver mit diversen längeren Texten und Buttons belegt 53% des Programmspeichers (gen.ESP) und 56% Ram. Sind für die reine Anwendung also 8% für Programm und 17% Ram oder anders rund 40kB Flash von rund 240kB und 13kB Ram von rund 49kB werden von meinem Programm belegt. Bleibt mir also noch recht viel Luft... Gruß aus Berlin Michael
Hallo, Michael U. (amiga) ! Ich bin schon an die Grenzen gestossen: http://www.esp8266.com/viewtopic.php?p=32054#p32054 Mal sehen, ob der ESP32 Abhilfe schafft. Ansonsten müsste ich mich in SPIFFS einarbeiten ..
temp schrieb: > Pete K. schrieb: >> Ein Lua-Modul kannst Du auch in Lua schreiben. Oder habe ich Dein >> Problem nicht richtig verstanden? >> >> Also, nodemcu Firmware laden und Lua-Skripte schreiben. Da muss nix >> kompiliert werden. > > Das was Wolfgang da gemacht hat: > > Wolfgang S. schrieb: >> Jedenfalls hat es mich nicht mehr als ein paar Stunden gekostet, IRMP in >> die vorhandene NodeMCU-Firmware als weiteres Modul einzubauen >> (Beitrag "Re: IRMP mit ESP8266"). > > würde als Lua-Modul in Lua geschrieben entweder an Timing Problemen > komplett scheitern oder ein Man-Jahre langes Unterfangen werden. Da > müsste in Lua erst mal alles das nachgeholt werden, was die Leute hinter > IRMP schon geleistet haben. Ja richtig. Ich bezweifele, daß sich IRMP in der vorhandenen Lua-Implementation der NodeMCU als pures Lua-Modul reimplementieren ließe. Selbst in purem C geht das, wie beschrieben, nicht auf direktem Wege, da im verwendeten SDK (dem letzlich von Espressif übernommenen Bestandteil) nur ein ms-Timer zur Verfügung steht. Das reicht nicht. Was ich gemacht habe (und unter Weglassen der mehr oder weniger unveränderten IRMP-Bestandteile, der eher trivialen queue und des Lua-Modul-Boilerplate nachfolgend zeige) ist, aus einer in der Pinchange-Interruptroutine gefüllten Queue nachträglich die irmp_ISR-Aufrufe zu generieren. Es wäre möglich, den C-Teil bis auf das Füllen der Queue (also die hier nicht gezeigte Interruptroutine) abzuspecken und den Rest langsam und in Lua zu implementieren. Aber warum sollte man? So ist es kompakter und schneller.
1 | /-------------------------------------------------------------------------
|
2 | // Lua: int = irmp.init( int queuesize)
|
3 | static int irmp_lapi_init( lua_State *L ) |
4 | {
|
5 | uint32_t i; |
6 | int queuesize = luaL_checkinteger( L, 1 ); |
7 | |
8 | // initialize a queue
|
9 | if (queuesize<50 || queuesize> 1000) queuesize=200; |
10 | queue.front=0; |
11 | queue.count=0; |
12 | queue.objs=(qobject_t*) malloc(queuesize * sizeof(qobject_t)); |
13 | queue.size=queuesize; // enable queue |
14 | |
15 | for (i=0;i<queue.size;i++) queue.objs[i]=0; |
16 | os_memset( irmp_data,0,sizeof irmp_data); |
17 | irmp_init(); |
18 | gpioinit(); |
19 | |
20 | lua_pushinteger( L, 1 ); |
21 | return 1; |
22 | }
|
23 | |
24 | //-----------------------------------------------------------------
|
25 | // Lua: int = irmp.close( )
|
26 | static int irmp_lapi_close( lua_State *L ) |
27 | {
|
28 | queue.size=0; // disable queue |
29 | if (queue.objs) os_free(queue.objs); |
30 | queue.objs=0; |
31 | return 0; |
32 | }
|
33 | //-----------------------------------------------------------------
|
34 | |
35 | // Lua: 0 or prot,addr,cmd,flags= irmp.get_data( )
|
36 | static int irmp_lapi_get_data( lua_State *L ) |
37 | {
|
38 | int rc ; |
39 | uint32_t i,j; |
40 | int32_t pulse; |
41 | uint32_t ticktime=0; |
42 | uint32_t irmptime=0; |
43 | |
44 | if (queue.objs == 0) |
45 | {
|
46 | lua_pushinteger(L, -1); // closed |
47 | return 1; |
48 | }
|
49 | |
50 | while (pulse = q_remove(&queue)) |
51 | {
|
52 | if (pulse > 0) |
53 | {
|
54 | irmpbit=1; |
55 | }
|
56 | else
|
57 | {
|
58 | irmpbit=0; |
59 | pulse = -pulse; |
60 | }
|
61 | |
62 | if (pulse>100000) pulse=100000; // 0.1 s max |
63 | |
64 | irmptime += pulse; |
65 | |
66 | while (ticktime < irmptime) |
67 | {
|
68 | (void) irmp_ISR(); |
69 | ticktime += (1000000/ F_INTERRUPTS); |
70 | }
|
71 | rc = irmp_get_data (&irmp_data); |
72 | if (rc) |
73 | {
|
74 | lua_pushstring( L, irmp_protocol_names[irmp_data.protocol]); |
75 | lua_pushinteger( L, irmp_data.protocol); |
76 | lua_pushinteger( L, irmp_data.address); |
77 | lua_pushinteger( L, irmp_data.command); |
78 | lua_pushinteger( L, irmp_data.flags); |
79 | return 5; |
80 | }
|
81 | } // while |
82 | lua_pushinteger( L, 0 ); |
83 | return 1; |
84 | }
|
temp schrieb: > Wolfgang S. schrieb: >> Zusammengefasst, was brächte mir die Verwendung des Arduino-Ports in >> Vergleich zur Erweiterung der NodeMCU-Firmware, wenn ich nicht auf >> Vorkenntnisse des Arduino-Biotops zurückgreifen kann? > > Kleines Beispiel. Ich hatte hier die Anforderung 8 Universen Artnet mit > je 512 Byte zu verarbeiten und dann mit 4Mbit über die 2. Uart und einem > Gpio-Pin zur Syncronisation an einen Cortex M zu übertragen. Das ganze > mit 25Frames/s. Wäre das mit LUA gegangen ohne noch eine Zeile C zu > schreiben? Mit der Arduino API und ohne jemals was mit Arduino gemacht > zu haben waren dazu knapp 300 Zeilen Code nötig incl. Ringbuffer für die > Artnet-Udp-Packete. Und vor allem in der Sprache in der ich zu Hause > bin. Eine Scriptsprache für diese Anwendung wäre weder hilfreich noch > sinnvoll. Ok. Würde ich auch machen, wenn ich das Arduino-API kennte. Tue ich aber nicht und sehe aktuell den Benefit nicht, sich dort einzuarbeiten. Ein analoges, sicherlich simpleres Problem (nur eine private Fingerübung zur eigenen Belustigung), nämlich einen IR-Spy auf Basis von IRMP zu bauen und den Output parallel via Webserver anzubieten und per UDP zu verschicken, habe ich ziemlich unspektakulär mit dem IOT-SDK von Espressif realisiert, ohne dafür noch irgend welche anderen Frameworks, IDEs oder APIs zu benötigen, siehe Beitrag "Re: IRMP mit ESP8266" Mal anderes gefragt, was geht mit dem Arduino-Port, was mit einem der Espressif-SDKs nicht geht oder schlechter geht? Wo ist der Benefit, wenn man nicht von "ich kenn' das Arduino-API schon" ausgehen kann? Ich habe im Moment fallweise die Wahl zwischen zwei Varianten a) Espressif-SDK und b) Erweiterung der NodeMCU-Firmware durch in C via Lua-C-API realisierte Module, die jeweils ihre spezifischen Vorzüge haben, bei a die Abwesenheit weiterer Abhängigkeiten, bei b die Möglichkeit, im fertigen Ergebnis eine Scriptierungsmöglichkeit zu haben. Welchen zusätzlichen (!) Vorteil brächte der Arduino-Port? Ich frage das ohne Hintergedanken, ich will den evtl. Benefit nicht abstreiten, sondern scheue einfach nur den Aufwand, das selber herauszufinden.
Hallo, es wird wohl von den Vorhaben abhängen... Mein 1,8" SPI-Display an den ESP zu hängen geht sicher auch ohne ArduinoIDE, nur dort war die spielende Lib schon da. Für den ESP habe ich auf die Schnelle nur eine OLED 0,96" Lib gefunden, das hatte ich aber nicht. Ich kann auch eine Grafik-Lib für ein Display selber schreiben, der Aufwand wäre mir da aber definitiv zu hoch im Verhältnis zum Nutzen bei einer "Spielerei". Ich bin über Arduino auch erst jetzt durch die billigen China-Sachen gestolpert, AVR 8Bit mache ich seit den Anfängen, Z80 und 6502 gab es davor. Man kann den Arduionokram auch in einer anderen IDE benutzen, für größere Sachen halte ich die ArduionoIDE für ziemlich ..naja.. unbrauchbar. Gruß aus Berlin Michael
Michael U. schrieb: > für > größere Sachen halte ich die ArduionoIDE für ziemlich ..naja.. > unbrauchbar. Ich wollte mit STM32F407 und der Arduino-IDE in Verbindung mit dem ESP8266 über OTA ein Projekt erstellen. Das E407-Board von Olimex lag hier noch rum. Erfolgreich war aber nur die Pgr. für STM32F103Z. Schwierigkeiten mit Bootloader! Wolfgang S. schrieb: > Ich > habe im Moment fallweise die Wahl zwischen zwei Varianten a) > Espressif-SDK und b) Erweiterung der NodeMCU-Firmware durch in C via > Lua-C-API realisierte Module, die jeweils ihre spezifischen Vorzüge > haben, bei a die Abwesenheit weiterer Abhängigkeiten, bei b die > Möglichkeit, im fertigen Ergebnis eine Scriptierungsmöglichkeit zu > haben. Welchen zusätzlichen (!) Vorteil brächte der Arduino-Port? Du hast schon 2 gute Lösungen, wozu eine Dritte? Es sei denn wegen der grösseren Beliebtheit in der Community.
Wolfgang S. schrieb: > Mal anderes gefragt, was geht mit dem Arduino-Port, was mit einem der > Espressif-SDKs nicht geht oder schlechter geht? Wo ist der Benefit, > wenn man nicht von "ich kenn' das Arduino-API schon" ausgehen kann? Für den der das Espressif-SDKs kennt nichts, und für dich gibt es keinen Benefit. Du sollst ja auch nicht bekehrt werden... Ich kannte beides nicht. Arduino ist aber extrem simpel, das braucht man nicht erst ewig und 3 Tage zu lernen wie viele andere Sachen. Anders als das Espressif-SDKs. Arduino Codeschnippsel laufen einem ständig irgendwo beim Suchen über den Weg, dem kann man gar nicht ausweichen. Ich habe auch keine Lust mich in das Espessif Sdk einzuarbeiten, dafür arbeite ich mit dem Teil zu wenig. Diese Entscheidung würde eventuell anders ausfallen wenn ich mehr damit machen wollte oder müsste. Für den der das SDK kennt wie dich macht es natürlich keinen Sinn. ich will es dir ja auch nicht wie Sauerbier anbieten. Aber Lua war für mich eben keine Alternative. Und Scripten an dieser Stelle will und brauch ich nicht. Wie schon geschrieben, die IDE von Arduino will ich nicht mal beurteilen, die habe ich nie ernsthaft ausprobiert. Einen Punkt gibt es aber noch. Die extreme Einfachheit der Arduino-Api lässt einem sicher viel weniger Fehler machen als mit dem Esp-Sdk. Und bei dem schnarchlangsamen Workflow und den fehlenden Debugmöglichkeiten empfinde ich das als Vorteil.
e-d schrieb: > Schwierigkeiten mit Bootloader! siehe auch: http://www.stm32duino.com/viewtopic.php?f=32&t=413
Michael U. schrieb: > Mein 1,8" SPI-Display an den ESP zu hängen geht sicher auch ohne > ArduinoIDE, nur dort war die spielende Lib schon da. Für den ESP habe > ich auf die Schnelle nur eine OLED 0,96" Lib gefunden, das hatte ich > aber nicht. Ok, das könnte ein Grund sein, den Arduino-Port zu nehmen. temp schrieb: > Wolfgang S. schrieb: >> Mal anderes gefragt, was geht mit dem Arduino-Port, was mit einem der >> Espressif-SDKs nicht geht oder schlechter geht? Wo ist der Benefit, >> wenn man nicht von "ich kenn' das Arduino-API schon" ausgehen kann? > > Für den der das Espressif-SDKs kennt nichts, und für dich gibt es keinen > Benefit. Du sollst ja auch nicht bekehrt werden... und > Die extreme Einfachheit der Arduino-Api lässt einem sicher > viel weniger Fehler machen als mit dem Esp-Sdk. Einfachheit ist durchaus ein Gesichtspunkt. Allerdings wird man vermutlich auch hier erst mal ein Gefühl für die sicherlich vorhandenen Einschränkungen bekommen müssen. e-d schrieb: > Du hast schon 2 gute Lösungen, wozu eine Dritte? Spieltrieb. Der Wunsch, einen gewissen Überblick über die möglichen Entwicklungsvarianten zu bekommen, die sich da bieten, soweit sich diese in relevanter Weise unterscheiden. Bloße Umsetzung in ein nicht geläufiges API ist weder unterhaltsam noch nützlich. Klar, das ist rein subjektiv. > Es sei denn wegen der grösseren Beliebtheit in der Community. Das Kriterium verstehe ich schon, es ist aber im Moment nicht mein Kriterium. Danke für alle Antworten, das war durchaus hilfreich, vielleicht ja sogar für den OP. Jedenfalls passt es zum ziemlich generischen Thread-Titel. :-)
Hallo, meine Erfahrung: die Arduino-Community schwimmt größtenteils an der Oberfläche, ist ja auch Sinn des Arduino. Es ist aber nicht verboten, tiefer zu tauchen, ist ja letztlich auch nur C/C++. Es gibt kaum schnell auffindbare Informationen, was eine Lib so treibt, wenn man nicht in der Lage ist, selbst in die Sourcen zu scheun ude diese zu verstehen. Welche Libs welche Timer oder sonstigen Sonderfunktionen des AVR nutzen und sich so gern ins Gehege kommen, muß man meist selbst rausfinden und korrigieren. Das stört mich aber weniger, es ist einfach weniger Aufwand das gespiegelte Bild meines China-Displays in der init-Routine der Lib geradezurücken als alles selber zu schreiben. Datenblätter kann ich lesen, Programmieren kann ich (in C/C++ eher nur wenig), es soll mich nur zu meinem Ziel führen und das macht es mit vergleichsweise wenig Zeitaufwand. Gruß aus Berlin Michael
Angehängte Dateien:
-
esp_ram.jpg
20 KB
Sorry für meine späte Rückmeldung, hatte da in kleines Problemchen mit meinem Account... Ausserdem traue ich mich mit meinen trivialen Problemchen ja schon gar nicht mehr in diesen Thread zurück ;-). NodeMCU/Lua hat mich nun doch neugierig gemacht, also habe ich es nach dieser Anleitung http://www.allaboutcircuits.com/projects/how-to-make-an-interactive-tcp-server-nodemcu-on-the-esp8266/ mal geflasht. Dort wird in einem Screenshot nach dem Flashvorgang ein freier Speicher von ~3.5MB angezeigt, klingt bei 4MB gesamt ja schlüssig. Bei mir sieht das aber wie im Anhang aus, ein bisschen dürftig...und entsprechend schon nach ein paar Scriptzeilen die Meldung "Speicher voll". Mehrfach probiert, immer das gleiche - eine Idee was ich falsch mache?
Nachtrag: Ich sehe übrigens auch gerade dass meine Version älter ist (0.9.5 Build 20150318) obwohl ich sie ganz frisch bei Github runtergeladen habe https://github.com/nodemcu/nodemcu-flasher/blob/master/Win32/Release/ESP8266Flasher.exe Ist da eine Version wieder zurückgezogen worden?
Bin schon länger weg von Lua, aber dieses Problem ist bekannt: This processing is a mature part of the Lua 5.x runtime system, and for normal Lua applications development this “behind-the-scenes” magic ensures that upvalues just work as any programmer might expect. Sufficient garbage collector metadata is also stored so that these hidden values will be garbage collected correctly when properly dereferenced. However allocating these internal structures is quite expensive in terms of memory, and this hidden overhead is hard to track or to understand. If you are developing a Lua application for a PC where the working RAM for an application is measured in MB, then this isn't really an issue. However, if you are developing an application for the ESP8266 where you might have 20 KB for your program and data, this could prove a killer. - ist aus: http://www.esp8266.com/wiki/doku.php?id=nodemcu-unofficial-faq&s[]=lua&s[]=not&s[]=enough&s[]=memory Lies es (oder lass es übersetzen), dort sind auch Hinweise zu finden ..
Erstmal Asche auf mein Haupt, mein Link war nicht ganz korrekt bzw. vollständig. Das Flashen habe ich so vorgenommen: http://randomnerdtutorials.com/esp8266-web-server/ Der Windows-Flasher beinhaltet ja schon ein 'werksseitiges' NodeMCU-Bin welches gebrannt wird, wenn man die Einstellungen nicht explizit ändert. Aus dem anderen Link hatte ich nur die Routine zum Formatieren und zur Ausgabe der Speichergrösse verwendet. Und da meldet das Teil eben nur die ~64kB, direkt nach dem Flashen ohne dass auch nur eine einzige Scriptzeile drauf wäre. Meine Mini-Testscripte init.lua (9 Zeilen) und main.lua (129 Zeilen inkl. ettlicher Leerzeilen) haben im Windoof-Explorer gerade mal 5kB, und da kommt schon die Meldung zuwenig Speicher - da ist doch was faul? Dein Link ist sicher interessant, ich verstehe aber leider nur Bahnhof und leider nicht den Zusammenhang zu meinem Problem?
Paul P. schrieb: > NodeMCU/Lua hat mich nun doch neugierig gemacht, also habe ich es nach > dieser Anleitung > http://www.allaboutcircuits.com/projects/how-to-make-an-interactive-tcp-server-nodemcu-on-the-esp8266/ > mal geflasht. > Dort wird in einem Screenshot nach dem Flashvorgang ein freier Speicher > von ~3.5MB angezeigt, klingt bei 4MB gesamt ja schlüssig. Ja. > Bei mir sieht das aber wie im Anhang aus, ein bisschen dürftig...und > entsprechend schon nach ein paar Scriptzeilen die Meldung "Speicher > voll". > Mehrfach probiert, immer das gleiche - eine Idee was ich falsch mache? Nichts, außer ein Board gekauft zu haben, das nur mit 512 K Flash bestückt ist. Wenn ich http://ecx.images-amazon.com/images/I/71dcVOlQO5L._SL1500_.jpg um 180 Grad drehe, kann ich da "Winbond W25Q40BW" lesen. Und das ist lt. https://www.winbond.com/resource-files/w25q40bw%20revf%20101113.pdf ein 4M-Bit-Flashbaustein. Vier Megabit, 512KByte, ist die Minimalbestückung für ESP8266-Boards. Was ich mir als NodeMCU-Image zusammencompiliert habe, braucht schon mehr Platz, jedenfalls kommt bei meinem mit 2 MByte bestückten Olimex-Board bei leerem Filesystem 1468601 0 1468601 heraus, also gut 1,4 MB vorhanden, 0 benutzt. Was Du da benutzt hast, ist offenbar für die Minimalbestückung übersetzt, läßt aber nicht mehr viel Platz im Flash. Du kannst also die div. Abspecktipps lesen und anzuwenden versuchen, oder ein anderes Board mit mehr Flash kaufen. Das Olimex-Board wird z.Zt. bei Amazon zu Mondpreisen angeboten, Olimex selber bietet es für 5,50 EUR an. https://www.olimex.com/Products/IoT/MOD-WIFI-ESP8266-DEV/open-source-hardware. Ich selber habe ein ESP8266-EVB, mit dem ich recht zufrieden bin. Antratek bietet das zu m.E. realisischen Preisen an. https://www.antratek.de/esp8266-evb. Ich weiß allerdings nichts über die Firma.
Paul P. schrieb: > Der Windows-Flasher beinhaltet ja schon ein 'werksseitiges' NodeMCU-Bin > welches gebrannt wird, wenn man die Einstellungen nicht explizit ändert. > Aus dem anderen Link hatte ich nur die Routine zum Formatieren und zur > Ausgabe der Speichergrösse verwendet. > Und da meldet das Teil eben nur die ~64kB, direkt nach dem Flashen ohne > dass auch nur eine einzige Scriptzeile drauf wäre. > Meine Mini-Testscripte init.lua (9 Zeilen) und main.lua (129 Zeilen > inkl. ettlicher Leerzeilen) haben im Windoof-Explorer gerade mal 5kB, > und da kommt schon die Meldung zuwenig Speicher - da ist doch was faul? > > Dein Link ist sicher interessant, ich verstehe aber leider nur Bahnhof > und leider nicht den Zusammenhang zu meinem Problem? 1. wichtig: aktuelles NodeMCU bin verwenden. Beispielsweise gibt es auf github von NodeMCU einen Link zum online Bin generieren. Da wählst du alle für dich notwendigen Libs aus und flashst auf den ESP8266. Alte Firmware (z.B. von Februar) ist teilweise ziemlich buggy. 2. 64 kByte haut nicht hin. Das ist eher die Größe vom RAM. Der Flash ist in Größenordnungen von 512 kByte. 3. es empfiehlt sich, größere Scripte von der Nutzung zu compilieren. Dann haben sie die Endung .lc Durch Compilieren benötigen sie weniger RAM. Wenn der RAM dann doch mal nicht ausreicht (war aber eher bei alter buggy Firmware so): nach Flashen und compilieren Neustart machen und dann das .lc File ausführen.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.