Add rawData to MAX31855

[pmarchini]

PR as requested in #1

[FabioBrondo]

@pmarchini i'm looking at your modifications, in order to learn something...

Tell me if i've get it in the right way:

First you have modified the MAX31855.cpp file, declaring a variable that have the same value of _value _rawData = value;

and after that declared _rawData (?)

uint32_t _rawData;

Than you have created a function, that returns the value of rawData out of the class

uint32_t getRawData() { return _rawData;};

After that you have modified the file MAX31855.h , inizializing the value of rawData to 0, and after that assigning the value of the 32 bits obtained from the module.

In the end you return rawData.

But the question ( maybe stupid ) is, what connection there is between the two files? In the .h one, you declare rawData and assign to the variable the value of the 32 bits, in the .ccp file, what do you do?

[RobTillaart]

The .h file defines the interface of the class (the WHAT functionality does it offer)

• which functions has it (and if they are rather small you can include their implementation)
• which are the internal variables of the class. (for its own administration)

The .cpp file holds the implementation of the larger functions. (HOW is it implemented) The implementation is "hidden" for the user and may change over releases, preferably keeping the interface (.h) the same

---

The private variable rawData holds the last read value, therefor it is used in the _read() function so it automatically holds the last value of the raw data. IN the previous version the raw data was a local variable in the _read() function so its value was gone when the function was done.

The uint32_t getRawData() { return _rawData;}; is a public function so the user can use this in its application. This way it is prevented that the variable rawData is written to by accident.

does that help?

[FabioBrondo]

Yes! I've written this small code:

#include <SPI.h>
#include <MAX31855.h>

#define MAXDO     12 // Definizione pin MISO
#define MAXCS     1  // Definizione pin CS
#define MAXCLK    13 // Definizione pin SCK 

MAX31855 thermocouple(MAXCLK, MAXCS, MAXDO); 

void setup ()
{                               
  Serial.begin(9600);
  delay (250);                  
}                             

void loop ()
{                               
  long int value;
  delay (100);                  
  thermocouple.read();
  value=thermocouple.getRawData();
  Serial.print(value, BIN);
  Serial.print("\t");
  Serial.println();

}                             

I've also putted a pullup resistor over the MISO pin, this is the result:

[RobTillaart]

@FabioBrondo

When you post c++ code you should add cpp after the three backquotes to get syntax highlighting, (I edited your post)

```cpp

it shows nicely 32 HIGH's in a row.

What does it look like when you remove the pull-up resistor?

[FabioBrondo]

If you leave the pin floating, the output is not stable:

[RobTillaart]

So a bit like I predicted, that it won't be zero all the time.

With the rawData in place you have an important building block to detect the "NO_BOARD_ERROR".

There should be a note in the readme.md file about the pull up resistor (which pin, size etc).

[FabioBrondo]

Is possible to upgrade the library to detect the no board connected?

No ideas on how to code it.

The new "table of truth" could be:

Bit set	Description
None	OK
0	Board connection error
1	thermocouple open circuit
2	thermocouple short to GND
3	thermocouple short to VCC

Or in each sketch could be enough in the code to add the following code?

if(rawData == 1)
Serial.print("Board error! Check board connections \n");

or

if(rawData & 0xFFFFFFFF)
Serial.print("Board error! Check board connections \n");

[RobTillaart]

The value zero should not be used for errors, that is an often used convention so I want to keep that.

I will have a look at the library code.

[RobTillaart]

@FabioBrondo I updated the library so that read() returns a STATUS_NO_COMMUNICATION in case the value read is 0xFFFFFFFF.

I called it no communication as that is what can be concluded from the faulty bit signal. Also check the readme.md file as I updated the table of return values there. Slightly different than your proposal.

Please rebase the library (git pull / merge), and have a look at the changes made.

[FabioBrondo]

@RobTillaart i've seen the changes, they look great! What do you mean with:

Please rebase the library (git pull / merge), and have a look at the changes made.

[RobTillaart]

As I merged changes into the library you must merge my changes first into your stream so your changes become changes with the latest state of the master branch. If I now merge your changes in , mine might get lost.

[FabioBrondo]

You're talking alien language to me! Tell me what i have to do, i'm not understanding right now

[RobTillaart]

Best is to read the course material I send you a link from. It is too much to explain right now in a few lines.