Hilfe bei Controllerauswahl für Sensorabtastraten im Mhz Bereich

[Aike H. (caipirinha)]

Moin!
Vorweg bitte ich um Entschuldigung, wenn ich nicht mit Fachwissen 
gesegnet bin, ich bin kein Elektrotechniker/Informatiker.

Ich habe mir jetzt seit Wochen (gefühlt) tausende Seiten durchgelesen 
und komme einfach nicht mehr sinnvoll weiter.

Mein Problem:
Ich habe einen Sensor, der auf Durchgang gegen Ground Schaltet als 
Ausgabe.
Ich habe einen Raspberry Pi 2 B+ mit GPIO Pull-Up programmiert und er 
erfasst nicht alle Schaltvorgänge (zumindest dokumentiert er sie nicht 
wie programmiert).

Was soll gemacht werden:
Der Sensor schaltet mit bis zu 20Mhz (variabel!!) und diese 
Schaltvorgänge möchte ich dokumentieren.

Ist mein Code Murks oder brauche ich nen anderen ´Controller oder oder 
oder. Ich bin für jeden Hinweis dankbar, lese und lerne gerne dazu.

#include <stdio.h>
#include <wiringPi.h>
#include <errno.h>
#include <time.h>
#include <sys/time.h>

long long c_t() {
        struct timeval te;
        gettimeofday(&te, NULL);
        long long milliseconds = te.tv_sec*1000LL + te.tv_usec/1000;
        return milliseconds;
}

void event_detected()
{
  FILE *fp;
  clock_t t;
  t = clock();
  long long ts = c_t();
  //time_t now;
  //time(&now);
  fp = fopen("/media/usb0/daten.txt", "a");
  if (fp == NULL)
  {
    printf("Datei konnte NICHT geoffnet werden.\n");
  }
  else
  {

    fprintf(fp, "%d\n", ts);
    fputc(10, fp);
    fclose(fp);
  }

}


int main(int argc, char *argv[])
{
  wiringPiSetup();


  const int pinNumber = 27;
  pinMode(pinNumber, INPUT);
  pullUpDnControl(pinNumber, PUD_UP);
  if (wiringPiISR(pinNumber, INT_EDGE_RISING, &event_detected) < 0)
  {
    fprintf(stderr, "Unable to setup ISR: %s\n");
    return 1;
  }
  while (1) delay(1);
  return 0;
}

Ps: Das die Timestamps noch im ms sind ist klar, aber ich hab es am 
Sensor ausprobiert - manche Schaltvorgänge schreibt er gar nicht erst in 
die Datei!

Mit freundlichen Grüßen, Aike

[The D. (thedaz)]

Um 20MHz zu erfassen müsste der Pi mit 40MHz samplen. Das kannst du auf 
einem System mit Standardbetriebssystem vergessen, das würde auch ein 
aktueller PC nicht schaffen. Dafür brauchst du schon entsprechende h/w 
bzw ein real-time OS auf einem schnellen Prozessor.

[Volle (Gast)]

Alles was mit print und Files zu tun hat, dauert gefühlt eine halbe 
Ewigkeit
das kannst du für deine Anforderung  komplett vergessen.

Es gibt Controller mit Caputue Eingängen (für PWM Input)  die bei einer 
Eingangsflanke einen Zählerstand ins RAM abspeichern.
Die Zähler laufen aber selten mit mehr als 20MHz maximal.
Dann müsstest du die Zählerstände auch noch mit zB. DMA verschieben 
bevor der nächste Impuls kommt.


Würde nicht auch die Anzahl der Pulse pro ms ausreichen?
Das ginge mit einem Zählereingang

[Planlos (Gast)]

Was du dir als erstes überlegen solltest:

Die "event_detected"-ISR muss fertig durchgelaufen sein, bevor das 
nächste Ereignis am GPIO erkannt werden kann.

Du machst darin langsame Dateioperationen, die je nach USB-Stick und 
Dateisystem schon mal eine Sekunde brauchen können.

Für dein Ziel muss diese Funktion also erstmal um den Faktor 2000000 
schneller werden.
(In der ISR: Nur Ereignis+Timestamp in eine Queue schreiben, im main: 
Queue auslesen und in Datei schreiben)

Das alleine wird trotzdem nicht reichen, mehr geht, wenn du den ISR-Teil 
in den Kernel verlagerst. Aber auch dann geht's nicht schneller als die 
Hardware ist.

Für wirklich volle 20 MHz: FPGA mit viel RAM und schneller Schnittstelle 
verwenden. PCIe bietet sich an.
Bedenke: Bei vollauslastung must du 20 Mio Timestamps a 8 Byte pro 
Sekunde an die CPU schicken und auf den Datenträger wegschreiben.
Da brauchst du DMA und schnelle Platten, keinen RasPi mit USB-Stick.

[Olaf (Gast)]

> Ist mein Code Murks oder brauche ich nen anderen ´Controller oder oder
> oder. Ich bin für jeden Hinweis dankbar, lese und lerne gerne dazu.

Wie schon jemand sagte, die Umsetzung auf Standardhardware mit einem 
ueblichen Betriebsystem ist bei deinen Wunschfrequenzen mindestens sehr 
sportlich, eher unmoeglich.

Fuer deine Anwendung waere ein Red Pitaya besser geeignet. Womit ich 
nicht sagen will das du dein Problem mal eben in einer Stunde 
programmieren geloest bekommst. :)

Olaf

[Aike H. (caipirinha)]

Moin!
Vielen Dank erstmal für das schnelle Feedback.
Auf den Pi bin ich gekommen, da ich in einem Blog (den ich gerade nicht 
mehr finde) gelesen habe, das er mit 44 MHz (Unter C, alles andere war 
im kHz Bereich - Phyton/Assembler/Shell) einen einzelnen GPIO betreiben 
kann. Allerdings ging es da um Pulsweitenmodulation (und davon hatte ich 
bis vor ein paar Tagen nichts wirklich verstanden). Mein Code ist auch 
sicherlich nicht gut, nur das das Ding im Sekundenbereich schon an die 
Grenzen kommt...

Witziger Weise hämmert mir das Programm in Abständen von 100-200 ms die 
.txt voll, als ich zwischen Sensor und GPIO ein Strommessgerät gehängt 
habe, um die Ein/Ausgangsspannungen vom Sensor zu erfassen.

Da ich aber denke, ein totes Kind zu entwickeln, würde ich gerne 
Hinweise auf einen Controller und die sinnvollste Messwerterfassung zu 
bekommen - Wie ihr oben schon ausgeführt habt. Viele vielen Dank!

Capture Eingang - sendet der ein Interruptsignal direkt in den Kernel?

Red Pitaya - werd ich mir mal ganz genau Anschauen! Vielen Dank!

echtzeit-Betriebsystem.... Kernelprogramm .... Ich nehme mal nicht an, 
das ich das mit Gentoo hin bekomme? Damit kenne ich mich wenigstens 
schon ein bisschen aus.

DMA - SOWAS SUCHE ICH!!

Eine Messdatenerfassung dauert nicht länger als eine Sekunde, der 
Timestamp muss auch nicht 8 bit groß sein, es würde reichen, wenn ich 
die Zeit (oder Clock) erfasse, die zwischen den einzelnen stamps liegen. 
Bzw. wäre es eine Option nur die Zeitdifferenz zum erwarteten Timestamp 
zu schreiben. Dann könnte ich evtl mit 5 bit auskommen - aber das würde 
wahrscheinlich das Programm zu sehr aufblähen?

Die Aufgabe des Controllers ist leider sehr divergent:
In Abständen von einigen Tagen/Wochen (oder nach einem bestimmten Event) 
sollen 20-30 Messungen im MHz Bereich möglich sein. Eine Messung dauert 
nicht länger als eine Sekunde. Danach sollen die Daten in eine Datei 
geschrieben werden.

