Forum: Mikrocontroller und Digitale Elektronik Geschwindigkeitsgewinn Raspberry "bare metal" vs. Linux


von Harald (Gast)


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!?

von Max D. (max_d)


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.

von foobar (Gast)


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.

von Olaf (Gast)


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

von Sportler (Gast)


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.

von Rolf M. (rmagnus)


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.

von Dr. Sommer (Gast)


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.

Bitte 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
Noch kein Account? Hier anmelden.