Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum
Re: Zeitsprünge Kategorie: IDE (von PeterS - 30.03.2012 14:11)
Als Antwort auf Re: Zeitsprünge von Joerg - 30.03.2012 10:38

> > > > > > > > Hallo Peter,
> > > > > > > >
> > > > > > > > mir sind, seitdem ich die neue Beta (2.20.0.16) benutze, Zeitsprünge mit
der internen Uhr aufgefallen.
> > > > > > > >
> > > > > > > > Ich habe ein Programm, welches Messdaten erfasst und diese zusammen mit der
> > > > > > > > Uhrzeit auf der Seriellen Schnittstelle ausgibt. Hin und wieder kommt es vor,
> > > > > > > > das die Uhrzeit von z.B. 18:38:49 auf 00:00:00 wechselt, ohne das ich die Uhr mit
> > > > > > > > Clock_SetTime() gestellt habe.
> > > > > > > >
> > > > > > > > Das interessant dabei ist, das auch das Datum dabei auf den nächsten Tag springt.
> > > > > > > >
> > > > > > > > Gibt es hierfür ein Erklärung (z.B interner �berlauf)?
> > > > > > > >
> > > > > > > > Hier sind zwei protokollierte Zeitsprünge:
> > > > > > > >
> > > > > > > >
> > > > > > > > 1)
> > > > > > > > 18:38:48 18:03:12  392 8 6.250000 0 0 0 0
> > > > > > > > 18:38:49 18:03:12  392 8 6.250000 0 0 0 0
> > > > > > > > 00:00:00 19:03:12  384 6 6.187500 0 0 0 0
> > > > > > > > 00:00:01 19:03:12  384 6 6.187500 0 0 0 0
> > > > > > > >
> > > > > > > >
> > > > > > > > 2)
> > > > > > > > 22:25:08 18:03:12  6 2 5.562500 0 0 1 0
> > > > > > > > 22:25:09 18:03:12  6 2 5.562500 0 0 1 0
> > > > > > > > 00:00:00 19:03:12  6 2 5.562500 0 0 1 0
> > > > > > > > 00:00:01 19:03:12  6 2 5.562500 0 0 1 0
> > > > > > > >
> > > > > > > > Grü�e Joerg
> > > > > > >
> > > > > > > Hallo Joerg,
> > > > > > >
> > > > > > > werde ich heute mal testen.
> > > > > > >
> > > > > > > Gruss Peter
> > > > > >
> > > > > > Hallo Peter,
> > > > > >
> > > > > > ich habe nun neue Erkenntnisse bezüglich der Zeitsprünge.
> > > > > >
> > > > > > Zuerst habe ich versucht, die Zeitsprünge zu detektieren und zu protokollieren.
> > > > > > Dabei habe ich festgestellt, dass die Häufigkeit und Art der Fehler mit der Grö�e des Codes zunimmt.
> > > > > > Zum Schluss bekam ich dann auch mal mit Clock_GetVal(CLOCK_SEC) Sekundewerte von 72 oder 110!
> > > > > >
> > > > > > Völlig frustriert bin ich dann auf die Version 2.13.015 zurück. Hierbei musste ich dann aber feststellen,
> > > > > > dass mit dieser Version noch alles viel schlimmer war. Selbst die globalen Variablen,
> > > > > > die ich zum protokollieren benutze, haben sich verändert.
> > > > > >
> > > > > > Ich habe dann über das Problem von Jo mit zu gro�em Code nachgedacht und folgendes durchgeführt:
> > > > > >
> > > > > > Unter Project Optionen habe ich â??Debug Code erzeugenâ?? und â??Array Index Grenzen überprüfenâ??
> > > > > > abgewählt. Alles andere ist angewählt. #
> > > > > > Der generierte Bytecode ging dann von ca. 26100 auf 23800 zurück.
> > > > > >
> > > > > > Mit dieser Einstellung konnte ich mit der Version 2.13.015 und 2.20.016 keine Zeitsprünge mehr feststellen!
> > > > > > Das ganze läuft jetzt mit der 2.20.016 seit 14Stunden ohne Fehler.
> > > > > >
> > > > > > Ich vermute deshalb, dass es immer noch Fehler gibt bei zu groÃ?em Code.
> > > > > >
> > > > > >      
> > > > > > Mit der Version 2.20.016 sind mir noch einige Dinge Aufgefallen:
> > > > > >
> > > > > > 1) Beim Laden erscheint manchmal im Ladebalken â??Wiederholeâ??.
> > > > > > 2) Der Irq_GetCount(INT_TIM2COMP) hat früher beim ersten Aufruf immer einen zufälligen Wert.
> > > > > >     Dieser ist jetzt aber 1.
> > > > > > 3) Die Fenster im Editor lassen sich nur noch in voller Grö�e darstellen.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Grü�e Joerg
> > > > >
> > > > > Hallo Joerg,
> > > > >
> > > > > danke für die Infos. Ich hatte selber mal getestet, konnte aber kein Problem feststellen. Wenn
> > > > > das mit zu gro�em Code zu tun hat, wäre es gut, wenn Du mir vielleicht wieder ein Beispielprojekt
> > > > > schicken könntest.
> > > > >
> > > > > Bleibt das "Wiederhole" denn stehen, oder blitzt das nur kurz auf? Ich habe vieles am Handling
> > > > > des USB Virtual Comport in der Beta geändert. Man kann jetzt viel gefahrloser komplett den
> > > > > Strom der C-Control Unit ausschalten, was früher oft zu einem "hängen" des virtuellen Comport
> > > > > geführt hat.
> > > > >
> > > > > Gruss Petera
> > > >
> > > > Hallo Peter,
> > > >
> > > > das â??Wiederholeâ?? blitzt immer mal wieder kurz auf (ca.4 mal pro Ladevorgang).
> > > > Ich lade nur mit der seriellen Schnittstelle.
> > > >
> > > > Ich hatte dir bisher nie ein Beispielprojekt geschickt.
> > >
> > > Sorry, ich hatte kurz nach meiner Nachricht auch gegrübelt, ob Du der
> > > Joerg warst, der mir schon ein Beispiel geschickt hat.
> > >
> > > > Welche Erwartungen hast du denn daran?
> > > > Das man es kompilieren und laden kann oder soll es auch laufen?
> > > >
> > > > Das Programm ist äu�erst komplex wie man an der Grö�e erkennen kann.
> > > > Ich habe ein Projectboard PRO128 mit sehr viel externen I2C Erweiterungen und Sensoren.
> > > > Wenn die nicht vorhanden sind, gibt es sehr viele Fehlerausgaben und es tut nicht mehr das,
> > > > was es soll. Ich müsste es dann noch modifizieren. Ob man den Fehler dann noch erkennen kann,
> > > > ist fraglich. Auch schalte ich meinen Detektor erst dann an, wenn mindestens ein
> > > > korrekter DCF Update stattgefunden hat. Bei mir findet ein DCF Update nur dann statt,
> > > > wenn zwei aufeinander folgende Minuten richtig erkannt werden und die Differenz nur eine Minute ist.  
> > > >
> > > > Bei der Programmierung des Detektors habe ich festgestellt, das jede Ã?nderung am Code
> > > > die Häufigkeit und Art des Fehlers beeinflusst. Ich hatte auch Versionen,
> > > > da trat der Fehler nur 1mal in 24h auf. Man muss auf das Ergebnis also manchmal sehr lange warten.
> > > >
> > > > Gibt es hier eigentlich jemand, dessen Projekt noch wesentlich grö�er ist als meins?
> > >
> > > Ja, ich hatte schon ein Beispiel, was genau an die Grenze der 128kb Flash heran reicht. Da
> > > hatte ich in der Vergangenheit ein Problem behoben, was aber nichts mit den Zeitroutinen
> > > zu tun hat.
> > >
> > > Ohne Beispiel das den Fehler reproduziert, habe ich es echt schwer den Bug zu finden.
> > >
> > > Gruss Peter
> > >
> > > >
> > > >
> > > > Grü�e Joerg
> > > >
> >
> > Hallo Peter,
> >
> > ich versuche mal den Fehler ohne spezielle Hardware zu reproduzieren.
> >
> > Grü�e Joerg
>
>
> Hallo Peter,
>
> mein Programm im Zielsystem ohne â??Debug Code erzeugenâ?? und ohne â??Array Index Grenzen überprüfenâ??
läuft nun seit 34h fehlerfrei.
>
> Das gleiche Programm mit â??Debug Code erzeugenâ?? und  â??Array Index Grenzen überprüfenâ??
> auf dem Projektboard läuft natürlich nicht ohne Probleme. Die schreib und lese Versuche
> auf dem I2C  erzeugen so viel Delay, das der Irq_GetCount(INT_TIM2COMP) nicht mehr
> unter 6 kommt. Es findet dann auch kein DCF Update mehr statt. Ich habe dann sämtliche I2C
> zugriffe entfernt. Nun läuft das Programm zwar, aber es treten keine Fehler mehr auf.
> Das Programm wird dir also nicht helfen.
>
> Für mich scheint das ganze ein Speicherproblem zu sein.
> Vermutlich wird der Stundenwert mit einer zu gro�en Zahl überschrieben und die Uhr
> springt nach 00:00:00. Das erklärt dann auch den Wechsel auf den nächsten Tag.
> Könnte das so sein?
>
> Vielleicht kannst du mir ja mal folgende Fragen beantworten:
> 1) Meine globalen Variablen liegen doch in der Reihenfolge im Speicher wie im MAP File angegeben oder?

ja

> 2) Wo liegt der Speicher meiner 12 Threads? Zusammenhängend davor oder danach? Reihenfolge?

Erst kommt der Interpreter, dann die globalen Variablen, danach für jeden Thread ein Block
mit arithmetischem und Programmstack.

> 3) Wo liegt der Stack des Hauptprogramms?

Am Ende des RAM Speichers.

> 4) Wo liegt der Speicher für die interne Uhr? Wer könnte diesen Speicher überschreiben?

Der liegt im Interpreter RAM, das ganz am Anfang ist. Das kann eigentlich
gar nicht überschrieben werden.


> 5) Kann man irgendwie an die Adressen der Variablen kommen?

Nein.

> 6) Verschiebt sich der Speicher der Variablen bei â??Debug Code erzeugenâ?? oder  â??Array Index Grenzen überprüfenâ???

Nein.

>
> Eine art Speicherabbild währe sehr hilfreich um den Fehler zu lokalisieren.
> Ich könnte dann mal Dummy Arrays einbringen oder Threads vergrö�ern.

12 Threads sind ziemlich viel. Wieviel Speicher hast Du jedem Thread gegeben?
Dir ist bewu�t, das Du für alle Threads und das Hauptprogramm ca. 2460 Bytes frei
hast?

Gruss Peter

>  
>
> Grü�e Joerg
>

    Antwort schreiben

Antworten:

Re: Zeitsprünge (von Joerg - 30.03.2012 20:26)
    Re: Zeitsprünge (von PeterS - 31.03.2012 9:21)
        Re: Zeitsprünge (von Joerg - 2.04.2012 8:41)
            Re: Zeitsprünge (von PeterS - 2.04.2012 11:50)