- LiFePO4 Speicher Test         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 23

Thema: sehr Kurze Warteschleifen für das korrekte Timing

  1. #11
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Anzeige

    LiFePo4 Akku selber bauen - Video
    Zitat Zitat von witkatz Beitrag anzeigen
    Hallo Siro,
    mit while blockierst du wieder den µC. Wenn der PIC in der Wartezeit noch andere Sachen tun soll ....
    Was soll in 500ns (in Worten Nanosekunden) wohl sinnvolles passieren? Da kann man kaum einen Call, ein Return und das Retten von einem Register unterbringen.

    Zitat Zitat von Peter(TOO) Beitrag anzeigen
    NOPs verwendet man eigentlich nur, wenn man nur ein paar braucht, sonst bremst man die CPU aus.
    Also genau hierfür, wo man um eine lahme HW herumprogrammieren muß

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  2. #12
    Erfahrener Benutzer Roboter-Spezialist Avatar von witkatz
    Registriert seit
    24.05.2006
    Ort
    NRW
    Alter
    54
    Beiträge
    542
    Blog-Einträge
    17
    Zitat Zitat von Klebwax Beitrag anzeigen
    Was soll in 500ns (in Worten Nanosekunden) wohl sinnvolles passieren?
    Dafür natürlich nicht. Ein Zeichen ausgeben mit einem (oder zwei bei 4bit Anschluss) Strobe auf Enable des LCD kann natürlich in einem Schritt untergebracht werden.
    Zwei Postings weiter hat Siro ein __delay_ms(2) - Wartezeit für die Ausführung des LCD Kommandos. Auch wenn hier 100µs ausgereicht hätten - dafür lohnt sich das Multitasking schon mal - wenn der µC parallel noch andere Aufgaben rechnet.

    - - - Aktualisiert - - -

    meine Schrittkette sieht z.B. so aus:
    Code:
        if(Tmr8bit250usLcd == 0){
            Tmr8bit250usLcd = 4; // Standardtaktung 1ms, kann in der Statemachine überschrieben werden
            static int8_t step = 0; 
    
            switch(step){ 
            case 0: // Set DDRAM Adresse = 0x00
                LCD_TRIS_DATA = 0; // Data Pins to Outputs
                LCD_RS = 0; // command
                LCD_DATA = 0b10000000;
                strobeE();
                Tmr8bit250usLcd = 20; // next call 5ms
                Idx = 0; // Initilaisiere Zeichenausgabe
                step++; 
                break;
    
            case 1: // 16 Zeichen der Line 1 ausgeben
                LCD_RS = 1; // data
                LCD_DATA = LCD_line1[Idx];
                if (LCD_DATA == 0)
                    LCD_DATA = ' ';
                strobeE();
                Idx++;  // Nächstes Zeichen der Zeile
                if (Idx >= 16) {
                    Idx = 0;
                    step++;
                }
                break;
    //usw
    mit
    Code:
     void strobeE(){
        LCD_E = 1;
        __delay_us(1);               // delay 1us
        LCD_E = 0;
    }
    Die Timervariable Tmr8bit250usLcd wird in einem 250µs Timerinterrupt dekrementiert.
    Code:
        if (Tmr8bit250usLcd != 0)
            Tmr8bit250usLcd--;
    Ist natürlich nur ein Vorschlag, vielleicht habe ich Siro's Frage auch nur falsch verstanden ...
    Geändert von witkatz (23.06.2016 um 21:15 Uhr)

  3. #13
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    66
    Beiträge
    2.435
    Hallo,
    Zitat Zitat von Klebwax Beitrag anzeigen
    Was soll in 500ns (in Worten Nanosekunden) wohl sinnvolles passieren? Da kann man kaum einen Call, ein Return und das Retten von einem Register unterbringen.
    Er bekommt in die 500ns immerhin 37 NOPs rein @72MHz.

    Je nach CPU kann man in dieser Zeit schon einiges rechnen.

    - - - Aktualisiert - - -

    Zitat Zitat von HaWe Beitrag anzeigen
    ich verwende für solche "Probleme" grundsätzlich Multitasking, und zwar
    Auch bei 72MHz reichen die 500ns nicht einmal für einen Taskswitch des Schedulers aus. Hier ist dann meist die Anzahl CPU-Register das Problem.
    Bei 32 Registern und einem PUSH/POP ALL-Befehl kommt man für den Wechsel auf mindestens ein Äquivalent von etwa 100 NOPs. Dann nochmals zurück, sind dann 200 NOPs, wo 37 reichen würden. Wenn die Busbreite nur die Hälfte der Registerbreite beträgt ist es gleich mal das Doppelte.

    500ns sind einfach eine doofe Zeit für dieses Problem

    Eine Möglichkeit habe ich noch vergessen, meist hat man so etwas:
    Code:
    put_LCD(char c)
    {
      Daten ausgeben
      Delay(500ns)
      Strobe setzen
      Strobe rücksetzen
    }
    
    LCD_Out(char *s)
      {
        while (*s)
         {
            put_LCD(*s);
            s++;
            // evtl. noch weiteres.
         }
      }
    Wenn man jetzt eben nicht streng strukturiert programmiert, kann man "s++:" und weiteres in das delay(500ns); verlegen.
    Code:
    put_LCD(char c)
    {
      c ausgeben
      Delay(500ns)
      Strobe setzen
      Strobe rücksetzen
    }
    
    LCD_Out(char *s)
      {
        while (*s)
         {
           c ausgeben
           s++;
           // evtl. noch weiteres.
          Delay(Restzeit)
          Strobe setzen
          Strobe rücksetzen
         }
      }
    Ist dann halt nicht so übersichtlich, aber sogar schneller, weil der Overhead für den Aufruf von put_LCD() wegfällt.
    Allerdings muss man sehen, dass man die Optimierung des Compiler ausschaltet, sonst weiss man nicht was ab geht.
    Sinnvoll kann auch der Einsatz von Inline Assembler an dieser Stelle sein, das kann der Compiler dann nicht optimieren und man hat immer den selben Code.
    Allerdings trägt man dann selber die Verantwortung, wenn sich die CPU-Frequenz ändert. Das lässt sich aber teilweise mit Macros automatisieren.
    Besonders bei CISC-CPUs muss man dann aber noch aufpassen, dass kompatible CPU-Versionen nicht unbedingt die selbe Zyklenzahl für die Befehle benötigen.
    Bei RISC-CPUs ändert die Zyklenzahl meistens nicht, da sie meistens der Anzahl Speicherzyklen entspricht.
    In beiden Fällen spielt dann aber noch das Pipelining und vorhandener Cache ins Timing mit rein.
    Hier kann es auch hilfreich sein, JMPs an Stelle der NOPs zu verwenden.

    Ach, früher war das alles einfacher

    MfG Peter(TOO)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  4. #14
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Peter(TOO) Beitrag anzeigen
    Hallo,

    Er bekommt in die 500ns immerhin 37 NOPs rein @72MHz.

    Je nach CPU kann man in dieser Zeit schon einiges rechnen.
    Nicht wirklich. Erst mal muß man einige Register retten, sie mit neuen Werten laden, dann ist die halbe Zeit rum und man speichert die Werte zurück und lädt die Register zurück und hat noch nichts gerechnet. Und je schneller die CPU, desto mehr Register sind betroffen und desto langsamer ist der Speicher im Vergleich zu Registern. Zeitscheiben im einstelligen Mikrosekundenbreich sind wegen des Taskswitchoverhead keine brauchbare Idee, mehr eine akademische Luftnummer.

    Aber es läßt sich sicher ein exotisches Beispiel finden, wo das sinnvoll ist.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  5. #15
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    66
    Beiträge
    2.435
    Hallo Klebwachs,
    Zitat Zitat von Klebwax Beitrag anzeigen
    Nicht wirklich. Erst mal muß man einige Register retten, sie mit neuen Werten laden, dann ist die halbe Zeit rum und man speichert die Werte zurück und lädt die Register zurück und hat noch nichts gerechnet. Und je schneller die CPU, desto mehr Register sind betroffen und desto langsamer ist der Speicher im Vergleich zu Registern. Zeitscheiben im einstelligen Mikrosekundenbreich sind wegen des Taskswitchoverhead keine brauchbare Idee, mehr eine akademische Luftnummer.
    Das habe ich alles in der Antwort an HaWe ausführlich erläutert.

    MfG Peter(TOO)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  6. #16
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Guten Morgen, Ihr wart ja fleissig , erstmal vielen Dank
    für Eure Informationen und Ideen.

    @ Sisor:
    Ja, Du hast recht, so kann ich den Timerüberlauf ignorieren. Gefällt mir sehr gut.


    @Klebwax:

    Ich hab die "2ms" nur zum Testen/Bestätigen das dort das Problem liegt eingebaut.
    Das ist natürlich völlig "überdosiert"


    Die Idee, dass der Compiler an bestimmten Stellen NICHT optimiert, wäre in meinem Falle
    sogar auch eine Lösung, find ich aber etwas unschön.


    @Witkatz:
    Ich habe so etwas in der Art auch schon implementiert.
    Sieht fast aus wie dein Code :

    Code:
    typedef struct 
    {
      void (*function)(); /* do this function */
      U32   microSec;     /* do next function after xxx micro second */
    } t_TimerFunc;
    
    /* shift out time for one byte is 17,92 microsec. we calc with 25 for every byte */
    /* the latch signal are set to 5 microsec. active phase and 5 microsec. recovery time */
    
    const t_TimerFunc functable[] = {
    
    {fn_shift_out_leds,100},       /* shift out 32 Bit LED code, after 100 microsec. */
    {fn_DISP_ENABLE_LEDS_HIGH,5},  /* generate the latch signal for 5 microsec. high*/     
    {fn_DISP_ENABLE_LEDS_LOW,5},   /* reset the latch signal to low */
    
    {fn_shift_out_pressure,50},    /* shift out 16 Bit data for pressure display, after 50us*/
    {fn_DISP_ENABLE_P_HIGH,5},     /* generate the latch signal for 5 microsec. high */
    {fn_DISP_ENABLE_P_LOW,5},      /* reset the latch signal to low */
    
    {fn_DISP_ENABLE_Q_LOW,5},      /* enable data for the flow display */
    {shift_out_flow,100},          /* shift out, 5 Bytes, data for flow display */
    {fn_DISP_ENABLE_Q_HIGH,5},     /* disable data for the flow display */
    
    {fn_DISP_ENABLE_V_LOW,5},      /* enable data for the volume display */
    {fn_shift_out_volume,125},     /* shift out data, 5 Bytes, for volume display */
    {fn_DISP_ENABLE_V_HIGH,5},     /* disable data for the volume display */
    
    . . . . 
    
    Wie dem obigen Codeausschnitt zu entnehmen ist, wurde eine spezielle Struktur angelegt um die Vorgehensweise 
    möglichst übersichtlich zu gestalten. Der Timer Interrupt ruft jeweils die entsprechende Funktion auf und 
    startet dann eine neue Zeitzähleinheit. Nach Ablauf der Zeit wird die nächste Funktion aufgerufen. 
    Wurden alle Funktionen durchlaufen, wird wieder mit der ersten Funktion in der Tabelle begonnen. 
    Die entsprechende Timer Interrupt Funktion konnte so kurz und übersichtlich implementiert werden.
    Für dieses Vorgehen  wurde der Prozessorinterne Timer 1 verwendet.
    fn_xxxxxx sind die entsprechenden Funktionen die aufgerufen werden.
    
    void TMR1_IRQHandler (void)
    {
      functable[timer1FuncNo].function();  /* do the selected function */
      LPC_T1TCR.bits.CR = 1;               /* set reset STOP and HOLD Timer */
     
      /* set the new time for the next interrupt */
      LPC_T1MR0 = functable[timer1FuncNo].microSec;
    
      /* selects the next function which want to call from this interrupt */
      if (++timer1FuncNo >= ((sizeof(functable) / sizeof(t_TimerFunc))))
            timer1FuncNo = 0; 
    
      LPC_T1IR.bits.MR0INT = 1;    /*clear the timer match interrupt */
      LPC_T1TCR.bits.CR    = 0;    /* release reset START Timer */
    }
    
    
    
    Um Sicherzustellen, dass alle Funktionen weniger Zeit benötigen, als angegeben, wurden die Laufzeiten mit einem 
    Oszilloskop gemessen. Dazu wurde am Anfang der Funktion ein Portbit gesetzt und am Ende der Funktion wieder gelöscht. 
    Dieses Portbit konnte so ohne Probleme mit einem Oszilloskop abgegriffen werden und die Laufzeiten anhand der 
    High Phase des Signal gemessen werden. Die Laufzeiten wurden mit verschiedenen C-Compiler Optionen gemessen 
    um sicherzustellen, daß unabhängig von den Compiler Einstellungen, die Zeiten eingehalten werden. 
    Es wurde auf Speed, Size und Balanced mit hoher, niedriger und völlig ohne Optimierung gemessen. 
    Die langsamste Variante war die völlig ohne Optimierung. Diese maximalen Zeiten wurden in der Software, 
    in den entsprechenden Funktionen, als Kommentar mit aufgenommen.
    
    Es wurde jedoch aus Sicherheitsgründen noch ein Rekursionstest eingeführt. Sollte sich die 
    Software innerhalb einer Funktion der Tabelle befinden und es erfolgt, aus welchen Grund auch immer, ein erneuter Eintritt 
    in diese Timerfunktion, liegt ein Fehler vor und das Gerät wird sofort angehalten. Dadurch könnte sonst ein Stacküberlauf 
    generiert werden und dies soll natürlich abgeblockt werden. Normalerweise ist dieses Vorgehen nicht nötig, da der Interrupt
    erst am Ende des Interrupt Handlers bestätigt wird und damit das momentan anstehende Interruptbit gelöscht wird. 
    Ich habe mich aber aus Sicherheitsgründen trotzdem für diese Vorgehensweise entschieden.
    Ich werde mich für die Timer Variante entscheiden, ein paar Mikrosekunden warten, spielt in dieser, meiner Anwendung keine Rolle.
    Habe ein 16 Bit Timer übrig, der dafür ausreicht.

    Meine While Schleife für den Timerwert blockiert ja nur kurzzeitig das Hauptprogramm,alle Interrupts laufen ja weiter. ADU, RS232 usw.

    Siro

    - - - Aktualisiert - - -

    Ich habe noch einen wichtigen Grund, warum ich der Delay Funktion niemals eine "1" übergebe:
    Es könnte passieren, dass garnicht gewartet wird.
    Wenn nach dem Setzten der globalen Variablen DelayCount der Timerinterrupt schon auftritt,
    wird der Wert gleich um eins runtergezählt und die While Schleife sofort wieder verlassen.
    Wir haben also generell eine Abweichung von ca. -1 Millisekunde.
    Code:
    /* EXTREM wichtig: volatile, sonst optimiert der Compiler Code weg */
    volatile static U32 DelayCount;  /* used for Delay_ms function */
    
    /*----------------------------------------------------------------------------*/
    /* DelayCount wird im Interrupt kontinuierlich um 1 runtergezählt */
    /* sofern er nicht schon 0 ist.
    
    void Delay_ms(U32 ms)
    {
      DelayCount = ms;
    
      while (DelayCount) ;
    }
    /*----------------------------------------------------------------------------*/
    /* this Interrupt handler is called every Millisecound */
    
    void SysTick_Handler(void)
    {
      if (DelayCount) DelayCount--;
    }
    /*----------------------------------------------------------------------------*/
    Geändert von Siro (24.06.2016 um 09:06 Uhr)

  7. #17
    Erfahrener Benutzer Roboter-Spezialist Avatar von witkatz
    Registriert seit
    24.05.2006
    Ort
    NRW
    Alter
    54
    Beiträge
    542
    Blog-Einträge
    17
    Zitat Zitat von Siro Beitrag anzeigen
    @Witkatz:
    Ich habe so etwas in der Art auch schon implementiert.
    Coole Idee mit der Funktionstabelle. Hab ich mir gemerkt

    Zitat Zitat von Siro Beitrag anzeigen
    Ich habe noch einen wichtigen Grund, warum ich der Delay Funktion niemals eine "1" übergebe:
    Es könnte passieren, dass garnicht gewartet wird.
    Wenn nach dem Setzten der globalen Variablen DelayCount der Timerinterrupt schon auftritt,
    wird der Wert gleich um eins runtergezählt und die While Schleife sofort wieder verlassen.
    Ich nehme für solche ms-Timings lieber einen 250µs Basistakt. Damit können mit einem char-Zähler (8bit PIC -> char wo es nur geht) Wartezeiten von 1ms bis 1s ziemlich gut realisiert werden, wenn eine Abweichung von 250µs keine Rolle spielt.

  8. #18
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Siro Beitrag anzeigen
    Die Idee, dass der Compiler an bestimmten Stellen NICHT optimiert, wäre in meinem Falle
    sogar auch eine Lösung, find ich aber etwas unschön.
    C ist in seiner ursprünglichen Form für die embeded Programmierung eigentlich nicht geeignet. Ohne einen Mechanismus, der die Optimierung steuert, geht nichts. Der Compiler würde sonst jede Abfrage von Funktionsregistern bis zur Unbrauchbarkeit optimieren. Stichworte sind volatile und INTRINSIC FUNCTIONS. Es mag für dich zwar unschön sein, ist aber unumgänglich.

    Code:
    void strobeE(){
        LCD_E = 1;
        __delay_us(1);               // delay 1us
        LCD_E = 0;
    }
    Wenn hier nicht ein solcher Mechanismus greifen würde, würde der Compiler das Setzen von LCD_E auf 1 rausschmeißen. Da niemand LCD_E liest, während es 1 ist, kann es auch gleich auf 0 gesetzt werden. Toter Code. LCD_E muß also volatile sein, damit das funktioniert.

    @Peter

    Ich habe deine Antwort nur bis --aktualisiert-- lesen können, als ich schrieb.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  9. #19
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    @Klebwax:
    Das Problem Optimierung ist mir schon recht oft zum Verhängnis geworden.
    Genau in solchen Situationen wie Du eben beschrieben hast.
    Habe immer öfter bemerkt, dass ein "volatile" unumgänglich ist, damit der "schlaue" Compiler es auch "richtig" versteht.
    Am Anfang hab ich immer gemerkert warum der Compiler meinen Code klaut,
    Er hat ja recht würd ich aus heutiger Sicht sagen, woher soll er wissen dass......


    Ich hab grad noch etwas rumprobiert und da stellt sich gleich noch eine Frage:

    Zuvor der Code, der schien zu laufen.....
    Beim Timerüberlauf stimmt aber die Berechnung nicht mehr. Doch dazu später....

    Code:
    /*--------------------------------------------------------------------------*/
    /* static volatile U16 t_old; */
    
    inline void wait_us(U16 us)
    { U16 t_old;
    
      t_old = TIMER1_TC;
      while ((TIMER1_TC - t_old) < us) ;
    }
    /*--------------------------------------------------------------------------*/
    Nun zur Frage:

    Ich habe das Schlüsselwort "inline" benutzt, damit darf der Compiler den Code ja direkt einsetzen ohne einen Call.
    Ob er das macht bleibt glaube ich ihm überlassen.
    Damit ich meine Funktion evtl. sogar aus verschiedenen threads bzw. Interrupts aufrufen könnte, müsste mein Variable t_old ja Dynmsich auf dem Stack liegen, also Lokal zum Funktionsaufruf.
    Aber wie funktioniert das mit dem Inline, ist das überhaupt erlaubt ? Inline und lokale Variable ?

    Der Compiler könnte den Call nun sparen aber was macht er mit der Variable t_old ? die müste er ja dynamsich auf dem Stack verwalten.
    Wenn es um Geschwindigkeit geht und ich nur aus einem Thread die Funktion aufrufe, kann ich die Variable ja Global anlegen,
    ich vermute hier wird er den besten Code dafür erzeugen können.
    Geändert von Siro (24.06.2016 um 14:18 Uhr)

  10. #20
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Warum meine Berechnung nach Timerüberlauf nicht mehr funktioniert, habe ich unn auch ermittelt.


    while (TIMER1_TC - t_old < us) ; /* geht nicht */

    /* Also "komplette" explizite Typwandlung auf allen Werten und Ergebnissen angewendet: */

    while ((U16)((U16)(TIMER1_TC) - (U16)(t_old)) < us) ; /* siehe da, es funktioniert */

    /* nun Typwandlungen gekürzt */

    while ((U16)(TIMER1_TC - t_old) < us) ; /* auch OKAY */


    Durch die Integer Promotion des Standard Typs int bei 32 Bit muss hier anscheinend das Ergebnis der Subtraktion
    explizit wieder in einen unsigned 16 Bit gewandelt werden, sonst geht es schief, jedoch nur manchmal, je nach Timerstand.

    Ich bin begeistert und kann nun das Wochenende geniessen...
    Habt auch ein schönes, warmes WE.

    Siro

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Ähnliche Themen

  1. Lipo-Ladegerät auf korrekte Funktion prüfen
    Von Che Guevara im Forum Elektronik
    Antworten: 2
    Letzter Beitrag: 17.03.2013, 11:51
  2. Korrekte Beschaltung eines Relais an einem AVR
    Von Björn im Forum AVR Hardwarethemen
    Antworten: 51
    Letzter Beitrag: 10.08.2009, 18:20
  3. Korrekte Schallmessung
    Von Dolfo im Forum Sensoren / Sensorik
    Antworten: 3
    Letzter Beitrag: 15.09.2008, 23:54
  4. Antworten: 3
    Letzter Beitrag: 18.01.2007, 22:10
  5. Warteschleifen bei ATMEL
    Von monoton im Forum C - Programmierung (GCC u.a.)
    Antworten: 8
    Letzter Beitrag: 08.09.2004, 01:15

Berechtigungen

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

Labornetzteil AliExpress