Split stealthChop, improve driver monitoring and other smaller changes

[teemuatlut]

• Split stealthChop settings such that XY and Z and E are treated individually. A user may want to utilize more powerful spreadCycle for XY and E, but keep the quiet operation for Z axis.
• StealthChop with SENSORLESS_HOMING now tracks the previous state of the mode and restores it after the homing procedure. Previously if an advanced user had disabled stealthChop on one specific driver with stepperX.en_pwm_mode(false);, it would get enabled after homing.
• Add overrides for CS pins into config files. This continues the effort to have the pins files be less necessary for modification for end user.
• Driver overtemperature pre-warn is no longer treated as a hard fault and will no longer activate full kill command of the print job. Automatic current decrease and warning printout still applies.
• Hard faults now require multiple errors to kill a print job. The killing feature was implemented to save material in a case where a driver would stop and go into a fault mode to protect itself. Now a single error that's possible due to a communication error will no longer kill the print.
• Reuse driver status data as much as possible to drastically reduce communication attempts when polling with MONITOR_DRIVER_STATUS. Should improve reliability of valid communication.
• MONITOR_DRIVER_STATUS will now check for a valid driver response. We don't want to act on invalid information.
• Full 20 bit tstep now displayed as "max". Although many of the data points in the output are more for me as a developer rather than the user, this seems like it would be less confusing.
• Automatic current step down will not go under 100mA anymore. I know this was in part fixed already but I just like my way better =)

---

Here's a general plan for the rest of the year.
Ticked boxes mark the changes introduced in this PR and the ones that have already been merged in.

• Move to new universal TMCStepper library
• Implement inherited Marlin TMC classes
• Support TMC2660
• Support TMC5160
• Add sanity checking for driver errors
• Greatly reduce communication attempts for monitoring
• Improve TMC error verbosity with better error messages
• Add communication checking on boot
• Add the ability to change chopper timings (spreadCycle)
• Tweak default chopper settings for quieter spreadCycle operation
• Support Trinamic coolStep technology
• Improve M122 with fetching raw register data
• Add TMC section to the LCD
• Support TMC5130
• Support TMC2224
• Add SOFTWARE_ENABLE for all smart drivers (Request from Panucatt)
• Split stealthChop by axis
• Read stallGuard status through software to eliminate the diag-endstop wire

[thinkyhead]

The definition for this function is removed, so should this be removed?. But it is still being called by this:

inline void delta_sensorless_homing(const bool on=true) {
  sensorless_homing_per_axis(A_AXIS, on);
  sensorless_homing_per_axis(B_AXIS, on);
  sensorless_homing_per_axis(C_AXIS, on);
}

[teemuatlut]

Just changed but not removed. I'll go based on the assumption that A_AXIS corresponds with stepperX and so on.

[thinkyhead]

The sensorless_homing_per_axis function is not present in motion.cpp. It was replaced by start_sensorless_homing_per_axis and end_sensorless_homing_per_axis.

[thinkyhead]

These introduce a regression. E_AXIS_N now takes an argument. The E_AXIS_N(1) macro is correct.

[thinkyhead]

Since this requires the stealthChop_by_axis array, which only exists if STEALTHCHOP_ENABLED we can assume that _TMC_INIT also requires STEALTHCHOP_ENABLED. This implies that AXIS_IS_TMC(...) for any axis also necessitates and assumes STEALTHCHOP_ENABLED to be enabled.

[teemuatlut]

stealthChop_by_axis should be defined whenever there's a TMC driver (HAS_TRINAMIC).

[teemuatlut]

I'm reverting the library manager to use the library name to fetch a proper release of TMCStepper.
To ensure backwards compatibility it'll be restricted to current major version (0.x.x). If I need to break the API in such a way that breaks this compatibility, it'll be released under a new major revision.

[thinkyhead]

I can see why you may prefer this. However, I really hope in the near future to get platformio.ini back to the point where it wasn't required to download and install git on Windows, which is another hoop for novice users to jump through. So, direct URLs pointing to a .zip archive (on GitHub or elsewhere) is preferred.

[teemuatlut]

It doesn't. I did try this in a VM before committing the change.

[teemuatlut]

To clarify, direct git links do need it. But when specifying just the registered library name, PIO can handle the download itself (through whatever) and git is not needed.

[thinkyhead]

Right, so I guess there are only certain libraries (those that PlatformIO doesn't know about) that need special treatment.

[teemuatlut]

Could you tell me why you'd prefer the static constexpr in stepper_indirection?

[thinkyhead]

constexpr gives the compiler the most leeway in how it chooses to manifest the array. It may not produce an array at all on the most simple setups.

[teemuatlut]

Okey sure but what's the benefit here? I've compiled and tested both versions are the is absolutely no size difference.

[thinkyhead]

Okey sure but what's the benefit here? I've compiled and tested both versions are the is absolutely no size difference.

The behavior may differ when compiled with various levels of optimization.