MAX6675 Reading over RPi 3B SPI

Basic Information:

Printer Model: Creality Ender 3 S1
MCU / Printerboard: Creality Stock
Host / SBC: Raspberry Pi 3 Model B, MainsailOS
klippy.log

klippy.log (745.0 KB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

I am attempting to use a MAX6675 as a chamber temp probe using the following section in my printer.cfg:

[temperature_sensor Chamber]
sensor_type: MAX6675

sensor_pin: rpi:None

spi_speed: 100000
spi_software_sclk_pin: rpi:gpio11
spi_software_mosi_pin: rpi:gpio10
spi_software_miso_pin: rpi:gpio9

The module I’m using works when tested with an Arduino Uno at 9600 Baud. It does not have a MOSI line, and there appears to be no config section for ‘MAX6675’. The attached klippy.log indicates ‘thermocouple open fault’ despite having a thermocouple attached. If I try to add ‘spi_bus: spidev0.0’, it is seen as an invalid item for the section. As far as I can tell, there is no display configured other than one using the UART lines.

It’s notable that the device should not have to run at more than 9600 Hz, yet the minimum configurable speed is 10x that at 100000 Hz. I don’t know if or what that’s a limitation of.

Swapping MOSI and MISO does not fix it. Swapping CS0 and CS1 does not fix it. Using SPI1 also does not fix it. All were done with the /boot/config options ‘spi0_cs0’, ‘spi0_cs1’ and ‘spi1_cs1’. Running the Pi off a DC-DC converter or USB AC adapter does not affect it.

Grounding the CS line stops the fault, but allows the Pi to take only a single reading from the MAX6675 as expected. It reads 1024C with the thermocouple properly oriented.

You are mixing up software SPI as in your config and hardware SPI. Stick do software SPI and try to explicitly set the CS pin as sensor_pin, e.g. sensor_pin: rpi:gpioXX

I got it working based on what you said. Thanks. Not sure if this is intended, but it works using the SPI0 clock and data pins with a different GPIO than 8 set as the chip select in printer.cfg. Would you also say it works to use SPI1 while specifying all pins?
As far as I understand it, SPI0 and SPI1 on the Pi 3 are in hardware and software respectively, and Klipper cannot use CS0/1 of SPI0 because they’re reserved for the hardware interface somehow. What I don’t understand is why Klipper can use SPI0, but not its chip selects.

You need to distinguish between software emulated SPI and SPI based on function blocks in silicon hardware of the CPU or MCU.

Your definition

spi_software_sclk_pin: rpi:gpio11
spi_software_mosi_pin: rpi:gpio10
spi_software_miso_pin: rpi:gpio9

tells Klipper to use the software version, which can use any GPIO and ignores the hardware capabilities of the pins.
If you want to use the hardware definition, then a simple (with nothing else):

sensor_pin: rpi:None

would have told Klipper to use the default SPI hardware bus and you would have been implicitly bound to the corresponding GPIOs 08, 09, 10, and 11.