UND dann muss das Ding die Daten verschlüsselt über den Äther(Internet) 
schicken können.

UND dann >sollte< den Controller über den Äther updatefähig sein.

Oder sollte man sich von einer Platine verabschieden?

Das ganze wird ein studentisches Forschungsprojekt (Und nein, meine 
Dozenten kennen sich damit nicht wirklich aus, da es kein 
Informatik/Elektrotechnik-Projekt ist) und ich kann/darf die genaue 
Verwendung nicht benennen. Aber meine Problemlösungen werde ich 
definitiv hier zur Verfügung stellen, wenn gewünscht.

[noti (Gast)]

Neben den ganzen schon erwähnten Problemen: bei 20MHz solltest du auf 
die Beschaltung des Signals aufpassen. Ich vermute, dass der interne 
pull-up nicht reicht. Beachte die (parasitären) Kapazitäten von Kabel 
und Eingangsbeschaltung (Schutzbeschaltung, Filter...).

Ich habe keinen Raspberry Pi, ev. kann das jemand überprüfen...

[Stefan F. (Gast)]

> Ich vermute, dass der interne pull-up nicht reicht.

Ja, ganz sicher reicht der dann nicht. ich denke aber, dass solche 
trivialitäten momentan nicht wichtig sind.

Du wirst wohl ein System ebnötigen, dass DMA und Echtzeit Anwendungen 
unterstützt. Internet udn Verschlüsselung sind wiederum eine ganz andere 
Welt, wo Linux sich zuhause fühlt. Ich würde diese beiden Teile 
harwaremäßig seaprieren. Also ein schnelles echtzeitfähiges Embedded 
System und ein anderes mit Linux für die externe Kommunikation.

[Georg (Gast)]

Aike H. schrieb:
> In Abständen von einigen Tagen/Wochen (oder nach einem bestimmten Event)
> sollen 20-30 Messungen im MHz Bereich möglich sein.

Das wird wohl nur funktionieren, wenn die Daten mit entsprechender 
Hardware gesampelt und in den Speicher geschrieben werden, und erst nach 
dem Ende der Messung auf Festplatte oder sonstwohin. In deinem Programm 
jedesmal die Datei zu öffnen, den Event zu schreiben und die Datei 
wieder zu schliessen, ist nicht nur einfach zu langsam, das ist um VIELE 
Grössenordnungen zu langsam!

Die Idee nur Veränderungen und dazu einen Timestamp zu speichern, ist im 
Prinzip nicht schlecht, aber wenn die Ereignisse wirklich im Abstand von 
50 ns kommen können, dann muss das auch in dieser Zeit durchgeführt 
werden, das wird nur mit spezieller Hardware gehen. Da fragst du am 
besten die Kollegen von CERN, die bauen solche Datenerfassungssysteme.

Georg

[Aike H. (caipirinha)]

bei 20 MHz a 8bit brauche ich also 20 MByte RAM...

Ich weiß, das ist eine ziemliche Ram Verschwendung, aber was wäre wenn 
man die Adresse als Timestamp nutzt oder ist die Idee vollkommener 
Blödsinn?

Counter ist gleichzeitig der Pointer?
Der Code sähe so ähnlich aus, das man am Anfang 2 GB Speicher exklusiv 
blockt und mit Nullen vollschreibt. Kommt jetzt ein Event, schreibt er 
ein oder zwei bit in die Adresse und fängt an zu zählen. Dabei zählt er 
den Speicher hoch..... der Abstand zwischen den geschriebenen Blöcken 
ist gleichzeitig die Zeit in ns zwischen den "Peaks"?

Ich denke, das die zwei Platinenversion die richtige ist. Vorallem kann 
ich beide Komponenten seperat austauschen.
Hätte wer nen Hinweis für ein embedded System, welches die 
Datenerfassung hin bekommt oder baut man sich sowas selber aus 
Bausteinen?

[The D. (thedaz)]

Aike H. schrieb:
> bei 20 MHz a 8bit brauche ich also 20 MByte RAM...
>

Nein, hier gehts um ein digitales Signal, und um das Shannonsche 
Abtasttheorem zu befriedigen muss mit 40MHz gesamplet werden. Macht 40 
MBit/s = 5MByte/s. Also 5MB RAM und das ohne wait states.

[Jim M. (turboj)]

The D. schrieb:
> Nein, hier gehts um ein digitales Signal, und um das Shannonsche
> Abtasttheorem zu befriedigen muss mit 40MHz gesamplet werden. Macht 40
> MBit/s = 5MByte/s. Also 5MB RAM und das ohne wait states.

Ein flankengetriggerter Capture Timer würde eine variable Datenrate 
liefern,
aber wenn die Pulse weit auseinander liegen dürfen, müsste man 16 oder 
32 Bits pro Puls speichern. Auch dieser Timer müsste mit >= 40 MHz 
laufen.

Klingt alles eher nach dickem FPGA mit (onChip)Block-RAM und externem 
(DDR-)SDRAM.

[The D. (thedaz)]

Jim M. schrieb:
> The D. schrieb:
>> Nein, hier gehts um ein digitales Signal, und um das Shannonsche
>> Abtasttheorem zu befriedigen muss mit 40MHz gesamplet werden. Macht 40
>> MBit/s = 5MByte/s. Also 5MB RAM und das ohne wait states.
>
> Ein flankengetriggerter Capture Timer würde eine variable Datenrate
> liefern,
> aber wenn die Pulse weit auseinander liegen dürfen, müsste man 16 oder
> 32 Bits pro Puls speichern. Auch dieser Timer müsste mit >= 40 MHz
> laufen.
>
> Klingt alles eher nach dickem FPGA mit (onChip)Block-RAM und externem
> (DDR-)SDRAM.

Das kriegt ein ARM gut hin und kann die Daten auch per DMA über USB 
streamen, wenn man ihn nicht mit einem dicken Betriebssystem ausbremst.

[Peter D. (peda)]

Aike H. schrieb:
> Ich habe einen Sensor, der auf Durchgang gegen Ground Schaltet als
> Ausgabe.

Dann brauchst Du schonmal einen recht niederohmigen Pullup, der in 
<12,5ns wieder auf high Pegel zieht, damit von den 20MHz noch was übrig 
bleibt.

Aike H. schrieb:
> ich kann/darf die genaue
> Verwendung nicht benennen.

Ja so ist das mit der Geheimniskrämerei.
Wenn Du mehr über das Signal verraten würdest und was Dich daran 
überhaupt interessiert, wäre die Sache vielleicht popeleinfach.

Ich kenne das auch zur Genüge. Das ist immer ne schwere Geburt, dem 
Kunden aus dem Kreuz zu leiern, was er eigentlich genau will. Zu Anfang 
hat man immer den Eindruck, er will mindestens Weltraumtechnik und hat 
mehrere Milliönchen € im Etat.

[W.A. (Gast)]

Aike H. schrieb:
> Der Sensor schaltet mit bis zu 20Mhz (variabel!!) und diese
> Schaltvorgänge möchte ich dokumentieren.

Und du bist sicher, das ein Rechner, der wahrscheinlich nichtmal unter 
einem Echtzeitbetriebssystem läuft, die richtige Wahl dafür ist. Auch 
als Informatiker wird dir vielleicht in einem Praktikum mal soetwas wie 
ein Logikanalysator über den Weg gelaufen sein. Falls ein paar Stunden 
Aufzeichnungsdauer bei 24MHz ausreichend sind, gibt es da praktischen 
Teile mit einem CY7C68013A bei Ebay&Co, die dir die Daten über USB 
direkt auf einem PC abliefern.