- 12V Akku mit 280 Ah bauen         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 21

Thema: Timer1 - Clear Timer on Input-Capture?

  1. #11
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Beiträge
    41
    Anzeige

    Powerstation Test
    NEIN, verdammt, das ist ja bitter.
    Ich ärgere mich jetzt fast 2 Tage lang damit rum, versuche und tue und alles scheitert, nur weil da ein einfacher "oder Strich" fehlt.
    Vielen Dank für den Hinweis jetzt funktioniert es endlich. Ich bin richtig erleichtert, jetzt kanns endlich weiter gehen.
    Gibt es sonst noch was an dem Code, was ich verbessern könnte?
    Bin für Verbesserungsvorschläge immer dankbar, da ich mich nur an den Tutorials orientieren kann.

    MfG
    Destrono

  2. #12
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86
    Hallo Leute,
    Ich versuche auch mit einem Atmega644 20Mhz die Umdrehung zu messen.
    Ich habe mir das so vorgestellt: immer wenn der Hallsensor eine positive Flanke sendet. Soll der aktuelle Zählerwert gespeichert und zurückgesetz (man kann ihn Zurücksetzen steht im Datenblatt) werden.
    Stimmt das das ich den Hall sensor am Capture Pin anschließen muss (OC2B ?)um den 16-bit Timer zu benutzen?

    p.s. Ich habe noch nie mit Timern gearbeitet...
    lg

  3. #13
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Man kann den Timer auch über einen anderen Eingang nutzen. Es bietet sich aber an auch den Input-capture Pin zu nutzen.

    Wenn es sehr genau werden soll, sollte man den timer nicht zurücksetzen, sondern die Differenz berechnen. Bei zurücksetzen hat man immer noch die Verzögerung bis die ISR ausgeführt wird, und die ist nicht immer ganz gleich.

  4. #14
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Beiträge
    41
    Hallo,
    dazu hätte ich dann auch gleich noch mal eine Frage:
    Bei meiner Zündanlage ist der Hallsensor bei ca. 40 Grad vor dem Totpunkt des Motors angebracht,bei dem gezündet werden muss.
    In Abhängigkeit von der Drehzahl muss der Kontroller also die Zeit warten, die der Motor vom Durchlaufen des Hallsensors bis zum Totpunkt braucht. Dafür werde ich auch einen Timer einsetzten müssen und der muss wohl auch jedes mal neu gestartet werden, dann bei einem bestimmten Ocp Wert einen Interrupt auslösen, anschließend wieder gestoppt werden und das TCNTx Register muss auf 0 zurückgesetzt werden, oder gibt es da eine elegantere Lösung?
    Wenn nein, gibt es einen Möglichkeit herauszufinden wie lange der Kontroller alleine für das Starten des Timers braucht? Denn die Zeitintervalle müssen in diesem Fall bis auf die ms stimmen.

    MfG
    Destrono

  5. #15
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86
    Hallo,
    Also wenn ich mein Programm Simuliere, wird nicht PD6 (Capture Pin) verwendet, sondern PD4 (OC1B). Sollte nicht PD6 verwendet werden sobald ich das Register ICIE1 auf High setze?

    Meine 2 Frage ist, wenn ich einen Timer2 bis OCR2A laufen lasse, dann kommt es zu einem Overflow Interrupt, dabei wird der Timer auf 0 gesetzt. Zudem möchte ich, wenn Timer1 ein Interrupt aufruft, sol Timer2 gelöscht werden. Wenn ich das Overflow Flag setze(bei Timer2), löscht er sich nicht. Habt ihr eine Idee wie ich das am besten realisieren kann? TCNT2= 0 geht offenbar zu langsam??

    lg

    Code:
    #include <avr/io.h>
    #define F_CPU 20000000
    #include <util/delay.h>
    #include <avr/interrupt.h>
    
    // Umdrehung durch Hallsensor messen
    
    uint8_t softtimer = 0, LB =0, HB = 0;
    double TIME=0, OLDTIME = 0;
    
    ISR(TIMER1_OVF_vect)   	   // Timer1 Überlauf
    { 
      softtimer++; 		   // zählen der Überläufe
    } 
    
    ISR(TIMER1_CAPT_vect)      //  Flanke an ICP pin
    { 
            // Variablendeklaration
      
      LB = ICR1L;         // low Byte zuerst, high Byte wird gepuffert
      HB = ICR1H;  
      TIME = (HB<<8)| LB;
      
      if(softtimer) {
        TIME += 65535 * softtimer-OLDTIME;
        TIFR1 = (1<<TOV1);
      }
      OLDTIME = TIME;
    }
    
    
    int main(void) {
      TCCR1A = 0; // kein PWM, kein INPUT bei OC1...
      TCCR1B |= (1<<ICES1); // reagiert bei steigender Flanke
      TCCR1B |= (1<<CS11) | (1<<CS10); // TAKT /64
      TIMSK1 |= (1<<ICIE1)|(1<<TOIE1);  // ICP steigende Flanke und overflow
      TIFR1  |= (1<<TOV1);   
    
      DDRC = 0xff;
      PORTC =0;
    
      long int Zahl =0;
    
    
      while(1){
        sei();
        Zahl = TIME;
        cli();
        PORTC = Zahl;
        sei();
      }
      return 0;
    }

  6. #16
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.686
    Zitat Zitat von Destrono
    ... herauszufinden wie lange der Kontroller alleine für das Starten des Timers braucht ... die Zeitintervalle müssen ... bis auf die ms stimmen ...
    Meine Controller - z.B. mega168 und mega328 - laufen vorzugsweise mit 20 MHz. Die arbeiten in einer Millisekunde 20 000 (zwanzig tausend) Maschinenzyklen ab - genug Zeit, um einen Timer einzuschalten, auszulesen, abzuschalten - und dazwischen noch zu gähnen.

    Ich weiß nicht, ob Deine Millisekundengenauigkeit ausreicht. Wenn ich mein Moped mit einer nicht allzu hohen Drehzahl fahre - 7200 Upm - dann dreht die Kurbelwelle in 23 µs ein Grad - in einer Millissekunde rund 43 Grad. Deswegen brauche ich mich um Fehler im Millisekundenbereich nicht mehr zu kümmern. Bei solchen Fehlern steh ich schon am Strassenrand und telefoniere nach dem ADAC.
    Ciao sagt der JoeamBerg

  7. #17
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die verzögerung ab der Flanke die man per ICP detektiert, würde ich mit dem selben Timer machen, ohne den Timer neu zu starten. Zu dem wert aus dem ICP Registern wird die Verzögerung addiert und dann in eines der OCP Register geschreiben. Man bekommt so nach der Gewünschten Zeit einen Interrupt und ggf. auch gleich ein Signal am Ausgang. Das wird dann auf einen Zyklus (z.B. 100 ns bei 10 MHz Takt) genau.

    Die Verzögerung zum Stoppen/ Starten des Timers könnte man im Simulator bestimmen. Da wird vermutlich in der Größenordnung 50 Zkylen, also ein paar µs liegen.

  8. #18
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Beiträge
    41
    Zitat Zitat von Besserwessi
    Die verzögerung ab der Flanke die man per ICP detektiert, würde ich mit dem selben Timer machen, ohne den Timer neu zu starten.
    Das geht aber nur, wenn der Timer so langsam hochzählt, dass er nicht mehr als seinen Ausgangswert erreicht, oder?
    Bsp.: Der Timer 1(16bit) hat einen Zählstand von 65000 beim Eintreffen des ICPs. Muss die Zeitdifferenz zum Warten so groß sein, dass der Timer1 bis zum Overflow und dann anschließend noch bis 65500 hochzählen muss, gibt es Probleme, da sich über die Differenz und das Zählen der Overflows die korrekte Zeit nicht mehr ermitteln lässt, oder?
    In diesem Fall hlift es nur den Timer auf 0 zurückzusetzen, um eine konstante Zeitdifferenz für einen Overflow zu erhalten?

    Ich habe das mal durchgerechnet und bin bei einer Taktfrequenz des Kontrollers von 8Mhz, einer Drehzahl von 6000 U/min, dem Hallsensor, der 40 Grad vor dem Totpunkt angebracht ist, dem Timer 1 mit 16bit und einem Precaler von 256 auf eine Auflösung von 1/32 ms gekommen. Das wäre noch zu verkraften. Auch würde der Prescaler von 256 bei diesen Einstellungen einen Overflow verhindern.

    MfG
    Destrono

  9. #19
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die Einschränkung die man hat, ist das die Verzögerungszeit nicht zu lang für die 65000 Schritte des timers ist. Für ein Timer der mit 8 MHz läuf sind das dann ca. 125 ns * 65000 also ca. 8 ms. Es kann gut sein das der Timer in der Wartezeit einen überlauf hat, aber das stört überhaupt nicht, wenn man mit Word variablen rechnet - den Überlauf macht die Atithmetik in C auch genau so mit. Der Timer läuft die ganze Zeit durch, die Überläufe können also also praktisch jeder Position auftreten. Solage man keine Zeitdifferenzen hat, die länger sind als eine Überlauf des Timers ist das kein Problem. Das messen längerer Zeitdifferenzen geht auch, ist aber etwas schwieriger.

    Wenn die 8 ms für rund 45 Grad sein sollen, dann hätte man 64 ms per Periode oder ca. 930 U/min. Das wird gerade etwas knapp - also wäre dann doch ein kleiner Vorteiler (z.B. /8 ) nötig. Man hätte dann 1 µs an Zeitauflösung, und eine Mindestdehrzahl von etwa 150 U/min. Das sollte für einen kleinen Motor reichen. Wenn man sich bei der Drehzahlmessung und der Berechnung der Verzögerungszeit daraus die berücksichtigung der Überläufe sparen will, dann sollte man einen Vorteiler von 64 nehmen, damit man auch für eine volle Umdrehung höchstens einen Überlauf drin hat.

  10. #20
    Benutzer Stammmitglied
    Registriert seit
    08.06.2009
    Beiträge
    41
    Danke erst mal für die Hilfe.
    Die Berechnungen habe ich auch angestellt. Ich bin aber auf einen min. Prescaler 256 gekommen bei einer Drehzahl von max. 6000 U/min und einer Controllerfrequenz von 16Mhz.
    Ich muss aber trotzdem den Timer zurücksetzen, weil ich möchte, dass der Kontroller unter einer gewissen Drehzahl von z.B. 1U/s in den Modus Stillstand wechselt und nicht mehr zündet. Ohne Zurücksetzen des Timers könnte ich mit der bloßen Differenz und den Interrupts nicht exakt feststellen, wie viel Zeit zwischen zwei ICP Interrupts aufgetreten ist. Hierzu wieder ein Beispiel. Der alte, gespeicherte Zählerwert soll 65000 betragen. Der Timer zählt dann weiter hoch bis zum Overflow, dort kann er einen Interrupt auslösen. Nach dem Overflow zählt er wieder hoch bis 65500 und genau jetzt kommt der ICP Interrupt, mit dem die vergange Zeit ermittelt werden soll.
    Nur wie soll das gehen? Laut Differenz hat der Timer gerade mal 500 Schritte hoch gezählt. Und der Overflowinterrupt hilft einem auch nicht weiter, da man daraus keine Schlüsse auf die vergange Zeit schließen kann (da der Zähler ja bei 65000 angefangen hat und nicht bei 0 )

    Oder irre ich da, denn Besserwessi schreibt:
    Es sei denn:
    Zitat Zitat von Besserwessi
    Solage man keine Zeitdifferenzen hat, die länger sind als eine Überlauf des Timers ist das kein Problem. Das messen längerer Zeitdifferenzen geht auch, ist aber etwas schwieriger.
    Und noch eine kurze Frage hinterher, da ich mich mit der kontrollerinternen Arithmetik nicht auskenne:
    Ist so was möglich ? Wenn ja, macht es Sinn, oder geht der Fließkommavorteil beim Umwandeln in eine Ganzzahl wieder verloren?
    Code:
    OCR1A = (unsigned short int) ( current_icp +  current_icp / 9.00) ;


    MfG
    Destrono

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Berechtigungen

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

LiFePO4 Speicher Test