Hi all, I am posting this for anyone searching for this problem in the future. Everything is fine now, as you will see.
I am working on a project for a controller for burning waste oil. My first successful system was open loop and I set the pump PWM and duty cycles based on experiments with my own stove. But I can do better with a closed loop system, and a thermocouple for sensing the internal temperature would be great. It could delay the pump feed until the fire box was hot enough to sustain combustion, and could shut off the fuel if the combustion stalled.
So I bought some K probes and a popular controller was the MAX6675. I wrote a simple library for the STM8 (81 bytes!) to initialize and read from this chip. I wrote a simple test program to read the current value every second and output the result to the UART. No problems. The values jumped around a lot, but the datasheet said that there could be many bits error (times 1/4 C) per sample. I am interested in temperatures in a firebox full of flame, so I don't care about one or two C error. Everything looks fine so far.
I had new boards for my controller and the GPIO pins were different from my test program. This should be no big deal. My "new" code started as my previous code, which waited for 100 milliseconds, checked things, did things, and then waited for the next 1/10 second interval. As part of this 1/10 second check, my code read the current temperature from the MAX6675 and the K probe. And to see that it was working, I put the current value on the display.
PROBLEM: My display was showing either a temperature that might be correct, but never changes, or zero. Neither can be correct. My original test program was always showing the result bouncing around by at least 1/2 C. And zero is obviously wrong.
Is this my new board? I spent so much time checking the power, clock, chip select, and data lines. Everything looks good. I made a jig to get my oscilloscope probes on the three lines. *CS looks good. Clock looks good. I set the data line to weak pullup, and the MAX6675 pulls it down on *CS, and keeps it down for the entire cycle. I repeated this with other MAX6675 modules and K probes.
Should I stop here and let you guess? NO! I won't be that bastard.
Yes, I did read the datasheet several times after this problem, and probably three times before. BUT! The devil is in the details.
On page 5, it states, "Forcing CS low immediately stops any conversion process. Initiate a new conversion process by forcing CS high."
On page 2, it states the conversion time is 0.17 to 0.22 SECONDS. In my world, that is an extremely huge amount of time.
On my scope, I was getting zero bits (crap) from the MAX6675 chip and I was doubting it was even real. After adding a delay, it started giving normal numbers. Giving 250 mS between requests may be acceptable (from 220mS in the datasheet), but I have not tested that. 400mS seems to work for me.
I hope this helps anyone else using the MAX6675 and K probes.