TIME and Timer1 on M2s

[cpedw]

I have read several posts about Timer1 and TIME. I understand that Timer1 rolls over every 20mS at 4MHz and is used to update TIME every second. So there must be a counter somewhere to count the 50 x 20mS rollovers. Is that counter accessible?

My application is an update of an old project using a 14M2. The latest version offers a choice of 5 day (hourly interval) or 1 day(12 mins interval) display. To achieve that, I have used the TIME variable to make a reading every 12 minutes. Running at 32MHz has improved the display; it redraws much more quickly. However, that means a fairly high current consumption (~ 3mA) even when nothing but timing is happening. Running at 31kHz while not measuring or drawing has reduced current well below 1mA which is good but, if the user changes the display interval then a redraw of the screen is needed and if the processor speed isn't increased, that takes around half an hour at 31kHz!

Currently, timing is achieved by waiting for 80s real time to pass at 32MHz (change of TIME of 160) followed by 640s at 31kHz (change of TIME of 5). The measurement and display are readily completed during the first 80s but I can't readily reduce that while TIME has only 128s resolution at 31kHz. I could avoid waiting 80s and handle the problem of redrawing during the "slow phase": increasing speed, redrawing and timing at mixed speeds, if I can access the Timer1 rollover counter.

I appreciate that the TIME clock is not chronometer accuracy but it's good enough for this application.

Incidentally, does Timer1 keep step with TIME at different frequencies or is it proportional to the SETFREQ speed? Only an issue around 4/8/16/32MHz.

Derek

 

[hippy]

The internal count of the Timer1 rollovers is internal to the firmware and cannot be accessed from the user program.

By watching the raw Timer1 value with PEEKSFR it might well be possible to tell when it has rolled-over and keep your own counter tracking that.

The 'time' variable increments at 1 second intervals at 4MHz and 16MHz, is proportional for other frequencies. Details at the link below -

http://www.picaxe.com/BASIC-Commands/Time-Delays/time

 

[GY44]

Bit 0 of PIR1 gets set when Timer1 overflows (pic16F1823) . It should be possible to do a PEEKFSR on PIR1. PIR1 is in Bank0.
Regards.
GY44

 

[AllyCat]

Hi,

Bit 0 of PIR1 gets set when Timer1 overflows (pic16F1823) . It should be possible to do a PEEKFSR on PIR1. PIR1 is in Bank0.

Isn't that flag reset by the PICaxe operating system (when effectively pre-loading T1 with 45536 for a 20 ms period), interrupt driven long before a PEEKSFR $11 will be able to read it? Also, a DISABLETIME is unlikely to help, because the timer may be still required for servo pulse generation (whether servos are in use or not).

I have always assumed that it would be necessary to continually poll the TMR1H ($17) register and look for a sudden fall in its value.

Cheers, Alan.

 

[hippy]

Isn't that flag reset by the PICaxe operating system (when effectively pre-loading T1 with 45536 for a 20 ms period), interrupt driven long before a PEEKSFR $11 will be able to read it?

That is correct. As soon as the roll-over occurs it sets the interrupt flag, the M2 firmware sees that, clears it.

Also, a DISABLETIME is unlikely to help, because the timer may be still required for servo pulse generation (whether servos are in use or not).

I can't recall if servos are disallowed with DISABLETIME, but I recall it has been shown that firmware will still intercept every Timer 1 roll-over interrupt. I don't know if anyone has tried disabling that interrupt.

I have always assumed that it would be necessary to continually poll the TMR1H ($17) register and look for a sudden fall in its value.

That was my assumption. Though when I did a quick test of polling TMR1H I saw some $00 values which notionally aren't possible with an M2. I haven't investigated further.

 

[hippy]

An alternative to trying to use Timer 1 on an M2 which the firmware will interact with, which makes it difficult to control or predict, may be to use Timer 2 ( 4 and 6 not accessible ).

Timer 2 is only 8-bit but has a presettable value, divide by 4, 16, 64 pre-scaler, a divide by up to 16 post-scaler, which should allow useful period lengths. This below works for K31 counting four second periods reasonably accurately.

#Picaxe 18M2
#Terminal 4800
#No_Data

Symbol PIR1             = $11   ' $011
Symbol TMR2             = $1A   ; $01A
Symbol PR2              = $1B   ; $01B
Symbol T2CON            = $1C   ; $01C

; PIR1

Symbol TMR1IF_BIT               = bit0
Symbol TMR2IF_BIT               = bit1
Symbol CCP1IF_BIT               = bit2
Symbol SSPIF_BIT                = bit3
Symbol TXIF_BIT                 = bit4
Symbol RCIF_BIT                 = bit5
Symbol ADIF_BIT                 = bit6
Symbol TMR1GIF_BIT              = bit7

; T2CON

Symbol T2CKPS0_BIT              = bit0
Symbol T2CKPS1_BIT              = bit1
Symbol TMR2ON_BIT               = bit2
Symbol T2OUTPS0_BIT             = bit3
Symbol T2OUTPS1_BIT             = bit4
Symbol T2OUTPS2_BIT             = bit5
Symbol T2OUTPS3_BIT             = bit6

Symbol reserveW0 = w0 ; b1:b0
Symbol reserveW1 = w1 ; b1:b0
Symbol ms        = w2 ; b5:b4
Symbol secs      = w3 ; b7:b6

Init:
  DisableTime

  PokeSfr PR2, 250

  T2CKPS0_BIT  = 0
  T2CKPS1_BIT  = 0
  TMR2ON_BIT   = 1 
  T2OUTPS0_BIT = 0
  T2OUTPS1_BIT = 0
  T2OUTPS2_BIT = 1
  T2OUTPS3_BIT = 0
  PokeSfr T2CON, b0

MainLoop:
  Do
    SetFreq K31
    Do
      PeekSfr PIR1, b0
    Loop Until TMR2IF_BIT = 1
    TMR2IF_BIT = 0
    PokeSfr PIR1, b0
    ms = ms + 400 // 4000
    If ms = 0 Then
      secs = secs + 4
      SetFreq MDEFAULT
      SerTxd( #secs, CR, LF )
    End If
  Loop

The K62 version is better, K125 possibly better still, so I am guessing there is some interaction at K31. None the less it should be good enough for timing 60 or 12 minute intervals ...

      secs = secs + 4 // interval
      If secs = 0 Then
        Gosub UpdateDisplay
      End If

Just set "interval=3600" for 60 minutes, "interval = 720" for 12 minutes.

 

[AllyCat]

Hi,

Ah, I've never tried Timer 2, does the PICaxe OS use it for any particular purposes / Commands?

The K62 version is better, K125 possibly better still, so I am guessing there is some interaction at K31. .

The base PIC has three "31kHz" oscillator modes (LF, MF and HF) with the LF duplicated in the OSCON frequency selection table (a "don't care" in the lsb). When I PEEKSFRed this register, I believe I found that PICaxe selects the LF mode which uses the "Watchdog" (aka Sleep) timer for k31. Whilst not as "bad" as the data sheet threatens (-50% to + 200% of nominal frequency), I think it is probably one to two orders of magnitude less accurate than the normal (factory calibrated) internal oscillator. Therefore, I would normally use SETFREQ k62 (or higher) for any timing purposes.

Cheers, Alan.

 

[cpedw]

The K62 version is better, K125 possibly better still, so I am guessing there is some interaction at K31. None the less it should be good enough for timing 60 or 12 minute intervals ...

Much interesting information here; several different things to investigate.

Are you saying there are 2 more SETFREQ arguments that are undocumented?