| Re: Zeitsprünge Kategorie: IDE (von PeterS - 31.03.2012 9:21) | |
|
Als Antwort auf Re: Zeitsprünge von Joerg - 30.03.2012 20:26
| |
|
> > > > > > > > > > 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 > > > > > Hallo Peter, > > erstmal vielen Dank für die Info. > > Das mit dem Speicher habe ich eigentlich überall mit > Thread_MemFree() überprüft. Natürlich kann man das nicht immer > bis in die unterste Ebene überprüfen. Ich habe aber einiges > an Reserve > > Meine Thread Konfiguration ist: > > #thread MAIN_THREAD, 0, 20 > #thread R_GROUP_1, 64, 2 > #thread R_GROUP_2, 64, 2 > #thread R_GROUP_3, 64, 2 > #thread R_GROUP_4, 64, 2 > #thread R_GROUP_5, 64, 2 > #thread R_GROUP_6, 64, 2 > #thread R_GROUP_MARKISE, 64, 2 > #thread R_GROUP_ALL, 80, 2 > #thread R_SWITCH_CONTROL, 128, 2 > #thread DOOR_CONTROL, 128, 2 > #thread ALARM_CONTROL, 128, 2 > #thread ENVIRONMENT_CONTROL, 128, 2 > > Das sind Ausgaben nach dem Starten: > > Thread Control 1is started! Mem Free = 58 > Thread Control 2is started! Mem Free = 58 > Thread Control 3is started! Mem Free = 58 > Thread Control 4is started! Mem Free = 58 > Thread Control 5is started! Mem Free = 58 > Thread Control 6is started! Mem Free = 58 > Thread Control 7is started! Mem Free = 58 > Thread Control All is started! Mem Free = 73 > Thread Switch Control is started! Mem Free = 119 > Thread Door Control is started! Mem Free = 121 > Thread Alarm Control is started! Mem Free = 121 > Thread Environment C is started! Mem Free = 88 > Main Mem Free = 1279 > > > Das der Thread einen arithmetischem und Programmstack hat, > war mir nicht bewuÃ?t. Was gebe ich den bei #thread an? > Die Summe aus beiden? Ja, bei #thread wird die Gesamtzahl angegeben. Mit dem Arithmetik Stack wird eine Stackmachine realisiert. Dies ist normalerweise unkritisch, es sei denn man baut sich z.B. was tail-rekursives. > > Der letzte Thread ist neu. Vorher lief das Programm > ca. 1 Jahr ohne Probleme. Der Thread Environment > führt auch Float operationen durch. Könnte das mit dem > arithmetischem Stack ein Problem sein? Die Einheit auf dem Arithmetik Stack ist immer 4 Bytes, egal ob man floats oder bytes berechnet, dies ist aus Effizienzgründen so. > > Ich programmiere beruflich seit 20 Jahren Signalprocessoren. > Ich hatte schon etliche Probleme mit Speicherüberschreitungen. > Wir mach zur Ã?berwachung des Speichers manchmal folgendes: > Die Speicher werden mit unterschiedlichen Mustern vorbelegt. > Ein Interrupt kontrolliert cyclisch diese Werte und gibt > Fehler raus, wenn gewisse Grenzen überschritten werden. > Vielleicht könnte man das Ende des Threadstacks auch so > überwachen. Es gibt Ã?berwachungsfunktionen, die dies eigentlich melden, wenn man zuviel Speicher benötigt. Du kannst aus SpaÃ? ja mal eine minimale rekursive Funktion aufrufen, das sollte direkt erkannt werden. > > > Erstmal schönes Wochenende Dir auch! Gruss Peter > > GrüÃ?e Joerg | |
Antwort schreiben Antworten:  Re: Zeitsprünge (von Joerg - 2.04.2012 8:41)Re: Zeitsprünge (von PeterS - 2.04.2012 11:50) | |
Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum