Forum: Mikrocontroller und Digitale Elektronik Neue Espressif-Funkmodule mit RISC-V-Prozessoren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christoph B. (birki2k)


Angehängte Dateien:

Bewertung
9 lesenswert
nicht lesenswert

Kommenden Monat sollen zwei neue miniaturisierte Funkmodelle von Espressif mit RISC-V-Prozessoren verfügbar werden. Zudem sind nun Informationen über einen pinkompatiblen Nachfolger des ESP8266 bekannt geworden.

Die neuen ESP32-S2-MINI Module wird es in zwei Varianten geben, einmal mit integrierter PCB-Antenne und einmal mit IPEX-Konnektor zum Anschluss einer externen Antenne. Dabei kommen die Module so auf eine Fläche von 14,4 mm x 20 mm respektive 14,4 mm x 15,4 mm. Als SoC kommt der ESP32-S2FH4 zum Einsatz, welcher über einen mit 240 MHz getakteten LX7-Prozessor in Kombination mit einem stromsparenden RISC-V-basierenden Koprozessor verfügt. Die Module mit 2,4 GHz-WLAN und Bluetooth verfügen über 4  MB Flash-Speicher und eine Vielzahl an Schnittstellen, darunter USB OTG, SPI, I2S, UART, I2C, Kameraschnittstelle und bis zu 43 GPIOs. Zusätzlich sind neben ADC und DAC ein Temperatur- und Berührungssensor vorhanden.

Der Nachfolger im klassischem ESP8266-Formfaktor soll demnächst in Form des ESP32-C3 kommen, auf cnx-software.com wurde hierzu ein vorläufiges Datenblatt verlinkt. Wie bereits spekuliert wurde, kommt bei dem ESP32-C3 ausschließlich ein 32-bit RISC-V-basierender Einkernprozessor zum Einsatz, der mit 160 MHz getaktet ist. Aufgrund der Rückwärtskompatibilität sind die GPIOs auf 22 begrenzt, wobei wichtige Schnittstellen wie SPI, I2C, UART und I2S ebenfalls abgedeckt werden. Darüber hinaus gibt es neben einem Temperatursensor und zwei ADC-Kanälen ein USB 1.1 Interface mit UART- und JTAG-Funktionalität.

In beiden Fällen zeigen die neuen Funkmodule eine weitere Verbreitung der RISC-V-Architektur und dürften den derzeit günstigsten Einstieg in RISC-V-basierte Hardware bieten.

Bild: Espressif


von Datenblat fehlt (Gast)


Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
WTF, warum müssen die das RISC-V Teil wieder ESP32 nennen?

von Nick M. (muellernick)


Bewertung
0 lesenswert
nicht lesenswert
Datenblat fehlt schrieb:
> WTF, warum müssen die das RISC-V Teil wieder ESP32 nennen?

Damit sie die unbrauchbare Doku vom ESP8266 weiterverwenden können?

von Stefan ⛄ F. (stefanus)


Bewertung
-4 lesenswert
nicht lesenswert
Ich finde den ESP8266 als Kommunikations-Co-Prozessor für einen anderen 
Mikrocontroller als Kern meiner Anwendung wesentlich attraktiver.

Für so einen Co-Prozessor brauche ich keinen ESP32 - egal welche 
Variante.

Und für simple Anwendungen (Ferngesteuerte Steckdose, Wetterstation, 
etc.) reicht der ESP8266 sowieso.

Da bleibe ich lieber beim ESP8266 in den ich mich mit viel Mühe 
eingearbeitet habe. Da weiß ich wenigstens, dass meine Programme 
zuverlässig laufen und wie ich die HW stabil betreibe.

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
3 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Und für simple Anwendungen (Ferngesteuerte Steckdose, Wetterstation,
> etc.) reicht der ESP8266 sowieso.

Naja, gerade am Beispiel Wetterstation sehe ich definitiv die Vorteile 
von BLE und einem Co-Prozessor (so lange das ganze per Batterie versorgt 
wird). Natürlich kann man seinen eigenen Co-Prozessor einsetzen und wenn 
es nur ein ATTiny ist aber man kann den sich auch sparen. Der ESP8266 
hatte jedenfalls sehr große Defizite, wie etwa ein fehlendes 
Hardware-I2C-Interface. Der ESP32 ist da erstmal in einer ganz anderen 
Liga. Dessen DMA- und Pin-MUX würde ich mir bei so manch anderem 
Controller wünschen.

In dem Sinne, das ein ESP8266 "sowieso für eine Funksteckdose" reicht 
dürfte wohl auch die Begründung liegen, den ESP32-C3 pinkompatibel zum 
8266 zu halten. Die Hersteller von irgendwelchen Funksteckdosen, etc., 
müssen dann "nur" den alten Chip durch den neuen ersetzen, die Firmware 
anpassen und schon kann deren Gerät nicht nur WLAN, sondern auch 
Bluetooth. Ein redesign der Hardware entfällt komplett.

Das Espressif nun endgültig auf den RISC-V-Zug aufspringt halte ich nur 
für logisch. Dass sie keine eigene Toolchain mehr pflegen müssen und 
nebenbei noch die Lizenzgebühren für den Xtensa-Kern sparen, dürfte für 
die wohl Grund genug sein auf RV umzustellen. Für den Anwender gibt es 
dabei automatisch besseren Support für Debug-Hardware oder etwa 
bestehende RTOS.

von Kling (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Das liest sich doch ziemlich gut. Ich hoffe die Dev-Boards von Wemos und 
Co. kommen dann endlich auch mal mit USB-C-Buchsen...

von Seppel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Jo,

warum nicht komplett RISC-V?

Grüsse, Seppel

von Schorschi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sieht gut aus.. Das Problem beim ESP8266 ist ja dessen stromverbrauch...

Mit RISC-V kommt wenigstens die Möglichkeit, den MCU mit Rust zu 
programmieren :)

von Schorschi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christoph B. schrieb:
> Der Nachfolger im klassischem ESP8266-Formfaktor soll demnächst in Form
> des ESP32-C3 kommen, auf cnx-software.com wurde hierzu ein vorläufiges
> Datenblatt verlinkt.

Zumindest bei diesem.

von Arduino Fanboy D. (ufuf)


Bewertung
4 lesenswert
nicht lesenswert
Dass die Chinesen voll auf den RISC-V Zug aufspringen ist nur natürlich.

Da ihnen die neueren ARM Entwicklungen vorenthalten werden, müssen sie 
sich "wandeln".

Ich prophezeie:
Wir werden demnächst eine große Anzahl an Händis und Tablets mit RISC-V 
Innereien auf dem Weltmarkt sehen.
Es ist wohl nur eine Frage der Zeit, wann ARM ins Hintertreffen gerät.

Der Trumpismus hat eine alte Schachstrategie übersehen:
> Zwinge niemals einen Gegner zu einem guten Zug!
Die Rollen werden sich ändern.
Vom Hinterherhechler zum Vorreiter.

: Bearbeitet durch User
von John Doe (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Dass die Chinesen voll auf den RISC-V Zug aufspringen ist nur natürlich.
>
> Da ihnen die neueren ARM Entwicklungen vorenthalten werden, müssen sie
> sich "wandeln".
>
> Der Trumpismus hat eine alte Schachstrategie übersehen:


Das hat doch mit Trump nichts zu tun.
Die Inder setzen auch voll auf RISC-V, die Russen steigen auch gerade 
ein und sogar die sonst so träge EU setzt darauf im HPC-Bereich, 
wenngleich in der ersten Version noch als Vektor-Prozessor neben einem 
ARM-Kern als Hauptprozessor. Der Nachfolger dürfte aber schon ein reines 
RISC-V Design sein.

RISC-V bietet einfach zu viele Vorteil gegenüber dem ARM-Konzept.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
John Doe schrieb:
> Das hat doch mit Trump nichts zu tun.
Doch...
Vorher war RISC-V eine Option.
Der Trumpismus hat daraus jetzt eher einen Zwang gemacht.

John Doe schrieb:
> Die Inder setzen auch voll auf RISC-V,
usw.
Natürlich....
Dürfen sie, alle.
Aber einzig die Chinesen haben die Fähigkeit das innerhalb kurzer Zeit 
mit einer immensen Macht am Markt zu platzieren.

Beispiel:
https://canaan.io/product/kendryteai
K210 Boards, für Bastler, sind für wenige Euronen zu erwerben.

Wie sich das entwickelt, bleibt abzuwarten.
Aber so weit ist bisher sonst noch keiner.

: Bearbeitet durch User
von abc (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Was leiste ich mir heute schönes? Entweder drei Tomaten für eine kleine 
Schüssel Tomatensalat oder ein Funkmodul mit WLAN,BLE, 160MHz Kern, 
diverser Peripherie und 400 kByte SRAM inkl. Transport über 8000 km?

Träne_aus_dem_Gesicht_wisch

John Doe schrieb:
> und sogar die sonst so träge EU setzt darauf im HPC-Bereich

Das Thema EU ist im Großen erledigt. Vor langer Zeit falsch abgebogen.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Wir werden demnächst eine große Anzahl an Händis und Tablets
> mit RISC-V Innereien auf dem Weltmarkt sehen.

Bisher habe ich im Android-Quelltext noch nichts von RISC-V gesehen. 
Wenn dort der Support auftaucht, ist das Thema ARM endgültig durch, 
denke ich.

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Bisher habe ich im Android-Quelltext noch nichts von RISC-V gesehen.

Auch an der Stelle haben die Trumpisten dem Chinaland feste auf die Füße 
getreten.
Keinen Zugang mehr zum AppStore usw.

Meine Prognose:
Ein Grund mehr ein eigenes OS zu entwickeln.
Quasi aus Selbsterhaltungstrieb.

Und dann:
S. R. schrieb:
> ist das Thema ARM endgültig durch,
> denke ich.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
>> Bisher habe ich im Android-Quelltext noch nichts von RISC-V gesehen.
>
> Auch an der Stelle haben Trumpisten dem Chinaland feste auf die Füße
> getreten. Keinen Zugang mehr zum AppStore usw.

Das ist hier irrelevant, weil es diesen Zugang auch vorher schon nicht 
gab. In/Für China verkaufte Android-Geräte benutzen schon lange 
Alternativen für GMS. Außerdem ist der Teil von Android ohnehin 
portabel, weil Java oder Kotlin.

Interessant ist die Portierung von AOSP auf RISC-V: Die Plattform, die 
meisten HALs und die Runtime sind alles C++. Als erstes müsste im Code 
also die passende Toolchain auftauchen (die ist bei Android immer ein 
prebuilt).

Aber solange es keine halbwegs verbreiteten High-Performance-RISC-V 
gibt, wird sich da nichts tun, denke ich. Das meiste ist ja auf 
STM32-Niveau oder knapp drüber.

von abc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> S. R. schrieb:
>> Bisher habe ich im Android-Quelltext noch nichts von RISC-V gesehen.
>
> Auch an der Stelle haben die Trumpisten dem Chinaland feste auf die Füße
> getreten.
> Keinen Zugang mehr zum AppStore usw.

China hatte schon immer ohnehin lieber ihre eigenen Dienste, weil sich 
die Westlichen nicht gut genug kontrollieren und zensieren lassen.

> Meine Prognose:
> Ein Grund mehr ein eigenes OS zu entwickeln.
> Quasi aus Selbsterhaltungstrieb.

Ein passender Fenster-Manager oder Fenster-Manager-Aufsatz für Linux 
genügt.

Das Theater ist eher mit den Treibern. Ein eigenes OS macht das nicht 
besser sondern schlimmer.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
> Ein passender Fenster-Manager oder
> Fenster-Manager-Aufsatz für Linux genügt.

Äh, nein. Leider nicht. Zwischen "Linux" und "Android" gibt es große 
Unterschiede. Leider auch aus guten Gründen.

von abc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> abc schrieb:
>> Ein passender Fenster-Manager oder
>> Fenster-Manager-Aufsatz für Linux genügt.
>
> Äh, nein. Leider nicht. Zwischen "Linux" und "Android" gibt es große
> Unterschiede. Leider auch aus guten Gründen.

Fanboy hatte geschrieben, China möge ein eigenes OS entwickeln. Und dazu 
meine ich schon, dass sie das lassen können und auf Linux aufsetzen 
können.

Denn ein wesentliches Problem von Android sind die Treiber. Dieses 
Problem ist mit einem komplett neuen Betriebssystem noch größer.

Ja, zwischen Android und Linux gibt es große Unterschiede. Der 
ursprüngliche Grund für Android damals war aber mangelnde Performance 
eines Smartphones für den Betrieb eines kompletten Linux. Das Problem 
gibt es heute fast nicht mehr. Heute hält das Ökosystem mit den ganzen 
Apps und APIs vom Wechsel auf Linux ab. Aber wenn man ja gerade auf das 
(westliche) Ökosystem verzichten will oder muss, dann kann man sich das 
ganze Geraffel drum herum auch gleich mit sparen. Auf jeden Fall bringt 
noch ein OS nix.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
> Auf jeden Fall bringt noch ein OS nix.
Aus Anwendersicht, sicherlich richtig....
Schätze aber mal, dass das Eisen längst in der Schmiede auf dem Ambos 
liegt.
Und wenn es auch auf Linux basiert...

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
Schorschi schrieb:
> Sieht gut aus.. Das Problem beim ESP8266 ist ja dessen
> stromverbrauch...
>
> Mit RISC-V kommt wenigstens die Möglichkeit, den MCU mit Rust zu
> programmieren :)

FULLACK!!!

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Schorschi schrieb:
> Mit RISC-V kommt wenigstens die Möglichkeit, den MCU mit Rust zu
> programmieren :)

Da freue ich mich tatsächlich auch schon sehr drauf :)

Der RTOS-Support für den ESP-32 (egal ob Xtensa oder RV) wird auch immer 
besser. Mittlerweile gibt es etwa neben FreeRTOS noch RIOT und Zephyr, 
die den ESP32 samt Wifi-Stack unterstützen. Ein ESP32-C3 mit Zephyr und 
Rust wäre schon nahe an dem, was mir so als optimale 
Entwicklungsumgebung vorschwebt ;)

S. R. schrieb:
> Bisher habe ich im Android-Quelltext noch nichts von RISC-V gesehen.
> Wenn dort der Support auftaucht, ist das Thema ARM endgültig durch,
> denke ich.

So schnell würde ich ARM nicht abschreiben, weil auch RISC-V nicht 
vollkommen ist aber es würde mich schon ein bisschen wundern, wenn nicht 
gerade jetzt, nachdem ARM von Nvidia geschluckt wurde, bei den großen 
Prozessorherstellern wie Samsung oder Qualcomm alle Warnlampen angehen 
und die Entwicklungen für eigene RV-Designs auf hochtouren laufen. Wenn 
einer von denen mit einem neuen RISC-V-Prozessor auf den Markt drängt, 
dann wird der ganze Stein auch sehr schnell ins rollen kommen. Dafür 
werden die Hersteller dann schon selbst sorgen.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Dafür
> werden die Hersteller dann schon selbst sorgen.

