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!?
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.
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.
> 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
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.