pjrebordao
Senior Member
From reading the documentation, namely the commands setint, setintflags I got the impression that the minimum "resolution" available for setting internal interrupts (through the timer) is 16 microS. Is this correct ?
Minimum resolution for 28X1 internal interrupts
- Thread starter pjrebordao
- Start date
pjrebordao
Senior Member
Hello Technical ? Anybody out there ?
I forgot to add in my post that the 16microS aply to a 28X1 running @ 16MHz as per the settimer statement in the manual. Is this correct ?
I forgot to add in my post that the 16microS aply to a 28X1 running @ 16MHz as per the settimer statement in the manual. Is this correct ?
hippy
Ex-Staff (retired)
Well that's what the manual says ....
The period of the timer can be used defined. The timer operates with ‘minor ticks’ and ‘major ticks’. A minor tick occurs every 1/(clock freq / 256) seconds. With a 4MHz resonator this means a minor tick occurs every 64us (32us at 8MHz, 16us at 16MHz, 12.8us at 20MHz). When the minor tick word variable (not accessible by the end user) overflows (from 65535 to 0) a major tick occurs. The major tick increments the timer variable, and so the number of major ticks passed can be determined by reading the ‘timer’ variable.
At 16MHz there's a minor tick every 16uS, so a major tick happens at N*16uS.
The period of the timer can be used defined. The timer operates with ‘minor ticks’ and ‘major ticks’. A minor tick occurs every 1/(clock freq / 256) seconds. With a 4MHz resonator this means a minor tick occurs every 64us (32us at 8MHz, 16us at 16MHz, 12.8us at 20MHz). When the minor tick word variable (not accessible by the end user) overflows (from 65535 to 0) a major tick occurs. The major tick increments the timer variable, and so the number of major ticks passed can be determined by reading the ‘timer’ variable.
At 16MHz there's a minor tick every 16uS, so a major tick happens at N*16uS.
pjrebordao
Senior Member
Can the 'timer' variable be 'preloaded' so that a interrupt can occur without the variable having to go all the way from 0 to 65535 ? That's where I find it unclear...
krypton_john
Senior Member
Also the interrupt isn't a real hardware interrupt - as I understand it the PIC runtime code checks between each user program instruction to determine whether the interrupt procedure should be invoked. Therefore the resolution of the interrupt firing is determined by the greater of the timer resolution and the amount of time the current instruction takes to execute. If the instruction is blocking such as infrain then that could be an interminable time.
Mycroft2152
Senior Member
Just curious, hat are you building where interrupt timeing is o critical?
As KJ said, the PICAXE still has to process the interrupt. Even at 16Mhz, you are only running ~8000 instructions per second.
As KJ said, the PICAXE still has to process the interrupt. Even at 16Mhz, you are only running ~8000 instructions per second.
pjrebordao
Senior Member
I'm looking to build a turntable driven by a stepper controlled by a Picaxe. Probably overkill I know...
I don't intend to have interrupts every 16microS, I just want to know what's the minimum step available to control the timing.
But regarding KJ post, I thought that on X1 Picaxes, the toflag interrupts were not blocked by something like infrain. Am I wrong ?
I don't intend to have interrupts every 16microS, I just want to know what's the minimum step available to control the timing.
But regarding KJ post, I thought that on X1 Picaxes, the toflag interrupts were not blocked by something like infrain. Am I wrong ?
westaust55
Moderator
Minimum resolution for 28X1 internal timer
SETINTFLAGS has a flag (Flag7 = toflag) for the TimerOverFlow flag which can be used for an internal interrupt.
SETTIMER has a duration of 16us for each minor tick at a PICAXE speed of 16MHz.
When the counter for minor ticks reaches 65535, the overflow at transition from 65535 to 65536 (=0) minor ticks increments the major ticks counter.
So when starting with the minor tick counter at zero (0) you would have to wait 16 x 65536 us for an overflow and major tick increment. This equates to 1.048 seconds.
You can preload the minor tick counter with a starting vale (read the manual) so if you set it to 65535 then just one minor tick or 16us will give a minor tick overflow.
BUT . . . is the toflag set when there is a minor tick overflow or a major tick overflow?
The manual covers minor tick overflow incrementing the major tick counter.
There are no words about a major tick overflow or specifically which tick (minor/major) sets the toflag.
As Krypton_John states, this is only the timer resolution. Depending upon which BASIC command is being actioned there is a further delay for that command to complete (unless it is a PAUSE or TUNE command) before the polled interrupt is actioend and them some time to transfer to the Interrupt subroutine.
With respect to the Infra Red input commands, INFRAIN does not apply for the X1 and X2 parts.
Use the IRIN command instead. This command does have a timeout period with a corresponding branch function so would not be "Stuck" forever if no signal received.
SETINTFLAGS has a flag (Flag7 = toflag) for the TimerOverFlow flag which can be used for an internal interrupt.
SETTIMER has a duration of 16us for each minor tick at a PICAXE speed of 16MHz.
When the counter for minor ticks reaches 65535, the overflow at transition from 65535 to 65536 (=0) minor ticks increments the major ticks counter.
So when starting with the minor tick counter at zero (0) you would have to wait 16 x 65536 us for an overflow and major tick increment. This equates to 1.048 seconds.
You can preload the minor tick counter with a starting vale (read the manual) so if you set it to 65535 then just one minor tick or 16us will give a minor tick overflow.
BUT . . . is the toflag set when there is a minor tick overflow or a major tick overflow?
The manual covers minor tick overflow incrementing the major tick counter.
There are no words about a major tick overflow or specifically which tick (minor/major) sets the toflag.
As Krypton_John states, this is only the timer resolution. Depending upon which BASIC command is being actioned there is a further delay for that command to complete (unless it is a PAUSE or TUNE command) before the polled interrupt is actioend and them some time to transfer to the Interrupt subroutine.
With respect to the Infra Red input commands, INFRAIN does not apply for the X1 and X2 parts.
Use the IRIN command instead. This command does have a timeout period with a corresponding branch function so would not be "Stuck" forever if no signal received.
Last edited:
pjrebordao
Senior Member
From what I understood, it's the major tick overflow that sets the toflag.
My question is, can we preload the major tick counter like we do the with the minor tick one ? Or do we have to wait always for the full count from 0 to 65535 before the toflag gets set ?
My question is, can we preload the major tick counter like we do the with the minor tick one ? Or do we have to wait always for the full count from 0 to 65535 before the toflag gets set ?
westaust55
Moderator
Minimum resolution for 28X1 internal
The preload only appears to apply to the minor ticks.
The internal timer word variable "Timer" appears to be reading the major ticks, and yes, the toflag for timer overflow is on re-reading associated with the word variable overflow and hence major ticks.
The preload only appears to apply to the minor ticks.
The internal timer word variable "Timer" appears to be reading the major ticks, and yes, the toflag for timer overflow is on re-reading associated with the word variable overflow and hence major ticks.
pjrebordao
Senior Member
Maybe the idea is to "manually" load the timer variable with the desired preload value inside the interrupt servicing routine...
Can the timer variable be set like any other ?
Can the timer variable be set like any other ?
A minor tick overflow causes a major tick - ie one increment of the timer variable. It does not affect the timer overflow flag.
The timer overflow flag is set when timer itself overflows for 65535 to 0.
As 'timer' can also be acted upon as a normal variable, you can preload it to any number you like.
So the following code would light an LED after 5 seconds, activated by the timer interrupt.
The timer overflow flag is set when timer itself overflows for 65535 to 0.
As 'timer' can also be acted upon as a normal variable, you can preload it to any number you like.
So the following code would light an LED after 5 seconds, activated by the timer interrupt.
Code:
settimer off
timer = 65530
settimer t1s_4
setintflags %10000000, %10000000
main:
pause 10
goto main
interrupt:
high 1
return
Last edited:
Having just read the thread again the answer to your original question is that you probably can't use the timer function as you intend. It is designed for couting elapsed periods of time e.g. seconds, not us.
If you set the timer feature up to overflow every few us, then the PICAXE will never get around to anything else (or do it exteremely slowly). That is because the the timer is entirely interrupt driven, and so takes priority over the main program. So in that situation the chip could simply end up spending all the processing time dealing with the interrupts, and have no time left to do anything else!
If you set the timer feature up to overflow every few us, then the PICAXE will never get around to anything else (or do it exteremely slowly). That is because the the timer is entirely interrupt driven, and so takes priority over the main program. So in that situation the chip could simply end up spending all the processing time dealing with the interrupts, and have no time left to do anything else!
pjrebordao
Senior Member
Actually, I'm looking at having an interrupt every few mS, not uS.
I just wanted to have the possibility to really fine tune the timing, hence the uS.
It might work...
I just wanted to have the possibility to really fine tune the timing, hence the uS.
It might work...