Nicht vergessen, dass Trump dafür auch noch ein Katalysator war.

Ganz China wird bald auf RISC-V umschwenken.

von dunky (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wie waren denn so eure Erfahrungen mit der ESP32 Entwicklung?

Also in Theorie war das alles nett, aber ich fand es mit dem IDF zum 
kotzen. Alle Nase lang irgendwelche obskuren Bugs. Dann wieder im Forum 
schauen...ja also mit dem OpenOCD geht dies nicht...musst Version xy 
nehmen...die läuft so einigermaßen. Dann geht das damit nicht.
Oh, hier mal wieder ein Update von userem Eclipse Plugin...wieder Haufen 
Scheißfehler und mit jedem gefixten Bug entweder 2 neue oder irgendein 
längst behobener Bug poppt wieder auf.
2 Wochen nix gemacht...wieder haufen IDF Patches...erstmal geht wieder 
nix. Mein Eindruck war, dass die ein echt sehr bescheidenes 
Qualitätsmanagment haben.

Und ja...das ganze debugging fand ich immer arg wackelig(mag aber auch 
an meinem Setup gelegen haben...hatte ein FT232H mit fliegender 
Verdrathung)

Womit habt ihr denn so entwickelt & gute Erfahrungen gemacht? Gerade 
beim Debuggen

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
dunky schrieb:
> Womit habt ihr denn so entwickelt & gute Erfahrungen gemacht? Gerade
> beim Debuggen

Auf RISC-V benutze ich die Eclipse + GnuARM + GDB + OpenOCD.

Hatte mich vor einem Jahr echt überrascht, dass GnuARM aktiv RISC-V 
unterstützt!

Gibt eine fertige Binärdistribution von Eclipse mit GnuARM - läuft out 
of the box wunderbar.

Nur für Rust bin ich jetzt noch am suchen ... Das schein in Eclipse noch 
nicht so gut integriert zu sein wie CDT.

: Bearbeitet durch User
von Mürbe (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Mampf F. schrieb:

> Ganz China wird bald auf RISC-V umschwenken.

Und wenn nicht, dann wird euch Mampf einfach ein neues Märchen 
erzählen.

von Mampf F. (mampf) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Mürbe schrieb:
> Mampf F. schrieb:
>
>> Ganz China wird bald auf RISC-V umschwenken.
>
> Und wenn nicht, dann wird euch Mampf einfach ein neues Märchen
> erzählen.

Schade, dass du dich hinter einem Gast-Account versteckst, sonst hätte 
ich dir das gerne in 2 Jahren unter die Nase gerieben ;-)

Es gibt auch schon einen RISC-V basierten AllWinner - wo kommen die 
nochmal her? Ach ja aus China ;-)

Und AllWinner ist keine kleine Garaschen-Klitsche.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
>> Äh, nein. Leider nicht. Zwischen "Linux" und "Android" gibt es große
>> Unterschiede. Leider auch aus guten Gründen.
>
> Denn ein wesentliches Problem von Android sind die Treiber. Dieses
> Problem ist mit einem komplett neuen Betriebssystem noch größer.

Das betrifft die chinesischen Hersteller nur begrenzt, denn die 
entwickeln sowohl die Hardware als auch die Software vor Ort.

In die Opensource-Treiber reinschauen kann man auch, und wenn man es mit 
den Lizenzen einigermaßen ernst nimmt, dann gibt es da auch die BSDs.

> Der ursprüngliche Grund für Android damals war aber mangelnde
> Performance eines Smartphones für den Betrieb eines kompletten Linux.

Das kann ich mir nicht so recht vorstellen, z.B. war der Sharp Zaurus 
durchaus relevant und nicht langsam. Problematisch ist, dass die zu 
Linux passende Infrastruktur für Smartphones ungeeignet ist - das fängt 
bei X11 an und hört bei besonderer Hardware für besondere Zwecke (z.B. 
komplexen Kamerachips, siehe "libcamera") noch lange nicht auf.

Android hat APIs geschafft, die einerseits POSIX über den Haufen werfen, 
andererseits aber solche Seltsamkeiten überhaupt erst 
anwendungsübergreifend nutzbar zu machen. Komplexe Kameras sind unter 
Linux noch immer nicht ordentlich nutzbar - und es gibt keine 
Möglichkeit für Hersteller, ihre Differentiatoren da einzubauen.

Ich kann mir gut vorstellen, dass die Chinesen von westlicher Technik - 
inklusive Linux - erstmal wegkommen wollen. So viel anders als Google 
ist das auch nicht, denen ist die GPL ein Dorn im Auge; wenn sie 
könnten, würden sie Linux auch rauswerfen.

Christopher J. schrieb:
> So schnell würde ich ARM nicht abschreiben, ...

Davon gehe ich auch aus. Allerdings halte ich es für wahrscheinlich, 
dass die noch auf die Vektorerweiterung warten.

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> So viel anders als Google
> ist das auch nicht, denen ist die GPL ein Dorn im Auge; wenn sie
> könnten, würden sie Linux auch rauswerfen.

Da war doch was... Achja Fuchsia hiess das. Während man vor 3-4 Jahren 
einige News immer wieder las, ist das wohl aus der Öffentlichkeit 
verschwunden. Leben tuts anscheinend noch: https://fuchsia.dev/

Bin ja gespannt ob das mal noch produktiv zum Einsatz kommt.

von abc (Gast)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> abc schrieb:
>>> Äh, nein. Leider nicht. Zwischen "Linux" und "Android" gibt es große
>>> Unterschiede. Leider auch aus guten Gründen.
>>
>> Denn ein wesentliches Problem von Android sind die Treiber. Dieses
>> Problem ist mit einem komplett neuen Betriebssystem noch größer.
>
> Das betrifft die chinesischen Hersteller nur begrenzt, denn die
> entwickeln sowohl die Hardware als auch die Software vor Ort.

Sieht man ja, wie gut das Allwinner und Konsorten funktioniert.

>> Der ursprüngliche Grund für Android damals war aber mangelnde
>> Performance eines Smartphones für den Betrieb eines kompletten Linux.
>
> Das kann ich mir nicht so recht vorstellen

Dann schau Dir noch mal an, was zum damaligen Zeitpunkt an CPUs 
verfügbar war und wie lang damit ein in der Hand tragbarer Akku mit 
Linux gehalten hat.

> Problematisch ist, dass die zu
> Linux passende Infrastruktur für Smartphones ungeeignet ist - das fängt
> bei X11 an und hört bei besonderer Hardware für besondere Zwecke (z.B.
> komplexen Kamerachips, siehe "libcamera") noch lange nicht auf.
> [...]
> Komplexe Kameras sind unter
> Linux noch immer nicht ordentlich nutzbar - und es gibt keine
> Möglichkeit für Hersteller, ihre Differentiatoren da einzubauen.


Bevor es Android gab, traf das auf Android auch alles zu; weil: Android 
gab es ja noch nicht. So ist es mit Linux auch. Henne-Ei. Der Grund, 
dass es das für Linux nicht gibt, ist nicht der, dass es nicht ginge. Es 
hat eben bisher keiner gemacht.

Die Tausend und eine API bei Android gibt es, weil es mit den 
Möglichkeiten der CPUs und Akkus gewachsen ist. Das heutige schnelle, 
flüssige Scrollen, H264-Full-HD-Videowiedergabe, Applikationen laufen im 
Hintergrund, Animationen beim Fenster wischen, Gesichtserkennung, und so 
weiter und so fort. Für all das und vieles mehr gab's damals die 
Hardware gar nicht verfügbar zu für die Masse akzeptablen Preisen und 
Akkulaufzeiten. Und für das Cloud-Zeug waren die Netze zu langsam.
Und so gibt es bei Android immer wieder neue APIs wenn die Hardware von 
genügend Geräten inzwischen schnell genug geworden ist für das nächste 
Feature xyz.

Für das Ganze Geraffel ist abgesehen von ein klein wenig Algorithmen bei 
der Bildverarbeitung kaum etwas Smartphone-spezifisches passiert und 
bzgl. der Bedienkonzepte auch nicht.

Die große Kunst (Innovation) ist es, den Kram zur richtigen Zeit auf den 
richtigen Geräten heraus zu bringen und zu vermarkten. Und vor allem hat 
mit der zunehmenden Menge der Preis skaliert. Das war die wesentliche 
Innovation.


Und beim ESP8266/32 gibt es auch keine Innovation. Die Peripherie ist 
vergleichsweise schlecht. Doku sowieso. Derartige Gesamtpakete gibt es 
schon lange und in viel besser. Bis auf eine Kleinigkeit: Der Preis. Und 
schwups, schau Dir an, was das alles ausgelöst hat und auslöst.


> Ich kann mir gut vorstellen, dass die Chinesen von westlicher Technik -
> inklusive Linux - erstmal wegkommen wollen.

Die sind froh, dass es gcc und opensource gibt.

> So viel anders als Google
> ist das auch nicht, denen ist die GPL ein Dorn im Auge; wenn sie
> könnten, würden sie Linux auch rauswerfen.

Und warum haben die Chinesen dann auf Risc-V gewartet, wenn sie die 
ganze kostenlose Infrastruktur bis hin zum Betriebssystem auch selbst 
gern stemmen könnten? So kompliziert ist der Entwurf einer ISA, die 
nicht weltweit kompatibel zu sein braucht und keinen gemeinsamen Nenner 
braucht, nun auch wieder nicht. Die Arbeit steckt in der Infrastruktur 
bis hin zum Betriebssystem-Support.

von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
abc schrieb:
> Und beim ESP8266/32 gibt es auch keine Innovation. Die Peripherie ist
> vergleichsweise schlecht. Doku sowieso. Derartige Gesamtpakete gibt es
> schon lange und in viel besser. Bis auf eine Kleinigkeit: Der Preis.

