EDV-Dompteur/Forum

Zitat von »Bastelfreund«

Was gibt es so für Möglichkeiten/Bootloader in der AVR Welt? Hast du da auch schon ein Remote-Flashing umgesetzt?

Weiß nicht, ob ich die Frage richtig verstehe.
AVR kann entweder jedes Mal per Programmiergerät geflasht werden (was auf die Dauer lästig wäre), oder per Bootloader.

Das sieht dann so aus, dass man einmalig per Programmiergerät einen der zahlreich verfügbaren Bootloader in einen dafür reservierten, kleinen Speicherbereich des Flash-ROMs brutzelt. Wir reden da über 512 Byte, oder 1024 Byte, oder (ganz fette Loader-Routinen) 2048 Byte.
Fortan kann der AVR z. B. über den seriellen Port programmiert werden.
Oder auch über prinzipiell jeden anderen I/O. Aber meistens nimmt man den normalen, seriellen Port.

Ich verwende gerne einen Bootloader, der auf Dezimal 127 am UART lauscht. Kommt dieses Byte dort an, so geht der Baustein in den Programmiermodus und alle weiteren Bytes, die seriell eintrudeln, werden als Programmcode interpretiert, der im Flash abgelegt wird.
Das kann man natürlich nur dann machen, wenn man im Normalbetrieb keine Binärdateien zum UART des AVR schicken will, in denen zufällig dezimal 127 vorkommen könnte.
Aber das funzt wunderbar, wenn der AVR ohnehin nur Textdateien erwartet, am RXD.

Es gibt auch Binärfile-taugliche Bootloader. Aber die erfordern dann halt noch einen zusätzlichen Input, oder das Drücken der Reset-Taste, um den Baustein in den Programmiermodus zu versetzen.

Wenn man an die seirelle Schnitte z. B. einen Infrarotempfänger hängt (oder den ESP, mit AT-Kommandos) und die Schaltung irgendwo unzugänglich verbaut, dann ist es natürlich komfortabler, wenn man einfach nur ein bestimmtes Byte über die sowieso vorhandene, dreiadrige, serielle Strippe senden muss (ohne weitere Aktionen), um sogleich mit dem seriellen Flashen loslegen zu können.

Beim Programmupdate auf diesem Wege wird jedenfalls das neue Programm wie in ein langes Schieberegister hinein geschoben. Es wird also nicht etwa am Ende des bestehenden Programmes abgelegt, sondern der alte Programmcode wird tatsächlich voll ersetzt (bis auf den Bootloader!). Dabei spielt es keine Rolle, ob der neue Programmcode kürzer, oder länger ist, als der alte.

So soll es sein, damit es gut ist und so ist es auch!
Und genau das würde ich mir auch beim ESP wünschen.


Die AVRs sind jedenfalls kleine Wunderdinger! Es ist immer wieder faszinierend, was für Kunststücke man mit derart begrenzten Ressourcen realisieren kann! Dabei programmiere ich verschwenderisch in Basic!

Im Ledstyles-Forum ist so ein Assembler-Guru unterwegs. Der hat mal den Spruch gebracht, dass das Timing der WS28XX doch gar nicht so schlimm ist, denn es lässt dem AVR an der zeitkritischsten Stelle ja "satte" 20 Takte und in 20 Takten könne man eine ganze Menge machen ...
- Da war ich baff!
Aber der Mann ist nicht etwa bloß ein Großmaul, sondern der weiß, wovon er spricht. Der hat schon richtig viele und heftige Projekte realisiert, mit AVR und WS28XX.
Mit meinem Basic würde ich in 20 Takten so ziemlich gar nichts gebacken bekommen.

Immerhin bietet mein Bascom (so heißt der Basic-Dialekt) aber die Möglichkeit, Assembler-Schnippsel einzufügen und gaaanz selten habe ich das auch schon gemacht, wenn mal hart optimiert werden musste.
Das ist eine angenehme Kombination. Der Großteil des Programmes wird dann komfortabel in Basic programmiert und nur an den wirklich kritischen Stellen optimiert man gegebenenfalls, in Form ganz weniger Zeilen Assembler-Code. Ist aber wirklich nur hochgradig selten erforderlich.
Und das bei meistens 8, oder 16 MHz Taktfrequenz.

Der ESP, mit seinen 80 MHz, gibt da schon ganz anders Gas! Und mehr noch: Er soll ja ein 32-Bit-Controller sein! AVR ist dagegen nur ein 8-Bitter.

Ich habe für einen LED-Farbwechsler (so ein Mood-Light) mal eine Farbschema-Konvertierung von HSV nach RGB programmiert. Da kommen reichlich Fließkommaberechnungen vor. Also da kommt ein AVR aber wirklich schwer ins Schwitzen! Und da freue ich mich wie blöd, über die reichlich mehr Rechenpower dieses unscheinbaren, kleinen ESP-Moduls!

Ich bin bei meiner Recherche ja schon auf allerhand widersprüchliche Informationen gestoßen.
Der Autor dieses russischsprachigen Beitrags ebenfalls:

http://esp8266.ru/esp8266-podkluchenie-o…arduino-connect

Und er erwähnt, dass er für den Beitrag die realen Erfahrungen der dortigen Forenuser zusammengetragen hat, um mal Ordnung ins Chaos zu bringen.

Man scrolle dort etwas herunter und beachte die beiden Schaltpläne in der Mitte. Dort ist zuerst der Standardweg gezeigt, wie man den ESP per Taster in den Programmiermodus versetzt und dann die Software einspielt.
Im zweiten Schaltbild dagegen, wird die sonst übliche Tasterdrückerei wegrationalisiert, durch Verwendung der Signale RTS und DTR vom seriellen Adapter.
Das ist schon deutlich eleganter!

