Geschwindigkeitsgewinn Raspberry "bare metal" vs. Linux

Harald Gast #5937565
Lesenswert?
• ▲
▼ 
Benötigt man schnellen I/O, den ein uC (STM32,  Pic32,...) eventuell 
nicht mehr  packt, dann wird oft zu einem FPGA geraten. Bei Raspberrys 
oder anderen SoCs hört man das ein Echtzeitbetrieb nicht möglich ist. 
Gut das mag sein wenn ein Linux drauf werkelt, dabei ist ein Raspberry 
doch auch nichts anderes als ein uC-Evalboard! Ohne Linux, bestenfalls 
ein kleiner RT-Microkernel oder doch ganz "bare metal" programmiert, 
müsste so ein Raspberry doch deutlich leistungsfähiger sein, sodaß sich 
die Notwendigkeit eines FPGAs  weit nach hinten verlagern müsste!  Hat 
schonmal jemand ein Vergleichstest Pi+Linux und Pi+bare metal 
vorgenommen? Welche Schaltfrequenzen lassen sich beispielsweise auf den 
GPIOs erreichen?  Ich vermute mal ein 100 - 200 MSPS ADC/DAC könnte man 
direkt am Pin-Header treiben, etwas was mit Linux auf der Kiste nicht 
funktioniert!?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Max D. #5937571
Lesenswert?
• ▲
▼ 
Die CPU ist zwar schnell darin durch einen großen Datenblock 
durchzureißen. Aber wenn es ans GPIO geht ist ganz schnell Schluss mit 
xGhz Rechenleistung. Das ist erstmal ein cache-miss und dann springst du 
und die pipeline ist leer. Dann lacht jeder AVR über die Zugriffszeiten 
(leicht übertrieben).
Je nach Anwendung rettet der DMA ein bißchen was, aber auch da ist 
bitbanging im zweistelligen MHz Bereich mehr Glück.
Und sobald das I/O nichtnur schnell sondern auchnoch 
vorhersagbar/präzise sein muss (wie bei nahezu allen 
realtime-Anwendungen) ist komplett Ende im Gelände.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
foobar Gast #5937572
Lesenswert?
• ▲
▼ 
Das Problem dieser Application-CPUs ist, dass die Ausführungszeit der 
einzelnen Befehle nicht deterministisch ist.  Die ganzen Caches, die 
MMU, die Busse (mit Fifos, Arbitrierung) etc führen dazu, dass das 
Laufzeitverhalten nicht mehr nur von dem eigentlichen Code abhängt, 
sondern von dem, was vorher ausgeführt wurde, was sonst noch im System 
aktiv ist, dem aktuellen Mondstand, usw.  Ein Cache-Miss z.B. erzeugt 
mal problemlos ein paar 100 Wartezyklen; wenn die Grafik-Einheit ne hohe 
Auflösung fährt, wird das RAM auf einmal langsamer; usw.  Aus diesem 
Grunde haben solche CPUs auch für alle I/O-Protokolle extra HW-Blöcke - 
Bitbanging geht auf denen nicht.

Das Betriebssystem selbst ist das kleinere Problem.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Olaf Gast #5937608
Lesenswert?
• ▲
▼ 
> Aus diesem Grunde haben solche CPUs auch für alle I/O-Protokolle extra
> HW-Blöcke - Bitbanging geht auf denen nicht.

Und das gilt im Prinzip auch fuer alle schnelleren Mikrocontroller. Die 
haben dann ja auch einen IO-Takt der langsamer ist als der Core. (und 
oft auch einen Cache!)

Olaf
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Sportler Gast #5937619
Lesenswert?
• ▲
▼ 
Harald schrieb:
> Ich vermute mal ein 100 - 200 MSPS ADC/DAC könnte man
> direkt am Pin-Header treiben, etwas was mit Linux auf der Kiste nicht
> funktioniert!?

100 - 200 MSPS ADC/DAC sind so zwischen 1 Gigabit/sec bis 4 Gigbit/sec.

Das am Pinheader ohne DMA ist gelinde gesagt: sportlich.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rolf M. #5937621
Lesenswert?
• ▲
▼ 
Kann mich da anschließen. Oft wird gedacht, so ein schneller µC oder ein 
SOC ist wie ein AVR, nur x mal so schnell, also muss ich doch auch x mal 
so schnell einen Pin wackeln lassen können. Das ist ein Trugschluss.
Die ganze Hardware ist für sowas überhaupt nicht gemacht. Sie wurde 
nicht entwickelt mit dem Gedanken im Hinterkopf, deterministisches 
Timing im ns-Bereich zu erzielen, sondern einen möglichst hohen 
Datendurchsatz.
Das ist wie bei den Internet-Verbindungen, wo sich der Gamer wundert, 
dass er trotz 250 MBit einen großen "lag" hat - man muss zwischen Latenz 
und Durchsatz unterscheiden, auch wenn beides oft als "Geschwindigkeit" 
bezeichnet wird.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dr. Sommer Gast #5937642
Lesenswert?
• ▲
▼ 
Erwähnenswert sind hier die TI Sitara Prozessoren (bastlerfreundlich in 
Form des Beagle Bone Black zu haben), welche mit den PRU so eine Art 
echtzeitfähige Mikrocontroller Kerne und DSP Kerne integrieren, sodass 
man hier geringe Latenz mit hoher Rechenleistung verbinden kann. Dank 
(bis auf 3D-Beschleuniger) vollständiger Dokumentation der Peripherie 
kann man diese auch gut Bare Metal, ohne Linux, ggf. mit RTOS, 
programmieren. Das ist allerdings nicht ganz so einfach, und das 
Preis-Rechenleistungs-Verhältnis ist schlechter als beim R-PI.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren