Wie ist das eigentlich bei Multicore Mikrocontrollern ?

[Hurzilein (Gast)]

Vermutlich wird sich ja kaum jemand Multicore ohne Betriebssystem antun, 
oder ?

Aber so für den Fall : wie sieht das in C aus ? Gibt es da main1() bis 
main8() oder startet erstmal nur ein Core, initialisiert alles und setzt 
dann die anderen auf die Spur, was sie abarbeiten sollen ?

[100Ω W. (tr0ll)]

FreeRTOS ist dir bekannt?
Hier ist eine Anleitung für den ESP32: 
https://microcontrollerslab.com/esp32-dual-core-freertos-arduino-ide/

[Daniel F. (foxi_the_daywalker)]

Hi,

kommt drauf an.
Es gibt auch Microcontroller mit Multicore. Da kann man den zweiten, 
kleineren Kern gerne mal nur für ein Protokoll arbeiten lassen und auf 
dem Hauptkern läuft das eigentliche Programm.
Da braucht man auch nicht unbedingt ein typisches Betriebssystem.
Nebenbei bemerkt: Ich empfinde den Übergang von einfacher "Firmware" zu 
"Betriebssystem" immer mehr als fließend.

Gruß
Daniel

[Andras H. (kyrk)]

Es gibt 2 Ansätze:
- ein Kompilat machen
    * und im Laufzeit dynamisch entscheiden ob wir CoreX sind
    * und jedes Core hat eigene einsprungadressen (praktisch mainx())
- jedes Core bekommt einen eigenen Kompilat

Beide Systeme haben vor und Nachteile. Nicht unbedingt muss der OS alle 
Cores kennen. Manchmal will der User die Inter Core Communikation selber 
machen und nimmt halt einen OS was nur Single Core kann. Oder man hat 
nur auf dem einen Core einen OS, und die anderen laufen ohne OS (nur mit 
einen Scheduler). Manchmal hast du auf einen Core einen Hypervisor.

Oft hast du einen Core der von dem HW gestartet wird. Dieser Core 
startet die anderen Cores dann und gibt denen die Einsprungadresse vor. 
Manche machen das über den OS, manche manuell aus dem eigenen C Code.

Es gibt alles :) Und es wird immer variiert. Je nach dem was deine Kunde 
haben möchte. Nicht alle Variationen machen Sinn. Manches wird 
aussterben, manches wird überleben.

[someone else (Gast)]

Hurzilein schrieb:
> Vermutlich wird sich ja kaum jemand Multicore ohne Betriebssystem antun,
> oder ?

Warum so pauschal? Ich finds auf den bis Mittelklasse µC echt simpel. 
Gleiche Cores, die man sich nach Wunsch aufteilen (und takten) kann. Wie 
es mit dem FreeRTOS Scheduler bei power/efficient Core Designs ist, kann 
ich allerdings mangels Erfahrung nicht sagen.

Beim Desktop Betriebssystem auf x86_64 kannste in den höheren Sprachen 
deine Threads/Worker/wie auch immer genannt losschicken und der 
Scheduler vom OS kümmert sich dann darum und man muss sich darauf 
verlassen, dass der gescheit seinen Job tut. Da drum herum arbeiten, 
ist, je nach OS, ziemlich murksiger Aufwand. Das ist bei so Dingen wie 
CCX, CCD, P-Cores, E-Cores, wo, wie, welcher Cache angebunden ist, inkl. 
stark variablen Taktfrequenzen eine undankbare Aufgabe. Insofern bin ich 
dann ab dieser Ebene froh, dass sich andere, darauf spezialisierte, den 
Kopf zerbrechen dürfen und das OS es für mich erledigt.

[c-hater (Gast)]

Hurzilein schrieb:

> Vermutlich wird sich ja kaum jemand Multicore ohne Betriebssystem antun,
> oder ?

Doch, z.B. mit dem SDK für den Raspi Pico ist das kein großes Ding.

> Aber so für den Fall : wie sieht das in C aus ?

Im Falle o.g. SDKs: ein Aufruf startet Core1 und läßt ihn mit der 
Abarbeitung des Programms ab dem als Parameter übergebenen Funktion 
starten.

Wie man dann die Verteilung der Arbeit im Detail organisiert, ist recht 
variabel. Am einfachsten ist es, mit dem Core1 über Queues zu 
kommunizieren. Eine Queue, um ihn mit Arbeit zu versorgen, eine weitere, 
um die Ergebnisse zurück zu bekommen.
Aber wie gesagt: es gibt auch noch unzählige andere Möglichkeiten, die 
ggf. sinnvoller sind. Hängt halt von der Anwendung ab, was sinnvoll ist.

> Gibt es da main1()

Man kann die als Parameter übergebene Funktion auch gerne main1 nennen. 
Das SDK hat da nix gegen einzuwenden. Das weiß: Namen sind Schall und 
Rauch, tatsächlich wir natürlich letztlich einfach eine Speicheradresse 
übergeben...

[Frank K. (fchk)]

Hurzilein schrieb:
> Vermutlich wird sich ja kaum jemand Multicore ohne Betriebssystem antun,
> oder ?
>
> Aber so für den Fall : wie sieht das in C aus ? Gibt es da main1() bis
> main8() oder startet erstmal nur ein Core, initialisiert alles und setzt
> dann die anderen auf die Spur, was sie abarbeiten sollen ?

Konkretes Beispiel:
https://www.microchip.com/en-us/product/dsPIC33CH256MP205

Kern 1 startet, lädt den Code für Kern 2 aus dem Flash in das PRAM von 
Kern 2 und startet ihn. Da RAM schneller als Flash ist, läuft der Kern 2 
mit 100 MHz, Kern 1 aber nur mit 90 MHz.

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/DataSheets/dsPIC33CH512MP508-Family-Data-Sheet-DS70005371D.pdf

ab Seite 17.

Bei anderen Prozessoren ist das wieder ganz anders.

fchk

[Olaf (Gast)]

> Aber so für den Fall : wie sieht das in C aus ? Gibt es da main1()

Beim RP2040 startet erstmal ein Core. (core0) In dessen Task kannst du
dann die Startadresse des zweiten Cores setzen und den einschalten.
Also im Prinzip gibt du dem eine Funktion und etwas Stack und
schaltest ein und es laeuft.

  //Das hier muss passieren bevor ein IRQ installiert wird                                        
  core1_reset(); //Core Reseten und anhalten                                                      
  //core1-main-funktion, begin des stackspeichers, stacksize in byte                              
  core1_start(main_core1, core1_stack, CORE1_STACKSIZE_LEVEL*4);

> Vermutlich wird sich ja kaum jemand Multicore ohne Betriebssystem antun,
> oder ?

Warum? Haengt halt davon ab welches Problem du loesen willst.

Olaf