C-Control Pro

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 Joerg - 30.03.2012 20:26)
Als Antwort auf Re: Zeitsprünge von PeterS - 30.03.2012 14:11
> > > > > > > > > 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? 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? 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. Erstmal schönes Wochenende Grü�?e Joerg
Antwort schreiben Antworten: 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)