Arduino blog

Arduino blog

Arduino thinkering

This blog is about things I come by related to Arduino which I feel are inspiring/important/funny enough to write about.

Some support for ino files in the arduino eclipse plugin.

eclipse pluginPosted by Jan Wed, May 21, 2014 14:58:42
If you have upgraded to the latest version of the plugin (nightly builds only) you may have noticed that there is now some support for ino files.
I hear you say: ino files???????? I thought you didn't like those?

Well I never objected to ino files in the Arduino eclipse plugin but I never saw the need for it as well. I mean someone who can handle C/C++ should not need the functionality ino files offer. I fully support the ino file decision made by the Arduino team in the Arduino IDE, but if you step up to eclipse you should be able to do without ino file functionality. I even embraced this because this keeps the unexperienced away.
Next to that I never saw a clean way to implement ino file support.

So what has changed?
Using the Arduino eclipse plugin I learned to know some weak points that are related to ino files. These are:
1) I noticed that I still use the Arduino IDE to look at the sample programs. Each time I download a library it is simply easier to start the Arduino IDE to look at the samples.
2) The eclipse plugin is perfect to make Arduino libraries but due to lack of support for ino files there is a weak point in developing the sample programs for the library.
3) Due to the above I noticed I have lots ( read: to many for me to handle) projects in my workspace. This is cause by having sample programs for each and every library I make which I can not really delete or get rid of (as a project) due to the above. If the plugin had better support for ino files I could just drop the project in the examples folder of the library. As a result there is a clearer link between the "library and examples" and I have a cleaner workspace.
4) I found a nice way to have some support ino files.

Some support for ino files?
It are the first versions so not all functionality is there. If some functionality is to hard to implement I won't bother doing it (unless a sponsor whips out his wallet big time)
And do you have an extensive list of what Arduino IDE supports in the ino files (if so please send it to me)
What is at the time of writing the supported features:
1) joining all ino files in 1 big file.
2) inclusion of Arduino.h
3) All includes are repeated at the top af the big file (after #include "Arduino.h")
4) All function declarations are added at the top of the big file (after the includes).

And the bonus is:
For me the big advantage is that I also wrote some code to create a project based on multiple examples. In the import wizard after you have selected your Arduino you can select the examples. I opted for multiple because the granularity of a example is different from that of a real project.
While I did so I immediately also import the library containing the example. if you select 1 simple example (those who do not have library dependencies and do not depend on "special ino functionality") it should compile after the wizard has finished.

How it works?
As I sated in point 4: "I found a nice way to have some support ino files.".
I'll share that nice way so you understand what is going on in case something is not working.
First of all: the code is based on the cdt indexer and does not parse the source code like Arduino IDE does.
I query the cdt indexer and dump the info I need in a file called .ino.cpp. . files are ignored by the Arduino IDE so that makes the solution compatible.
Buy querying the CDT indexer I can do 2,3,4. After that I add a #include "xxx.ino" for each and every ino file in the project.
As a result all *.ino files are compiled as 1 big file and line numbers and references all still work.

Wait a minute... If the code of the ino file x.ino is included in .ino.cpp and x.ino the code exists 2 times; that will give conflicts.

yes and no. You have to flag *.ino (and add *.pde as well) as C++ source code in eclipse. If not, the indexer will not parse the code and the GUI will not represent the code in a nice way. These are CDT parts and they work file based so the code will exists only once for CDT.
The compilation is done by make based on a make file generated by my plugin.
So when I create the make file I exclude *.ino files from the build.

What are the currently know limitations?
1) all headers must contain #include guards
2) You can not use a define in the code before the include to modify the behavior of a header file (use the project properties to do so)

To avoid errors in the build in the generated function declaration part I need to first include the headers. As I do not want to touch your files I can not exclude the headers. therefore all headers are included 2 times.
For example the example toneKeyboard will give warnings

For the same reason as above a #define in front of your header will actually end up between the 2 includes. Due to the #include guard the second include will be ignored and as such your define is actually after the real include.

Bugs can be reported at <>


  • Comments(0)//