"John Temples" <usenet@xargs-spam.com> wrote in message
news:slrndk3hmh.c0u.usenet@jwt.xargs.com...
> On 2005-10-03, Keyser Soze <noreturn@nothere.com> wrote:
>> "John Temples" <usenet@xargs-spam.com> wrote in message
>> news:slrndk2ltf.akt.usenet@jwt.xargs.com...
>>> There is no "internal global interrupt enable bit."
>>>
>> Oh my, you are of course correct.
>>
>> Although I seem to remember an errata for one of the first 16Cxx
>> parts to implement interrupt may have had some such quirk.
>
> There was an errata in the old 16Cs that if an interrupt occurred
> in the same instruction in which you were clearing GIE, GIE would not
> clear; you had to test GIE after clearing it to see that it actually
> cleared. Perhaps this is what you're thinking of.
>
No I don't think that was it.
It's more likely one of the "features" of the 8051.
I've been doing a few of those lately and the mix-master I'm using for a
brain probably got confused again.
Reply by John Temples●October 3, 20052005-10-03
On 2005-10-03, Keyser Soze <noreturn@nothere.com> wrote:
> "John Temples" <usenet@xargs-spam.com> wrote in message news:slrndk2ltf.akt.usenet@jwt.xargs.com...
>> There is no "internal global interrupt enable bit."
>>
> Oh my, you are of course correct.
>
> Although I seem to remember an errata for one of the first 16Cxx
> parts to implement interrupt may have had some such quirk.
There was an errata in the old 16Cs that if an interrupt occurred
in the same instruction in which you were clearing GIE, GIE would not
clear; you had to test GIE after clearing it to see that it actually
cleared. Perhaps this is what you're thinking of.
--
John W. Temples, III
Reply by Keyser Soze●October 3, 20052005-10-03
"John Temples" <usenet@xargs-spam.com> wrote in message news:slrndk2ltf.akt.usenet@jwt.xargs.com...
> On 2005-10-03, Keyser Soze <noreturn@nothere.com> wrote:
> > We have not told you one of the really sneaky bit of the interrupt handling
> > on the PIC processors.
> >
> > There are two global interrupt enable bits.
> >
> > One bit is the GIE bit in the INTCON register, bit 7.
> >
> > The other is buried inside the PIC with no direct access from the program.
> >
> > This bit is "set" when the RETFIE is executed and "cleared" when any
> > interrupt is processed.
> >
> > For an interrupt to occur at least one interrupt source must be enabled, the
> > GIE bit in INTCON must be set to one and the internal global interrupt
> > enable must be "set". If the interrupt source is one of the peripheral
> > device then the PEIE bit in INTCON must also be set to one.
>
> There is no "internal global interrupt enable bit."
>
Oh my, you are of course correct.
Although I seem to remember an errata for one of the first 16Cxx
parts to implement interrupt may have had some such quirk.
Sorry for the missinformation.
Reply by John Temples●October 3, 20052005-10-03
On 2005-10-03, Keyser Soze <noreturn@nothere.com> wrote:
> We have not told you one of the really sneaky bit of the interrupt handling
> on the PIC processors.
>
> There are two global interrupt enable bits.
>
> One bit is the GIE bit in the INTCON register, bit 7.
>
> The other is buried inside the PIC with no direct access from the program.
>
> This bit is "set" when the RETFIE is executed and "cleared" when any
> interrupt is processed.
>
> For an interrupt to occur at least one interrupt source must be enabled, the
> GIE bit in INTCON must be set to one and the internal global interrupt
> enable must be "set". If the interrupt source is one of the peripheral
> device then the PEIE bit in INTCON must also be set to one.
There is no "internal global interrupt enable bit."
--
John W. Temples, III
Reply by Keyser Soze●October 3, 20052005-10-03
"Keyser Soze" <noreturn@nothere.com> wrote in message
news:j%40f.8409$oO2.3601@newssvr27.news.prodigy.net...
> [...snip...]
>
> There is a bug with the way you reload the TIMER ONE count register from
> the ISR.
>
> The bug is that the "t1rollover" is used to update TIMER ONE only when
> "rollover_count" reaches zero.
>
> This means the TIMER ONE will request an interrupt 10 milliseconds after
> the call to "SetClock" then count 65536 cycles 99 more times until
> "rollover_count" reaches zero. This results in a 6,498,064 cycles between
> changes of the LED. Or about 1.6 seconds using a 4MHz clock.
this should be ---> 6.5 seconds <---
Forgot the divide by 4.
Reply by Keyser Soze●October 3, 20052005-10-03
"Julian Morrison" <julian@extropy.demon.co.uk> wrote in message
news:dh1dh0$pdb$1$8300dec7@news.demon.co.uk...
>> Why not just re-enable GIE - the interrupt will just happen if one is
>> pending.
>
> It will? What counts as "pending"? Will the interrupt fire if it happened
> at any time while GIE was off? Or, only if the cause is ongoing?
>
We have not told you one of the really sneaky bit of the interrupt handling
on the PIC processors.
There are two global interrupt enable bits.
One bit is the GIE bit in the INTCON register, bit 7.
The other is buried inside the PIC with no direct access from the program.
This bit is "set" when the RETFIE is executed and "cleared" when any
interrupt is processed.
For an interrupt to occur at least one interrupt source must be enabled, the
GIE bit in INTCON must be set to one and the internal global interrupt
enable must be "set". If the interrupt source is one of the peripheral
device then the PEIE bit in INTCON must also be set to one.
-----
An a second note as to "what else was wrong" in your code.
There is a bug with the way you reload the TIMER ONE count register from the
ISR.
The bug is that the "t1rollover" is used to update TIMER ONE only when
"rollover_count" reaches zero.
This means the TIMER ONE will request an interrupt 10 milliseconds after the
call to "SetClock" then count 65536 cycles 99 more times until
"rollover_count" reaches zero. This results in a 6,498,064 cycles between
changes of the LED. Or about 1.6 seconds using a 4MHz clock.
But then you have already found this one. :)
Reply by Michael Lange●September 24, 20052005-09-24
Julian Morrison schrieb:
> Nope, not misunderstanding, being sneaky by doubling up the use of the
> ISR code. Based on the assumption: "retfie" is exactly equivalent to
> "bsf INTCON, 7" followed by "return".
Not exactly, RETFIE prevent to re-enter the ISR before the return is
executed! And that is a big difference.
> Therefore it doesn't matter who
> calls the ISR so long as this behaviour is intended.
>
> The code sequence I was thinking about:
>
> 1. normal code
> 2. GIE off
> 3. critical section
> (at this stage we need to check interrupts and switch on GIE)
> 4. jump to ISR via a normal "call"
> 5. ISR has been written to check interrupt bits
> 6. ISR conditionally does what needs doing
> 7. ISR finishes with "retfie"
> 8. retfie re-enables GIE and returns
>
> Result: code saved and simplified by checking interrupts in one place.
Arrrghh!
My result: It's not sneaky, you are fully missunderstand the whole
concept of intrerrupts!
This is my last hint: Before you think about such crazy stuff, study the
basics and made some spimle things working.
Michael
Reply by toby●September 23, 20052005-09-23
Julian Morrison wrote:
> > Why not just re-enable GIE - the interrupt will just happen if one is
> > pending.
>
> It will? What counts as "pending"? Will the interrupt fire if it happened
> at any time while GIE was off?
Yes, so you don't have to do anything.
> Or, only if the cause is ongoing?
The interrupt flags are sticky and are maintained regardless of the
interrupt enables. (This also means it's usually disastrous to enable
interrupts in the ISR.)
Reply by Julian Morrison●September 23, 20052005-09-23
> Why not just re-enable GIE - the interrupt will just happen if one is
> pending.
It will? What counts as "pending"? Will the interrupt fire if it happened
at any time while GIE was off? Or, only if the cause is ongoing?
Reply by Mike Harrison●September 23, 20052005-09-23
>Michael Lange wrote:
>
>
>>> Also, if code passes through a critical section with GIE off, am I
>>> right it's a good idea to run the ISR manually to catch any missed
>>> interrupts (and rely on the retfie at the end to re-enable GIE)?
>>
>> Sorry, but it looks like you are missunderstanding the term ISR!
>
>Nope, not misunderstanding, being sneaky by doubling up the use of the
>ISR code. Based on the assumption: "retfie" is exactly equivalent to
>"bsf INTCON, 7" followed by "return". Therefore it doesn't matter who
>calls the ISR so long as this behaviour is intended.
>
>The code sequence I was thinking about:
>
>1. normal code
>2. GIE off
>3. critical section
>(at this stage we need to check interrupts and switch on GIE)
>4. jump to ISR via a normal "call"
>5. ISR has been written to check interrupt bits
>6. ISR conditionally does what needs doing
>7. ISR finishes with "retfie"
>8. retfie re-enables GIE and returns
>
>Result: code saved and simplified by checking interrupts in one place.
Why not just re-enable GIE - the interrupt will just happen if one is pending.