LPC176x Framework SPI Fixes for MAX6675, MAX31855 and MAX31865 SPI boards

[GadgetAngel]

The issues in this PR only affect the LPC1768 and LPC1769 framework.

This is a long description…

Requirements

1. SKR V1.3 or SKR V1.4 or SKR V1.4 Turbo board from BIGTREETECH.
2. At least one or two PT100 sensors and one or two K-Type Thermocouples
3. MAX6675 board
4. A MAX31855 board
5. A MAX31865 board
6. A USB Logic Analyzer would come in handy, I use the one from Saleae Logic Pro 8.
7. A few 100K Thermistor would be nice to compare temperature results.
8. REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
9. Snap-on ribbon cable connector that pierces the ribbon cable to access the SPI lines on the default hardware SPI bus as long as SDCARD_CONNECTION is "LCD."

Over the last couple of months I have been having issues with attaching different temperature sensors (PT100, K-Type Thermocouple) to the LPC1768 and LPC1769 boards (SKR V1.3, SKR V1.4 and SKR V1.4 Turbo). I have all these boards here and have tested with them to discover the following issues:

ISSUE#1: The LPC176x Framework does not allow for the ARDUINO define in the framework itself. Instead the ARDUINOLPC is defined in c_cpp_properties.json file. Without the ARDUINO defined in c_cpp_properties.json none of the MCU boards in the LPC framework can use the MAX31865 library. Since the boards I am dealing with are all 3.3VDC ADC referenced MCU boards, not having access to the MAX31865 library limits the Marlin user's ability even more. Since the Adafruit MAX31865 and Adafruit MAX31855 are open source libraries and are covered under the BSD license, one can fork the library and add to it as long as you stick to the BSD license. This PR fixes the issue with LPC environment not being able to compile with the Adafruit MAX31865 library by creating a version of the MAX31865 library just for the LPC framework. Configuration files for this BUG:
Configuration_Issue#1.zip Here is a link to a video demonstrating this ISSUE#1: https://drive.google.com/file/d/1xdhI9QNYdjAKTzIfNopnHdkLFYAhaBGN/view?usp=sharing
This PR will fix this ISSUE#1.

ISSUE#2: The SKR V1.3 board is very limited on free I/O PINS in which to use to attach a MAX31865 or MAX31855 or MAX6675 SPI board. Therefore, most users only have one extruder and the SKR V1.3 / SKR V1.4 / SKR V1.4 Turbo boards all have two extruder driver sockets. This allows the Marlin user of the SKR V1.3 board to run a MAX31855 right from the E1 driver socket without having to use any other additional PIN on the SKR V1.3 board. The problem resides in the fact that when you try to use the E1_DIR_PIN (P0_00) or the E1_STEP_PIN (P0_01) the SKR V1.3 HAL's SanityCheck.h file says you can not use those PINS. The SanityCheck.h in the Marlin\src\HAL\LPC1768\inc directory has a BUG. The SKR V1.4 and SKR V1.4 Turbo uses different PINS for the E1_DIR_PIN and E1_STEP_PIN and this fact was overlooked. Here are the configuration files used to find this BUG:
Configuration_Issue#2.zip Here is a link to a video demonstrating this ISSUE#2: https://drive.google.com/file/d/1ZKUSshMx08fRq4Fefy4Za61re_LaZ33G/view?usp=sharing

