Guten Abend Leser. Ich habe eine Protokollimplementierung auf einem RPi gemacht , bei der in jeder Sekunde zwei Bitströme mit je 10.24Mbit im Speicher erzeugt werden. Nun möchte ich diese Bitströme zu einen Modulator über die GPIOs ausgeben. Wie wäre die Datenausgabe auf einem Pi zum Beispiel umsetzbar? Man bräuchte ja einen feingranularen Timer der dann alle 1/10.24M Sekunde eine Routine aufruft um ein Bit des Datenstromes per Bitbanging auszugeben. Gibt es so feingranulare Timer auf einem Pi unter Linux??? Schaft das ein "normaler" Linux-Kernel noch oder sind hier schon RT-Linuxkernel von Nöten? Bei einem uC kann man ja die Takte als Timer auszählen, da hängt dann aber auch kein OS dazwischen. Allerdings würde ich ein Pi o.a. Board und ein Linux bevorzugen, da ich für die Erstellung der 2* 10.24MBit/s Content aus mehreren Programmen mittel TCP/IP Unterprozesskommunikation erhalte. Für ein paar Ratschläge von Leuten die den Pi SoC im Schlaf kennen wäre ich dankbar. Gruß Rudolph
RudolphB schrieb: > Schlaf kennen Das tu ich zwar nicht, es soll aber Leute geben, die eine i2s-Schnittstelle für solchen Kram zweckentfremden. Den LR-Clock und den Bit-Clock lässt man eben im Nichts enden...
Ist nicht machbar. Linux haut dir gerne mal fuer ein paar Millisekunden dazwischen. Auch ein Echzeitlinux wird die 10M nicht schaffen. Hoechstens unter Verwendung eines Schedulers, der zwischen deinem Echtzeittask und dem Linux umschaelt. Dann ist der Betriebssystem-Komfort aber irgendwie wieder weg...
Du könntest die Daten ja auch Byteweise ausgeben. Also nicht seriell and einem GPIO, sondern parallel an 8 GPIO Pins + Takt. Die könnte man dann ja theoretisch im auch wieder serialisieren - aber der der RPi wäre erstmal entlastet. Allerdings wäre die Frage, was es mit Deinem "Modulator" auf sich hat. Kannst Du da überhaupt schnell genug modulieren?
Sowas macht man per DMA über SPI. K.A, ob der RPi sowas hat.
RudolphB schrieb: > Wie wäre die Datenausgabe auf einem Pi zum Beispiel umsetzbar? Bei der Datenrate würd ich versuchen, das in einen kleinen FPGA auszulagern. Dort Bufferst du die Daten und lässt ihn die Daten serialisieren. 10MHz auf einen GPIO mit RT-Linux ist wahnsinnig. Das Ding geht in den Interrupts unter.
wurster schrieb: > Bei der Datenrate würd ich versuchen, das in einen kleinen FPGA > auszulagern. Warum immer gleich mit dem Schlachtschiff FPGA draufballern, wenn ein MC völlig ausreicht. Z.B. der LPC1769 hat 2 SPI, die können bis 50MBit und haben einen 8*16Bit FIFO, DMA können die auch.
Wie wär's damit: Beitrag "Arduino Nucleo-H743ZI" Damit könnte das Problem mit der Spi in ein paar Zeilen Code gelöst sein. https://arduino.stackexchange.com/questions/16348/how-do-you-use-spi-on-an-arduino
Marvin schrieb: > Allerdings wäre die Frage, was es mit Deinem "Modulator" auf sich hat. > Kannst Du da überhaupt schnell genug modulieren? Das ist kein Problem und auch nicht die Frage. Diese "Blackbox" muss nur kontinuierlich ohne Aussetzter 2x 10.24 MBit/s empfangen. Der Knackpunkt ist momentan nur die Ausgabe von 2x10.24 MBit/s am GPIO. Einige Nutzer schreiben ja, das Linux das nicht zulässt? Das dürfte dann doch aber sicher nur den Userspace betreffen oder wie schaufelt das System USB2/3 oder Ethernet mit weit höheren Datenraten rein/raus? Ließe sich nicht über ein Gerätetreiber mehr Echtzeitverhalten aus einem normalen Kernel rausholen? Als Ultima Ratio würde ich eventuell die Daten per Ethernet auf ein STM32H7 (Nucleo Board mit 400 MHz Takt) senden und die Daten dort per GPIOs ins Auge fassen. Aber eigentlich sollten doch "läppische" 2x 10 MBit auch per Gerätetreiber auf einem Linux-Board möglich sein ohne das Linux da einen ein Bein stellt?
RudolphB schrieb: > ein Gerätetreiber mehr Echtzeitverhalten Ja Kernelmodul ist schneller und mit weniger Jitter. RudolphB schrieb: > oder wie schaufelt das > System USB2/3 oder Ethernet Nicht bitgenau und in Echtzeit in den Userspace...
RudolphB schrieb: > Der Knackpunkt ist momentan nur die Ausgabe von 2x10.24 MBit/s am GPIO. > > Einige Nutzer schreiben ja, das Linux das nicht zulässt? Das dürfte dann > doch aber sicher nur den Userspace betreffen oder wie schaufelt das > System USB2/3 oder Ethernet mit weit höheren Datenraten rein/raus? 1. mit spezialisierter Hardware. Die Serialisierung wird in Hardware gemacht und die Hardware hat dedizierte Buffer, die über einen breiten und schnellen Bus gefüllt werden. 2. mit Kernel-Treibern. Spätestens dann, wenn Datenmengen größer als der Hardware-Buffer übertragen werden sollen, braucht man DMA und Interrupts und eben einen Kernel-Treiber, der das handlen kann. > Ließe sich nicht über ein Gerätetreiber mehr Echtzeitverhalten Mit Echtzeit hat das so erstmal nichts zu tun. > Als Ultima Ratio würde ich eventuell die Daten per Ethernet auf ein > STM32H7 (Nucleo Board mit 400 MHz Takt) senden und die Daten dort per > GPIOs ins Auge fassen. GPIO impliziert "in Software am Pin wackeln". Und da wirst du dich auch auf einem 400MHz ARM schwer damit tun, 10.24 MBit rein in Software zeitsynchron hinzubekommen. Ein SPI wirst du schon wenigstens dafür brauchen.
Axel S. schrieb: > Ein SPI wirst du schon wenigstens dafür > brauchen. Zu den SPI auf dem Pi habe ich nun zwei verschiedene Sachen gefunden. 1. der Pi unterstützt generell nur 500kHz als Geschwindigkeit. 2. Der Treiber spi_bcm2835/spi_bcm2708 unterstützt folgende Geschwindigkeiten: cdiv speed cdiv speed 2 125.0 MHz 4 62.5 MHz 8 31.2 MHz 16 15.6 MHz 32 7.8 MHz 64 3.9 MHz 128 1953 kHz 256 976 kHz 512 488 kHz 1024 244 kHz 2048 122 kHz 4096 61 kHz 8192 30.5 kHz 16384 15.2 kHz 32768 7629 Hz ... für 10.24 Mbit bräuchte ich theoretisch ein cdiv von 24.4140625 ... Hmmmm. Müsste man die den Signalgenerator so verändern können, das bei 10.24 MBit ein ganzzahliges cdiv möglich wird.
RudolphB schrieb: > Axel S. schrieb: >> Ein SPI wirst du schon wenigstens dafür >> brauchen. ... > Der Treiber spi_bcm2835/spi_bcm2708 unterstützt folgende > Geschwindigkeiten: ... > für 10.24 Mbit bräuchte ich theoretisch ein cdiv von 24.4140625 ... > Hmmmm. Siehste. Der nächste Grund, der gegen den RasPi spricht. An einen Cortex-M kannst du zumindest im Prinzip einen Quarz deiner Wahl dranhängen, der dir die gewünschte, krumme SPI-Taktfrequenz erlaubt. Wobei sich dann gleich die nächste Frage stellt, ob du damit auch das Ethernet zum Laufen kriegst.
Axel S. schrieb: > Wobei sich dann gleich die nächste Frage stellt, ob du damit auch das > Ethernet zum Laufen kriegst. Wobei man den Ethernet Part zur Not mit einem separaten Chip realisieren kann, der seinen eigenen Quarz hat.
Man könnte beim H743 die SPI als Slave benutzen, und den 10.24MHz Takt extern an die SPI-führen. Dann muss man auch nichts an F_CPU drehen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.