www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zyklengenaues abfragen von Pin B1


Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Prozessor schlafen legen und mit Interrupt des Eingangspins das 
Programm fortsetzen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kachel - Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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" ?

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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, ..))

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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%

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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%

Autor: Das delay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 16MHz dauert ein Taktzyklus exakt 62ns und nicht 65ns.

Gruß

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutz doch den ICP Interupt dan weißt du genau wann das Signal kam (auf 
einen Takt genau...)

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>und nicht 65ns.

Ich habe überboten. Ich bin somit raus ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst sooft fragen wie Du willst, es gibt keine andere Möglichkeit 
als ICP oder Idle:

Beitrag "Interrupt Sprungzeit"


Peter

Autor: Das delay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SHARP EL-531LH  0,000000062
TI-36X II       0,000000063
Windows Rechner 0,0000000625

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Casio FX 991:

16M => 1/x => 62.5n

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz klar, Du brauchst einen wissenschaftlichen Rechner :-)

Autor: Das delay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, habe das jetzt auch festgestellt.
Und nun geht das Problem los welcher.

Naja, ist ja bald Nikolausi und Weihnachten.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer auf einem 8- oder 10-stelligen Taschenrechner 1/16000000 statt nur 
1/16 rechnet, ist es aber auch selbst Schuld.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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....

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Passt alles noch sehr gut zum Thema
Macht doch eine Taschrecher Brett auf.

Autor: Das delay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Je genauer der TR desto weniger zappelt das Pixel auf dem Bildschirm.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist praktisch gesehen dasselbe!

Da stimme ich Dir mal einfach nicht zu.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Das ist praktisch gesehen dasselbe!
>Da stimme ich Dir mal einfach nicht zu.


Musst du auch nicht, aber zwischen
sync:        sbic PinB,1
             rjmp sync
und dem:
>mit dem Sleep?

besteht bei Betrachtung der sonstigen Aufgaben kein Unterschied!

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also muß Ich mir "nur" in die richtige Stelle aussuchen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.