ISSUE#3: I was asked by a Facebook group to do a guide on how users of the SKR V1.3/V1.4/V1.4 Turbo could hook up a PT100 and K-Type thermocouple using SPI protocol. Infact, that's what got me testing the setups because I like to test things out before writing a guide. I do not always follow this rule but this time I decided that since I already owned the boards I would test out the configurations I was going to recommend. It was during my testing that I discovered all these issues and can now understand why a lot of users can not get SPI to work on these boards. Back to ISSUE#3. Like I stated in ISSUE#2, the E1 socket has free pins available to use. So I decided that if a user had a mix of UART and SPI drivers he would have at least 3 additional PINS on the E1 driver socket. The AUX-1 connector is also available on the SKR V1.3 board but the two signal pins are shared with the TFT connector (TX0 which is P0_02 and RX0 which is P0_03). So I tried to hook up the MAX31865 board with PT100 sensor to E1 socket's E1_DIR_PIN (P0_00), E1_STEP_PIN (P0_01) and E1_SERIAL_RX_PIN (P1_01 - of course the "UART" jumper must be in place for this RX_PIN to work) and SERVO_PIN which is P2_00 as MAX31865_MOSI_PIN. When I tried this out I get an immediate MAX TEMP ERROR. After purchasing a USB Logic Analyzer I could see that the SPI communication lines where not functioning so I decided to try the Adafruit MAX31865 library call. But the Adafruit MAX31865 library is already installed for Marlin, you may say. BUT, remember that the LPC176x framework does not have the ARDUINO constant defined and all LPC176x framework boards will fail when compiled. So I created a MAX31865 library that contains the ARDUINOLPC constant and instead of doing a readFault(), which returns only 1 byte and then you have to do a readRTD() to get the RTD value. I decided to create two new library members called: readRTD_with_Fault() and readRTD_Resistance(). After working within temperature.cpp file, I decide to just use the readRTD_with_Fault() library member. This readRTD_with_Fault() will return the RTD value with the one "fault bit" which indicates, if set, that a readFault() needs to be done to get the whole fault byte. This way I can get the fault and RTD in one unsigned 16 bits and let temperature.cpp process it like it does the MAX6675 temperature. The RTD then can be used like before to calculate the max31865_ohms value without having to do another call. So you only do an additional call if the fault bit is set. You still have to do the same max31865.temperature() call but max31865.temperature() is identical to the one found in the NON-LPC board's Adafruit MAX31865 library. No code changes needed. I also tested the MAX31865 hardware SPI call. The two libraries are identical except for what I have mentioned here in the above discussion. Here are the configuration files that were used to find ISSUE#3:
Configuration_Issue#3_MAX31865 will not run on E1 pins.zip Here is a link to a video that demonstrates this ISSUE#3: https://drive.google.com/file/d/1RC_9j6Jk4IXzzgIpCbOEi81NYrU2cXEn/view?usp=sharing Here is a link to the video that demonstartes how this PR fixes ISSUE#1, ISSUE#2 and ISSUE#3: https://drive.google.com/file/d/1r_JaTKZQ7-w5DcX1lAxCS-FwrU_wAZ7w/view?usp=sharing This PR fixes ISSUE#1thru#3. This PR will also close BUG report #20132.

