Quote Originally Posted by The Master View Post
Ok. Ill have a read through them. I thought the thing Darrel made was to make interrupts easier.
Actually, what he made was to make interrupts more "real-time." It doesn't make PBP interrupts themselves easier, it makes "hardware" interrupts easier.

An interrupt is a hardware bit in the PIC (there are typically quite a few) that is set when a certain condition occurs. (Here are a few examples: when an a/d conversion is done; when a timer overflows; when a certain i/o pin changes state, when serial data arrives.) When one of these bits gets set, the code stops executing at its current position, and temporarily goes to the assigned interrupt code.

Now here's the part that describes why Darrel's code is helpful:

A "software" interrupt is BASIC-speak for checking the interrupt flags after each basic command. If a flag is set, then the code essentially gosubs to the interrupt code. This is the standard way to do interrupts within PBP. It's not a true interrups, but this is a "safe" way to do it, because none of the temporary hidden system variables are overwritten during an interrupt. (These system variables are used within the compiler commands, and are invisible to you unless you look at the compiled code.) This is an easy way to do it if you don't need 100% perfect timing.

A "hardware" interrupt is also BASIC-speak for a "real" interrupt. Instead of checking the flags, it relies on the hardware to do the interrupt if you have the Global or Peripheral Interrupts Enabled. That is, if you set the flags properly, then within a clock cycle or two, the code jumps to the interrupt handler. This is nice because the timing is instant, accurate, and precise. However, if you are in the middle of a BASIC command (or math operator), and you also use that command within your interrupt, then when it returns to where it was previously, the values could be corrupt. This is why Darrell put together his code routines... so it can save the hidden system variables, go through the interrupt, restore the system variables and return without losing any information in the process.

I'm sure this will help you understand a lot more. Basically, if you need precision--such as audio pwm--then you want to use the hardware interrupts. If you are doing something where the timing is much more casual--such as charging a battery--then you might as well use the s/w interrupts; they are easier to implement.