STM32 & Due IRQ Priorities adjustment/fixes

[AbsoluteCatalyst]

• STM32's had their priority grouping set to 3 bits preempt, 1 bit sub priority. Adjusted them to 4 bits preempt, 0 sub since we're not using that feature & match Due. Shouldn't affect anything atm.

• E3 Mini's had their endstop interrupt priorities set to 6 by default. Adjusted to 1.

• STM32F4 tone timer was missing it's setPriority, i'm not sure what it defaulted to.

• I adjusted the Due's timer IRQ priorities to loosely match the other HAL's. They were quite low. I think I hear an extremely slight improvement in motion. (placebo?)

• I set the STM32F1 set to the same priorities.

[repetier]

I'm ok with that at the moment. But I think we need to make an official priority list. Things that are important are:

• Motion3 timer highest priority
• Serial communication second highest priority so we loose no data
• Beeper is not required that high maybe one lower then serial. Serial is also quite fast.
• Motion2 needs frequent calls also not that sensitive due to caching of buffers.
• Servos are quite fast and need precision or the jitter, so higher then motion2
• PWM is not that relevant - it's only software pwm and can be slow.

Did I forget a function? What do you think about that order?

[AbsoluteCatalyst]

I agree we should have it defined out. I wasn't too sure myself how the order should be.

Motion3 definitely at the top ( I wonder how SysTick interferes with it? ) with 0

Serial should be 1, I've gotten some errors with my USB irq set to 3-4. I Imagine normal uart might have more errors. We need to check them/set them though since I think they're defined to 0 by default and might interfere with motion3. I'm not so concerned with other serial devices eg TMC drivers since they're infrequent/not so important.

Agreed with beeper. It's little finicky via SW pwm sometimes, but since it's not used so often & finishes quick: 2-3.

I couldn't figure out where to put motion2. (Uh, do you have a good rule of thumb for it's frequency compared to stepper frequency btw?)

The last two PWM & servo sound right. PWM also manages our ADC but I don't think I see any difference regardless of priority.

[AbsoluteCatalyst]

Sidenote: I caught my bltouch and endstops generating a bunch of priority 1 interrupts during printing. I think it might be worthwhile to detach any HW endstops when not homing and not always checking endstops.

I wrote something small with endstops.h that handled that this morning. Though reworking it with your recent update/commit now.

[repetier]

Motion2 is defined by these two settings: // Update frequency for new blocks. Must be higher than PREPARE_FREQUENCY.

define PREPARE_FREQUENCY 2000

// Number of blocks with constant stepper rate per second.

define BLOCK_FREQUENCY 1000

Each motion3 block for long moves is 1/BLOCK_FREQUENCY seconds. Problem is when we have moves that are shorter than that time. We fill up with PREPARE_FREQUENCY = motion3 frequency. With it being twice as high we normally have a good margin that the 16 possible precomputed blocks do not run out. That is the only thing we need to avoid and since the code is a bit longer it can easily shift other interrupts a few us when they have lower priority So I think it should be ok to have it not the highest priority. Shifting it around makes no real difference. So it should be lower than the fast servo interrupt. Maybe before pwm which is not really relevant especially with all the hardware interrupts.

Revised order: 0 Motion3 timer highest priority 1 Serial communication second highest priority so we loose no data 2 Beeper for good quality but not blocking critical interrupts 3 Servos are quite fast and need precision or the jitter, so higher then motion2 4 Motion2 needs frequent calls also not that sensitive due to caching of buffers. 5 PWM is not that relevant - it's only software pwm and can be slow.

Regarding end stop detach - If I understood you correctly they are giving false triggers? Then it would in deed be better to disable them. I have with last commit added an improved debug endstops. When you send M111 S70 you see every trigger/untrigger of an endstop in log. This is now reported in main loop and not in interrupt so it does not block and crash firmware any more when frequently triggered.

We can add an attach/detach function in EndstopDriver or maybe better add 2 IO_TARGET to enable/disable all. On the other hand I wanted to use motor end stops to detect lost steps or at least try if it works. Here disabling all would be a bad idea. So disabling all is also bad. So guess better attach/detach function so we can selectively do this e.g. zprobe automatically with activate and deactivate of probe. That should be the biggest one especially with inductive probes that trigger at certain z height.

[AbsoluteCatalyst]

Revised order for the priorities looks good.

// Update frequency for new blocks. Must be higher than PREPARE_FREQUENCY.

define PREPARE_FREQUENCY 2000

// Number of blocks with constant stepper rate per second.

define BLOCK_FREQUENCY 1000

Shouldn't that be "Must be higher than BLOCK_FREQUENCY"? I was curious about it because i've been toying around with my step rates. If the buffers ran out would it begin to stutter or just cap/slow speed? Right now I have 325khz w/4khz on my Due. I figure it should be enough at 250us...

Regarding end stop detach - If I understood you correctly they are giving false triggers?

Yes, it's quite weird actually. Multiple endstops would occasionally trigger at once, or sometimes because of vibrations. May be some electrical problems. The BLTouch's needle wiggles inside it's socket too, though.

I have with last commit added an improved debug endstops.

Thanks for the updated debugs, was using them while testing today.

I have an implementation of the detach/attachable endstops i'll pull in a few minutes. Yep! We can select which endstops to detach with this.

[repetier]

Ok description is wrong must be BLOCK_FREQUENCY of course.

What happens when motion3 blocks are empty is that no steps are send until motion2 adds a new block. So we are not loosing any steps but if timings get bad motors might stall or loose a step from it.