PWM and Interrupts

[afnan]

I am using a dual rotary encoder that has two pins A and B that determine the direction of rotation. While doing that I am running two BLDC motors as well. I have found that if I disable PWM or write MAX PWM for the motors the encoder interrupts work fine. However, if I control the speed using PWM the encoder interrupt events are not caught timily.

Any workarounds?

[fivdi]

I have found that if I disable PWM or write MAX PWM for the motors the encoder interrupts work fine.

If I understand this statement correctly, it means that whether or not things function correctly depends on the value passed to pwmWrite. Is this correct? If so, I don't have an explanation of how this could effect whether or not interrupts are caught timely.

Normally, if interrupts are not being handled timely, it would indicate that other code is running when the interrupt occurs and this other code must run to completion before the interrupt handler is executed.

It's very difficult to say much here without a simple test case that can be used to reproduce the problem.

[afnan]

The test case would be but tricky to produce as it will depend on the interrupt trigger. The test program I have only had two functions.

1. PWM Motor
2. Monitor Encoders (single interrupt at enA)

Now, if I disable PWM, or do digital write on the motor control pin or use 255 the encoder interrupts work fine. The algorithm for monitoring encoders consists of an if-else within the interrupt call and checks compares the level (of the int causing pin) and digitalRead of another pin to determine the direction of motion https://howtomechatronics.com/uncategorized/rotary-encoder-works-use-arduino/. I can go in more detail.

What I think is happening is that Pi does PWM and as its software PWM the processor does not address the interrupts timely.

For now to get the distance readings I have disabled speed and just write 255 and everything is working fine

[fivdi]

The algorithm for monitoring encoders consists of an if-else within the interrupt call and checks compares the level (of the int causing pin) and digitalRead of another pin to determine the direction of motion...

For timely interrupt processing, it's not really that important how long the interrupt handler itself executes. I would imagine that your interrupt routine is running fast. I would also imagine that there are not very many interrupts per second. I would expect the interrupt handler itself to be fine. What is much more important is what the JavaScript engine is doing at the instant the interrupt occurs. Don't forget, in JavaScript there is one thread that does everything. If the JavaScript engine is running application code at the instant the interrupt occurs, it will first run that code to completion before returning to the event loop thus giving the interrupt handler a chance to execute. To handle interrupts timely, everything needs to be quite fast, not just the interrupt handler. For example, if the program has synchronous code somewhere that runs for 250 milliseconds, and a hardware interrupt occurs 1 millisecond after that synchronous code starts running, then there will be at least a 249 millisecond delay before the interrupt handler is executed. The slowest synchronous code in the application will determine how timely interrupts are handled.

What I think is happening is that Pi does PWM and as its software PWM the processor does not address the interrupts timely.

This isn't how it works. pigpio uses a DMA hardware peripheral on the Pi to generate PWM pulses. It doesn't use software to generate the pulses. Note that if you feel that the problem is related to how pigpio uses DMA to generate PWM pulses, you could switch to using classical hardware generated PWM pulses using hardwarePwmWrite to see if it helps.