Hallo, ich suche nach Beispielen für ESP32 ohne FreeRTOS und bin noch nicht fündig geworden. Gibt es diese irgendwo im Netz? Grüße Tycho
Da man den ESP32 auch mit der Arduino-Umgebung programmieren kann, würde ich stark davon ausgehen, daß da kein FreeRTOS involviert ist.
Rufus Τ. F. schrieb: > Da man den ESP32 auch mit der Arduino-Umgebung programmieren kann, > würde > ich stark davon ausgehen, daß da kein FreeRTOS involviert ist. Leider ein Irrtum. (ich würde dir ja gerne zustimmen) Die Arduino ESP32 Umgebung basiert u.A. auf FreeRTOS https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/include/freertos/freertos/FreeRTOS.h Es ist Teil des ESP32 SDK. Das heißt, man wird auf das zugehörige SDK verzichten müssen, da viele Interna dieses nutzen. Und ohne das SDK bekommt man WLAN nicht zum laufen. Dank der vor kompilierten Dateien, mit ihren geheimen Quellen..
Nicht einmal Espressif selbst liefert Beispiele dafür sondern verweist immer wieder einmal aufs Reference Manual: https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf Nach einem kurzen Blick hinein würde ich drigend davon abraten sich auf diese Ebene zu begeben...
Arduino Fanboy D. schrieb: > Und ohne das SDK bekommt man WLAN nicht zum laufen. > Dank der vor kompilierten Dateien, mit ihren geheimen Quellen.. Oh, dass wusste ich gar nicht. D.h. WLAN ist bare metal gar nicht möglich?
Tycho B. schrieb: > D.h. WLAN ist bare metal gar nicht > möglich? Ja, das ist mein Wissensstand! Aber ohne Gewähr.
Arduino Fanboy D. schrieb: > Die Arduino ESP32 Umgebung basiert u.A. auf FreeRTOS > https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/include/freertos/freertos/FreeRTOS.h Ah. Gut zu wissen. Jetzt wäre noch die Frage: Was stört am FreeRTOS?
Rufus Τ. F. schrieb: > Was stört am FreeRTOS? Nun, mit der neuen Erkentniss ist es auch closed source von WLAN. Das ist zu offensichtlich, dass da etwas nach hause telefonieren soll, oder? Zum Anderen ist es der Overhead. Und meine potentielle Anwendung ist relativ überschaubar, so dass ich Multithreading zu Lernzwecken selbst implementieren wollte.
Auch mit dem freeRTOS kann man wie gewohnt arduinolike programmieren man erstellt einen Task der eben 2 funktionenn aufruft.
1 | void setup(void) |
2 | {
|
3 | |
4 | }
|
5 | |
6 | void loop(void) |
7 | {
|
8 | |
9 | }
|
10 | |
11 | |
12 | |
13 | void my_task(void * pvParameters) |
14 | {
|
15 | setup(); |
16 | |
17 | while(1) |
18 | {
|
19 | loop(); |
20 | portYIELD(); |
21 | }
|
22 | }
|
irgendwo musst du einmalig diesen Task erstellen:
1 | xTaskCreate( my_task, "my", 512, NULL , 1 , NULL ); |
dein anwendungstask läuft dann mit niedriger Priorität und behindert alles andere nicht. in deinem loop kannst du drölfzig delays einbauen ohne das irgnedwas stört ob das YIELD notwendig ist .. gucken. Das forciert nach jedem loopdurchlauf einen taskswitch um zu schauen ob etwas anderes wichtiger wäre..
Tycho B. schrieb: > Das > ist zu offensichtlich, dass da etwas nach hause telefonieren soll, oder? Och nöö... Wäre die Wlan Schnittstelle offen, würde sich der ESP als Hacker Tool eignen. Das MUSS unterbunden werden. Wenn ich mich richtig erinnere gibt es sogar EU Richtlinien, welche sich explizit damit beschäftigen, und mittlerweile in DE Recht umgesetzt sind. Aber da ich keine Rechtsexperte bin, auch hier wieder: Ohne jede Gewähr.
Tycho B. schrieb: > Nun, mit der neuen Erkentniss ist es auch closed source von WLAN. Hä? Ist das ein Binär-Blob? > Das ist zu offensichtlich, dass da etwas nach hause telefonieren soll, oder? Ah, Verschwörungstheorien. Na gut, es ist Freitag.
Rufus Τ. F. schrieb: > Hä? Ist das ein Binär-Blob? Das dachte ich. Ist es nicht? Rufus Τ. F. schrieb: > Ah, Verschwörungstheorien. Gib eine alternative Erklärung an wie Arduino Fanboy D. oder lass stecken.
gdfgsdgsg schrieb: > Auch mit dem freeRTOS kann man wie gewohnt arduinolike programmieren Ich arbeite eher mit Atmel Studio und ähnlichem, Arduino verdeckt mir zu viel.
Rufus Τ. F. schrieb: > Hä? Ist das ein Binär-Blob? Ja. https://github.com/espressif/arduino-esp32/tree/master/tools/sdk/lib Und das hat nichts mit Arduino zu tun. Das SDK ist nur so zu bekommen.
gdfgsdgsg schrieb: > void setup(void) > { > > } > > void loop(void) > { > > } > > void my_task(void * pvParameters) > { > setup(); > > while(1) > { > loop(); > portYIELD(); > } > } > > irgendwo musst du einmalig diesen Task erstellen: xTaskCreate( > my_task, "my", 512, NULL , 1 , NULL ); Tycho B. schrieb: > gdfgsdgsg schrieb: >> Auch mit dem freeRTOS kann man wie gewohnt arduinolike programmieren > > Ich arbeite eher mit Atmel Studio und ähnlichem, Arduino verdeckt mir zu > viel. dann gilt das obige trotzdem sieh dann die void my_task(void * pvParameters)" funktion als eine neue "main" an und fertig. vor der endlosschleife kommt deine initalisierung ind fertig in dem loop kommt dein kram rein wenn du das mit RTOS mal verstanden hast , kannst du noch 20 solcher "mains" dazubauen und wirst dich nicht wundern warum das trotzdem läuft ^^
> wenn du das mit RTOS mal verstanden hast , kannst du noch 20 solcher > "mains" dazubauen und wirst dich nicht wundern warum das trotzdem läuft > ^^ Verstehe ich ja. Ich habe keine Skrupel mich ins RTOS einzuarbeiten, die Motivation war eher auf Registerebene einen Doppelkerner und die daraus resultierenden Eigenheiten zu erlernen.
Arduino Fanboy D. schrieb: > Wenn ich mich richtig erinnere gibt es sogar EU Richtlinien, welche sich > explizit damit beschäftigen, und mittlerweile in DE Recht umgesetzt > sind. EU Richtlinien würden aber das Unternehmen wenig daran hindern, in China den Source zu veröffentlichen. Oder in USA. Oder in Neuseeland.
Tycho B. schrieb: > Und meine potentielle Anwendung ist relativ überschaubar, so dass ich > Multithreading zu Lernzwecken selbst implementieren wollte. Vielleicht wäre es sinnvoll, das auf einem ARM (oder RISC-V)-Prozessor zu machen, um die zugehörigen Architektonischen Details einer verbreiteteren Plattform zu erlernen. m.W. gibt es kein einziges WLAN-Modul/Karte mit einer Open Source Firmware. Einige wenige Host-Treiber sind Open Source (z.B. ATWILC1000), aber auf der Karte ist immer noch ein Prozessor mit Binärblob. Mit anderen Worten: WLAN ist eine allgegenwärtige Technologie mit der heutzutage alles™ vernetzt wird, aber keiner weiß wie es funktioniert!
Dr. Sommer schrieb: > Vielleicht wäre es sinnvoll, das auf einem ARM (oder RISC-V)-Prozessor > zu machen Hast du konkrete Vorschläge? Wenn ich mir die Doku anschaue, dann ist es vielleicht wirklich besser. Ich hatte mich wegen Preis und Geschwindigkeit (+WLAN) für den ESP32 entschieden.
Tycho B. schrieb: > Hast du konkrete Vorschläge? Wenn ich mir die Doku anschaue, dann ist es > vielleicht wirklich besser. Die Doku der ARM-Prozessorkerne ist praktisch perfekt. Habe da noch nie eine Uneindeutigkeit, Fehler oder Lücke gefunden oder ein anderes Dokument, was an diese Qualität heranreichen würde. Das gilt natürlich nur für den ARM-Kern, welcher aber hauptsächlich relevant für Multithreading ist. Die ESP sind aber wirklich die billigsten WLAN-Chips und ARM-Kerne sind sowieso immer ein bisschen teurer, d.h. wenn Preis das wichtigste ist (Stückzahl?) dann ist ARM hier nicht das Beste. Es gibt diverse ARM's mit WLAN integriert. Das sind aber immer ARM Cortex-M/R (z.B. TI C3000, Cypress CYW43907) die zwar auch ganz gut für RTOS geeignet sind, aber halt nicht besonders leistungsfähig und auch keinen virtuellen Speicher (MMU) bieten. Wie gut die in Sachen Leistung gegen einen ESP32 abschneiden kann ich nicht einschätzen. 8-Bittern wie AVR sind sie aber um viele Größenordnungen überlegen. Echtzeitfähig und Energie-effizient sind sie sicherlich. Man braucht auch für Multithreading nur sehr wenig Assembler. In Sachen Multithreading sind die Anwendungsprozessoren (ARMv7-A, Cortex-A) deutlich leistungsfähiger, aber auch viel komplexer. Die gibt es m.W. aber nie mit integriertem WLAN; da würde man ein externes Modul z.B. via SDIO anbinden müssen. Hier wären die Prozessoren von TI, NXP, Microchip und neuerdings ST zu nennen, da es hier eine Doku der Prozessor-Peripherie gibt und man diese daher ohne Linux programmieren kann (inkl. eigenem Mutithreading). Das ist dann aber schon "advanced level" und man braucht eine gute Portion Assembler.
Tycho B. schrieb: > EU Richtlinien würden aber das Unternehmen wenig daran hindern, in China > den Source zu veröffentlichen. Oder in USA. Oder in Neuseeland. Das Argument scheint mir nicht allzu tragfähig zu sein. Denn: Damit würden sie aber dann wohl den Vertrieb in die EU unmöglich machen. Den größten, oder zweitgrößten, Markt für ESPs. Ob das wohl gewollt ist? (Nicht ganz) Vergleichbar: Export von Kinderüberraschungseiern in die USA
Tycho B. schrieb: > Ich arbeite eher mit Atmel Studio und ähnlichem, Arduino verdeckt mir zu > viel. Das ist ja auch Sinn der Sache. Sich nicht mit tausenden von Kleinigkeiten Monate- oder sogar Jahrelang beschäftigen zu müssen sondern sich auf das wesentliche zu konzentrieren. Masochisten können sich natürlich auch an die Bare-Metal-Programmierung wagen. Alleine den WLan-Stack von Grund auf selbst zu entwickeln dürfte Arbeit für Monate sein...
Manni schrieb: > Alleine den > WLan-Stack von Grund auf selbst zu entwickeln dürfte Arbeit für Monate > sein... Seeeehr optimistisch. Die WLAN-Hardware und binärblobs zu reverse engineeren um dann einen eigenen Stack zu implementieren dürfte viele Jahre dauern.
Tycho B. schrieb: > Ich hatte mich wegen Preis und > Geschwindigkeit (+WLAN) für den ESP32 entschieden. Wenn Du WLAN brauchst, dann wirst Du kaum um ein Multitaskingsystem herumkommen. Die WLAN Firmware ist in eigenen Tasks gekapselt, das meiste bekommst Du als Anwender nicht zu sehen, was durchaus seine Vorteile hat. Gruß, Stefan
Stefan K. schrieb: > Wenn Du WLAN brauchst, dann wirst Du kaum um ein Multitaskingsystem > herumkommen. Der Host-Treiber vom ATWILC1000 kann asynchron betrieben werden, d.h. nur auf Interrupts reagierend. Dort ist Multithreading nicht zwingend erforderlich, aber je nach Anwendung wahrscheinlich doch sinnvoll.
Dr. Sommer schrieb: > Manni schrieb: >> Alleine den >> WLan-Stack von Grund auf selbst zu entwickeln dürfte Arbeit für Monate >> sein... > > Seeeehr optimistisch. Die WLAN-Hardware und binärblobs zu reverse > engineeren um dann einen eigenen Stack zu implementieren dürfte viele > Jahre dauern. Das wurde zumindest für den ESP8266 schon gemacht und ist beim ESP32 nicht gross anders. Leider, denn der Radio-Watchdog ist somit immer noch buggy. Den Verschwörungstheoretikern kann ich nur raten: Reinschauen. xtensa-Disassembly ist keine Raketenwissenschaft.
Martin S. schrieb: > Das wurde zumindest für den ESP8266 schon gemacht und ist beim ESP32 > nicht gross anders. Leider, denn der Radio-Watchdog ist somit immer noch > buggy. Ach? Gibt's dazu einen Link?
Martin S. schrieb: > xtensa-Disassembly ist keine Raketenwissenschaft. Nö, aber das WLAN-Protokoll mit allen WPA-Modi und zig Erweiterungen sowie das Interface zur Hardware... Das im C-Code zu erkennen dürfte schon eine Herausforderung sein, als Assembler-Code ists nur etwas mehr Fleißarbeit.
Dr. Sommer schrieb: > Manni schrieb: >> Alleine den >> WLan-Stack von Grund auf selbst zu entwickeln dürfte Arbeit für Monate >> sein... > > Seeeehr optimistisch. Die WLAN-Hardware und binärblobs zu reverse > engineeren um dann einen eigenen Stack zu implementieren dürfte viele > Jahre dauern. Nicht umbedingt. Da die Binärblobs schön getrennt sind kann man jeden der Blobs einzeln reversen, selbst implementieren und testen. Da die einzelnen Blobs dann auch nicht besonders groß sind, sollte das relativ fix klappen. Sobald man dann die Wifi Lib komplett selbst nachgebaut hat, kann man dann das FreeRTOS stückweise rauswerfen. Jahre wird man da sicher nicht investieren müssen. Aber ob das wirklich eine sinnvolle Verwendung von mehreren Monaten arbeit ist, ist fraglich.
Ntldr -. schrieb: > Aber ob das wirklich > eine sinnvolle Verwendung von mehreren Monaten arbeit ist, ist fraglich. Die richtige Aufgabe für jemanden, der Vater und Mutter erschlagen hat.
Ntldr -. schrieb: > . Da die > einzelnen Blobs dann auch nicht besonders groß sind, sollte das relativ > fix klappen. Okay... Die Firmware für z.B. das ATWILC1000 ist ca 170kB groß (nur WLAN-Teil, ohne RTOS oder TCP/IP-Stack). Ich habe derzeit das fragwürdige Vergnügen einen Flash-Treiber aus kompiliertem Assembler-Code zu reverse engineeren. Wenn ich da meine Arbeitsgeschwindigkeit hochrechne komme ich auf ca. 1 Jahr nur für die Fingerübung des Dekompilierens. Das Verstehen des Peripherie-Interface und WLAN-Protokolls ist dann noch ein ganz kleines bisschen länger...
Dr. Sommer schrieb: > Ach? Gibt's dazu einen Link? Nein, wurde nicht veröffentlicht. Sind aber einige Leute dran gewesen, die am esp-open-rtos mitmachen/gemacht haben, vielleicht findest du da was. Oder du nimmst dir IDA mit dem Xtensa-Plugin her und nimmst die libphy.a auseinander - man darf sich über die recht deskriptiven Funktionsnamen freuen. Aber es stimmt schon, was oben gesagt wird, so richtig brauchbar ist das alles nicht, was die einzelnen Registerzugriffe in den phy_*.o machen bleibt obskur. Wegen der div. Hardware-Bugs flog der Kram schliesslich definitiv in die Ecke, Fazit: sicher min. zwei Wochen Zeitverschwendung.
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.