Für ein zukünftiges Projekt (Grafikberechnung auf 480 x 320 Pixel) benötige ich einen leistungsstarken Prozessor. Der ESP8266 lässt sich vom Hersteller aus auf bis zu 160MHz takten, teilweise sind sogar 300MHz möglich (damit hab ich mich allerdings noch nicht genauer beschäftigt). Das Display wird per 4-Wire SPI angebunden werden, theoretisch würden daher 4 GPIOs und Hardware-SPI als Ausstattung reichen. Nun hab ich bei Mouser und Co. mal nachgesehen, was denn ein Prozessor im Bereich von 200MHz kosten würde (zur Erinnerung: Den ESP8266 gibt es bastlerfreundlich für etwas mehr als 2$), und die kosten mindestens das 3-fache von dem ESP8266 (von Cortex M4 bis Cortex M7), und dann fehlt natürlich noch ein Minimal-PCB mit Kondensatoren, Spannungswandler etc. Gibt es einen (geheimen) Tipp für möglichst viel Rechenleistung zu wenig Geld oder soll ich bei dem ESP8266 bleiben?
:
Bearbeitet durch User
Max M. schrieb: > Für ein zukünftiges Projekt (Grafikberechnung auf 480 x 320 Pixel) > benötige ich einen leistungsstarken Prozessor. Was heisst denn Grafikberechnung? Raytracing? Leistungsstark kann auch alles bedeuten. Ein paar Infos mehr bitte.
Der ESP32 ist leistungsfähig genug, um ein in Software berechnetes PAL-Signal auszugeben, und hat noch genügend Reserven, um da nicht nur ein statisches Bild, sondern auch ein einfaches Videospiel darzustellen - mit Ton, versteht sich. http://bitluni.net/esp32-color-pal/
Bei so einem grossen Display ist die SPI-Verbindung der Flaschenhals. Wenn's dir um schnellere Grafikausgabe geht, dann würde ich mich nach einem ARM Cortex M3 oder M4 umschauen mit einem Memory-Mapped Display. Und zwar keines, welches nur ein Adress- und ein Datenregister mappt, sondern eines, welches den kompletten Grafikspeicher linear im Adressraum der CPU liegen hat.
Spongebob schrieb: > Was heisst denn Grafikberechnung? > Raytracing? Tatsächlich hast du ins Schwarze getroffen. Genau genommen handelt es sich um Pathtracing. Also nochmal etwas aufwändiger. ESPler schrieb: > Brauchst du WLan? Nein, benötige ich nicht. Rufus Τ. F. schrieb: > Der ESP32 ist leistungsfähig genug Den hab ich tatsächlich auch hier. In der Ausgangsfrage war indirekt die Hoffnung versteckt, nicht mehr das gruselige SDK von espressif verwenden zu müssen und stattdessen auf eine MCU mit Debugmöglichkeiten umzusteigen :D fusi schrieb: > Bei so einem grossen Display ist die SPI-Verbindung der Flaschenhals. Das glaube ich nicht. Mein C-Code braucht auf einem Core i7 6700k bei so einer Auflösung mind. 1s.
:
Bearbeitet durch User
Schau dir mal die STM Discovery Boards an mit Display. Die sind meist mit internem Grafik Controller und externem Sdram. Ggf ist eins der M7 Boards ausreichend
Peter schrieb: > Schau dir mal die STM Discovery Boards an mit Display. Hast du meine Preisvorstellung gelesen? Die MCUs auf dem M7 und M4 Disco-Boards kosten einzeln schon über 10€ und sind mit 180MHz bzw. 216MHz nicht wirklich viel schneller. Noch dazu sind die Dinger mit teilweise über 100 Pins eher schwer zu verbauen.
:
Bearbeitet durch User
fusi schrieb: > Bei so einem grossen Display ist die SPI-Verbindung der Flaschenhals. > > Wenn's dir um schnellere Grafikausgabe geht, dann würde ich mich nach > einem ARM Cortex M3 oder M4 umschauen mit einem Memory-Mapped Display. > Und zwar keines, welches nur ein Adress- und ein Datenregister mappt, > sondern eines, welches den kompletten Grafikspeicher linear im > Adressraum der CPU liegen hat. Zu langsam? https://www.youtube.com/watch?v=02-vUJkdGzs Das ist ein ILI9341 mit 16bit-Parallel-Interface via FSMC angebuden an einem STM32F407. Ok, ist kein Video mit 25 oder mehr fps, aber für die meisten Anwendungen jenseits von Video und Animation m.M.n. völlig ausreichend. Das war übrigens mein 1. Versuch mit sehr, sehr vielen unnötigen Wait-Takten auf dem FSMC. Geht also inzwischen sogar noch um Einiges schneller. Was man auf dem Video nicht sieht: man kann das ges. Fester in Echtzeit verschieben (natürlich per Touch), und das geht durchaus flüssig.
Harry L. schrieb: > Zu langsam? > Youtube-Video "STemwin mit ILI9341" > > Das ist ein ILI9341 mit 16bit-Parallel-Interface via FSMC angebuden an > einem STM32F407. Ganz schön zittrige Finger hast du da ;) Spass beiseite, ... Ist das so ein Display, welches ein Datenregister und ein Adressregister oder den kompletten Adressraum mappt? Ich habe hier nämlich schon mehrere SSD1289, die sind genau so aufgebaut und das frisst so viel Zeit/Speicher im Handling... Entweder muss ich den gesamten Bildschirminhalt vorhalten und ggf. bei Änderung ein paar Bytes raushauen oder ich sende jedes Byte, ob geändert oder nicht. Mit FSMC und STM32F103 @72MHz komme ich auf lumpige 3-4fps. Übertaktet auf 128MHz entsprechend mehr (steigt linear mit an). Und das Problem beim Testen der FPS war auch keines, was mit Datenbeschaffung zu tun hatte, ich habe einfach stumpf immer nur 0xffff gesendet, Pixel für Pixel.
Max M. schrieb: > Peter schrieb: >> Schau dir mal die STM Discovery Boards an mit Display. > > Hast du meine Preisvorstellung gelesen? Die MCUs auf dem M7 und M4 > Disco-Boards kosten einzeln schon über 10€ und sind mit 180MHz bzw. > 216MHz nicht wirklich viel schneller. > Noch dazu sind die Dinger mit teilweise über 100 Pins eher schwer zu > verbauen. Wieviel 100 Stück sollen es denn werden? Bei Einzelstücken ist der Bauteilepreis nie ein ernsthaftes Kriterium. Ob das Teil nun 10 oder 20 oder 50€ kostet, ist doch letztendlich egal. Ansonsten greif doch zum Raspberry Pi. Quadcore 1.2 GHz beim 3B+. Plus HDMI, parallel RGB und MIPI DSI LCD Interfaces. Besser wirds nicht. fchk
Frank K. schrieb: > ist doch letztendlich egal. Achso, na dann. Frank K. schrieb: > Ansonsten greif doch zum Raspberry Pi. Quadcore 1.2 GHz beim 3B+. Plus > HDMI, parallel RGB und MIPI DSI LCD Interfaces. Besser wirds nicht. Das ist mir ehrlich gesagt zu weit weg von der Hardware und zu wenig Gebastel :) Anscheinend bleibe ich dann beim ESP8266 - danke für eure Antworten.
:
Bearbeitet durch User
Max M. schrieb: > In der Ausgangsfrage war indirekt die Hoffnung versteckt, nicht mehr das > gruselige SDK von espressif verwenden zu müssen und stattdessen auf eine > MCU mit Debugmöglichkeiten umzusteigen Sieh mal hier: https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/jtag-debugging/
Max M. schrieb: > Hast du meine Preisvorstellung gelesen? Ich könnte dir ja einen H7 mit 400 MHz empfehlen, aber die 3,50 dafür sind für dich unerschwinglich hoch. Bedenke auch, dass noch Porto dazu kommt. Max M. schrieb: > Anscheinend bleibe ich dann beim ESP8266 Eine kleine Welt ist besser überschaubar, auch wenn man dabei die großen Dinge nicht erkennt.
Sorry, das STM32f429 Discovery Board kostet so ca 30.- das ist doch nicht zu teuer! Da hast du einen 2MB controller + 64MB SDRam dabei und das Display! Nebenbei auch noch den entsprechenden Debugger und alle Pins auf einer Stiftleiste. Ach ja, er hat auch eine "Grafikeinheit". also eigentlich einen extra DMA der ein paar grafikspezifische Dinge kann... Wenn du wirklich billig an richtig rechnenleistung kommen willst, dann ist glaubeich der RPi das Mittel der Wahl. Wenn du ohne Linux was drauf machen willst, dann programmier ihn doch bare-metal... infos z.B. hier: https://github.com/bztsrc/raspi3-tutorial 73
Max M. schrieb: > Das glaube ich nicht. Mein C-Code braucht auf einem Core i7 6700k bei so > einer Auflösung mind. 1s. Dann hast du eh schon verloren. Wie viel Minuten darfs denn dauern? Dann nennen wir dir den richtigen Mikrocontroller. Mit einem entsprechenden Cortex A gehts vielleicht in 10s.
> Hast du meine Preisvorstellung gelesen? Die MCUs auf dem M7 und M4 > Disco-Boards kosten einzeln schon über 10€ und sind mit 180MHz bzw. > 216MHz nicht wirklich viel schneller. Warum ist der Preis in irgendeiner Form von Bedeutung wenn du ein Einzelstueck bastelst? Da zaehlt dann ausschliesslich die Qualitaet der Dokumentation und der Entwicklungsumgebung. Iss einfach mal einen Doener weniger und leiste dir eine ordentliche CPU. > Noch dazu sind die Dinger mit teilweise über 100 Pins eher schwer zu > verbauen. Wenn du Rechenleistung und Speicher haben willst dann wird der CPU core eine gewisse Groesse haben muessen. Da sind dann das grosse Gehaeuse mit vielen Pins ein unvermeidbarer Nebeneffekt. Olaf
Quark schrieb: > Ich könnte dir ja einen H7 mit 400 MHz empfehlen, aber die 3,50 dafür Dann zeig mir den bitte. Ich hab ihn nicht gefunden. Hans schrieb: > Da hast du einen 2MB controller + 64MB SDRam Ich brauch leider weder 2MB Flash noch 64MB RAM. Olaf schrieb: > und Speicher Ich hab nirgends was von Speicher geschrieben Hans schrieb: > Sorry, das STM32f429 Discovery Board kostet so ca 30.- das ist doch > nicht zu teuer! Wenn man die ganzen Features braucht: bestimmt nicht. Ansonsten schon. Richard B. schrieb: > Der ESP32 kostet ~2EUR Den ESP8266 hab ich sinnbildlich auch für den ESP32 verwendet Hans schrieb: > Wenn du ohne Linux was drauf machen willst, dann programmier ihn doch > bare-metal Ich hab da JTAG mit OpenOCD nie zum laufen bekommen. Ergo bestand das Programmaufspielen aus lästigem SD-Karte rein- und rausschieben. Das möchte ich mir nicht mehr antun. Sorry, dass das etwas absolutistisch klingt, aber ich brauch halt echt nur 4 GPIOs, etwas Flash und RAM sowie viel Rechenleistung.
:
Bearbeitet durch User
Max M. schrieb: > Sorry, dass das etwas absolutistisch klingt, aber ich brauch halt echt > nur 4 GPIOs, etwas Flash und RAM sowie viel Rechenleistung. Hört sich so an als könntest du dein Problem mit einer großen SD-Karte lösen und das Video auf deinem Core-i7 vorberechnen. Dann reicht auch wenig Rechenleistung, sofern genug IO-Bandbreite möglich ist. Und du hast echte FPS statt Minuten-Pro-Frame. Oder gleich ein Display nehmen, was von sich aus Videodateien abspielen kann. Gibt's billig inkl. Gehäuse als "Reise-Kinderruhigstellungsgerät" zur Montage an Autokopfstützen.
fusi schrieb: > Ist das so ein Display, welches ein Datenregister und ein Adressregister > oder den kompletten Adressraum mappt? Ja, da sind nur die beiden Register in den Adressraum eingeblendet.
Quark schrieb: > Ich könnte dir ja einen H7 mit 400 MHz empfehlen, aber die 3,50 dafür > sind für dich unerschwinglich hoch. Bedenke auch, dass noch Porto dazu > kommt. welcher soll das sein? Alles was ich bisher gefunden habe war deutlich über 5 USD. Gerade wenn man noch genug Speicher > 1Mb haben will.
ESPler schrieb: > Hört sich so an als könntest du dein Problem mit einer großen SD-Karte > lösen und das Video auf deinem Core-i7 vorberechnen. Wenn man den Pathtracer etwas dynamisch mit z.B. der Möglichkeit, dass Objekte verschoben werden können, implementiert, funktioniert dein Trollvorschlag leider nicht.
Max M. schrieb: > Ich hab da JTAG mit OpenOCD nie zum laufen bekommen. Ergo bestand das > Programmaufspielen aus lästigem SD-Karte rein- und rausschieben. > Das möchte ich mir nicht mehr antun. Wenn der Bauer nicht schwimmen kann, ist nicht immer die Badehose Schuld ;)
Sebastian R. schrieb: > Max M. schrieb: > Ich hab da JTAG mit OpenOCD nie zum laufen bekommen. Ergo bestand das > Programmaufspielen aus lästigem SD-Karte rein- und rausschieben. > Das möchte ich mir nicht mehr antun. > > Wenn der Bauer nicht schwimmen kann, ist nicht immer die Badehose Schuld > ;) Natürlich kannst du es auch auf meine Inkompetenz schieben, aber damals war mir sogar im BareMetal Forum von Raspi nicht zu helfen. Noch dazu die mehr als mangelhafte Doku. Die CPU ist nicht für BareMetal gedacht.
:
Bearbeitet durch User
Max M. schrieb: > Die CPU ist nicht für BareMetal gedacht. So wie alle andern komplexen Architekturen auch ... Vllt wäre es bei deinen Anforderungen besser die Berechnungen in ein cpld/fpga auszulagern... Gibt's ja auch billig... 73
> Vllt wäre es bei deinen Anforderungen besser die Berechnungen in ein > cpld/fpga auszulagern... Gibt's ja auch billig... Haben zuviele Beine, damit kommt er dann wieder nicht klar.... Olaf
Max M. schrieb: > Wenn man den Pathtracer etwas dynamisch mit z.B. der Möglichkeit, dass > Objekte verschoben werden können, implementiert, funktioniert dein > Trollvorschlag leider nicht. Wieso Trollvorschlag? Vorberechnen/Caching ist eine gängige Vorgehensweise. sh. https://de.wikipedia.org/wiki/Time-Memory_Tradeoff Und nachdem deine Wunsch-CPU nur 4 Leitungen (zum Display?) und sonst keine IOs haben sollte, war auch nicht davon auszugehen, dass da irgendwas interaktiv werden soll. Hast du eine diskrete Anzahl an möglichen Objektpositionen? => Evtl. ist Vorberechnen weiterhin möglich. Auf eine SD-Karte passen sehr sehr viele Bilder mit 480x320 Pixeln, selbst ohne Komprimierung. Und muss es unbedingt Pathtracing sein? Meinst du wirklich man sieht Unterschiede zu einer hardwarebeschleunigten OpenGL-Darstellung, wenn man sich bei der etwas Mühe mit den Shadern gibt? Insbesondere bei der Auflösung? Oder geht es um "Basteln um des Bastelns willen", um zu beweisen dass das Problem auch irgendwie mit der unpassendsten Hardware lösbar ist? Würde dir ein Attiny13 dann nicht mehr 1337-Punkte einbringen?
Was man hier leider inzwischen großteils an nutzlosen Beiträgen lesen muss tut ja fast weh. Hans schrieb: > Gibt's ja auch billig... Nein, das günstigste FPGA ist von Lattice und kostet etwas über 5€, zumindest das letzte mal als ich eines bestellt habe. Ich stelle es mir außerdem unglaublich aufwändig vor, so einen Algorithmus zu portieren. Olaf schrieb: > Haben zuviele Beine Es gibt einen Unterschied zwischen zu vielen (>100) und einer passenden Anzahl an Pins die sich gut verbauen lassen ([8, 64]). Aber dein Beitrag war eh nicht ernst gemeint. ESPler schrieb: > Wieso Trollvorschlag? Das berechnen von möglichen Positionen einer Kugel im 3D-Raum überlasse ich dir. Falls du es berechnen kannst, wird dir klar werden, dass das ein Trollvorschlag war ESPler schrieb: > Und muss es unbedingt Pathtracing sein? Meinst du wirklich man sieht > Unterschiede zu einer hardwarebeschleunigten OpenGL-Darstellung, wenn > man sich bei der etwas Mühe mit den Shadern gibt? Mir ist kein uC mit hardwarebeschleunigtem OGL bekannt. Pathtracing deswegen, weil die Mathematik dahinter für mich verständlicher ist als die von irgendwelchen "fake" globalen Beleuchtungsmodellen. Es geht hier nicht um OGL sondern ganz einfach darum, ob es einen leistungsstärkeren Prozessor als den ESP im selben Preisbereich gibt. ESPler schrieb: > Und nachdem deine Wunsch-CPU nur 4 Leitungen Die Minimalanforderung waren 4 GPIOs (und maximal war weniger als 100). Du hast da was verwechselt. Es dürfen gerne zwischen 4 und 64 GPIOs sein.
:
Bearbeitet durch User
Wenn du auf die Frage geantwortet hättest, würdest du jetzt vielleicht eine sinnvollere Antwort bekommen: avr schrieb: > Dann hast du eh schon verloren. Wie viel Minuten darfs denn dauern? Dann > nennen wir dir den richtigen Mikrocontroller. Mit einem entsprechenden > Cortex A gehts vielleicht in 10s. Nur damit du das Problem vielleicht besser einschätzen kannst: Ein STM32F7 mit 216MHz ist je nach Aufgabe Faktor 500-1000 langsamer als dein i7. Die nächste Klasse Cortex A wirst du mit unter 100 Pins nicht finden und ohne Linux inklusive externem Ram wirst du hier Bare-Metal-Programmierung betreiben müssen wie beim Raspberry PI. Und selbst der PI3 mit seinen 4 Cortex A53 Kernen ist um zweistelligen Faktor langsamer als deine CPU. Ums kurz zu machen - von den drei Punkten können nur zwei zutreffen: - Der Code ist effizient geschrieben - Die Berechnung erfolgt innerhalb 1s - Du verwendest einen Application Processor (z.B. RPI3)
Max M. schrieb: > Nein, das günstigste FPGA ist von Lattice und kostet etwas über 5€, > zumindest das letzte mal als ich eines bestellt habe. Achja,Mist .... EP2C5T144 Boards kosten ja 15.- beim Chinesen... 73
Hans schrieb: > Achja,Mist Der Hauptgrund ist, ich mag nicht mit einem FPGA anfangen. In VHDL bin ich auf dem Niveau, dass ich gerade eine einfache 4bit Akkumulator-CPU designen kann. avr schrieb: > Wenn du auf die Frage geantwortet hättest Ich möchte es wenigstens probieren. Warum wird immer gleich versucht, das gesammte Projekt zu begraben, sobald man einen neuen Beitrag aufmacht? Hans schrieb: > 73 86
:
Bearbeitet durch User
Und was spricht jetzt dagegegen, den ESP32 zu verwenden? Anders, als Du angenommen hast, lässt sich der über JTAG debuggen, zumindest beschreibt Espressif, wie es geht (s.o. Link).
Max M. schrieb: > Ich möchte es wenigstens probieren. Warum wird immer gleich versucht, > das gesammte Projekt zu begraben, sobald man einen neuen Beitrag > aufmacht? Ich wollte nur realistisch sein. Wenn du deinen bisherigen Code nicht optimieren kannst, dann wird jede Lösung auf einem nicht PC-Prozessor deutlich langsamer sein.
Max M. schrieb: > Das berechnen von möglichen Positionen einer Kugel im 3D-Raum überlasse > ich dir. > Falls du es berechnen kannst, wird dir klar werden, dass das ein > Trollvorschlag war Das ist einfach. Ich definiere mir einfach für alle Details die du (aus Trollgründen?) nicht verraten willst Werte und komme darauf: Es gibt eine Position mitten im Sichtfeld und unendlich viele außerhalb. Vorab-Rendern von zwei verschiedenen Bilddateien reicht. Was? du willst mehr verschiedene Positionen? Dann überlege u. verrate wieviele/wie exakt du deine Kugel positionieren willst. Dann kannst du auch einfach ausrechnen, ob sich das Vorausberechnen lohnt, bzw. ob du mit vorausberechneten Bildern auskommst. Auf eine 32GB SD-Karte kriegst du grob geschätzt 64k Bild-Dateien. Damit kannst du deine Kugel schon recht exakt positionieren/animieren. Hast du dir mal überlegt, warum Animationsfilme als Videodatei oder sogar auf Filmrolle an die Kinos gehen, und nicht als 3D-Rohdatensatz mit Render- und Abspielanleitung? Max M. schrieb: > Mir ist kein uC mit hardwarebeschleunigtem OGL bekannt. RasPi wurde genannt. Willst du aber wohl nicht. Wird dann auch nichts mit Bare-Metal.
ESPler schrieb: > RasPi wurde genannt. Willst du aber wohl nicht. Wird dann auch nichts > mit Bare-Metal. Du bist anscheinend unfähig, meine Beiträge zu lesen und/oder zu verstehen. ESPler schrieb: > Das ist einfach. Einfach ist der Fakt, dass du hier rumtrollst. Es geht mir nicht darum, auf einem MCU langweilige Bilder abzuspielen sondern tatsächliche Berechnungen durchzuführen. Und jetzt erspare mir bitte deine Beiträge.
Dann musst du wohl beim ESP bleiben. für die 2-3€ gibt es nichts vergleichbares. auch ein M7 von ST H7 oder NXP RT1060 kann hier nicht viel machen Wenn du gesichtserkennung oder ähnlcihes machen möchtest ist das für diese klasse zu viel es gibt nur eine brauchbare lösung die ich bereits gesehen habe. AU-Zone technologies hat auf dem NXP Stand mit dem RT1060 EVK eine gesichtserkennung laufen gehabt.was auch ganz gut aussah
ach ich vergaß zudem ist es bei dem ESP , und auch bei den M7 wichtig wo die funktionen liegen. Diese µC haben die möglichkeit funktionen in einen dafür vorgesehenen RAM ( ITCM ) zu legen damit diese funktionen ohne waitstates aufgeführt werden können. der flashzugriff dauert hier üblichweise mehrere Takte!! auch der STM ART kann hier nur 128 bytes puffern. bei ungünstigen funktionen kann sowas irre lange dauern. deswegen hier immer wichtig: ISR und kritische funktionen in den ITCM legen ich hab auf einem F7 den JPEG dekoder kmplett in den ITCM gelegt. vorher aus dem flash: 6-8FPS @ 100% MCU last nacher aus ITCM: kostant 25FPS @ 80% MCU Last
tgdfgdf schrieb: > Dann musst du wohl beim ESP bleiben. > > für die 2-3€ gibt es nichts vergleichbares. Irgendwie schade :( Danke für deine Antwort.
Max M. schrieb: > Irgendwie schade :( > > Danke für deine Antwort. ist leider so. die ESP werden mit aller gewalt auf den markt gedrückt. deswegen auch so billig die ganzen distis bei uns schütteln uach nur den kopf wenn wir irgendwas mit WLAN haben wollen und kommen dann mit preisvergleichen zum ESP alle standardmodule von redpine und co kosten mal eben das 5fache heißt nicht das sie das nicht wert sind ... selbiges gilt für die µC die M7 und so haben alle ihre daseinsberechtigung. je nach aufgabengebiet ist das eben besser als ein ESP denn auch so ei ESP hat seine grenzen.
tgdfgdf schrieb: > je nach aufgabengebiet ist das eben besser als ein ESP > denn auch so ei ESP hat seine grenzen. Der ESP ist vor allem langsamer als ein M7 - trotz dual core.
tgdfgdf schrieb: > die ESP werden mit aller gewalt auf den markt gedrückt. > deswegen auch so billig Es funktioniert auch. Ich kann mir fast nicht vorstellen, dass die dabei nur Verlust (in monetärer hinsicht) machen? Oder ist das vom chinesischen Staat subventioniert? avr schrieb: > Der ESP ist vor allem langsamer als ein M7 - trotz dual core. Hast du eine Quelle für diese Behauptung?
Max M. schrieb: > tgdfgdf schrieb: >> die ESP werden mit aller gewalt auf den markt gedrückt. >> deswegen auch so billig > > Es funktioniert auch. Ich kann mir fast nicht vorstellen, dass die dabei > nur Verlust (in monetärer hinsicht) machen? > Oder ist das vom chinesischen Staat subventioniert? gute frage .. ich glaube hier macht es die masse die anfangs günstig auf den markt geworfen wurde dadurch kamen einige hersteller auf die bildfläche ebenso die integration in die arduinoumgebung das zeug ist jetzt schüttgut ... > avr schrieb: >> Der ESP ist vor allem langsamer als ein M7 - trotz dual core. > > Hast du eine Quelle für diese Behauptung? aus neugier gegoogled: ein 32F7 At 216 MHz fCPU, the STM32F745 delivers 1082 CoreMark / 462 DMIPS macht : 2,138 DMIPS/Mhz ein 32H7 At 400 MHz fCPU, the STM32H743/753 lines deliver 2020 CoreMark /856 DMIPS macht : 2,14 DMIPS/Mhz RT1060 3020 CoreMark/1284 DMIPS @ 600 MHz macht : 2,14 DMIPS/Mhz zum ESP32: Xtensa dual-core 32-bit LX6 microprocessor up to 240 MHz and performing at up to 600 DMIPS ich denke hier eher die 240MHz bei dual core also grob 2,5DMIPS je Mhz Je kern also eher 1,25DMIPS/Mhz aus einer PDF mit gemessenen ergebnissen bei eigenem Benchmark: M7 750DMIPS ESP8266 113DMIPS ESP32 224DMIPS
gdfgsdgsg schrieb: > zum ESP32: > Xtensa dual-core 32-bit LX6 microprocessor up to 240 MHz and performing > at up to 600 DMIPS > > ich denke hier eher die 240MHz bei dual core > also grob 2,5DMIPS je Mhz > Je kern also eher 1,25DMIPS/Mhz in einer hersteller PDF steht etwas von 1,22DMIPS/Mhz kommt also grob hin
avr schrieb: > tgdfgdf schrieb: >> je nach aufgabengebiet ist das eben besser als ein ESP >> denn auch so ei ESP hat seine grenzen. > > Der ESP ist vor allem langsamer als ein M7 - trotz dual core. Eine FP-MAC braucht 100ns.. https://www.esp32.com/viewtopic.php?f=14&t=800&start=10
gdfgsdgsg schrieb: > avr schrieb: >> Der ESP ist vor allem langsamer als ein M7 - trotz dual core. > Hast du eine Quelle für diese Behauptung? Ich hab da Mal in irgendeinem Paper gelesen. Da wurde glaube ich mit einem dhrystone Benchmark verglichen. Von den Specs sieht der esp32 natürlich besser aus, die Frage ist, ob das auch mit sinnvollem Code erreichbar ist oder man auf irgendwelche Flächenhälse stößt.
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.