Suddenly...

Created Sun, 26 Jun 2011 06:07:28 +0000 by Mr_Fixit

Mr_Fixit

Sun, 26 Jun 2011 06:07:28 +0000

All of the sudden, after a couple days having a good ole time coding, I start having problems compiling. To diagnose the potential cause of this problem, I wrote the most simplistic program I could possibly write to demonstrate the issue. The error I am getting is: /testEDR.h:4:18: fatal error: Wire.h: No such file or directory compilation terminated.

I have tried a number of libraries and get the same answer... So, what is the code? Here is the sketch:

#include "testEDR.h"

void setup(){ }

void loop(){delay(1000);}

What is in the .h file you ask? Well, for this particular test:

#ifndef testEDR_h #define testEDR_h

#include <Wire.h>

#endif

I have restarted my computer, re-installed the compiler, deleted the install folder, and got a fresh copy and installed it... same deal. Something dun got broked and I dont know what it is. I am on build 20110619. Even tried the older "Released" build and that did not work. There must be a configuration file that I somehow toasted, or perhaps yall can think of a better solution.

Mark

Tue, 28 Jun 2011 03:11:47 +0000

Hold down the shift key and then click the VERIFY button, it will give a bunch of output. Post that back so we can see what is going on.

Mark

Mr_Fixit

Tue, 28 Jun 2011 04:00:42 +0000

Useful trick.. here is the output:

C \Program Files (x86)\chipkit-win-20110619/hardware/pic32/compiler/pic32-tools/bin/pic32-g++ -O2 -c -mno-smart-io -w -fno-exceptions -ffunction-sections -fdata-sections -G1024 -mprocessor=32MX320F128H -DF_CPU=80000000L -D_BOARD_UNO_ -IC \Program Files (x86)\chipkit-win-20110619\hardware\pic32\cores\pic32 C \Users\Erik\AppData\Local\Temp\build4734234504180783282.tmp\ClassTest.cpp -o C \Users\Erik\AppData\Local\Temp\build4734234504180783282.tmp\ClassTest.cpp.o In file included from C:\Users\Erik\AppData\Local\Temp\build4734234504180783282.tmp\ClassTest.cpp:1:0: C:\Users\Erik\AppData\Local\Temp\build4734234504180783282.tmp/TestH.h:4:18: fatal error: Wire.h: No such file or directory compilation terminated.

Mr_Fixit

Wed, 29 Jun 2011 04:54:20 +0000

Ok, I found the solution to this, though IMHO this solution is shoddy at best. Apparently if a .h, .cpp, or presumably a .c file has one or more include statements, those include statements MUST also be in the main sketch file. I dont understand why this is, but it fixed the problem I was having.

After messing around, this is apparently a problem with the mainstream arduino compiler as well. Hopefully someone can fix this as I can see how this could be problematic with complex programs.

hairymnstr

Wed, 29 Jun 2011 09:57:27 +0000

.h files typically contain function prototypes, these declare the input and return variable types for each function. C and C++ compilers in general will compile each individual file separately then perform a linking operation on the assembled source to join up functions from one file to another. Therefore you need to have the types of each function called declared in every file that calls it. e.g. if you call a function declared in foo.cpp from bar.cpp you will want foo.h included in both to ensure the function types are the same.

This is standard practice in C/C++ compilers and isn't a bodge or work around.

Mark

Wed, 29 Jun 2011 11:47:48 +0000

We had similar problems, it has to do with the pre-processor portion of Arduino. We found that the order of #include files makes a difference. In all of our test cases, the problem was the same for Normal Arduino and for MPIDE.

Mark

Mr_Fixit

Wed, 29 Jun 2011 15:45:32 +0000

hairymnstr - Yup. I am aware of the purpose and intent of .h files. In my program, the sketch is extremely basic and has an instance of my robot, which is a class defined in a .h file.

The robot .h file has the main robot class and primary functionality. It has many jobs but is primarily concerned with managing the activities of the robot, so it creates instances of the various classes that it needs. One example is that I have a class for my SRF08 sensors, and the robot.h file must then create two instances of this (One for each sensor).

Point being, the main sketch has no use or knowledge of this sensor and is only concerned with creating an instance of the main robot class and triggering begin. So, there is no need to #include "SRF08.h" there, or any of the others for that matter. With any other C/C++ compiler this is not required. Typically we would only have to #include the files that define the objects we are immediately using, not all the child objects beyond that.

No matter really. Point is that it is working. Coding can continue, or as my friend says "[color=#FF0000]Beatings will continue until morale improves![/color]"

hairymnstr

Wed, 29 Jun 2011 15:52:43 +0000

Understood, that is odd behaviour :S