I wrote a Photon app a few months ago, and it worked fine. Now I’m revisiting it to enhance it, and I’m getting a whole bunch of errors. Googling “OneWire/OneWire.cpp:135:15: error: ‘INPUT’ was not declared in this scope” results in exactly one hit, in these forums I believe, but I couldn’t find a followup thread that solves it. Here is part (but not all!) of the error dump:
OneWire/OneWire.cpp: In constructor ‘OneWire::OneWire(uint16_t)’:
This looks like an error in OneWire library.
Would you like to create an issue on GitHub to let the author know?
OneWire/OneWire.cpp:135:15: error: ‘INPUT’ was not declared in this scope
pinMode(pin, INPUT);
^
There are probably 40 or 50 similar “not declared in this scope” errors.
I tried compiling a file I found somewhere (I don’t remember where) called “sparkcoreonewiretest” and it does the same thing.
OK upon reading some more about this, I now realize that my issues are because I switched to a Photon from my original Core that I developed the code on. I naively assumed they were bit-compatible, at least at the library level. Doh!
One more comment – I found another “OneWire” lib that is already in Build. Just re-pointing to that library (via the Include in App feature of Build) fixed everything. The Particle-OneWire lib would’ve required code changes – maybe quite a few. The new OneWire one seems to be backward-compatible with the one that I used with my Core.
I’m also having a bit of headache with the OneWire library. Whenever I try to use the OneWire type in a file other than the main .ino file or if I try to pass a parameter of type OneWire to a function, I get this error:
'OneWire' does not name a type
Any idea what’s causing this? It’s pretty ugly that the library’s code can only be accessed in the main .ino. Makes the code messy. Or Am I doing something wrong?
That’s not ugly but very normal in C.
Each file needs to include the needed headers to make non-keywords known to the compiler.
Each file gets compiled as seperate module and only gets linked to the others after all modules have been compiled successfully.
No, no, I know that But even if I include it or pre-declare the class, it still doesn’t accept it as a type. It must be some Arduino-like wizardry, definitely not a C or C++ mechanism.
Even in the main .ino file I can’t use OneWire as a normal type:
OnewWire obj (PIN); //This works
void func (const OneWire& obj); //This gives error:'OneWire' does not name a type
I checked the OneWire type definition in the OneWire library header and it’s declared as a normal class. So there must be some Arduino-like wizardry involved here.
One guy mentions on the Arduino forums that this error can be cause by not having your library source files in the right place within the libraries directory. But since I’m using the online IDE, I have no control over where the library source files are…
Another strange thing is runtime behavior.
If I declare the OneWire object on the stack at the top of the main .ino file, the temperature reading works fine:
OneWire obj (PIN); //Temperature reading works later
But if I declare a OneWire pointer and I allocate space for the object on the heap in the setup function, the temperature reading fails:
OneWire* obj;
...
void setup ()
{
obj = new OneWire (PIN); //Temperature reading fails later
}
// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"
OneWire obj(D1); //This works
void func(const OneWire& obj);
And it even builds when having the prototype for your fn() in its own header and the implementation is the respective .cpp file.
like this
This is very strange… I don’t understand how it works for you to pass it as param and to put it into another file and why the same thing does not work for me…
If you look at my example in my previous post, I did instantiate the class in the setup() function, like this:
obj = new OneWire (PIN);
By failing, I mean that somewhere in the temperature reading something fails and ultimately it returns 0 degrees instead of the actual temperature.
I don’t want to spam this forum by posting the whole source code here…
Firmware used to build is the latest (0.4.5) and the device is a Photon.
Yes, there was a typo, but in the IDE it was correct
As soon as I copy for example this line of your code into my IDE, it starts giving me the error (“OneWire does not name a type”) :
void func (const OneWire& obj); //ScuffR's code, compiles fine for him, not for me
The only thing that I have in my main .ino file before the point where I pasted your code is this:
#include "LiquidCrystal_I2C_Spark/LiquidCrystal_I2C_Spark.h"
#include "OneWire/OneWire.h"
#include "TimeUtils.h" //Some header of mine, nothing interesting in it, just some simple functions
#include "Temperature.h" //Some header of mine, nothing interesting in it, just some simple functions
#include "SystemUtils.h" //Some header of mine, nothing interesting in it, just some simple functions
const int OneWirePin = D2;
LiquidCrystal_I2C* lcd = NULL;
OneWire oneWire (OneWirePin);
byte oneWireAddr[8];
int lastSecond = -1;
This should not interfere with the OneWire library code…
Don't try to past one line of my code into your file, use my whole sketch and move forward from there by adding one library after the other and always verify/build each state and then add your own files and finally your own code bit by bit.
When you get an error you've found the culprit - it's obviously not the OneWire library as such, as it just compiles with my sketch.
Just for extetics I think you should not have these blanks between the function name and the parameter list.
BTW: I doubt this worked even without the typo, since it'd expect a public OneWire::OneWire() which isn't there.
The public constructor requires one parameter which you don't provide by writing it this way.
Yes, sorry, I forgot to add the int parameter to the constructor. I’ve edited my previous posts and added it now.
About the spaces between the function names and the brackets… I’m used to writing it that way. Our coding style at work requires it.
Ok, I’ve tried pasting your whole code from your .ino file into a new app:
// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"
OneWire obj(D1); //This works
void func(const OneWire& obj); //OK
And it works… as long as the function func does not have an implementation. Try adding an empty body to function func and it immediately starts not compiling.
// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"
OneWire obj(D1); //This works
void func(const OneWire& obj) {} //Ooops! "Error: 'OneWire' does not name a type"
I also had code in the function, I also had other functions (besides setup() and loop()) between prototype and implementation and I had things divided in several files (as above) - it just builds fine.
But I would avoid to have an object named the same as a parameter of a function in the same scope, as you are reusing obj above.
OK, I have figured out the difference. The above two pieces of code are indeed identical. The difference was that for the one that did not compile there was a blank line before the first line of code (before the #include statement). And this is what makes the difference. If there’s a blank line before the include (anywhere before it), you get the compilation error. So weird!
Well, it seems that anything before the OneWire include causes the error, not just blank lines but any line of code before it.
So I moved the OneWire include to the first line of the .ino file, and it works. But this is soooo very strange…
Especially since there was an exactly opposite issue a long time back when things only worked with a blank first line.
Maybe something @suda wants to know of.
But even if I include it or pre-declare the class, it still doesn’t accept it as a type. It must be some Arduino-like wizardry, definitely not a C or C++ mechanism.