D-FlipFlop

Tag zusammen,

ich habe eine beinah peinliche Frage...wie realisiert man ein D-FlipFlop in einer Programmiersprache?
Bei jeder positiven Taktflanke (0-->1) wird ja der Wert am Dateneingang auf den Ausgang gegeben. Soweit sogut, klingt ja nicht weiter schwer. In meinem Code (C++) sieht das ganze dann so aus:
Die betreffende Stelle in der main-Funktion sieht dann so aus:
Nicht verwirren lassen, es ist beabsichtigt dass Signal1 den Clock abtastet. Die Übergabe-Reihenfolge bzw. die logische Beschaltung des FF stimmt so. Der Clock in der main-Funktion ist am Dateneingang des FF angeschlossen.
Das sollte doch richtig sein oder? Wird nämlich in der FF-Funktion keine steigende Flanke detektiert wird Q einfach durchgereicht, und zwar unverändert.
Der Clock ist bedeutend langsamer bzw. niederfrequenter als die Daten, aber die Funktionsweise (bei steigender Flanke die Daten durchzuschleusen) sollte doch die selbe sein. Trotzdem erhalte ich ein sehr sehr unterschiedliches Ergebnis, wenn ich das Problem zB in Simulink realisiere und mit einem Scope die Signale betrachte...wieso?

Sieht für mich ganz gut aus. Warum testest Du aber 2x auf L und 1x auf H? Und bleibt Q1 zwischen 2 Aufrufen gleich? Sonst würde das FF beim nächsten Aufruf ein falsches Ergebnis liefern.

Btw.: Wäre es nicht besser, eine FF-Klasse zu machen und den Zustand im Objekt selbst zu speichern?

Weil Signal1 niederfrequenter ist als der Clock. Um zuverlässig eine steigende Flanke zu detektieren muss ich genau dieses Bitmuster erkennen. Beispiel:
Signal1 = ...000111001110011100...
Clock = ...010101010101...
Und da Signal1 der Clock für das FlipFlop ist, und Clock die eigentlichen Daten...dacht ich das wär ne gute Idee. Das mit der Klasse klingt gut, ist aber vorerst zuviel Aufwand. Ich bin noch im Versuchstadium...

UnimatrixZero schrieb:

Und bleibt Q1 zwischen 2 Aufrufen gleich?

Zum Vergrößern anklicken....

Ja, es bleibt gleich. Der Wert von Q wird ja nur durchgereicht, in dem Fall dass keine steigende Flanke detektiert wird. Ich habe das bereits verifiziert.

Das Fehlerbild das ich erhalte sieht aus wie eine Phasenverschiebung. Mit anderen Worten: Das was ich eigentlich zum Zeitpunkt t1 am Ausgang des FF erhalten sollte, kommt in meinem Programm erst zum Zeitpunkt t2...Der gesamte Versatz beträgt etwa 2 Grad (Phase).
Hat jemand ne Idee woher das kommt? Ich steh total auf dem Schlauch. Meine Funktion für das FF ist doch nun wirklich nix besonderes.

Willst Du Schalterprellen kompensieren??

dante99 schrieb:

Willst Du Schalterprellen kompensieren??

Zum Vergrößern anklicken....

Nein. Das hat mit Entprellen nichts zu tun. Die FlipFlops dienen als Sample&Hold-Glied, mehr nicht.

wenn die flipflops nur als sample and hold glied dienen, benutz doch einfach ne variable ^^. Wenn sie aber doch zum schalter entprellen gedacht sind, tuts auch ne zeitschleife die, die 1 oder 0 was auch immer nach einer bestimmten zeit (in der zeit in der der schalter keineswegs mehr prellt (z.b. 1sek)) definiert...

edit: habe gesehn das du ein flanken gesteuertes flipflop brauchst/willst, naja genau die flanke wirst du mit variablen warscheinlich nicht treffen, aber ich denke du kannst auf die paar 1000mircosek verzichten... natürlich brauchst du noch die ein oder andre if anweisung, naja wenn dus wie oben beschrieben nicht hinbekommst, denk ich ist das eine gute alternative (wenn auch langsamer)...

cc_ip schrieb:

wenn die flipflops nur als sample and hold glied dienen, benutz doch einfach ne variable ^^.

Zum Vergrößern anklicken....

Negativ. Das FF dient zwar als Sample-and-Hold, aber die Flanke muss trotzdem zuverlässig detektiert werden können, denn von der ist der Ausgang Q abhängig. Mit einer einzigen Variable ist das in dieser Anwendung nicht möglich.

edit: habe gesehn das du ein flanken gesteuertes flipflop brauchst/willst, naja genau die flanke wirst du mit variablen warscheinlich nicht treffen, aber ich denke du kannst auf die paar 1000mircosek verzichten... natürlich brauchst du noch die ein oder andre if anweisung, naja wenn dus wie oben beschrieben nicht hinbekommst, denk ich ist das eine gute alternative (wenn auch langsamer)...

Zum Vergrößern anklicken....

Das hab ich nicht ganz verstanden. Das Eingangssignal ist ja quasi eine Variable, bestehend aus drei Elementen. Diese Elemente sind schon Fehlerbehaftet genug, als dass ich dann noch auf zusätzliche Mikrosekunden verzichten kann.

Anyways...Das Problem hat sich bereits vor einigen tagen aufgelöst. Das FF funktioniert einwandfrei, der Fehler lag in einem Korrekturfaktor für den Clock-Eingang, den ich falsch berücksichtigt habe.