What happens if interrupt breaks PULSIN, PULSOUT, ADCIN, PWM, etc statements?

[CuriousOne]

Hello.

Say there is some code, which runs in loop, and measures frequency at one pin, measures voltage at another pin and does something extra.

There is also an interrupt configured, so when signal on certain pin gets high, another piece of code is launched, which will take about 1 millisecond to execute. What will happen? as I understand, all above mentioned operations will be disrupted, and measurements need to be retaken, correct?

[HenrikOlsson]

If you're using PBP ON INTERRUPT then nothing happens because it always waits for the current command to "complete" before servicing the interrupt.

If you're using "real" interrupts (in ASM or using DT-INTS for example) then it's different:

If an interrupt occurs in the middle of a...
...PULSOUT command the width of the generated pulse will be extended by the amount of time that the interrupt takes.
...PULSIN command the measured width will be off by (up to) the amount of time that the interrupt takes.
...PWM command the PWM "signal" will just stop being generated for the duration of the interrupt. (Not applicable for HPWM of course).
...ADCIN command generally nothing happens. There's usually no harm in sampling the signal longer than needed and once sampled the actual conversion is done without software.

Generally speaking whatever the PIC is doing is put on hold for the duration of the interrupt + context save/restore. This means that ALL commands using software timing will be affected.

/Henrik.

[CuriousOne]

Yes I want to use "real" interrupts, since the task is to be executed in time. Thanks a lot.

[CuriousOne]

So if I understood correctly, if PULSOUT was generating "1" at moment of triggering, output will be held "1" till the interrupt completes? that is bad....

[HenrikOlsson]

Correct, if you have PULSOUT generating a 100us pulse and an interrupt occurs while the pulse is being generated the actual pulsewidth will be "extended" for the duration of the interrupt. Bad, perhaps, but that's how interrupts work, they interrupt whatever the processor is doing (ie keeping track of time in order to generate a 100us wide pulse) and goes off doing something else, more important. If generating the 100us pulse is the most important/critical task then perhaps THAT should be done using interrupts.

/Henrik.

[CuriousOne]

Ok, so I have to move additional routine, which will ensure that output is "0", when interrupt will happen.