Hallo, wie kann man per Software einen Pin so abfragen das dazu immer die gleiche Zeit dazu benötigt wird. sync: sbic PinB,1 rjmp sync das macht ja das was es soll aber wie kriege ich das mit nop so hin das für den Vorgang immer eine konstante Zeit benötigt wird. Maximal habe ich ca. 20 Zyklen Zeit wenn es weniger sind dann ist das auch gut.
Den Prozessor schlafen legen und mit Interrupt des Eingangspins das Programm fortsetzen.
Da kann ein Programm nichts machen, die SW hat doch gar keinen Einfluss auf den PinB1. Wie sollte das dann immer gleich lang dauern? sync: sbic PinB,1 ; 1 Durchlauf oder 10 Durchläufe rjmp sync ; sollen gleich lang dauern? Offenbar hast du nicht den Kern des Problems beschrieben, sondern nur ein Symptom. Sag doch wo das eigentliche Problem liegt.
Der Kern des Problems ist. das nach immer der gleichen Zeit nachdem an PinB,1 ein High anliegt eine Aktion folgen soll. Mit einem Interrupt gibt es das Problem das der Controller erst seinen Befehl fertig macht und dann den Interrupt auslöst was zu Schwankungen führt die man nicht so einfach ausgleichen kann. sync: sbic PinB,1 rjmp pc+x sbic PinB,1 rjmp pc+x sbic PinB,1 rjmp pc+x sbic PinB,1 rjmp pc+x sbic PinB,1 rjmp pc+x rjmp sync nop nop nop nop nop nop konnte das vielleicht (fast) Funktionieren?
> Mit einem Interrupt gibt es das Problem das der Controller erst seinen > Befehl fertig macht und dann den Interrupt auslöst was zu Schwankungen > führt die man nicht so einfach ausgleichen kann. Deshalb schickt man ja den Controller in den Sleep (Mode Idle), dann ist die Interrupt-Responsetime immer gleich, denn da muss kein angefangener Befehl fertig gemacht werden, sondern nur der CPU-Takt eingeschaltet werden. Und das dauert immer gleich lange. KH
>das nach immer der gleichen Zeit nachdem an PinB,1 ein High anliegt eine >Aktion folgen soll. Also so: - High an PB1 erkannt, - kurz warten, - irgendwas machen?. So? Wielange ist "kurz" ?
Kurz ist max. 20 Zyklen sync: sbic PinB,1 rjmp sync das Problem ist das der High pegel nicht sofort erkannt wird wenn das Programm bei rjmp sync ist zurückspringt und den High pegel dann erst erkennt. Wenn der High pegel zufälligerweise sofort bei sbic PinB,1 kommt dann habe ich z.b. 2 Zyklen Abarbeitungszeit abdersrum 3 oder 4 Zyklen. und das ist mein Problem. wenn das ganze nach ausgleich dann immer als Beispiel 10 Zykelen hat egal wenn der High Pegel eingetreten ist dann ist das optimal.
>>sync: sbic PinB,1 >> rjmp sync Du hast hier immer eine Auswertezeit von durchschnittlich (t_abfrage + t_jump)/2 und zudem einen genauso großen Jitter. D.h. niemand kann dir garantieren, dass du nicht zufällig die zwei Befehle "unnötig" abarbeitest, weil das Signal auch nur 1 fs zu spät angekommen ist. Entweder machst du hier etwas unnötig umständlich, oder der Controller ist zu langsam ;-) > wenn das ganze nach ausgleich dann immer als Beispiel 10 Zykelen > hat egal wenn der High Pegel eingetreten ist dann ist das optimal. Deine Rahmenbedingung ist also: die Routine muß_konstant 10 (oder 20) Zyklen dauern. Dabei sollte zum Schluss herauskommen, ob ein Pin gesetzt wurde oder nicht? Wieso wartest du dann nicht 10 Zyklen und fragst den Pin hinterher ab? Was soll denn im einen (Pin=0) oder anderen (Pin=1) Fall passieren? Um mich mal selber zu zitieren: > Sag doch wo das eigentliche Problem liegt.
>das Problem ist das der High pegel nicht sofort erkannt wird wenn das >Programm bei rjmp sync ist zurückspringt und den High pegel dann erst >erkennt. Wenn der High pegel zufälligerweise sofort bei sbic PinB,1 >kommt dann habe ich z.b. 2 Zyklen Abarbeitungszeit abdersrum 3 oder 4 >Zyklen. >und das ist mein Problem. Aber dir ist schon klar, das hier ein "Zyklus" kleiner als 100ns (in Worten: eine Zehn-Millionstel Sekunde) ist. Wenn du es genauer brauchst, was ich bezweifle, dann msst du das in Hardware aufbauen (FPGA, GAL, ASIC, ..))
Ich brauchs schon so genau das es um die Auswertung von VGA Signalen geht. Momentan benutzte ich einen Mega 16 mit 16Mhz Taktfrequenz. ein Zyklus dauert 0,065 uS. Ich muß nach dem Zeilesignal eine konstakte Zeit warten und immer im fast Selben (optimal im selben) Pixel einrasten und dann eine Aktion ausfüren. 10 Zeilen Pause und die Aktion beginnt von vorn. Durch diese hin und herflattern bekomme ich trotz Mittelwerbildung "ungenaue" Ergebnisse.
>ein Zyklus dauert 0,065 uS.
Wenn, du schriebst, ein Zyklus 0,065µs = 65NANOsekunden dauert, brauchst
du mit einem µC nicht anfangen.
Wenn ein Zyklus aber 0,065ms = 65Mikrosekunden (ergibt ~15384Hz) dauert,
und durch obiges Beispiel ein Jitter von ca 100ns entsteht, hast du eine
Toleranz von 0,1%
Falsch ich meine den Prozessortakt mit 0,065 uS Die zeilenfrequenz befrägt je nach signal ca. 48 kHz da dürfte doch ein ATmega ausreichend sein.
>Die zeilenfrequenz befrägt je nach signal ca. 48 kHz da dürfte doch ein >ATmega ausreichend sein. Ja, mit dem besagten Jitter von einem Zyklus. Den hast du immer! Bei jedem sequentiell arbeitenden Beiteil. Und wo ist jetzt das Problem? 48kHz => 20µs, davon 65ns ergeben 0,3%
Bei 16MHz dauert ein Taktzyklus exakt 62ns und nicht 65ns. Gruß
>Bei 16MHz dauert ein Taktzyklus exakt 62ns
Es sind exakt weder 62 ns noch 65 ns sondern 62.5 ns. Aber Du warst
näher dran ;-)
1/16 = 0.0625.
Benutz doch den ICP Interupt dan weißt du genau wann das Signal kam (auf einen Takt genau...)
Du kannst sooft fragen wie Du willst, es gibt keine andere Möglichkeit als ICP oder Idle: Beitrag "Interrupt Sprungzeit" Peter
SHARP EL-531LH 0,000000062 TI-36X II 0,000000063 Windows Rechner 0,0000000625
Es muß ja nicht aufs 1000senstel sein. Momentan wandert der Punkt ca. 1-5 mm bei einer 1028x1024 auflösung bei 60Hz hin und her.
Jo, habe das jetzt auch festgestellt. Und nun geht das Problem los welcher. Naja, ist ja bald Nikolausi und Weihnachten.
Wer auf einem 8- oder 10-stelligen Taschenrechner 1/16000000 statt nur 1/16 rechnet, ist es aber auch selbst Schuld.
> im Selben (optimal im selben) Pixel einrasten ... Du sagst es selber: bau dir doch eine PLL, die auf das VGA-Signal einrastet , dann multipliziere die Frequenz mit 'x' und takte damit deinen uC. Auf diese Art hast du immer den selben Phasenbezug und jitterst nicht so um den Sync herum. Matthias Lipinsky wrote: > Casio FX 991: > 16M => 1/x => 62.5n HP28C/S und HP48 auch 0.0000000625 bzw. 6,25e-8
>62,5n und >6,25e-8 ist nicht dasselbe ;-) Besser als >6,25e-8 wäre scchonmal 62,5e-9 ! Einige TR haben eine wissenschaftliche Funktion. Dadurch werden solche Zahlen nur mit Zehnerpotenzen, die Vielfache von Drei sind, dargestellt. Noch bessere Taschenrechner ersetzen diese Dreier-Zehnerpotenz dann durch den wissenschaftlichen Vorsatz, zB m für Milli, oder G für Giga. (Das nennt sich ENG - engineering mode) Will ich nicht mehr missen....
Passt alles noch sehr gut zum Thema Macht doch eine Taschrecher Brett auf.
Je genauer der TR desto weniger zappelt das Pixel auf dem Bildschirm.
>Passt alles noch sehr gut zum Thema
Du siehst, hier bist Du in besten Händen.
Aber irgendwie willst Du nicht mit sleep bzw. idle arbeiten?
Nee sleep legt doch alles lam, was mach ich dann mit den anderen sachen die dann noch nebenbei laufen. Wie meinst Du das denn mit dem Sleep?
>...die dann noch nebenbei laufen.
Wenn Du auf den Impuls wartest, wirst Du nichts nebenbei machen können.
Oder hast Du währendessen Interrupts aktiv?
Der Prozessor soll nicht den ganzen Tag schlafen, sondern nur an dieser
Stelle "synchron warten", bis der Impuls gekommen ist.
>Der Prozessor soll nicht den ganzen Tag schlafen, sondern nur an dieser >Stelle "synchron warten", bis der Impuls gekommen ist. Das ist praktisch gesehen dasselbe!
Das läuft so das ich die Zeilen vom VGA Signal mit Timer 1 Compare MatchB auswerte und alle 20 Zeilen eien Interrupt habe. Pin B1 ist Eingang und mit Hsync verbunden der timer steht auf externen Takt steigende oder fallende Flanke. Der Interrupt löst dann den AD-Wandler aus. Die Frage ist doch jetzet wann schicke ich den Controller Schlafen?
>Das ist praktisch gesehen dasselbe!
Da stimme ich Dir mal einfach nicht zu.
>>Das ist praktisch gesehen dasselbe! >Da stimme ich Dir mal einfach nicht zu. Musst du auch nicht, aber zwischen
1 | sync: sbic PinB,1 |
2 | rjmp sync |
und dem:
>mit dem Sleep?
besteht bei Betrachtung der sonstigen Aufgaben kein Unterschied!
Ich hab mal versucht den Controller am Ende eines Interrupts schlafen zu schicken geht auch nur kommt man dann nicht mehr aus dem IR raus. Habe dann nochmal mit Timer1 experimentiert: so Initalisiert: ldi templ ,(1<<COM1A1) | (1<<COM1A0) out TCCR1A,templ ldi templ, (1<<TICIE1) out TIMSK, Templ ldi tempL, (0<<CS12)|(0<<CS11)|(1<<CS10)|(0<<WGM12) ; out TCCR1B, tempL sei und das sind es dann immer laut Simulator beim betätigen von PinD6 genau 8 Zyklen bis zum Interrupt.
René Schink wrote: > Ich hab mal versucht den Controller am Ende eines Interrupts schlafen zu > schicken geht auch nur kommt man dann nicht mehr aus dem IR raus. Klar, man schickt den ja auch in der Hauptschleife schlafen und nicht in der ISR.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.