ich möchte ein PWM-Signal (28.57Hz, 2.857% Tastgrad) ausgeben, sobald ein Sensor eingeschaltet wird (siehe Abbildung). Bisher habe ich mit Arduino und Tiva C LaunchPad experimentiert. Dass Problem ist, dass die Δt Zeitspanne nicht konstant ist, bei den beiden Mikrocontrollern variieren die Δt-Werte innerhalb eines Taktzyklus, 62,5ns und 12,5ns (etwa wie oben dargestellt).
Gibt es eine Möglichkeit, Δt konstant zu halten? Gibt es eine effektivere Lösung für dieses Problem (vielleicht mit analogen ICs)?
Was für ein Arduino soll das sein? Bei den üblichen 16MHz sind die 62,5 ns gerade mal ein CPU Takt. Ein geringerer Jitter geht schon aufgrund der Zeitquantisierung gar nicht. Das Lauchpad hat ne ARM CPU, da gibts noch viel mehr Faktoren die das Zeitverhalten beeinflussen.
Was für ein Arduino soll das sein? Bei den üblichen 16MHz sind die 62,5
ns gerade mal ein CPU Takt. Ein geringerer Jitter geht schon aufgrund
der Zeitquantisierung gar nicht.
Ganz genau.
Falls du es nicht bemerkt hast: das in ein klassischer Traffic-Troll-Thread. Und Leute wie du sorgen dafür, dass er sich wirklich zu eine Thread entwickelt...
Das Diagramm ist arg irreführend: es suggeriert eine PWM-Frequenz von 11.6 MHz.
Bei genauerer Betrachtung (und als Physik-Laie) wüsste man gerne den Grund, warum die 62.5 ns bei 28.57 Hz (entspricht 1.8 ppm) stören.
Gibt es eine Möglichkeit, Δt konstant zu halten? Gibt es eine
effektivere Lösung für dieses Problem (vielleicht mit analogen ICs)?
Ja sicher. Man muss den Timer passend laden und dann den Timer mit der PWM starten. Analog muss man da gar nichts fummeln. Allerdings kann es auch da Jitter geben, denn der Intzerrupt zum Erkennen der Sensorflanke ist im Normalfall nicht ganz jitterfrei, eben weil das normale Programm ja läuft und unterschiedlich lange BEfehle bearbeitet. GGf. besitz dein Controller ein Eventsysten, wo das alles IN hardware erledigt werden kann, dann wird es besser. Aber selbst mit Jitter könne es ausreichend gut sein, denn die CPU mit sehr hohem Takt läuft.
Dein Oszilloskopbild ist reichlich sinnlos, wenn man keine Zeiteinheit sieht. Als Physiker, so du denn wirklich einer bist, ein neudeutsches "FAIL".
Nimm einen schnellen µC (Tennsy 4.0 oder 4.1 müsste IMHO gehen) und programmiere ein Hardware Feedback zwischen dem steuernden GPIO und der PWM Ausgabe.
Bessere moderne µC als AVR können das inzwischen - grade weil Interrupts eine variable Latenz haben.
Man müsste wenigstens den Prozessortakt synchron halten mit dem möglichen Sensoreinschaltzeitpunkt, per PLL oder so, also als externen Takt einspeisen was auf einem Arduino nicht vorgesehen ist, und selbst dann stört das laufende Programm mit Befehlen die mehr als 1 Takt benötigen und nicht unterbrochen werden können
Gibt es eine
effektivere Lösung für dieses Problem
Um etwas xx ns nach Start eines Signals beginnen zu lassen, muss man erst mal dieses Signal auf ns genau erfassen. Was ist der Zeitpunkt, da wo die Signalspannung 10, 50 oder 90% des Nennwertes hat ? Wie schnell steigt die Signalflanke von 10 auf 90%, in 1us oder 1ns ?
Wenn man eine analoge PWM Erzeugung mit Beginn der Signalflanke startet, hat man zwar nicht das Problem, dass diese nicht taktsynchron erfolgt, weil es keinen Takt gibt, aber man hat das Problem, dass die analoge Startphase der PWM eventuell nicht nanosekundengenau nach dem Signal beginnt, sei es dass die Versorgungsspannungsabhängig ist, temperaturabhängig oder davon wie lange zuvor Ruhe war.
Du müsstest also schon sagen, WIE genau der PWM Startpunkt vom Signal abhängen muss, und wenn das 10ns ist, dann könnte man das mit Digitaltechnik, z.B. einem FPGA mit 200MHz Takt hinbekommen.
Ich denke allerdings, 28.5Hz und Nanosekunden passen nicht zusammen, du hast dich um Grössenordnungen vertan.
Ihr denkt mal wieder viel zu kompliziert. Kennt denn keiner mehr das Ei des Columbus?
Einfach das PWM-Signal durchlaufen lassen und das Sensor-Signal damit synchronisieren.
Mit ein paar Logik-ICs das PWM-Signal dann nach aussen freigeben. Der Jitter zwischen sync. Sensor und PWM sollte je nach verwendeter Logik < 1 ns betragen.
Kannst Du mal erzählen, welches Problem Du eigentlich lösen möchtest?
Falls die PWM tatsächlich bei 28.57 Hz läuft brauchst Du Dir über Nanosekunden wirklich keine Gedanken machen. Selbst falls Du kHz gemeint haben solltest, kann das eigentlich kein Problem sein. Wenn das wirklich eine PWM ist, dann hängt dahinter ein Tiefpass um einen DC Pegel zu erzeugen und der ist um Größenordnungen langsamer.
Oder benutzt Du die PWM-HW, um spezielle Pulsfolgen zu erzeugen?
wenn es nur auf den zeitlichen Abstand zwischen Sensorsignal und PWM Flanke ankommt, dann geht das theoretisch ganz einfach. Praktisch sehe ich erstmal kein Problem. Sensorsignal wird per Interrupt erkannt und in diesen Interrupt wird der Timer gestartet. Weil im Interrupt nichts dazwischen funkt bleibt der zeitliche Abstand immer konstant. Der Timer wird vorher passend konfiguriert mit Hardwareausgang zum "OCRn"/"WO" Pin. Dann kann er unbekümmert und unbeeinflusst vor sich hintakten.
Aber ich befürchte c-hater könnte recht haben. Ist bestimmt ein Fake Account, denn einen User "Andrew P". o.ä. gibt es schon und nicht erst sein 15.05.2023. Um das zu entkräften müßte der TO in seinem Thread aktiv mitmachen.
Sensorsignal wird per Interrupt erkannt und in diesen Interrupt wird der
Timer gestartet. Weil im Interrupt nichts dazwischen funkt bleibt der
zeitliche Abstand immer konstant.
Die Anzahl der CPU-Takte zwischen Interrupt und Ausführung der Interruptroutine kann je nach unterbrochenem Befehl schwanken. Außerdem möchte der TO ja sogar genauer als ein CPU-Takt sein.
Das Problem ist: das Sensorsignal trifft irgendwo innerhalb eines uC-Taktes ein, und die Reaktion (in Gestalt des PWM-Beginns) kann frühestens mit dem nächsten Takt erfolgen. Folglich haben wir prinzipiell eine Unbestimmtheit von der Dauer eines uC-Taktes.
Und wie, umgekehrt, der Sensor auf den uC synchronisiert werden soll, muss uns Mi N. erstmal erklären, ohne ihn zu kennen. Es könnte sich ja auch z.B. um einen analogen Sensor handeln.
Das Diagramm ist arg irreführend: es suggeriert eine PWM-Frequenz von
11.6 MHz.
Ja, ich weiß. Ist nur eine grobe Darstellung, damit man vom Problem irgendeine Ahnung hat.
Bei genauerer Betrachtung (und als Physik-Laie) wüsste man gerne den
Grund, warum die 62.5 ns bei 28.57 Hz (entspricht 1.8 ppm) stören.
Das Signal ist Triggersignal für einen Radar. Die Interrupt-Latenz muss immer gleich groß sein (egal ob ns oder μs), damit sie die Messergebnisse nicht verfälscht.
Dein Oszilloskopbild ist reichlich sinnlos, wenn man keine Zeiteinheit
sieht. Als Physiker, so du denn wirklich einer bist, ein neudeutsches
"FAIL".
Ist nicht mal mein Oszibild, habe es irgendwo im Internet gefunden. Ist nur eine Darstellung über den Jitter. Aber hast völlig Recht, es ist echt irreführend. Sorry.
Das Signal ist Triggersignal für einen Radar. Die Interrupt-Latenz muss
immer gleich groß sein (egal ob ns oder μs), damit sie die
Messergebnisse nicht verfälscht.
Mensch Meier, lies mal was über Netiquette!!
Und fasse dein Ziel man in Zahlen!
Kleiner Tipp. 0ps Jitter sind nicht möglich! Wenn man alle Register der Digitaltechnik zieht, kommt man vielleicht auf +0/-1 Takt. Und wenn der hoch genug ist (100MHz++), reicht es dann vermutlich auch praktisch aus.
Die Interrupt-Latenz muss immer gleich groß sein (egal ob ns oder μs)
Reicht dann nicht ein Jitter von, sagen wir, 2 ns (es wurde ein "Teensy 4 mit 600 MHz" vorgeschlagen)? Ich meine, die anschließende PWM-Impulsfolge auf 2e-9 genau zu halten, stelle ich mir auch etwas aufwändig vor.
Das Signal ist Triggersignal für einen Radar. Die Interrupt-Latenz muss
immer gleich groß sein (egal ob ns oder μs), damit sie die
Messergebnisse nicht verfälscht.
Dann nimm einen Draht und keine getaktete Logik.
Kommt dein Sensorsignal überhaupt synchronisiert zum CPU-Takt ?
Die Anzahl der CPU-Takte zwischen Interrupt und Ausführung der
Interruptroutine kann je nach unterbrochenem Befehl schwanken. Außerdem
möchte der TO ja sogar genauer als ein CPU-Takt sein.
Das Problem ist: das Sensorsignal trifft irgendwo innerhalb eines
uC-Taktes ein, und die Reaktion (in Gestalt des PWM-Beginns) kann
frühestens mit dem nächsten Takt erfolgen. Folglich haben wir
prinzipiell eine Unbestimmtheit von der Dauer eines uC-Taktes.
Und wie, umgekehrt, der Sensor auf den uC synchronisiert werden soll,
muss uns Mi N. erstmal erklären, ohne ihn zu kennen. Es könnte sich ja
auch z.B. um einen analogen Sensor handeln.
Hallo,
ja stimmt, ihr habt wie immer recht. Ich hatte völlig außer acht gelassen das die Takte unbestimmt sind wann die zugehörige ISR überhaupt aufgerufen wird. Das ist die Unbekannte in der Betrachtung. Aber da das vom TO nur theoretische Betrachtung ist und alle Bilder von ihm aus dem Internet sind, seine Hardware nicht bekannt ist, ist das für mich uninteressant geworden.
Bisher habe ich mit
Arduino und Tiva C LaunchPad experimentiert. Dass Problem ist, dass die
Δt Zeitspanne nicht konstant ist, bei den beiden Mikrocontrollern
variieren die Δt-Werte innerhalb eines Taktzyklus, 62,5ns und 12,5ns
Wie hast du eigentlich den Δt-Jitter auf einem Atmega328P auf nur einen Taktzyklus beschränkt? Der Atmega328P hat doch gar keinen Eingang der einen Timer zurücksetzt. Was übersehe ich?
Falls du es nicht bemerkt hast: das in ein klassischer
Traffic-Troll-Thread. Und Leute wie du sorgen dafür, dass er sich
wirklich zu eine Thread entwickelt...
signal.PNG
(4,4 KB)
HEKJs.png
(41 KB)
