Raspberry Pi Pico für Datenanalyse

[Michael (michael_b2)]

Hallo zusammen

Ich wollte eine Machbarkeit mit dem Raspberry Pi Pico prüfen für ein 
Projekt, bin aber bisher nicht weitergekommen, bzw. erhalte verschiedene 
Aussagen im Web dazu. Vielleicht kann hier jemand helfen, der sich 
besser auskennt?

Geplant ist, sieben Signalleitungen auszuwerten. Eine Signalleitung 
davon gibt einen Takt vor:
Ein logisches Signal 1 (high) für 125 ns gefolgt von einem logischen 
Signal 0 (low) für 125 ns. Immer bei 1 soll der Zustand aller Leitungen 
erfasst werden (für jede Leitung gilt ebenfalls 0 oder 1).

Zusammen mit den steigenden und sinkenden Flanken dauert das Taktsignal 
von 0 auf 1 mindestens 334 ns gemäss Herstellerangaben. Das würde 
heissen, dass pro Sekunde ganze 2'994'012 Datensamples erfasst werden 
müssten, oder knapp 3 Msps => 3 MHz. Wenn man beim Taktsignal auch die 0 
als Signal zählt, sind wir bei 5'988'024 sps => 6 Mhz. Gemessen werden 
müsste somit mit 6 MHz.

Die 334 ns sind jedoch die kleinst mögliche Zeitspanne für den Takt.
Effektiv sind es 15'360 Datenpunkte mit einer Refreshrate von 70 Hz, +/- 
5 Hz. Mit 75 Hz als Maximum wären wir bei 1'152'000 sps oder 2'304'000 
sps. Somit 2.3 MHz. Nun ist es aber so, dass nur 2'304'000 sps pro 
Sekunde gesammelt werden, aber es vorkommen kann, dass zwei Datenpunkte 
in 334 ns Abstand kommen, auch wenn im Durchschnitt nur alle 868 ns ein 
Datenpunkt kommt. Würde heissen, dass die Abtastrate doch auch 6 MHz 
sein kann, da ja immer bei Takt = 1 abgetastet werden muss.

Was ich bisher ausfindigmachen konnte:
- Es ist auf jedenfall C/C++ notwendig, da mit Micropython maximal circa 
55-60 kHz möglich sind.
- Benchmarktests haben Signalabtastraten von 120 Mhz gezeigt => wäre 
also theoretisch mehr als genügend Luft nach oben. 120 MHz wäre ja eine 
Abtastrate von 1 sp / 8.33 ns...

Nun ist die Frage: Benchmarktest ist das eine, aber ist es auch 
realistisch aus 7 Kanälen die Werte gleichzeitig zu beziehen? Das wäre 
ja pro Takt 7 Datenpunkte, somit die 7-fache Menge. Es ist zu erwähnen, 
dass die Daten nicht gespeichert werden sollen auf dem Pico sondern 
direkt über USB auf den PC übertragen werden. Jeweils 15'360 Datenpunkte 
müssen zusammenhängend bleiben. Und ebenfalls zu erwähnen ist, dass die 
Refreshrate von 75 Hz beim übertragen der Daten nicht notwendig wäre. 
Theoretisch wäre es ausreichend, die ersten 15'360 Datenpunkte pro 
Sekunde zu erfassen, was an der Datenmenge etwas ändert, jedoch nicht an 
der Abtastrate. Die Datenpunkte ändern sich nämlich nur dann, wenn der 
Nutzer dies aktiv auslöst. Es ist jedoch an dem Gerät, von dem die 7 
Datenleitungen kommen, nicht möglich, pro Sekunde mehr als einmal die 
Datenpunkte zu ändern. Es ist sogar eher so, dass die Daten eher alle 
3-5 Sekunden geändert werden können maximal. Aber weiterhin muss die 
Abtastrate gleich hoch bleiben, da zwingend 15'360 Datenpunke 
nacheinander ausgelesen werden müssen, damit die Daten in sich schlüssig 
sind.

Was meint ihr dazu?

Gruss und Danke
Michael

[Michael H. (mha1)]

Selbst der ältere Raspberry Pico RP2040 wird sich dabei langweilen, wenn 
man es vernünftig in C/C++ umsetzt.

Das Einlesen der Daten macht man über die PIO. Damit belastet man die 
CPU Cores nicht. Ein Core bereitet die eingelesenen Daten auf und der 
zweite Core kümmert sich um den USB Transfer.

Das sollte bei Einsatz der PIO für das Einlesen der Daten sogar mit 
µPython machbar sein.

[Rainer W. (rawi)]

Michael schrieb:
> Was meint ihr dazu?

> Eine Signalleitung davon gibt einen Takt vor:
> Ein logisches Signal 1 (high) für 125 ns gefolgt von einem logischen
> Signal 0 (low) für 125 ns.

Das ergibt nach meiner Rechnung zusammen 250 ns.

> Zusammen mit den steigenden und sinkenden Flanken dauert das Taktsignal
> von 0 auf 1 mindestens 334 ns gemäss Herstellerangaben.

Da sehe ich gegenüber deiner Angabe "high" für 125 ns + "low" für 125 ns 
eine deutliche Diskrepanz. Wie reimt sich das zusammen?
Vielleicht zeigst du einmal direkt die Herstellerangabe.

> Nun ist die Frage: ..., aber ist es auch realistisch aus 7 Kanälen
> die Werte gleichzeitig zu beziehen?
> Das wäre ja pro Takt 7 Datenpunkte, somit die 7-fache Menge.

Üblicherweise würde man die 7 Signale bei einem Mikrocontroller alle auf 
den selben Port legen, so dass man sie parallel einlesen kann. Pro 
Auslesung erhält man dann mit einem einzigen I/O-Zugriff ein Byte mit 
allen Signalen.

[N. M. (mani)]

Schau Mal da:
https://github.com/gusmanb/logicanalyzer

Da kann man sicher etwas abschauen.
Er bekommt sogar 24 Kanäle mit 200/400MSPS hin.
Allerdings nicht im Streaming Modus.

Wobei auslesen alle 3-5s sicher auch machbar sein sollten.

[Andreas B. (bitverdreher)]

N. M. schrieb:
> Allerdings nicht im Streaming Modus.

Das ist allerdings den lahmen USB-2 Interface geschuldet.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michael schrieb:
> Würde heissen, dass die Abtastrate doch auch 6 MHz sein kann, da ja
> immer bei Takt = 1 abgetastet werden muss.
Ich will da nicht mit den Herren Shannon und Nyquist kommen, weil wir 
hier digital unterwegs sind, aber auch digital muss man bei der 
asynchronen Abtastung von Signalen das zu messende Signal 
"überabtasten"(**). Denn sonst kannst es leicht passieren, dass die 
Setup/Hold-Zeiten zum Einlesen der Information nicht beachtet werden. 
Fazit: sporadisch "umgekippte" Bits.

> gemäss Herstellerangaben
Was gibt denn der Hesteller sonst noch an? Wie lange vor der steigenden 
Flanke sind die Daten bereits valide? Wie lange nach der fallenden 
Taktflanke sind sie noch stabil?

Ein Tipp: ein simpler Link aufs Datenblatt des Bausteins reicht.

> Immer bei 1 soll der Zustand aller Leitungen erfasst werden
Einzig möglicherweise funktionierende Lösung: du liest immer alle 7 
Leitungen zusammen mit der Taktleitung am selben Port ein. Dann suchst 
du in diesen Samples den Zustand, wo die Taktleitung sicher 1 ist. Und 
das ist dann das Sample, das den gültigen Pegel der Datenleitungen 
enthält.

Der falsche Weg wäre, ständig "nur" die Taktleitung abzufragen, und dann 
erst, wenn dort eine 1 erkannt wurde, die Daten einzulesen. Denn wenn 
dann zwischen "Erkennen" und "Einlesen" ein winzig kurzer Interrupt oder 
DMA-Zugriff reinfunkt, dann passen die Daten nicht mehr zur Taktleitung.

> Es ist zu erwähnen, dass die Daten nicht gespeichert werden sollen auf
> dem Pico sondern direkt über USB auf den PC übertragen werden. Jeweils
> 15'360 Datenpunkte müssen zusammenhängend bleiben.
Und dafür brauchst du noch einiges an Software, die "nebenher" den 
dauernd ankommenden Datenstrom analysiert, verwaltet und bearbeitet.

Ob dir dann genau irgendwelche ungeschickt programmierten Interrupts 
oder DMA-Blockaden auf dem internen Bus die äquidistante (oder 
wenigstens ausreichend schnelle) Abtastung zerhageln, das findest du 
dann schnell genug heraus.

(**) bei meinen FPGA-Lösungen gehe ich da wenn möglich mindestens auf 
eine 8-fache Überabtastung. In deinem Fall mit einer Signalfrequenz 
60MHz oder einer Pulsdauer von 125ns von wären das 50MHz. Und dank 
paralleler Hardware wird da der isochrone Ablauf sicher nie von einer 
anderen Komponente ausgebremst.

EDIT:
Mein erster Ansatz für dein Problem wäre also sicherzustellen, dass das 
System schnell und jitterfrei genug ist. Und dafür würde ich in der 
Abtast-Routine anfangs einen Ausgang zu toggeln. Diesen Ausgang dann an 
ein Oszilloskop anschließen und das auf "Triggerung Pulsdauer" und 
"Nachleuchtzeit ewig" stellen. Mit der passenden Einstellung für die 
Pulsdauer siehst du dann, ob die Abtastung mal "geruckelt" hat.

[Michael (michael_b2)]

Rainer W. schrieb:
> Das ergibt nach meiner Rechnung zusammen 250 ns.

> Da sehe ich gegenüber deiner Angabe "high" für 125 ns + "low" für 125 ns
> eine deutliche Diskrepanz. Wie reimt sich das zusammen?
> Vielleicht zeigst du einmal direkt die Herstellerangabe.

Beispiel:
Signal ist zum Zeitpunkt 0 auf Low.
Dann erfolgt steigende Flanke mit Dauer von 42 ns.
Danach ist Signal für 125 ns high.
Danach erfolgt sinkende Flanke mit Dauer von 42 ns.
Danach ist Signal für 125 ns wieder low.

Eine solche Taktabfolge ist somit 42 + 125 + 42 + 125 = 334 ns.

> Üblicherweise würde man die 7 Signale bei einem Mikrocontroller alle auf
> den selben Port legen, so dass man sie parallel einlesen kann. Pro
> Auslesung erhält man dann mit einem einzigen I/O-Zugriff ein Byte mit
> allen Signalen.

Dann hätte ich an einem Pin 7 Signale, die alle entweder Low < 0.8 Volt 
bringen oder high > 2.0 Volt. Wie kann der Pin zwischen diesen Signalen 
unterscheiden und wissen, welches Kabel nun was ist? Dass kann ich mir 
gerade so nicht vorstellen.

[Michael (michael_b2)]

Hier die Herstellerangaben zum Signal.
Das Taktsignal wäre CL2.

Zu erwähnen wäre noch, dass der Hersteller des Gerätes einen Adapter 
anbietet, um das Signal auszuwerten und auf den PC zu übertragen. Leider 
ist der Adapter nicht mehr erhältlich und der Hersteller behauptet, 
keine Angaben mehr im Archiv dazu zu haben. Einzige Info die ich dazu 
erhalten habe ich, dass das Signal mittels LCA Circuit unteranderem 
übertragen wurde.

[Thomas W. (Gast)]

Michael schrieb:

>> Üblicherweise würde man die 7 Signale bei einem Mikrocontroller alle auf
>> den selben Port legen, so dass man sie parallel einlesen kann. Pro
>> Auslesung erhält man dann mit einem einzigen I/O-Zugriff ein Byte mit
>> allen Signalen.
>
> Dann hätte ich an einem Pin 7 Signale, die alle entweder Low < 0.8 Volt
> bringen oder high > 2.0 Volt. Wie kann der Pin zwischen diesen Signalen
> unterscheiden und wissen, welches Kabel nun was ist? Dass kann ich mir
> gerade so nicht vorstellen.

Ein Port hat (beim RaspberryPi) acht Bit Ein/Ausgang. Und ein Byte (acht 
bit) eine natuerliche Groesse beim Mikrocontroller.

[Clemens S. (zoggl)]

Michael schrieb:
> sieben Signalleitungen auszuwerten

Michael schrieb:
> Hier die Herstellerangaben zum Signal.

ich sehe hier nur 4

warum einen Raspberry?

nimm einen logic analyzer und schreib dafür eine Auswertung am PC.

https://www.sparkfun.com/usb-logic-analyzer-24mhz-8-channel.html

und vielleicht benennst du den geheimen Hersteller. vielleicht hat 
jemand einen Adapter herumliegen.

sg

[Rainer W. (rawi)]

Michael schrieb:
> Dann hätte ich an einem Pin 7 Signale, ...

nicht an einem Pin, sondern an einem Port.
Frag mal jemand aus der Hardware-Ecke.

> Wie kann der Pin zwischen diesen Signalen unterscheiden und wissen,
> welches Kabel nun was ist?

z.B.
Signal i im Bit i (für i=0..6),
also Signal 0 im Bit 0, Signal 1 im Bit 1 usw.

Michael schrieb:
> Beispiel:
> Signal ist zum Zeitpunkt 0 auf Low.
> Dann erfolgt steigende Flanke mit Dauer von 42 ns.
> ...

Dann sprichst du also nicht von digitalen Signalen, sondern beschäftigst 
dich mit den Analogsignalen, die deinen Takt repräsentieren. Zeig doch 
einmal die Spezifikation.
Musst du deine Eingangssignale noch mit dem Takt synchronisieren, bevor 
du sie mit dem µC einliest, damit du stabile Signalzustände erfasst?

[N. M. (mani)]

Thomas W. schrieb:
> Ein Port hat (beim RaspberryPi) acht Bit Ein/Ausgang.

Meinst du den Raspberry Pi oder den Pico um den es hier im Thread geht?

https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf
2.3.1.2. GPIO Control
S.28ff

Input registers, GPIO_IN and GPIO_HI_IN, allow the processor to sample the current state of the GPIOs
Reading GPIO_IN returns all 30 GPIO values (or 6 for GPIO_HI_IN) in a single read. Software can then mask out
individual pins it is interested in.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michael schrieb:
> Das Taktsignal wäre CL2.
Die Daten sind nicht "während cl2 = 1" gültig, sondern sie sind auf die 
fallende Flanke dieses CL2 spezifiziert. Und wenn ich die tds2 = 100ns 
mit der twcl2h = 125ns vergleiche, dann sind die Daten in den ersten 
25ns der 1-Phase des cl2 noch undefiniert. Du musst also diese 5 Bits 
parallel einlesen und dann eine Flankenerkennung auf das Bit cl2 
ausführen, damit du gültige Daten D0..3 übernimmst.

Zusätzlich musst du den cl1 auswerten, um den Anfang eines 12-Bit Wortes 
zu erkennen.

> dass das Signal mittels LCA Circuit unteranderem übertragen wurde.
Meine Worte: mit einem FPGA wärs einfach...

[Rainer W. (rawi)]

Michael schrieb:
> Eine solche Taktabfolge ist somit 42 + 125 + 42 + 125 = 334 ns.

Michael schrieb:
> 2025-07-21_11h16_48.png

Die Angaben in der Tabelle sind alles Mindestwerte/Minimalwerte und 
stellen nicht die Zeiten dar, solange in dem Design nicht alles auf 
Kante genäht ist.
Welches Timing besitzen dein Signale wirklich?
Worum geht es, wer erzeugt die Signale und um welchen Baustein geht es?

[Andreas M. (amesser)]

Wie oben schon geschrieben, der RP2040 langweilt sich bei der Aufgabe. 
Ein paar Zeilen PIO Assembler zum Samplen der Daten, per DMA ins RAM und 
von da ab ins USB.

Wenn es da ein Performanceengpass gibt, dann im USB Protokoll...

Wenn es unbedingt MicroPython sein soll, hier gibts schonmal ne 
Flankenerkennung als Beispiel:

https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_pinchange.py