Eigentlich ist das Teil ein Modem, ein Funkmodem. Das legt schon der AT-Commandset, den die Erfinder des Chips gebaut haben, nahe. Die Anfänge stammen von den Fa. Hayes und sind im Laufe der Zeit für alle möglichen Datenübertragungen erweitert worden, hier für WLAN. Daß ein Modem heutzutage im wesentlichen aus einem Prozessor statt aus diskreter Logic und vielen Filtern besteht, ist klar. Wenn man mit der Funktionalität des mitgelieferten AT-Commandsets auskommt, klemmt man das genauso wie einen seriell-USB Wandler (auch eine Art Modem) an die serielle. Da ich gerne UDP verwende, hat mir die eingebaute Funktionalität aber nicht gereicht. Um ich mir die Entwicklung einer vollständigen eigenen Firmware zu sparen, bau ich mir mein "eigenes" Modem in Lua.Zitat von thewulf00
Was meine ich mit "einfache Aufgaben"? Alles was nicht zeitscharf ist, so z.B alle paar 10 Millisekunden Taster abfragen, Alle Ausgaben, die für einen Menschen gedacht sind usw. Und was sind keine "einfachen Aufgaben"? Eigentlich alles, wofür es zum Teil sehr aufwendige Hardwareunterstützung in den µCs gibt, viele IOs, Timer, schnelle SPI, mehrphasen PWMs, ADCs etc. So eine Quadcopter Steuerung wird nicht richtig funtionieren, wenn der WLAN Stack die CPU für eine Weile blockiert. Als Telemetriesender passt der ESP aber sicher.
Sicher, in der dem Problem angemessenen Hochsprache. Bei einer Lohnbuchhaltung ist es unerheblich, wenn das Laufzeitsystem einer Hochsprache ab und an mal den Garbagecollector anwirft, wie bei vielen interpretierten Sprachen und auch bei Lua. Auf den µCs verwende ich C, das ist im Moment der beste Kompromiss zwischen Hochsprache und Zeitschärfe (und Verfügbarkeit).Und sollte man nicht eher sehr komplexe Aufgaben in einer Hochsprache lösen? (Der Fehlertoleranz und vereinfachung des Codes wegen...)
MfG Klebwax
Zitieren
Lesezeichen