You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I used the example of extras/sntp and then, based on a timer that triggers every second, collect a time_t=time(NULL) when 60 triggers have passed
This should give a constant update of near 1 minute in reported time which is does...
HOWEVER, after a certain time (not always the same), the clock reports backwards by 7:44:50 (not always the same, but within a minute yes). It then continues going backward for an amount of time (not always the same*) and at that 'moment in the past' is starts reporting again 1 minute up until it goes back by 7:44:xx again and then gets back in gear
*) for one session (uninterrupted by a restart) the bad-run-time was 115 minutes twice, but another session it is much more.
Is this based on a bug? there seems to be some repeatable pattern so it suggests a code based issue.
Any help is appreciated,
relevant pieces of code below
EXTRA_COMPONENTS = extras/sntp
#define SNTP_SERVERS "0.pool.ntp.org", "1.pool.ntp.org", "2.pool.ntp.org", "3.pool.ntp.org"
void time_task(void *argv) {
while (sdk_wifi_station_get_connect_status() != STATION_GOT_IP) vTaskDelay(20);
const char *servers[] = {SNTP_SERVERS};
sntp_set_update_delay(24*60*60000); //SNTP will request an update every 24 hours
const struct timezone tz = {1*60, 0}; //Set GMT+1 zone, daylight savings off
sntp_initialize(&tz);
sntp_set_servers(servers, sizeof(servers) / sizeof(char*)); //Servers must be configured right after initialization
time_t ts;
do {ts = time(NULL);
if (ts == ((time_t)-1)) vTaskDelay(10);
} while (!(ts>1608567890)); //Mon Dec 21 17:24:50 CET 2020
printf("TIME: %ds %u=%s\n", ((unsigned int)ts)%86400, (unsigned int) ts, ctime(&ts));
vTaskDelete(NULL); //check if NTP keeps running without this task
}
void heater1(uint32_t seconds) {
time_t ts = time(NULL);
char timestring[26]; ctime_r(&ts,timestring); timestring[19]=0;
printf("Heater1 @ %d: S1avg=%2.4f S2avg=%2.4f %s", (seconds+10)/60, S1avg, S2avg, timestring+4\n);
}
TimerHandle_t xTimer;
void vTimerCallback( TimerHandle_t xTimer ) {
uint32_t seconds = ( uint32_t ) pvTimerGetTimerID( xTimer );
vTimerSetTimerID( xTimer, (void*)seconds+1); //136 year to loop
if (seconds%60==50) {
heater1(seconds);
}
}
user_init:
xTaskCreate(time_task,"Time", 512, NULL, 1, NULL);
xTimer=xTimerCreate( "Timer", 1000/portTICK_PERIOD_MS, pdTRUE, (void*)0, vTimerCallback);
and a few lines of the output
Heater1 @ 346: S1avg=21.8750 S2avg=20.4792 Dec 23 22:29:27
Heater1 @ 347: S1avg=21.8750 S2avg=20.4896 Dec 23 22:30:28
Heater1 @ 348: S1avg=21.8750 S2avg=20.4896 Dec 23 22:31:28
Heater1 @ 349: S1avg=21.8646 S2avg=20.5000 Dec 23 07:03:05 <=double skip
Heater1 @ 350: S1avg=21.8750 S2avg=20.5000 Dec 22 23:19:24
Heater1 @ 351: S1avg=21.8750 S2avg=20.4896 Dec 22 15:35:42
Heater1 @ 352: S1avg=21.8750 S2avg=20.4792 Dec 22 07:52:01
Heater1 @ 353: S1avg=21.8750 S2avg=20.4792 Dec 22 00:08:20
maybe a conflict in multiple places where time gets defined?
a friend also observed this kind of behaviour on an unrelated repository.
What they have in common is the use of CPU acceleration for specific activities. So for about 0.5 seconds at a time, the CPU goes to 160MHz and then back to 80MHz.
I switched to using extras/timekeeping which has a bit steeper learning curve, but performs perfect AFAIAConcerned
If others bump into this, we might find a root cause in extras/sntp and solve it...
I used the example of extras/sntp and then, based on a timer that triggers every second, collect a time_t=time(NULL) when 60 triggers have passed
This should give a constant update of near 1 minute in reported time which is does...
HOWEVER, after a certain time (not always the same), the clock reports backwards by 7:44:50 (not always the same, but within a minute yes). It then continues going backward for an amount of time (not always the same*) and at that 'moment in the past' is starts reporting again 1 minute up until it goes back by 7:44:xx again and then gets back in gear
*) for one session (uninterrupted by a restart) the bad-run-time was 115 minutes twice, but another session it is much more.
Is this based on a bug? there seems to be some repeatable pattern so it suggests a code based issue.
Any help is appreciated,
relevant pieces of code below
and a few lines of the output
maybe a conflict in multiple places where time gets defined?
The text was updated successfully, but these errors were encountered: