Mit uC oder RPi einen Bitstrom ausgeben

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?

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.

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...

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.

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.