Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C Quellcode formatieren: <code>Quellcode</code> BASIC Quellcode formatieren: <basic>Quellcode</basic> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! -> I > > > > > 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. > 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? > > > Grüße Joerg >