Was ich noch wahnsinnig elegant fände, das wäre der komplette Verzicht auf einen USB-Seriell-Wandler.
Prinzipiell geht USB nämlich auch in Software. Wäre aber zweifellos ein ziemlicher Akt, das zu entwickeln. Doch ich kann mir vorstellen, das jemand bereits eine passene Lib geschrieben hat. Für die Erstprogrammierung bräuchte man aber natürlich weiterhin 'nen Adapter, das ist klar.

(Hoffentlich kommt mein Witty bald; will endlich loslegen!)

Zitat von »Bastelfreund«

Nur ist mir nicht ganz klar wie das mit RTS und DTR beim ESP funktioniert, da ja (laut Wikipedia ) jeweils ein "High Pegel" zur jeweiligen Aufforderung gesendet wird, der ESP für "Reset" und "Programming" aber auf GND gezogen werden muss .

Boah, ich glaub' Du hast Recht!
Ich habe diese beiden Signale noch nie verwendet, bin immer mit TXD und RXD ausgekommen.
So auf Anhieb würde ich sagen, dass das ein Fehler sein muss, auf der russischen Website. Aber der Autor erwähnt ja andererseits, dass er selbst schon allerhand widersprüchliche Aussagen gesichtet hat und er behauptet, dass er dort nur bewährtes Wissen zusammengetragen hätte ...

Das sind immer so diese 1000 fiesen Details, mit denen man sich als Entwickler herumschlagen muss, und die die meiste Zeit fressen.

Übringens: Ich müsste jetzt selbst nachschauen, ob die LED an TXD in Deiner Schaltung wirklich richtig beschaltet ist. Weil TXD doch im inaktiven Zustand high ist und erst beim Senden pulsweise low wird. Aber Du schriebst mal, es wäre auf Board Soundso genau so gemacht ...
Also die LED soll ja nur bei Datentransfer flackern, sonst aus sein.

Vermutung on (im FT232-Datenblatt fand ich "auf die Schnelle" gerade nichts dazu, aaaaber): Wahrscheinlich kann man die Polarität der Signale konfigurieren.

Zitat von »Bastelfreund«

Meinst du damit im Prinzip die Bausteinfunktionalität wie z.B. vom FTDI direkt in SW umzusetzen und von der USB-Buchse direkt auf den uC zu gehen?

Ja, das meine ich.
Es gibt so einen Low-Speed-Mode bei USB. Den könnte man rein in Software schaffen, denke ich mal (ohne mich da bereits hineinvertieft zu haben).

USB ist noch relativ easy, wenn man bereit ist, sich mit einem virtuellen COM-Port zu begnügen.
Für den Eigenbedarf reicht das, aber realen Kunden kann man das nicht zumuten.
DAUs brauchen Plu&Play, mit automatischer Geräteerkennung. Aber das zu implementieren ist schon wieder eine ganz andere Schuhnummer.

Ich habe mal vor Jahren mehrere USB-IDs gekauft, zum Schnäpperlepreis, für eventuelle spätere Verwendung in eigenen Geräten. Ich kann die nur nicht mehr finden und weiß auch nicht mehr, wo ich die gekauft hatte ...
Bislang habe ich daher immer nur den FTDI-Chip genommen, mit Einrichtung eines virtuellen COM-Ports.

Zitat von »Bastelfreund«

Ach stimmt, da war ja was mit den USB Vendor IDs. Das ist aber nur dann wichtig wenn ich ein Produkt verkaufe oder? Ansonsten ist mir das im privaten als Bastler ja ziemlich egal da schnapp ich mir einfach eine ID. Oder gibt es diesbezüglich noch andere Gründe?

Nö, eigentlich nur bei Geräten wichtig, die man auf andere Menschen los lässt.

Elegant ist es, wenn sich ein USB-Gerät (was auch immer es tatsächlich ist) zunächst als kleiner USB-Stick anmeldet, woraufhin das Installationsprogramm für den Treiber des eigentlichen Gerätes per Autostart sein Ding tut.

Beispiel: Das Gerät sei eine Lichtsteuerung mit WS28XX. Einstecken - dingdong - neues USB-Gerät erkannt: USB-Stick ... Autostart des Treibers, anschließend Auswurf des "USB-Sticks" ... nun wird die Lichtsteurung am USB-Port erkannt.
So erpart man Kunden das Herumhantieren mit Installations-CDs.

Wenn ich meinen Kunden ein Gerät überlasse, dann möchte ich auch gerne sagen können, dass ich für eventuelle Software-Updates nicht etwa mit 'nem Programmiergerät persönlich anrücken muss, sondern dass ich einfach eine neuere Version z. B. per E-Mail zusende.
Wenn das 10 Monate später tatsächlich vorkommt, dann hat der Kunde eine Treiber-CD bis dahin ohnehin schon längst verschlampt.
Das manuelle Einrichten eines virtuellen COM-Ports kann man Otto Normaldau, oder Tante Erna, sowieso nicht zumuten.

- Öh, bislang bin ich aber noch jedes Mal mit dem Programmiergerät hin ...
Aber das soll ja mal besser werden.
Von dem ESP verspreche ich mir so manche Erleichterung und warte wirklich sehnsüchtig auf die Lieferung aus China.

Hubi hat das hier ausgebuddelt:
https://github.com/jeelabs/esp-link

Er wollte, vom WLAN seines Rechers aus, drahtlos mit einem einzelnen ESP kommunizieren.
Also ohne Verwendung eines zweiten ESP, samt FT232, am PC.

Dabei sollte sich der entfernte ESP wie eine COM-Schnittstelle am PC verhalten. Sich also genau wie ein FT232 am PC als virtueller COM-Port zeigen.
Nach einiger Recherche fand er den obigen Link, wo eine mundfertige Firmware existiert.

Das Leckerlie dieser Lösung ist die Möglichkeit, AVR-Controller, oder auch andere ESP-Module, nun drahtlos flashen zu können, also auch für die Erstprogrammierung!

Großartiger Tipp - vielen Dank an Hubi, für diesen guten Hinweis!

Hubert hat noch was ausgebuddelt. Abgefahren!

Color TV Broadcasts are ESP8266’s Newest Trick

Die interessante Information, die dabei so nebenbei abfällt, ist dass der ESP seinen I2C-Port mit 80 HMz per DMA füttern kann!
Das ist ein echter Bringer, auch bei so zeitkritischen Sachen, wie der Ansteuerung von WS28XX LED-Dots, wo man per Bit-Banging zu kaum was anderem kommen könnte. Uff, und genau dazu hat der selbe Mann auch schon was gerissen und bereits ein Video mit sehr guten Erklärungen gemacht:

Using I2S on the ESP8266 to drive WS2812Bs

Für andere Verzweifelte, die genau wie ich am ESPlorer zunächst mal scheiterten, hier meine Lösung, nach stundenlangem Kampf ...

Ob es wirklich notwendig war, kann ich im Nachhinein nicht sagen (ich zweifle sogar daran), aber im Web hieß es, man müsse zuerst die NodeMCU-Firmware in den ESP8266 flashen, bevor man man mit dem ESPlorer auf das Modul zugreifen kann.

Hier der Direktlink auf ein Windows-Programm, dass stand-allone die Firmware flasht:
https://github.com/nodemcu/nodemcu-flash…8266Flasher.exe

Es handelt sich dabei um ein Projekt von Rui Santos. Hier die Projektseite:
http://randomnerdtutorials.com/flashing-…-using-windows/
http://randomnerdtutorials.com/esp8266-t…shooting-guide/


Das Flashen der Firmware klappte bei mir mit diesem Tool auf Anhieb. Zuvor stellte ich im Flashprogramm die Baudrate auf 74880. Denn mir war bereits bei meinen zuvor erfolglosen Versuchen mit dem ESPlorer aufgefallen, dass der Witty offenbar diese recht ungewöhnlich Baudrate braucht (was bei anderen Usern aber offenbar anders sein kann!).

Nach dem erfolgreichen Flashen also erneut den ESPlorer gestartet und zunächst an dieser Fehlermeldung fast verzweifelt:


Der Meldung "Communication with CPU" folgten endlos Punkte, bis man im ESPlorer zweimal den Button "RTS" klickt (rechter Bildschirmteil, oben).
Tasten muss man am Witty nicht drücken, der Button reicht.
Anschließend wurde zwar die Meldung "Got answer!" ausgegeben, aber gefolgt von "Can't autodetect firmware, because proper answer not received."
- Das hat mich bald irre gemacht!

In einem russischen Forum fand ich die Erklärung: Die neueste NodeMCU-Firmware meldet sich anders, als die vorherigen Versionen und der ESPlorer kennt diese Änderung einfach noch nicht. Doch darum muss man sich gar nicht kümmern!
Das Auto-Detect der Firmware soll sich im ESPlorer auch abstellen lassen.

Aber selbst daraufhin konnte ich zunächst partout kein Script in den ESP8266 laden.
Ich verwendete übrigens dieses Script, das die kleine blaue LED auf dem ESP-Modul blinken lässt:



Doch das Betätigen des Buttons "Save to ESP" (ganz links unten) führte nur zu einer Fehlermeldung (Timeout).
Wiederum in einem russischen Forum fand ich schließlich die erlösende Erklärung:

"открывайте порт на скорости 9600, а потом уже переходите на 921600 ( ESPlorer сам перенастроит порт и отправит команду NodeMCU для переключения скорости)"

Auf Deutsch: Man muss im ESPlorer den Port zunächst auf 9600 Baud stellen, dann den Port öffnen und dann (bei geöffnetem Port!) einfach auf die tatsächlich nötige Baudrate umschalten (in meinem Fall also 74880, nicht wie im Forum erwähnt 921600).
Daraufhin konfiguriert der ESPlorer irgendwie alles in geeigneter Weise um ...
DAS war wohl die ganze Zeit der eigentliche Grund, an dem es bei mir haperte!
Ich würde das ja einen Bug nennen, aber meine Dankbarkeit für den kostenlosen, tollen ESPlorer ist einfach zu groß, um das übers Herz zu bringen.

Anschließend ließ sich das Script jedenfalls problemlos übertragen (nach Klick auf "Save to ESP" und die blaue LED fing brav an zu blinken.

Nun ist es ganz easy: Man ändert das Script in gewünschter Weise, klickt links unten auf "Save to ESP" und das Modul auf dem "Wirtty" tut sofort im Anschluss, ohne dass man Taster betätigen müsste etc., wie ihm aufgetragen

Also mit Lua werde ich auch nicht so ganz grün. Diese Sprache hat ein paar Eigenschaften, die mir umständlich vorkommen, bzw. mich ärgern.
So z. B.:

1. Die Syntax einiger Operatoren.
2. Die IMHO völlig kuriose Eigenart, dass auch Null als true gewertet wird, weswegen man dauernd nil braucht, um ein false zu erzwingen.
3. Die Tatsache, dass man Tabellen nur mit schweren Klimmzügen ab Null indizieren kann.

Zur Geschwindigkeit von Lua vs. "C" finde ich im Netz widersprüchliche Angaben. Manchmal heißt es, Lua wäre schnell und reiche fast an "C" heran. Woanders heißt es dann, die Geschwindigkeit wäre erheblich lahmer, verglichen mit "C".
Ich blicke da noch nicht recht durch, ob da nun von auf dem ESP8266 interpretiertem Quelltext die Rede ist, oder von compiliertem Lua-Code ...

Ich glaube mich zu erinnern, schon WS28XX-Ansteuerung in Lua gesehen zu haben, was nun echt zeitkritisch ist. Also wenn das geht ...
Andererseits habe ich auch Genörgel gelesen, dass genau das kaum vernünftig gehen soll, mangels Echtzeitfähigkeit dieser Scriptsprache.
- Verwirrung total!

Inzwischen gibt es für den ESP auch einen Basic-Interpreter. Aber der ist wohl noch sehr mager, in Bezug auf die beigesteuerten Snippets/Funktionen/Protokolle.

Jetzt muss ich mir wohl Python mal genauer anschauen und recherchieren, was es da bereits gibt.


Aktuell brauche ich übrigens ein Programm für den ESP, das mir dessen ADC-Daten in eine rohe Audiodatei streamt, die ich dann unverzögert auf dem Smartphone anhören, bzw.per FFT analysieren kann.
Über sowas wird in den Lua-Foren zwar viel gequasselt, aber gemacht hat es anscheinend noch keiner.
- Soll in meinem Fall ein Testgerät zur Fehlersuche auf Notebook-Mainboards werden, mit galvanischer Trennung.

Die Idee dazu hatte ich schon vor zwei Jahren. Seither schieben Hubi und ich dieses Projekt (das noch viel mehr können soll) vor uns her und finden nie die Zeit dafür. Doch die ist jetzt wirklich oberreif!

Falls Du mal zufällig einen mundfertigen Code auftreibst (egal, in welcher Sprache), dann denke bitte an mich!

Grmbl! Ich kämpfe und kämpfe seit Stunden über Stunden und kriege den Witty partout nicht ins WLAN.

Mit dem ESPlorer kann ich erfolgreich Code in den Witty übertragen, der z. B. die LED blinken lässt, oder Texte per Print ausgibt (über USB).
Soweit funktioniert das also. Aber nix mit WLAN.

Diese Anleitung ist eigentlich für Blöde:
http://randomnerdtutorials.com/esp8266-web-server/
Ich verwende genau diesen Code, trage dort brav meine SSID und das Passwort ein (wie im Router hinterlegt) und der Witty bezieht (nach laaangem Kampf!) inzwischen sogar zuverlässig eine IP vom Router. In meinem Fall 192.168.178.45

Tja, aber wenn ich diese IP in die Adresszeile des Browsers eingebe, tut sich nichts.
Es half auch nicht, die eigentliche Funkplatine des Witty vom USB-Teil abzuziehen und an ein 5V/1A Netzteil zu hängen.
Die IP lässt sich nicht mal per Windows CMD anpingen. Er antwortet nicht.

Auch der Browser meines Smartphones weigert sich, zu dieser IP zu verbinden.
Tippe ich in die Browser-Adresszeile hingegen die IP-Adresse meines Routers ein, so führt das erwartungsgemäß zur Darstellung von dessen Konfigurationsmenü. Das heißt: das Smartphone verbindet sich brav mit dem Router, beide sind im selben Netz.

Der Gag ist ja, dass der Witty funktionieren muss, auch WLAN-mäßig, denn er bezieht ja die IP vom Router. Schalte ich am Router das WLAN aus, dann bezieht der Witty auch keine IP mehr.
Aber warum kann ich die simple Testseite aus dem Beispielprogramm nicht im Browser darstellen? Bzw. noch härter: Warum lässt sich der Witty nicht mal anpingen???

Habe im Routermenü schon alles mögliche versucht. Gastzugang eingerichtet und die Kommunikation von Geräten untereinander zugelassen und so.
Habe auch versucht, den Witty stand-allone zu verwenden, ohne Router, gemäß den Tipps in den Kommentaren der oben verlinkten Seite. Alles ohne Erfolg.

Grmbl!!! Stehe total auf dem Schlauch!

Hallo Bastelfreund,

ich gehe jetzt mal nicht auf die einzelnen Punkte ein, bedanke mich aber herzlich für's Mitdenken!

Nöö, jetzt habe ich von diesem nodeMCU & Lua echt die Nase voll, zumal ich im Web noch andere (nicht gerade unkompetent wirkende) Blogger fand, die mit dem Ding ebenfalls graue Haare bekommen haben und schließlich auf andere Entwicklungssysteme umgestiegen sind (das von Arduino soll tatsächlich praktisch stressfrei sein, sofern man keine C-Allergie hat).
Nee, nix mehr mit nodeMCU und Lua. Kaum hat man dort eine Macke irgendwie umschifft, taucht instant die nächste auf. Das hat keinen Sinn.

Daher probierte ich heute den Mmiscool Basic-Interpreter.

Basic war ohnehin die ganze Zeit die Programmiersprache meiner schamlosesten Wunschträume. Seit einem dreiviertel Jahr wird an dem Projekt gearbeitet und erst seit wenigen Tagen ist der Funktionsumfang als ausreichend zu bezeichnen. Der Zeitpunkt für einen ersten Test ist also genau richtig.
Offenbar wird ganz kräftig daran gewerkelt, was hoffen lässt, dass der Autor die Welt eines schönen (und hoffentlich nahen) Tages auch mit einem Compiler beglücken wird.

Vollkommen auf Anhieb klappte es bei mir auch mit dem Basic nicht, aber zwischen dem Flashen des Interpreters und den ersten funktionierenden Codes, die per Firefox über WLAN eingespielt und ausgeführt/angezeigt wurden, verging nicht viel mehr, als 'ne halbe Stunde.
Beim dritten Code handelte ich mir dann 'nen hartnäckigen Hänger ein, nachdem ich an nicht ganz verstandenen Parametern kopflos herumspielte. Darum werde ich den ESP nun wohl neu flashen müssen (morgen, bin jetzt zu müde). Aber das waren endlich mal erste, echte Lichtblicke! Und das ohne viel Theater.

Der Weg, per Webbrowser den ESP mit Codezeilen zu füttern, die dort dann interpretiert werden, worauf eine Website zum Browser zurück geschickt wird, ist zwar ausgesprochen komfortabel, aber die Geschwindigkeit leidet doch spürbar.
Egal - immerhin kann ich jetzt erstmals meine Experimente machen, die ich schon seit fast zwei Jahren ständig vertage.
Wenn später echt zeitkritischer Code benötigt wird, kann man den ja immer noch in C umfrickeln. Doch es gibt tatsächlich Beispiele, wo sogar die vom Timing her reichlich anspruchsvollen WS28XX Neopixels mit diesem Basic angesteuert werden - Hut ab!

Gut gefällt mir, dass man nach dem Flashen des Interpreters das USB-Kabel nicht mehr braucht, sondern seinen Code fortan per WLAN überträgt. Das erfüllt mir einen seit Jahren gehegten Wunsch, bei meinen AVR-Projekten!
Portexpander an den ESP hängen und AVR hat endlich ausgekackt!

Zitat von »Bastelfreund«

Der Hinweis von dir bzgl. dem Witty war wirklich super

Schau Dir auch mal diese hier an:

http://www.ebay.de/itm/Mini-NodeMcu-4M-b…sIAAOSwiylW~qOn

http://www.ebay.de/itm/NEW-NodeMcu-Lua-E…nwAAOSwubRXHuXn

http://www.ebay.de/itm/WeMos-D1-R2-NodeM…TkAAOSwbwlW~tlf

Von diesen NodeMCU-Boards gibt es eine ganze Reihe verschiedener Versionen, mit unterschiedlichen Abmessungen und leicht abweichender Bestückung. Ich habe oben die drei IMHO interessantesten Versionen herausgepickt, für diese unterschiedlichen drei Einsatzzwecke:

1. Betont klein
2. Größer, aber billig und auch die Zusatzpins des 12-Moduls sind auf die Stiftleisten geführt.
   
3. Komfortables Experimentieren auf dem Labortisch (und vermutlich Arduino-Shield kompatibel)

Und hier noch ein Motor-Shield:
http://www.ebay.de/itm/ESP8266-NodeMcu-M…WgAAOSwvFZW6zHI

Zitat von »Bastelfreund«

und sogar Bread-Board geeignet.

Nicht wirklich
Probiere es doch mal ...
Der Witty passt zwar auf das Steckbrett, aber dann ist darin keine Buchse mehr frei, um noch Drähte zu stecken.

Nett beim Witty finde ich, dass man die Funkplatine solo verwenden kann, wenn man USB nicht braucht. Und das zu einem sehr günstigen Gesamtpreis. Dann hat man die untere Platine, mit dem USB-Teil, sozusagen geschenkt dazu bekommen (kann man immer mal gebrauchen, diese Dinger).


Was ich aber bei bislang ALLEN Boards mit aufgepfropftem ESP-Modul etwas widersinnig finde: Die ESP-Platine hat einen winzigen Chip drauf, mit superkleinen Anschlüssen. Um den Chip besser benutzen zu können, führen die ESP-Module die Chip-Anschlüsse nach außen, auf Lötflächen mit größerem Pinabstand. Soweit sogut.
Doch nun kommen diese Entwicklungs-Boards daher, die hauptsächlich noch 'nen Spannungsregler und 'ne USB-Buchse integriert haben, und führen die Pins des darauf bestückten Moduls abermals weiter nach außen, auf noch weiter auseinander liegende Anschlüsse.

In manchen Fällen mag das ja so seinen Sinn haben, aber oft ist es einfach konzeptioneller Unsinn. Nämlich dann, wenn das Endprodukt besonders klein bleiben muss.
Die obere Funkteil-Platine des Witty belegt eine viel größere Fläche, als das ESP8266-12 Modul, dabei ist auf der Unterseite kaum was bestückt.
Statt die Anschlüsse weiter nach außen zu verfrachten (im vermeintlich Steckbrett-freundlichen 100 MIL-Abstand), hätte ich mir eher eine klein gehaltene Fläche und im Mittelteil der Unterseite PADs für einen SMD-Micro-Match etc. gewünscht.

Dann wäre erstens das Endprodukt flächenmäßig kleiner (sogar auch flacher) und man könnte per Flachbandkabel entweder auf ein (dann ernsthaft nutzbares) Steckbrett, oder halt an das, was man am Ende mit dem ESP ansteuern möchte.

Gut, der Witty, mit seinem Lichtsensor und der Mehrfarb-LED, ist eher ein Test- und Entwicklungssystem. Dafür ist er schön klein gehalten.
Aber der Mini NodeMCU, aus dem ersten Link, ist von der Fläche her noch eine Spur kleiner, trotzdem der USB-Teil gleich mit integriert ist, der beim Witty auf einer zweiten Platine sitzt.
Mini NodeMCU ist also besser designt (weniger platzverschwenderisch). Und man kann - verglichen mit dem Witty - sogar viel leichter an die Extra-Pins des ESP-Modul etwas anlöten (die auch dort einfach ungenutzt bleiben).


Das Board aus dem zweiten Link ist größer, scheint aber die Zusatzanschlüsse des ESP-Moduls mit auf die Stiftleisten geführt zu haben.
Und es ist billiger, als der betont kleine Mini NodeMCU.


Das WeMos aus dem dritten Link ist natürlich richtig groß, aber zum Experimentieren auf dem Tisch irgendwie "griffiger".
Ich bin mir nicht sicher, ob das betont an Arduino erinnernde Design tatsächlich kompatibel zu dessen Shields ist. Falls ja, wäre das in manchen Fällen sehr praktisch.


Was mir jetzt vorschwebt:
Ein Platinchen in den Abmessungen des ESP-12, das nur einen Spannungsregler und einen bidirektionalen Levelshifter beinhaltet (evenbtuell ein entsprechender Portexpander-Baustein), sowie einen Flachband-tauglichen Anschluss.
Der Sinn ist der, auf kleinster Fläche den ESP mit "alter" 5V-Technik zu verheiraten.

Wegen dem Flachband-tauglichen Anschluss, könnte auch bequem eine Verbindung zu einem DIL-Sockel hergestellt werden.
Also den DIL-IC einer bestehenden Schaltung aus dem Sockel nehmen und an dessen Stelle dort 'nen entsprechenden DIL-Stecker rein, der auf ein Flachbandkabel gecrimpt ist. Dessen anderes Ende führt zu dem ESP-Platinchen.
So kann man bestehende Schaltungen entweder aufmotzen, oder für Testzwecke mal Signale zuführen/mitloggen, bei galvanischer Trennung.
Das ist z. B. dann interessant, wenn irgendwo GALs (oder andere, programmierte Bausteine) bestückt sind, deren Inhalt man nicht kennt.

Ich habe immer wieder mal was zu reparieren, was noch ausschließlich mit 5V-Technik läuft und irgendwo total schlecht zugänglich verbaut ist, oft unter betont engen Verhältnissen.
Bisher musste ich dann gefühlt 1000 Mal irgendwie bäuchlngs in 'ne Maschine kriechen, dort 1000 Mal 'nen IC aus dem Sockel rupfen, den dann neu programmieren und ausprobieren ... geht noch nicht ...
Jetzt würde ich halt den ESP einbauen und aus der Ferne programmieren, bis es passt. Am Ende verbleibt er einfach in der Schaltung; kostet ja nix

Hey Bastelfreund,

hast Du schon mal versucht, größere Datenmengen zu übertragen?
Ich deponierte gestern ein JPG von 1,1MB in dessen Filesystem und rief es dann per Firefox auf.
Es dauerte satte 2 Minuten und 43 Sekunden, bis es angezeigt wurde!

Zuerst vermutete ich, dass der Basic-Interpreter so krötenlahm ist. Aber das Problem ist offenbar grundsätzlicherer Natur beim ESP.
Hubert schrieb mir das hier:

ja da vermute ich das Windows-Problem den den Delayed Acks:
https://github.com/esp8266/Arduino/issues/1430

Jedes IP-Paket hatte eine Wartezeit von 200ms. 1MB sind ca. 750 Pakete.
Das wären also 2,5 Minuten. Genau deshalb, sind wir dann umgestiegen,
auf dem Atmel-Baustein.

Mit der Lib wurde es besser (ca. 7ms pro Paket), aber das hilft Dir ja
auch nicht weiter, als Basic-Benutzer
http://www.forward.com.au/pfod/pfodParse…ries/index.html


Demnach könntest Du, Bastelfreund, mit Deinem Arduino-Entwicklungssystem die Geschwindigkeit aufpeppen, sofern du diese Lib installierst.
Aber ein Rennpferd wird der ESP dadurch auch nicht. Dann halt ca. 6 Sekunden, statt 163. Immer noch lahm.

Also das ist jetzt aber ein herber Rückschlag, nachdem ich gerade begonnen habe, mich an ein erstes, reales Projekt zu wagen.
Und selbst ein Umstieg auf das von mir so ungeliebte "C" würde das Problem nicht ausreichend aus der Welt schaffen ...

Laut Hubert ein Windows-Problem ...
Habe die Datei dann per Android-Smartphone aufgerufen. Da dauerte es ziemlich genau 40 Sekunden.
Das ist immer noch reichlich lange, angesichts der mir in der Fritz!Box angezeigten Datenrate von 64 MBit/s. Hier könnte es also tatsächlich an der Krötigkeit des Basic-Interpreters liegen.
Update: Nö, liegt nicht am Basic, siehe Folgeposting!

Magst Du mal den Test bei Dir wiederholen, mit einer vergleichbar großen JPG-Datei?

Hubert ist wegen diesem grundlegenden Problem einst vom ESP auf ein Modul von Atmel umgestiegen, das die große Wende brachte.
Auf diesen Schritt habe ich aber wenig Lust. Das Ding ist größer und viel teurer, als der ESP. Zudem müsste man sich neu einarbeiten. Und Hubert beklagte die grottige Dokumentation, sowie einige andere Macken dieses Moduls, die ziemlich schwer zu umschiffen waren.

Vielleicht bringt ja der bald kommende, zweikernige und angeblich grundlegend optimierte Nachfolger des ESP8266 die Erlösung (ESP32).

Hab's noch nicht ausprobiert (kann den nötigen Rechner-Neustart jetzt nicht durchführen), aber ...
Update: Habe die im verlinkten PDF beschriebene Lösung inzwischen ausprobiert. Erfolg! Das Bild lädt jetzt in 6 Sekunden (statt 163)!

... hier wird das Problem diskutiert:
https://github.com/esp8266/Arduino/issues/1027

Weit unten findet man dort das folgende PDF verlinkt, in welchem erklärt wird, wie man Windows diese ACK-Verzögerung abgewöhnen kann:
http://www.icpdas.com/root/support/faq/c…CK_Delay_en.pdf


Interessant ist noch (was im Github-Thread ebenfalls erwähnt wird), dass manche Versionen des Internet-Explorers diese Windows-Macke von sich aus "bypassen".
Aber halt nur manche Versionen ...
Und davon abgesehen: Wer verwendet schon freiwillig den IE, wenn er genug Hirnzellen im Kopf hat, um sich mit dem ESP zu beschäftigen?




Themenwechsel: ESP und Router.
Bekanntlich hatte ich mit NodeMCU fette Probleme (in Bezug auf WLAN). Mit Basic ging es gleich viel besser, dennoch hatte ich auch damit gestern plötzlich wieder Verbindungsschwierigkeiten. Nebst dem Phänomen, dass in der Fritz!Box die Verbindung zum ESP zwar angezeigt wurde, dennoch aber kein Zugriff per Webbrowser darauf möglich war.
Dieses Problem verschwand komplett, nachdem ich die Firmware meiner Fritze von 6.04 auf 6.51 updatete!

Kann sein, dass schon ein bloßer Router-Neustart gereicht hätte, aber ich will es erwähnt haben, was bei mir konkret half.
Es wäre denkbar, dass jetzt auch NodeMCU bei mir funzen würde, allerdings habe ich keine Lust mehr auf das Ding.


Themenwechsel: ESP und dessen Stromversorgung.
In verschiedenen Foren fand ich Hinweise auf Probleme mit dem ESP, die sich durch das Einlöten von Stützkondensatoren zwischen 3,3V und GND perfekt beseitigen lassen sollen. Was auch völlig plausibel klingt, angesichts dessen, dass zwar der durchschnittliche Stromverbrauch des ESP recht gering ist, der Strom jedoch in schmalen Bursts gezogen wird.
Jedes Test-Board ist anders aufgebaut (ganz zu schweigen von Breadboard-Aufbauten) und auch die daran angeschlossenen Stromversorgungen differieren natürlich, von Anwender zu Anwender, weswegen das Problem bei manchen dick in Erscheinung tritt, bei anderen aber überhaupt nicht.

Ein schneller Blick auf den Witty offenbarte mir, dass dieser bezüglich Kondensatoren doch recht suboptimal designt ist.
Bei fehlerhafter Datenübertragung also mal HF-taugliche Kondensmänner einlöten, möglichst direkt an die Anschlüsse des ESP-Moduls und mit kürzest möglichen Leitungen.
Ideal dürften zwei Kondensatoren parallel sein: Ein recht großer (einige hundert Mikrofarad) und ein kleinerer (dafür flotterer) mit so ca. 100nF.

Wer eine grafische Oberfläche zur Steuerung seines ESP-Projektes per Webbrowser braucht ...

... der kann diese natürlich "von Hand" in HTML und CSS erstellen.
Ist aber halt ein Sack voll Arbeit.

Hier fand ich das verlinkt: NetIO

Also die Beispiele der damit erstellten GUIs sehen ja wirklich großartig aus!
Aber ich sehe "C"-Code ...


Dennoch fand ich das Projekt inspirierend. Es mag andere Möglichkeiten geben, ein ähnlich schickes Userinterface zu stricken.
Generell denke ich an ein Programm zur Gestaltung von Websites, über dessen HTML-Ausgabe man ein Stück eigene PC-Software rappeln lässt, das anhand der Elemente dann wiederum Basic-Code (oder Lua, oder Python, was auch immer) für den ESP generiert, zur Abfrage von Buttons etc.

Auch Visual Basic bietet ja die Möglichkeit, sich Oberflächen per Maus zusammen zu klicken und am Ende kommt ein Rohbau aus VB-Code heraus, der dann nur noch mit Inhalten gefüllt werden muss.

Bin offen für gute Tipps!

Zitat von »Bastelfreund«

Nur so am Rande: würdest du es auch mit einem Spannungsteiler R1 = Rntc,Arbeitspunkt (ca. 120°C)versuchen und die Temperatur dann über ne entsprechende Regressionsfunktion (Excel spuckte mir ein Polynom 4. Grades aus) berechnen? Oder gibt es da bessere/geschicktere/praxistauglichere Vorangehensweisen?

Hallo Bastelfreund,

zugegeben: Ich hatte mit Temperatursensoren bislang nur soweit zu tun, dass ab Überschreitung eines bestimmten Grenzwertes eine Abschaltung erfolgen sollte.
Also keine linearen Messungen, über einen weiten Bereich, sondern einfach eine gut/böse-Entscheidung. Da interessieren sensorbedingte Unlinearitäten absolut gar nicht.

Bei einem Platinsensor (PT100 etc.) hättest Du das Problem nicht, weil dessen Kennlinie schön linear und das Gesamtverhalten dieser Sensoren untereinander hochgradig identisch ist.
Aber da es bei Dir halt ein NTC ist, wäre der sinnvolle Weg, dessen Kennlinie schaltungstechnisch zu linearisieren (schon ein simpler Vorwiderstand tut den Trick!), um dann mit einfachster Mathematik und einfachstem Code auszukommen.

Hier wird das schön anschaulich erklärt:
http://www.sprut.de/electronic/temeratur/temp.htm

Auch gut:
http://rn-wissen.de/wiki/index.php?title=PTC/NTC

Zu beachten ist noch, dass der ADC des ESP ganz unten, nahe Null Volt, unlinear ist. Ebenso ganz oben, also bei 1V.
Man sollte also vorzugsweise so zwischen 0,1V und 0,9V arbeiten.

Wenn hohe Präzision und ein weiter Temperaturbereich gefordert ist, bietet es sich an, den Messbereich mit einem Operationsverstärker an dieses Fenster anzupassen, so dass jedweder Temperaturwert stets zu einem Spannungswert innerhalb dieses Fensters am ADC führt ...
... was aber auch wieder schwierig ist, wenn keine negative Versorgungsspannung zur 'Verfügung steht, denn kaum ein OPV kommt am Ausgang ohne Linearitätsfehler bis auf 0,1V herunter.
Jedenfalls könnte man mit einem OPV sowohl den Offset in den benötigten Bereich verschieben, als auch, durch entsprechende Wahl des Verstärkungsfaktors (der hier eine Abschwächung wäre), die Fensterbreite dem Bedarf entsprechend auf 0,8V begrenzen.

Wenn Du ohne OPV arbeiten willst (wovon ich ausgehe), solltest Du noch einen kleinen Kondensator zwischen ADC-Eingang und dem Masseanschluss des Controllers schalten, um den ADC-Eingang zu entkoppeln, sonst haut Dir jede kurzfristige Spannungsschwankung auf dem 3,3V-Pfad voll in die Messung rein.

Es kann sein, dass Du dennoch sonderbare Abweichungen von Messung zu Messung feststellst, trotz identischer Temperatur.
Das kann man aber per Software korrigieren. Z. B. indem man mehrere Messungen durchführt, deren Werte in eine sortierte Liste einfügt (da bietet sich wohl Bubblesort an) und dann einfach den Median nimmt. Ausreißer durch Störeinflüsse wird man damit los.
Wenn auch der Median stärker als erwünscht springt, dann halt mehrere Werte aus der Mitte der sortierten Liste nehmen und daraus den Durchschnitt bilden.

Wer krass drauf ist, kann natürlich auch Integralrechnung betreiben ... wobei ja eigentlich der von mir empfohlene Kondensator am Eingang genau diesen Job genügend hinreichend tun sollte, rein schaltungstechnisch (für einen richtigen Integrator nimmt man aber doch 'nen OPV zur Hilfe).
Beim AVR war es jedenfalls so, dass der ADC trotz bestem Eingangssignal immer wieder mal Ausreißer lieferte. Da musste ich also per Software korrigieren.
Normalerweise sollte aber die Schaltungstechnik den Löwenanteil tun.
Hast ja gesehen: Ein simpler Widerstand plus ein Kondensator vereinfacht die Matematik auf Grundschul-Niveau ... sofern der ADC seinen Job ordnungsgemäß tut.
Beim AVR war das immer sehr bedeutend, mit möglichst einfacher Mathe auszukommen, weil dessen 8-Bit-Architektur bei Fließkommarechnung wirklich krötenlahm wurde.

... kam von Hubert noch die Empfehlung auf jQuery-mobile.

Der Vorteil soll sein, dass dabei am Ende mehrere Seiten in nur einer einzigen HTML-Datei enthalten sind.
Es muss also nur eine einzige Seite geladen werden und die ganze Interaktion geht ratzfatz.

Also ich weiß nicht ...
Von Anfang an plagen mich Stabilitätsprobleme:

- Mit NodeCMU habe ich ja bekanntlich niemals eine WLAN-Verbindung zustande bekommen.
- Mit Basic klappte das, aber gab doch gelegentlich Zicken.
- Die Zicken besserten sich deutlich, nach dem Update der Firmware meiner Fritz!Box. Ich bin mir aber nicht völlig sicher, ob es wirklich daran lag.

Seither konnte ich mit dem Witty relativ gut arbeiten, wenn ich lediglich kleine Programme ausprobierte. Doch beim Upload eines großen Programms (830 Zeilen) schlug dieser immer wieder fehl, mit Abbruch bei beliebigen Zeilennummern.
Ich führte das auf die Spannungsversorgung zurück und lötete daraufhin mehrere Kondensatoren parallel direkt an die Anschlüsse VCC und GND des ESP:
Ein Becherelko von 1000 Mikrofarad, ein SMD-Tantalelko von 160 Mikrofarad, ein KerKo mit 10 Mikrofarad und ein 10nF Kerko.
Also an Kondensmännern dürfte es dem Modul nun wirklich nicht mangeln.

Gespeist wird der Witty bei mir von einem 1A USB-Netzteil, direkt in die obere Platine. Andere Netzteile habe ich auch schon probiert.
Die Spannung am VCC des ESP beträgt 3,315V, gegen GND. Also ganz leicht über Sollwert - bestens!

Nach dem Einlöten der Kondensatoren konnte ich beim vierten Versuch erstmals erfolgreich das 830-Zeilen-Programm hochladen, was zuvor in etlichen Versuchen partout nicht klappte. Aber - öhh - vierter Versuch ...

Zudem geht die Verbindung bei der Ausführung des dicken Programms immer wieder flöten.
Guuut, vielleicht liegt's ja an der Fritz!Box, also das Smartphone gezückt. Da erscheint und verschwindet der ESP ...
Wenn er mal da ist, wird die Signalstärke mit "hervorragend" angezeigt.


Als letzte Verzweiflungstat lötete ich das Funkmodul von der oberen Platine ab und ein anderes ESP8266-12E ein.
Speicher formatiert, Basic neu geflasht, dann getestet. Praktisch gleiche Zicken wie zuvor ...


Bastelfreund, läuft der Witty bei Dir stabil?
Und hast Du schon mal ein vergleichbar großes Programm ausprobiert?
Hast Du vielleicht ein fertiges Image eines dicken Programms, das ich testweise mal flashen könnte?
Vielleicht liegen die Zicken ja am Basic?