ISSUE#4: Since I owned some K-Type Thermocouples, I wanted to see the how the MAX6675 board would do on the SKR V1.3 board. To my surprise, when I connected a MAX6675 board with a K-Type thermocouple and utilized hardware SPI by using one of the AUX-1 connector's signal pins (TX0 - P0_02 and RX0 - P0_03) to act as a CS for the MAX6675 board I got a MAX TEMP error when I used P0_02 as seen in this link to the video for P0_02: https://drive.google.com/file/d/1Ec5zMlSDFHIeKsQm_Uxo6-1-N7DEyIAe/view?usp=sharing and I got a MIN TEMP ERROR when I used P0_03 as seen in this link to the video for P0_03: https://drive.google.com/file/d/1D6fhdvHDwK3of_RkC7o9wTb2B7kzOJEF/view?usp=sharing. Here are the configuration files that were used to find this BUG on P0_02: Configuration_Issue#4_1_P0_02.zip Here are the configuration files that were used to find this BUG on P0_03: Configuration_Issue#4_2_P0_03.zip To fix this ISSUE#4, I examined the captured SPI data and decided that maybe the LPC framework is riding on the edge of the SPI protocol. So I went looking for an external library. For some reason using library calls seems to fix the SPI problems with this framework. I found a open source library that was done by Adafruit which they no longer maintain. I modified it to add a begin() method and a hardware spi object instance. I used the same technique in temperature.cpp but placed a library wrapper around it. I keep the software SPI object instance because I wanted to add a member that would send back the raw 16 bits of unsigned data so that the temperature.cpp could process it like it always has. This new member is called readRaw16(). readRaw16() returns the raw unsigned 16 bits of data from the MAX6675 packet. This way temperature.cpp can process it normally. When I tried it out the issue with P0_02 and P0_03 in hardware SPI was fixed. I also tested the software SPI instance of this MAX6675 library and it works like a charm. Here is a link to the video that demonstrates how this PR will fix ISSUE#4 for P0_02:
https://drive.google.com/file/d/1RiM-0hohDI9dTUd5jXIsPy9kyRRpy19z/view?usp=sharing and here is a link to the video that demonstartes how this PR will fix ISSUE#4 for P0_03: https://drive.google.com/file/d/1Ef_eWXFkcFryugnuwmnq2APqw8tjbZst/view?usp=sharing. This PR fixes ISSUE#4. This PR will also close BUG #20359

ISSUE#5: Since I tested the MAX6675 board, the next logical step would be to test the MAX31855 board. By this time I had pulled out my SKR V1.4 and SKR V1.4 Turbo boards. I start running tests and any problem I found on the SKR V1.4 I also found on the LPC1769 SKR V1.4 Turbo. Again, I want to use whatever pins I can without hacking at the MCU board. By this time I have a standard set of tests. Run a test with Software SPI by utilizing the pins on the empty E1 driver socket and run a test in hardware SPI with two MAX31855 boards and utilize the pins on the TFT connector. ISSUE#5 is about the results of the software SPI on the MAX31855 board. When I use the empty E1 driver socket pins (E1_DIR_PIN is P1_14, E1_STEP_PIN is P1_15 and E1_SERIAL_RX_PIN which is P1_01) to run one MAX31855 in software SPI mode it results in a MIN TEMP error. From looking at the capture data I could see only one sample gets through and then the SPI lines do not function properly. Here is the configuration files that were used to find this BUG: Configurations_Issue#5_MAX31855 will not work on E1 socket with SKR V1.4 Turbo.zip Here is a link to the video that demonstrates ISSUE#5: https://drive.google.com/file/d/1gfes4-4VozdZxBdNdRCTonhXl6iNBOfZ/view?usp=sharing. I bet you that you already know what I did to fix this issue, you are right! I found the Adafruit MAX31855 library. Its is an open source library with BSD license. I used the Adafruit MAX31855 library to add the ARDUINOLPC constant. I also added a new member to this library called readRaw32(). readRaw32() returns the raw 32 unsigned bits of data from the MAX31855 data packet and then temperature.cpp can process it as it always has (no new code changes). Here is a link to a video that demonstrates how this PR fixes ISSUE#5: https://drive.google.com/file/d/1Ri-j5ZjTuXcPVT1pBNLy2_t8cvDK2WDM/view?usp=sharing. This PR fixes ISSUE#5 and closes BUG report #20418.

Before I go on to the last ISSUE I found, I want you to really understand that none of these new libraries will get executed unless the MCU board running is defined as being part of the "IS_LPC1768" macro that I created in the boards.h file. I will say this again, If the board is an SKR PRO or GTR V1.0 board, these board are NOT part of the IS_LPC1768 macro and will use the Adafruit MAX31865 library 1.1.0 and will not use MAX6675 library or the MAX31855 library or the MAX31865 library for LPC1768 framework!! I want the Marlin code to run as it did before but only add these new libraries for the LPC framework and for MCU boards that are listed in the IS_LPC1768 macro.

ISSUE#6: As I stated in ISSUE#5, I also ran a hardware SPI test using two MAX31855 boards that use the two signal pins from the TFT connector on the SKR V1.4 Turbo board. The two TFT signal pins are RX0 which is P0_03 and TX0 which is P0_02. The MAX31855 is hooked up to the default hardware SPI bus on EXP2 connector by tapping into the EXP2 ribbon cable with a snap on piercing connector. The default hardware SPI bus is EXP2 connector as long as #define SDCARD_CONNECTION is set to LCD. When I ran this test the SKR V1.4 Turbo immediately got a MIN TEMP error. After looking at the SPI capture data with my USB Logic Analyzer, I can see only ONE sample of data got through and then the SPI lines stop functioning. Here are the configuration files that were used to find this BUG:
Configuration_Issue#6 MAX31855 not working in Hardware SPI with P0_03 pin.zip. Again, I turn to the MAX31855 library and look at the hardware SPI object. I added the new member readRaw32() as I discussed in ISSUE#5. But I made no further changes to the Adafruit MAX31855 library. This way temperature.cpp can use readRaw32 to get its raw data so that temperature.cpp can process it. I tested the hardware SPI with two MAX31855 and used the P0_03 and P0_02 pins and everything works nicely. Here is a link to a video demonstrating how this PR fixes ISSUE#6: https://drive.google.com/file/d/1xYfAhIY9kH46tssbu9sMDyAc6b5qRuZk/view?usp=sharing This PR fixes ISSUE#6 and will close the BUG report #20429

Summary of Test Results with the Current Bug-fix-2.0.x Branch of Marlin used:

ISSUE #	SPI Board Tested	SPI mode used during testing	Result
ISSUE#1	MAX31865 & MAX31855	SW SPI & HW SPI	failure to COMPILE
ISSUE#2	MAX31865 & MAX31855	SW SPI & HW SPI	failure to COMPILE
ISSUE#3	MAX31865	SW SPI	MAX TEMP error
ISSUE#4	MAX6675	HW SPI, using P0_02	MAX TEMP error
ISSUE#4	MAX6675	HW SPI, using P0_03	MIN TEMP error
ISSUE#4	MAX31865	HW SPI, using P0_02	MAX TEMP error
ISSUE#5	MAX31855	SW SPI	MIN TEMP error
ISSUE#6	MAX31855	HW SPI, using P0_03	MIN TEMP error

From examining the table above, I still believe that the current SPI communications on the LPC framework
are "riding on the edge". Sometime the LPC MCU board reads the data WRONG and produces a MAX TEMP error because it thinks a fault was found. Sometimes the LPC MCU board reads more than fifteen Zeros and produces MIN TEMP error because the SPI handshake just STOPS WORKING.

Summary of Test Results with this PR Branch of Marlin used:

ISSUE #	SPI Board Tested	SPI mode used during testing	Result
ISSUE#1	LPC MAX31865 & LPC MAX31855	SW SPI & HW SPI	Fixed
ISSUE#2	LPC MAX31865 & LPC MAX31855	SW SPI & HW SPI	Fixed
ISSUE#3	LPC MAX31865	SW SPI	Fixed
ISSUE#4	LPC MAX6675	HW SPI, using P0_02	Fixed
ISSUE#4	LPC MAX6675	HW SPI, using P0_03	Fixed
ISSUE#4	LPC MAX31865	HW SPI, using P0_02	Fixed
ISSUE#5	LPC MAX31855	SW SPI	Fixed
ISSUE#6	LPC MAX31855	HW SPI, using P0_03	Fixed

Description

I now will cover which files I have changed and why I made the changes:

In MarlinCore.cpp I added to the section on "INIT and Initialize SPI Thermocouples" so that the new SS_PIN will be used if MAX6675_SS_PIN is not being used.

In platformio.ini file I added the new Marlin variables that when active will load the Modified library from my github repository. These new libraries are only for the LPC framework:

MAX6675_HAS_MAX31865    = Adafruit MAX31865 library@~1.1.0                         
LPC1768_HAS_MAX31865    = https://github.com/GadgetAngel/Adafruit-MAX31865-V1.1.0-Mod-M.git
LPC1768_HAS_MAX31855    = https://github.com/GadgetAngel/Adafruit-MAX31855-V1.0.3-Mod-M.git
LPC1768_HAS_MAX6675     = https://github.com/GadgetAngel/MAX6675-V1.1.0-Mod-M.git

The Marlin variable for the normal Adafruit MAX31865 library V1.1.0 had to be changed so that it does not get loaded for the LPC framework. For the LPC framework you want Adafruit-MAX31865-V1.1.0-Mod-M library to be used instead of Adafruit MAX31865 library V1.1.0. LPC_1768_HAS_* will only be active for LPC boards in IS_LPC1768 macro.

In boards.h file, I add the IS_LPC1768 macro.

In pins_BTT_SKR_V1_3.h file, I define a new Marlin compiler directive "LPC1768_IS_SKRV1_3" that is used in Marlin\src\HAL\LPC1768\inc\SanityCheck.h file.

In Marlin\src\HAL\LPC1768\inc\SanityCheck.h file, I fixed the bug that would not allow P0_00 or P0_01 to be use as TEMP_0_PIN. One simple #if directive.

In pins_BTT_SKR_common.h file, I corrected typos.

In Marlin\src\inc\SanityCheck.h file: for the check on "MAX6675_SS_PIN (required for TEMP_SENSOR_0) not defined for this board." I added the new Marlin variables so this message would not appear. I did the same for the MAX6675_SS2_PIN message.

In Conditionals_post.h file, I create two new Marlin compiler directives MAX6675_0_IS_MAX6675 and MAX6675_1_IS_MAX6675.
I also added the new compiler directives that turn on a new LPC library if it needs to be on. I also determine if Software SPI will be used and set a new compiler directive to indicate that for the temperature.cpp file. This is also where I can distinguish between which MAX31865 library will be used.

Now to temperature.cpp file:
Added setup for the LPC1768 libraries. So just like you did for the Adafruit MAX31865 V1.1.0 libray, I did the same for the new LPC framework of libraries (MAX6675, MAX31855 and MAX31865)

Added new compiler directives so that MAX6675_SEPARATE_SPI would not be trigger unless it needed to be.

In Temperature::init(), I added the new .begin() calls for the MAX6675 and MAX31855. These are only active for the IS_LPC1768 boards.

Fixed two typos with PIN_EXISTS(TEMP_0_TR_ENABLE) these were PIN_EXISTS(TEMP_0_TR_ENABLE_PIN). I search for TEMP_0_TR_ENABLE_PIN_PIN but there was not one so I assumed it was a typo and you really intended it to be "TEMP_0_TR_ENABLE"

The rest of the changes were done in Temperature::read_max6675():

Added compiler directives so that spiBegin(); and spiInit(MAX6675_SPEED_BITS); will only be used when spiRec() is needed.

Added compiler directives so that "MAX6675_WRITE" and "DELAY_NS(100)" will only be active when you are doing hardware SPI or you needed to use max6675_spi.receive() call for Software SPI.

Most MCU boards will use max6675_spi.receive() call for MAX31855 Software SPI or MAX6675 Software SPI. The MAX6675_WRITE and DELAY_NS(100) are needed when max6675_spi.receive() and spiRec() calls are used.

If they are need, created references to the new library objects called max31855. and max6675.

If the new MAX31865 library for IS_LPC1768 MCU board is being used, initialize max6675_temp to be readRTD_with_Fault();

If the new MAX6675 library for IS_LPC1768 MCU board is being used, initialize max6675_temp to be readRaw16()

else
If MAX31865 V1.1.0 library is being used, initialize fault_31865 to (readFault() with the upper two bits zeroed out) or set fault_31865 to 1.

Now, we test for faults like we did before.
I changed the format of the error messages but that is a minor change.

You process max6675_temp if you do not have a fault.

If you do have a fault, we increment the error count and check against THERMOCOUPLE_MAX_ERRORS.

If we are processing a MAX31855 we support negative readings.

If we are using MAX31865, based on compiler directives we have two different ways to calculate max31865_ohms. Use the right formula for the right MAX31865 library.

return max6675_temp

Benefits

This PR will take out unneeded manipulations of the MAX6675_SS_PIN. The Marlin user will no longer have to provide an UNUSED PIN so that Marlin will know when software SPI is being used instead of hardware SPI for the MAX31865 board. The user will now have the choice of using the backward compatible MAX6675 variables for DO_PIN, SCK_PIN and SS_PIN or they can use the new ones:

for MAX6675:

MAX6675_SS_PIN or MAX6675_CS_PIN
MAX6675_SS2_PIN or MAX6675_CS2_PIN
MAX6675_SCK_PIN
MAX6675_DO_PIN or MAX6675_MISO_PIN

for MAX31855:

MAX6675_SS_PIN or MAX31855_CS_PIN
MAX6675_SS2_PIN or MAX31855_CS2_PIN
MAX6675_SCK_PIN or MAX31855_SCK_PIN
MAX6675_DO_PIN or MAX31855_MISO_PIN

for MAX31865:

MAX6675_SS_PIN or MAX31865_CS_PIN
MAX6675_SS2_PIN or MAX31865_CS2_PIN
MAX31865_MOSI_PIN
MAX6675_SCK_PIN or MAX31865_SCK_PIN
MAX6675_DO_PIN or MAX31865_MISO_PIN

Configurations

Configuation and Platformio.ini file for PR.zip

Related Issues

The following BUG Reports will be fixed with this PR:

#20132, #20359, #20418, #20429, and #20584, and #20839

Other issues related to this PR

bigtreetech/BIGTREETECH-SKR-PRO-V1.1#176
bigtreetech/BIGTREETECH-SKR-mini-E3#476 (comment)

[rhapsodyv]

Good to see that you found the solution for all MAX and LPC issues. I will not able to test it until my sensors arrive. Maybe anyone here can test it.

For a general review, I think you should take a look if it's possible to change this PR to it be more general, avoiding thinks like:
LPC1768_IS_SKRV1_3, IS_LPC1768, MAX6675_HAS_MAX31855_LPC176X.
Not because their are wrong, but because it's hard to maintain. In theory, a SPI sensor like MAX should not have any specific code for a specific board. It could, yes, have some specific configs.
Again: I'm not saying your fix is wrong. But it would be good if the fix was a little more general.

[GadgetAngel]

Again: I'm not saying your fix is wrong. But it would be good if the fix was a little more general.

I agree. The problem is ARDUINOLPC define. If you add compiler directive to tell LPC framework to define an ARDUINO you get a ton of errors from a lot of other LPC framework code.

So the ARDUINOLPC constant is needed. I do not know of a way to use a script to add characters to a certain line of code in a platformio. library and add " || ARDUINOLPC" right before compilation.

The only solution was to MOD the platformio libraries. I was not sure if the Marlin developer team wanted that. But if you are telling me to make the MOD libraries work for ALL MCU boards, I can try and do that. I have the following boards I can test the MOD libraries out on:

1. HiLetgo RAMPS 1.4 with ELEGOO MEGA 2560 R3 Board
2. SKR Mini E3 V2.0
3. SKR V1.3
4. SKR V1.4
5. SKR V1.4 Turbo
6. SKR PRO V1.1
7. SKR PRO V1.2
8. SKR GTR V1.0 with M5 V1.0

Are you telling me to change my MOD libraries so Marlin can use these libraries for ALL MCU boards?

I am going to assume the answer to my question is YES and start working on making the libraries general purpose and then add the general purpose libraries to the temperature.cpp code.

[sjasonsmith]

We do not really want lots of dependencies pointing to random user forks. Perhaps @p3p has some suggestions for working with the ARDUINO defines.

[GadgetAngel]

We do not really want lots of dependencies pointing to random user forks. Perhaps @p3p has some suggestions for working with the ARDUINO defines.

The problem is that without these framework specific libraries as a temporary fix to the SPI communication problems with the LPC framework, the Marlin code for LPC type boards will NOT function in a reliably consistent way with SPI temperature sensors. I have actual seen a temperature sensor on a SPI MAX (i.e., MAX31865 or MAX31855) work and then 30 minutes later STOP working. When I rebooted the MCU board, the SPI MAX would not work again! The whole SPI communication is NOT reliably on the LPC framework.

Klipper firmware works fine on the LPC framework MCU boards with the SPI MAX( MAX31855 or MAX31865) boards. I would love to see Marlin do the same!

If user forks are prohibited and can not be used temporarily, to fix the SPI problems with the LPC framework then, at the very least, put a message in configuration.h for the Marlin users of the LPC framework to let them know that they can not use -2, -3, or -5 temperature sensors until the SPI communication problem gets fixed.

//===========================================================================
//============================= Thermal Settings ============================
//===========================================================================
// @section temperature

/**
 * --NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table
 *
 * Temperature sensors available:
 *
 *    -5 : PT100 / PT1000 with MAX31865 (only for sensors 0-1)  [not available for env:LPC1768 or env:LPC1769 at the present time]
 *    -3 : thermocouple with MAX31855 (only for sensors 0-1)    [not available for env:LPC1768 or env:LPC1769 at the present time]  
 *    -2 : thermocouple with MAX6675 (only for sensors 0-1)     [not available for env:LPC1768 or env:LPC1769 at the present time]
 *    -4 : thermocouple with AD8495
 *    -1 : thermocouple with AD595
 *     0 : not used
 *     1 : 100k thermistor - best choice for EPCOS 100k (4.7k pullup)
 *   331 : (3.3V scaled thermistor 1 table for MEGA)

[GadgetAngel]

I am going to rerun the tests (on this new version of the PR) for the following boards to see if any issues show up:

1. SKR V1.3
2. SKR V1.4 Turbo
3. SKR PRO V1.1
4. GTR V1.0
5. SKR Mini E3 V2.0
6. RAMPS 1.4

I will post my results in table format here when my testing is done.

[slowbro]

@GadgetAngel @thinkyhead - With this being merged back in February, should the features.ini file have been updated with the proper libraries, too? Or will these be brought in some other way?

Marlin/ini/features.ini

Line 32 in 5326fdc

TEMP_.+_IS_MAX31865 = Adafruit MAX31865 library@~1.1.0

It looks like the code in temperature.cpp uses function calls specifically from GadgetAngel's repos, so things would fail when using stock Adafruit libs.

Marlin/Marlin/src/module/temperature.cpp

Lines 2704 to 2719 in 5326fdc

	#if HAS_MAX31855_TEMP
	Adafruit_MAX31855 &max855ref = THERMO_SEL(max31855_0, max31855_1);
	max_tc_temp = max855ref.readRaw32();
	#endif
	#if HAS_MAX31865_TEMP
	Adafruit_MAX31865 &max865ref = THERMO_SEL(max31865_0, max31865_1);
	#if ENABLED(LIB_USR_MAX31865)
	max_tc_temp = max865ref.readRTD_with_Fault();
	#endif
	#endif
	#if HAS_MAX6675_TEMP
	MAX6675 &max6675ref = THERMO_SEL(max6675_0, max6675_1);
	max_tc_temp = max6675ref.readRaw16();
	#endif

[thinkyhead]

Good question. It should be discussed over at #22682 as we're looking at fixing thermocouple issues there.