TEST, program compiled with CPU Speed: 396MHz, Optimize: Faster
Test used the very same program as yesterday afternoon (v149 w/o OLED affecting subs)
Summary, there have been now Freezes of 2033ms duration (at CPU 600MHz they were ~1786ms), located at several new positions
In detail:
Test Start: 16:49
19:53 First Freeze, inside a successful check, if a client had connected. The connection was detected within 10us. The short info, sent by another Arduino Due, simply requested some information. The process was successfully done, then client.close() and client,stop() executed. There are several while(!client.available()) inside this routine, but there has been no further time stamps inside this routine to pin-point the exact loaction.
I assume this Freeze is similar to those observed earlier in the testing sequence, although they appeared when the routine connected as a client to another server.
20:47, Second Freeze, between Zeit[6] and Zeit[7], inside subroutine „processWaterValveControl()” – the first time I saw a Freeze at this location. This routine calls several other routines, which are all unchanged from their successful use inside an Arduino Mega2560. Some of these routines use time comparisons with millis(), some use additionally short delay() s. However, this whole sequence of routines would only run for more than 1ms (but well below 2033ms) if there was a request by a user controlled switch, which wasn’t here the case. There was also no printing to USBSerial from any of these routines during this Freeze. I can easily remove this whole bunch of routines for further tests.
13 Loop() later, the Third Freeze, again at a different (never seen before) location, between Zeit[0] and Zeit[1]. During this time setToogleBits() is running, a routine which reads minute() and hour() of library <TimeLib.h>, and checks if a minute or hour have passed. There is neither a use of millis(), micros() or USBSerial inside my code, but I assume within TimeLib.h
13 Loop() later – again – the Fourth Freeze, during the time a check was done, if a client had connected – just as Freeze 1 above, BUT this time no client was detected, therefore no while was executed inside my code. However, some of these requests, which were executed, might still do this:
Code:
Ethernet.setRetransmissionCount(2)
Ethernet.setRetransmissionTimeout(50);
EthernetClient client = server.available();
client.setConnectionTimeout(100);
22:22, Fifth Freeze, between Zeit[33] and Zeit[34], this time inside poll_Switches_and_Hell(false), the routine, which has at present still analogRead replaced by digitalReadFast The Freeze happened between ZeitStopE and ZeitStop, see:
Code:
ZeitStopE=millis();
if(micros()-t1>100) {Serial.print("dt_us>100(Inputs):"); Serial.println(micros()-t1);}
ZeitStop=millis();
11 Loop() later – Freeze Six: identical to Freeze 3, above.
13 Loop() later, Freeze Seven: again a new one, this time between Zeit[5] and Zeit[6], inside checkTimedActions(showTimerControl), a routine which makes heavy use of millis(). In addition micros() are read at the start and the end of this routine, reporting a correct delay of 2033386us, whilst Zeit[6]-Zeit[5] = 2033ms report
00:00 Freeze 8: inside check for client, as Freeze 1 = client check
7:32 Freeze 9, identical to Freeze 1 = client check
7:45 Freeze 10, identical to Freeze 1 = client check
TestStop 9:46
SUMMARY:
The length of a Freeze is constant but depends obviously on CPU Speed. Somehow, everything seems to point to internal time keeping, be it micros(), millis(), elapsedMillis(), elapsedMicros(). Of course, I have used millis() and very rarely micros() in my code, at positions Freezes occur, but other Freezes show refernces to libraries, which also might use millis() at such points.
During above reported Freezes, only the Timer ISR (30ms) was active, the external Interrupt had not been called.
Whilst I do not rule out, that those Freezes are caused by my user code, I am becoming doubtful that this is the true case, seeing now Freeze Time dependent on CPU Speed.
My next step:
I will now run a further test with the identical program, but compiled with CPU Speed: 600MHz and now with
Optimze: Debug. Furthermore I will prepare another test, which will use a program which has
(1) removed all user requests to micros()
(2) replaced my two ISRs with simple polling inside Loop().
running the test over night resulted in 8 Freezes of 1789ms, just as before - I shortly will list their exact locations. However, we can say, removing micros() from user code had no effect.