Hallo liebes Forum, ich hätte eine Frage zum Abschätzen in Bezug auf den Raspberry Pi 4 und der Datenaufnahme. Also ob man das was ich vor habe versuchen könnte oder es von vorne rein aussichtslos ist. Ein 8Ch-ADC (ADS8344) soll über eine SPI-Schnittstelle seine Messdaten (Abstastrate pro Kanal: ~10ksps) zum Rasp schicken und abspeichern. Das heißt man wäre bei ca. 1,9MBit/s Datenrate (24Bit*8Kanäle*10ksps). Ein Messzyklus besteht in meinen Wunschvorstellungen aus der Abtastung von 600 Punkten pro Kanal, d.h. 600Punkte*10ksps = 60ms Messzeit. Dieser Zyklus soll alle 100ms wiederholte werden, sprich es gibt 40ms Pause. Wäre so etwas grundlegend machbar?
Die SPI-Schnittstelle wäre schnell genug. Die Schreibgeschwindigkeit auf die SD-Karte (oder USB-Stick) wäre schnell genug. Die Anwendung für das Auslesen und Schreiben muss in einer Programmiersprache der Geschwindigkeit wie C sein.
Gast
#6490463
Bei den alten Raspis konnte man zeitlich fuer gar nichts garantieren. Ob das bei den "neuen" besser geworden ist, weiss ich nicht. Raspi war damals bei mir raus.
Beitrag #6490470 wurde von einem Moderator gelöscht.
Gast
#6490528
ElecEddy R. schrieb: > Wäre so etwas grundlegend machbar? Nein. Ein rPi ist genau so wenig echtzeitfähig wie dein Windows-PC. Und falls du ihn ohne Linux programmieren wolltest: er ist weitgehend undokumentiert. Also völlig ungeeignet.
Gast
#6490532
ElecEddy R. schrieb: > Dieser Zyklus soll alle 100ms wiederholte werden Wie genau muss das sein? Der Pi ist nicht Echtzeit fähig, wenn dem OS irgendwas anderes einfällt startet deine nächste Messung halt später. Ich würde das ganze zeitkritische Zeug auf einem eigenen Controller machen z.B. STM32 Die Messdaten schiebt der dann mit Zeitstempel versehen z.B. per Ethernet rüber.
Gast
#6490549
Es scheint auch für den Raspberry Pi Echtzeit-Linux-Implementationen zu geben: https://www.embedded-software-engineering.de/echtzeit-mit-dem-raspberry-pi-und-linux-preemptrt-a-630498/ Ob die Echtzeitfähigkeit "hart genug" ist, kann ich nicht beurteilen, 17µS Latenz klingt bei 200ms Abtastrate aber nicht komplett daneben. MfG, Arno
ElecEddy R. schrieb: > 24Bit*8Kanäle*10ksps https://www.mikrocontroller.net/part/ADS8344 mit einem 16-Bit ADC? woher stammen die zusätzlichen 8 Bit?
Joachim B. schrieb: > ElecEddy R. schrieb: >> 24Bit*8Kanäle*10ksps > https://www.mikrocontroller.net/part/ADS8344 > mit einem 16-Bit ADC? > > woher stammen die zusätzlichen 8 Bit? die zusätzlichen 8 Bits sind Controlbits (Start bit, Channel select...) die den eigentlichen 16 Datenbits vorangestellt sind.
Ok, erstmal danke für die ganzen Abschätzungen. Das hilft mir sehr. Ich denke demnach auch, dass es eine gute Idee ist einen Mikrocontroller zwischen ADC und Rasp für die zeitkritischen Dinge zu bauen. Der Rasp dient dann nur zum Starten der Messung und zur Anzeige der Daten, welche er über USB oder Ethernet mit Zeitstempel bekommt. Zumal im System auch noch ein DAC (AD5761) angesteuert werden müsste, welcher im 10ksps Takt Spannungswerte einstellt. Also wäre dann der Ablauf: --> Messzyklus starten auf Rasp 4 --> µC wird initialisiert --> µC startet Messprogramm --> Spannung wird von DAC(AD5761) mit 10ksps eingestellt --> Spannung wird auf 8 Kanäle aufgeteilt --> 8 Kanäle werden von ADC(ADS8344) mit 10ksps digitalisiert --> Daten kommen über SPI zu µC und bekommen Zeitstempel --> Messdaten über USB/Ethernet zu Rasp --> Messzyklus beenden und Daten anzeigen auf Rasp Bei der Datenmenge von wenigen Mbit/s (2... 3... 4 Mbit/s) sollte USB doch eigentlich reichen, oder würde Ethernet einen wichtigen Vorteil haben? Zwecks µC, ich hab hier noch ein MSP-EXP430F5529LP und ein LAUNCHXL-F28379D liegen. Eines von beiden sollte das doch schaffen können. Ich bin nur noch nicht ganz draus schlau geworden, ob diese genug SPI-Interfaces (2) haben um sowohl den DAC als auch den ADC mit bespielen zu können (bspw. über CS).
MaWin schrieb: > ElecEddy R. schrieb: >> Wäre so etwas grundlegend machbar? > > Nein. > > Ein rPi ist genau so wenig echtzeitfähig wie dein Windows-PC. Ja, nein, ... vielleicht doch. Mit so einem Linux kann man ein paar ziemlich lustige Sachen tun. Es gibt da ja so Realtime-Patches, außerdem RTAI und Xenomai. Womöglich kann man seine Software auch als Kernelthread bauen... Außerdem kann man den Scheduler des Linux-Kernels mit dem Bootparameter isolcpus anweisen, einen oder mehrere CPU-Cores nicht zu benutzen. Diese sind dann (bis auf die zwingend notwendigen Interrupts) frei für Echtzeitprozesse, an die sie per taskset(1) gebunden werden können... YMMV. > Und falls du ihn ohne Linux programmieren wolltest: er ist weitgehend > undokumentiert. Das gilt lediglich für den VideoCore, aber nicht für die CPU. Das Lustige ist, daß die meisten Menschen mit dem Begriff "Echtzeit" etwas ganz anderes verbinden als Leute, die sich damit auskennen. Nachzulesen hier [1]. [1] https://de.wikipedia.org/wiki/Echtzeit
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.