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.
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?
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.
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.
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 :)
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.
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.
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.
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.
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_wischJohn 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.
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.
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.
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.
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.
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.
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.
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...
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!!!
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
....dann ist das nur noch eine Frage der Zeit, wann man auf dem ESPxxxx
Chip Linux laufen lassen kann :-)
Der Schritt ist logisch und öffnet enorme Potentiale und macht RISC-V
einer breiten Entwicklergemeinde zugänglich. Für 1$ an einen RISC-V
Entwicklungssystem zu kommen ist jedenfalls der Hammer.
ARM dürfte vor Neid erblassen. Ist ja nur noch eine Frage der Zeit, wann
ein RISC-V Raspi kommt. PicoRio macht es vor...
https://riscv.org/blog/2020/09/picorio-for-risc-v-like-raspberry-pi-for-arm/
Ich freue mich drauf mal wieder was neues zu lernen :-)
Sobald eine solche Tabelle sehr einseitig daher kommt, kann man wohl
nicht viel von der Gegenseite erwarten:
https://riscv.org/wp-content/uploads/2020/09/Screen-Shot-2020-09-28-at-3.08.23-PM.png
Bei den Cost hätten man z.B. ruhig 30-80$ schreiben können, ebenso bei
der Clock speed, die meines Wissens um 1GHz ist. Und bei der HW/SW zu
schreiben completely proprietary ist ja auch knapp daneben und doch weit
vorbei.
Bitte enrsthaft antworten - bitte einmal für Dummies:
Worin liegen die Vorteile? Ich habe verstanden, das RISC Teil ist
pinkompatibel - da also kann der Vorteil in erweiterten IOT Funktionen
nicht liegen?
Stromsparender?
Schneller ?
Mehr Libraries von "Standardsoftware" einbindbar?
Was sonst noch ???
Danke & Gruesse
Hendrik L. schrieb:> Worin liegen die Vorteile?
Für China geht es um die Unabhängigkeit von den USA.
Die das Dingens technisch abschneidet, spielt nur eine sehr geringe
Rolle.
Hendrik L. schrieb:> Worin liegen die Vorteile?
RISC-V ist eine offene Technologie und nicht ARM.
Das heißt, es fallen für den Hersteller des Chips keine Lizenzgebühren
an.
Mögliche Patentstreitigkeiten sind auch eher unwahrscheinlich.
Und es handelt sich bei RISC-V nicht um eine US-amerikanische
Technologie (seit ARM von nVidia gekauft wurde, ist das eindeutig).
Vorteile für dich? Keine besonderen. Nachteile aber auch nicht.
Hendrik L. schrieb:> Worin liegen die Vorteile?
Und die "Dagegen"-Mentalität nicht vergessen.
Ne im ernst - wieso sollte man ARM und NVIDIA unterstützen wollen?
Da sollte man sich lieber auf die Seite des Newcomers schlagen.
> Und es handelt sich bei RISC-V nicht um eine US-amerikanische> Technologie ...
Das musst du unbedingt den Briten erzählen. Die werden sich vielleicht
freuen.
Herbert schrieb:>> Und es handelt sich bei RISC-V nicht um>> eine US-amerikanische Technologie ...>> Das musst du unbedingt den Briten erzählen.> Die werden sich vielleicht freuen.
Die Briten sind raus, seit (a) ARM von SoftBank gekauft und (b) an
nVidia weiterverkauft wurde. Jetzt ist es US-Technologie.
Und was RISC-V angeht... die Spec ist offen, kann man sich auch aus
Europa besorgen, brav an den USA vorbei.
S. R. schrieb:> Die Briten sind raus, seit (a) ARM von SoftBank gekauft und (b) an> nVidia weiterverkauft wurde. Jetzt ist es US-Technologie.
Du hast nicht nur immense Probleme, das dummdeutsche Wort Technologie
einzuordnen, sondern auch Schwierigkeiten zu erkennen, wer die
ARM-Architektur entworfen wurde. Aber lassen wird das, lese hier sowieso
nicht mehr mit (Einfach zu viele geistige Zwerge).
MArtin schrieb:> Du hast nicht nur immense Probleme, das dummdeutsche Wort Technologie> einzuordnen, sondern auch Schwierigkeiten zu erkennen, wer die> ARM-Architektur entworfen wurde. Aber lassen wird das, lese hier sowieso> nicht mehr mit (Einfach zu viele geistige Zwerge).
Ich weiß tatsächlich nicht, wer die ARM-Architektur entworfen wurde.
Sie hat britische Wurzeln, das ist mir bekannt.
Das ist inzwischen aber irrelevant, weil das, was daran klebt (Lizenzen,
Patente usw.) jetzt nicht mehr in britischer Hand liegen und auch nicht
mehr in der Hand eines mehr-oder-weniger zuverlässigen Unbeteiligten.
Für diejenigen, die jetzt ein Interesse an RISC-V haben, ist das ein
völlig ausreichender Grund. Unabhängig von kleinen oder großen Geistern.
RISC-V ist ja nur eine Lizenzfreie Architektur, das heisst aber noch
lange nicht dass wir einsehen können ob Chiphersteller Backdoors
eingebaut haben oder? Ist ja nicht Open Source. Die Lithographiesystem
kann nicht einfach so jedermann kaufen.
Forgoden . schrieb:> RISC-V ist ja nur eine Lizenzfreie Architektur
Den Befehlssatz kan Jeder hernehmen und selbst eine CPU bauen die den
verwendet. Ob im FPGA oder als eigenen Chip.
> das heisst aber noch> lange nicht dass wir einsehen können ob Chiphersteller Backdoors> eingebaut haben oder?
Klar. Du darfst einen Chip bauen, der zum RISC-V Befehlssatz kompatibel
ist und der eine Backdoor hat. Und den darfst du auch verkaufen.
Forgoden . schrieb:> Ist ja nicht Open Source.
RISC-V ist quelloffen. Aber wenn du jetzt einen Chip baust der den
RISC-V Befehlssatz verwendet, dann musst du den nicht quelloffen machen.
Aber du kannst wenn du einen RISC-V Chip nutzen willst den jetzt
entweder selber bauen oder einen kaufen der quelloffen ist. Es gibt ja
doch mehrere RISC-V Implementierungen - auch quelloffene.
Gustl B. schrieb:> entweder selber bauen
Wie baut man den selber? Schickt man die Schaltkreise an den
Chipauftraghersteller oder braucht man eigene Lithographiesysteme?
Forgoden . schrieb:> Wie baut man den selber?
Ich weiß nicht genau wie, aber es gibt viele Firmen, die Chips designen
und woanders produzieren lassen.
Ich stelle mir das ähnlich vor, wie bei Leiterplatten. Da schickt man
dem Hersteller ja auch nur maschinenlesbare Produktionspläne.
Stefan ⛄ F. schrieb:> Ich stelle mir das ähnlich vor, wie bei Leiterplatten.
Exakt! Kann man selber fertigen, ist aber krass aufwändig wenn es kleine
Strukturen sind oder man schickt das zu einem Fertiger. Hier ist ein
älterer Thread dazu:
Beitrag "Eigenen Chip produzieren. Kosten"
S. R. schrieb:> Herbert schrieb:>>> Und es handelt sich bei RISC-V nicht um>>> eine US-amerikanische Technologie ...>>>> Das musst du unbedingt den Briten erzählen.>> Die werden sich vielleicht freuen.>> Die Briten sind raus, seit (a) ARM von SoftBank gekauft und (b) an> nVidia weiterverkauft wurde. Jetzt ist es US-Technologie.>> Und was RISC-V angeht... die Spec ist offen, kann man sich auch aus> Europa besorgen, brav an den USA vorbei.
War eigentlich nicht anders zu erwarten, wenn man seinen Chip-Kunden
erklärt, daß man sie vielleicht nicht mehr beliefern könnte. Spätesten
seit ARM einer US-Firma gehört, zwingen solche Aussagen die Kunden
(viele Handys laufen mit Qualcom Chips) dazu, sich Alternativen zu
überlegen. Man muß da höllisch aufpassen, daß der Umstellungsschmerz für
den Kunden von diesem nicht plötzlich ertragbar angesehen wird. Das ist
kein Gebiet, auf dem man mit immobilienmaklermethoden lange erfolgreich
ist.
Aber was soll's, ist auch für Europa besser, wenn man eine ISA benutzen
kann, die Lizenzfrei ist. Und wie wenig wir das könnten, kann man daran
sehen, was die USA angestellt haben, als die Chinesen einen Hersteller
von Maschinen für die Chip-Fertigung aus DE kaufen wollten. Wir könnten
schon, aber das lohnt sich nicht, wenn die wichtigen ISA's nicht frei
verfügbar sind. Wenn der Lizenzgeber selber Chips fertigt, dann kann er
Lizenznehmer immer über den Preis kontrollieren. Und solange er
zuverlässig liefert, lohnt selberbauen nicht.
Der S2 hat definitiv kein Bluetooth, dafür aber USB OTG (das wird im
Eingangspost fälschlicherweise anders dargestellt).
Der C3 hat definitiv BLE und zwar sogar in Form von BLE 5.0 aber laut
den aktuellen Datenblättern dafür kein USB (auch das wird vom TO anders
dargestellt).
Des weiteren hat der C3 meines Wissens nach keinen ULP, während der S2
einen ULP in RV-Architektur besitzt. Als Hauptprozessor haben beide
Varianten nur einen Kern (der S2 als LX7, der C3 als RV), im Gegensatz
zum "Ur-ESP32", welcher zwei Kerne nebst "Custom-ULP" hat.
Ich denke die Jungs bei Espressif haben gemerkt, dass sie mit dem
"Ur"-ESP32 etwas übers Ziel hinausgeschossen sind. Die neuen Modelle
bedienen entsprechend zum Einen den Markt für Geräte mit dauerhafter
Stromversorgung (S2), bei denen man sich den USB-UART-Converter
einspart, etwa für Firmwareupgrades oder auch einfach um das Gerät per
USB anzuflanschen (statt über WLAN) und zum anderen jene Geräte die
sowieso per Battterie laufen müssen (BLE 5.0 mit ESP32-C3). Interessant
finde ich, dass Espressif gerade bei letzterem den ULP scheinbar
"weggespart" hat. Mir ist aber ohnehin ein einziger Kern der sehr gut
skalierbar ist lieber, als ein Haufen Kerne für dieses oder jenes. Die
"Programmierbarkeit" des ULP des "Ur-ESP32" stellt ja schon fast jene
der PRU von TI in den Schatten, zu Zeiten in denen es für diese noch
keinen C-Compiler gab. Wahrscheinlich gab es auch ein entsprechendes
Feedback von den (Groß-)Abnehmern.
Oliver K. schrieb:> Vielleicht gibt's hier noch welche direkt von der Quelle:> https://twitter.com/EspressifSystem/status/1337750119068811266?s=20
Da habe ich natürlich nicht nach gesucht und Ali und Taobao waren ohne
Erfolg. Ich befürchte aber, dass man auf diesem Weg nun auch keine
Dev-Boards mehr erhält, sofern man nicht vorweisen kann, ein
"bedeutsamer" Entwickler zu sein. Die Antwort steht ja im Prinzip
explizit im Twitter-Thread: zu viele Anfragen
dunky schrieb:> 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
Ich arbeite grad Hobbymäßig schon seit längerem an einem komplexen ESP32
Projekt.
Grob gesagt Bluetooth-Audio-Empfänger mit DSP und 4 Kanal Audio-Out.
Habe so ziemlich alles im Einsatz (WiFi Access-Point zur DSP
Konfiguration dazu parallel! Bluetooth für Audio-Empfang, beide I2S
module, dazu noch den RMT für IR-Receiver und die NVS Library... Achja
I2C auch noch).
Das ganze entwickle ich unter einem virtuellen Lubuntu mit dem ESP-IDF.
Was das debuggen angeht bin ich bisher mit dem "UART" debugging
ausgekommen.
Den Code editiere ich mit einem ganz normalen Editor. Kein Eclipse oder
so.
Ich finde eigentlich, dass das ganze Ökosystem extrem stabil läuft und
der ESP gefühlt unendlich viel Rechenleistung hat. Ich mache hier
Audio-Processing mit 40 IIR filter in 48kHz/32Bit floating-point in
Echtzeit und er macht parallel noch das WiFi+BT.
Ich habe bisher nur paar kleinere Bugs im I2S Treiber gefunden, was das
syncing der beiden Audio-Ports angeht und dass es statt dem gewünschten
I2S Format eigentlich PCM Format ausgibt.
Habe aber für beides relativ schnell einen SW-Workaround gefunden.
Die Code-Beispiele von Espressif laufen auch nicht alle immer 100%
korrekt, sind aber eigentlich immer ein guter Ausgangspunkt. Macht alles
echt easy.
Wenn man mal in dem ganzen ESP-IDF Ökosystem drinnen ist und ab und zu
mal ins Reference-Manual schaut, ist das ganze System bedeutend
einfacher zu handhaben wie ein STM32.
Ich liebe das Teil. Im Ernst.
ARM + RISC-V :
Hier wird ARM gegen RISC-V so wie ein Krieg dargestellt. Also von
einigen. Ich, im Gegensatz zu diesen Endzeitpropheten, sehe das als ganz
normalen Teil des globalen Marktes. Sind beide Optionen(Hypothetisch und
stark vereinfacht) gleich gut, gibt es irgendwann ein Gleichgewicht und
nicht die totale Vernichtung, Endzeit und Gejammere.
ESP8266 :
Chips von 1970 kaufen? Ebay, China, etc. Es wurden und werden mehr
ESP8266's als der "Alte Scheiss" von damals produziert. Also ich bin
guter Dinge in 30 Jahren noch welche zu bekommen. ... und lass das
"Fake" Argument stecken. Von denen rede ich nicht.
NVIDIA + ARM :
Mampf F. schrieb:
>Hendrik L. schrieb:>> Worin liegen die Vorteile?>Und die "Dagegen"-Mentalität nicht vergessen.>Ne im ernst - wieso sollte man ARM und NVIDIA unterstützen wollen?>Da sollte man sich lieber auf die Seite des Newcomers schlagen.
Die "Du kannst mich mal mit deiner Beeinflussungs"-Mentalität bitte auch
nicht vergessen:)
NVIDIA hat ARM sicher gekauft um das komplette Ökosystem einzustampfen.
Es ist ja nur ein Milliardengeschäft. Genau so operieren Großkonzerne.
Irgendwelche Torschlusspanik hinsichtlich diesem Thema halte ich für ein
Märchen. Genau so wie manche der hier vorgestellten Prognosen
hinsichtlich der Marktlage in der Zukunft. Das sind doch alles haltlose
Spekulationen (wie diese 2 Jahres Prognose von oben, ups ... schon
wieder Mampf).
>Schade, dass du dich hinter einem Gast-Account versteckst, sonst hätte>ich dir das gerne in 2 Jahren unter die Nase gerieben ;-)
Die Erwähnung der Zukunft, also eine Projektion deiner Hypothese macht
sie noch lange nicht zu einer Tatsache. Besser sind standhafte Daten und
sichere Argumente um solch eine Behauptung glaubhaft zu machen.
Das ist übrigens nicht persönlich gemeint, Mampf. Ist nur zufällig
ausgewählt.
Ich meine einfach nur dass wir alle etwas vorsichtiger sein sollten und
einen kühlen Kopf bewahren sollten. Niemand kann Vorhersehen was
passiert wenn ein Staat ins Spiel eingreift, was die Natur zu bieten hat
(erinnert ihr euch an Erdbeben, Tsunami und Speicherpreise?) oder ein
Vollpfosten regiert(ein Land oder eine Firma, egal)?
Auf jeden Fall ist es eine Plattform mehr, zudem noch eine Offene, etwas
seeeeeeeeeeeeeeehr seeeeeeeeeehr teuflisches, das wir mit allen Mitteln
bekämpfen sollten. Kenne deinen Feind(Ironie)! Um das zu tun sollten wir
uns in die Materie einlesen und uns damit beschäftigen(keine Ironie).
https://riscv.org/community/learn/risc-v-books/https://github.com/Lingrui98/RISC-V-book
RISC-V Assembly Language, Dos Reis
Bitte teilt auch Eure Leseempfehlungen
Ach so, Topic. "Neue Espressif-Funkmodule mit RISC-V-Prozessoren".
Klasse ! Her damit;) Kommt ins Feinde-Regal neben Sipeed Maix Boards,
Russische Röhre und Konsorten:P
Jedzia D. schrieb:> NVIDIA hat ARM sicher gekauft um das komplette Ökosystem einzustampfen.
Nein. Aber der Fakt, dass damit die gesamte ARM-Technologie unter
US-Gesetze fällt, dürfte nicht unwesentlich gewesen sein. Für einen
Handelskrieg sollte man die Technologien, die man anderen verbieten
will, schon unter Kontrolle haben - und ARM gehörte da bisher nicht zu.
Was RISC-V angeht, da warte ich noch auf die dicken Brummer.
Und Unterstützung in AOSP. Das wird aber noch 5-10 Jahre dauern.
S. R. schrieb:> Jedzia D. schrieb:>> NVIDIA hat ARM sicher gekauft um das komplette Ökosystem einzustampfen.>> Nein. .........
Du weißt schon, dass ich das ironisch meinte, oder? Das sollte soviel
heißen wie: Handelskrieg oder Milliardengewinne. Was glaubst du wohl was
man in den Chefetagen bevorzugt?
Und falls Du recht hast, wen betrifft das? China? Toll. Mich dann wohl
nicht, weil ich habe vor ein paar Tagen noch ARM-Chips gekauft.
Will meinen: Sehr relevant ist das für uns doch nicht. Und es ist ja
auch nicht so, dass es keine Alternativen gäbe. Inklusive RISC-V.
Jedzia D. schrieb:> Was glaubst du wohl was man in den Chefetagen bevorzugt?
Ich glaube, dass die Welt komplexer ist, als man uns das gern weismachen
würde.
Jedzia D. schrieb:> wen betrifft das? China? Toll. Mich dann wohl nicht
Wenn du meinst, dass dich chinesische Reissäcke oder Fledermäuse nicht
betreffen, dann schaue dich bitte einfach mal in der Welt um.
Persönlich betrifft mich das auch nicht, zumindest noch nicht.
Meinen Arbeitgeber längerfristig schon. Und dann doch mich persönlich.
Ich gebe dir vollkommen recht, svenska. Die Welt ist sehr komplex. Genau
das wollte ich sagen. Viel komplexer als hier vereinzelt dargestellt
wird.
Ich verzichte auch auf den latent unter schwingenden Rassismus, wenn es
um die "Anderen" (wurstegal ob China) geht.
Und nein ich beschuldige dich nicht!
> Wenn du meinst, dass dich chinesische Reissäcke oder Fledermäuse nicht> betreffen, dann schaue dich bitte einfach mal in der Welt um.
Ich hab dir doch meine Situation und Meinung geschildert. Was gibt es da
herum-zu-lamentieren? Kann man die nicht akzeptieren? Du musst ja nicht
meiner Meinung sein, bzw. kannst du in einer komplett anderen Situation
wie ich sein. Blödsinn, Du BIST in einer komplett anderen Situation als
ich:)
"Was glaubst du wohl was man in den Chefetagen bevorzugt?" ..... Ist
eine Vereinfachung, oder nicht? Aber keine Angst ich arbeite gerade an
einem umfangreichen Artikel über die Makroökonomie dieser Firmen.
Achja, das dauert noch ein Jahr, hat 500 Seiten und ist total off-topic.
Spass beiseite. Danke für deine Gedanken und einfach cool bleiben. Nicht
alle wollen uns ans Leder.
Michael D. schrieb:> dual-core: esp32-s3
Wow wie kann man mit so wenigen Produkten seine eigene
Produktkennzeichnung so undurchsichtig halten.
ESP8266: Tensilica L106, Single Core
ESP32: Xtensa LX6, Single oder Dual Core
ESP32-S2: Xtensa LX7, Single Core
ESP32-C3: Risc-V, Single Core
und jetzt neu ESP32-S3: Xtensa LX7 Dual Core
Hätten sie doch die ESP32 Reihe weiterlaufen lassen, alles unter Xtensa
und für Risc-V eine neue Bezeichnung ausgedacht.
Wenn jetzt die Peripherie, der C3 und S3 Serie nicht gleich ist, weiss
ich erst recht nicht, was sich Espressif da gedacht hat.
Bei der Suche auf aliexpress nach ESP32-C3 kommt auf jeden Fall alles
mögliche, was ESP32 im Namen hat.
Jedzia D. schrieb:> ARM + RISC-V :> Hier wird ARM gegen RISC-V so wie ein Krieg dargestellt. Also von> einigen. Ich, im Gegensatz zu diesen Endzeitpropheten, sehe das als ganz> normalen Teil des globalen Marktes. Sind beide Optionen(Hypothetisch und> stark vereinfacht) gleich gut, gibt es irgendwann ein Gleichgewicht und> nicht die totale Vernichtung, Endzeit und Gejammere.
Das ist aber ein instabiles Gleichgewicht: Sobald eine der beiden
Alternativen z.B. von Compilern und anderer Software besser unterstützt
wird, gibt es einen Grund dafür, auf diese Alternative zu wechseln. Dort
sammeln sich dann immer mehr Entwickler, die Software, Bibliotheken,
Tools etc für diese schreiben, was das Gleichgewicht weiter verschiebt,
etc, bis schließlich eine der beiden vorherrschend wird.
P.S.: Damit beide längerfristig als bedeutende Architekturen überleben,
bräuchten sie jeweils ihre Nische, in der sie deutlich besser als die
andere sind.
Philipp Klaus K. schrieb:> Das ist aber ein instabiles Gleichgewicht
Natürlich!
Von allen Seiten wird da geschubst.
Kooperation + Konkurrenz sind die "inneren" Faktoren.
Der Trumpismus einer der äußeren.
Führt zu so einer Art Gruppenbildung.
Operator S. schrieb:> Wenn jetzt die Peripherie, der C3 und S3 Serie nicht gleich ist, weiss> ich erst recht nicht, was sich Espressif da gedacht hat.
Identisch ist die Peripherie ganz sicher nicht. Der S3 bringt USB-OTG
mit und der C3 (wenn überhaupt) USB-Device. Beide kommen aber mit BLE
5.0 daher.
Vielen Dank für die interessanten Kommentare hier und dem Starter.
Weiß man schon etwas über den Wlan Durchsatz oder die maximale GPIO
Frequenz beim C3? - Das war ja vorher nicht so schön.
Great article, I wasn't expecting such microprocessors, but their
appearance shows progress) I wonder how soon they will appear on the
vendor's source? I think they will be in demand, so soon enough. It's a
good thing I'm already working with them)
Großer Artikel, ich war nicht erwarten, dass solche Mikroprozessoren,
aber ihr Aussehen zeigt den Fortschritt) Ich frage mich, wie bald sie
auf der Quelle des Anbieters erscheinen wird? Ich denke, sie werden in
der Nachfrage sein, so früh genug. Es ist eine gute Sache, die ich
bereits mit ihnen arbeiten)
Thread beobachten
Seitenaufteilung abschalten