ESP32 ohne FreeRTOS

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..

Tycho B. schrieb:
> D.h. WLAN ist bare metal gar nicht
> möglich?

Ja, das ist mein Wissensstand!
Aber ohne Gewähr.

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.

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 
^^

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!

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.

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.

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.

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.