-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: Signal-Länge erfassen und gleichzeitig verlängert ausgeben?

  1. #1
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    23.05.2004
    Beiträge
    209

    Signal-Länge erfassen und gleichzeitig verlängert ausgeben?

    Anzeige

    Hallo,

    eine vielleicht seltsame Überschrift, aber besser habe ich es nicht hinbekommen

    Ich will die HIGH-Phase ein einem Pin Messen und gleichzeit diese Länge + x% Verlängerung wieder ausgeben. Anbei eine Skizze, oben das Original-Signal, mitte das manipulierte Signal bei dem halt die HIGH-Phase verlängert ausgegeben werden soll.
    Aber die Verlägerung sollte nahtlos angefügt werden, nicht erst durch ein Low-Einsatz unterbrochen werden.

    Das zu verlängernde Signal hat ca eine Länge von 3-20ms. Ist eine solche nahtlose Verlängerung real-time übehaupt machbar? Oder muß erst eine HIGH-LOW-Phase zum messen durchlaufen werden?

    Ich erwarte keine fertige Software, nur vielleicht ideen.

    Ich wollte per timer eine abfrage alle 1/1000 sekunden machen, ob der Eingang Pin auf High ist, gleichzeitig den Ausgangpin auf high setzen. und wenn der Eingangspin das erste mal auf low ist eine berechnung der vergangen High-Zeit machen und die HIGH-Phase vom Ausgangspin dahin gehend verlängern....

    Oder wer hat da eine bessere Idee? Besten Dank schonmal.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken high_low.gif  

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    05.08.2007
    Ort
    Oberhofen im Inntal (Tirol)
    Alter
    43
    Beiträge
    377

    Re: Signal-Länge erfassen und gleichzeitig verlängert ausgeb

    Zitat Zitat von m_herr
    Aber die Verlägerung sollte nahtlos angefügt werden, nicht erst durch ein Low-Einsatz unterbrochen werden.
    Hallo m_herr!

    Du kannst es dir einfach machen:
    Code:
    dim my_counter as word
    
    if eingang = 1 then
        ausgang = 1
        my_counter = 0
    else
        incr counter
        if my_counter > 10000 then
            ausgang = 0
        end if
    end if
    Um den richtigen Wert für "my_counter" zu ermitteln, musst du ein wenig probieren. Und vielleicht kannst du es sogar mit einem Oszi messen.

    Wenn es ganz genau sein soll, dann kannst du die Variable "my_counter" von einem Timer hochzählen lassen.

    mfg
    Gerold
    :-)

  3. #3
    Eine zusätzliche (etwas elegantere) Variante von Pythons Lösung:

    Dein Signal auf den Input Capture-Pin leiten und damit den Counter starten. sobald der Counter stoppt (Flanke des Signals) kannst du dein Wert berechnen und den anderern Pin entsprechend setzen.

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Wie man das am besten löst (einige gute Ideen gibt´s ja schon) hängt m.E. auch noch von 3 wichtigen Fragen ab:

    1. Haben die Impulse immer die gleiche Länge, oder variiert die Pulsdauer?

    2. Falls die Impulsdauer variabel ist: Muss sich die anzuhängende Zeit auch verändern, d.h. stellt sie einen bestimmten Prozentsatz vom Ursprungsimpuls dar, oder hat diese Zuatzzeit eine konstante Länge?

    3. Muss der Controller "nebenbei" noch was anderes machen, oder ist das sein einziger Job?

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    23.05.2004
    Beiträge
    209
    Vielen Dank für die Antworten.

    zu 1.) Nein, wie oben schon geschrieben steht, variert die Länge zwischen 3-20ms.

    zu 2.) Die Verlängerungszeit sollte immer Prozentual von der High-Periode sein. Nehmen wir 10% dann sollte halt 10% länger sein.


    zu 3.) Ja, der Chip sollte noch was machen. 3 ADC-Auswertungen alle 200ms. Dann per TX ca 50 Zeichen alles 500ms Senden, einige Pins toggeln und auch per ICP/Counter etwas Frequenz messen.
    Atmega16 mit 4MHZ

    Zur Not könnte aber auch der Atmega16 mit 8MHZ laufen - grob über den Daumen gepeilt: ginge dies?

  6. #6
    Zitat Zitat von m_herr
    Zur Not könnte aber auch der Atmega16 mit 8MHZ laufen - grob über den Daumen gepeilt: ginge dies?
    Ja, mit der Input-Capture Methode sollte es ohne Weiteres gehen.

  7. #7
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    23.05.2004
    Beiträge
    209
    die fällt leider schon wegen Belegung aus....

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Ja, der Chip sollte noch was machen.
    Dann bleiben eigentlich nur Interrupts - gaaaanz grob würd´ ich es etwa so machen:

    Der Original-Impuls wird auf einen Interrupt-Eingang gelegt, der auf wechselnde Flanke konfiguriert ist.

    In der ISR wird abgefragt, ob der PIN 1 oder 0 ist.

    Wenn der Pin gerade 1 ist, dann wird der Ausgangs-Port (beliebig) auf 1 gesetzt, ein Timer gestartet und dann return.

    Wenn der Pin 0 ist, wird der wird der Timer gestoppt, sein Wert an eine Variable übergeben und der Timer auf 0 gesetzt. Diese Variable wird z.B. durch 10 geteilt (für 10%) und in das Output-Compare-Registers des Timers geschrieben. Der Timer wird gestartet und der Output-Compare-Interrupt freigegeben, und return.

    In der Output-Compare-ISR (die logischerweise nach weiteren 10% Zeit erreicht wird) passiert folgendes:
    Der Ausgangs-Port wird auf 0 gesetzt, der Timer gestoppt und auf 0 zurückgesetzt. Und, ganz wichtig, den Output-Compare-Interrupt deaktivieren, damit er beim "langen" hochzählen während des nächsten Impulses nicht "zuschlägt". Und return!

    Ich hoffe, dass das jetzt nicht zu wirr war

    Gutes Gelingen!

  9. #9
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    23.05.2004
    Beiträge
    209
    Mh, also Timer0 und Int0 benutzen?

  10. #10
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    705
    Im Prinzip ja, aber der 16-bit Timer1 wäre von der Auflösung deutlich geeigneter. Immerhin überstreicht der Bereich der möglichen Impulsdauern ja schon fast eine Zehnerpotenz, und wenn dann die notwenidige Division durch 10 noch ein halbwegs sauberes Ergebnis liefern soll, müsste sich der auszuwertende Zählerstand schon in einer anderen Größenordnung bewegen als irgendwo kurz vor 255...

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •