Hi Leute, gibt es schon Erfahrungen was den ESP32 in kommerziellen Projekten angeht? Irgendwelche Auffälligkeiten? Könnt ihr den Chip empfehlen? Beste Grüße, Markus
Also, das ESP8266-SDK ist erst seit relativ kurzer Zeit halbwegs stabil, sofern man nicht auf SSL angewiesen ist. Was ich aber beobachtet habe: Seit es den ESP32 gibt, findet beim Vorgänger fast keine Weiterentwicklung mehr statt. Als ob sie den Chip fallen ließen wie eine heiße Kartoffel. Dabei ist er gar nicht mal so lange am Markt. So eine Firmenpolitik macht mich skeptisch. Ich würde darauf verzichten, in Zukunft irgendetwas von denen einzusetzen.
Angehängte Dateien:
-
IMG_20170826_171157.jpg
240 KB
Ich habe hier eine drahtlose Maus von Razer auseinander gebaut heute (Razer Naga) und musste feststellen das der Funk über ein ESP8266 realisiert wird. Zugegeben: zu meiner Verwunderung... da 2,4Ghz für Mäuse ja doch relativ ungewöhnlich ist. Die Maus ist Schätzungsweise ca. 4 Jahre alt. Und funktioniert tadellos (bis auf den Kabelbruch des mechanisch Probritären USB Kabel welches ich ausbesserte) Also: ja die ESP werden schon kommerziell und professionell eingesetzt.
:
Bearbeitet durch User
Rene K. schrieb: > und musste feststellen das der Funk über ein ESP8266 > realisiert wird. Na sowas, wird da ein richtiges WLAN aufgemacht? Oder wird der Funk-Teil per Software so gesteuert dass er ein eigenes (einfacheres/effizienteres) Protokoll nutzt?
Rene K. schrieb: > Die Maus ist Schätzungsweise ca. 4 Jahre alt. Da gabs den ESP8266 AFAIR doch noch gar nicht (jedenfalls nicht verfügbar). Und WLAN (802.11bgn) in ner Maus? Nunja... recht hohe Verzögerung und Energiebedarf und komplexe Settings --> unwahrscheinlich. Nicht alles was ein ähnliches Package hat ist gleich ;-)
Ich würde da bis auf weiteres die Finger lassen. Die erste in Massen ausgelieferte Version hatte noch erbärmliche Fehler die viele Funktionen unnutzbar ließen. Aktuell scheint auch das SDK noch nicht mal wirklich im Beta Stadium. Man hat das Gefühl es wurden nach "bullshitbingo" viele Funktionsblöcke in einen Chip gewürfelt und jetzt schaut man während der SDK Entwicklung was davon auch verwendbar ist. Ein plakatives Beispiel für das Gebahren der Firma ist der "deepsleep" des esp8266. Da verhindert wohl ein Fehler im internen Bootloader den korrekten Einsatz und muß durch ein - noch dazu im Datenblatt falsch beschriebenes - Workaround mit Funktionseinschränkung erzwungen werden; anstatt einer neue Revision zu bringen. Kommt man mit den im aktuellen SDK gerade funktionstüchtig implementierten Funktionen aus ist es sicher ein "Schnäppchen", Hoffnungen auf einen uneingeschränkten Einsatz aller beworbenen Features würde ich mir allerdings nicht machen....
G. H. schrieb: > Ein plakatives Beispiel für das Gebahren der Firma ist der "deepsleep" > des esp8266. > Da verhindert wohl ein Fehler im internen Bootloader den korrekten > Einsatz und muß durch ein - noch dazu im Datenblatt falsch beschriebenes > - Workaround mit Funktionseinschränkung erzwungen werden; Wie meinen? Der Modus funktioniert doch.
nö, eben nicht so wie eigentlich vorgesehen. Der Würgaraund ist eben der "Reset" über gpio16 von dem behauptet wrid, dass er zum Aufwachen benötigt wird (wobei die direkte Verbindung wie sie im DB gefordert wird einen normalen Reset bzw. eine Neuprogramierung zum Glücksspiel macht). Auch ohne die Verbindung wacht der µC auf, bloß weiß der 1st stage BL nichts mit "wakeup" anzufangen ....
Moin, für die Espressiv-Lösungen habe ich auch nur noch vernichtente Kritik übrig. Der schlimmste Bug ist der HW-Watchdog im Radio-Teil, der den Chip in seltenen Fällen einfach zum Neustart zwingt. Damit sind keine 24/7-Anwendungen zu machen. Zudem strotzen JTAG und Bootloader nur vor Bugs. Anstatt einen Fix zu präsentieren, schmeisst man halt einfach mal einen weiteren CPU-Kern drauf. Ob das Problem damit behoben ist, ist mir allerdings nicht bekannt, habe ich dem ESP32 keine Chance mehr gegeben. Die wenigen Dollar, die man gegenüber brauchbaren Lösungen einspart, machen den Aufwand für die ganzen Workarounds nicht wett. Dazu kommen eine Menge Lizenzkonflikte, die eine saubere industrielle Anwendung unmöglich machen.
Rene K. schrieb: > Ich habe hier eine drahtlose Maus von Razer auseinander gebaut heute > (Razer Naga) und musste feststellen das der Funk über ein ESP8266 > realisiert wird. Zugegeben: zu meiner Verwunderung... da 2,4Ghz für > Mäuse ja doch relativ ungewöhnlich ist. > > Die Maus ist Schätzungsweise ca. 4 Jahre alt. Und funktioniert tadellos > (bis auf den Kabelbruch des mechanisch Probritären USB Kabel welches ich > ausbesserte) > > Also: ja die ESP werden schon kommerziell und professionell eingesetzt. 2,4 GHz für Mäuse ist jetzt nicht so ungewöhnlich -> Bluetooth.
Ich quäle mich auch gerade mit einen ESP32 herum -> fürchterlich bis man alles zusammen hat. Ich glaube ich bleibe beim winc1500, da auch weniger Strom verbraucht. Bis auf ein paar Kleinigkeiten hat das mit dem ASF sofort gut funktioniert. Die IDF ist einfach fürchterlich überladen und dadurch ist das was als Task für den Anwender übrig bleibt er lächerlich. Also Anwendung darauf entwickeln zu müssen ist so ziemlich grausam...
:
Bearbeitet durch User
G. H. schrieb: > Auch ohne die Verbindung wacht der µC auf, bloß weiß der 1st stage BL > nichts mit "wakeup" anzufangen .... Das wusste ich nicht. Ich frage mich nur: Haben die das Hardwaredesign versaubeutelt, oder warum gibt es da nicht ein einfaches Firmwareupdate? Strubi schrieb: > Die wenigen Dollar, die man gegenüber brauchbaren Lösungen einspart, > machen den Aufwand für die ganzen Workarounds nicht wett. Welche brauchbaren Lösungen meinst Du? Sind die ähnlich einfach zu programmieren?
> Welche brauchbaren Lösungen meinst Du?
Mir fallen spontan die Chips von Wiznet ein.
André R. schrieb: > oder warum gibt es da nicht ein einfaches Firmwareupdate? Der Bootloader befindet sich im ROM. evtl. Maskenprogrammiert, also nix Update.
Stefan U. schrieb: >> Welche brauchbaren Lösungen meinst Du? > > Mir fallen spontan die Chips von Wiznet ein. Die kosten nach ersten Recherchen aber auch gut und gerne das Zwanzigfache – oder mehr. Arduino F. schrieb: > André R. schrieb: >> oder warum gibt es da nicht ein einfaches Firmwareupdate? > Der Bootloader befindet sich im ROM. > evtl. Maskenprogrammiert, also nix Update. Das kann gut und gerne sein. Aber der Fehler scheint ja schon seit Jahren bekannt zu sein. Was hätte dagegen gesprochen, eine zweite Hardwarerevision herauszugeben, in der der Fehler korrigiert ist? Von mir aus einen 8266A, o.Ä. Nur der Interesse halber: Kann es dann eigentlich sein, dass die so genannte RTC des Chips sich eigentlich gar nicht zurücksetzen sollte, wenn der Timer den Chip aufweckt, und dies nur wegen des Workarounds mit dem Reset tut? Mir kommt das nämlich fehlkonstruiert vor, dass dieser nach jedem Aufwachen bei 0 zu zählen beginnt. Die Uhr muss systembedingt im DeepSleep weiterlaufen, um dem System zu sagen, wann der Reset ausgelöst wird. Warum man den Timer dann zurücksetzt, ist mir schleierhaft!
> Die kosten nach ersten Recherchen aber auch gut und gerne das > Zwanzigfache – oder mehr. Lohnt sich trotzdem, sofern du ein Einzelstück entwickelst und mit den Macken der ESP Chips noch nicht vertraut bist. Wer Geld sparen will und in größerer Menge Produziert, mag ESP Chips bevorzugen. Ich habe micht im Ramen des Hobbiues mit dem ESP8266 beschäftigt. Da war der Weg das Ziel und Zeit spielte keine Rolle. Ob ich aber jemals einen kommerziellen Auftrag damit entwickeln würde, ist sehr unwarscheinlich.
> Was hätte dagegen gesprochen, eine zweite > Hardwarerevision herauszugeben Die Entwicklungskosten. Solange sich der alte Chip verkauft, wird er verkauft. Bei diesem Produkt setzt man ganz klar auf Masse statt Klasse. > Kann es dann eigentlich sein, dass die so genannte RTC des Chips > sich eigentlich gar nicht zurücksetzen sollte, wenn der Timer den > Chip aufweckt, und dies nur wegen des Workarounds mit > dem Reset tut? Ich weiss nicht, was der Hersteller sich dabei gedacht hat, aber ich halte es für einen Bug. Ich halte es auch für einen Bug, daß der Chip einige zig mA aufnimmt, wenn man die Stromversorgung einschaltet während man den EN (CH_PD) Pin auf Low hält.
André R. schrieb: > Welche brauchbaren Lösungen meinst Du? Sind die ähnlich einfach zu > programmieren? Wiznet (schon genannt) ist recht einfach zu programmieren und ist ziemlich stabil, meine Favoriten sind aber die Mediatek 7688 MIPS-Plattformen. Die laufen mit einem kompakten OpenWRT from the Box sehr robust und sind als DIP-Module zu kriegen. Bei einigen 100 Stück lohnt sich das längst und die Module kann man ohne Bauchweh betr. gefälschter FCC-Zertifikate auch in ein Industriegerät einsetzen. Wenns ans Stromsparen geht, muss man etwas tiefer ins System einsteigen. Stefan U. schrieb: >> Die kosten nach ersten Recherchen aber auch gut und gerne das >> Zwanzigfache – oder mehr. > > Lohnt sich trotzdem, sofern du ein Einzelstück entwickelst und mit den > Macken der ESP Chips noch nicht vertraut bist. Ja, lohnt. Ich habe am ESP8266 sicher 1 Mannmonat an Reverse-Engineering verbraten, man darf also rechnen. Es gibt sicher Frickel-Anwendungen, wo man mit einem weiteren Käfer den ESP-Kram per MOSFET bei Bedarf einschalten kann um mal schnell ne Message wegzuschicken. Da ist aber eine klassische WLAN-Karte über SDIO oder USB die deutlich bessere Wahl.
Keine Ahnung was ihr erwartet, aber das Teil wurde von Chinesen entwickelt bzw. teilweise aus 3rd party IP blöcken (Tensilica usw.) zusammen ge-copy+pasted. Die Software wurde doch sogar teilweise von den Anwendern aufpoliert... als das auf den Markt kam war die Software ein schlechter Witz soweit ich mich erinnern kann. Das ist halt nicht Atmel oder TI.
Stefan U. schrieb: > Ob ich aber jemals einen > kommerziellen Auftrag damit entwickeln würde, ist sehr unwarscheinlich. Das ist eh nicht meine Ambition. Für mich ist das eher ein Hobby und an kniffligen Herausforderungen habe ich schon immer Spaß gefunden. Wenn ich mein Endprodukt hinterher verkaufen würde und dafür auch noch Garantie übernehmen müsste, würde ich sicher auch so denken. Martin S. schrieb: > Bei einigen 100 Stück > lohnt sich das längst und die Module kann man ohne Bauchweh betr. Das kann ich mir vorstellen. Habe auch die von Dir empfohlenen Chips einmal angesehen. Für eine Hobbyinstallation sind mir aber knapp 45 $ pro Stück dann doch etwas zu viel. Für das Geld kann ich viele ESPs verbraten. Pinker Waschbär schrieb: > Keine Ahnung was ihr erwartet, aber das Teil wurde von Chinesen > entwickelt bzw. teilweise aus 3rd party IP blöcken (Tensilica usw.) > zusammen ge-copy+pasted. Das finde ich prinzipiell nicht verwerflich. Sicher sehen das hier einige anders, aber machen wir uns doch nichts vor: Das Rad neu erfinden tut doch schon lange keiner mehr. 90-95 % eines jeden "neuen" Produktes sind doch letztlich zusammen geklaut. Und das machen auch deutsche Hersteller und Entwickler so. Und immerhin muss ich, wenn man die Mitbewerber so vergleicht, den Chinesen meine Hochachtung dahingehend ausdrücken, dass sie es geschafft haben, einen solch universellen Chip für einen derart niedrigen Preis herstellen zu können. Man muss sich immer eine Zahl vor Augen führen: 1,70 € inklusive Versand bei Einzelabnahme (wenn man ein gutes Angebot erwischt).
Pinker Waschbär schrieb: > Keine Ahnung was ihr erwartet, Naja, es steht doch im Titel, "im professionellen Einsatz". Ich frage mich bei den Dinger immer, wie viel die FCC ID wert ist. Macht man eigene Software müsste das hinfällig sein. Aber eine zertifizierte Software habe ich auch noch nicht gesehen, nur mal für den ESP8266 das Angebot einer Dienstleistung von einer Dritt-Firma das zu zertifizieren.
> Aber eine zertifizierte Software habe ich auch noch nicht gesehen
Ist das nicht die AT Firmware?
Stefan U. schrieb: > Ist das nicht die AT Firmware? Wenn Du dafür einen belastbaren Beleg findest, gerne posten.
André R. schrieb: > Habe auch die von Dir empfohlenen Chips > einmal angesehen. Für eine Hobbyinstallation sind mir aber knapp 45 $ > pro Stück dann doch etwas zu viel. von welchen redest Du da? Ich glaube strubi meinte eher etwas in diese Richtung: https://www.seeedstudio.com/LinkIt-Smart-7688-p-2573.html Kostet zwar immernoch mehr als ein ESP-Modul, aber dafür bekommst Du halt ein ohne Bauchschmerzen anpassbares OpenWRT als Basis.
André R. schrieb: > Das kann ich mir vorstellen. Habe auch die von Dir empfohlenen Chips > einmal angesehen. Für eine Hobbyinstallation sind mir aber knapp 45 $ > pro Stück dann doch etwas zu viel. Für das Geld kann ich viele ESPs > verbraten. 45? Also für die LinkIt-Module bezahlst du normalerweise unter 10 USD in Einzelstückzahlen.
Stefan U. schrieb: > Ich halte es auch für einen Bug, daß der Chip einige zig mA aufnimmt, > wenn man die Stromversorgung einschaltet während man den EN (CH_PD) Pin > auf Low hält. Ist das vielleicht bedingt durch den Flash-Speicher? Hast Du ein Modul oder den nackten Chip vermessen?
> Ist das vielleicht bedingt durch den Flash-Speicher?
Da ich den Flash Speicher von außen nicht steuern kann und auch nicht
will, halte ich das für einen Konstruktionsfehler. Egal welcher der
beiden Chips auf dem Modul nun Schuld ist.
Wenn ich den EN Pin nach dem Boot Vorgang auf Low ziehe, geht die
Stromaufnahme wie erwartet auf unter 1mA runter.
>Ich frage mich bei den Dinger immer, wie viel die FCC ID wert ist. >Macht man eigene Software müsste das hinfällig sein. Wenn ich es richtig weiß, ist eine FCC-Zulassung auf einem Bauteil im Gerät sowieso nutzlos weil immer das gesamte Gerät mit dem letzten Softwarestand abgenommen werden muss. D.h. Du kannst zwar ein Funkinterface mit Zulassung einbauen, musst aber trotzdem eine Zulassungsprüfung für das Gesamtgerät machen. Mein Idee dazu ist: Ein Gerät mit Linux Kern bauen und einen WIFI-Stick in die Verpackung dazu legen.
Markus schrieb: > Wenn ich es richtig weiß, ist eine FCC-Zulassung auf einem Bauteil im > Gerät sowieso nutzlos weil immer das gesamte Gerät mit dem letzten > Softwarestand abgenommen werden muss Neuerdings, so ich die 'neuen' FCC-Restriktionen verstanden habe, muss garantiert werden können, dass an der Radio-Firmware keine Parameter verändert werden können. Da die FW aber ein statisch gelinkter Blob ist, der höchstens noch auf "closed" ROM-Routinen zugreift, ist da keine richtige Trennung vorhanden. Darin liegen offenbar eine Menge juristischer Fallstricke, mal von den ganzen Lizenzverletzungen abgesehen. Beim Mediatek-OpenWRT kann man zwar ebenso am Kerneltreiber manipulieren, aber es ist einigermassen getrennt vom Userspace, so kann man als "Inverkehrsbringer" immerhin gut nachweisen, dass man den Originaltreiber verwendet. Vielleicht war das die Idee beim ESP32, einfach durch einen zweiten Kern einen "userspace" zu schaffen. Bringt nur nicht viel, wenn das gesamte Software-Framework schon broken by design ist..
Markus schrieb: > Wenn ich es richtig weiß, ist eine FCC-Zulassung auf einem Bauteil im > Gerät sowieso nutzlos weil immer das gesamte Gerät mit dem letzten > Softwarestand abgenommen werden muss. D.h. Du kannst zwar ein > Funkinterface mit Zulassung einbauen, musst aber trotzdem eine > Zulassungsprüfung für das Gesamtgerät machen. > Mein Idee dazu ist: Ein Gerät mit Linux Kern bauen und einen WIFI-Stick > in die Verpackung dazu legen. Afaik reicht bei vorzertifizierten Funkmodulen eine normale CE/EMV Prüfung. Wird der WiFi Stick dem Gerät beigelegt gehört er zum Gerät und muss bei der Prüfung mit geprüft werden, muss der Kunde ihn gesondert bestellen als normaler WiFi Stick ohne Bezeichnung "WiFi Modul für Gerät XY" kann man dies auch umgehen, solch ein Problem hatten wir schon mal, ich weiß bloß leider nicht mehr für welches Land/Norm dies notwendig war.
Gerd E. schrieb: > Ich glaube strubi meinte eher etwas in diese Richtung: > https://www.seeedstudio.com/LinkIt-Smart-7688-p-2573.html Strubi schrieb: > 45? Also für die LinkIt-Module bezahlst du normalerweise unter 10 USD in > Einzelstückzahlen Danke für den Link. Als ich den Namen gestern bei Google eingegeben habe, wurden mir Boards angezeigt, die alle bei knapp 40 $ zzgl. Versand lagen. Unter 10 $ klingt ja schon ganz anders. Ein Node-MCU mit dem ESP8266, also Board mit herausgeführten Pins fürs Breadboard, kostet effektiv ja auch 6 $ um den Dreh.
André R. schrieb: > Unter 10 $ klingt ja schon ganz anders. Ein Node-MCU mit dem > ESP8266, also Board mit herausgeführten Pins fürs Breadboard, kostet > effektiv ja auch 6 $ um den Dreh. Ein ESP Modul wie der ESP-12, das sich beliebig leicht selbst von Grobmotorikern auflöten läßt, kost rund $1,60. Da hängt die ESP-Latte https://www.aliexpress.com/item/Elecrow-ESP-12F-Wifi-Module-ESP8266-Remote-Serial-Port-WIFI-Smaller-Package-Size-Tensilica-L106-Industry/32776298599.html?spm=2114.search0104.3.26.FPliMk&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_5490020_10068_10194_5430020_5410020_10304_10307_10137_10060_10155_10154_10333_10334_10056_5370011_10335_10055_10336_10054_10059_10332_100031_10099_5400020_10103_10102_10052_10053_10050_10107_10142_10051_10320_10321_10325_5380020_10326_10084_10083_10080_10082_10081_10177_10110_10111_10112_10113_5390011_10114_10180_10312_10313_10314_10184_10316_10078_10079_10073_10186_5420011-10177_10333_10110,searchweb201603_1,ppcSwitch_5&btsid=5775cafa-a2cb-4c5a-ae67-29fa1443e29e&algo_expid=210fe54a-14cb-4841-bb33-80573cb1cd57-3&algo_pvid=210fe54a-14cb-4841-bb33-80573cb1cd57 MfG Klaus
guten morgen, André R. schrieb: > Ein Node-MCU mit dem > ESP8266, also Board mit herausgeführten Pins fürs Breadboard, kostet > effektiv ja auch 6 $ um den Dreh. jfyi: die nodemcu kosten aktuell ca. $2.60 inkl. versand aus china. gruss, -- randy
Oh, da sind dann meine Preise nicht mehr ganz auf dem Stand der Dinge. Ist schon unglaublich günstig, das Zeugs. 1,55 $ für das obige Angebot, das sind momentan 1,29 €.
Ich hatte hier selber schonmal das SDK des ESP32 als "haaresträubend" bezeichnet und in manchen Belangen ist es tatsächlich so. Ich muss aber fairerweise sagen, dass es nicht in allen Belangen so ist. Ich würde es irgendwo zwischen "unausgegoren" und "es fehlt der letzte Feinschliff" einordnen. Die grundsätzlichen Funktionen sind aber alle sehr stabil. Wifi funktioniert bisher tadellos und Schnittstellen wie SPI, I2C oder UART machen auch keine Probleme. Mit BLE habe ich noch keine persönlichen Erfahrungen gesammelt. Ich finde man muss die Sache ganz nüchtern betrachten. Preis und Verfügbarkeit des ESP32 sind sehr gut und der Standby-Verbrauch von 5uA kann sich ebenfalls sehen lassen. Das SDK ist brauchbar, könnte aber besser sein, was es aber auch täglich wird. Einen Vergleich mit dem ESP8266 finde ich nicht wirklich angebracht. Sowohl was die Hardware, als auch was die Software und das Ökosystem drum herum angeht spielt der ESP32 in einer ganz anderen Liga. Ob man den Chip nun "professionell" einsetzen sollte oder nicht kommt meiner Meinung nach ganz stark auf die individuellen Anforderungen an. Die Frage ist vor allem was man denn für Alternativen hat und was die können oder eben nicht können bzw. was diese kosten. Die CC3220 von TI sehen recht interessant aus und sind auch als Modul verfügbar. Die Wizard Geckos von Silabs könnten ebenfalls etwas taugen. Beide haben aber meines Wissens nach z.B. kein BLE, was aber auch nicht schlimm ist, wenn man es denn nicht braucht. Eine Lösung mit OpenWRT würde ich nur in Betracht ziehen, sofern man die Vorteile die man mit Linux bekommt auch nutzen kann und man sich bewusst ist, dass man so ein System auch pflegen muss, weil das Produkt nämlich ansonsten auch schnell Teil eines Botnetzes werden kann, wie Abermillionen IP-Cameras und digitale Videorekorder beweisen.
Christopher J. schrieb: > Eine Lösung mit OpenWRT würde ich nur in > Betracht ziehen, sofern man die Vorteile die man mit Linux bekommt auch > nutzen kann und man sich bewusst ist, dass man so ein System auch > pflegen muss, weil das Produkt nämlich ansonsten auch schnell Teil eines > Botnetzes werden kann, wie Abermillionen IP-Cameras und digitale > Videorekorder beweisen. Bei einer Lösung mit ESP32 bist Du das Thema Sicherheit nicht los, sondern Du musst es auch teilweise selbst angehen und teilweise musst Du dich auf Espressiv verlassen und kannst es gar nicht selbst lösen, da es in deren Binaries ist. Das sehe ich eher als deutlichen Nachteil des ESP32. Denn während ich das OpenWRT vollständig im Source vorliegen habe und ein Sicherheitsproblem auch in 5 Jahren noch selbst patchen kann, kann es sein daß es Espressiv in 5 Jahren gar nicht mehr gibt oder die sich dann nur noch um den ESP64 kümmern und denen der ESP32 und seine Sicherheitslücken nicht mehr interessieren. Auch wenn jemand nicht in der Lage sein sollte das OpenWRT selbst zu patchen, so gibt es genug Selbständige die das können und die man für einen überschaubaren Betrag sowas machen lassen kann. Ein Sicherheitsproblem aus einem binary Blob wie beim ESP32 rauszupatchen ist dagegen eine ganz andere Liga, durch den eher ungewöhlichen Tensilica-Core nochmal ganz besonders.
Ich gebe dir Recht, dass das Thema Sicherheit ganz eng mit dem Vertrauen in den Hersteller verbandelt ist. Blobs hasse ich selber wie die Pest, die hat man allerdings durchaus auch bei Linux, vor allem im Treiberbereich. Bei vielen Geräten (vor allem bei Android-Handys) ist das der Grund warum man keinen neueren Kernel bekommt. Da hat man aber als Normalsterblicher auch keine Chance etwas zu machen. Reversing des Treibers und Anpassung auf neuen Kernel? So etwas gibt es nicht für kleines Geld zu haben. Immerhin hat der ESP32 deutlich weniger Blobs als sein Vorgänger. Wären es Null wäre es mir persönlich natürlich lieber aber selbst da müsste man die Vertrauensfrage stellen. TI redet beim CC3220 schon direkt von "ROM-based" Wifi-Coprocessor. Da Frage ich mich ob die tatsächlich den Netzwerkstack in OTP-Flash gegossen haben. Von den Produktionskosten her würde es sicher Sinn machen aber wenn dem so sein sollte, dann gute Nacht wenn es da mal einen Exploit gibt.
Gerd E. schrieb: > Bei einer Lösung mit ESP32 bist Du das Thema Sicherheit nicht los, > sondern Du musst es auch teilweise selbst angehen und teilweise musst Du > dich auf Espressiv verlassen und kannst es gar nicht selbst lösen, da es > in deren Binaries ist. Da gabs zumindest beim ESP8266 eine Menge Böcke in den Libraries und im ROM, um das System von aussen abzuschiessen, Buffer Exploits habe ich mit dem xtensa erst gar nicht versucht. Dazu kommt, dass das System keine effektive MMU/Kernel protection hat, d.h. potentiellen Zugriff auf alles. Bei OpenWRT sind's eher die unbeschwerten User, die mal eben einen unsicheren Service installieren, oder die Service-Passwörter herumleaken, gross Magie ist in so nem IoT-Botnetz nicht. Sonst ist mein Vertrauen in die prinzipielle Härte eines MIPS-basierenden OpenWRT-Router ziemlich gross, wenngleich man beim closed Wifi-Teil auch nur eben vertrauen kann, auch da wäre nicht ausgeschlossen, dass illegale Radiopakete Kernelspace-Zugang verschaffen könen. Schlussendlich ist es eine Frage der wahrgenommenen MTBF oder des empirischen Honeypot-Tests.
Martin S. schrieb: > Sonst ist mein > Vertrauen in die prinzipielle Härte eines MIPS-basierenden > OpenWRT-Router ziemlich gross, wenngleich man beim closed Wifi-Teil auch > nur eben vertrauen kann, auch da wäre nicht ausgeschlossen, dass > illegale Radiopakete Kernelspace-Zugang verschaffen könen. Klar, siehe Broadcom. Aber zumindest für die MT7688 gibt es soweit ich weiß hier auch Opensource-Treiber von Mediatek: http://www.openwrtdl.com/wordpress/mt76xx-p4rev%E7%B3%BB%E5%88%97%E4%B8%8B%E8%BD%BD Ich hab diese jetzt bei mir noch nicht ausprobiert, aber sieht aus als würden die passen. Dann kannst Du die Mediateks komplett ohne fremde Blobs verwenden.
Hier ist einer der Entwickler im Interview: https://blog.squix.org/2017/02/interview-with-espressifs-ivan-grokhotkov.html
Das bringt alles nichts wenn du plötzlich feststellst das es sich mit einigen APs nicht verbindet lässt oder es extrem lange dauert -> Assoc Fail . wie immer eine Lösung ist nicht in Sicht. Wenn du wirklich das Ding professionell einsetzen willst kannst du deinen Anwendern erklären warum eine Verbindung nicht möglich ist. Deswegen habe ich es auch fast aufgeben das MQTT Projekt auf den ESP weiter zu zu entwickeln. Der winc1500 machte da eine bessere Figur, der konnte auch mehr messages verarbeiten. Das RTOS lässt nicht mehr viel übrig für umfassende Anwendungen. Das Problem dabei ist auch das viele Funktionen die Anwendung blockieren. Call Back Möglichkeiten z.Bsp des lwIP sind durch das IDF schon verwendet und lassen nach Außen wenig Spielraum. Der ESP ist zwar deutlich günstiger aber benötigt auch mehr Strom, Problematiken wie deep sleep wo auch das wlan betroffen ist da sich der ESP nicht mehr mit dem AP verbindet wenn er aufwacht geben das ganze den Rest.
:
Bearbeitet durch User
und wer sich mit dem Thema beschäftigen will dem ist folgende Literatur zu empfehlen. https://leanpub.com/kolban-ESP32
Also der Code muss immer schlimmer werden ;) Gestern habe ich mal meine IDF auf den neusten stand gebracht und der ESP schmierte sofort ab. Das Problem liegt irrend wo in der u8g2 lib .. Da muss ich nochmal forschen. Zumindest mein MQTT Stack lieft ohne Probleme...
Ich habe gerade zum ersten Mal mit dem ESP32 zu tun und bei aktuellem Stand ist das Bluetooth SPP Profil des IDF Frameworks defakto unbrauchbar... zumindest wenn man auf eine stabile Datenübertragung angewiesen ist.
Vincent H. schrieb: > Ich habe gerade zum ersten Mal mit dem ESP32 zu tun und bei aktuellem > Stand ist das Bluetooth SPP Profil des IDF Frameworks defakto > unbrauchbar... zumindest wenn man auf eine stabile Datenübertragung > angewiesen ist. Was ist für Dich "aktuell"? 3.1 stable oder 3.2dev?
3.1 stable Über folgendes Problem bin ich gestolpert: https://www.esp32.com/viewtopic.php?t=5613 Der Workaround aus Kommentar #2 funktioniert nachwievor und ermöglicht auch hohe Datenraten zu fahren.
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.