Picaxe X2 SETTIMER CPU overhead

PhilHornby

Senior Member
In another thread, there was the following conversation :-
Me said:
Is there a recommendation, as to whether to go for one long tick, or lots of shorter ticks? (i.e. 1 x 0.1Sec vs 10 x 0.01Sec or even 100 x 0.001Sec)
hippy said:
I would say one long tick would be better. T1S_8 would interrupt your PICAXE program once for a one second interval. Why have 10, 100 or more interrupts to achieve the same thing ? There's overhead for every tick but more so for more frequent ticks, and the accuracy probably decreases with shorter ticks. If there is 1us lost per tick that's almost nothing over a one second period with one tick, but a full millisecond if you had a 1,000 ticks in the same period.
I was idly curious, as to the size of this overhead - so set about measuring it.

Initially, I used a simple 'Toggle B.1' in a loop, measuring the achieved frequency on a 'scope vs different values of TIMER Preload. The effect seemed highly non-linear - ranging from some 950Hz to about 86Hz. This was rather hard to log, so I changed to incrementing a variable instead. I then used the TIMER itself, to calculate how many incrementing loops were executed per second.

Of course, using the TIMER to highlight short-comings with the TIMER could be problematic! I added the Interrupt Routine to double-check that TIMER overflow wasn't occurring and also compared some of the results with my (un-log-able) frequency measurements. I'm fairly confident that the measured results are correct.

At the end of each loop, the program outputs the SETTIMER Preload used, along with the 'TIME taken' to perform a 1000 loops. This data was eventually loaded into Excel to produce charts.

Two formulas were used (presented here for review).

The length of the TIMER tick is given by: = ((65536-PRELOAD) * 32 / 1000000) [for an 8MHz 20X2]
The number of COUNTER incrementing loops per second is given by =(1000/(TIMER value * TIMER Tick Time)) [where TIMER value is the value of TIMER at loop end, and TIMER Tick Time is calculated above]

This is the code I used :-
Rich (BB code):
#Picaxe 20X2

