As I also now understand from the other responses. Slap on my own wrist. Thanks, -Neil. On Tuesday 04 October 2005 01:06 pm, Howard Winter scribbled: > That's the way Interrupts work on PICs - when an Event occurs that has an > Interrupt associated with it, its Interrupt Flag is set, then if its > Interrupt Enable is set, and if the General Interrupt Enable is set, an > actual "Interrupt" occurs (similar to a CALL 0x04). The only thing that is > stopped ("gated") by the Enables, is the Interrupt itself - the Flags are > always set by the Event. > > There is a good reason for this - if you have disabled one of the > Interrupts temporarily and during that time an Event occurs, when you > Enable it you would have "lost" the fact that the Event occurred if the > Flag wasn't set. In the case of a real time clock it would lose time, but > other more serious consequences could happen in other applications. > > So to sum up, the correct procedure (unless you *never* clear an Enable in > the program) when you want to know if an Event needs handling is: > > IF an Event's Enable AND Flag are set > an Event occurred and should be handled > ELSE > ignore this Event > > The language doesn't help - some people tend to use "Interrupt", "Flag" and > so on ambiguously. I prefer these definitions: > > Interrupt: The act of passing control to the Interrupt Service Routine > Event: Something which happens, and which may cause an Interrupt > Flag (or Interrupt Flag): A bit which indicates that an Event has occurred > Enable (or Interrupt Enable): A bit which indicates that an Event will > cause an Interrupt > > Of course there are two types of Enable - the General one which prevents > all Interrupts from occurring, and the specific ones which relate to > individual Events, and both have to be set to allow an Interrupt to occur. > > Cheers, > > > Howard Winter > St.Albans, England -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist