SKR 2.0 support?

[Tophness]

Just wondering if the same principles can be applied to the SKR 2.0 board.
It's a whole new chip, but changing the pin values and such should work the same way, right?

[GadgetAngel]

Just wondering if the same principles can be applied to the SKR 2.0 board.

It's a whole new chip, but changing the pin values and such should work the same way, right?

Yes make the appropriate changes for PIN assignments and it will work. The principles or methods are the same, the PIN you choose changes between new boards.

Hope this helps.

[Tophness]

I've tried with the following pins but it crashes and I can't connect to it through USB-serial.

I'm not using your MOD-M library because it's now included in SKR 2.0 firmware, but other than that everything is exactly the same.
I had no issues getting it to work on my SKR 1.4 Turbo board so I don't think it's EBKAC error.
There is a variant.h in buildroot\share\PlatformIO\variants\MARLIN_F4x7Vx, but I've tried changing PIN_SPI_SS and PIN_SPI_SS1 from PA4 to PC4 in there and manually changing the pins in src\pins\stm32f4\pins_BTT_SKR_V2_0_common.h, as well as only doing one or the other. Same issue.
Tried using LCD and ONBOARD both in configuration_adv.h, as well as only in pins_BTT_SKR_V2_0_common.h, and every combination of both/either/or.
I set TEMP_0_CS_PIN to PC4 in configuration_adv.h and pins_BTT_SKR_V2_0_common.h with TEMP_SENSOR_FORCE_HW_SPI.
I would try software SPI, but now that they've included your lib in the new firmware, I'm not sure how to do that since it doesn't look for the same variables. Either way, I attempted it with TEMP_0_CS_PIN PC4, TEMP_0_MISO_PIN PA7, TEMP_0_MOSI_PIN PA6, TEMP_0_SCK_PIN PA5

[GadgetAngel]

Sorry about that

[GadgetAngel]

I've tried with the following pins but it crashes and I can't connect to it through USB-serial.

I'm not using your MOD-M library because it's now included in SKR 2.0 firmware, but other than that everything is exactly the same. I had no issues getting it to work on my SKR 1.4 Turbo board so I don't think it's EBKAC error. There is a variant.h in buildroot\share\PlatformIO\variants\MARLIN_F4x7Vx, but I've tried changing PIN_SPI_SS and PIN_SPI_SS1 from PA4 to PC4 in there and manually changing the pins in src\pins\stm32f4\pins_BTT_SKR_V2_0_common.h, as well as only doing one or the other. Same issue. Tried using LCD and ONBOARD both in configuration_adv.h, as well as only in pins_BTT_SKR_V2_0_common.h, and every combination of both/either/or. I set TEMP_0_CS_PIN to PC4 in configuration_adv.h and pins_BTT_SKR_V2_0_common.h with TEMP_SENSOR_FORCE_HW_SPI. I would try software SPI, but now that they've included your lib in the new firmware, I'm not sure how to do that since it doesn't look for the same variables. Either way, I attempted it with TEMP_0_CS_PIN PC4, TEMP_0_MISO_PIN PA7, TEMP_0_MOSI_PIN PA6, TEMP_0_SCK_PIN PA5

Well, off the bat, I can tell you that PIN_SPI_SS and PIN_SPI_SS1 should never be changed in variant.h file. So please change those back to the way they were.

The PIN_SPI_SS, PIN_SPI_SS1, PIN_SPI_SS2, and PIN_SPI_SS3 are used as the CS lines for the SPI bus and those in particular control the CS lines for the devices that are defined by the Mother board.

You need one free "un-used" PIN that does not have a pull-up resistor attached to it for you CS line for the MAX31865.board.

From looking at Marlin and looking at the SKR 2 schematic it looks like both PA4 and PC4 are both free "un-used" PINS.

I think I see the error. In src\pins\stm32f4\pins_BTT_SKR_V2_0_common.h set the following:

TEMP_0_CS_PIN         PC4
TEMP_0_MISO_PIN    PA6
TEMP_0_MOSI_PIN    PA7
TEMP_0_SCK_PIN      PA5

You accidentally swapped MISO_PIN and the MOSI_PIN. Try swapping them back and I think it will work for you.

[Tophness]

Should have made that clearer, I tried with the original MISO/MOSI pins and also swapping MISO and MOSI. I eventually got it to work by adding -DLIB_MAX31865 to my build flags and
LIB_MAX31865 = Adafruit-MAX31865=https://github.com/GadgetAngel/Adafruit-MAX31865-V1.1.0-Mod-M.git to features.ini to revert to your original external library.
I don't know exactly what the problem is about the new library, but SKR 2.0 default hardware SPI pins should already be set properly without any of this mucking around and they are with your old external one, so it's probably not todo with transferring the pin variables, debug options on still crashes before it can report anything, and the new marlin has the same problem on my older SKR v1.3 board. Using the external lib again fixes the problem.

[GadgetAngel]

Should have made that clearer, I tried with the original MISO/MOSI pins and also swapping MISO and MOSI. I eventually got it to work by adding -DLIB_MAX31865 to my build flags and LIB_MAX31865 = Adafruit-MAX31865=https://github.com/GadgetAngel/Adafruit-MAX31865-V1.1.0-Mod-M.git to features.ini to revert to your original external library. I don't know exactly what the problem is about the new library, but SKR 2.0 default hardware SPI pins should already be set properly without any of this mucking around and they are with your old external one, so it's probably not todo with transferring the pin variables, debug options on still crashes before it can report anything, and the new marlin has the same problem on my older SKR v1.3 board. Using the external lib again fixes the problem.

Well, sorry you are having problems. I am glad you found a solution. But as of now, I no longer use Marlin. I am using Klipper.

Please keep in mind. That my external library has issues also. The library uses synchronous reads (reads that are blocking, i.e. using delay(x)) for the MAX31865 communications, when it should use asynchronous calls. So you can not run the 3D printer at the fastest speeds.

I would spend time reading through the issues that Marlin has with the MAX31865: https://github.com/MarlinFirmware/Marlin/issues?q=MAX31865

See: MarlinFirmware/Marlin#20447 (comment)
and
See: MarlinFirmware/Marlin#22682

I developed my library because Marlin did not allow different boards to use the MAX31865 due to some unusual situations that would not allow the Marlin firmware to compile correctly. What I found was that the code implementation between different mother boards for SPI communications (hardware SPI) was handled differently. So I requested that Marlin allow the user the option to use an external Library for the MAX31865 to try to get around the SPI issues.

Since my first PR with Marlin, solved the problem at the time the PR was submitted, I quite developing the MAX31865 Library.

Since that time, Marlin has done a lot of work on the SPI communications for all the different platforms (mother boards). So I have no ideas what state the SPI calls for the MAX31865 in Marlin look like as of this date. Your best bet is to get on the Marlin discord and ask questions.

At this time, I do not have the time to look at the state of the Marlin firmware.

Good luck, and I hope you are able to solve all your 3D printer problems.