Kurze Impulse messen (Auflösung 10ns)

[Ceos]

Beim Prozessor würde ich aber nochmal genau nachprüfen ob der für deine Zwecke ausreicht.
Du hast geschrieben du möchtest Pulspakete messen, das impliziert für mich mehrere Pulszeiten hintereinander. Von welchen Pausenzeiten zwischen den Pulsen reden wir hier?
Meine Erfahrung hat gezeigt, dass DMAs je nach spezieller Ausprägung bei Cortex basierten Prozessoren richtig langsam sein können, je nachdem wie die Busmatrix aufgebaut ist und der DMA seine sog. Transferdeskriptoren speichert.
Ich persönlich würde nach eminer Erfahrung einen XMega wählen(2 Timer arbeiten mit bis zu 96MHz), da ist der Transfer von 16Bit z.B. innerhalb weniger Takte(32MHz) erledigt. Bei einem ATSAM von Atmel waren das schon fast 2 duzend Takte(bis zu 120MHz ... glaub ich) die er brauchte um den nächsten Transfer durchzuführen und wenn der Bus gerade der Meinung war ein Busy Flag hoch zu halten dehnte sich die Verzögerung auch noch undefiniert stark aus.
Bei STM32 gibt es Erfahrungsgemäß dieses Problem nicht, die arbeiten ähnlich schnell wie die XMegas.

tl;dr;
Mach zur Sicherheit einen Test, starte einen Timer mit max. Clock und einne 2ten Timer mit langsamerer Clock. Im ersten Timer stellst du die Periode auf 255 und benutzt den Overflow als Trigger für den DMA, der dir einfach fortlaufend die Timerwerte des 2ten Timer ind en speicher schreibt. Wenn der DMA mal einen Takt verpassst siehst du das sofort in deinen Timestamps!
Jetzt reduzierst du einfach die Periodendauer des ersten Timer so lang bis du Sprünge bekommst. Dann weist du wie schnell dein DMA ticken kann.

Ich habe mir das Manual zum LPC angesehen und dort ist von Speicher(RAM)-Deskriptoren zu lesen und die sind Erfahrungsgemäß sehr langsam! Ich rate dringend zum Test um spätere Überraschungen zu vermeiden

[Siro]

@Peter:
Das erste Dankeschön geht an Peter:

Auswahl der Diode:
Ich habe einfach nach einer Diode mit einer möglichst kurzen "reverse recovery time" gesucht
und bin auf die 1N60P gestoßen. Die Angabe von 1ns erschien mir sehr geeignet, zudem ist sie bei Segor in Berlin erhältlich.

Du hast völlig recht, der Level Output Current interessiert ja garnicht. (schäm) totaler Blödsinn.
Der Pullup muss dann nur die Eingangskapazität/Diodenkapazität auf/umladen und das sollte möglichst schnell erfolgen,
wobei ich hier natürlich mein Meßobjekt entsprechend belaste.

Intern hat die CPU ja Schutzdioden, theoretisch kann ich sogar beide weglassen.
Höhere Spannungnen werden ja eigentlich schon D1 gesperrt, damit kann D2 tatsächlich entfallen.



@Ceos:
auch hier ein Dankeschön für deine Erfahrungen und berechtigte Zweifel.

Wenn ich das richtig erforscht habe im Datenblatt, kann der LPC1768 NICHT im DMA Modus Capturen,
somit ist der Prozessor für das Vorgehen bei schnellen Pulsfolgen ungeeigent.
Einzelne Impulse kann ich jedoch auch im Interrupt auswerten, da ja die beiden Timerwerte in den Registern gespeichert werden.

Intern hat der Prozessor auch Schreibpuffer, teils mit ungeahnten Auswirkunken.
So darf ich zum Beispiel ein Interrutpflag niemals in der letzten Programmzeile der ISR löschen,
hier habe ich schon meine "negativen" Erfahrungen gemacht. Da gibt es danmn DSB (data synchronisation barrier)
und DSM (data synchronisation memory)

Die Idee mit dem zweiten Timer und den DMA Test ist eine gute Idee.


Insgesamt sind hier entscheidende Informationen gekommen. Das ist doch schwieriger als man zunöchst denkt,
und 100Mhz ist ja heutzutage nicht die Welt....


Hintergrund:
Der Grund warum ich mich überhaupt mit diesem Thema beschäftige ist folgender:
Ich habe mir ein RIGOL MSO1104Z-S Oszilloskop gekauft
Dann führte ich Messungen an einem PWM Signal durch und hatte sichtbar irgendwelche "Ausreißer"
Der Ossi bietet die Möglichkeit einer Statistik und die kann Min und Maxwerte darstellen.
Dann sah ich mir die Werte an und musste feststellen, daß die Statistik NICHT stimmt.
Nach Prüfungen mit einem Ossis eines anderen Herstellers konnte dies eindeutig bestätigt werden.
Ich hab es dann geschafft, die Pulsfolge sowie den Scrennschoot mit den Werten im Display festzuhalten
und dieses Problem dem Lieferanten mitgeteilt.
Dieser muste mir "leider" bestätigen, dass dieses Gerät es wirklich nicht besser kann, es werden "nicht alle Signale" erfasst...

Da ich aber die Min und Maxwerte "aller" Pulse erfassen wollte, kam nun die Idee: Selbst ist der Mann,
da ich schon viel mit der LPC-Serie programmiert habe, war das auch mein bevorzugter Prozessor.

Siro

[Ceos]

DSB (data synchronisation barrier)
und DSM (data synchronisation memory)

Der Übeltäter hier ist der AHB Bus! Teuflich kann ich dir sagen, daher muste ich bei uns auf die Pläne einen ATSAML21 zu verwenden nach 2 Wochen investierter Arbeit abbrechen.
Deine Auflösung macht schon fast einen Cortex notwendig, aber die DMAs bei Cortex Kernen sind leider fast alle sog. eDMA welche das Transferdeskriptor-Modell verwenden. Liegen die Deskriptoren im RAM muss für jede Aktion erst der aktuelle Deskriptor von den Registern in den RAM geschrieben werden (Writeback) dann der getriggerte Deskriptor aus dem RAM geladen werden und dann erst kann die Transaktion starten. Tritt dann noch ein Busy-Flag wegen AHB Sync auf ist dier Performance richtig im Teich.

Es gibt einige wenige Prozessoren (STM32 als mir bekanntes Beispiel), welche die Deskriptoren in eigenen Registern vorhalten (damit auch Funktionsmäßig limitiert sind auf Inkrement und Dekrement aber keine Addresssprünge ... fuck schreibt mand as wirklich so???) und deswege halbwegs agil reagieren. Aber der STM leidet darunter dass er nur fest verdrahtete Events zu DMA Channel Verbindungen hat und somit ziemlich unflexibel in der Perepherie zu benutzen ist. Man kann ja z.B. nichtmal 2 DMAs verkettet laufen lassen um z.B. immer einen ADC Wert und sofort passend dazu einen Timestamp auf einem 2ten Channel zu kopieren.

Ich rate daher bei Zeitkritischen Basteleien immer eine Voruntersuchung der Hardware vorzunehmen, das Datenblatt verschweigt oft vieles, weil der Schreiber die generelle Funktion im Sinne hatte aber der praktische Anwender in der Regel extreme Ideen