In meinen Augen hat Espressif vom ESP8266 zum ESP32 einen riesigen 
Schritt getan und zwar was Hardware, Software und die Dokumentation dazu 
angeht. Aus einem Controller, der eigentlich nur durch reversing von ein 
paar Nerds eigenständig nutzbar gemacht wurde, wo es Binary-Blobs für 
alles und jedes gab und die Doku den Namen nicht verdient hatte hin zum 
ESP32, mit quelloffenem SDK, enorm verbesserter Peripherie (I2C, I2S, 
CAN, Bluetooth, etc.) und einer Doku, die zumindest halbwegs brauchbar 
ist.

Wenn man bedenkt, dass Espressif kein Multimilliarden-Großkonzern wie 
NXP oder TI ist, sondern eine kleine "Klitsche" mit 50 Mann (war bei 
ESP32 Release meine ich so könnten jetzt durchaus mehr sein), dann 
nötigt mir das jedenfalls einiges an Respekt ab.

Wo wir bei "es gibt viel bessere Alternativen" wären. Wo sind die ganzen 
MCUs, die sowohl WLAN, als auch Bluetooth bieten und eine so viel 
bessere Peripherie und Doku haben? Ich kenne da nichts, lasse mich aber 
gerne aufklären.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
es gibt RTL8170 oder RTL8195 mit ARM statt Xtensa Kern, aber zumindest 
in der Hobbywelt sind die sogut wie garnicht zu finden.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Wo sind die ganzen
> MCUs, die sowohl WLAN, als auch Bluetooth bieten und eine so viel
> bessere Peripherie und Doku haben? Ich kenne da nichts, lasse mich aber
> gerne aufklären.

Da hätte ich spontan auf Nordic getippt. Zumindest Bluetooth mit 
ARM-Core, gutem SDK und guter Doku usw gibt es da schon seit Jahren.

Hatte letztes Jahr mal das Vergnügen BLE über low6pan auf einem nRF52 zu 
testen. War ein Mini-Modülchen von UBLOX mit nRF52, den man frei in C 
programmieren konnte - und man konnte per SWD sogar super auf den 
Dingern debuggen.

WLAN und Bluetooth haben die mittlerweile sicherlich auch.

Kosten halt mehr als $1 und das ist wohl der Grund, wieso die nicht so 
verbreitet sind wie die ESP8266.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
abc schrieb:
>>> Denn ein wesentliches Problem von Android sind die Treiber. Dieses
>>> Problem ist mit einem komplett neuen Betriebssystem noch größer.
>> Das betrifft die chinesischen Hersteller nur begrenzt, denn die
>> entwickeln sowohl die Hardware als auch die Software vor Ort.
> Sieht man ja, wie gut das Allwinner und Konsorten funktioniert.

Was siehst du da? Ich sehe, dass Allwinner und Konsorten einfach ein BSP 
für ein Betriebssystem liefern, wo dann ein kräftig zusammengepatchter 
Haufen Grützcode einigermaßen funktioniert.

Ob das nun mit Linux, mit Android-HALs oder meinetwegen auch mit NuttX 
gepfuscht ist, interessiert die doch garnicht. Da kann es auch ein 
Huawei-Android-Ersatz sein.

(Nachtrag: Du willst garnicht wissen, wie Mediatek das strukturiert. Da 
läuft einem der kalte Schauer über den Rücken.)

>>> Der ursprüngliche Grund für Android damals war aber mangelnde
>>> Performance eines Smartphones für den Betrieb eines kompletten Linux.
>>
>> Das kann ich mir nicht so recht vorstellen
>
> Dann schau Dir noch mal an, was zum damaligen Zeitpunkt an CPUs
> verfügbar war und wie lang damit ein in der Hand tragbarer Akku
> mit Linux gehalten hat.

...und das Android jener Zeit hat ebenfalls Linux genutzt, also sind 
weder die Hardware noch der Linux-Kernel daran schuld, dass es unter 
Linux-Distributionen kacke war. Und noch immer wäre.

> Die Tausend und eine API bei Android gibt es, weil es mit den
> Möglichkeiten der CPUs und Akkus gewachsen ist. [...]

Ja, und weil das Linux-Ökosystem es weder damals noch heute hinbekommen 
hätte. Google hätte nämlich statt "wir machen unser eigenes Ding" auch 
eine Linux-Distribution nehmen können - und wäre damit jämmerlich auf 
die Schnauze geflogen.

Weil es damals nichts gab, was man brauchte.
Und abgesehen von Android hat sich daran noch immer nichts geändert.

>> So viel anders als Google ist das auch nicht, denen ist die
>> GPL ein Dorn im Auge; wenn sie könnten, würden sie Linux auch
>> rauswerfen.
>
> Und warum haben die Chinesen dann auf Risc-V gewartet, wenn sie die
> ganze kostenlose Infrastruktur bis hin zum Betriebssystem auch selbst
> gern stemmen könnten?

Wer sprach denn von "gern"? An eigener Technik hängt immer ein 
Preisschild dran, und China ist auch nicht ganz so gleichgeschaltet, wie 
wir das immer gerne glauben wollen. Denen ist auch klar, dass 30 
dezentral entwickelte, proprietäre Architekturen ne doofe Basis sind.

