[Solved] Issue with DallasTemperature Library (Compiling Issue)

Alright everyone. I have what I imagine is a simple fix. Here's my code: onewireexample.ino · GitHub

I've added the OneWire and DallasTemperature libraries found on the WebIDE to my project. I'm trying to port the same code I'm using on my UNO to the Spark to no avail. I've been slowing uncommenting part by part of my code and hit a wall.

Here's the error I got:

onewireexample.cpp:3:19: error: variable or field 'printAddress' declared void
void printAddress(DeviceAddress deviceAddress);

onewireexample.cpp:3:19: error: 'DeviceAddress' was not declared in this scope
onewireexample.cpp:4:23: error: variable or field 'printTemperature' declared void
void printTemperature(DeviceAddress deviceAddress);

onewireexample.cpp:4:23: error: 'DeviceAddress' was not declared in this scope
onewireexample.cpp:5:22: error: variable or field 'printResolution' declared void
void printResolution(DeviceAddress deviceAddress);

onewireexample.cpp:5:22: error: 'DeviceAddress' was not declared in this scope
onewireexample.cpp:6:16: error: variable or field 'printData' declared void
void printData(DeviceAddress deviceAddress);

onewireexample.cpp:6:16: error: 'DeviceAddress' was not declared in this scope
make: *** [onewireexample.o] Error 1

What the heck is going on? The line that's really confusing me is

variable or field 'printAddress' declared void

Anybody have any ideas?

Something is wrong with the include for the Dallas temperature library–you are not getting any of the included things you need like the typedef for DeviceAddress.

As a work-around, you can try to use the circle plus to add the .cpp and .h files to your sketch on the web IDE.

// This #include statement was automatically added by the Spark IDE.
#include "spark-dallas-temperature/spark-dallas-temperature.h"

I’ve actually tried that and I get the same problem. Any other ideas?

I actually figured it was a typedef issue so I added the type def to the .ino file. I don’t know if you are “allowed” to do this but it didn’t work anyway.

I really do appreciate the help.

Alright. I’m convinced that the preprocessor is a deranged maniac sometimes. Adding

#pragma SPARK_NO_PREPROCESSOR

Seems to fix the problem

1 Like

That was going to be my next suggestion! Typedef and preprocessor do not play nicely together in either the Arduino or the Spark world.

1 Like

Weird behavior I’m having here,

I comment the code at the beginning of the file and it works :

//#pragma SPARK_NO_PREPROCESSOR

If I remove it completely, I get these errors back…

Yup, that pragma doesn’t like being commented out that way.
You could try a block comment /* .... */, remove the # or do `//#//pragma …

but I need it to be there either complete or //commented to be able to compile :sweat_smile:

If you need it, you should have it without //

Just a comeback with my latest experiment with this library.

To avoid the use of #pragma SPARK_NO_PREPROCESSOR and compile normally.

I’ve set up all my functions outside of the .ino file.
it looks like this :

MyApp.ino :

//this is the file I added
#include "sensors_ds18b20.h"

//Instantiate my own Sensors_DS18B20 controller (18x ds18b20)
Sensors_DS18B20 sensors_ds;

void setup()
{
    sensors_ds.begin();
}
void loop()
{
    sensors_ds.runAndPublish( PUBLISHING_DELAY );
}

sensors_ds18b20.h :

#include "OneWire/OneWire.h"
#include "spark-dallas-temperature/spark-dallas-temperature.h"

class Sensors_DS18B20 
{ /....../  }

sensors_ds18b20.cpp :

#include "sensors_ds18b20.h"

Sensors_DS18B20::Sensors_DS18B20(void)
{

    _onewire =  new OneWire( DS18B20_WIRE_BUS );
    _ds =       new DallasTemperature(this->_onewire); 
/****etc****/
}

Conclusion, including the library from a header file instead of the main.ino compile just fine. Hence the capacity to remove completely this hack.

(phew, one week to learn c++, that was intense, yet so much left to learn :smile: )

The reason for this is, that .h and .cpp files are not treated by the Wiring Preprocessor anyway.

And I’d not consider the #pragma a hack but rather a way to re-establish normal C/C++ behaviour for .ino files too :wink:

Not including necessary headers and not supplying forward declared function prototypes is more of a hack than doing it right to start with :sunglasses: