Go Down

Topic: Library works with MAX31855 as well as MAX6675 (thermocouple interface) (Read 766 times) previous topic - next topic

polypagan

Feb 06, 2018, 02:20 am Last Edit: Apr 03, 2018, 09:04 pm by polypagan Reason: Updated Library
I've been thinking about this for some time and today I wrote a library (attached, unless I forget to) that work with both MAX6675 (obsolete, but still available and very useful) or MAX31855 (more up-to-date, fussier to use).

Incidentally, I have seen on several web sites that these two chips are not pin-compatible.  That's true if you mean you can't drop MAX31855 into a MAX6675 footprint (both of these devices are SMD), because the newer part is 3v3 supply.  Otherwise, they are compatible. MAX6675 works quite well in 3v3 applications. It's the software that's the problem, and I've been using conditional compilation to work around that. This library should solve that problem.

Please try out my library. I'd like to have your comments and suggestions. I built it using Nano R3, but my target is ATtiny85. I'd appreciate hearing about any compatibility problems or successes, too.

Some specific questions:

Is there a flaw in my method of just doing a 32-bit read on a (possibly) 16-bit device and, if the two 16-bit words match, declare it a 16-bit part? Is there any condition where the 32-bit part could return two identical 16-bit words? Might the 16-bit part just stop disgorging data? Not specified.

Does it make sense to have a begin() method? My reasons for doing so seem weak, but not utterly ridiculous to me. They are:
1) the Adafruit_MAX31855 library has a begin() method. It is commonly done.
2) begin() allows me to avoid doing pinMode or digitalWrite at constructor time, which seems cleaner.
3) begin() can be safely called repeatedly to re-assert data direction and levels, say if the wire are shared with some other device.

Note that I don't test for begin() having been called (probably should). So, if you forget, it probably won't work.

I chose to do the 32-bit read on every call to readCelsius(). Obviously, that's not really necessary and could be gotten around with one more boolean. The cost just seems so low. I was gonna need to do a 16- or maybe 32-bit read anyhow. At least in my applications, I don't read the thermocouple more often than once per second, and I'm waiting around for a timer to expire to do that, so the wasted time doesn't seem like a problem.

Have fun, and I look forward to hearing from you!

NOTE: I have uploaded an updated library (farther down the thread).
There are 10 kinds of people in the world, those who understand binary, and those who don't.

pert

2) begin() allows me to avoid doing pinMode or digitalWrite at constructor time, which seems cleaner.
Yes, that's the reason for having it.

Note that I don't test for begin() having been called (probably should). So, if you forget, it probably won't work.
I don't think it's worth the overhead of the check. All you could do is make it not work if the check fails so it's really not that much different. If someone can't follow the directions well enough to call begin then they aren't going to have any luck with programming anyway.

polypagan

I agree with both of your points, and thanks.

I did go ahead and add a sop to backwards compatibility & sloppy programming by:

Code: [Select]

 if(!_begun)        // sop to back compatibility & lazy, forgetful programmers
      begin();

in spiread32();

This morning I am testing combinations of 6675 & 31855 parts in SPI mode.  I'm up to three and running out of hardware.
There are 10 kinds of people in the world, those who understand binary, and those who don't.

polypagan

Here's an updated version.

I've been using this for some time in several different applications. Seems to work fine.

Have fun & good luck!
Daniel

There are 10 kinds of people in the world, those who understand binary, and those who don't.

Go Up