symbol Counter = W27
symbol N = W26

      ;Gosub Interrupt_Enable - only used to verify TIMER OVERFLOW wasn't occurring

      for N = 65001 to 65531 step 2 ;VARIOUS VERSIONS WERE TRIED.
            Counter = 0
            TIMER = 0  
           
            settimer N
           
            do while Counter < 1000
                  inc Counter
            loop

            settimer OFF

            sertxd (cr,lf,#N,tab,#TIMER) ; Data for excel to process
      next N
      end

Interrupt:
      SerTxd( "Timer Overflow " )
      toggle B.1
Interrupt_Enable:
      timer = 0
      SetIntFlags $80, $80
      toFlag = 0
      Return
I discovered that you cannot use "0" as a SETTIMER Preload; it is interpreted as "OFF". I also discovered that values of 65532 or greater cause the Picaxe to lock-up. (Requiring a hardware RESET to load a new program).

I performed several runs, using different loop parameters to show the detail of what I found. At some values of PRELOAD, there is strange oscillation present. Initially I thought this was just integer arithmetic at play, but it's also there, to some degree, when using the Frequency-measuring method. I don't know what its significance is.

I present two graphs - the second being effectively, a zoomed-in version of the first. They are plots of "Counts per second" vs TIMER Preload. :-





From these results, it would seem unwise to use a counter Preload of <5mS on an 8MHz Picaxe 20X2 :cool:
 
Last edited:

hippy

Technical Support
Staff member
Of course, using the TIMER to highlight short-comings with the TIMER could be problematic!
Indeed, and I think your methodology may be faulty in using calculated values as if real time when they won't be. That might explain the sawtooth nature of the results you calculate.

The number of instructions executed per real second should depend on the number of ticks per real second; the more ticks there are the less of a real second there is within which to execute instructions.

There should be no cases where, as the number of ticks per second increases, the number of instructions executed per seconds also increases. That should always be decreasing.

I would analyse it how you started; toggle an output ever X loops, adjust the SETTIMER and see how that affects the toggle period time. It probably is non-linear as you noted, probably involves a 1/N or even a 1-1/N somewhere along the way. Frequency is also 1/t so that might make things even more difficult to analyse.

I suppose the bottom line I am arriving at is that meaningful results can only be had with reference to actual real time.
 

hippy

Technical Support
Staff member
This is the code I used to measure similar to what you are measuring -

Code:
#Picaxe 20X2
#Terminal 9600

Symbol preload = w0
Symbol counter = w1

Do
  Pause 2000
  SerTxd("Started",CR, LF )

  For preload = 65000 To 65531
    timer = 0

    SetTimer preload
    For counter = 1 To 1000 : Next
    SetTimer OFF

    SerTxd( #preload, TAB, #timer, CR, LF )
  Next
Loop
As expected the 'timer' value always increases as the 'preload' value increases. Sometimes there is no apparent increase because we are not showing the fractional part of 'timer' which is internal and inaccessible.

Results when using 'Step 50' for 'preload' were -

Code:
65000 42
65050 47
65100 52
65150 59
65200 68
65250 80
65300 98
65350 125
65400 172
65450 278
65500 716
That is as expected; with a specific 'preload', when the counter reaches a preset value the 'timer' counter will have increment by some amount.

That proves that with a higher 'preload' value there is a shorter tick length and the 'timer' increases more quickly. That's as expected.

The challenge is how to turn a full set of data into something meaningful or more readily comprehensible. I am not sure that can be done without some real time known for how long the 'counter' loop took.

In terms of overhead; that can also only be determined from a real time value. Whether the firmware overhead on each increment of 'timer' were 1us, 1ms or 1 second, that would be entirely internal and would not affect the results shown. The 'timer' will still have incremented by the same amount for a specific 'preload' value. Only in real time it would have take longer.

One can take the data and determine how many increments of 'counter' per 'timer' increment, but that's with reference to the timer, again, not real time.
 

inglewoodpete

Senior Member
@Phil - When you're using interrupts and sailing close to the wind, it is best to clear your flags (Eg TOFlag) early in the routine. The SetIntFlags command is not critical and can be done last.

If, for any reason, the execution of the Interrupt routine is held up or delayed, a second interrupt may be missed (ie the Flag is set and set again before it is cleared). This can happen if you have to passivate interrupts in your foreground code, to read and alter a variable that can also be altered within the interrupt routine (eg a timer-driven keypad handler) or if you have a blocking or slow command in your foreground code.

As an example, the SerTxd statement at the start of your Interrupt service routine above takes at least 15mS to execute before the ToFlag can be reset.

The "Interrupt Enable:" subroutine, as you have it embedded in the Interrupt routine, can look like a neat use of code but it can also be problematic. See the discussion here.
 

PhilHornby

Senior Member
Indeed, and I think your methodology may be faulty in using calculated values as if real time when they won't be. ... I suppose the bottom line I am arriving at is that meaningful results can only be had with reference to actual real time.

and...

The challenge is how to turn a full set of data into something meaningful or more readily comprehensible. I am not sure that can be done without some real time known for how long the 'counter' loop took.
In terms of overhead; that can also only be determined from a real time value...One can take the data and determine how many increments of 'counter' per 'timer' increment, but that's with reference to the timer, again, not real time.
I don't think I'm measuring that which I am actually interested in :confused:

Regardless of variations of starting TIMER and PRELOAD value, the timer will eventually overflow (and optionally trigger an interrupt) just once. What I really want to know, is the effect of having the Timer running in the background at different rates i.e. when it's not supposed to be influencing the user code execution.

I tried another experiment - using actual real-time values ... but I think it is still measuring the same thing :(

This time, the interrupt is brought into play to find out how many loop iterations where achieved during the Timer period. I introduced a switch to control proceedings and generated some pulses to display on my 'scope. I used the scope's Measuring System to obtain the (actual) timer value. One of the thing I think this demonstrated, is that the Timer is remarkably accurate. The overhead of generating the pulses and invoking the interrupt seemed to be a consistent 1.6mS ... and of course, that also influenced the calculations. As the Timer period lengthens, the scope's measuring resolution drops, and the overhead is no longer significant anyway. Conversely, at short timer periods, the overhead becomes more and more important.

Rich (BB code):
#Picaxe 20X2

symbol Counter = W27
symbol PRELOADRAM = W26

symbol PRELOAD    = 64286; start @ 40mS
symbol TICKS      = 65535; 1 tick
symbol INCREMENT  = 1250 ;(40mS)


      pause 1000
      ;
      ; RUN 0 command brings us back here, when button pressed.
      ;
      if PRELOADRAM = 0 then
            PRELOADRAM = PRELOAD
      else
            PRELOADRAM = PRELOADRAM - INCREMENT
      endif

      Counter = 0

      High B.0                            ;LED ON
      low B.1                             ;DEBUG OFF
     
      sertxd(cr,lf,"PRELOAD=",#PRELOADRAM,", TICKS=",#TICKS)

      do : loop while PinB.2 = 1          ;wait for switch press before starting.

      SetIntFlags %10000000,%10000000     ;Timer Overflow Interrupt enable

      TIMER = TICKS
           
      low B.0                             ;LED OFF + 1st debug pulse
      SETTIMER PRELOADRAM
      do
            inc Counter
      loop
Interrupt:
      High B.1                            ;2nd debug pulse
      High B.0                            ;Led on
      SerTxd( ", COUNTER=",#Counter)
      pause 125                           ;debounce switch
      do : loop while PinB.2 = 1          ;wait for press
      low B.0 : low B.1                   ;LEDs off
     
      settimer off                        ;stop timer
      TOFLAG = 0                          ;survives RUN 0!
      run 0                               ;quick way out of Interrupt state
      
One thing I noticed, is that although the shortest functioning PRELOAD value (65531) equates to 160µS, the actual timer period is approx. 8mS (or 6.4mS discounting the overhead in measuring it!). Therefore, there seems little point in using a PRELOAD of less than 65286 which actually is 8mS (at least, when using a single Major tick.)

I took measurements all the way from the maximum (approx. 2.1S) to 40mS, at 40mS intervals :-
The RED trace, calculated using real (measured) time, shows that same characteristic 'droop', as before. However, using the calculated value, corrects the (blue) trace considerably! (Cause of the weird up-turn at the end is unknown!)

20X2 Timer 3.jpg

Zooming into the timer period from 40mS to 8mS, the effect of real vs calculated time, shows the same effect - I think this purely the measurement overhead, compared to the timer duration.

20X2 Timer 4.jpg

I tried going back to my original method, of toggling a pin and measuring its frequency. One thing that became obvious, is that at certain Timer intervals, it is not stable! The frequency does change, but tends to jump around between several values for a few seconds each. This makes it very hard to log...

What I thought I would do next, is use the 'loop counting' method, but run over a fixed time period, while using different values of Timer PRELOAD (but with no Timer interrupt or overflows occuring. I should be able to send a consistent clock signal from a second Picaxe, to interrupt the first and print the loop count.
 
Last edited:

hippy

Technical Support
Staff member
What I really want to know, is the effect of having the Timer running in the background at different rates i.e. when it's not supposed to be influencing the user code execution.
I would start with an analogy. Your sitting in the front room reading a book. Every time an egg timer goes off in the kitchen you walk to the kitchen, reset the egg timer, come back and continue reading.

Over a period of say an hour you will have read say 60 pages of a book.

If you set the egg timer to half the time it was, the alarm will go off twice as frequently, you'll make twice as many trips to the kitchen, have less time to read your book. At the end of the hour you will have read less than 60 pages.

Halve the timer again and you'll have even less time to read the book, will have read even less in an hour.

At some point the timer will be going off so frequently that you hardly have time to read a single word before you are back in the kitchen resetting the timer. And at some point it will be going off before you are even back to the book and your book reading will have ground to a halt.

In PICAXE terms; reading the book is the PICAXE firmware executing your Basic commands. The walk to the kitchen is the firmware being diverted to handle the timer tick, reset the timer, increment the 'timer' variable and flagging a call needed to your 'interrupt:' routine if 'timer' overflows to zero.

So we know, in general terms, the shorter the tick interval, the more often the firmware has to handle ticks so the less is available for Basic command execution during any period of time. High preload values, more frequent ticks, have more impact than lower preload values, less frequent ticks.

So that answers the original question, which is best; few longer interval ticks are better than more frequent shorter interval ticks. The lower the preload value, the longer the tick interval, the more of any time period is available for executing Basic commands.

Quantifying exactly what impact there actually is requires knowing how much time is spent executing Basic commands during a real time period, or how many Basic commands were executed in that particular time.

That can also be calculated from knowing how long it took to execute a fixed number of commands.

And that can also be determined by measuring the frequency of an event which happens every time those fixed number of commands completes.

In terms of commands per second versus timer tick it should be as your graph shows; an inverse exponential decay. It starts high, slowly decreases then takes an ever rapidly increasing downward turn.

That also maps to our book reading analogy earlier. The final dive is down to zero commands per second, where the timer is going off so frequently that all the time is dedicated to the timer and there is no time to read the book or execute Basic commands.

Apart from curiosity and wanting to put numbers on things I am not sure how useful doing that is. We already know to use the longest time interval possible, and if one uses shorter intervals that will impact on the number of commands being executed per second. How far one can go before the impact is considered debilitating may have some usefulness but the proverbial doctor's reply of "well don't do that!" would seem to apply to most cases I can think of. Don't use short timer intervals unless you have to, and if you do then there will be consequences. Whether debilitating or not would depend on what's required and being done.

What intrigues me most is that you are not getting a continuous line for number of commands per second; that saw-toothing and rippling should not happen. To me that points to some error or issue creeping in somewhere. What you have 'looks right' but not to me entirely right.
 

PhilHornby

Senior Member
I would start with an analogy.
I understand and agree with your analogy.

him as well said:
Apart from curiosity and wanting to put numbers on things I am not sure how useful doing that is.
Pure inquisitiveness :D

I wondered if, because the PIC machine-code instructions are executing so much faster than the Picaxe Basic, there would be any difference between the two extremes. I believe that my current method of measuring this is having a large impact on the results, at the moment.

What intrigues me most is that you are not getting a continuous line for number of commands per second; that saw-toothing and rippling should not happen. To me that points to some error or issue creeping in somewhere.
My guess is that it's some background code running - but it seems to be at quite a slow interval, so can't be something like a check for TIMER overflow. I think this is the effect I see with the simple Toggle Pin approach; i.e. the Frequency jumps around, before my very eyes :confused:.
 

hippy

Technical Support
Staff member
I have taken a slightly different approach to yourself. I run a loop which increments a counter for a half second and reports the count achieved depending on timer preload value. I used a half second because that allowed a percentage to be more easily calculated. That half second is generated by another PICAXE-18M2.

Code:
#Picaxe 20X2
#Terminal 9600

Symbol IN_PIN  = pinC.0

Symbol preload   = w0
Symbol counter   = w1
Symbol reference = w2
Symbol percent   = w3

Do
  Pause 2000
  SerTxd("Started",CR, LF )
  reference = 0

  For preload = 65331 To 65531 Step 5
    timer = 0
    counter = 0

    SetTimer preload
    Do : Loop Until IN_PIN = 1
    Do : Loop Until IN_PIN = 0
    Do : Loop Until IN_PIN = 1
    Do
      counter = counter + 1
    Loop Until IN_PIN = 0
    SetTimer OFF

    If reference = 0 Then
      reference = counter
    End If
    
    percent = counter * 100 / reference

    SerTxd( #preload, TAB, #counter, TAB, #percent, "%", CR, LF )
  Next
Loop
The results are; preload, counts per half second, percentage of first reading -

Code:
65331 566   100%
65336 565   99%
65341 565   99%
65346 564   99%
65351 564   99%
65356 563   99%
65361 562   99%
65366 561   99%
65371 560   98%
65376 560   98%
65381 559   98%
65386 558   98%
65391 557   98%
65396 556   98%
65401 555   98%
65406 553   97%
65411 552   97%
65416 551   97%
65421 549   96%
65426 547   96%
65431 545   96%
65436 543   95%
65441 541   95%
65446 538   95%
65451 535   94%
65456 532   93%
65461 529   93%
65466 525   92%
65471 520   91%
65476 515   90%
65481 509   89%
65486 501   88%
65491 492   86%
65496 481   84%
65501 467   82%
65506 449   79%
65511 425   75%
65516 390   68%
65521 338   59%
65526 247   43%
65531 53    9%
Code:
65501 463   100%
65502 461   99%
65503 457   98%
65504 454   98%
65505 450   97%
65506 447   96%
65507 442   95%
65508 438   94%
65509 433   93%
65510 427   92%
65511 422   91%
65512 416   89%
65513 410   88%
65514 403   87%
65515 396   85%
65516 388   83%
65517 380   82%
65518 370   79%
65519 360   77%
65520 348   75%
65521 335   72%
65522 321   69%
65523 306   66%
65524 288   62%
65525 268   57%
65526 245   52%
65527 218   47%
65528 187   40%
65529 151   32%
65530 106   22%
65531 53    11%
That matches with what I would expect and the count per half second never increases though there may well be some 'off by one' sometimes where it has started another count just as the pulse ends.

The counts do seem to vary in each. I would guess that's down to the variability of clock in both the 20X2 and 18M2.
 

hippy

Technical Support
Staff member
I seem to get around 580 count increments without the SETTIMER enabled, and looking at the results, it would be about 90% of that right the way down to having a timer interval of about 2ms, would be getting 50% of that at 0.5ms.

From that 50% at 0.5ms one could probably calculate what amount of overhead there were per tick but that escapes me for now.
 

PhilHornby

Senior Member
I have taken a slightly different approach to yourself. I run a loop which increments a counter for a half second and reports the count achieved depending on timer preload value. I used a half second because that allowed a percentage to be more easily calculated. That half second is generated by another PICAXE-18M2.
Your data in graphical form (a picture's worth 1024 words :p )

20X2 Timer 5.jpg

The graph is resolutely refusing to change shape :)

At least with this method of measurement, it reveals that the Timer overhead doesn't actually start to get significant until the interval is getting down to very small numbers (compared to the Picaxe instruction time).
 

inglewoodpete

Senior Member
From another angle...

I used the following code to allow me to capture the interrupt service time proportions for a 100mS vs a 5mS Timer interrupt.
Rich (BB code):
#PICAXE 28X2
#No_Table
Symbol mskBGTimer    = %10000000 'For the background timer (only) interrupt
Symbol flgBGTimer    = %10000000 'For the background timer (only) interrupt
Symbol tmrIntOn1stTick = 65535   'Interrupt to be caused by roll over on first major tick
Symbol c100mS_8      = 62411     'SetTimer value for 1/10 second ticks
Symbol c5mS_8        = 65380     'SetTimer value for 1/200 second ticks
Symbol False         = 0
Symbol True          = 1
'
SerTxd("Booted", CR, LF)
'Start the background timer (runs continuously)
Timer = tmrIntOn1stTick
SetTimer c5mS_8
TOFlag = False                         'Reset serial reception flag
SetIntFlags flgBGTimer, mskBGTimer     'Set timer 0 to interrupt
'
Do
   Low B.3
Loop
'
Interrupt:  High B.3
            If TOFlag = True then
               TOFlag = False                      'Reset (clear) the flag first
               Inc w10                             'A token bit of work
               '
               Timer = tmrIntOn1stTick             'Then reset the timer
             EndIf    'Timer has ticked
             SetIntFlags flgBGTimer, mskBGTimer    'Set timer 0 to interrupt
             Return
You will see that about half of the 5mS timer period is taken servicing the timer interrupt. It doesn't leave much time to handle any foreground tasks!

100mS Timer Interrupt.JPG5mS Timer Interrupt.JPG
 
Last edited:

PhilHornby

Senior Member
I couldn't understand how you were successfully triggering a 5mS Timer Interrupt - so I did a little more playing.

Recall that a TIMER PRELOAD of 65531 (the highest value that works without locking up the Picaxe) - is supposed to give 160µS, but actually gives >8mS ...

I re-ran one of my test programs - for the shortest 27 intervals and plotted the results. These are PRELOAD values 65505 (s/be ~1mS) -> 65531 (as above). I think the Timer is probably working fine, but the Picaxe interpreter has run out of steam.

20X2 Timer 6.jpg
The most noticeable thing about this graph, is that it slopes in the wrong direction - the times are supposed to be getting shorter, as the PRELOAD increases, but actually get longer. (It's the inverted version of the previous charts). It starts with the ~1mS Timer interrupts taking ~2.6mS to get delivered (probably as expected) ... and goes downhill from there. (Actually, it goes uphill, but you know what I mean!)

The green trace, is the time that it takes the Interrupt Service Routine to execute the next statement (and turn on the LED) and that does the same thing.

One final test (maybe) ... I compared the effects of using one long time interval, vs lots of shorter ones to achieve the same overall result :-

PreloadMajor Tick
(TIMER)
Minor tick lengthMajor ticksCalculated Time IntervalMeasured Time IntervalNo. of 'loops' achieved by Picaxe code during that time.
65380654364.992mS100499.2mS511.6mS755
639746552649.984mS10498.84501.0mS774
4991165535500mS1500.0mS500.1mS777

The inescapable conclusion - which Hippy said two pages and two threads ago :eek: - is go for the longest Minor Interval possible. It has lowest overhead on the running program and managed the closest time to its target, for good measure.
 

inglewoodpete

Senior Member
I couldn't understand how you were successfully triggering a 5mS Timer Interrupt - so I did a little more playing.
There was no real science involved in my selection of 5mS, just an educated guess that there should be enough time to execute a 5mS interrupt. The entire experiment took about 20 minutes and I only did the test because I had a 28X2-based lighting controller on the bench. (It is now back in service as an RGB lighting controller for the client.)

I have to admit that I have not tried to fully understand your algorithm. It seems more academic than useful for me. The apparent additional overheads that you are getting with shorter periods suggest that there is something amiss with your algorithm. Note that my 5mS test produced a square wave pretty damn close to 200Hz!

The inescapable conclusion - which Hippy said two pages and two threads ago :eek: - is go for the longest Minor Interval possible. It has lowest overhead on the running program and managed the closest time to its target, for good measure.
I rarely build a PICAXE project without a background timer - so handy. Usually, the shortest timer period is 100mS (I have used 80mS), often for debouncing keypad presses. If I need smaller intervals I move to MPLAB and a raw PIC but I have to have a good reason to do it. PICAXE timer interrupts may have a Timer overhead but MPLAB/PIC programming has a much larger development overhead.:):)
 

hippy

Technical Support
Staff member
The most noticeable thing about this graph, is that it slopes in the wrong direction - the times are supposed to be getting shorter, as the PRELOAD increases, but actually get longer.
That increase seems to be correct to me. As the preload value increases, the tick period gets shorter, the tick handler gets used more often, you spend more time handling the timer, the less time to execute the Basic Commands, or, as in the analogy, less time to read your book, so the longer it takes to read the book.

Your green seems to be the amount of time to read the book, your red the time taken to handle the timer, though I may have read that wrong. Part of the problem is mapping how you are terming things to how I would.
 

PhilHornby

Senior Member
Part of the problem is mapping how you are terming things to how I would.
I'd better explain then...
#Picaxe 20X2

symbol Counter = W27
symbol PRELOADRAM = W26

pause 1000
;
; RUN 0 command brings us back here, when button pressed.
;
if PRELOADRAM = 0 then
PRELOADRAM = 65505 ; start @ 0.992 (1mS)
else
PRELOADRAM=PRELOADRAM+1 max 65531 ; picaxe hangs @ 65531
endif

Counter = 0

High B.0 ,b.1 ;LED ON + ;DEBUG ON
;high B.1 ;timing same as above

sertxd(cr,lf,"PRELOAD=",#PRELOADRAM)
do
: loop while PinB.2 = 1 ;wait for switch press before starting.

SetIntFlags %10000000,%10000000 ;Timer Overflow Interrupt enable

TIMER = 65535

low B.0 ;LED OFF
low B.1 ;DEBUG POINT (A)

SETTIMER PRELOADRAM
do
inc Counter
loop

Interrupt:
High B.1 ;DEBUG POINT (B)
High B.0 ;DEBUG POINT (C) Led on
SerTxd( ", COUNTER=",#Counter)
low B.0
;LED off
pause 125 ;debounce switch (unnecessary now)
;do : loop while PinB.2 = 1 ;wait for press

settimer off ;stop timer
TOFLAG = 0 ;could survive RUN 0

run 0 ;quick way out of Interrupt state



The program effectively runs once per TIMER PRELOAD under test. This means that the 'Tick Handler' doesn't get used more often, as the PRELOAD value changes - it too is invoked &#8203;just once.​

The Y axis of the graph, is the time that elapsed between DEBUG POINT (A) and DEBUG POINT (B). The red bars show what the Timer interval should be according to the agreed formula, plotted against what it is actually is (as measured by my 'scope). The green bars show the time taken between DEBUG POINT (B) and DEBUG POINT (C) - a single Picaxe statement, that simply sets a 2nd Pin high. The X axis doesn't apply in this case - each green bar should be the same size. By stacking them on top of the red bars, the graph shows the total measured time from DEBUG POINT (A) to DEBUG POINT (C).

The shape of the graph is probably expected, in that it is the same shape as the graphed data from all the previous experiments (albeit inverted).

Most of the values tested, would be totally impractical when combined with a single MAJOR tick, as they are shorter than the Picaxe's instruction time.

JUST TO ADD ...

What this test shows, is that the background overhead of the Picaxe firmware increases in ABSOLUTE terms, as the TIMER PRELOAD is shortened. (At a value of 65532 it is overwhelming and the Picaxe stops functioning altogether)​
 
Last edited:

hippy

Technical Support
Staff member
The green bars show the time taken between DEBUG POINT (B) and DEBUG POINT (C) - a single Picaxe statement, that simply sets a 2nd Pin high.

each green bar should be the same size.
I don't think so. When you enter the interrupt routine the timer is still ticking. Time is taken away from executing Basic statements within the interrupt through servicing those ticks, just as time is taken away from the main counter part of the program. So B to C will take longer with higher tick rates, higher preload values.

If you move the SETTIMER OFF to before B then I would expect the B to C period to become constant and consistent.
 

hippy

Technical Support
Staff member
looking at what you are measuring it seems to be you are measuring how long it takes to make 'timer' overflow and noting by how much a counter has increased before that time.

We already know the 'timer' variable will overflow quicker with a faster tick rate, higher preload values; that's by design and intent.

The count will therefore reflect that shorter time period and it will also be affected by how much tick handling occurs while executing before 'timer' overflows.

That just seems a more esoteric and convoluted way of measuring impact than just checking how many counts one gets during a fixed period of time with various preload values.

Like inglewoodpete it seems too academic for me. I am not sure what you are attempting to illustrate beyond what we already know. I am having difficulty comprehending how what you are doing amounts to anything I can get my head round. I accept that may be my failing
 

hippy

Technical Support
Staff member
What about this approach - Set a pin high for 1 second, measure how long it is high for at different preload values. As the impact of faster ticks hits the real time will extend. That can even be observed visually.

Code:
#Picaxe 20X2

#Macro Test(preload)
  High C.0
  SetTimer preload
  Pause 1000
  SetTimer Off
  Low C.0
  Pause 2000
#EndMacro

Do
  Test(0)
  Test(65531)
  Test(65331)  
Loop
That allows the impact of various preload values to be determined.
 

PhilHornby

Senior Member
looking at what you are measuring it seems to be you are measuring how long it takes to make 'timer' overflow and noting by how much a counter has increased before that time.
No, the 'counter' code was a left-over from experiment #1. It wasn't logged or graphed in this case.

him as well said:
That just seems a more esoteric and convoluted way of measuring impact than just checking how many counts one gets during a fixed period of time with various preload values.
No, 'counts' don't come into it. I was measuring real, elapsed time, vs expected, computed time.


(These posts have got a bit entangled, timewise!)
 
Top