defragster
Senior Member+
T.MM on SFun_ML 35 minutes and all is well doing : 't' and "F" - the SSD1306 is still running as it should. - don;t have active Serial5 pins exposed on ML - so that is a NOP.
>> 1 hours 20 minutes and multiple uploads and T.MM on the HL carrier is fine and healthy ....
There is something wrong with my PJRC.BB (image in email) - not sure what that is soldered side F_headers - nothing cut?
The change to (60) fps update was just to see the updated callback count when the TFT was 'if (0)'
The uploaded Ex_2 had LAME prime _isr() busy work rates only using 0.05% of cpu cycles.
One part is the PrPS value was 1000 * 1, bumping that back to * 220 gives that many more interrupts:
That is a bit more load - but 'priRestart' is still a small number. Bumping that to '53680457' results in 57.3 load on the CPU cycles:
That dips the number of _isr()'s as finding some primes extends into the next timer _isr()
Playing with those two numbers can vary the load.
Bigger number holds the _isr even longer and now seeing so breaks in the continuous update - seems a single frame gets drawn out of sync ( one or more some seconds ) though it recovers.:
Fewer _isr's but display rate dropped:
Temp of 54C here is higher than before - it wasn't from that - not sure what is up with the breakoutBoard - it was fine for days - but what I was seeing there before is now fixed/HIDDEN with the Pri(102) updates to lib/src/.cpp
>> 1 hours 20 minutes and multiple uploads and T.MM on the HL carrier is fine and healthy ....
There is something wrong with my PJRC.BB (image in email) - not sure what that is soldered side F_headers - nothing cut?
The change to (60) fps update was just to see the updated callback count when the TFT was 'if (0)'
The uploaded Ex_2 had LAME prime _isr() busy work rates only using 0.05% of cpu cycles.
Code:
redraw rate = 10.55 Hz secs = 2421 deg C=55
LP#=20 Pri#=1001 last Pri=67537 ms=2422342 ipCyc%=0.05 deg C=54
Code:
const int PrPS=1000 * 220; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 65537 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
Code:
redraw rate = 9.71 Hz secs = 154 deg C=55
LP#=18 Pri#=220118 last Pri=505763 ms=155310 ipCyc%=16.28 deg C=54
That is a bit more load - but 'priRestart' is still a small number. Bumping that to '53680457' results in 57.3 load on the CPU cycles:
Code:
redraw rate = 7.58 Hz secs = 80 deg C=54
LP#=14 Pri#=142801 last Pri=53966057 ms=80746 ipCyc%=57.32 deg C=55
That dips the number of _isr()'s as finding some primes extends into the next timer _isr()
Playing with those two numbers can vary the load.
Bigger number holds the _isr even longer and now seeing so breaks in the continuous update - seems a single frame gets drawn out of sync ( one or more some seconds ) though it recovers.:
Code:
const int PrPS=1000 * 180; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
#define usPTimer 1000000.0/PrPS // intervalTimer us freq val
#define priRestart 107375183 // Larger Primes takes longer :: 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
Fewer _isr's but display rate dropped:
Code:
redraw rate = 6.82 Hz secs = 101 deg C=53
LP#=14 Pri#=110121 last Pri=107595413 ms=101267 ipCyc%=57.52 deg C=54
Temp of 54C here is higher than before - it wasn't from that - not sure what is up with the breakoutBoard - it was fine for days - but what I was seeing there before is now fixed/HIDDEN with the Pri(102) updates to lib/src/.cpp