Im Gegensatz zum Westen sind die absolut auf nix festgenagelt - in den 
Allwinner-Chips steckt auch ein OpenRISC drin.

> So kompliziert ist der Entwurf einer ISA, die nicht weltweit
> kompatibel zu sein braucht und keinen gemeinsamen Nenner braucht,
> nun auch wieder nicht.

Wenn sie außerhalb deiner Firma auch kompatibel sein soll, dann schon. 
Es sei denn, sie wird außerhalb deiner Firma entwickelt und du kaufst 
ein, aber dazu braucht es eine zentrale Instanz.

Das kann Berkeley sein, das kann Huawei sein, das kann ARM sein, 
scheißegal. Und bis Trump gab es keinen wirklich wichtigen Grund, es 
selbst zu tun.

Jetzt gibt es einen.

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Da hätte ich spontan auf Nordic getippt. Zumindest Bluetooth mit
> ARM-Core, gutem SDK und guter Doku usw gibt es da schon seit Jahren.

Nordic ist mir bekannt und mit deren Chips habe ich auch schon 
gearbeitet. Die sind wirklich sehr fein und wenn es nur um Bluetooth 
geht sicher deutlich besser als die ESP32 aber WLAN habe ich da noch 
nicht gesehen.

Johannes S. schrieb:
> es gibt RTL8170 oder RTL8195 mit ARM statt Xtensa Kern

Die kenne ich auch, haben aber eher weniger Doku und mehr Binary-Blobs 
als die ESP32, von daher sehe ich hier keinen Vorteil, eher Nachteile.


PS:
S. R. schrieb:
> bis Trump gab es keinen wirklich wichtigen Grund, es selbst zu tun.
>
> Jetzt gibt es einen.

Ich stimme da definitiv zu, auch was Arduinofanboy mit dem Zwang zu 
einem guten Schachzug gesagt hat. Es ist von der Trump-Regierung schon 
sehr plump, zu glauben mit so einfachen "Tricks" lasse sich die 
chinesische Konkurrenz abhängen. Ganz im Gegenteil: Durch das Verbot für 
TSMC (jetzt mit Hauptsitz in Amerika) an chinesische Firmen wie Huawei 
auszuliefern steigt der (ohnehin vorhandene) Leidensdruck auf Seiten der 
Chinesen so immens, dass sie mittelfristig (ich schätze so fünf bis zehn 
Jahre) ihren eigenen Auftragsfertiger aus der Taufe heben werden. Das 
wiederum dürfte dann TSMC so gar nicht schmecken

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> ihren eigenen Auftragsfertiger aus der Taufe heben werden. Das
> wiederum dürfte dann TSMC so gar nicht schmecken

Ich dachte, diese Rolle übernimmt SMIC schon? :-)
Allerdings lässt bei denen u.a. Qualcomm fertigen, als kann man das 
nicht zu offensichtlich machen... bisher.

von abc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> abc schrieb:
>>>> Denn ein wesentliches Problem von Android sind die Treiber. Dieses
>>>> Problem ist mit einem komplett neuen Betriebssystem noch größer.
>>> Das betrifft die chinesischen Hersteller nur begrenzt, denn die
>>> entwickeln sowohl die Hardware als auch die Software vor Ort.
>> Sieht man ja, wie gut das Allwinner und Konsorten funktioniert.
>
> Was siehst du da? Ich sehe, dass Allwinner und Konsorten einfach ein BSP
> für ein Betriebssystem liefern, wo dann ein kräftig zusammengepatchter
> Haufen Grützcode einigermaßen funktioniert.

Genau so sehe ich das auch. Das war mein Punkt. Für ein weiteres 
OS-Unikat wird es nicht besser und dann kann ggf. keiner mehr "helfen".

>> Die Tausend und eine API bei Android gibt es, weil es mit den
>> Möglichkeiten der CPUs und Akkus gewachsen ist. [...]
>
> Ja, und weil das Linux-Ökosystem es weder damals noch heute hinbekommen
> hätte. Google hätte nämlich statt "wir machen unser eigenes Ding" auch
> eine Linux-Distribution nehmen können - und wäre damit jämmerlich auf
> die Schnauze geflogen.

Es gab bzgl. existierender Linux-GUIs nichts, das performant und 
stromsparend genug für die damalige Smartphone-Hardware zu sinnvollen 
Preisen gewesen wäre. Aber...

> ...und das Android jener Zeit hat ebenfalls Linux genutzt, also sind
> weder die Hardware noch der Linux-Kernel daran schuld, dass es unter
> Linux-Distributionen kacke war. Und noch immer wäre.

...heute ist die Situation anders. Deshalb wäre das heute eben nicht 
mehr so.

>> So kompliziert ist der Entwurf einer ISA, die nicht weltweit
>> kompatibel zu sein braucht und keinen gemeinsamen Nenner braucht,
>> nun auch wieder nicht.
>
> Wenn sie außerhalb deiner Firma auch kompatibel sein soll, dann schon.
> Es sei denn, sie wird außerhalb deiner Firma entwickelt und du kaufst
> ein, aber dazu braucht es eine zentrale Instanz.
>
> Das kann Berkeley sein, das kann Huawei sein, das kann ARM sein,
> scheißegal. Und bis Trump gab es keinen wirklich wichtigen Grund, es
> selbst zu tun.

