3

I'm a longtime C programmer. I've also done a little C++, a little Java, and a LOT of Objective-C, but am fairly new to the Arduino platform and it's IDE.

So far all my sketches have had a single source file.

I see how you copy libraries into the libraries sub-folder of your Arduino source folder, either from the Mac finder or from the IDE.

I'm trying to understand somebody else's project (The "Camera Axe" device for high speed photography.) in that project there is a folder for the entire sketch, "cameraAxe". In that folder there's a file called "cameraAxe.ino", which follows the usual convention that the sketch's main source file needs to be inside a folder with the same name.

However, for this project there are 17 other source ".ino" files. Looking at the main "cameraAxe.ino" file, it only #includes 2 files, "EEPROM.h" and "DogmCA.h", both using the convention of enclosing the filename in angle brackets so the compiler knows to look in it's libraries directory. That makes perfect sense to me, and works like any other C compiler I've ever seen.

What I DON'T understand is how the compiler knows where to find the code for the many functions that are defined in other files in the same folder. There a function projectileMenu() which handles the menu for configuring a projectile sensor. That function is defined in the file menu01_projectile.ino, but it doesn't have a header, and there's no #include anywhere.

Does the compiler treat all the ".ino" files in your sketch folder as part of your source and compile them all together and as if they are one large file? I see tabs in the IDE for each of the files, which suggests that it does.

What if there are dependencies among the files? What defines the order in which they are compiled? Or is it a 2 pass compiler where the order of function definitions doesn't matter?

::wanders off, muttering in confusion::

Improve this question

1 Answer 1

Reset to default
3

arduino has its own little .ino preprocessor that generates forward declarations (like in a header file) for all function in the project's .ino files. Most of the time this just makes things less confusing for new users.

I'm not familiar with the entire process, but the effect is that any function in any .ino is known to all other .ino code.

Anything with .h or .cpp in a library or in the project file is treated as normal c++ code and not subject to arduino's manipulations. It will need "#include"s.

If you are interested, there is a hack to make arduino not mess with a function in a .ino file: add an empty "throw()" like this:

void foo() throw() {
}
Improve this answer
6
  • Interesting. What about #defines, global variables, typdefs, and things like that that are in secondary .ino files? And can you use .c as well as .cpp as a suffix?
    – Duncan C
    Sep 13, 2014 at 23:31
  • @DuncanC Basically any code that is in another .ino file is as though it was appended to the main .ino file.
    – geometrikal
    Sep 14, 2014 at 10:45
  • In what order though?
    – Duncan C
    Sep 14, 2014 at 11:28
  • I've done a bit of digging and it would appear the order is whatever java's File.list() gives, which is not guaranteed to be anything in particular.
    – BrettAM
    Sep 14, 2014 at 23:00
  • OMG, that's awful. So it is a typical single-pass C compiler where functions and variables have to be declared first before they can be referenced, but the order in which the files are parsed is not defined? It sounds like it handles function declarations through some kind of magic, but what about #defines, global variables, etc?
    – Duncan C
    Sep 17, 2014 at 2:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.