#include problem

I am trying to move some of my common #defines and functions out of my sketches and into an include file.
(I'm not patient enough to make a library :wink: )
The #defines are no problem and neither are many of the functions I add.
However, when I add a particular function into the new tab for the .h file, I get those red compile errors.
The root one seems to be:
[.....\Temp\build8774.tmp/Base_Funcs.h:33: error: 'getIRKey' was not declared in this scope]

The function that I add that causes this is . . .

int getIRKey() { // used by get_remote() reads IR & converts Sony keys *V2* 
  int duration, irCode, mask;
  do {                                   // wait for start bit
    duration = pulseIn(ir_pin, LOW);
  } 
  while (duration < 2160 || duration > 2640);//Wait for a start bit look for
  irCode = 0;                         //  2200ms pulse.
  mask = 1;                         // set mask to bit 0
  for (int idx = 0; idx < 7; idx++) {       // get only 7 of the 12 bits
    duration = pulseIn(ir_pin, LOW);     // measure the bit pulse
    if (duration >= 1080)               // > 1000uS it is a 1
      irCode |= mask;                       // yes, update ir code
    mask <<= 1;                               // shift mask to next bit
  }
  irCode = irCode +1;                    // convert raw return to actual digit values
  if (irCode == 10) irCode = 0;          // special case for zero key
  return irCode;
}

I know I'm doing something wrong but I don't know what.
Seems like it has something to do with passing variables between the main sketch and the #include.
Any thoughts or tips are appreciated.
[Edit] Tried declaring the function "static" but no help.

Its not considered good practice in C to put functions in an include file. You can create a new C file(s) for the functions in the sketch directory and these will appear as tabs and be compiled and linked together.

Your common #defines can certainly go into an include file and you will also want to have the prototypes of the external functions in an include file as well.

FYI, functions in a C file that are to be accessed from other C files shouldn't be declared static, static functions are only visible to other functions in the same file.

int getIRKey() { // used by get_remote() reads IR & converts Sony keys *V2*

I have a feeling this sort of thing has come up before, and the problem was the line comment on the same line as the start of the function definition. Try removing "// used by get_remote() " etc. and see if that helps. The Arduino IDE does some preprocessing to automatically produce function prototypes and it gets confused sometimes.

Andrew

Are you trying to call getIRKey()? Or is the error referring to the definition itself?

The Arduino IDE doesn't do any pre-processing of your .h files, so it shouldn't matter (I think) that you have a comment next to it. This means, however, that you might need to declare your own function prototypes.

What else was in the header file?

Thanks for your replies.
"mem" - yes, I know, I heard the same from the "real" C developers we have at work. Actually, I took my queue from the BlinkM examples where BlinkM_funcs.h has all the base C funcs they use, and so I wanted to try it. At ths point, it's become wierd enough where I might not persue it, other than out of curiosity. (Note, however, that BlinkM_funcs.h does use "static".)

Andrew, your sugg looked promising, but no joy.
mellis, here is a better description of what's happening . . .

Sketch (tab) . . . .              |Base_Funcs.h (tab) . . .
#include "Base_Funcs.h"           |    #include "WConstants.h" (no help)
                                  |
[Functions that call              |
long get_remote(int key_type) ->  |    long get_remote(int key_type){
                                  |     // stuff . . .
                                  |     key = getIRKey(); // calls this
                                  |     <---
key = getIRKey();                 |     // more stuff (i.e big case statement) }
// This is the function I can't   |
move to Base_Funcs.h              |

Prototypes may be the answer. Would I do this in the Base_Funcs.h?
In any case, no reason to "beat a dead horse", but will try any any suggestions. Thanks again.
John

So you're trying to call the same function from within the sketch and from within another function in the header file? Which one gives the error when you move the called function to the header file?

Not quite, (I think!)
Diagrammed above is the code that currently compiles OK. In it,
getIRKey (in the sketch) is only called by get_remote (in the header).
The sketch never calls getIRKey directly, it's only called by get_remote.
So what's working, is the sketch calls a function in the header which calls a function back in the sketch.

When I cut getIRKey out of the sketch and paste it in the header (next to it's buddy), I get the compile errors . . .

[. . . ]\LOCALS~1\Temp\build20569.tmp\/Base_Funcs.h: In function 'long int get_remote(int)':


[. . . ]\LOCALS~1\Temp\build20569.tmp\/Base_Funcs.h:124: error: 'getIRKey' was not declared in this scope


Couldn't determine program size: C:\Program Files\arduino-0010\hardware/tools/avr/bin/avr-size: '[. . . ]\LOCALS~1\Temp\build20569.tmp\Laser_Alarm_RTC_Logger.hex': No such file

I thought that perhaps a function can't call a function when in a header, but I've seen that work with another set of functions I tried.
BTW, I also tried deleting the "applet" folder between compiles.

[Edit] I've tried using this include with other sketches and things that would work in one sketch don't work in another. I'm on real shakey ground with this idea, so I'm going to bag it and make a lib the right way. Don't know how BlinkM got away with it! Thanks much for your help though.

In the header, you need to declare getIRKey() above get_remote(). Or at least a prototype for getIRKey().

Bingo! Thanks a lot! I didn't think the order made any difference, but I guess it does in an #include file!
That's great. I think I'll take another stab at it. I was trying to go the lib route, and having trouble on that front too.

Thanks for sticking with me.
John

Right, that's why we generate prototypes for functions in your sketch: so it doesn't matter what order you do things in. When you start using header files, though, we figure you probably know what you're doing so it's best not to mess with your code.