Und sie machen es auch heute nicht selbst. RISC-V ist doch keine 
chinesische Entwicklung.

> Jetzt gibt es einen.

Und ist der Grund jetzt wieder weg? Seit Jahrzehnten ist die Entwicklung 
nun schon so, auch aufgrund diverser Fehlentscheidungen unsererseits.
Der Umstieg chinesischer Firmen auf die nun verfügbare RISC-V war der 
nächste logische Schritt. Über den Wandel bei den SoCs weg von ARM und 
hin zu Risc-V haben wir schon vor dem Handelskrieg gesprochen. Manche 
glauben vermutlich wirklich, dass ohne Trump dies nicht passiert wäre. 
Auf ein Jahr eher oder später kommt es doch nicht an.
Aber wenn genug Menschen fest an eine Sache glauben, dann ist es am Ende 
auch tatsächlich Realität, wie mit einer Religion:
Die Chinesen kaufen am liebsten westliche Technologie und wollen nichts 
selbst entwickeln. Blocken bestimmter Technologien gab's noch nie. Aber 
jetzt wegen Trump gehts aber los. Ähnliches Thema bei den sozialen 
Medien.
Vom Stress mit der Ostsee-Pipeline über Nato-Stützpunkte bis hin zu 
vielen anderen Themen, die hier alle offtopic sind: "Ohne Trump wäre das 
mit den lieben Amerikanern alles nicht passiert". (Dabei gibt es viel 
schwerwiegendere Themen von Snwoden bis hin zu diversen Kriegen.) So 
bleibt man auch beim Technischen nicht verschont von dieser "Ansicht". 
Seit Jahren kaum ein längere Unterhaltung, bei dem nicht irgendwann das 
Thema "Trump" eingestreut wird. Leider wird sich diese Mentalität nun 
wieder verstärkt anders entladen.
Lange Rede, kurzer Sinn: Nein, Trump ist nicht ursächlich dafür, dass 
chinesische Firmen jetzt auf Risc-V setzen. Die chinesischen Firmen 
machen jetzt das, was zuvor bereits Nvidia, WD und diverse westliche 
Firmen bereits tun. Sie machen das, weil sie ihre Produkte weltweit auf 
den Märkten platzieren wollen. Sie wollen mehr Wohlstand und ordnen dem 
praktisch jedes andere Thema unter.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich dachte, diese Rolle übernimmt SMIC schon? :-)
> Allerdings lässt bei denen u.a. Qualcomm fertigen, als kann man das
> nicht zu offensichtlich machen... bisher.

Ja, die meinte ich auch mit "aus der Taufe heben" aber die hinken 
technologisch immer noch ca. 4 Jahre hinter TSMC hinterher und die 
Aufholjagd wird denen mit allen möglichen Mitteln erschwert, inkl. 
Exportbeschränkungen für notwendige Technologie seitens der USA. Das 
wird die kurzfristig zurückschmeißen aber deshalb werden die ganz sicher 
nicht aufgeben, ganz im Gegenteil.

Für so einen ESP32 sollte es aber eigentlich dennoch reichen.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Ich frage mich, ob die Ankündigung der zum ESP8266 pin-kompatiblen 
Variante zugleich das Aus des ESP8266 bedeutet. Ich fände das sehr 
schade, denn ich habe mich an den ESP8266 gewöhnt. Ich habe keine Lust, 
diesen mühsam Lernprozess jetzt schon zu wiederholen.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Ich schätze mal, dass es mit dem ESP8266 so sein wird wie sonst auch 
immer:
So lange das Teil gekauft wird, wird der auch noch produziert und da das 
Teil stand Heute in unzähligen "China-Gadgets" steckt wird der wohl auch 
in Zukunft nachgefragt werden, weil eben nicht alle Hersteller für 
Features, die sie gar nicht benötigen (etwa Bluetooth), ihre Software 
anpassen wollen.

Ich kann deine Bedenken bezüglich des ESP32 aber nicht wirklich 
nachvollziehen. Im Endeffekt bekommst du einen wesentlich besser 
dokumentierten Controller, mit wesentlich besserer Peripherie (inkl. der 
Möglichkeit einen Debugger anzuklemmen) und das womöglich zu einem 
ähnlichen Preis.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Für mich ist der ESP "nur" ein Kommunikations-Coprozessor und Bluetooth 
will ich nach Jahrelangen negativen Erfahrungen nicht mehr benutzen. 
Insofern ist das ESP-01 Modul für mich genau richtig.

: Bearbeitet durch User
von Cihan S. (cihan_s)


Bewertung
0 lesenswert
nicht lesenswert
Alles eine Frage des Preises.

von Christoph B. (birki2k)


Bewertung
1 lesenswert
nicht lesenswert
Inzwischen gibt es eine englische Pressemitteilung zum ESP32-C3: 
https://www.espressif.com/en/news/ESP32_C3

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.